Thats because you could originally get negative scores. Ever wonder why people with low bounties are neg killers? You used to start with negative bounty. So some people would have an average kill of -10, which were refered to as negative bounty hunters. Later on, after they realised that people would still kill small bountied players, they had them start at 0 again, to remove the goal of getting the smallest score. The neg killer term still stuck.
The way most C compilers work, if you do a short * short -> int, it will extend it as if it was int * int. Tested on GCC and MSVC 6.0
Code: Show/Hide int main()
{ short a, b; int c; a = 30000; b = 100; c = a * b; printf("%d * %d -> %d [%d]\n", a, b, c, a * b); } |
Code: Show/Hide 30000 * 100 -> 3000000 [3000000] |
Cyan~Fire - Sun Sep 11, 2005 2:57 pm
Post subject:
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 - Mon Sep 12, 2005 6:18 am
Post subject:
Woo! You are "fixing" Mervbot, Cyan?
Cyan~Fire - Mon Sep 12, 2005 9:03 pm
Post subject:
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 - Tue Sep 13, 2005 2:48 am
Post subject:
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 - Tue Sep 13, 2005 9:21 pm
Post subject:
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 - Fri Sep 16, 2005 6:51 pm
Post subject:
Code: Show/Hide sub esp, 3064 |
LOL. Yes, I am definitely going to implement command-registering with handler functions.