"I thought you fire the bullet, you tell the server, it calculates what happens to the bullet and tells the client. Isn't that how it works?"
Well you can code multiplayer that way. And that way makes it more difficult to cheat. However that way also introduces a lot of lag into the gameplay. My tank game uses a server based architecture, but with trusted clients.
For example, the clients in my tank game move about as they would if they were playing the game locally. Then, each time the user changes the input they are providing, which generally happens less than five times a second, the client tells the server what inputs are currently active, where it's tank is, what direction it is facing, and how fast it is moving. This allows the client to move completely smoothly on their end, even when playing over a modem. When playing FPS games like Wolfenstein over a modem, you will find that your movements are not smooth. You jump around because the server mispredicts where your own inputs placed you. So it corrects your location. In my setup, the client is never corrected. The client corrects the server. And because every single change in direction is sent to the server, the simulations of playet movements are 100% precise. There is no player warping when there is a lot of lag. The main side effect of lag is that the players may see themselves in a different location than the other players see them. The more lag, the more discrepency there is.
Unfortunately this means that a bullet that one player thinks missed them, may actually hit them on the server side. Now, either you have the server make the decision about who was hit and who was not... Which will make you be hit by bullets you thought did not hit you, or you have the clients tell the server when they themselves were hit, which will make bullets you fire appear to do no damage to some enemies you think you hit, and damage other enemies you think you missed.
This is a problem in completely server based games too though. Most FPS's avoid this problem though through trickery. They do not tell you how much damage the other players have taken. And they use invisible bullets for most weapons, so you can't really tell if you hit the enemy players. And when they do show that you hit an enemy, it might only be blood spatters, which don't give you a very precise idea of exactly how many bullets actually hit their mark. And speaking of bullets... You fire lots of them at once, except with sniper rifles, and the damage from most weapons is spread out over a wide area, so that even if you miss with your rocket, or some of your bullets, they still end up taking some damage.
My game unfortunately does not allow me to do these tricks, so I need to reduce lag as much as possible and figure out what will annoy the player least. And probably a player being hit by a bullet they though missed them would be more annoying than a bullet they fired not damaging an enemy player or a bullet that missed damaging the enemy. So I will probably have the clients tell the server when they have been hit by a bullet rather than the server telling the clients who has been hit. The server will simply pass along the information to the other clients that one has been damaged.
Of course as I said, this can make it easier to cheat, but my secret weapon against that is that the game will only have a few people in it at once, and the game will allow the player who is the server to ban other players from the game. And there won't be any servers running with nobody manning them to watch for cheaters. Plus my game won't be near as popular as Half Life so nobody will be likely to write any cheats for it.
Anyhow, to get back to what this new timing method is for... Basically as I said in the post above, I wanted to stop bullets from appearing to bounce off a wall on one system and miss the wall entirely on another. Now, I could code the server to keep track of when bullets hit a wall, and tell the clients to spawn a new bullet there traveling in a new direction, but that would be prone to lag, and bullets would appear to stop when they hit a wall for a moment. Also if I had the server tell the player where their bullet was fired from that would result in bullets appearing away from the tank turret, and after a short delay, in some cases, again, because of lag.
Well you can code multiplayer that way. And that way makes it more difficult to cheat. However that way also introduces a lot of lag into the gameplay. My tank game uses a server based architecture, but with trusted clients.
For example, the clients in my tank game move about as they would if they were playing the game locally. Then, each time the user changes the input they are providing, which generally happens less than five times a second, the client tells the server what inputs are currently active, where it's tank is, what direction it is facing, and how fast it is moving. This allows the client to move completely smoothly on their end, even when playing over a modem. When playing FPS games like Wolfenstein over a modem, you will find that your movements are not smooth. You jump around because the server mispredicts where your own inputs placed you. So it corrects your location. In my setup, the client is never corrected. The client corrects the server. And because every single change in direction is sent to the server, the simulations of playet movements are 100% precise. There is no player warping when there is a lot of lag. The main side effect of lag is that the players may see themselves in a different location than the other players see them. The more lag, the more discrepency there is.
Unfortunately this means that a bullet that one player thinks missed them, may actually hit them on the server side. Now, either you have the server make the decision about who was hit and who was not... Which will make you be hit by bullets you thought did not hit you, or you have the clients tell the server when they themselves were hit, which will make bullets you fire appear to do no damage to some enemies you think you hit, and damage other enemies you think you missed.
This is a problem in completely server based games too though. Most FPS's avoid this problem though through trickery. They do not tell you how much damage the other players have taken. And they use invisible bullets for most weapons, so you can't really tell if you hit the enemy players. And when they do show that you hit an enemy, it might only be blood spatters, which don't give you a very precise idea of exactly how many bullets actually hit their mark. And speaking of bullets... You fire lots of them at once, except with sniper rifles, and the damage from most weapons is spread out over a wide area, so that even if you miss with your rocket, or some of your bullets, they still end up taking some damage.
My game unfortunately does not allow me to do these tricks, so I need to reduce lag as much as possible and figure out what will annoy the player least. And probably a player being hit by a bullet they though missed them would be more annoying than a bullet they fired not damaging an enemy player or a bullet that missed damaging the enemy. So I will probably have the clients tell the server when they have been hit by a bullet rather than the server telling the clients who has been hit. The server will simply pass along the information to the other clients that one has been damaged.
Of course as I said, this can make it easier to cheat, but my secret weapon against that is that the game will only have a few people in it at once, and the game will allow the player who is the server to ban other players from the game. And there won't be any servers running with nobody manning them to watch for cheaters. Plus my game won't be near as popular as Half Life so nobody will be likely to write any cheats for it.
Anyhow, to get back to what this new timing method is for... Basically as I said in the post above, I wanted to stop bullets from appearing to bounce off a wall on one system and miss the wall entirely on another. Now, I could code the server to keep track of when bullets hit a wall, and tell the clients to spawn a new bullet there traveling in a new direction, but that would be prone to lag, and bullets would appear to stop when they hit a wall for a moment. Also if I had the server tell the player where their bullet was fired from that would result in bullets appearing away from the tank turret, and after a short delay, in some cases, again, because of lag.