Server Help

[Cyan~Fire]

I fully don't expect anybody to know this, but does SubSpace use a short or int for the bounty * Flag:FlaggerKillMultiplier on a player death? Just curious, because MERV's using a short right now, which could roll over. Just wondering if I should fix it.
_________________
This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him.

[Smong]

The setting uses a short, but since register size is typically 32bits I think it's going to get extended when used in math (in ss).

[Cyan~Fire]

Well, it'll get extended, but is it still stored as a short? You wouldn't think so, but hey, these are the guys that stored score as a signed value.

[Mine GO BOOM]

[Cyan~Fire]

OK, the way it was happening was something like

Code: Show/Hide short bounty = pkt.bounty; if (killer->flags > 0)    bounty *= settings.FlaggerKillMultiplier + 1;   //possible loss

but I've changed it to use an int now.

And that makes sense about the negatives, but I'd think it would just be better to have the score unsigned and the bounty signed, then "negative bounty hunters" would just have a score of 0. Haha.

[Maverick]

Woo! You are "fixing" Mervbot, Cyan?
_________________

Nickname: Maverick (I changed my name!)
TWCore developer | Subspace statistics

[Cyan~Fire]

In a way. I'm doing it at just the wrong time though. First I though MERV was cool, then I realized it sucked (compared to how cool it could be), then I figured it's useless with asss, then I figured it might still be useful, then I decided that since I started I mightn't as well finish.

What I'm wondering about, though is plugin changes. I would have to make sure old plugins would work, but I'm thinking of adding a whole new callback type interface instead of this messaging thing. Basically what it would do is search for a specific function name (like "handlePlayerMove") in the plugin, and call it if it finds it. That way, it completely automatically calls only the functions you need. Kinda cool, right?

[Maverick]

Sounds cool.
But make sure its backward-compatible as you already said or alot of coders are going to be mad at you (including me) .

What's so sucky about Mervbot btw? (specific points if you can name them)
Only thing I can mention is the lacking feature of registering commands (so you can't ever catch all the commands that the plugin isn't handling). (Aka.. like TWCore does)

[Cyan~Fire]

Command registration is definitely an issue. Ekted's timer feature is also a bonus.

But a lot of the improvements are behind the scenes. Plugin interaction is exactly the same now, but the core code is completely whacked out.

Parital list of changes:

• Conversion from iostream classes to FILE io.
  
• Formed class SSConnection, which does a pretty good job of black-boxing the core protocol.
  
• A lot of items use static buffers instead of dynamically allocated.
  
• Packets are handled as structures and not as byte strings (much, much cleaner).
  
• Removed class UDPSocket, as it didn't provide enough Winsock features. (I mean, a wrapper for a library? Ugh.)
  
• The map now treated as a class and not a pure byte structure.
  
• Packet handlers use a pure array and not a template class.
  
• Formatted sendPrivate(), sendPublic(), etc. messaging, eliminates need to use String class for chatting.
  
• Using more library functions instead of catid ones: isprint() instead of isPrintable() among others, zlib's crc32() instead of getFileChecksum(), and an intrinsic strlen() instead of STRLEN().
  
• In the middle of getting rid of struct clientMessage, which dynamically allocates the size needed for the packet, and instead using a packet structure on the stack.

That's all the major ones I can think of right now.

[Cyan~Fire]

Code: Show/Hide sub   esp, 3064

LOL. Yes, I am definitely going to implement command-registering with handler functions.