Ughghghghgh the force feedback is inverted :vomit:
This makes evaluating the physics near impossible, but from what I can tell they're not *that* bad, at least compared to what such projects usually produce. But where you got the idea from that this thing has anything in common with LFS physics wise is a mystery to me. Maybe you could be fooled if you only use keyboard and thus don't even know how good LFS physics are to begin with. In any way, this program doesn't handle like LFS now, nor like any previous version of LFS.
This makes evaluating the physics near impossible, but from what I can tell they're not *that* bad, at least compared to what such projects usually produce. But where you got the idea from that this thing has anything in common with LFS physics wise is a mystery to me. Maybe you could be fooled if you only use keyboard and thus don't even know how good LFS physics are to begin with. In any way, this program doesn't handle like LFS now, nor like any previous version of LFS.
As I understood he means the rear mounting point of the upper wishbone.
Don't worry, that's just your chin absorbing the brunt of LFS forums drama! 
Not sure if I understand your question correctly, but to semi-accurately simulate a monoshock suspension in LFS all we need to do is:
1) Only allow symmetrical editing of the spring strength since there is only a single spring (this is already the case, as we cannot modify spring stiffness asymmetrically anyway)
2) Set the ARB to a high value and lock it or only allow minimal editing
The second point is the reason why the default FBM setup has 100 N/mm front ARB. Other than that nothing else needs to be done to get nearly the same behaviour. Of course a proper simulation (that allows you to use more realistic values) would be preferable, and I believe a few details are different - at least the spring plays a different role on resisting body roll in addition to the anti-roll bar.
1) Only allow symmetrical editing of the spring strength since there is only a single spring (this is already the case, as we cannot modify spring stiffness asymmetrically anyway)
2) Set the ARB to a high value and lock it or only allow minimal editing
The second point is the reason why the default FBM setup has 100 N/mm front ARB. Other than that nothing else needs to be done to get nearly the same behaviour. Of course a proper simulation (that allows you to use more realistic values) would be preferable, and I believe a few details are different - at least the spring plays a different role on resisting body roll in addition to the anti-roll bar.
I wondered the same thing, actually. Maybe it's bendy metal - then that bar would act as a weak spring, too, but that seems like a strange design decision.
Whoa there, look at that badly tuned suspension. You really should put some anti-roll bars on it!
Just for your information David, the anti-roll bar in a monoshock suspension is the part marked in orange:
The anti-roll strength is determined by how much this bar resists twisting (blue arrows, twisting in a direction depending on which wheel tries to move upwards).
If both both left and right suspension move equally, there is no twisting and only spring and damper influence the wheel's vertical movement. In this case the whole T-shaped segment moves back and forth (green arrow), compressing the spring.
If for example only the right wheel drives over a kerb and is thus pushed up, the triangle part rotates counter-clockwise (it rotates around the green part which is where it's mounted), pushing the damper rod and pulling on the spring rod. Since only the right wheel tries to move up, the anti-roll bar now has to twist clockwise to allow (or not allow) this to happen.
Obviously this means if LFS tries to simulate a monoshock suspension (front susp. of FBM for example) the ARB should have a very limited adjustability and be rather strong in general, which isn't the case at the moment. Though this should be fixable very easily with simple setup restrictions in the future.
The anti-roll strength is determined by how much this bar resists twisting (blue arrows, twisting in a direction depending on which wheel tries to move upwards).
If both both left and right suspension move equally, there is no twisting and only spring and damper influence the wheel's vertical movement. In this case the whole T-shaped segment moves back and forth (green arrow), compressing the spring.
If for example only the right wheel drives over a kerb and is thus pushed up, the triangle part rotates counter-clockwise (it rotates around the green part which is where it's mounted), pushing the damper rod and pulling on the spring rod. Since only the right wheel tries to move up, the anti-roll bar now has to twist clockwise to allow (or not allow) this to happen.
Obviously this means if LFS tries to simulate a monoshock suspension (front susp. of FBM for example) the ARB should have a very limited adjustability and be rather strong in general, which isn't the case at the moment. Though this should be fixable very easily with simple setup restrictions in the future.
Holy thread-resurrection Batman!
Did you notice the post you replied to was made more than three and a half years ago?
Did you notice the post you replied to was made more than three and a half years ago?
I think it's the responsibility of whoever puts those links on their page, etc. to use the now correct format. I can't imagine the URL format will ever change again, now that it is implemented in LFS itself, so it should only be a one-time change anyway.
E: ^^^ I guess that kind of answers it 
^^^
---
Are you sure you're actually clicking a well-formed lfs:// link?
A correct link must look like this:
If someone creates a link that is just
you'll get the parameter 1 invalid error message.
^^^---
Are you sure you're actually clicking a well-formed lfs:// link?
A correct link must look like this:
lfs://join=<hostname>
If someone creates a link that is just
lfs://<hostname>
you'll get the parameter 1 invalid error message.
I can confirm that the sound vanishes - I think Niko caused it. Watch the pit exit at 24:45, on top of the bridge the where the left corner down to the exit ramp starts; Niko crashes and flies off into the trees. His car hangs there for a second before the sound cuts out at the exact moment where he respawns onto the track. If you watch him directly (first person/follow view, not shift+u), then the sound bugs out even more and the camera doesn't respawn at all.
It is a userrights issue. I don't have Vista/Win7, so I cannot go into detail on how to fix this, but you should either install LFS into the equivalent of the XP "My Documents" folder, or give your user account write/modify rights to the LFS folder. Running the LFS.exe with administrator privileges might help too, if you're using the auto-updater.
Tough luck.
I'm serious. There is nothing the people on the forum / devs can or will do. Track down whoever is doing that and solve it in private.
I'm serious. There is nothing the people on the forum / devs can or will do. Track down whoever is doing that and solve it in private.
I'm not sure if people with fewer than 10 posts can upload attachments here 
\/\/\/ Guess I was wrong
\/\/\/ Guess I was wrong
Last edited by AndroidXP, .
Yo, graphs 'n shit is my business, dude!
Wait, actually it isn't. I guarantee my graphs involve no mathematics whatsoever (at least not from me!) since I'm a complete failure when it comes to maths.
Heh, not so sure about the latter part.
But seriously, I'm just sick of seeing the same effortless moaning / complaints repeated over and over. Everybody knows that LFS does not simulate every aspect of racing correctly (heck even the arguably best one - physics - is bad enough that Scawen decided it needs a complete overhaul); any "improvement suggestions" consisting solely of pointing that out are worthless.
You shouldn't have bothered, really.
Constructive feedback is only available in response to constructive improvement suggestions. This random bunch of complaints doesn't exactly fulfil that requirement.
That's I think an artefact of the anisotropic filtering. Has nothing to do with LFS itself or Z28 specifically.
To expand on this a little, the reason for this restriction is that every car actually has a fixed simulated gearbox type - it's not just "roleplaying" to use the most realistic one. The road-type and "older" sports cars have H-gate boxes, whereas all other cars have sequential ones with the BF1 being the only one actually using paddles. I guess you already saw the list on the script guide.
Now one restriction sequential gearboxes have is that they are, as their name indicates, strictly sequential. To go from 5th to 2nd you need to go 5th-4th-3rd-2nd - there's no way around that. If the H-gate shifter mode could be used for such a car, this would allow you to "cheat" by immediately going from 5th to 2nd. The other way round (using a sequential shiftmode for H-gate cars) is of course possible, since nothing stops you from going through every gear in a H-gate box.
Now one restriction sequential gearboxes have is that they are, as their name indicates, strictly sequential. To go from 5th to 2nd you need to go 5th-4th-3rd-2nd - there's no way around that. If the H-gate shifter mode could be used for such a car, this would allow you to "cheat" by immediately going from 5th to 2nd. The other way round (using a sequential shiftmode for H-gate cars) is of course possible, since nothing stops you from going through every gear in a H-gate box.
It will be a host option.
A particle system (which the current smoke already is, just a very simple one) has nothing to do with the DX version. That "puff" could very well be spawned at a different location than the contact patch and also behave differently than now - it just needs to be coded. The hard part is not generating the smoke particles, but finding a good mathematical model that tells you when, where and how much smoke you need to generate.
Used for distance measurement. Has been implemented since... ages.
I guess they're aiming for a Christmas release, but we'll see. Software development time can be quite unpredictable if delivering an unfinished product is not an option.
Hah, if only!
Apparently you don't know how CPUs work all too well, so you should probably refrain from such assumptions
As of now LFS is not a multithreaded / multi-core-optimized application, so it will always only use one CPU core. In your case LFS was CPU limited before your GFX card upgrade and still is now, hence no fps improvement.
Apparently you don't know how CPUs work all too well, so you should probably refrain from such assumptions
As of now LFS is not a multithreaded / multi-core-optimized application, so it will always only use one CPU core. In your case LFS was CPU limited before your GFX card upgrade and still is now, hence no fps improvement.
Last edited by AndroidXP, .
Duuuuh, I was thinking of the wrong thing :dunce:
I completely forgot there is a hotlap analyser and confused it with the LFSW hotlap validation.
I completely forgot there is a hotlap analyser and confused it with the LFSW hotlap validation.
FGED GREDG RDFGDR GSFDG