I think Scawen should reprogram the temp gauge to not show FPS but the CPU/GFX card temp instead 
Progress:
Hard to express, but if you take the last two digits of PI that gives you the completion percentage.
Release:
Some time after it's done.
Hard to express, but if you take the last two digits of PI that gives you the completion percentage.
Release:
Some time after it's done.
No, because LFS uses the underlying hardware configuration as a key to it's locking algorithm. You shouldn't be playing at school anyway 
Maybe you just screwed up when extracting/installing LFS? LFS itself definitely does NOT put anything on the desktop.
E: After seeing your picture, you definitely did screw up *sigh*
http://en.lfsmanual.net/wiki/Introduction#Installation
E: After seeing your picture, you definitely did screw up *sigh*
http://en.lfsmanual.net/wiki/Introduction#Installation
Sheesh, you're a trainwreck.
Huh? Why do you have anything on the desktop? LFS doesn't care what's on your desktop, you of course have to put it in the <LFS>\data\dds folder.
Haha, "Scawen is probably on it." Yeah sure. The good old times 
Dunno about Copenhagen, but I can warmly recommend Amsterdam if you're willing to travel a bit farther (but I'm not saying to skip Copenhagen 
). If you do, you should plan staying for the whole weekend, though, to get a chance to see its night life. Was there for a week about a month ago; it's a truly beautiful city with an astonishing amount of equally beautiful women. And bicycles. Lots and lots of bicycles. Ever seen a parking garage full of bicycles? Look no farther than in front of the Centraal Station.
). If you do, you should plan staying for the whole weekend, though, to get a chance to see its night life. Was there for a week about a month ago; it's a truly beautiful city with an astonishing amount of equally beautiful women. And bicycles. Lots and lots of bicycles. Ever seen a parking garage full of bicycles? Look no farther than in front of the Centraal Station.So, decreasing the coding efficiency by about a factor of 10 you call a 'solution'? 
(I still use that minimalistic notepad kind of approach for HTML and JavaScript coding, though. And I agree that everyone should start learning coding in such a minimalist environment, so they can learn the concept of programming and thinking ahead without being distracted by fancy tools.)
Would it really be worth totally overthrowing one of the fundamental concepts (functions cannot exist outside of a class) just to get rid of abstract classes with static methods? I guess what it comes down to is what you're used to - at least for me it's not in the slightest counter intuitive. Surely, if you take "object oriented" literally and say that every object must be instantiable (or even comparable to a real world object) then you might be annoyed by "shoehorning common functions into an abstract class", but in respect to what is technically/conceptually possible, the only alternative would be a MathFunctionCollection that you'd have to instantiate every time and then call a method of that, which would be rubbish.
Actually I don't even remember why I even started this argument, as in real world usage that's really a non-issue. Seems more like an argument for the sake of arguing to me now
(I still use that minimalistic notepad kind of approach for HTML and JavaScript coding, though. And I agree that everyone should start learning coding in such a minimalist environment, so they can learn the concept of programming and thinking ahead without being distracted by fancy tools.)
Would it really be worth totally overthrowing one of the fundamental concepts (functions cannot exist outside of a class) just to get rid of abstract classes with static methods? I guess what it comes down to is what you're used to - at least for me it's not in the slightest counter intuitive. Surely, if you take "object oriented" literally and say that every object must be instantiable (or even comparable to a real world object) then you might be annoyed by "shoehorning common functions into an abstract class", but in respect to what is technically/conceptually possible, the only alternative would be a MathFunctionCollection that you'd have to instantiate every time and then call a method of that, which would be rubbish.
Actually I don't even remember why I even started this argument, as in real world usage that's really a non-issue. Seems more like an argument for the sake of arguing to me now
Nothing has changed, try again next year.
Oh I definitely agree that there must be some compromises to ensure a certain playability, but specifically the F11 options were recently reduced quite a lot to only give full blown race cars the benefits of live adjustments. Adding a (unrealistic) live brake strength adjustment just to make the life of driver-swapping teams easier would be kind of hypocritical in that aspect, wouldn't it?
You're wrong, then
Because I say so
But maybe my perspective is just different on this. I'm working on a web based business application with several 100k lines of code, uncountably many business rules and on average five other programmers who work on the same code. I'd rather have everything nicely grouped together than the intellisense exploding with tons of entries because someone needed a math function in one line of code of a business object that is a few thousand lines big. Having all the BO's functions in there is bad enough (though partial classes do help).
Because I say so
But maybe my perspective is just different on this. I'm working on a web based business application with several 100k lines of code, uncountably many business rules and on average five other programmers who work on the same code. I'd rather have everything nicely grouped together than the intellisense exploding with tons of entries because someone needed a math function in one line of code of a business object that is a few thousand lines big. Having all the BO's functions in there is bad enough (though partial classes do help).
Last edited by AndroidXP, .
Well, duh. That's right, but, aren't there much more glaring non-represented differences between the UF1 and BF1 other than how the brake pedal feels? You're still sitting in front of a monitor looking at a moving 2D picture pretending to be a race driver; I reckon simulating the different brake pedal feelings is kinda over the top.
Never heard of a thread wandering off topic?
It went from "F11 brake strength adjustment, discuss" to "Is that even realistic/technically possible?" to "Would real race drivers even need that?" to "No, because brake strength IRL is pressure dependant anyway" to further discussion about that.
Personally I don't want the brakes strength to be adjustable in the F11 menu. Mainly because it would add another unrealistic element (while we should actually try to get rid of these) and it would make people write scripts that adjust the brake strength for each corner, which I don't like.
It went from "F11 brake strength adjustment, discuss" to "Is that even realistic/technically possible?" to "Would real race drivers even need that?" to "No, because brake strength IRL is pressure dependant anyway" to further discussion about that.
Personally I don't want the brakes strength to be adjustable in the F11 menu. Mainly because it would add another unrealistic element (while we should actually try to get rid of these) and it would make people write scripts that adjust the brake strength for each corner, which I don't like.
Last edited by AndroidXP, .
^ I don't see the problem? Have one weak outer spring that holds the pedal up, but doesn't touch the load cell and one strong inner spring or rubber block (from the nixim pedal mod, for example) that touches the load cell after a few cm of dead travel. Or anything similarly simple, for that matter. You'd only need force feedback if you want to simulate ABS or brake failure.
That's why it's an abstract class containing static methods 
Tbh, I don't see what's bad about this. Sure you can't instantiate "Math", but it serves as a nice way to group common methods together. Would you rather import a certain package/namespace and suddenly have all those functions directly available?
Tbh, I don't see what's bad about this. Sure you can't instantiate "Math", but it serves as a nice way to group common methods together. Would you rather import a certain package/namespace and suddenly have all those functions directly available?
RallyX is a completely different beast, because the clutch is subjected to extra stress by the jumps. What you'd have to do is to lift off while you're airborne, to make sure the clutch doesn't die when you ram back into the ground with fast spinning wheels that suddenly have grip again. The flat shifting itself should actually be less of a problem, since the traction is all around lower compared to a road race, which means you'll actually spin the tyres more than slipping the clutch.
^ Yep, what he said. A two hour race on Blackwood is about 75 laps, but the XFG has the fuel capacity for about 90 laps. A no-stop strategy would be possible if you can make the tyres last - I'd take about 85% fuel for that.
To determine what pit/fuel strategy is best, you have to first assess what a pitstop costs you (how much time you lose compared to a normal lap). Then you have to find out (by lots of testing) how much faster you actually are with a lower fuel load and not having to be as careful with the tyres. Then the question basically looks like "am I faster with 80% fuel and careful driving, or two times 40% fuel + time lost at a pitstop?"
You also have to consider that a pitstop generally breaks the flow / your concentration and is a risk in itself, as you could get a drive-through if you're not careful enough. Additionally to that, if you drive a no-stopper at 98% of race pace to preserve the tyres you'll most likely have less accidents compared to driving at 102% at a one-stopper, where you're always pressured to be as fast as possible to make up for the time lost at the pitstop. As a bonus, usually not trying to drive fast makes you end up with faster laptimes than when actively pushing it
To determine what pit/fuel strategy is best, you have to first assess what a pitstop costs you (how much time you lose compared to a normal lap). Then you have to find out (by lots of testing) how much faster you actually are with a lower fuel load and not having to be as careful with the tyres. Then the question basically looks like "am I faster with 80% fuel and careful driving, or two times 40% fuel + time lost at a pitstop?"
You also have to consider that a pitstop generally breaks the flow / your concentration and is a risk in itself, as you could get a drive-through if you're not careful enough. Additionally to that, if you drive a no-stopper at 98% of race pace to preserve the tyres you'll most likely have less accidents compared to driving at 102% at a one-stopper, where you're always pressured to be as fast as possible to make up for the time lost at the pitstop. As a bonus, usually not trying to drive fast makes you end up with faster laptimes than when actively pushing it
After one lap? I have to see this. Your shifting technique must suck in ways never seen before. Not even autoclutch does this, though maybe you can somehow achieve it by using the button clutch on the lowest button rate.
Seriously, the clutch heating does a rather bad job at preventing flat shifting. In a typical road race clutch heat is no factor at all, unless you do it to the extreme like zeug described.
Seriously, the clutch heating does a rather bad job at preventing flat shifting. In a typical road race clutch heat is no factor at all, unless you do it to the extreme like zeug described.
Flat shifting = you're not lifting the throttle during a shift = you're longer on the throttle during acceleration = slightly faster acceleration.
However, there are also negative points:
However, there are also negative points:
- the clutch gets less effective and dies after prolonged use of this technique
- the driven wheels get a quick jolt every time you do this, which might not be the best idea regarding cornering stability (though it has to be said, the demo cars are generally not powerful enough to get you in big trouble)
Yes and no. Brake fluid almost doesn't compress at all. With your foot you are basically directly pressing against the brake discs (once pad and disc touch).
However, to make it possible for you to brake at all, there's both mechanical and hydraulic force multiplication/leverage going on, not to forget the vacuum driven power assist which removes a lot of the braking effort, too. All this results in a pretty high power multiplication, but the (for us preferable) tradeoff is that you have to push the pedal much further to move the brake pad a tiny bit. If we for example have a power multiplication of 1:36, pushing the pedal with 10kg will push at the pads with 360kg, however to move the brake pad 1mm we'd have to move the brake pedal 3.6cm. It might seem like the pedal position has anything to do with how strong you brake, but this is only indirectly true and only when applying relatively weak braking forces. At some point there's simply no place in the brake system that could move away a little and the brake strength becomes clearly purely pressure dependant.
However, to make it possible for you to brake at all, there's both mechanical and hydraulic force multiplication/leverage going on, not to forget the vacuum driven power assist which removes a lot of the braking effort, too. All this results in a pretty high power multiplication, but the (for us preferable) tradeoff is that you have to push the pedal much further to move the brake pad a tiny bit. If we for example have a power multiplication of 1:36, pushing the pedal with 10kg will push at the pads with 360kg, however to move the brake pad 1mm we'd have to move the brake pedal 3.6cm. It might seem like the pedal position has anything to do with how strong you brake, but this is only indirectly true and only when applying relatively weak braking forces. At some point there's simply no place in the brake system that could move away a little and the brake strength becomes clearly purely pressure dependant.
Nothing? You cannot tune or alter the engine's output in any way ingame.
There are things like LFS Tweak that allow you to alter some of the car specs from outside of the game, but this is only for messing around offline.
There are things like LFS Tweak that allow you to alter some of the car specs from outside of the game, but this is only for messing around offline.
I think the main problem right now is the tyres - more specifically the poor modelling of their life cycle. At the moment, the rubber has only one and a half factors affecting it: heat and to a minor extent wear. With that I mean the only thing you have to watch out for is to not overheat the tyres and to change them before they pop due to wearing completely down.
You cannot ruin your tyres by overheating (you just lose time until they cool back down, then they're in perfect condition again) or overexerting them (no graining or tyre failure due to for example taking a curb in a bad way), you cannot flatspot them (technically you can, but even extreme flatspots have a minimal effect on performance) and the wear has no effect on the tyre whatsoever, other than making it cool down faster and weigh less, which means the more worn the tyre, the better. If anything, the wear should at least affect the relative camber of the tyre surface, making them work less well when the surface gets "equalized" to the ground.
Besides that, the R1 to R4 compounds are completely made up and not modelled after real tyres at all, and while that isn't necessarily a bad thing by itself, their current behaviour is limiting the compound choice pretty severely. It was a good step to alter the tyre heating behaviour and make the softest compound not automatically the one you'll choose for a race, but the general tyre strategy is still pretty much to take the softest compound you can get away with not overheating completely during the race.
The point is, tyres aren't modelled well enough yet to make the way you use them and the choice of compound realistic. Of course criticising is much easier than fixing, especially when things are done in the LFS way of modelling components and behaviours abstractly and just letting realism happen as you put the parts together.
LFS is at this point a brilliant simulator of vehicle dynamics, but when everything comes together it does not resemble the characteristics of real life racing all that accurately. I'm not sure if it ever will, either, but at least it has set a respectable landmark in sim racing.
[/
]
You cannot ruin your tyres by overheating (you just lose time until they cool back down, then they're in perfect condition again) or overexerting them (no graining or tyre failure due to for example taking a curb in a bad way), you cannot flatspot them (technically you can, but even extreme flatspots have a minimal effect on performance) and the wear has no effect on the tyre whatsoever, other than making it cool down faster and weigh less, which means the more worn the tyre, the better. If anything, the wear should at least affect the relative camber of the tyre surface, making them work less well when the surface gets "equalized" to the ground.
Besides that, the R1 to R4 compounds are completely made up and not modelled after real tyres at all, and while that isn't necessarily a bad thing by itself, their current behaviour is limiting the compound choice pretty severely. It was a good step to alter the tyre heating behaviour and make the softest compound not automatically the one you'll choose for a race, but the general tyre strategy is still pretty much to take the softest compound you can get away with not overheating completely during the race.
The point is, tyres aren't modelled well enough yet to make the way you use them and the choice of compound realistic. Of course criticising is much easier than fixing, especially when things are done in the LFS way of modelling components and behaviours abstractly and just letting realism happen as you put the parts together.
LFS is at this point a brilliant simulator of vehicle dynamics, but when everything comes together it does not resemble the characteristics of real life racing all that accurately. I'm not sure if it ever will, either, but at least it has set a respectable landmark in sim racing.
[/
]Well, the meaning of my post got kinda lost. What the heck are "shifting arms"?
This would be better:
If you have a G25 you only can only shift in the mode that the car's gearbox supports. That means in normal road cars you may use the shifter in H-gate mode, but for most racing cars you have to use the sequential mode or the paddles.
This would be better:
If you have a G25 you only can only shift in the mode that the car's gearbox supports. That means in normal road cars you may use the shifter in H-gate mode, but for most racing cars you have to use the sequential mode or the paddles.
FGED GREDG RDFGDR GSFDG