Yes, now that we made the decision to sell S3 licenses, there is no reason to hold back tracks because of tyre physics. The quicker we can get a track out there, the better, as the S3 license upgrade will look like twice as good value. But it will take a while as Eric is working to a high detail level as you can see in Westhill and Rockingham.
Originally the tyre physics delays held up some things, and still holds up the Scirocco. As most people know - and this has never changed - tyre physics was and still is the reason for the delay in the Scirocco.
The tyre physics update is the best thing that can happen to LFS on the code side. On the content side, new tracks are the best thing.
It will also allow us to simulate more different types of vehicles because the tyre model should scale correctly from small tyres to large tyres. There are so many possibilities from having a better tyre model, not only that it feels better and more fun to drive as you put the power on coming out of a bend and so on. A physics model based on real physical principles that produce the mathematical functions that produce the slip curves and the way of combining lateral and longitudinal forces (they aren't 'combined' as such, they just come out of the model naturally).
And no, I'm not going into details now. Right now I'm trying to get this quick update out of the way. And as I said then I'm working on functions for Eric and at last I'll be back on the tyre physics. If there's something interesting to say about it in a few months, then perhaps I will.
I noticed that my previous post could be misread, so I just want to make it clear there will be no tyre physics updates in the coming patch.
1) Test patch in a few days with crash fix, a few small lesson editor fixes, possibly an MPR smoothing.
2) Not going to get into a massive patching session. I've just come off one. Just release the full version with a few minor updates.
3) Do some editor functions that Eric has asked for.
4) Work on tyre physics.
The only way to provide a truly customised version of LFS is through InSim.
However, if you want to try to allow the user to do a few things through text commands assigned to wheel buttons, you will need commands like:
The text commands are documented in the commands.txt file in your docs folder.
You can assign text commands to wheel buttons in Options - Controls screen in the CTRL+ and ALT+ sections.
Also you can assign multiple text commands to a single button press by using a script. The script is simply a list of LFS commands, saved in the data\script folder. You can run a script with the command /run filename and that is the text you would assign to the wheel button.
I didn't want to get into a new full version at this point, but a crash bug is enough to change my plans. We can't leave a crash bug out there in the official version. So I'd like to do a few small fixes and improvements to make it more worthwhile. I won't be getting into any monster graphical updates now, as that has far lower priority than the tyre physics which I must get back onto without delay, after doing some editor functions to help Eric with the track he is working on.
One way is to have an external program connected to Live for Speed through InSim. Wheel buttons can be assigned to /i messages that will be sent out through InSim, so now the external program knows when you press any wheel button.
The InSim program can then display options on the screen, that might be tracks or cars to select, and the user can select the appropriate option by pressing wheel buttons.
I have managed to reproduce it using vitaly's method. Thank you for this report and reproduction. It's a bit mysterious, something to do with accessing memory after it was freed. But I'll track it down as top priority.
EDIT: Now I know the cause of it.
EDIT2: It seems to me this bug is not new, and has been there ever since shadows could be cast on layout objects, I think when the concrete objects were introduced.
EDIT3: Now I've found a seemingly more reliable way to get the crash, and in this case it takes place in the new code that selects the correct draw lists depending on your height above ground. In this method, you do not wait for the car to go out of physics. Just use in car view and pause the game before entering SHIFT+U mode. Then delete the object the car is sitting on. You should get a crash when you exit SHIFT+U mode.
EDIT4: Fixed in my version. There are a few quick things on my list that have come up so there should be a test patch out sooner than expected.
Thank you all for the feedback and thanks sinanju for your version of the instructions.
I'd say better not put it on the wiki yet, as I'm going to make a few improvements in the editor. It's half term week here and I've just finished a big push, so I'm not getting stuck into serious work, but can do some simple updates.
Of course I want to make things easier to use and remove any pointless restrictions, if possible, as discussed.
Are there any completely different lesson types that should be added? Or types of lesson that would be good but the current modes do not support?
There was previously a handbrake on all the single seater cars in LFS. But there are no handbrakes on single seaters in reality. Some people were using the handbrake to gain an advantage in some places while hotlapping. This forces other people to use the same unrealistic trick to remain competitive and there was a request on the test patch thread to remove this exploit while we were on some other hotlapping improvements.
Please can you give me a step by step explanation how to reproduce this, or a layout?
Also, if it did crash, do you have the crash address? In case it's hard to reproduce...
If LFS really crashes, this is very bad and we need to release a new full version without delay.
My failed attempt to reproduce a crash - I put a start point on a high piece of concrete, restarted the race to put the car up there, switched off the engine so it goes out of physics, went back into the editor, removed the concrete, exited the editor, car goes back into physics and falls to the ground as expected.
For a start, make sure you have enabled the post processing shader in Misc options.
The different examples in the psh file are mostly commented out, and you can see this because their line starts with a double slash.
// This line is a comment and is ignored by the compiler
// Comments are also used to make code inactive
So, if you wanted to try the gamma example, you should add // to comment out the currently active section of code, remove the // on the gamma line of code, save the file then type /rsh in LFS. Watch out for any error messages or warnings that will appear as messages at the top left of the screen.
First of all I see I made a mistake with the folder name. It's actually data\training and not data\lesson. So I've edited the first post with that correction. Hopefully that should solve the problem you found and you should see those files, ready to load.
I see what you mean that my description could be quite confusing. I've changed the "How a training lesson is constructed" section to be more informative.
It's interesting the way you have written your version, in a step by step way that is probably easier to understand. Anyway for now at least I have added a bit more info. I know it needs more, like a description of the format for the text file.
About your last question, yes, if you loaded the layout and image file into your lesson, then when you click "save" at the bottom of the screen, the saved file is a .lsn file, representing the lesson itself and that would be something you could add to the list.
As many of you know, we released our simple training lesson editor in the 0.6K update. This is obviously not expected to have mass appeal, but some people would like to use it. We have recently had a technical support query from someone who wants to use it for educational purposes. They want to be able to edit lessons but don't know where to start.
I decided this afternoon to have a go at writing a short description / instruction manual for it. I don't want to go into great detail with it but thought it might point people in the right direction.
I thought I'd just attach it here, in case anyone with a vague interest could let me know if it reads OK or if any of it is unclear, before we send it out.
Last edited by Scawen, .
Reason : corrected mistake - the folder is data\training not data\lesson - also more corrections
It is ok to select the 59 option. It's some wierd Microsoft thing. A slightly odd solution to a genuine slight issue. I can't remember the details but you can google it. Something to do with 59.9 Hz or something (?). Anyway if you select that I think you'll see 60 FPS in game (if you enable vertical sync).
I suppose it's to avoid intersecting physics objects that fly apart madly when touched. That problem doesn't really apply to unmovable objects. But then the question is, why would you want ordinary objects to intersect?