Server Help :: View topic - <c> Do you have PMS?

Server Help

ASSS Custom Projects - <c> Do you have PMS?

50% Packetloss - Mon Apr 04, 2005 3:46 am
Post subject: <c> Do you have PMS?

Prize Management System (I liked the acronym)

Well I figured I needed to start somewhere and decided to remake a powerbot plugin that always was my favorite. I believe the same idea was implemented on a few mervbot plugins too.
It's fairly simple, the module stores prizes given by the ?pgive command by moderators and then the player can claim them at their digression. Moderators can ?plist (display) the list of prizes and manage them with ?pdelete. Players can ?myprizes (display) their own prizes and ?prizeme to claim them. Prizes also have an expiration time, 7 days by default.

The module is capable of storing bounty plus one of every special item. I though about making it capable of storing multiple special items (like 4 bits per item) but decided that it is a waste of memory. Also it only stores positive special items (it isn't really a prize if it hurts your ship). There were also some things that might people might like added to the module (assuming that it is actually useful for someone). Currently it doesn't load settings from an ini file, seeing how it only has 1 real setting (expiration time) I just made it a #define and placed it at the top of the code. Also logging of prize-actions might be useful, so that sysops can view the logs and check if mods are prizing themselves or any other frowned upon actions are taking place. Expiration notifications would be a bit of code but doable, so that when players entered the zone they would be notified that their prize is expiring soon. And last, players giving other players their prizes, It's doable but I think I might need to change some variables so that it doesn't look like the original operator who gave the prize, gave the prize to the person who received it 2nd (if that makes any sense). So if you really think that this module might benefit your zone and you need something small like the above added to it, I might consider adding it.

There are also 1-2 things that I don't really like too much, but am willing to live with. I made the ?plist and ?myprizes commands print out legible prize displays that look sexy, but if a moderator prizes a ridiculous amount of special items, then it kinda messes up the nice look of the display. I considered a few fixes but I don't really care that much, normally people only get prized 0-10 special items. Also, my cmd_ functions run a function I made called ClearSpaces(char*). It clears the space character from the string and makes it easier for me to deal with multiple number params (?pdelete 1,5,2 or ?pgive 50% Packetloss:500:prox,shields,super). It might be slightly frowned upon to edit another module's data, but it seems fairly safe as long as there aren't other modules using the exact same command names as the above module.

I wrote this module using VC++. I gave makefiles a shot and found that they make me annoyed. So I apologize to the linux people for not having a linux binary nor a makefile for the above module. But for those windows users, I included the VC build of the pthread dll, you will probably need it for this plugin because I used util.h/util.c for grel's nice amalloc function and some other stuff. So I'm not sure if everything I wrote is linux-compatible or not, but if someone makes a makefile and/or edits the code to work for linux, I would be very grateful.

Finally some thanks are in order. First off, the entire idea of prize management belongs to The Junky, I used a few of his ideas and improved/unimproved on a few others of his. I read through a lot of source code, all of which belonged to smong and grel, so I owe them some thanks, plus I liked smong's readme.txt format that he enclosed in his modules and used that format to make one for the above module. Also I'd like to thank grel, for a very well written program, a development document that was passed to me that was very informative, and for putting up with some retarded questions that I asked him while I started to learn ASSS.

I did my best to make sure that the module is bug-free but if you encounter anything, drop me a forum private-message and I will look into it. Also I tried to comment most of my code to make sure it made sense to anyone who was reading it, but if you have a question about a part, just drop me a message.

Anonymous - Mon Apr 04, 2005 9:43 am
Post subject:

Nicely done 50, sounds like this module is gonna be really nice, ill put it in my zone and test it out ASAP

Smong - Mon Apr 04, 2005 7:35 pm
Post subject:

You might want to put a 19 character limit on the name length.

A version or date in the initial comment could be useful later.

I notice you are writing the 'next' member of the PrizeItem struct to the file, maybe unecessary?

ClearSpaces function, maybe use isspace(char)? (You are already using isalnum(char)).

Instead of hacking a prize packet together manually why not use the GivePrize function from game.h?

50% Packetloss - Mon Apr 04, 2005 9:48 pm
Post subject:

-Names are of 24 character length according to the Player struct outlined in ASSS (it is the only name garenteeded to be NULL terminated).

-Yah, I probably should add a version number, my bad. Just consider the above v1.0. I dated the .txt file though

-Writing the pointers to file doesn't hurt anything, but yah, it might be slightly wasteful (4 bytes per prize). I'll probably edit that, thanks <3.

-The ClearSpaces approach might be better than checking every character until I get to the numbers that I wish to pick out of the string. I use one pointer to find the ',' character in the string and then use another to determine if there is a valid number before that comma, it saves me doing a few extra loops to skip over spaces.

-Take a look at game->GivePrize, it is built more for multiple players. Lets have a look,

Code: Show/Hide

local void GivePrize(const Target *target, int type, int count)
{
struct SimplePacket prize = { S2C_PRIZERECV, (short)count, (short)type };
net->SendToTarget(target, (byte*)&prize, 5, NET_RELIABLE);
}

So far it looks ok, it makes the simple packet the same way and then sends it to SendToTarget() function

Code: Show/Hide

void SendToTarget(const Target *target, byte *data, int len, int flags)
{
LinkedList set = LL_INITIALIZER;
pd->TargetToSet(target, &set);
SendToSet(&set, data, len, flags);
LLEmpty(&set);
}

This is wasteful if I'm only prizeing to a single player. The function makes a linklist and then calls some other functions to fill it with however many players are in the Target* variable. Then the SendToSet() function does the exact same thing as SendToOne() except for a linklist of players. So for the purposes of the CPrize() function (it handles *prize commands), the game->PrizeGive is great if it is sending arena-wide prizes, but for a single player it is probably better to just do it by hand and save the other modules the trouble of making/parsing a linklist.

I appritiate someone looking through my code to make sure it's sound. Thanks Smong <3.

Smong - Tue Apr 05, 2005 12:55 pm
Post subject:

I think there is a misunderstanding with the ClearSpaces function.

Quote:

local void ClearSpaces(char *string)
{
char *ptr= string;

while(*ptr != '\0')//cycle through string
{
if(!isspace(*ptr))//if the character isn't a space
{
*string++ = *ptr;
}
ptr++;//increment through string
}
*string = '\0';//terminate the string
}

I suggested using GivePrize for auditing purposes.

50% Packetloss - Tue Apr 05, 2005 1:16 pm
Post subject:

oh, ok. Thanks.

50% Packetloss - Tue Apr 05, 2005 7:45 pm
Post subject:

Actually, it is always faster to just do the compare than to call a function. Durring a function call, the instruction pointer and registers get pushed on to the stack and then get popped off at return;. So, checking for spaces is easy and I got lazy and called the isnum function in a few places. I'll probably fix that.

Grelminar - Wed Apr 06, 2005 12:42 am
Post subject:

It's painful to see this attitude. Don't you know that premature optimization is the root of all evil? Have you ever measured the actual "savings" of one of these inane optimizations? Is the relative importance of programmer time versus CPU time completely lost on you? Do you not realize that the context switch to the sending thread probably costs more than the "overhead" of using GivePrize?

Here are some basic rules to follow: Never optimize. Maybe, later, once your code is working perfectly, profile. Then profile again. And a third time. Then think really hard about whether it's worth it. Then, maybe, try optimizing one function, and go back to the profile step. Finally, learn how to spell.

Mine GO BOOM - Wed Apr 06, 2005 2:15 am
Post subject:

Grelminar wrote:

Don't you know that premature optimization is the root of all evil?

Well, if you optimize your design (ie: Merge/Quick sort vs Bubble sort), its fine. But trying to do assembly level optimizations, yeah, that is a waste of time unless you are trying to port HL2 to PSP.

50% Packetloss - Wed Apr 06, 2005 4:28 am
Post subject:

I don't understand why you are angry about something so small. I could care less about a few cpu cycles and mostly care about my code being legable. It doesn't make sense to go through a "middleman" module just to do a simple job of sending a simple packet.

Although ASSS only really cares about return mm_fail; durring mm_load, it is still important that it returns the correct return value for all "int action" cases (just in case in the future that changes). It also makes it easy for people reading the code to understand in which "cases" I have code doing something and which I have nothing happening. A switch makes things readable and the entry-point really isn't called that frequently.

ASM level optimizations arn't important.

I have plenty of time, most of which I spend doing homework: so to me, it's worth it to spend a little extra time thinking of the best solution (or the best I could come up with at the time). And I'm not exactly writting a novel here, so who gives a fuck how I spell. Noticing spelling mistakes is a sure sign that you arn't getting laid.

Bak - Wed Apr 06, 2005 6:05 am
Post subject:

u spelt "aren't" rong

Mine GO BOOM - Wed Apr 06, 2005 12:04 pm
Post subject:

50% Packetloss wrote:

What if someone like me decides to make a new client? To design a new packet style, all you would have to do is change a few functions around to send the correct type to specific clients. Sending the packet directly to net assumes that they understand that packet specifically.

Being modular means that when you want to upgrade functionality, you only have to change in one location, and the rest of the code world doesn't notice a thing. Shaving off a few milliseconds here and there is nice, but also can destroy portability. Yes, its a ways of processing power, but it isn't like calculator is currently running the server.

As Grelminar said before, saving programmer's time is more important that computer time. If your module is used once a second, and your optimization saves half a millisecond (being very generous), you'll save your processor 4 hours of work a year. Now, say someone makes a new client with a new protocol, that even includes P2P packets, and has to go around and fix all the packet handling methods in ASSS, instead of making a whole new server. They release a patch, and you apply it to your server. All these new clients get weird errors and bugs only in your zone, so you spend some time debugging, and attempting to figure it out. How long will that take? How much energy and effort will it take for the maker of that new client to help and debug a problem that is in no way his?

4 hours of computer time saved a year per zone, under heavy, heavy usage of your optimizations, accounts to nothing. Keep it modular, and you'll keep its portability. Computer time is cheap, programmer time isn't. You'll find this out whenever you spend time trying to upgrade or fix some long gone programmer's "optimized" code.

50% Packetloss - Wed Apr 06, 2005 12:31 pm
Post subject:

Point taken, code changed and uploaded <3.

Anonymous - Wed Apr 06, 2005 1:37 pm
Post subject:

can someone put that in lamen's terms? too many big words for me, i just wanna know what the fuss is about

Mine GO BOOM - Wed Apr 06, 2005 2:27 pm
Post subject:

He made a specific part faster, but by doing so, it makes it less upgradable. Its like adding aftermarket turbo charger to your car. Sure, it makes it faster now, but when you go in for repairs for another part of your engine, YOU personally have to make sure that the repairs and the turbo charger work together, or pay much more money for the mechanic to deal around with it.

Anonymous - Wed Apr 06, 2005 5:34 pm
Post subject:

oh ok thanks MGB

Mr Ekted - Fri Apr 15, 2005 11:44 pm
Post subject:

Grelminar wrote:

You are assuming that optimization is just tweaking stuff here and there to make it faster. This is a flawed view of coding. Very very often in projects with any degree of complexity, there are many ways to approach the problems. Choosing one way over another might be one or more orders of magnitude of improvement in speed. Switching between the approaches is rarely a tweak. Good optimization starts at design-time, and continues through typing code in. A decent coder doesn't have to optimize or profile (except in the most extreme cases) because they generate decent results the first time.

Ultimately, the problem is that the true average coder (ie college CS grad with 5 years on the job) is a complete and utter newb who has no clue what they are doing. This results in seriously bad code, where small tweaks can make things really fast (ie from ludicrously slow up to incredibly slow). In this situation, there's no hope of reasonable design from the start.

Grelminar - Sat Apr 16, 2005 3:14 am
Post subject:

In that post, I was using "optimization" to refer to "micro-optimization", which is what I was responding to (copying code instead of using game->GivePrize(), avoiding isspace() and isalnum()). Of course there are many higher-level concerns that affect performance, and can be optimized, and will most often have a larger effect than any micro-optimization. That was what I was trying to imply by mentioning the context switch.

SamHughes - Sat Apr 16, 2005 3:22 pm
Post subject:

What is wrong with using isspace() and isalnum()?

Mine GO BOOM - Sat Apr 16, 2005 10:22 pm
Post subject:

SamHughes wrote:

What is wrong with using isspace() and isalnum()?

Nothing, use them. Almost any compiler made in the last 6 years will be able to optimize them very well by inlining them or other neat tricks.

Solo Ace - Mon May 23, 2005 6:52 pm
Post subject:

It's not my intention to bump or "hijack" this thread, I just thought it'd be good thread to post the question I wanted to ask a while ago in now.

I'm using MS Visual C++ 2003 and I was wondering a while back why my (even release builds) executables were big.

The language to compile it in doesn't seem to matter since the sizes were exactly the same.

Debug - 106.496
Release - 36.864

When I disassembled a program someone else wrote and compiled (in release mode) with MS Visual C++ 6 I could clearly see what happened in the program and where it ended, without any other stuff really.

When I disassemble my own hello world executable (release build) I see a lot other stuff next to what I really wrote, like exception strings as "\r\nThis application has requested the Runtime to terminate it in an unusual way.\nPlease contact the application's support team for more information.\r\n" and a MessageBox.

I understand why there are exceptions for the runtime in it, but are these really necessary?
How did he turn them off, os it just that his verion is too old that runtime exception warnings weren't implemented?
All these exception warnings seems to increase the size of executables.
Is my personal edition forcing me to have 'larger-than-normal' executables?
If so, I'm sure he used some warez'd professional edition (if that exists for VC++ 6).

Heh, I have no idea how to decrease the size, someone tell me.

Or, shouldn't I be worried at all?

Oh yeah, what's up with VC++ putting paths to the .pdf file of the project in the exe?

2dragons - Mon May 23, 2005 10:32 pm
Post subject:

Tact check.

Cyan~Fire - Tue May 24, 2005 1:25 pm
Post subject:

VC++6 is what I use, and it's good. So I don't know all that much about later version, sorry.

Anonymous - Fri Jun 10, 2005 9:02 am
Post subject:

If the complaints on optimization are over, then Id like to refer to an "alternate design option." Whilst jealousy exudes from every pore that you beat me to the finish on this particular module, I cann still trip you up on some inane feature. Go check out the prize plugin I wrote for mervbot, I believe version 3. That one is SQL and Im sure can easily be changed to fit into a module and utilize the already existing ASSS MySQL tables. It works well and (ultimately as your database grows) will be faster than any text file reading you do on your own.

Its probably available at sscentral.com/bots

Anonymous - Fri Jun 10, 2005 9:19 am
Post subject:

And prize3 is months out of date, I fixed some ugly code and the expiration works properly. All dates are stored as per the time on the mysql server, meaning localization is not needed. Ill update it when I get home on the 21st.

50% Packetloss - Fri Jun 10, 2005 2:28 pm
Post subject:

lol, at max, a zone would nearly never need more than 100 prizes in the database. In the zone I play in, I don't think I've ever seen more than 20-30 prizes in the bot. Even in large zones, the events have a lot more people but only 1-5 events are run at a time and thus not very many people are prized, assuming that there are 1-3 winners from each event. So in my opinion, mysql is overkill.

But there is no doubt in my mind that you could write a better module. There is plenty I left out and I'm sure there are ideas I didn't think of that belong in the bot. But I think you are a far more capable programmer than myself, so maybe your expertise are better suited on larger module ideas.

Come to think of it, I should probably make the mod-commands in the above module global to ALLARENAS, I'll update it later.