In other words, it is completely impossible to become correctly synced if the server is running anything but 100FPS, 200FPS 300FPS. net_graph is a strange debugger tool - not even VALVE understand how it works).įor example, if a server is running 125FPS, the client is forced to use 62.5FPS in order to become correctly synced.
The trick with net_graph 1 is that the blue/purple line (below green one) shows how off sync you are with the server (why I don't know.
#Download cs 1.3 download
The green line shows how stable your download is, the line under is for upload.įor a perfect example, use "New Game" and watch how the line is dead stable, just like the green one. Use net_graph 1 to determine how much in sync you are. The problem is getting synced with the server. Please please please do anything you can to optimize the netcode to what it was in CS 1.3 and earlier versions! Or even improve it beyond that. A more responsive game is more fun and addictive. Players want to feel empowered, not restricted. Since cheaters will invariably cheat, why not optimize the netcode experience for everyone else and allow them to manually police cheaters the way they must already do now in tournaments, competitive leagues, and public servers? The problem is that the user experience has suffered, but people still cheat. For our games, this risk is too high and we fall back to requiring an authoritative server. If we encapsulated absolute state data in this fashion, we'd raise the motivation to hack the client even higher than it already is3. For Half-Life, this mechanism is unworkable because of realistic concerns about cheating. This is how peer-to-peer games generally work. This is how a lot of the military simulation systems work (i.e., they are a closed system and they trust all of the clients). At this point, you may be asking, why not eliminate all of the server stuff and just have the client report where s/he is after each movement? In other words, why not ditch the server stuff and just run the movement and weapons purely on the client-side? Then, the client would just send results to the server along the lines of, "I'm now at position x and, by the way, I just shot player 2 in the head." This is fine if you can trust the client. Replicating the necessary fields to the client and handling all of the intermediate state is a fair amount of work. All of the variables that contribute to determining weapon state (e.g., ammo, when the next firing of the weapon can occur, what weapon animation is playing, etc.), are then part of the authoritative server state and are replicated to the client so that they can be used on the client for prediction of weapon state there.īut it goes on to say that this was done in order to mitigate cheating: Umm, This is a Lot of Work In Half-Life, we chose to avoid this complication by moving the implementation of a weapon's firing logic into "shared code" just like the player movement code. Of course, this can get complicated if the actual weapon logic is different between client and server. With this information, the firing logic can be layered on top of the movement logic because, once again, the state of the firing buttons is included in the user command data structure that is shared between the client and the server. Additional state information is needed for the local player on the client, of course, including which weapons are being held, which one is active, and how much ammo each of these weapons has remaining. Layering prediction of the firing effects of weapons onto the above system is straightforward. Here is a relevant excerpt from the paper (bolded sentences to get the gist): Bernier ( and it seems this change was made in order to mitigate cheating. I read a white paper about the netcode by Yahn W. We saw evidence of this change of behavior as top tournament players lost their ability to effective spray weapons accurately with later releases. The CS 1.3 netcode was more responsive than later versions of the game.
0 kommentar(er)
