Spring RTS Engine

I am interested in documentation for communicating with a TS Server. I have looked through source code and have found how to log in, but my eyes hurt! I refuse to look at code for my answers anymore. I would be more tolerant, but I know they probably got it from some documentation. Does anyone know where it is?

I wonder what I am doing

http://spring.clan-sy.com:8202/lobby/pr ... iption.xml

join #bots in the lobby for help and discussion and such.

e: wait...TS or TAS?

TA* Thank you. This helps soo much. :]

The protocol itself really sucks and should be redone. Is there an on-going project for this already, or should one be started?

What comes to the new protocol:
- A binary format (big endian) should be considered, even though text format will probably be used anyway.
- All commands should be tokenizable. This is not the case with the current protocol, as tokens may be separated by spaces or tabs and only the lexer knows which (the parser does not know about the commands).
- No escaping whatsoever. Just don't do it.
- Colors should be passed either as 6-digit hex numbers (as in HTML), as three separate floating point values (0.0-1.0 for R, G and B, as in OpenGL) or in binary (uint32 ARGB).
- Changing the player limit and other settings should be possible without rehosting a battle.
- Clients should not be required to generate unique identifiers (other than nicks). The server can do this and guarantee that the IDs really are unique.
- All commands should be asynchronous and have IDs assigned to them and the corresponding replies (similar to IMAP).
- The commands should be categorized (reducing the number of "global" commands).

EDIT: one very important addition: make all strings UTF-8.

Indeed, CE needsa new server and currently I and iamacup have 2 rival server designs. I'm still working on the lobby however.

Tronic wrote:The protocol itself really sucks and should be redone. Is there an on-going project for this already, or should one be started?

What comes to the new protocol:
- A binary format (big endian) should be considered, even though text format will probably be used anyway.
- All commands should be tokenizable. This is not the case with the current protocol, as tokens may be separated by spaces or tabs and only the lexer knows which (the parser does not know about the commands).
- No escaping whatsoever. Just don't do it.
- Colors should be passed either as 6-digit hex numbers (as in HTML), as three separate floating point values (0.0-1.0 for R, G and B, as in OpenGL) or in binary (uint32 ARGB).
- Changing the player limit and other settings should be possible without rehosting a battle.
- Clients should not be required to generate unique identifiers (other than nicks). The server can do this and guarantee that the IDs really are unique.
- All commands should be asynchronous and have IDs assigned to them and the corresponding replies (similar to IMAP).
- The commands should be categorized (reducing the number of "global" commands).

EDIT: one very important addition: make all strings UTF-8.

ive implemented 2 of thoes so far

- Colors should be passed either as 6-digit hex numbers (as in HTML), as three separate floating point values (0.0-1.0 for R, G and B, as in OpenGL) or in binary (uint32 ARGB).

- All commands should be tokenizable. This is not the case with the current protocol, as tokens may be separated by spaces or tabs and only the lexer knows which (the parser does not know about the commands).

i dont see the benefit of a 2nd ID though?

iamacup wrote:
i dont see the benefit of a 2nd ID though?

Taking a shot in the dark, but I'm guessing its a permanent ID linked to your account and usernames that is static, unlike your dynamic username. Again guessing, its for things like friends lists, so even if you change your username you remain on them due to the static ID.

I'm likely talking bullshit

Relative wrote:

iamacup wrote:
i dont see the benefit of a 2nd ID though?

Taking a shot in the dark, but I'm guessing its a permanent ID linked to your account and usernames that is static, unlike your dynamic username. Again guessing, its for things like friends lists, so even if you change your username you remain on them due to the static ID.

I'm likely talking bullshit

Talking shit or not, +1 to this idea. But thats slightly off topic for this thread.

Well there needs to be a standard, and currently it is the main one; thus I will be using it. The only client as far as I know that is still being worked on is the java one, and I dislike java, so I decided to try and write my own in C# and mono. I would use c/c++, but I this not a serious project at the moment and I do not want to risk wasting my time writing a lot. However, it might end up being one. Eh.

I was about to brag about my efforts of making a teamspeak webend till I noticed that this is about the TA lobby protocol. :(

hmmm, a lot of java classes I've seen are 99.9% identical to C# classes that do the same thing.

For example 99% of the porting work of hugh perkins C# tdfparser to java was changing capitalisation in string methods equalsIgnoreCase vs equalsignorecase.

No. I mean I dislike running java application. They tend to be sluggish. Mono might seem the same, but I believe mono runs better than java. It is the lesser of the two evils. And I have already written a few classes that I will use from some other projects. Using C# will save me much more time than using c/c++ or java.

Java isnt sluggish but yes most java apps are horribly slow.

http://java.sun.com/products/jfc/tsc/ar ... eads1.html

Thats the golden rule of java GUI programming that 95% of java apps break. Thats why programs like Limewire are notoriously slow.