| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000162 | Spring engine | General | public | 2006-04-24 05:10 | 2006-04-25 22:01 | ||||
| Reporter | monohouse | ||||||||
| Assigned To | tvo | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | closed | Resolution | won't fix | ||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0000162: actions depend on server lag | ||||||||
| Description | whenever a command is given to a unit or to a factory to build or queue some units with shift, the command is then being sent to the server and only when the command was received by the server and returned to the sender as confirmation the command is being performed on the client, this produces something you can call "command lag" in addition to which units also slow down when given orders. instead when a command is given to the units they should perform it immedialty instead of waiting until the server confirms it, otherwise that is a double-lag, one time to wait until the server accepts the new command, and then again to wait until the server receives the new unit position after it was moved. the operations should be performed in paralell, a unit is given the order and is doing it (no building queue lag/unit ack lag), in the same time the command is sent to the server. it's not fun to wait for the server to allow you to queue units, or to wait 2xyour latency (in an optimal case when outgoing latency=incoming latency) until a unit starting to fire at the enemy or move to a location. | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
tvo (reporter) 2006-04-25 22:01 |
This is impossible to change: it's part of the synced simulation network model. If your client would execute a command sooner then another client, you would be out of sync immediately. I agree tho that the perceived lag could be better, but that's something for the new GUI (ie. it could already show orders as being queued even tho the queue order was not yet "confirmed" by the server). |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-04-24 05:10 | monohouse | New Issue | |
| 2006-04-25 21:59 | tvo | Status | new => assigned |
| 2006-04-25 21:59 | tvo | Assigned To | => tvo |
| 2006-04-25 22:01 | tvo | Status | assigned => closed |
| 2006-04-25 22:01 | tvo | Note Added: 0000172 | |
| 2006-04-25 22:01 | tvo | Resolution | open => won't fix |
| Issue History |