When dev's look up into better collision?
I found this thread http://www.lfsforum.net/showthread.php?t=2148 and its 5 years back.
This never really troubled me before now. (IHR) is great racing server but collision detecting sux big
time and people get banned for no reason becouse of this.Allso this would add the meaning of close racing in LFS which never really was in there.

thank you for your suggestion, however it has been suggested 999999999999 times before. everyone knows about the barrier bug.

It's even in the know bugs threads and you haven't noticed it

Just pointing the thing what imo would be necessary to fix.
it have been known issue for over 5 years and it still is there.

You ever think there's maybe a reason for that? It's a lag issue more than it is a physics issue and I'm pretty sure it relates to the number of cycles dedicated to external body collisions and the latency between server and client skipping them.
If that's what is actually happening then the physics system would need updated to run a higher physics frequency which would eat up even more CPU time.

I still bounce to the moon off barriers in single player in which last time I looked, has no lag. There's some fundamental issues with collisions. Which, by the way has been mentioned in the last 18 months in the devs to-do list.

From my programming experience in physics there can be huge challenges that are rarely solved; like the red and white barrier. I think Dajmin was correct in saying 'lag' is the issue, however not internet based lag. Running a game (or physics engine within a game) at 100fps (100hz) means that the physics will update once every 0.01 seconds. Which is a substantial amount of time.

Two objects that collide at time = 0.014 will not be colliding on the first update (time = 0.01), but will already be into eachother by quite a lot by the second update (at time = 0.02). This impurity in computer simulations is brings huge issues all around. Why it happens only to the red and white barriers, likely because the barriers are placed as objects rather than being part of the track; An object that doesn't move yet is not considered static - just a guess. It could also have to do with the fact the collision model is thin for the wall, meaning when the car is halfway through the wall at time = 0.02 the wall will apply forces in all sorts of directions because the car is on all sorts of directions from the center of the object.

Kinda hard to describe what I mean without pictures that I am too lazy to draw at this moment. But saying this is a difficult problem is an understatement.

I dont think it is anything like that, cuz there is illegal mods that makes the barriers either move and be like a cone or a tire, or it can be static like a wall(no moon visit or anything like that)

I belive all this is easy to fix, cuz if a non dev can make a mod about it without really knowing lfs its hearth like a dev, it sounds pretty easy for a modder... imo

Quote from JasonJ :

I still bounce to the moon off barriers in single player in which last time I looked, has no lag. There's some fundamental issues with collisions. Which, by the way has been mentioned in the last 18 months in the devs to-do list.

No one has mentioned the white-red barriers -.-

They were discussion the car to car collison.

Quote from Uke :

No one has mentioned the white-red barriers -.-

They were discussion the car to car collison.

Quote from mattlikespeoples :

So i was racing around a tight autoX course and i just realized how much this annoyed me. I'd clip a big red barrier, sink in a bit and then shoot off in the other direction when i should've hit it and ricocheted off, not sling shotted in the wrong direction.

I don't know where it was discussing other things but I was under the impression of the barrier bug as well. Not only from JasonJ's post, but also because I briefly read what the "5yr old" thread was about and the first post told me; barriers. I don't know, but it didn't sound like it was about car to car collisions. Maybe they did later on, in which the original post here should have specified.

Same thing applies. Imagine it on a bigger scale. One physics refresh per second. Most of the time you'd be fine because the cars stay apart but when they collide you have to wait for the next second for the collision to be detected. Think how far overlapped the cars could get in a second - that's a lot of force build up. Those forces get applied in that next cycle irrelevant of whether you've actually seen them build up or not.

I can't remember what rate LFS updates at (is it 333Hz?) but for the sake of easiness we'll use 100Hz. With 100 refreshes per second you only have 1/100th of a second before the collision is detected, but even then the cars can overlap a long way before that happens. It can't be ruled out totally (my earlier example was a combination of both net lag and physics refresh latency) but the issue is exasperated when you combine that physics rate with a connection which may lose those packet updates along the way.

If your car is doing 100mph then it will travel just under half a meter per 100Hz physics refresh, and that's a lot of distance to overlap

Exactly, my explanation was not only for the barrier issue, it was with all physical objects; Although I did also mention some things more specific to the barrier, the physics timestep example; as Dajmin points out, applies to all aspects; including car-to-car collision.

What about repare just barrier's bug now? And a rest in S3 for example.

The bug has always been there, it should have been fixed before new content was added imo.

I don't think you're understanding the underlying problem here. There is only so much a computer can do, and the time step being to large. Like Dajmin said, at 100mph at 100hz the car moves HALF A METER every 'step'. You can't always place the car where contact initiated, because the barriers are thin the contact could have initiated on the left side and also the right side all in the the same time step; that is where things will go wild. One solution is to speed up the rate physics are run; so that the car can't go more than 1mm or something small enough, within a single time step; this of course is not quite possible with current CPU speeds although I believe there will come a day.

yeah, blackbird pretty much summed it up.

It is to do with the barriers being moveable objects so they are not hard coded into the track so to speak, which is where the problems are caused....


Any regular wall doesn't fling you into the sky at over 9000 mph because the collision detection system knows that whatever happens, any given force could only have been applied to it from one side, as the other side of the wall would be out of bounds etc, but with a barrier, a moveable object, by the time the physics knows that it has been hit, at what angle, and tries to decide from what side it was hit first (the car is half way through it at his point) so all forces from all possible angles and directions are applied all at once which results in well, flying cars, or if you are going fast enough, you can go totally through the barrier.

The same also happens with the wooden fencing on the BL carpark, if you end up out of the track and drive slowly into the fence, you can drive through it until a certian point, and then the collision forces go mental and then you get flung accross the track.

Oh comoon. We dont need no monster Cpu's to run LFS with ok collision.

Right, can a more mathmatically minded person come and explain how many CPU cyles would be needed in order to have a nigh on perfect real time collision system, as i imagine it would be a bloody lot!