Server Help

[Cheese]

colors module has undergone a final redesign, and will most likely not be altered in the future.

if the file timestamp on your files is older than this post's timestamp, your version is outdated. grab a new copy.

there is really no reason why any zone should not have this module, all the cool kids have it...

:)
_________________
SSC Distension Owner
SSCU Trench Wars Developer

[Cheese]

fixed bug in new logic that sent arena messages to zone.
files updated.

[Cheese]

updated interface.
should be slightly faster, and now you arent forced to use the color constants, even if theres no real reason not to :P
files updated.

[Samapico]

What's going here? Your if/else statements do not work as the indenting would lead you to believe...

Code: Show/Hide          if(mode == MODE_ZONE) LLAdd(&playerlist,pp);          else          {             if(mode == MODE_ARENA) if(pp->arena == a) LLAdd(&playerlist,pp);             else             {                if(mode == MODE_FREQ) if(pp->arena == a) if(pp->pkt.freq == freq) LLAdd(&playerlist,pp);                else return; //wtf?             }          }

Correct indenting:

Code: Show/Hide          if(mode == MODE_ZONE)             LLAdd(&playerlist,pp);          else          {             if(mode == MODE_ARENA)                if(pp->arena == a)                   LLAdd(&playerlist,pp);                else                {                   if(mode == MODE_FREQ)                      if(pp->arena == a)                         if(pp->pkt.freq == freq)                            LLAdd(&playerlist,pp);                         else return; //wtf?                }          }

I don't know if that's how you intended it to work, but your indenting makes me believe otherwise...
Having 3 if's on the same line generally is a bad idea
_________________
(Insert a bunch of dead links here)

[Cheese]

i think it was because i was testing something or other, and forgot to fix it...
in any case, its fixed.
files updated.

[Samapico]

Another small thing I noticed... your module logs messages using the ERROR tag when it loads and unloads correctly, you might want to change that to Information

[Cheese]

all my modules do

INFO level messages are by default not sent to chat
when the zone crashes because someone attached a module to a different arena, id want to know

[Samapico]

Suggestion: Would be nice to be able to use printf style format with the ColorA, ColorP, etc. functions

[Samapico]

I modified the code so the interface handles printf style formatting.

I also added interface functions to send colored messages with sounds


Note that I stripped off the code of the Voice module in there, because I was lacking some constants, presumably in the xchat module, and I didn't want to bother with that... So do what you want with it

There are a few minor changes here and there I did while skimming through your code, mostly in code formatting (i.e. a switch (params[0]) instead of if...else if... chain).

[Dr Brain]

In matters of style, an if-else chain is generally preferred over switch statements. See the Java style for an example. The if statements are more flexible, and therefore easier to expand in the future, and of course the basic form generates the same machine code.
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me

[Samapico]

Well it depends what is subject to change... if the input is subject to change, your if else if chain will be less flexible, since you'll need to change it all... But if the conditions might get changed or combined, then yeah.
Also if your condition is a function or some calculation, the switch avoids the need of a local variable to store the result before comparing it, which is practical.

IMHO

</offtopic>

[Cheese]

[Samapico]

I personally find it less readable when the statement is on the same line as the conditon... you have to visually scroll to the end of the condition (i.e. the closing parenthesis) and then find the statement...

Anyway.... if you didn't notice, I did the printf format style functions, so you don't need to, in the post just after the one you quoted

Also, I know you can send the % sounds when you type a colored messages, but I'm mainly using the color module's interface from other modules and I doubt adding a %# in the message string would make a sound... the % thing is client-side.

[Cheese]

when youre getting up to 10,000 lines of code, adding extra space for no reason makes you wait a really long time while scrolling to the part youre looking for.



yes, all sounds are client side, and yes, you did copy+paste from chat.c just like i will.

:)

[L.C.]

[Cheese]

i find them to be equally readable at best, but one is a waste of space

[Cheese]

[BaK (mgb wont reset pw)]

[Dr Brain]

How would you generate a jump table without comparisons, exactly? A fully populated table for ints would be 4GB (assuming the relative jump could be packed into 1 byte, of course). A sparse table would require comparisons and would start to look very much like that if-else tree.

Jump tables are great for strictly defined things like interrupt handling vectors, and custom code where you can write assembly to get the very last nanosecond out.

[BaK (mgb wont reset pw)]

if you're dense near 0, you check the maximum range once and then after that assume the index is in bounds.

I think the compiler did it when I was learning asm and it took me a minute to figure out what was going on.

[Guest]

[Dr Brain]

You're right, you can do it with one comparison if you have fully dense cases. I've never seen it done, but again, I don't work with switch statements for the style reasons stated above.

I'd like to note that I don't think CPU branch predictors are well suited to that sort of jump table (relative jump with offset held in a register instead of an immediate). Branch predictors may have improved since I last studied them, but as I don't see how this kind of dependence could be resolved while still in the pipeline. So you'll get a pipeline flush every time you do the jump, which in deeply pipelined processors can hurt performance instead of helping it (modern x86_64 are deeply pipelined). The exact penalty depends on the probability distribution of the cases and the pipeline flush penalty, but except for truly massive switch statements or processors with shallow pipelines it won't reach break-even.

But, that said, any compiler smart enough to optimize a switch statement (if indeed there is an improvement from a jump table, which I tend to doubt) is probably smart enough to check if the if-else tree can follow the same optimization. It's a simple enough comparison of the AST to see if every branch of the if-else does an integer comparison against the same variable.

Perhaps the jump table is the -O0 behavior? That would make sense, since the argument could be made that it would more closely resemble the C code. Or perhaps it's -Os, if there's a code size savings (e.g. the relative offset could fit in a byte, but the branch opcodes are one word wide).

Most of the code I write isn't x86, so I may be unaware of new developments in the processor architecture. The last x86 I studied was the Pentium 4. Most of my code is C, written for the AVR and AVR32 architectures, compiled using gcc.

[BaK (mgb wont reset pw)]

it doesn't need to be fully dense, as some gaps can be filled in with the same address (jump to the default handler, or after the switch statement).

Even in the case of a very sparse switch statement, it can be implemented using a binary search which will be faster than a sequential checking using if statements alone.

[Dr Brain]

The pipeline flush from the jump table is still going to drive the performance cost on any x86 and x86_64.

And you don't think an optimizing compiler can rewrite them both into the same exact machine code? That was my original point: they'll generate the same exact binary. Therefore one should use whichever is easier to read, which for my money is the if else-if.

[Cheese]

ive always wanted an elseif switch

Code: Show/Hide elseifswitch(num) { case > 3: break; case > 2: break; case > 1: break; }