When spring temporarily looses conenction with the host for a second or so the game dirfts. SFX get larger or smaller and dotn stop, untis carry on on their trajectories floating not animating, explosions keep getting bgiger and bigger and bigger, etc..
Instead the game should stop all motion and resume once the connection resumes, rather than showing ugly drifting effects for seconds or half a second at a time, its unproffesional.
Ideally when this happens the units would stay still and a little icon or small animation would be drawn in the corner using a lua widget.
Unit drift
Moderator: Moderators
-
TechnoTone
- Posts: 165
- Joined: 23 Aug 2005, 22:02
I disagree. Units should continue with their current orders. The client knows their orders too so it should be able to make the same decisions as the host about how the unit should be moving. When the connection is reestablished there is hopefully a minimal amount of adjustment to perform.
Effects such as nanospray, explosions, smoke, should do their normal behavior too and not just continue growing/moving indefinitely. The client should know when to stop the effect anyway so why does it need the host to tell it? This should also apply to weapons.
Effects such as nanospray, explosions, smoke, should do their normal behavior too and not just continue growing/moving indefinitely. The client should know when to stop the effect anyway so why does it need the host to tell it? This should also apply to weapons.
no no no no no
you totally misundrstood me.
If I take my itnernet cable and yank it out 2 thigns happen.
1) All my units start drifting, all the animations stop, untis will float through eachother and it all looks very strange
2) After 10-20 seconds of this spring closes without warnign havign detected time out.
So no, units should not continue there orders because theyre incapable of doing their orders, because the game is not in progress, its in limbo, gametime is not progressing.
When playing a game sometimes this will happen for a moment and you'll see everything drift for a second or two then it syncs back and the game speeds up for a second or two playing catch up then things continue as normal.
If you still don't understand what I mean, play a game and at the very end have all your units move in random directions. When the server/host exits all your units start drifting.
EDIT::
For further clarification
you totally misundrstood me.
If I take my itnernet cable and yank it out 2 thigns happen.
1) All my units start drifting, all the animations stop, untis will float through eachother and it all looks very strange
2) After 10-20 seconds of this spring closes without warnign havign detected time out.
So no, units should not continue there orders because theyre incapable of doing their orders, because the game is not in progress, its in limbo, gametime is not progressing.
When playing a game sometimes this will happen for a moment and you'll see everything drift for a second or two then it syncs back and the game speeds up for a second or two playing catch up then things continue as normal.
If you still don't understand what I mean, play a game and at the very end have all your units move in random directions. When the server/host exits all your units start drifting.
EDIT::
For further clarification
This is utterly impossible. The drift issue only occurs when there is no connection to the host or the connection is temporarily cut/lags. When the network connection is interrupted the game is paused and the units start to drift around like I said, and when the connection is regained the units stop drifting and return to their normal positions and carry on as they should do.Effects such as nanospray, explosions, smoke, should do their normal behavior too and not just continue growing/moving indefinitely. The client should know when to stop the effect anyway so why does it need the host to tell it? This should also apply to weapons.
-
TechnoTone
- Posts: 165
- Joined: 23 Aug 2005, 22:02
-
TechnoTone
- Posts: 165
- Joined: 23 Aug 2005, 22:02
-
TechnoTone
- Posts: 165
- Joined: 23 Aug 2005, 22:02
Well if the hosts game continues that means the client has to then catch up with everything it has missed while it was absent from the game. Therefore, my original assumption was correct and my point still stands - it would be better for the client to try to continue with the information it knows at the time the connection was suspended in the hope that when the connection resumes its game state is as close as possible to the hosts.
But thats somewhat pointless as all that effort is going to be undone anyway.
What's more its a lot of effort to code with no benefit at all and it hides a potential conenction problem from the user.
On top of that it introduces a desync issue with users perception. A temporary time out could last 5-6 seconds during which the game could change a lot. The unit that moved a few screens in a transport that your currently tracking might have been killed by an order the host issued in the moment you lost contact temporarily.
Its horrendous user design, and it conceals valuable information from the user and is a lot to do.
What's more its a lot of effort to code with no benefit at all and it hides a potential conenction problem from the user.
On top of that it introduces a desync issue with users perception. A temporary time out could last 5-6 seconds during which the game could change a lot. The unit that moved a few screens in a transport that your currently tracking might have been killed by an order the host issued in the moment you lost contact temporarily.
Its horrendous user design, and it conceals valuable information from the user and is a lot to do.
-
TechnoTone
- Posts: 165
- Joined: 23 Aug 2005, 22:02
I rarely see it last more than a few hundred milliseconds so I don't see it being that big a deal personally. If, however, everything momentarily froze every time it happened I think it would be very distracting.
You say it's a lot of effort - why? It's not something new that the engine doesn't know how to do? Currently, certain things are being suspended while others aren't. I don't know the code but I don't see why it should be this way.
Yes, discrepancies will occur due to changes in orders but for the most part the game will continue in the same way on both the client and the host.
The only time things really become problematic is when the connection is lost for many seconds but if that happens then the client player really has lost control and doesn't know what is happening in the game. At least a "simulated" view of the game will provide some insight as to what is most likely to be occurring and they are able to consider those events instead of just stare at a static screen with no idea at all of what is happening.
Consider that you've just sent a scout over the enemy when your connection freezes. You now don't know what it is seeing while it is flying over the enemies base until your connection resumes and all you have to show for it are ghosts of buildings. You have no idea of any amassed units that may be in the area or of how much airborne air defense there is, etc.
Consider that your connection has frozen and while your game is "paused" you have a group of enemy units attempt to overrun part of your defenses. You don't know about this, however, until the game resumes so you aren't prepared for it and ready to send in the reinforcements that you have in standby for just such an event.
Personally, I would like to know what is happening in the game, even if it's not 100% accurate, rather than nothing at all.
You say it's a lot of effort - why? It's not something new that the engine doesn't know how to do? Currently, certain things are being suspended while others aren't. I don't know the code but I don't see why it should be this way.
Yes, discrepancies will occur due to changes in orders but for the most part the game will continue in the same way on both the client and the host.
The only time things really become problematic is when the connection is lost for many seconds but if that happens then the client player really has lost control and doesn't know what is happening in the game. At least a "simulated" view of the game will provide some insight as to what is most likely to be occurring and they are able to consider those events instead of just stare at a static screen with no idea at all of what is happening.
Consider that you've just sent a scout over the enemy when your connection freezes. You now don't know what it is seeing while it is flying over the enemies base until your connection resumes and all you have to show for it are ghosts of buildings. You have no idea of any amassed units that may be in the area or of how much airborne air defense there is, etc.
Consider that your connection has frozen and while your game is "paused" you have a group of enemy units attempt to overrun part of your defenses. You don't know about this, however, until the game resumes so you aren't prepared for it and ready to send in the reinforcements that you have in standby for just such an event.
Personally, I would like to know what is happening in the game, even if it's not 100% accurate, rather than nothing at all.
-
Auswaschbar
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Its because the client only executes a step of the simulation after it gets a special message from the server to ensure there are no orders given. Running a step without these will cause desyncs when there are orders the client doesn't know about.You say it's a lot of effort - why? It's not something new that the engine doesn't know how to do? Currently, certain things are being suspended while others aren't. I don't know the code but I don't see why it should be this way.
Every small difference may cause a desync...Yes, discrepancies will occur due to changes in orders but for the most part the game will continue in the same way on both the client and the host.
a momentary pause would eb best. Seeing units predict their commands momentarily then snap back for a few hundred milliseconds will look the same as the drifting but slightly better. The drift issue would still remain for when the server exits.
Also, what if your scout flew over an enemy abse in the time out revealing the enemy base but when it synced back the enemy blew up the scout before it could see anything? Its exploitable.
What's more you have to save the current game state so that when connections resumed its reloaded and it continues otherwise you're going to get a hard desync and have to restart the game.
The effort of saving then restoring changes could in itself cause momentary time outs leading to a recursive loop leading to a full blown time out.
Whereas you could simply pause the game and keep the current behaviour and display a friendly message so that the user knows exactly what's going on, why its happened, and the whole thing is nice and clean cut. Its far quicker to implement and much faster to run.
Also, what if your scout flew over an enemy abse in the time out revealing the enemy base but when it synced back the enemy blew up the scout before it could see anything? Its exploitable.
What's more you have to save the current game state so that when connections resumed its reloaded and it continues otherwise you're going to get a hard desync and have to restart the game.
The effort of saving then restoring changes could in itself cause momentary time outs leading to a recursive loop leading to a full blown time out.
Whereas you could simply pause the game and keep the current behaviour and display a friendly message so that the user knows exactly what's going on, why its happened, and the whole thing is nice and clean cut. Its far quicker to implement and much faster to run.
-
TechnoTone
- Posts: 165
- Joined: 23 Aug 2005, 22:02
Fair comment. That's not good.AF wrote:Also, what if your scout flew over an enemy abse in the time out revealing the enemy base but when it synced back the enemy blew up the scout before it could see anything? Its exploitable.
Yes - that would be a lot of effort.AF wrote:...you have to save the current game state...
Ok, I'm convinced. Where do I sign.AF wrote:Whereas you could simply pause the game and keep the current behaviour and display a friendly message so that the user knows exactly what's going on, why its happened, and the whole thing is nice and clean cut. Its far quicker to implement and much faster to run.
-
Auswaschbar
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Iirc there already is one: Spring.GetFrameTimeOffset()
-
Auswaschbar
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
-
Mr.Frumious
- Posts: 139
- Joined: 06 Jul 2006, 17:47
Personally, I don't care about the drift effect. What I want is an icon showing me that it's communication with the server that's the problem. Something like the little "cable unplugged" symbol from the Quake games.
Still, the drift effect is annoying, since usually during a freeze you stop and look around and plan what's to happen at resume (particularly since resume often includes a little fast-forwarding). Having stuff glide all over the place makes that pretty rough.
Still, the drift effect is annoying, since usually during a freeze you stop and look around and plan what's to happen at resume (particularly since resume often includes a little fast-forwarding). Having stuff glide all over the place makes that pretty rough.
-
Auswaschbar
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
I have implemented as a CallOut function named GetHasLag() with bool as return type because:
1. It needs only one function (HasLag) instead of two (OnLag and LagEnd)
2. The state (lag or not lag) has to be polled each Draw(), so there should be no speed difference
3. Widgets dont need to store the lag status local, instead they can just use the func
Unfortunately I dont know enough LUA to write a test script.
When someone found a bug, please post it here.
1. It needs only one function (HasLag) instead of two (OnLag and LagEnd)
2. The state (lag or not lag) has to be polled each Draw(), so there should be no speed difference
3. Widgets dont need to store the lag status local, instead they can just use the func
Unfortunately I dont know enough LUA to write a test script.
When someone found a bug, please post it here.