Suggestion For Client Programmers

[LabRat]

While talking to Wytter yesterday, I asked if the server would accept version numbers higher than the current CVS version, and he replied in the affirmative.

 

My suggestion (after discussion at length with the_antiroot) is to make a thread on the forums, with everyone involved in making custom clients and bots to have a set range for their personal use, so the senior mods can determine the percentage of custom clients and bots in use at a glance.

 

I suggest that custom clients have the range 64.00 through 127.255 (0x4000 - 0x7fff). I choose this range arbitrarily, but a simple bit search (high version & 0x40) would show up the custom versions.

 

There are not that many custom clients at the moment, but bots - well that is a whole new ball game, and I suggest using bit 7 for those (128.00-255.255, 0x80FF - 0xFFFF), and a very simple patch to the server colour code could instantly identify a bot, and change its name colour. Existing bot code could be patched in a couple of seconds to cope with this, and as long as people keep to their set ranges - or request more if necessary - this could be a productive and easily trackable client and bot control system.

 

I would therefore like to declare my intention to use the range 64.00 through 64.255 inclusive (0x4000 through 0x41ff). I know 512 seems excessive, but the amount of builds I make is phenomenal - Last check I was on build 80+, and with my version control I will soon run out of numbers in 8 bits, so I have chose 9 bits to give that extra flexibility.

 

If you are a client or bot programmer, please show your support by declaring a range you intend to use in this thread, 42.00-127.255 for clients, 128.00-255.255 for bots.

[Learner]

While talking to Wytter yesterday, I asked if the server would accept version numbers higher than the current CVS version, and he replied in the affirmative.

 

My suggestion (after discussion at length with the_antiroot) is to make a thread on the forums, with everyone involved in making custom clients and bots to have a set range for their personal use, so the senior mods can determine the percentage of custom clients and bots in use at a glance.

 

I suggest that custom clients have the range 64.00 through 127.255 (0x4000 - 0x7fff).  I choose this range arbitrarily, but a simple bit search (high version & 0x40) would show up the custom versions.

 

There are not that many custom clients at the moment, but bots - well that is a whole new ball game, and I suggest using bit 7 for those (128.00-255.255, 0x80FF - 0xFFFF), and a very simple patch to the server colour code could instantly identify a bot, and change its name colour.  Existing bot code could be patched in a couple of seconds to cope with this, and as long as people keep to their set ranges - or request more if necessary - this could be a productive and easily trackable client and bot control system.

 

I would therefore like to declare my intention to use the range 64.00 through 64.255 inclusive (0x4000 through 0x41ff).  I know 512 seems excessive, but the amount of builds I make is phenomenal - Last check I was on build 80+, and with my version control I will soon run out of numbers in 8 bits, so I have chose 9 bits to give that extra flexibility.

 

If you are a client or bot programmer, please show your support by declaring a range you intend to use in this thread, 42.00-127.255 for clients, 128.00-255.255 for bots.

162422[/snapback]

 

Several problems I see:

 

1. When the server gets upgraded to require a new version because of critical changes, the bots & custom clients will not obey that and probably start crashing or doing strange things.

 

2. The version number is 4 bytes, so the range you've actually asked for a lot more then 64k.

 

3.. The version number from the Client can't be trusted for how to change things in the game. Yes, it could be used for some things, but we already know that people are producing Clients with known illegal things int them. Do you actually expect them to announce they are running a custom version?

[crusadingknight]

And since they're going to add a bot flag in the next update anyway...

[LabRat]

In reverse order, as it seems the more important item is last:

 

3.. The version number from the Client can't be trusted for how to change things in the game. Yes, it could be used for some things, but we already know that people are producing Clients with known illegal things int them. Do you actually expect them to announce they are running a custom version?

 

Pretty much all the custom clients use some form of colour code in them in #GM - it would not be at all difficult to test for one of those..

 

If the line about 'known illegal things' was a backhanded remark at me, I have an entirely separate thread explaining that - please reply there as this thread has nothing to do with that.

 

I would not have suggested the thread if I was not willing to declare the clients as custom clients, in fact this was the entire purpose of the thread.

 

2. The version number is 4 bytes, so the range you've actually asked for a lot more then 64k.

 

Heh I really have to get my head around the fact that C uses 32 bits for an integer, and 64 bits for a long integer, as opposed to BASIC's 16 bit int and 32 bit long int

 

