You are welcome to use the button to report the post if someone makes an offensive comment. Do you think I read every post in minute detail? Maybe, I am very busy so I have to read over things quite quickly, even if I am following a thread, and might not have time to analyse every word.
On the other hand, I suppose if someone came to the forum every few days and wrote repeated posts about how bad the people of a certain nation are, it would get noticed. Especially if this went on for many years.
The person we are now talking about has been extremely negative, toxic and unpleasant for a very long time. I don't know why someone like that keeps coming back. I'd be happy if he stayed away for good. But something tells me to always be very tolerant and give tiny short bans even when long ones seem deserved.
It's pretty hard doing this job when under attack so often. Also, I could do something else. I do this job for the community members. So it's actually quite upsetting to hear constant anger from bitter members who really have no idea what they are talking about or what is involved.
When have I said that? I've never said that.
A full time occupation, working 10 to 12 hours most days, is more than a hobby, I think.
Unless you have a different meaning of hobby?
I have said, I like working on it. Maybe you interpret that as meaning it's a hobby and not a job?
To be clear to others reading:
You submitted a street car (because of course, there aren't enough bimmers and bimmys and bavarias on the system already). Then from what I can see you changed it to a racing car, then later back to a street car, and then later back to a racing car.
Maybe if you were paying a monthly subscription for mod usage, we could hire a team of people whose sole job is to manage the mods system. But we are running a system that is free to use and it is supported by a few volunteers who are trying to make it good for everyone.
We don't have the manpower to constantly monitor your tricks and buy ever more servers to keep hundreds of versions of mods on.
Mods saved our business from total collapse, but now it's becoming a massive drain on my development time. I've spent nearly the whole of January dealing with mods (not to mention most of 2021 and 2023 as well).
You submitted a street car (because of course, there aren't enough bimmers and bimmys and bavarias on the system already). Then from what I can see you changed it to a racing car, then later back to a street car, and then later back to a racing car.
Maybe if you were paying a monthly subscription for mod usage, we could hire a team of people whose sole job is to manage the mods system. But we are running a system that is free to use and it is supported by a few volunteers who are trying to make it good for everyone.
We don't have the manpower to constantly monitor your tricks and buy ever more servers to keep hundreds of versions of mods on.
Mods saved our business from total collapse, but now it's becoming a massive drain on my development time. I've spent nearly the whole of January dealing with mods (not to mention most of 2021 and 2023 as well).
No problem, I was just interested, as I saw the frame rate hits, when a lot of cars were on screen, and also seemingly in panning shots with a few cars on screen.
I wondered if there were any problems in LFS so I built a profiler version to see what's up and I spotted a lot of CPU usage in "Draw driver" and "Draw meshes" (that includes subobjects) and "Draw wheels" (includes spoke objects) and also similar issues in the alpha pass. This particular CPU usage is not related in any way to number of polygons. Thousands of polygons may be drawn in a single draw call, which is also the same for one single triangle. LFS does a good job of combining all triangles of a single material, into a single draw call. No matter how many cutouts you use, they will still be combined together if they are using a single material and in a single object.
This heavy CPU usage which is (I think, roughly) double that of an XR turbo led me to look in the model a bit, specially near subobjects and spoke objects. That's where I noticed this use of multiple textures. Also the concealed driver thing which is just one switch to fix.
When the cars are initially generated (when leaving pits) and when there is a collision, this is when the number of triangles (actually vertices) is a problem. All these vertices and triangles must be created on the CPU and then sent to the graphics card. When damage occurs, the model must be deformed and it is all sent to the graphics card again.
But for a modern graphics card, this number of vertices isn't really a problem regarding drawing the car each frame (when there is no collision). The number of materials is more of a problem, and also subobjects that are not "attachments". Each movable subobject requires a new matrix to be sent to the graphics card and of course a whole batch of draw calls for its materials (which cannot be combined with the main object's materials).
Taking the example of the steering wheel, if those textures are all used only in the steering wheel, then it is a perfect case to make a special texture for that steering wheel. I imagine those 11 (or was it 12) 128x128 textures I talked about, going onto a new texture of 512x512 and you use the 16 squares, leaving a few spare.
It is not a problem to use the same texture in two different subobjects if that is convenient, or for subobjects to share a texture with the main object. But it brings no specific benefit, other than maybe reducing the total size of textures in the whole model. That is more about what texture cutouts you can fit on what pages.
For example, I wouldn't suggest using really massive textures to try to share everything in the whole model. It can be good to use smaller textures, if that is convenient for one (or a few) subobjects. So... don't worry about different subobjects sharing a texture, that is OK, but don't go mad and try to combine everything, which would require extra big textures for no benefit.
However, "attachment" subobjects are a different case, as they don't move, they are combined with the main object. So it's a good idea to share textures with the main object (and/or other attachments) in that case.
I want to help with the materials display in the cutout editor (as described, there is a bug). I am interested to try and add a CPU display in the vehicle editor so you can see the results of your improvements.
EDIT: added image showing materials in my fixed version, that will be more helpful to see the results after you share textures.
EDIT2: added another image showing the combined list of materials, when attachments are combined with main object.
Last edited by Scawen, .
Reason : added image
I think you mean: multiple, selectable wheel styles in a single vehicle.
It's something I'd like to do eventually but it's a big job, cannot be done in a compatible version.
As I keep saying, I'm working on the development version now, not mods (which I've been working on for two years already).
EDIT: OK, apparently I'm losing track of time. Here's a rough history.
We have been working on the new graphics and physics versions for years.
2021 I spent most of the year on mods which we released that year.
2022 was a bit more on mods then back to graphics, multithreading, etc.
2023 I seemed to get pulled back onto mods for most of the year.
The end of 2023 was an unforgettable extreme push on mods so it would be much appreciated if people wouldn't keep asking for big changes to the mods system right now. I can do a few updates here and there to the editor. But my main focus is the new development version.
It's something I'd like to do eventually but it's a big job, cannot be done in a compatible version.
As I keep saying, I'm working on the development version now, not mods (which I've been working on for two years already).
EDIT: OK, apparently I'm losing track of time. Here's a rough history.
We have been working on the new graphics and physics versions for years.
2021 I spent most of the year on mods which we released that year.
2022 was a bit more on mods then back to graphics, multithreading, etc.
2023 I seemed to get pulled back onto mods for most of the year.
The end of 2023 was an unforgettable extreme push on mods so it would be much appreciated if people wouldn't keep asking for big changes to the mods system right now. I can do a few updates here and there to the editor. But my main focus is the new development version.
Last edited by Scawen, .
Well you can discuss amongst yourselves, but I am only one programmer and I think the priority is completing the new graphics and physics version. Limits were discussed and set long ago. Unfortunately, hackers learned to get around the limits. I've spent the last two years working on improvements for mods, delaying the big release that everyone wants. I worked right up to the limit of my health before the Christmas holidays, to allow me to get back to the main task.
Now I have learned half the mod creators use a hack to bypass the limits, while other people complain about glitches when people leave the pits. My job is to make sure that doesn't happen, then get back to what I am supposed to be working on. The game is supposed to run smoothly and that is the most important thing.
I'm not going to drop what I am working on to continue working on more updates for mods. I hope you understand.
Now I have learned half the mod creators use a hack to bypass the limits, while other people complain about glitches when people leave the pits. My job is to make sure that doesn't happen, then get back to what I am supposed to be working on. The game is supposed to run smoothly and that is the most important thing.
I'm not going to drop what I am working on to continue working on more updates for mods. I hope you understand.
I prefer it if you don't tell me how to do my job. Nothing here is meaningless and I update because it is extremely important to check these changes thoroughly in the last few days before a massive update.
If you don't want to be involved in testing, don't download the test patch in the first place.
And when were you forced to update? Your whole post is rubbish.
If you don't want to be involved in testing, don't download the test patch in the first place.
And when were you forced to update? Your whole post is rubbish.
Last edited by Scawen, .
I'm not certain that's the best idea. You could add a /echo command after the command that sets the lights. Would that do the job?
EDIT: OK that won't really work with /light head next but could work with /light head high
For example an F key bind (now that more than one command is allowed on a single line) could be:
/light head high /echo high beam
EDIT: OK that won't really work with /light head next but could work with /light head high
For example an F key bind (now that more than one command is allowed on a single line) could be:
/light head high /echo high beam
I understand why you chose to use unrealistic settings before, even if I don't agree with that approach.
To make a good mod in the proper way, the thing is to get as accurate values and settings as possible. If there are physical problems it's really my job to sort that out by improving the physics model. I do understand slight tweaks to mods to deal with imperfect physics.
But the mod still has massive downforce now, even after the steering model changes. Speaking as a mod user (not as a developer) I'd like to explain that makes me simply not want to use the mod at all. No bike in the world has F1-style downforce, as it's impossible. In my opinion the undertray should be deleted, the downforce set to zero and then work on the bike's geometry, mass, weight distribution, suspension, drag, etc. to make it as near to a real 600 as possible, then it will be a fun mod to use.
To make a good mod in the proper way, the thing is to get as accurate values and settings as possible. If there are physical problems it's really my job to sort that out by improving the physics model. I do understand slight tweaks to mods to deal with imperfect physics.
But the mod still has massive downforce now, even after the steering model changes. Speaking as a mod user (not as a developer) I'd like to explain that makes me simply not want to use the mod at all. No bike in the world has F1-style downforce, as it's impossible. In my opinion the undertray should be deleted, the downforce set to zero and then work on the bike's geometry, mass, weight distribution, suspension, drag, etc. to make it as near to a real 600 as possible, then it will be a fun mod to use.
It would be very hard and far beyond the scope of this test patch to make the AI generation work in a separate thread so it doesn't hang between updates while it iterates the path improvements. You should generate offline (and outside of VR) any AI paths you want to use. Maybe you could use a separate LFS instance.
About the speed of AI, it's not your fault but I'm getting a bit tired of explaining so many times, the AI's driving ability (handling of one car, nothing to do with the overtaking) is all specific to the tyre model in question and has already been improved to some extent in the development version, but I will not be working on that for the public version, as it would be pure wasted time.
Nothing about their speed has got worse in the test patches, as I haven't worked on that. But you could verify by starting an earlier exe, run a single AI and see if the lap times are the same. That's your job as a tester really.
I assert that their lone car driving ability is not changed. You are welcome to prove me wrong.
About the speed of AI, it's not your fault but I'm getting a bit tired of explaining so many times, the AI's driving ability (handling of one car, nothing to do with the overtaking) is all specific to the tyre model in question and has already been improved to some extent in the development version, but I will not be working on that for the public version, as it would be pure wasted time.
Nothing about their speed has got worse in the test patches, as I haven't worked on that. But you could verify by starting an earlier exe, run a single AI and see if the lap times are the same. That's your job as a tester really.
I assert that their lone car driving ability is not changed. You are welcome to prove me wrong.I see, that is a very clever and useful feature. It looks like Daniel did a great job with it. I wish a version of Lazy was available, without the "hack" stuff (that needed to be updated with each version version of LFS) and only the InSim features (that usually remain compatible when LFS updates).
To track the lap and store it in a new data format, do the comparisons and save and load that data at the right times, it's a pretty complicated task. It's good that I have looked at it, I should have another read of Mandula's very good post. It needs time to sink in though.
I can see how such a feature would be good (and most useful) to support natively, but also could make the point that this is the reason for InSim, so other programmers can do this stuff so I can focus on the core.
To track the lap and store it in a new data format, do the comparisons and save and load that data at the right times, it's a pretty complicated task. It's good that I have looked at it, I should have another read of Mandula's very good post. It needs time to sink in though.
I can see how such a feature would be good (and most useful) to support natively, but also could make the point that this is the reason for InSim, so other programmers can do this stuff so I can focus on the core.
I've been thinking for a few minutes about this, for example what would happen if I simply enabled a background texture for s_clock_formula / s_clock_f1 / s_clock_f3 / s_clock_fbm (or some of them).
The thing is these clock textures are very hard coded, without adjustment. So I think a proper job for these clocks would be to provide adjustment sliders and many other forms of customisation. And that is what I really can't do at this time.
But... in theory it could be easy to enable a background texture for at least some of them. I'm not sure how much use you could make of it, with these current non-adjustable versions of the textures.
But maybe it's more useful than I think. Do let me know, please.
LFS should be able to do a good job of assigning groups when loading a obj. I know because I wrote a big function to do it!
It depends on the vertices not being fused. From a quick glance in the code I can't get my head round it entirely, but is it that normals have to be exported? So that the vertices in the different smoothing groups refer to different normals?
LFS doesn't use smoothing groups as defined in the obj specification, so there is no point saving them in the obj.
I think it should be possible to do the export in such a way that LFS gets all the smoothing groups right.
This is not to say that turbofan's suggested function couldn't be useful, but hopefully is not necessary in this case if the export is done in the right way that LFS can work out the groups automatically. Certainly it should work fine for Blender exports, but if it's not possible in exports from other software I'd like to know about it.
EDIT: I thought there was something in the LFS manual about it but I can't see it in a quick search. Anyway here's a few tips for Blender. https://youtu.be/Rf6HK_niFjo?t=66
It depends on the vertices not being fused. From a quick glance in the code I can't get my head round it entirely, but is it that normals have to be exported? So that the vertices in the different smoothing groups refer to different normals?
LFS doesn't use smoothing groups as defined in the obj specification, so there is no point saving them in the obj.
I think it should be possible to do the export in such a way that LFS gets all the smoothing groups right.
This is not to say that turbofan's suggested function couldn't be useful, but hopefully is not necessary in this case if the export is done in the right way that LFS can work out the groups automatically. Certainly it should work fine for Blender exports, but if it's not possible in exports from other software I'd like to know about it.
EDIT: I thought there was something in the LFS manual about it but I can't see it in a quick search. Anyway here's a few tips for Blender. https://youtu.be/Rf6HK_niFjo?t=66
Last edited by Scawen, .
I had fun, thanks!
I did hold it together for the first race so I'm happy with that. After a start grid incident I found myself at the back of the field in 16th position. I gradually worked up a bit to finish 9th. Related to energy saving, I managed to catch up and pass Zdravko Topolnjak near the end of the final lap, but ran out of energy on the final bend so he passed me again. This was quite exciting.
My second race was a bit out of control. I think I struggled with the extra power, which I had opted for in that race but as my car was faster than usual at the high speed bend, I think that was the cause of a few wall hits that made the car handle badly. Eventually when we could select dry tyres, I opted to fix the car which took a long time, only to immediately hit the same wall again! After another driver's incident caused a safety car I was allowed to pass the safety car and raced around the track to catch the back of the field. Lack of experience showed when I came across the slow moving cars on lap 19 and crashed right into the back of Jared Meade, knocking his car into the air. Sorry about that! That was again at the famous high speed corner. After the restart there wasn't long to go and on lap 20 I hit the armco at the high speed corner, this time knocked myself right out of the course and had to find my way back in to the circuit to finish the race. Is that legal?
So... that fast corner caused a lot of trouble for me but as I say, the first race felt in control and consequently more fun. I don't think I deserve any congratulations at all for the second race.
I would like to congratulate the other drivers, especially the top three: Gábor Gyüre, Imran Azhar and Niko Puntola though I have to say there were a lot of really good drivers there. It's amazing to see.
The replicas of the real tracks are so well done by Michal Málek, within the limits of the layout editor. The organisation and running the races by Master Race Car in conjunction with New Dimension Racing is incredibly professional. Finally the coverage by Sim Broadcasts is so well done and entertaining, what can I say but well done everyone, amazing job.
It's quite humbling to experience such fine work using this old simulator and I am extra inspired to get done what needs to be done, to bring the latest updates to you.
Nearly my finest moment:
Definitely not my finest moment:
I did hold it together for the first race so I'm happy with that. After a start grid incident I found myself at the back of the field in 16th position. I gradually worked up a bit to finish 9th. Related to energy saving, I managed to catch up and pass Zdravko Topolnjak near the end of the final lap, but ran out of energy on the final bend so he passed me again. This was quite exciting.
My second race was a bit out of control. I think I struggled with the extra power, which I had opted for in that race but as my car was faster than usual at the high speed bend, I think that was the cause of a few wall hits that made the car handle badly. Eventually when we could select dry tyres, I opted to fix the car which took a long time, only to immediately hit the same wall again! After another driver's incident caused a safety car I was allowed to pass the safety car and raced around the track to catch the back of the field. Lack of experience showed when I came across the slow moving cars on lap 19 and crashed right into the back of Jared Meade, knocking his car into the air. Sorry about that! That was again at the famous high speed corner. After the restart there wasn't long to go and on lap 20 I hit the armco at the high speed corner, this time knocked myself right out of the course and had to find my way back in to the circuit to finish the race. Is that legal?
So... that fast corner caused a lot of trouble for me but as I say, the first race felt in control and consequently more fun. I don't think I deserve any congratulations at all for the second race.
I would like to congratulate the other drivers, especially the top three: Gábor Gyüre, Imran Azhar and Niko Puntola though I have to say there were a lot of really good drivers there. It's amazing to see.
The replicas of the real tracks are so well done by Michal Málek, within the limits of the layout editor. The organisation and running the races by Master Race Car in conjunction with New Dimension Racing is incredibly professional. Finally the coverage by Sim Broadcasts is so well done and entertaining, what can I say but well done everyone, amazing job.
It's quite humbling to experience such fine work using this old simulator and I am extra inspired to get done what needs to be done, to bring the latest updates to you.
Nearly my finest moment:
Definitely not my finest moment:
Last edited by Scawen, .
About laps remaining / fuel usage per lap display, see the attachment for a mockup. Probably just grey on transparency like the other displays (not green on pure black). I'm asking more about the layout and information format.
Would this do the job? I'm not sure about "1L" and "AV". My intention is to replace the @ symbol with either a fuel tank or battery.
But some of you are good graphics designers so please let me know if you have a better idea.
EDIT: There are pictures of a first version actually implemented a few posts later.
Note that 48.6L (laps remaining) is already shown on the steering wheel (but not in all cars).
Would this do the job? I'm not sure about "1L" and "AV". My intention is to replace the @ symbol with either a fuel tank or battery.
But some of you are good graphics designers so please let me know if you have a better idea.
EDIT: There are pictures of a first version actually implemented a few posts later.
Note that 48.6L (laps remaining) is already shown on the steering wheel (but not in all cars).
Last edited by Scawen, .
Something Eric asked me about recently, combined with another thing I noticed regarding the E-challenge, makes me want to do a quick update.
Eric's suggestion is a keypress to cycle the F9 to F12 status screens.
My answer is something like a /status command.
How about:
/status [none/F9/F10/F11/F12/next/prev]
So for Eric's request you would assign to an F key (and wheel button) the following text command:
/status next
How it relates to E-Challenge: on this thread there are some scripts designed to make it easy to set pit instructions to change tyres, when conditions change to wet or dry.
But it is possible for these scripts to go wrong if you aren't careful as they rely on the starting conditions being correct. This is because they use left and right arrow key presses, which change things (e.g. tyres) relative to the current value.
They go into or out of the status screens with commands like /press F12 (which also has the problem that F12 is a toggle, so if you are already in that screen you would exit the screen instead of entering it.
So I was thinking this could be better if there were some very positive commands that don't rely on the current setting.
I was thinking of a command /pitreq, that could work like this:
/pitreq ftyre R2
/pitreq repair yes
/pitreq cancel
/pitreq rcamber -2
I hope you get the idea and I just thought I'd put that out there as I hope to do a quick job on it, and maybe someone thinks of something I haven't thought of.
I think the following /pitreq options are needed, though it's not fully considered yet.
fuel
tyrechange
repair
symmetric
ftyre
fcamber_l (aka fcamber if symmetrical)
fpressure_l (aka fpressure if symmetrical)
fcamber_r
fpressure_r
fwing
rtyre
rcamber_l (aka rcamber if symmetrical)
rpressure_l (aka rpressure if symmetrical)
rcamber_r
rpressure_r
rwing
Eric's suggestion is a keypress to cycle the F9 to F12 status screens.
My answer is something like a /status command.
How about:
/status [none/F9/F10/F11/F12/next/prev]
So for Eric's request you would assign to an F key (and wheel button) the following text command:
/status next
How it relates to E-Challenge: on this thread there are some scripts designed to make it easy to set pit instructions to change tyres, when conditions change to wet or dry.
But it is possible for these scripts to go wrong if you aren't careful as they rely on the starting conditions being correct. This is because they use left and right arrow key presses, which change things (e.g. tyres) relative to the current value.
They go into or out of the status screens with commands like /press F12 (which also has the problem that F12 is a toggle, so if you are already in that screen you would exit the screen instead of entering it.
So I was thinking this could be better if there were some very positive commands that don't rely on the current setting.
I was thinking of a command /pitreq, that could work like this:
/pitreq ftyre R2
/pitreq repair yes
/pitreq cancel
/pitreq rcamber -2
I hope you get the idea and I just thought I'd put that out there as I hope to do a quick job on it, and maybe someone thinks of something I haven't thought of.
I think the following /pitreq options are needed, though it's not fully considered yet.
fuel
tyrechange
repair
symmetric
ftyre
fcamber_l (aka fcamber if symmetrical)
fpressure_l (aka fpressure if symmetrical)
fcamber_r
fpressure_r
fwing
rtyre
rcamber_l (aka rcamber if symmetrical)
rpressure_l (aka rpressure if symmetrical)
rcamber_r
rpressure_r
rwing
Well, that explains why Discord could want my details but doesn't explain why they would threaten to pass that on to the criminal. So although I accept there may be a legal process, I suggest that this is a convenient way for Discord (and maybe other companies, too) to avoid doing that part of their job that they don't really want to do. It would only take 5 minutes to verify the illegitimacy of certain servers and close them down, but they would rather hide behind this legal process.
There is no Scavier Solutions, that's just a made-up company. I think one of the early beta testers put it on a skin for fun, or something like that.
There is no Scavier Solutions, that's just a made-up company.
I think one of the early beta testers put it on a skin for fun, or something like that. There is little that is realistic about suspension and engine damage in LFS and I don't see any benefit in trying to make the repair times realistic. Obviously not now, and probably never.
But that could be some whole philosophical debate. In my opinion the damage should be sufficient to stop you doing bad things in races that you wouldn't do in reality - that keeps the racing real, which is the point here - but it's actually "better than reality" that you can get these things fixed super fast and not be entirely knocked out of a long race for some minor error like an early downshift.
I mean, this whole philosophical debate about realism can go pretty deep, and I remember someone suggested having a job in the game to earn money to buy your car parts. Well my opinion is, if you want it that realistic, just use the real world, get a real job and go real racing. Then you can find out how much broken parts cost. To me, a game can be, in some ways, *better* than reality. Taking LFS as an example, you spend a lot more time racing and a lot less time fixing things.
At the moment, for this version, in which engine damage has finally become repairable, I don't yet see any inconsistency between the super-fast engine repair times and the super-fast suspension repair times.
But that could be some whole philosophical debate. In my opinion the damage should be sufficient to stop you doing bad things in races that you wouldn't do in reality - that keeps the racing real, which is the point here - but it's actually "better than reality" that you can get these things fixed super fast and not be entirely knocked out of a long race for some minor error like an early downshift.
I mean, this whole philosophical debate about realism can go pretty deep, and I remember someone suggested having a job in the game to earn money to buy your car parts. Well my opinion is, if you want it that realistic, just use the real world, get a real job and go real racing. Then you can find out how much broken parts cost. To me, a game can be, in some ways, *better* than reality. Taking LFS as an example, you spend a lot more time racing and a lot less time fixing things.
At the moment, for this version, in which engine damage has finally become repairable, I don't yet see any inconsistency between the super-fast engine repair times and the super-fast suspension repair times.
About an option to use or not use the name coloured arrows on servers without lap timing:
I wonder where it will be seen, other than football? Which servers don't use lap timing?
Cruise servers is one example (though I'm struggling to think of others). Degats pointed out a possible issue, but we haven't heard from anyone if they actually found it a problem or a benefit in reality.
Would be interesting to hear if people like it in cruise servers.
As you say: Maybe. I hope to hear from people what they actually feel about it.
At the moment we are just talking about solutions to theoretical problems that may exist.
I see two problems with acting too fast:
1) We have not received any feedback at all about what people think about it on servers (if they actually like it or not).
2) The question of server option vs user option. Both seem as valid as each other but it's probably not a good idea to implement both, as they can conflict. Before anyone tells me, yes I know we could have server option "ON / OFF / FREE CHOICE" to avoid actual conflict between two options (or server option "ALLOW COLOURFUL ARROWS IF USER WANTS") but interaction between server option and user options is more complicated than I really want for this simple fun feature.
My job is not to dictate the answer but to assess feedback from people who are actually using it, compare this with suggestions and see what comes up.
Obviously as mentioned I like the easy solution of "no option" (as now) but still need to hear feedback from people using it. Maybe less useful at this point is thinking of options for other people whose opinions we have not yet heard and may or may not like it.
I wonder where it will be seen, other than football? Which servers don't use lap timing?
Cruise servers is one example (though I'm struggling to think of others). Degats pointed out a possible issue, but we haven't heard from anyone if they actually found it a problem or a benefit in reality.
Would be interesting to hear if people like it in cruise servers.
As you say: Maybe. I hope to hear from people what they actually feel about it.
At the moment we are just talking about solutions to theoretical problems that may exist.
I see two problems with acting too fast:
1) We have not received any feedback at all about what people think about it on servers (if they actually like it or not).
2) The question of server option vs user option. Both seem as valid as each other but it's probably not a good idea to implement both, as they can conflict. Before anyone tells me, yes I know we could have server option "ON / OFF / FREE CHOICE" to avoid actual conflict between two options (or server option "ALLOW COLOURFUL ARROWS IF USER WANTS") but interaction between server option and user options is more complicated than I really want for this simple fun feature.
My job is not to dictate the answer but to assess feedback from people who are actually using it, compare this with suggestions and see what comes up.
Obviously as mentioned I like the easy solution of "no option" (as now) but still need to hear feedback from people using it. Maybe less useful at this point is thinking of options for other people whose opinions we have not yet heard and may or may not like it.
Thanks for the feedback about engine damage. It looks like most people would like it displayed (as a number).
About the repairs, and options for servers to allow it, or for users to select whether it should be done or not in pits, InSim output etc. that is massively beyond the scope of this patch. I've got far too much work to do and can't get into things that take many hours to do, even if they are good thoughts you are having.
My suggestion was that, maybe, (and I haven't even checked the code yet) a small amount of damage could result in the already existing "minor damage" time delay and a larger amount of damage could result in the already existing "major damage" time delay.
There's already a damage repair option and that would apply to engine and suspension all with the same option.
That's all I can offer at this time, no interface, no options, just an opportunity for engine damage to be fixed by the super fast mechanics while the other super fast mechanics might be working on the suspension and doing a incredible job fixing the bodywork without a trace.
About the repairs, and options for servers to allow it, or for users to select whether it should be done or not in pits, InSim output etc. that is massively beyond the scope of this patch. I've got far too much work to do and can't get into things that take many hours to do, even if they are good thoughts you are having.
My suggestion was that, maybe, (and I haven't even checked the code yet) a small amount of damage could result in the already existing "minor damage" time delay and a larger amount of damage could result in the already existing "major damage" time delay.
There's already a damage repair option and that would apply to engine and suspension all with the same option.
That's all I can offer at this time, no interface, no options, just an opportunity for engine damage to be fixed by the super fast mechanics while the other super fast mechanics might be working on the suspension and doing a incredible job fixing the bodywork without a trace.
After a longer gap than usual there are a few things to report. 
Soon after the last report, after fixing a few things that were sitting on lists, I added a new type of object that can be used in the track editor to connect up other objects more easily. Instead of the usual cross-sections connected by segments (with curves) this new system allows the simple addition of triangles. As if in the modeller, but between different cross-sections. It's hard to explain but it does simplify tasks by making it a lot easier to fill odd-shaped holes!
After my day of fixes on Fern Bay, Eric decided to have a quick go at it, really just fixes for the new lighting system. There were still some holes to fill, which are important for shadows, and he wanted to add some shine (specular effect) to the roads. He updated a few textures here and there in addition to the road surfaces but did the bare minimum of modelling. As stated before, there isn't time to bring Fern Bay up to the modern standard before the coming release, but it was certainly worth a few days tidying up.
After Eric sent me the update, I noticed a few remaining issues that I could improve with the use of new editor functions that I quickly coded. It is useful for me to spend a little time in the track editor because I often think of a few new functions or improvements to do.
Trying to get things finished can be a lengthy process! After the Fern Bay update we ended up taking on an extra task, almost by mistake. Eric wanted to update some of the layout objects which looked quite tired and old. His plan was just a few days brushing up a few objects. Quickly the task expanded and we started to make use of the new mapping configuration and monochrome colours system, that help maintain variety in the track editor, now extended to the layout objects. With a single object selected there can be several variations on the texture cutouts that are displayed. There was community involvement and we took on some of the ideas. There are definite benefits, so it was worth a week on the job. Even if that week turned out to be two weeks! We're near the end of layout updates for now!
Public thread about layout objects: https://www.lfs.net/forum/thread/101752
Eric and I have discussed the need to try to get to the release and only do what is necessary from now on. We want to do a lot of things but they can be done after the release.
On my side I have another day or two on layout functions, and there are some editor features to look at that could help Eric complete South City. Sometimes when buildings follow the edges of existing roads they can end up quite complex and bring up issues that can be made easier by certain new editor functions. I enjoy doing editor functions but of course, I am trying to get off graphics to finish the tyre physics and get to that public beta as quickly as possible.
Log of updates:
Layout marshals also needed to pick up lighting from lightmap (objects already do)
- marshals are done a different way and do a single lightmap reading when first drawn
Improved track editor function for setting height of multiple points
- also generally updated initialisation of text entry to the new style in a few places
Added a new type of surface that can be added in the track editor
- an extension of "section end triangles" but now can connect to other cross-sections
- as arbitrary triangles between track objects they can make it easier to fill holes
- turned out this is was a bit more work than expected in the track editor
- when objects can refer to others a lot of care must be taken with delete functions
Fix: track editor bug - surface properties were not updated correctly when changed
Fix: a physics surface debug display was not using the thread-safe copy of wheels
Fix: suspension diagram was also not yet updated to use thread-safe variables
Fix: time could move on up to 30 sec in track editor then car would catch up on exit
Eric sent a minor update of Fern Bay with specular lighting added to road textures
- other small updates as well including filling all the holes as seen from above
- although it's not a full update these are important fixes for the shadow system
- also improved a few textures around that needed brightening up in addition to shine
- the general effect is improved as you can see in the attached screenshots
I spotted a few remaining Fern Bay issues and went into the track editor to fix them
- changed/added editor functions that helped with searching/updating multiple objects
- a benefit of me spending time in editor is I sometimes come up with useful functions
Eric started to do a quick update on the layout objects that would take a few days
- it is not really the highest priority but seemed like a quick improvement at first
- job got a little bigger as we added support for selectable "mapping configurations"
- these, along with a colour selector, allow more variety without more object slots
- so we can have e.g. more signs or cone colours using the new improved objects
Discussion with Eric about the new world triangles hole filling system
- it can help fill holes in South City, either large holes out of town or small holes
- Eric showed me some of the challenging things at South City to finish in a good way
- looking at the real situations that come up, we thought of some helpful improvements
Worked on the updated (and new) layout objects
- asked community members if they had suggestions for a few useful objects
- some useful things came from that thread: https://www.lfs.net/forum/thread/101752
- using the new mapping configurations and monochrome colours, more variety is possible
- with a single object selected, multiple configurations can be chosen (e.g. letters)
- in the screenshot you can see most of the new objects but not showing all variations
Soon after the last report, after fixing a few things that were sitting on lists, I added a new type of object that can be used in the track editor to connect up other objects more easily. Instead of the usual cross-sections connected by segments (with curves) this new system allows the simple addition of triangles. As if in the modeller, but between different cross-sections. It's hard to explain but it does simplify tasks by making it a lot easier to fill odd-shaped holes!
After my day of fixes on Fern Bay, Eric decided to have a quick go at it, really just fixes for the new lighting system. There were still some holes to fill, which are important for shadows, and he wanted to add some shine (specular effect) to the roads. He updated a few textures here and there in addition to the road surfaces but did the bare minimum of modelling. As stated before, there isn't time to bring Fern Bay up to the modern standard before the coming release, but it was certainly worth a few days tidying up.
After Eric sent me the update, I noticed a few remaining issues that I could improve with the use of new editor functions that I quickly coded. It is useful for me to spend a little time in the track editor because I often think of a few new functions or improvements to do.
Trying to get things finished can be a lengthy process! After the Fern Bay update we ended up taking on an extra task, almost by mistake. Eric wanted to update some of the layout objects which looked quite tired and old. His plan was just a few days brushing up a few objects. Quickly the task expanded and we started to make use of the new mapping configuration and monochrome colours system, that help maintain variety in the track editor, now extended to the layout objects. With a single object selected there can be several variations on the texture cutouts that are displayed. There was community involvement and we took on some of the ideas. There are definite benefits, so it was worth a week on the job. Even if that week turned out to be two weeks! We're near the end of layout updates for now!
Public thread about layout objects: https://www.lfs.net/forum/thread/101752
Eric and I have discussed the need to try to get to the release and only do what is necessary from now on. We want to do a lot of things but they can be done after the release.
On my side I have another day or two on layout functions, and there are some editor features to look at that could help Eric complete South City. Sometimes when buildings follow the edges of existing roads they can end up quite complex and bring up issues that can be made easier by certain new editor functions. I enjoy doing editor functions but of course, I am trying to get off graphics to finish the tyre physics and get to that public beta as quickly as possible.
Log of updates:
Layout marshals also needed to pick up lighting from lightmap (objects already do)
- marshals are done a different way and do a single lightmap reading when first drawn
Improved track editor function for setting height of multiple points
- also generally updated initialisation of text entry to the new style in a few places
Added a new type of surface that can be added in the track editor
- an extension of "section end triangles" but now can connect to other cross-sections
- as arbitrary triangles between track objects they can make it easier to fill holes
- turned out this is was a bit more work than expected in the track editor
- when objects can refer to others a lot of care must be taken with delete functions
Fix: track editor bug - surface properties were not updated correctly when changed
Fix: a physics surface debug display was not using the thread-safe copy of wheels
Fix: suspension diagram was also not yet updated to use thread-safe variables
Fix: time could move on up to 30 sec in track editor then car would catch up on exit
Eric sent a minor update of Fern Bay with specular lighting added to road textures
- other small updates as well including filling all the holes as seen from above
- although it's not a full update these are important fixes for the shadow system
- also improved a few textures around that needed brightening up in addition to shine
- the general effect is improved as you can see in the attached screenshots
I spotted a few remaining Fern Bay issues and went into the track editor to fix them
- changed/added editor functions that helped with searching/updating multiple objects
- a benefit of me spending time in editor is I sometimes come up with useful functions
Eric started to do a quick update on the layout objects that would take a few days
- it is not really the highest priority but seemed like a quick improvement at first
- job got a little bigger as we added support for selectable "mapping configurations"
- these, along with a colour selector, allow more variety without more object slots
- so we can have e.g. more signs or cone colours using the new improved objects
Discussion with Eric about the new world triangles hole filling system
- it can help fill holes in South City, either large holes out of town or small holes
- Eric showed me some of the challenging things at South City to finish in a good way
- looking at the real situations that come up, we thought of some helpful improvements
Worked on the updated (and new) layout objects
- asked community members if they had suggestions for a few useful objects
- some useful things came from that thread: https://www.lfs.net/forum/thread/101752
- using the new mapping configurations and monochrome colours, more variety is possible
- with a single object selected, multiple configurations can be chosen (e.g. letters)
- in the screenshot you can see most of the new objects but not showing all variations
Remember that if you do the things we recommend, your mod can be processed super fast.
Example 1:
Mod creator creates a development thread, shows progress, lists sources and shares info with public during development. Finally mod is done, submit. SUPER QUICK PUBLISHING
Example 2:
Mod suddenly appears submitted, EITHER claims original work but looks like it comes from another game OR mod is from sketchfab (etc) claimed as original work by sketchfab uploader, but looks like from another game. Reviewers have no way to know if dodgy looking mod is really legit, strong suspicion that it's not. Unwilling to publish. VERY SLOW PUBLISHING
These are just two examples. Other mods may have reasons for super fast publishing and many other mods may also look dodgy for whatever reasons, like FAKE "work in progress" images, that are hard to prove one way or another.
I'm not going to get in a discussion here. In fact I will not subscribe to the thread. But it's amazing how many people IGNORE our advice for how to get mods published quickly, then complain that it takes a long time.
The reviewers are doing their best. Please help them, by doing the proper thing with mod development threads, provide genuine proof of your investigations into the legitimacy of any sources. It is not the job of the reviewers to do that. It is your job to show beyond any doubt that the mod is legitimate.
Example 1:
Mod creator creates a development thread, shows progress, lists sources and shares info with public during development. Finally mod is done, submit. SUPER QUICK PUBLISHING
Example 2:
Mod suddenly appears submitted, EITHER claims original work but looks like it comes from another game OR mod is from sketchfab (etc) claimed as original work by sketchfab uploader, but looks like from another game. Reviewers have no way to know if dodgy looking mod is really legit, strong suspicion that it's not. Unwilling to publish. VERY SLOW PUBLISHING
These are just two examples. Other mods may have reasons for super fast publishing and many other mods may also look dodgy for whatever reasons, like FAKE "work in progress" images, that are hard to prove one way or another.
I'm not going to get in a discussion here. In fact I will not subscribe to the thread. But it's amazing how many people IGNORE our advice for how to get mods published quickly, then complain that it takes a long time.
The reviewers are doing their best. Please help them, by doing the proper thing with mod development threads, provide genuine proof of your investigations into the legitimacy of any sources. It is not the job of the reviewers to do that. It is your job to show beyond any doubt that the mod is legitimate.
Would the kerb objects like you see at Blackwood do the job?
Six more days have elapsed and there is a little more progress to report. It's interesting that most of the work was really nothing to do with multithreading. I had to remove a system that used to clear out disused skins from RAM, because the way it worked was not thread-safe. As mentioned before, we needed a new system that works with all car textures (not just skins). So I've implemented that as described below. You can see it doing its thing in the attached screenshot.
Another milestone is that I sent a version to Eric with a cautious recommendation that he could try using it for development. It has been stable apart from one thread-related crash - an FF device was being uninitialised at the same time as it was being used on another thread.
One of the next steps is a pit-out glitch reduction system that is a lot better than the old one. To reduce a glitch when a remote player leaves the pits in the current version of LFS, while you are driving, no textures are loaded from HDD (or SSD, obviously). The car model is built but may appear white where there should be textures, if those textures were not already loaded for some other car. It has often been reported as a "white cars" bug although it's really not a bug at all, and their cars are rebuilt with textures when you stop at some point.
In the new system (as reported on Sat 29 Oct) a remote player's car model is not built as soon as they leave the pits, but only when they are within your view. But currently all their textures will be loaded immediately as I had to remove the white cars pit-out glitch reduction system.
My new plan is to make it that a car may appear white for a short time, but one by one over the coming frames, the textures will be loaded. The entire model will not have to be rebuilt at any later point, only the actual textures will be loaded, without the car's model even noticing that. This will also cover a similar situation when a remote player joins and their skin is downloaded. That skin will be applied to their car without needing a full rebuild. I expect this to take a few days. The principle is that when a texture is requested, if it is not already in RAM, all information that is required to load it is stored in a "Texture" object that doesn't have its own D3D texture (instead pointing to a small plain system texture, probably grey). The real D3D texture will be loaded at some point (up to a few a few seconds later) and replaced in the Texture object.
Now that multithreading is basically done, I'll stop reporting daily progress and go back to a more normal style. I hope to report more regularly than in the past, as I know the reports are interesting for some people and the use of a closed thread has allowed me to make unofficial reports without them becoming a distraction.
I hope the detailed daily calendar has been of some interest, and some insight into the general complication of the work done by a game programmer. We don't just do some super-slow magic, conjuring up cars and tracks. Instead, it's mostly a lot of strange and abstract stuff that you might not think of immediately. It has been interesting for me, looking back and seeing all this stuff and helps me to understand why my time estimates are always so far off.
Anyway, here's the last of the daily detail calendars, for now:
31 Oct (evening)
FIX: Escape from MPR click to point in replay continued visibly speeding after Esc
FIX: Exposure was not reset after exiting from game which could cause overexposure
1 Nov
FIX: Lights were not switched on when starting a night replay after daylight replay
Removed function "check_for_skin_space" which was accessing Race at the wrong time
- this function ran through texture and car lists to remove older skins from memory
- it is not thread-safe as it was accessing Race (game code) during graphical render
- a better way to identify unused textures (not only skins) is now needed due to mods
Gathered remaining things to do onto new sheets of papers to make them more readable
FIX: Crash when loading very old cars, then a memory leak when loading very old cars
Sent update to Eric with suggestion that it may now be safe to use for development
2 Nov
As mentioned we need a system to remove textures and skins from cars no longer in use
Started coding a method to detect which already loaded textures can be deleted from RAM
First step: to know exactly which textures are used by cars (and helmets) but not world
- imperative not to delete any textures that are still in use or there will be a crash
- change all texture and material initialisation functions to specify usage (car/world)
- this also applies to "re-use" functions, in case a car texture is later used by world
Eric reported a crash bug with ALT+TAB from full screen and provided the crash address
- crash address was in LFS code, setting a Force (on a FFDevice that still existed)
- thread-related: controllers were being shut down while game code applied a force
3 Nov
Examined yesterday's code and brushed up a bit, ready to start with the second step
The algorithm must identify all car textures that are not in use and can be deleted
- avoids an excessive build-up of textures in RAM as cars come and go over time
- run through all textures marked CAR and IN USE - set to DISUSED (and add time stamp)
- new 3D object and car functions to run through all textures and mark then as IN USE
- call car functions on every car in the race, game setup screen, garage (and helmet)
- whatever remains as DISUSED is no longer used by an existing car so can be deleted
Now the focus is on when to run the described algorithm and which textures to delete
- we don't want to delete textures every time it's possible as they may be needed soon
- for example a player who goes to the pits is likely to exit again with the same car
- another example: whole game exits to game setup screen - no point removing textures
- the "last used" time stamp could help to delete textures not in use for a while
Wrote a system to remove materials and textures after some time
- if any car is added or removed in game, a short countdown is started
- after 3 seconds, disused materials and textures are identified (algorithm above)
- then 1 disused material or 1 disused texture is deleted every graphical frame
- but only materials and textures set to unused at least 5 minutes ago are deleted
4 Nov (morning)
Yesterday's algorithm does the job and unused textures always get removed eventually
- avoids build-up in RAM but will sometimes remove textures that will be needed again
- algorithm can be adjusted later but now it's best to work on delayed texture loading
- cleaned up some code and added debug check for texture delete while material exists
Another milestone is that I sent a version to Eric with a cautious recommendation that he could try using it for development. It has been stable apart from one thread-related crash - an FF device was being uninitialised at the same time as it was being used on another thread.
One of the next steps is a pit-out glitch reduction system that is a lot better than the old one. To reduce a glitch when a remote player leaves the pits in the current version of LFS, while you are driving, no textures are loaded from HDD (or SSD, obviously
). The car model is built but may appear white where there should be textures, if those textures were not already loaded for some other car. It has often been reported as a "white cars" bug although it's really not a bug at all, and their cars are rebuilt with textures when you stop at some point.In the new system (as reported on Sat 29 Oct) a remote player's car model is not built as soon as they leave the pits, but only when they are within your view. But currently all their textures will be loaded immediately as I had to remove the white cars pit-out glitch reduction system.
My new plan is to make it that a car may appear white for a short time, but one by one over the coming frames, the textures will be loaded. The entire model will not have to be rebuilt at any later point, only the actual textures will be loaded, without the car's model even noticing that. This will also cover a similar situation when a remote player joins and their skin is downloaded. That skin will be applied to their car without needing a full rebuild. I expect this to take a few days. The principle is that when a texture is requested, if it is not already in RAM, all information that is required to load it is stored in a "Texture" object that doesn't have its own D3D texture (instead pointing to a small plain system texture, probably grey). The real D3D texture will be loaded at some point (up to a few a few seconds later) and replaced in the Texture object.
Now that multithreading is basically done, I'll stop reporting daily progress and go back to a more normal style. I hope to report more regularly than in the past, as I know the reports are interesting for some people and the use of a closed thread has allowed me to make unofficial reports without them becoming a distraction.
I hope the detailed daily calendar has been of some interest, and some insight into the general complication of the work done by a game programmer. We don't just do some super-slow magic, conjuring up cars and tracks. Instead, it's mostly a lot of strange and abstract stuff that you might not think of immediately. It has been interesting for me, looking back and seeing all this stuff and helps me to understand why my time estimates are always so far off.
Anyway, here's the last of the daily detail calendars, for now:
31 Oct (evening)
FIX: Escape from MPR click to point in replay continued visibly speeding after Esc
FIX: Exposure was not reset after exiting from game which could cause overexposure
1 Nov
FIX: Lights were not switched on when starting a night replay after daylight replay
Removed function "check_for_skin_space" which was accessing Race at the wrong time
- this function ran through texture and car lists to remove older skins from memory
- it is not thread-safe as it was accessing Race (game code) during graphical render
- a better way to identify unused textures (not only skins) is now needed due to mods
Gathered remaining things to do onto new sheets of papers to make them more readable
FIX: Crash when loading very old cars, then a memory leak when loading very old cars
Sent update to Eric with suggestion that it may now be safe to use for development
2 Nov
As mentioned we need a system to remove textures and skins from cars no longer in use
Started coding a method to detect which already loaded textures can be deleted from RAM
First step: to know exactly which textures are used by cars (and helmets) but not world
- imperative not to delete any textures that are still in use or there will be a crash
- change all texture and material initialisation functions to specify usage (car/world)
- this also applies to "re-use" functions, in case a car texture is later used by world
Eric reported a crash bug with ALT+TAB from full screen and provided the crash address
- crash address was in LFS code, setting a Force (on a FFDevice that still existed)
- thread-related: controllers were being shut down while game code applied a force
3 Nov
Examined yesterday's code and brushed up a bit, ready to start with the second step
The algorithm must identify all car textures that are not in use and can be deleted
- avoids an excessive build-up of textures in RAM as cars come and go over time
- run through all textures marked CAR and IN USE - set to DISUSED (and add time stamp)
- new 3D object and car functions to run through all textures and mark then as IN USE
- call car functions on every car in the race, game setup screen, garage (and helmet)
- whatever remains as DISUSED is no longer used by an existing car so can be deleted
Now the focus is on when to run the described algorithm and which textures to delete
- we don't want to delete textures every time it's possible as they may be needed soon
- for example a player who goes to the pits is likely to exit again with the same car
- another example: whole game exits to game setup screen - no point removing textures
- the "last used" time stamp could help to delete textures not in use for a while
Wrote a system to remove materials and textures after some time
- if any car is added or removed in game, a short countdown is started
- after 3 seconds, disused materials and textures are identified (algorithm above)
- then 1 disused material or 1 disused texture is deleted every graphical frame
- but only materials and textures set to unused at least 5 minutes ago are deleted
4 Nov (morning)
Yesterday's algorithm does the job and unused textures always get removed eventually
- avoids build-up in RAM but will sometimes remove textures that will be needed again
- algorithm can be adjusted later but now it's best to work on delayed texture loading
- cleaned up some code and added debug check for texture delete while material exists
Thanks for the link! I watched it with the family yesterday evening. Interesting to see how Peter has changed. Well, I remember I was in my late 20s when we all went to his 40th birthday party, and now I'm 50, so he must be in his 60s now.
Nice that Eric and I were kindly mentioned.
That story about how we met isn't quite true though it's based on facts. That's kind of what Peter does.
In fact I did work as a motorbike courier for a company called Black & White that was based in Twickenham. But I was looking for a job as a programmer (I had previously worked at a company called Digital Integration, on the Hind helicopter simulator) so I contacted a recruitment agency that specialised in game jobs. Quite quickly they came up with this interview, with someone who I would surely admire (Peter Molyneux). Actually I hadn't even heard of him before but went for the interview as it sounded good. I rode down on my bike and had a good meeting there, in which we of course talked about my job at Black & White, which was funny as the interview was about working on the game called Black & White.
I had a nice demo (with an animated car and some people and dogs that could walk around on a lumpy landscape - actually it's the same program that evolved into LFS) so they were able to offer me the job on the spot. I said, thanks and I'll consider it. But he looked a bit shocked and said, why aren't you accepting the job now? I said, well I thought that it was the right thing to do... and actually I decided to just accept it then anyway. That was the right move as it was a very good job in the end although there were ups and downs.
We got it running a few years ago, using a boxed game and the fan patches you can find online. Leo and Nicole enjoyed it quite a bit.
How about this attached picture from the video, you can see a creature editor I built in game, using my own buttons system that I had imported into Black and White.
Compare that with the attached image of the vehicle editor.
The early LFS in-game menu style was more inspired by Quake 3 Arena.
FGED GREDG RDFGDR GSFDG