07 Sep 11, 09:23PM
Long story:
ENet is based on UDP, not TCP, which means packets don't always arrive in order; with ever increasing server-side logic required to compensate for the original trust-assumption the cubeengine was built on .. meaning: combat the cheaters .. the effect of LAG has become a real gauge of whether a server or individual player is "fun to play with". The beauty of ENet is that even a dial-up connection, though less "talkative" would be able to take part in the "conversation" .. in cube (cube1) you'd just have to "get used" to a specific jerkiness in that players movements, AC has functions that smoothen (remote-)player-movement though, so that'd not be an aspect you'd have to establish a skill in anymore.
Yet .. LAG ..
The engine still basically assumes the game is local, it just uses the server as a multiplexer to keep all the "local games" (halfways) in synch.
Long story short:
The lagging player may have sent a shot-message that either took "the scenic route" (see UDP above) or is one of the few that got through - but not enough did to stop him from being flagged as lagged ... anyway, that message then gets transmitted to your client and you may take damage from it.
Caveat:
It's been known to have been used as basis for a number of exploits/cheats - a temporary lag shouldn't be cause for complaint, it's the internet after all, but if it occurs repeatedly and/or suspiciously to the benefit of the lagger you might consider mentally flagging that player as a potential cheater .. and take appropriate measures.
Don't Panic!:
This is definitely not meant to encourage a wave of "LAG .. it's a cheater!"-cries - that is not a given, but if in doubt - as always - get the demo and subject it to peer review. You should try to get the IP-address of the player and show the demo to friends and known authorities of the community (try visiting the IRC channel with a file-D/L-URL at the ready).
HTH
ENet is based on UDP, not TCP, which means packets don't always arrive in order; with ever increasing server-side logic required to compensate for the original trust-assumption the cubeengine was built on .. meaning: combat the cheaters .. the effect of LAG has become a real gauge of whether a server or individual player is "fun to play with". The beauty of ENet is that even a dial-up connection, though less "talkative" would be able to take part in the "conversation" .. in cube (cube1) you'd just have to "get used" to a specific jerkiness in that players movements, AC has functions that smoothen (remote-)player-movement though, so that'd not be an aspect you'd have to establish a skill in anymore.
Yet .. LAG ..
The engine still basically assumes the game is local, it just uses the server as a multiplexer to keep all the "local games" (halfways) in synch.
Long story short:
The lagging player may have sent a shot-message that either took "the scenic route" (see UDP above) or is one of the few that got through - but not enough did to stop him from being flagged as lagged ... anyway, that message then gets transmitted to your client and you may take damage from it.
Caveat:
It's been known to have been used as basis for a number of exploits/cheats - a temporary lag shouldn't be cause for complaint, it's the internet after all, but if it occurs repeatedly and/or suspiciously to the benefit of the lagger you might consider mentally flagging that player as a potential cheater .. and take appropriate measures.
Don't Panic!:
This is definitely not meant to encourage a wave of "LAG .. it's a cheater!"-cries - that is not a given, but if in doubt - as always - get the demo and subject it to peer review. You should try to get the IP-address of the player and show the demo to friends and known authorities of the community (try visiting the IRC channel with a file-D/L-URL at the ready).
HTH