1. When the server gets upgraded to require a new version because of critical changes, the bots & custom clients will not obey that and probably start crashing or doing strange things.

 

In which case it is down to the programmer to have kept track with the CVS code, as I do every time I release a new version.. indeed some of my client code actually forces a server update (a case in point is the drop all button - I wrote a version that works at the moment and is code ready for being a server driven implementation in the future, which is now part of the official client CVS, instead of being an illegal patch as it was before I rewrote it).

 

//rethink slightly - still send the current 2nd and 4th bytes as 0x0a 0x0a, but send the other 2 bytes as specified above, as in db 0x40 0x0a 0x01 0x0a - problem solved with no major code change, and it will UPGRADE_TOO_OLD just the same as a normal client if the server changes the required version.

 

This thread is to offer an easy way to track custom clients and bots, you know who makes them and I know who makes them, so it is not like I am asking anyone to do something they have not previously declared, and if there is a problem with a specific version of a client it will take but a moment to code the server with "don't let this version of the client connect" and restart the server code.. it takes only a moment for a major server upgrade, so a minor one like this would be child's play, and prevent people from connecting with illegal clients (a simple test - if the client does not send a version number>10.10 and sends a coloured string in GM declare it illegal until it is modified.

 

If you guys have a problem with coding any of the above, tell me the language you use and I will knock something together for you to implement server side, but if Radu (All Hail) can knock a game engine together in it, and give you guys the keys, you must be able to string a couple of if(...) statements together or you wouldn't have server code access.

[crusadingknight]

The colour code in #gm is rejected afaik... if you add the check for that, you'd might as well just boot people for using it. ... I'm suddenly very sorry I made that patch, if people won't accept it's status.

 

And I don't think learner was accusing you, but this just gives us a way to track benevolent clients - the one's we really need to have concerns about are the macro'ing ones, which are programmed to hide the differences in every way, shape, and form. Sending version would really only allow us the advantage of checking statistics using grep on some logs (if we even log it?)...

Edited May 15, 2005 by crusadingknight

[Learner]

I wasn't accussing you, I was actually think of other clients that were specifically written to macro and automate things like healing, combat, manu, etc.

 

Probably what is needed is a better way to track and monitor some of this information on the Server then is currently in place. For instance, there are really TWO different version numbers that are sent. The first that is used for knowing the protocol/data version and if your version is too old, is two shorts, the second is formatted as 4 unsigned bytes and is intended for doing things like tracking the patch level, etc and holds the dev-cpp version number data by default. This second version number could be used carefully for stats & logging if a specific client is having problems and is displayed in the client with the #ver command. Currently then protocol/data version is kept in sync with the full client version. The client devs should be advancing the the last byte more often in CVS, but that is often overlooked.

 

The client version could be used to track your specific client/bot version, but because of the cheat concerns, the server shouldn't assume that is usable data for anything like flaging a bot or not. I'd actually have to look at the server code to see if the client version is being logged or not.

[Entropy]

I don't really see any use for it.

Those with illegal clients will not use that feature anyway, and those with legal clients, it doesn't really matter.

[waldi]

its not required to use the 'SEND_VERSION' request, so bots could be identified by just not using it...isnt this simple enough ??

[trollson]

Heh I really have to get my head around the fact that C uses 32 bits for an integer, and 64 bits for a long integer, as opposed to BASIC's 16 bit int and 32 bit long int

162452[/snapback]

 

Not quite that simple :-) (puts on language lawyer hat...)

 

The C standard (and inherited by C++) defines the following integer types (refering to data type sizes):

• char: == 8 bits.
  
• short: >= 16 bits, >= char.
  
• int: >= 16 bits, >= short.
  
• long: >=32 bits, >= int.
  
• long long: >= 64 bits, >= long.
  
• unsigned type: == type.
  

The minimum sizes are defined in the requirements for <limits.h>, and the relative sizes by the type conversion requirements (an int must fit within a long).

 

On most 32-bit architectures, int and long are 32 bits, long long may be 64 bits.

 

If writing for portability though, you cannot assume that a type has a particular size (except for char). This is particulary significant since the 64 bit platforms are increasing in number. ...and then there are the endian issues...

 

 

(Currently dealing with cross platform software...)