@DJ, this is not intended to be compatible with link play, as it requires the server as a man-in-the-middle. Perhaps I will integrate link play support into a later version, but not in 1.0. As for timeouts and disconnects, it will be at the discretion of the server how long to wait before a unit is classified as "timed-out". Conversely, it will be at the discretion of the unit itself how long to wait before we as classified as having lost our connection. If this happens, there will be an emergency throw of data into a temporary appvar. DJ, how up to data are you with the latest specs of the project, out of curiosity?

Sprites Request

Players will have the option of being aligned to 5 classes: Federation, Klingon, Vulcan, Romulan, and Dominion.

Anyone willing to contribute sprites for ships for those classes would be credited and appreciated.
I will be using a universal sprite for each class, to save memory. At least for now. This may change in a later version. Sprites may be 8x8 or 12x12 or 12x8. I will respect the judgement of others on the ideal size for these sprites.

Also, @Sorunome. How difficult would it be to implement the following... a calculator connected to the server. If a new update of this game (client side) is available, we create a temporary downloading program, quit the game, overwrite the local game copy with the update, and then switch back to the game. Like an automatic update... ?

Yes, I'm planning to adjust data refresh rate based on CPU speed. How can I detect it? What code?

Ok. What I'm gonna do, is set default refresh rate to 1 second, but give the user a slider bar, to adjust up or down. Adjusting the refresh rate up gets data from the server more often. adjusting it down gets it less often.

My initial thought was for max refresh rate to be every .1 second and minimum to be 1 second. But I'm thinking to make max .25 seconds and max like 2 seconds or maybe 1.5.

on the server side, you can create variables to keep track of incoming requests for data, and responses to those requests sent. maybe then create a net figure. If we are trending toward a backlog (more incomings than outgoings), the server sends out a broadcast "drop refresh rate" message, that all non-Basic 83+'s will comply with.

Well me me ask you a question... Im gonna implement a cap. 30 players to a world. Assuming the world is maxed out (30 players online), each requesting data, how well could the server keep up? How often could we request data without getting backlogged?

ok. now correct me if im wrong, but the hash cannot be reversed. As in, you can hash something, but you cannot unhash it, at least not without extensive computational power.

But dont we need all data to be sent anyway?