Me, and im sure every other person who plays LFS is annoyed at one particular thing. THE BUGGY BARRIERS.
Ive just been racing and i touched one of these red and white barriers and i flew in the air so unrealistically it was wierd.
Im starting to get really pis**ed off at this.
When will you devs start fixing things, producing more bug fixes + updates!
Maybe a few other people feel that you guys are slacking, and arnt working hard enough to keep this games standards up (HENSE THE DROP OF ACTIVITY IN THE GAME)
Why should it be "fixed"? It's not like drivers are supposed to hit them in first place. And if by "fixing" it the devs would have to screw the otherwise realistic enough physics model, then it's simply a no-no.
Now see I love what error the devs have made here,
The red and white barriers that are in LFS are based on the water filled ones you get in real life, if you were to hit one in real life, your car would not instantly stop, because the barrier is not solid,
HOWEVER the barrier would move with the impact of the car, but significantly slowing it down,
What the devs have done, is made the barrier to be permanant in its position, but still tried to make it 'soft' which is why they turned out like Jelly
What should of happend, is that the red and white barriers were made to be a much Heavier version of the hay bale, so that it can move, but not far, thus not flinging the car up in the air, yet being soft and effective at the same time
It's not the barriers that are 'wrong' or something, it's the collision detection system combined with the physics engine that causes the extreme reaction of cars when hitting them.. it's been explained some while ago.. can't be bothered to search for the topic.. srry.
Probably as a tool for the almighty layout building feature we have in LFS. I do agree its a thing that should be on the "to do" list, but im not really that bothered by it since you dont fly off if you just touch them. If you go hard into them you will fly, but you probably would have a wrecked car anyways after such a hit so it wouldnt matter that much.
This is a known issue, it has many facets that contribute to it and it is on the list of fixes that need to be addressed. The short of it is, issues with collision detection combined with the physics engine's response to a situation where two objects are reported to be occupying the same place at the same time.
The collision part of the issue is that due to a lag issue or physics tic rate limitation, two objects are allowed to pass in to one another before a collision is detected. This is what allows the physics response to happen which is to throw the objects apart violently.
The physics part of the issue is that there is not enough energy absorption allowed in the equation. In the real world energy is absorbed as structures compress, deform and or change states and through energy conversion in to heat which all reduce the amount of energy available to redirect the objects back away from each other.
So combine a situation where little of the potential energy is absorbed or dispersed with the physics engine trying to cope with a situation of overlapping objects, which it was not designed to handle and things get funky fast. Correcting the issue is not an easy thing to do and as I am not a coder I will not try offer a solution, but I can see from a logic point of view what sort of things would need to change, if not how those changes could be implemented.
In LFS this may very well be the case. My first collision system for Virtual RC Racing years ago did the same thing because I treated contact points two ways fundamentally:
1) There was an impact velocity (more precisely, a "normal" velocity perpendicular to the face that was hit) where a big force was applied to get the contacts to move away from each other at the right speed. This included the coefficient of restitution which is just a multiplier to scale down this velocity. This is the energy absorption you mentioned.
2) An additional spring force that scaled with penetration depth so cars could sit on their roofs without slowly sinking into the ground or a wall if you were wall riding. If memory serves me correctly, this part was only done if the impact velocity was below some arbitrarily chosen threshold.
The main problem with this was twofold:
1) The forces were not taken care of simultaneously correctly. I.e., if you have a bunch of contact points, each with its own velocity, then when you add them up the force can easily be too large even if the coefficient of restitution is very small. For instance, in my old system if you dropped a block on a plane with four contact points, it would solve each one independently and you'd wind up with four times as much force as you should really be getting. BOING!! Flying block Combine this with a fairly low velocity impact (like scraping up against a wall rather gently) where the spring forces come in to play and are added to this, potentially to great effect, and whammo: The car could go flying instead of scraping along the wall.
This took all kinds of little checks and hacks for special situations, but was by no means universally good. Good enough 99% of the time if you stay out of trouble and drive properly, but if anybody here has ever played Virtual RC Racing you've undoubtedly seen a car explode across the racetrack now and then after you hit a couple off track objects at the same time at a strange angle or something. This is why
2) The interpentration stuff with the springs where the extra force is determined by penetration depth can happen suddenly in some situations and cause another kick on top of this. My old system worked in a pretty simple way where the car was made up of a bunch of potential contact points (like a flight simulator). It was possible for one of these points to be "behind" a triangle yet just off to the side so it was not literally "touching" it yet. If the car moved just a tiny bit, the collision might register and suddenly there is this really huge penetration and resulting spring force. So a car could be sliding upside down very slowly, then just by chance because of how the triangle geometry was in a certain area with a few objects, you'd get this huge collision that would flip a nearly "at rest" car 20 feet in the air end over end. Very annoying and unfortunately a lot of people don't differentiate this part of physics from the driving model end of things. Suddenly the physics suck and it reflects badly on the rest of the very good model where the really important stuff is (the driving/vehicle model which is separate).
In my case problem 1 was more of the situation. It wasn't so much the interpenetration problem, but rather how I was treating simultaneous contacts.
The solution was rather complicated and took nearly a year to figure out and write and is still not perfect in every way, but suffice it to say I can now stick a car half way into a wall and it will pop out in one time step without going flying even an inch. So there are ways around this. In my case though I had to completely throw out the old collision system and start over. It was not a simple fix by any means. Given that it took a year, I'd be surprised to see Scawen bother. Wouldn't you guys rather have something else instead first
I don't know how LFS works in this area of course. Just sharing my own similar experience. The interpenetration problem you described here is definitely real in some engines and not others. Changing this is a massive task though. Probably was worse than writing the vehicle model itself...
Yes, this is true. This turns out to be the simple coefficient of restitution and is no big deal in practice. You have a target velocity that you're trying to make a certain contact point reach after hitting something and just scaling it down with a single multiplication. (It's just a single line of code in my engine.) In my system at least this was not one of the real problems. I doubt it is in LFS either, but could be wrong.
I'd be surprised to see this ever fixed. If I had to vote I'd say spend the next many many months or a year doing other things rather than rewriting the whole collision response system.
Don't forget that this does not apply to solid objects on track...
SO walls, even softs ones, never seem to send you flying.
You can get a launch from the wall surrounding the track areas, but only when you manage to get one car wheel inside the wall (massive crash involved, from what I know you have to approch the wall from above to do that).
I remember an interesting hypothesis from AndroidXP some time ago, explaining that the bug was probably caused by the thickness (lack of) of the barriers - allowing the car to penetrate the barrier in between collision calculations. You only get a launch when the wheel and the barrier intersect, the car body seems to react "normally" to collisions.
So if Slap you guys on a track, with an FZR in a race with 10-20 people on it, you wont fail? I only know 2-3 good Cruisers who can manage to race. This may not be the case for all of you. :P
You may not be noobs because you make over 200 laps a day, on the same track, at speed limits..
Wouldn't the simplest sollution be to make the barrier solid? Look on fences on BL3, no matter how hard you hit them, those sons of bitches won't move - nor send your car flying.
What if the devs somewhat could code the barriers to be absolute solid?
Why can't this be done / what are the limitations?
It could be done... But they want them to be soft, and still to stop your car. Like water filled barrels. That's why they can't just be solid. And try to drive a lap around Oval and hit the concrete between track and pits. What happens? Here's the video. Sorry for drivin' on keyboard. (Unlimited attachments. )
