does the damage before impact only hapen in replays or also during real time gameplay ?
Yes, you're exactly right - which is my problem with the "servers POV" solution. I really didnt have time to think it through yesterday, but you've got the nail on the head with that idea...
Nice idea, but you cant really do this as an unknown number of physics steps will have cycled (outside influences could alter the FPS and thus the number of cycles per frame etc. etc.), so things may happen that you cant predict accurately, and you'd probably end up doing the expensive damage calculations twice for the same item of damage.
Whilst its a nice idea, I'm not sure on how it would applicable it is, for the above reasons
This is something I've been meaning to discover.
Other than recording the output of LFS, through a graphics card (fraps wouldnt have a small enough frame time), so we can determine this, I dont think we can solve the mystery completely
it happens early realtime, just so fast you dont notice it, thats why i dont really see this whole thing as being a problem imo
and about the "server side" replay.. that makes no since, why would the server be doing work for your own computer like that? afaik, your own car doesnt lag whatsoever in any way shape or form.. if it did im sure you would see some times where you are jumpy and whatnot, each replay is done by your own computer recorded by what is being sent to you, otherwise it would be the server sending you what you just did which.. i still have to say makes no since at all
after testing this in single player, im gonna have to say it occurs only in multiplayer, so heres a test for you angel, get some buds, go to BL carpark, run some cars into each other and watch what happens (one stopped, and have the other car charge into it)
if nothing happens, lower the PPS, if nothing then, somehow increase lag (might be hard but it would be helpful) so what i suggest is you do one at 3 PPS and if you didnt see anything, still save replay, leave server for a few secs, and watch that MPR again and see what happens, if nothing happens this might be deeper than lag
and about the "server side" replay.. that makes no since, why would the server be doing work for your own computer like that? afaik, your own car doesnt lag whatsoever in any way shape or form.. if it did im sure you would see some times where you are jumpy and whatnot, each replay is done by your own computer recorded by what is being sent to you, otherwise it would be the server sending you what you just did which.. i still have to say makes no since at all
after testing this in single player, im gonna have to say it occurs only in multiplayer, so heres a test for you angel, get some buds, go to BL carpark, run some cars into each other and watch what happens (one stopped, and have the other car charge into it)
if nothing happens, lower the PPS, if nothing then, somehow increase lag (might be hard but it would be helpful) so what i suggest is you do one at 3 PPS and if you didnt see anything, still save replay, leave server for a few secs, and watch that MPR again and see what happens, if nothing happens this might be deeper than lag
I'm not seeing it as a problem XCNuse, I'm more curious about how LFS works, and understanding some of its stranger behaviours. Sometimes it can help solving problems or answering questions. Plus it solves some of my personal niggles.
Oh dear (see my comment at the bottom)
*sigh* Something (amongst other things) I've been trying to sort out for a little while - but nothing I have time for (****ing woman changing things last minute [her: "oh, we'll go to mine tonight" me: "but we said mine...i've arranged to do things later" her: "dont you love me?" me: "argh!! ****ing hell..." etc. ] and work [booo, evil buggers 
])
Thats kind of my fear at the moment. It could be a deep issue with LFS, and in the future it might be a lot harder to fix
Oh dear
(see my comment at the bottom)*sigh* Something (amongst other things) I've been trying to sort out for a little while - but nothing I have time for
(****ing woman changing things last minute [her: "oh, we'll go to mine tonight" me: "but we said mine...i've arranged to do things later" her: "dont you love me?" me: "argh!! ****ing hell..." etc. ] and work [booo, evil buggers ])Thats kind of my fear at the moment. It could be a deep issue with LFS, and in the future it might be a lot harder to fix
I'm not sure what did you mean but I think the server just shares the data about car damage, car positions, player related data (name, car choise...) etc. ... and checks that the client has valid version of LFS
But wouldn't it be *** to have the server run the physics of the all cars too?
I think the system is more like this:
the server just shares the data. Meaning that that it gets data from player A's client and sends it to other players. Then these client machines check the positions of the other cars and compared it to the postion of your own car (also speed and other factors too). As the network system has lag and the physics system has lag, these two make this possible:
Let's imagine two cars racing on the track:
1. cars are 1 mm from each other
2. a data package is send to the server by both clients about their current situation
3. Server forwards the data back to clients
Let's assume these 3 steps take 0,2s to happen.
In the meanwhile the cars have moved forward and also closer to each others in their clients' LFS engine. The server does not know this yet. The real distance between them is now -5mm. So the cars are "overlapping". At the moment the client A thinks that the other car B is driving directly forward. The client A does not get any actual data about this but it predicts it. The same is done vice versa.
4. So the both clients think there is some distance between them. Now the clients recieve the packets from the server. The collision system (the rays system, as mentioned earlier) is ran and the prediction damage is calculated and shows up in the 3d model. (the ray models notices that the cars are overlapping)
5. The actual code handling the actual damage and physics is calculated (the bounding box, as said earlier). It gets some weird data about the distance and the speeds of the cars (the distance of the cars being now -5mm). As it was just just before positive and bigger. (This may or may not be the cause why we sometimes get some strange sky flying episodes, but I have some more to it. The physics engine may see that the other car has a lot more speed than it in reality has and therefore it thinks the impact is much higher...read on)
6. The physics are run in the clients' machines and clients send this data to the server, which forwards them as said earlier.
6.1 at the same time the car of the client gets its physics data and the physics are run. The car of the client A gets the force of the impact and moves slightly away from the the other car B (but the B doesn't see it yet, though he moves away also, but the A does not see this. They both see the other has moved when they get their packets from server.
7. The impact is not that big, so the cars don't change their lines much. So when the clients recieve the next packets the data on those says: Cars are still inside each other, distance being -3mm, but the speed of the both cars is away from each others too. Maybe the clients engine can't understand this (or the force factor is coded so that it is set as integer with values acceptable being over 0 and under 50000 (can't remember the right values for this, sorry). As it gets a negative value (or too big one) the integer gets "upside down" and becomes something really big. Or it gets a 0, meaning there is no effect at all.
But there is also a third option. As the bounding box sees the distance is negative it tells the phys engine to create a negative force too. As this force draws the other car close the value gets again negative and bigger, let's say -12mm. Now the bounding box gets the right values for the speed (cars gettting closer) and wrong values for the distance. So it just gives some berzerk values to the physics engine, which creates a big force between the cars.
8. So the client A gets a big value and flies off the skies while the B keeps driving and notices an airplane on the sky
. The client A sends the data to the server which just forwards it, and doesn't notice those ridiculous values about it's altitude.
I will read this once more, once I've got my head cleared up. So beware the obvious logical errors in it
But wouldn't it be *** to have the server run the physics of the all cars too?
I think the system is more like this:
the server just shares the data. Meaning that that it gets data from player A's client and sends it to other players. Then these client machines check the positions of the other cars and compared it to the postion of your own car (also speed and other factors too). As the network system has lag and the physics system has lag, these two make this possible:
Let's imagine two cars racing on the track:
1. cars are 1 mm from each other
2. a data package is send to the server by both clients about their current situation
3. Server forwards the data back to clients
Let's assume these 3 steps take 0,2s to happen.
In the meanwhile the cars have moved forward and also closer to each others in their clients' LFS engine. The server does not know this yet. The real distance between them is now -5mm. So the cars are "overlapping". At the moment the client A thinks that the other car B is driving directly forward. The client A does not get any actual data about this but it predicts it. The same is done vice versa.
4. So the both clients think there is some distance between them. Now the clients recieve the packets from the server. The collision system (the rays system, as mentioned earlier) is ran and the prediction damage is calculated and shows up in the 3d model. (the ray models notices that the cars are overlapping)
5. The actual code handling the actual damage and physics is calculated (the bounding box, as said earlier). It gets some weird data about the distance and the speeds of the cars (the distance of the cars being now -5mm). As it was just just before positive and bigger. (This may or may not be the cause why we sometimes get some strange sky flying episodes, but I have some more to it. The physics engine may see that the other car has a lot more speed than it in reality has and therefore it thinks the impact is much higher...read on)
6. The physics are run in the clients' machines and clients send this data to the server, which forwards them as said earlier.
6.1 at the same time the car of the client gets its physics data and the physics are run. The car of the client A gets the force of the impact and moves slightly away from the the other car B (but the B doesn't see it yet, though he moves away also, but the A does not see this. They both see the other has moved when they get their packets from server.
7. The impact is not that big, so the cars don't change their lines much. So when the clients recieve the next packets the data on those says: Cars are still inside each other, distance being -3mm, but the speed of the both cars is away from each others too. Maybe the clients engine can't understand this (or the force factor is coded so that it is set as integer with values acceptable being over 0 and under 50000 (can't remember the right values for this, sorry). As it gets a negative value (or too big one) the integer gets "upside down" and becomes something really big. Or it gets a 0, meaning there is no effect at all.
But there is also a third option. As the bounding box sees the distance is negative it tells the phys engine to create a negative force too. As this force draws the other car close the value gets again negative and bigger, let's say -12mm. Now the bounding box gets the right values for the speed (cars gettting closer) and wrong values for the distance. So it just gives some berzerk values to the physics engine, which creates a big force between the cars.
8. So the client A gets a big value and flies off the skies while the B keeps driving and notices an airplane on the sky
. The client A sends the data to the server which just forwards it, and doesn't notice those ridiculous values about it's altitude. I will read this once more, once I've got my head cleared up. So beware the obvious logical errors in it
It also does some basic sanity checking as well...
Yes, sorry if I didnt make this clear. This is exactly how it should work. The client is the only one who works out damage. The server shouldnt even see the clients as more than 1 "point".
I've not got the chance to read your whole post right now. I'll edit/update when I can.
Collision detection
(56 posts, started )
FGED GREDG RDFGDR GSFDG