Apr 03, 2010, 02:26 AM
I don't recommend the nonaue.dem. Really impossible to see anything because the whole thing was recorded from a 3rd person camera that isn't even locked to the player's orientation. Without the first person I think the demo looks legit and he missed that soldier Ranma mentioned 4 times in a row before the guy cratered (grazing him with 0-2 pellets of a scattergun is a miss, definitely not a bot during this scene).
Saw a short discussion about his lag:
F*ckin Nasher... : you are so fuckin laggy unintelligible name...
ñØÑŵ£ : downloading files ^^
I couldn't actually see him lagging from the demo. The guy really could have been downloading stuff, but lag is rarely ever beneficial. It may help in a few situations, but overall they are at a significant disadvantage to players with less latency and congestion. If a player consistently benefits from a poor connection, I would suspect it was done intentionally or maybe even the effects of a speed/rate hack or something.
The take2.dem does seem a bit odd. He manually aims at his targets and doesn't take a shot until you would expect him to, but as soon as he clicks it hits them so dead center every time. I didn't see any strong signs like snapping to unintended targets who are not even near the reticule. But I did see the little reticule jig that was mentioned near that last checkpoint on cp_granary. He was trying to look left but it was like his orientation was being reset on the following frame.
I've seen that sort of behavior before in games. In most games, player input is one of the first things to be evaluated within the main loop, and then it will update your position/orientation based on what keys or mouse movements it sees. it reads network buffers, the scene is updated, audio is queued, light cycles go by, and eventually it has to render the scene for you to view. Now considering that order of events, to take control away from the player, either intentionally by the game or like an aimbot would do, they usually allow the game to process inputs and update the scene as usual, and then they reset to the desired position and orientation. This is fine, so long as they set these values after the scene has been updated and prior to rendering the scene. If these values are reset before the pos/aim is updated or after the scene is rendered, you end up with a series of frames that are all starting out with a forced orientation but are then being slightly offset from each other by the inputs of the player and other updates, causing a 'vibration' effect.
Saw a short discussion about his lag:
F*ckin Nasher... : you are so fuckin laggy unintelligible name...
ñØÑŵ£ : downloading files ^^
I couldn't actually see him lagging from the demo. The guy really could have been downloading stuff, but lag is rarely ever beneficial. It may help in a few situations, but overall they are at a significant disadvantage to players with less latency and congestion. If a player consistently benefits from a poor connection, I would suspect it was done intentionally or maybe even the effects of a speed/rate hack or something.
The take2.dem does seem a bit odd. He manually aims at his targets and doesn't take a shot until you would expect him to, but as soon as he clicks it hits them so dead center every time. I didn't see any strong signs like snapping to unintended targets who are not even near the reticule. But I did see the little reticule jig that was mentioned near that last checkpoint on cp_granary. He was trying to look left but it was like his orientation was being reset on the following frame.
I've seen that sort of behavior before in games. In most games, player input is one of the first things to be evaluated within the main loop, and then it will update your position/orientation based on what keys or mouse movements it sees. it reads network buffers, the scene is updated, audio is queued, light cycles go by, and eventually it has to render the scene for you to view. Now considering that order of events, to take control away from the player, either intentionally by the game or like an aimbot would do, they usually allow the game to process inputs and update the scene as usual, and then they reset to the desired position and orientation. This is fine, so long as they set these values after the scene has been updated and prior to rendering the scene. If these values are reset before the pos/aim is updated or after the scene is rendered, you end up with a series of frames that are all starting out with a forced orientation but are then being slightly offset from each other by the inputs of the player and other updates, causing a 'vibration' effect.