since this bug is there since 2005 or earlier and still hasent been fixed, i'll post it again...
the red-white barriers are bouncy..
this simulator should be realistic...
and afaik flying to the moon because of hitting a barrier isnt realistic!
when will this bug be adressed?
when cows can fly?
c'mon scavier, set priorities...
whats more importent? interiors or good gameplay?
flying to the moon isnt really a great aspect of a race simulator :s
when i know it korrectly it´s not even the bareer that produces this bug, it has anything to do with lag (but was a while back that i read that so i can´t remember very well)
When you're on single player it still does that not only with the AI cars but your car as well. It had nothing to do with lag. What they could do is fix the barrier to act just like a trackside wall. If they could do that, (cuz I have no idea who fixes bugs.. I forgot already) then the problem is solved.
I read from a similar topic a while ago that the fix is not as easy as making the barriers act like a trackside wall. This is because the trackside wall is a static object, which means that the collision engine only needs to calculate the speed and angle of anything that hits it, because the location of walls is coded into the track itself.
With the autocross objects which can be placed anywhere, when a car hits them, the location and angle of the barriers has to be calculated as well as the speed and angle of the car, which takes longer to compute so the car can go partially through the barrier before the collision detection realises that the barrier has been hit. It is then that you get the journey into outer space.
If you go fast enough, you can sometimes go through the barrier completely with not so much as a scratch because the car has passed through the barrier so quickly and is out the other side before the collision has been detected.
It's something like the car's updating 2000/1 of a second and collisions only 200/1 so the game detects the collision when the car is in the middle of the barrier = JUUUMP
Correct me if i'm wrong but.. I can't find the thread proving me..
I think it was said that if you improved the collision detection it would kill most computers.
The collision detection runs at 100Hz, to be able to cause a problem and go by undetected the car would have to travel more than one whole car length in 1/100th of a second, which is about 2160 km/h (1340 mph).
So the detection is certainly there, the main problem is that a barrier is very small and can be approached from all sides. With a track wall, you have a very definite way of telling what's inside the track and what not, therefore it's very easy to determine which part of the intersecting car is somewhere it doesn't belong. With the barrier it's different - as soon as your car sticks through the barrier you don't even know from which side the car approached. Did it just gently tap one side or was it flung through the barrier rapidly from the other side? Or even, what is a "side"? As a human that's easy to tell, but from the engine point of view that's just a 3D object that could have any shape which may not be intersected.
A different problem is the collision response. Right now it seems to generate a opposing force dependent on how far the object intersects, or something similar. The problem is especially apparent on the tyres; either they have the same response as the rest of the car but since they're running at 2000Hz they add that repellent force 20 times before the normal car physics can even react, or they have an inherent problem due to trying to drive "on the surface", which instantly teleports the tyre contact patch to the topmost surface from the object it is intersecting with (normally the ground).
The only solution I can see (though I have never worked with collisions in a 3D environment) is that the collision response is rewritten substantially. It would need to keep track of the objects previous locations (like 2 or 3 frames) so upon collision it can look back in history and extrapolate the objects relative speeds to generate a proper response, instead of just looking at how far everything intersects. Other cars suddenly teleporting into you (due to lag/prediction errors) are another thing that needs to be solved. Every time a car's position is corrected, the collision response should take that fact into account and make a sanity check with the last known positions, since it's very unlikely that the car to you left suddenly steered into you with very high speed. Though when implementing such a thing you at the same time you have to watch out to keep the sanity checks very subtle. A real high speed crash should not make the system go "well that was unlikely to happen, so it didn't", but instead still generate a proper response.
I'm by no means qualified to solve this kind of issue, but it seems to me that if the system is not able to react quickly enough to provide an adequate answer, another way would be anticipating / getting ready for the collision.
I was thinking of a larger ghost enveloppe around the cars, basic volume shape, that stores the pre-collision data to be used in case of collision in the next iteration(s). Do you think it would be feasible?
I have no idea how it would affect resources though, might be a terrible hit.
That is a very good idea, however, the only downside i can see, which you mentioned, is LFS itself having to constantly update the position of the cars, thus updating the envelope.
Im just wondering if your suggestion could be implemented, but on the barriers themselves, as the barriers are static, LFS would in theory load these settings when the track is loaded and that would be all it would need to do.
Probably the most known about bug in LFS history. It's not fixed yet because it's not that simple.
Besides, it's only annoying in those Auto-X events, but then again, I'm sure the majority of LFS players don't bother with those. The barriers in LFS are foibles, not overly annoying during the majority of races, and alot of fun when the mood takes you.
I strongly disagree with this part of your post.
Racing on Fern Bay tracks can be a nightmare as well, because the collision bug does also affect the chicane damned tyres. If the car ahead sets one of these tyres loose you get into a lottery where the jackpot is a return trip to the moon.
I often race on Dead Men Racing server, and they usually add obstacles to create new chicanes on the tracks or add obstacles to make sure existing chicanes do slow you down. Even if this server attracts fair and clean racers, a light contact with these obstacles can happen - and that buys you another lottery ticket.
But this bug is long known, and I am sure that it is on the "devs are probably working on it" list
I rarely have issues with this bug but others have and I have often pondered a solution. I wonder if it would be possible for the barriers in question to be recoded so that when a collision occurs the barrier reads it as a low speed collision instead of at the actual speed that the car collided with the barrier. If the barrier (and/or car/ or tyre) "thinks" the collision was a minor one perhaps the reaction wouldn't be so exaggerated? I have also pondered the same theory for car collisions where lag sometimes allows two cars to overlap which may cause a "flying car" event.
