Joined: Sun Dec 24, 2000 3:00 am
Re: twgs beta (whatever version it is now)
I actually wrote a long response on this for Kaus, but thanks to Microsoft, it went into the bit bucket. I haven't had time to get back to it.
There are three considerations for timing now, and commands/cycle isn't one of them. That has been phased out. Instead, we have the command "sync delay", an actual delay, and simulated latency. Let me describe these a bit.
1) Every action in the game now has a "sync delay", which is different from a true delay in that the delay is only imposed as a minimum time between any two commands. So if the sync delay is 10 ms, if you attempt to issue the command a second time in less than 10 ms, you're forced to wait until 10 ms have passed before the command is processed. If you issue the command, then wait 10 seconds and issue the command again, no pause is imposed. So sync delays pace the commands, guaranteeing that they cannot be issued beyond a specified rate. The rate has been defined such that no single command, if repeated, will pull more than 5% of CPU. Many sync delays are as small as 2 ms, the minimum, though some are larger.
Sync delays are currently not configurable. I am open to suggestions on which commands are running too fast or two slow. The goal is for everything to run at about the same pace as it ran on v1.03, but for the pace to be locked in so that it no longer continues to get faster with improvements in hardware and network speeds. The speeds will be as-designed rather than whatever a gameop's system happens to provide. A faster machine will provide room for more players rather than faster play for its players.
2) True delays are always imposed no matter how much time has passed between two commands. These are meant to slow down certain actions relative to other players. Ship attacks/moves are one example. There is an editor that allows gameops to configure many other action delays in a variety of ways. The minimum move delay has been 250 ms for many years. I experimented with allowing a much smaller move delay, but it has been unstable. I believe that 250 ms is a good official minimum, because it has been well proven over the years, but I am willing to allow gameops to "overclock" their server to support faster move delays, as long as they know that it can create instability.
3) A major factor on command delays is the emulated latency setting. It defaults to 150 ms. If a single command is issued, there will be a 150 ms delay before that command is processed. If the player has a 50 ms latency, then only 100 ms additional delay is imposed. This tends to level the playing field for players in regard to ping time. Of course, players with > 150 ms ping will still have > 150 ms ping, but the difference in their performance over that of players with < 150 ms ping will be less than it otherwise would have been.
If a burst of commands is sent in a macro or whatever, only the initial command will have this 150 ms latency. The remaining commands in the burst will be processed without delay, just as you would expect with true latency.
In the previous version, the delay for any command was a random amount from 0 to 250 ms. Now it is a very consistent delay as defined by the three kinds of delays listed above. The game has the potential to be many times faster than it was before, but the new delay system is designed to give the game a fast, stable, reasonable pace.
Help fund the TradeWars websites! If you open a hosting account with A2 Hosting, the service EIS uses for all of its sites, EIS will earn credits toward its hosting bill.