Why does TNL/network handle a lagged out client weirdly?
by TerroX · in Torque Game Engine · 09/16/2007 (7:06 am) · 8 replies
I've noticed odd way of handling lag/packet loss, whatever you like to call it - since recently after Tribes2 was released. I had a bad connection to a particular server and using predictable lag spikes I was able to hover over gaps without using energy.
Not very exciting, but this situation still exists in TNL. I didn't really know if I was just being paranoid, but after a lot of lengthy discussions I have written up this document and made a test video and a test script to prove my insanity. It doesn't seem like TNL specifically requires this situation to exist in order to do what it does, it just seems to be the way it's been implemented.
The Cliff Notes,
Clients get "frozen" in time/space within the game whenever the client network transmissions stop. They gain various abilities from this.
I don't want to get into an argument about semantics, the result is still the same no matter how it is described.
There are various exploits and cheezy tactics a player can/could develop once they know this issue - it can be far more annoying than you might be thinking right now.
The question is,
Why is it still like this in HEAD when it could be different? (AFAIK it wouldn't be less efficient and would not look bad AND it might fix seemingly unrelated issues like vehicle warping).
ps: I can't code c++, hence the unconventional writing style.
Not very exciting, but this situation still exists in TNL. I didn't really know if I was just being paranoid, but after a lot of lengthy discussions I have written up this document and made a test video and a test script to prove my insanity. It doesn't seem like TNL specifically requires this situation to exist in order to do what it does, it just seems to be the way it's been implemented.
The Cliff Notes,
Clients get "frozen" in time/space within the game whenever the client network transmissions stop. They gain various abilities from this.
I don't want to get into an argument about semantics, the result is still the same no matter how it is described.
There are various exploits and cheezy tactics a player can/could develop once they know this issue - it can be far more annoying than you might be thinking right now.
The question is,
Why is it still like this in HEAD when it could be different? (AFAIK it wouldn't be less efficient and would not look bad AND it might fix seemingly unrelated issues like vehicle warping).
ps: I can't code c++, hence the unconventional writing style.
#2
Added a demo video to the page using stock TGE 1.5.2 binary to show that it is happening on the latest codebase, to rule out any questioners wondering if our app is the only thing borked.
09/16/2007 (7:19 pm)
Sorry, I may have written it in an aggressive tone, my angst kept slipping in there. I'm not having a go at the original designers, mainly everyone else who could have noticed and done something.Added a demo video to the page using stock TGE 1.5.2 binary to show that it is happening on the latest codebase, to rule out any questioners wondering if our app is the only thing borked.
#3
It's clearly a problem. The trade-off is how smooth the play experience is for people with genuinely bad connections. Why not add some code to start processing ticks with null moves after some short time-out, say, 50 or 100 ms with no new moves from player? That would give more data, so that we (as maintainers) can make an informed decision as to whether the one approach or the other is best.
Have you tried checking to see if the problem repros in Zap? It has a different networked movement model so would be useful to compare against.
09/16/2007 (8:28 pm)
Pat likes to discount other's opinions. ;)It's clearly a problem. The trade-off is how smooth the play experience is for people with genuinely bad connections. Why not add some code to start processing ticks with null moves after some short time-out, say, 50 or 100 ms with no new moves from player? That would give more data, so that we (as maintainers) can make an informed decision as to whether the one approach or the other is best.
Have you tried checking to see if the problem repros in Zap? It has a different networked movement model so would be useful to compare against.
#4
09/17/2007 (10:33 am)
Yes, I would definitely try and reproduce this in Zap. I think an issue like this was fixed in that version of the networking.
#5
- I was able to push a client around when THEY we're lagged
- Whatever the lagged out client were doing last (movement anyway, didn't test shooting) they keep doing while they're lagged (good).
- Sometimes they warped back to different position after a big collision but I think it would be just normal networking predicition mistake on my end due to ping 250+
Looked good.
Is that version of the TNL available somewhere? ;)
09/17/2007 (11:58 pm)
Does not seem to occur in ZAP! Although it is harder to test for without a gravity.- I was able to push a client around when THEY we're lagged
- Whatever the lagged out client were doing last (movement anyway, didn't test shooting) they keep doing while they're lagged (good).
- Sometimes they warped back to different position after a big collision but I think it would be just normal networking predicition mistake on my end due to ping 250+
Looked good.
Is that version of the TNL available somewhere? ;)
#6
09/18/2007 (1:04 pm)
Yes - opentnl.org has the full source for the version of TNL used in Zap.
#7
http://sourceforge.net/project/showfiles.php?group_id=106342&package_id=114583&release_id=307583
What version of TNL did TGE/TGEA stop keeping up at? (as in TGE/TGEA isn't the latest TNL yeah?).
1.5.0 changelog has some complex sounding changes in it, will it be difficult to update TGE with the new model?
http://sourceforge.net/project/shownotes.php?release_id=307583&group_id=106342
09/18/2007 (5:46 pm)
Is the Zap!'s networking code the same as TNL 1.5.0 code? I see Zap's source in the 1.5.0 file, so I assume so, from http://sourceforge.net/project/showfiles.php?group_id=106342&package_id=114583&release_id=307583
What version of TNL did TGE/TGEA stop keeping up at? (as in TGE/TGEA isn't the latest TNL yeah?).
1.5.0 changelog has some complex sounding changes in it, will it be difficult to update TGE with the new model?
http://sourceforge.net/project/shownotes.php?release_id=307583&group_id=106342
#8
TGE/TGEA never used TNL, because TNL was written well after their development started. Same techniques, different code.
09/19/2007 (1:02 pm)
Zap is running either the same code or code very similar to the stuff on SF.TGE/TGEA never used TNL, because TNL was written well after their development started. Same techniques, different code.
Torque 3D Owner Pat Wilson