Yes, I have been thinking of this too, actually have already asked Eric about it.
The only issue I have, and it's not a big problem, just which point to use as the origin of the automatically created "break off" object. I think it should be one of the points belong to the selected triangles, or somehow related to them.
Maybe a yellow button if there is one, or a point that is low down in the selection. You might think of something like a point that is in the centre of the selection, but this could risk losing precision. Maybe the nearest point to the centre, or the lowest point?
Just thought I'd ask this in case anyone has a good idea for that. It's not that big a deal because you can adjust it after breaking off, but a good choice of object centre might be helpful, I guess.
The only issue I have, and it's not a big problem, just which point to use as the origin of the automatically created "break off" object. I think it should be one of the points belong to the selected triangles, or somehow related to them.
Maybe a yellow button if there is one, or a point that is low down in the selection. You might think of something like a point that is in the centre of the selection, but this could risk losing precision. Maybe the nearest point to the centre, or the lowest point?
Just thought I'd ask this in case anyone has a good idea for that. It's not that big a deal because you can adjust it after breaking off, but a good choice of object centre might be helpful, I guess.
The NCL can only have an effect when used within the same smoothing group. In that case it will give a higher weighting to the triangles with the higher number. So it affects only the normals at the boundary between two normal contribution levels, within the same smoothing group. But across smoothing group boundaries, separate triangles do not contribute to the same normal anyway so then it has no effect.
But I wondered about the slight shading errors, and had a look in game and in editor. I tried "flat" view mode, because flat shading shows a good representation of the triangle normals, that produce the raw data for the vertex normals.
As you can see in flat shaded view, there is a sort of dent here (attached image). Because of how LFS works, that dent is the cause for the undesirable normals at that location.
I forgot to mention flat shaded mode. That is another thing that Eric uses a lot. I think that by moving vertices around a few mm here or there, the flat shaded model can display more consistent lighting and that will affect the vertex normals in a good way. I don't know if you can use the same thing in blender (I know blender supports non-triangle polygons so I don't know).
EDIT: I just remembered, sometimes triangle rotations can also have a quite a noticeable effect on the normals. I mean rotating two triangles within a quad (select 1 triangle, SHIFT+click the adjacent triangle). The LFS importer doesn't always make the best choice of triangle rotation when creating two triangles from a quad in the imported obj file.
Last edited by Scawen, .
I haven't seen the specific case you are talking about but there are some tricks you can use.
First to understand:
- the normals at a vertex are based on the directions of the connected triangles, within a smoothing group.
- the normal contributions are higher from the larger triangles meeting at that point.
You can adjust the normals in two main ways:
- extra triangles may sometimes be needed
- use "normal contribution level" (ncl)
I have a feeling that a lot of people don't know about normal contribution levels, although Eric uses them a lot. You can use it to increase the importance of some triangles, relative to others, regarding their contribution to normals.
Actually, triangles with ncl of zero will not affect the normal at all if there are triangles with a higher contribution level also connected to that point.
You can view and assign the ncl in a similar manner to smoothing groups.
I don't really want to lay down the law as such, but maybe a good guide would be our most recently updated car, the RB4 GT.
Eric is an artist and like most artists he would like to use more polygons, but he is also a game developer so tries to do what he can without being excessive with the numbers.
There are other ways to optimise models too, for example by using one texture page for several cutouts, within reason and when that is convenient (not possible for 'repeating' textures).
Note that "attachment" subobjects are merged into the main object so it's a good idea for attachments to share texture pages with the main object too (when convenient) as if they were part of the main object.
Also, most cars should have "Concealed driver" enabled. Driver not concealed is only needed for things like karts and bikes (when you can see the driver's body from a long distance away). ordinary road cars have concealed driver and this is a significant CPU saving. This setting does not affect the helmet, which is drawn anyway.
Eric is an artist and like most artists he would like to use more polygons, but he is also a game developer so tries to do what he can without being excessive with the numbers.
There are other ways to optimise models too, for example by using one texture page for several cutouts, within reason and when that is convenient (not possible for 'repeating' textures).
Note that "attachment" subobjects are merged into the main object so it's a good idea for attachments to share texture pages with the main object too (when convenient) as if they were part of the main object.
Also, most cars should have "Concealed driver" enabled. Driver not concealed is only needed for things like karts and bikes (when you can see the driver's body from a long distance away). ordinary road cars have concealed driver and this is a significant CPU saving. This setting does not affect the helmet, which is drawn anyway.
So boring to hear this old rubbish.
Eric and I are working on a project we love, the way we want to work. We work at home, on things we like to work on. It's a good life.
We don't work in an office, managing a team of artists and programmers and accountants and project managers etc.
The way we work earns less money but gives a better quality of life in our opinion although that might not be everyone else's ideal way to work.
If you are a victim of capitalism and you believe the purpose of life is to make the most money, then from your point of view we made wrong decisions, that's for sure.
If someone's opinion is that you should be able to work as closely as possible to the things you are interested in, then we made right decisions.
I'll say again, we make the game we want to make, the way we like to make it. If you like it, please race or play or whatever you want to do. If not, then go and do something else, that's fine. But just remember the developers are enjoying their work and this project is driven by many decisions other than maximising income.
I've added that to the RB4, and fixed the triangle errors in XRR / FO8 / XFR / FOX.
I'm nearly at the point to send Eric an update, and I've coded a setup height repair system as these development models have the model object centre correctly located at the lowest point of the model, instead of at rough ground level or whatever other random position they were in the old versions. The repair detects old setup and adjusts height according to a table of height adjustments for the official cars.
That's so all the existing setups will load correctly in the new version. No doubt they'll need an adjustment for the new physics but I think there's no harm in working from old setups.
I'm nearly at the point to send Eric an update, and I've coded a setup height repair system as these development models have the model object centre correctly located at the lowest point of the model, instead of at rough ground level or whatever other random position they were in the old versions. The repair detects old setup and adjusts height according to a table of height adjustments for the official cars.
That's so all the existing setups will load correctly in the new version. No doubt they'll need an adjustment for the new physics but I think there's no harm in working from old setups.
I can't give any better estimate when the 1000 Hz update will be released. Eric is currently working on significant updates for Kyoto and I am trying to finish an intermediate semi-compatible release of the public version with improved mods support.
After that release I'll be trying to finish the new tyre physics and the plan is to release that with the new graphics, as both are in the separate development branch of LFS. I have no more information that that, at this time.
---
About the FF display, I seem to remember someone did a mockup of a way that a native FF display could work. Can anyone remember that, or does anyone have a good idea for it, how it could look, how it should be enabled? Should it be something like the display you can see when you click the small car button in Misc or Graphics options (a lateral graph moving up the screen).
Half the issue implementing something like this is the general design and the interface for it. Another significant problem with adding things to the screen are all the situations that can come up when trying to display the new feature at the same time as other things on the screen, so if you could help sort out the details that would be helpful.
I have a slight issue at the moment that whenever I try implementing some "simple feature that would be very useful" I end up spending several days or weeks sorting out all the repercussions that arise. So the thought of taking on yet another task is a bit nerve wracking right now.
By the way, in the development version I do have a simple "MAX FF" red text that comes up in the middle of the screen in the same place as the usual large text. It might be a bit too raw for a public release. Obviously this would be a lot simpler to implement than a graph. So that approach would avoid delays but I'm not sure how useful that would be, compared with the full graph display. Also would it need an option, like "Show FF clipping" NO / YES.
After that release I'll be trying to finish the new tyre physics and the plan is to release that with the new graphics, as both are in the separate development branch of LFS. I have no more information that that, at this time.
---
About the FF display, I seem to remember someone did a mockup of a way that a native FF display could work. Can anyone remember that, or does anyone have a good idea for it, how it could look, how it should be enabled? Should it be something like the display you can see when you click the small car button in Misc or Graphics options (a lateral graph moving up the screen).
Half the issue implementing something like this is the general design and the interface for it. Another significant problem with adding things to the screen are all the situations that can come up when trying to display the new feature at the same time as other things on the screen, so if you could help sort out the details that would be helpful.
I have a slight issue at the moment that whenever I try implementing some "simple feature that would be very useful" I end up spending several days or weeks sorting out all the repercussions that arise. So the thought of taking on yet another task is a bit nerve wracking right now.
By the way, in the development version I do have a simple "MAX FF" red text that comes up in the middle of the screen in the same place as the usual large text. It might be a bit too raw for a public release. Obviously this would be a lot simpler to implement than a graph. So that approach would avoid delays but I'm not sure how useful that would be, compared with the full graph display. Also would it need an option, like "Show FF clipping" NO / YES.
I'll start by linking to a couple of threads which show a lot of the work I have been doing recently:
Test Patch D33: https://www.lfs.net/forum/thread/102117
Editor Test Patch D40: https://www.lfs.net/forum/thread/102626
As you can see, particularly on the Editor Test Patch thread, I have made a huge number of improvements for the mod support. I find it a great thing that LFS is a way for people to be creative, and the mods system is a massive new part of that. It was very "new" indeed when released (basically a bunch of dev editors brushed up a bit) which is why there have been so many issues to sort out.
In the past months, while I have been doing these, Eric was at first finishing South City, which took a lot longer than he anticipated. Filling those holes is not easy, and he likes to fill them just as people would actually "fill the holes" when building a real city. I received an update recently and tested it, reported a bunch of issues and he fixed those. We find the completion level very good now, basically good enough for public testing when we can get the full version together. He is now working on the Kyoto improvements. As you may know from the official progress reports, that was never finished before Eric moved onto the South City, that turned into an epic development and massive expansion.
On my side, I'm trying to finish test patch things so that I can finally complete the tyre physics. In fact my current focus is on wheels, both in the development and public version. In the public version there should be a graphical update for wheels in the next few days, to go along with the many updates there have been for mods. Again, please read the test patch threads to know what I'm talking about.
There is also other work I do, that you never see, such as updates for the track editor. Suppose Eric is doing a task and finds he has to do something in a laborious or repetitive way and one of us thinks of a new editor function that could help him achieve certain tasks more quickly, then I always want to stop whatever else I was doing and work on the track editor for a few days.
I'm trying to get to an official release so my focus can then be entirely on the tyre physics in the development version. It has taken me much longer than expected to complete this round of test patches as there were so many unfinished things in the mods system. When I see creators, working hard and having to use workarounds for issues, I feel a great responsibility to get that issue sorted out.
Of course, the priorities I attach to various tasks, will not be the same as someone else's priority. We all have different priorities, so there's not a person in the world who could agree with all my choice of tasks to work on. But I must work on what I feel is important. Actually I find it a huge mental effort to complete these tasks, and that's why I need to follow the inspiration. Sometimes I'm awake at night working out how to do something, then experimenting and testing, it's a lot of work.
It takes a long time, but there is always progress.
I've received another South City update from Eric so did a few track editor updates that were relevant at this point. In the process I updated a few features from the public editor, so here they are.
Editor Test Patch D19:
Hotkey for "hide/unhide (un)selected" changed from X to H (like blender)
- small H button at top left to hide/show message history (old H function)
Left click increments should now always be smaller than right click
- previously this was not consistent for all types of buttons
- as before, CTRL may do smaller steps, SHIFT may do larger steps
- this change should apply to distance, colour, angle and scale
Find button for error triangles or points now selects all as expected
- previously only selected the first point or triangle in the list
Editor Test Patch D19:
Hotkey for "hide/unhide (un)selected" changed from X to H (like blender)
- small H button at top left to hide/show message history (old H function)
Left click increments should now always be smaller than right click
- previously this was not consistent for all types of buttons
- as before, CTRL may do smaller steps, SHIFT may do larger steps
- this change should apply to distance, colour, angle and scale
Find button for error triangles or points now selects all as expected
- previously only selected the first point or triangle in the list
I've had a look into this, found a possible reason for the crash and recreated a crash that matches your description.
It looks as if the code will fail (and crash, unpredictably) if there are more than 64 different materials in the model (when the subobjects are combined with the main model, which LFS does automatically).
I'll need to decide how to allow more materials, limit the number of materials, or both, as it is of course not acceptable for the program to crash.
Although I will do that, I must also say that I feel it's an excessive number of materials. Eric's most extremely detailed vehicle, the RB4, has reached 50 materials. Although I shouldn't be surprised that someone else's model exceeds 64 materials, as a programmer I feel this is too much for in game use and somehow you should reduce the number of materials. Maybe you can achieve the same results by either reducing the number of textures (e.g. by using cutouts on fewer, combined, texture pages) or reducing the number of different material settings in the 'cutout' mode?
I can't give any specific suggestions without seeing the model, but I have made a note to consider a fix/limit/warning/etc. Please let me know if the explanation makes sense (if I've described it properly and if you model really does have so many materials).
Last edited by Scawen, .
OK, I think that's exactly what Eric was talking about.
Please explain a bit more - I don't know what this means.
I think that will be:
/pitreq repair [yes/no]
I think you are now talking about live settings? F11 menu? I understand this seems like a similar thing but I won't look at that for now.
You can look in the guide on the linked page, it is a pretend wet condition, drivers must pit and use road tyres if the rain comes (declared by the organiser). The cars are harder to handle so it's similar to real life, even if there is no actual rain.
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
It has gone down in 10 years, yes, as discussed a thousand times, due to so many things we can't discuss here and piracy too, But far more interesting is how it has gone up in the last 1.5 years. See the attachment, representing 600 weeks.
But calling it abandoned is just some fantasy which you want to believe in because it suits your narrative. To believe that, you have to ignore all our progress reports, everything we say, decide we are lying than make up your own version of reality. In fact I'm working about 10 hours a day and Eric is working loads too. There is a lot of progress. Is it as fast as anyone would like? No, but to suggest it is abandoned is just so absurd from my point of view.
The game has picked up so much, sales are up since 2021 when there was a serious problem, as stated. Piracy was bringing the game down. Now it's not. You are free to believe what you want but I'd appreciate it if you won't mope around here making up fantasies of doom and gloom and trying to paint that depressing picture.
You know, this thread is about how to improve attendance for scheduled events. The answer can't be, let's go back in time 10 years and change history. What threads are for is, to comment if you have anything to say on the matter. Not an invitation to spread feelings of doom and gloom.
I thought about extending CTRL+D (duplicate selected) to other screens like mapping/cutout/page
Also CTRL+N for a NEW point/mapping/cutout/page
I was also thinking about Extrude (that you and r3zp3k7 mentioned) and Flip. I understand people use extrude a lot so SHIFT+E could work for that? Or should it just be plain 'E' ?
Why I say "SHIFT" in this case and not "CTRL": CTRL+key I try to reserve for universal functions that work across the whole of LFS (or many editors in LFS). Operations that are more specific to one particular editor should have SHIFT+key or plain key presses.
About FLIP I wondered if there should be an option to flip the triangles after an extrude, as it's easy to confuse the inside/outside options. If you have points selected (instead of triangles) it could flip the triangles that are connected to the selected points. This way, I think FLIP would work as expected after an extrude. I'm not sure which key to use. F is front view and SHIFT+F hides buttons. Maybe CTRL+F, but that seems like it might have a more system wide use? Any other suggestions for FLIP? What is the key if there is a similar operation in another editor like Blender?
EDIT: Final question for the morning, kenblock30 mentioned a key for "fuse to green". It's another 'F'
but F isn't really available for that so thought I'd ask if there is such a function in Blender and which key it uses? Not that we have to copy Blender but it can be a good idea to use the same keys when possible.P.S. before anyone starts complaining that I am not focussing on tyre physics, I have been working on tyre physics this week and making some progress. But in fact that is a process of doing things and chewing on it a bit, coming up with something to try the next day etc. I can't just work 24-7 on tyre physics. So to do the odd editor function is great for mod creators and can help Eric too.
Last edited by Scawen, .
About hotkeys / shortcuts:
I'm on tyre physics most of the time now but occasionally will update the editor. I wonder what are the most repeated functions (that would most benefit from a special key) and what those keys should be (maybe the same as in another program like Blender, when practical).
I asked Eric in August and he suggested:
He also mentioned CTRL+S to save the main model.
I'm on tyre physics most of the time now but occasionally will update the editor. I wonder what are the most repeated functions (that would most benefit from a special key) and what those keys should be (maybe the same as in another program like Blender, when practical).
I asked Eric in August and he suggested:
He also mentioned CTRL+S to save the main model.
Thanks, I've moved the posts to a new thread.
Interesting thoughts that the new version might help with this, and even the thought of a slight rename with that version, so that journalists don't keep saying it's a 20 year old game and implying that the developers have vanished. Though there is a slight problem with that as it really is an ongoing project. When the 'big release' comes out there will still be some outdated stuff remaining that Eric and I still want to work on.
Anyway it's not a big deal, just slightly annoying to hear the same old crap which is just made up on the spot, or copied from other journos. Or maybe they are confusing it with some other old game, it does sound a bit like that. Probably the guy is quite young too as he appears to think that wheel support is something new, doesn't realise LFS had support for FF wheels long before 2002.
But now I'm making up my own stuff.Anyway nothing more important than the new version that we are still working hard on!
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
Well there has also been a request to use the back of such boards as an advert slot allowing people to change it through AX_ADS1 image file, which Eric and I have not discussed yet.
A question about the paint letters (see attachment).
As with the letter and number boards, there are 3 objects with 16 slots each.
For the polystyrene tiles we have:
But the road paint has slightly different use.
1) no need for SPACE (does nothing). Eric suggests & which is commonly used on roads.
2) small arrows aren't appropriate, in real life they are twice as long as the letters, so we'll probably add some painted long arrows on a separate object.
That leaves the last 4 mapping slots free and I thought it would be best to ask what characters or character-sized symbols you might want in there.
As with the letter and number boards, there are 3 objects with 16 slots each.
For the polystyrene tiles we have:
A-M SPACE . :
N-Z # @ /
0-9 ( ) < > ^ v [last 4 are small arrows]
But the road paint has slightly different use.
1) no need for SPACE (does nothing). Eric suggests & which is commonly used on roads.
2) small arrows aren't appropriate, in real life they are twice as long as the letters, so we'll probably add some painted long arrows on a separate object.
That leaves the last 4 mapping slots free and I thought it would be best to ask what characters or character-sized symbols you might want in there.
Eric has a plan to add all 8 arrow directions instead of just the "keep left" and "keep right" directions on the metal standing board. I'm not sure if that does all you want or have a better idea. Or if it's important to have arrows on the alphanumeric boards.
We are actually right on the question of alphanumeric boards now. With 36 slots used for A-Z and 0-9 there are 12 spare slots.
We have proposed use for these 12 "spare" slots but I want to ask you if some swaps would be better.
BOARD1: A B C D E F G H I J K L M _ < >
BOARD2: N O P Q R S T U V W X Y Z ! & @
BOARD3: 0 1 2 3 4 5 6 7 8 9 # * % + - _
That's what Eric suggested. I guess one of the _ is a actually a SPACE. I don't know if < and > should actually be a triangle or arrow instead? And are there any better choices than & ! + - % * _ ?
I suppose to my mind the most useful extras are: SPACE # < > @ (not sure about the others)
Thanks for the feedback.
Let me try to make sure we are clear by asking some questions:
I think you are saying: Polystyrene, movable equivalent of Banner1 and Banner2? And when you say the pics file, you mean like AX_ADS1.jpg or equivalent?
The countdown boards, do you mean the distance to corner markers? And so what you are suggesting is on the back of them could be mapped another slot from an AX_ADSx file?
Good suggestion but I'll say not for this update. To get into InSim coding now is way too complicated for me as I've got a few things on the go. Just adding a few objects is about all we can do for now.
But either during public beta testing or maybe for a version after the 'big release' would be a reasonable time.
Interesting idea. Let's see if Eric like the idea. I think you mean, massive flat chalk letters? I supposed they should be extended "vertically" so they are easy to read from a car like painted SLOW sign on a road?
What size would you suggest? Something like a SLOW sign?
https://s0.geograph.org.uk/geophotos/02/52/55/2525585_aa2c8f9d.jpg
Let me try to make sure we are clear by asking some questions:
I think you are saying: Polystyrene, movable equivalent of Banner1 and Banner2? And when you say the pics file, you mean like AX_ADS1.jpg or equivalent?
The countdown boards, do you mean the distance to corner markers? And so what you are suggesting is on the back of them could be mapped another slot from an AX_ADSx file?
Good suggestion but I'll say not for this update. To get into InSim coding now is way too complicated for me as I've got a few things on the go. Just adding a few objects is about all we can do for now.
But either during public beta testing or maybe for a version after the 'big release' would be a reasonable time.
Interesting idea. Let's see if Eric like the idea.
I think you mean, massive flat chalk letters? I supposed they should be extended "vertically" so they are easy to read from a car like painted SLOW sign on a road?What size would you suggest? Something like a SLOW sign?
https://s0.geograph.org.uk/geophotos/02/52/55/2525585_aa2c8f9d.jpg
We are currently spending a few days improving layout objects as the old ones are just too ugly. It might not be absolutely necessary before the release but we sort of fell into it, anyway it'll be done soon and had to be done at some point!
We've now got the ability to select up to 16 mappings per object, so for example we could have alphabet boards like this. Maybe a rectangle, with one letter per board.
- 1 board with letters A to M selectable
- 1 board with letters N to Z selectable
- 1 board with numbers 0 to 9 selectable
That only takes 3 object slots - not 36!
I suggest a plain (white by default) polystyrene rectangle that could stand on the ground or be floating. It could also have colours selectable.
Eric asked what size the board should be. Any ideas? I suppose not too big as you want to make words with them. But big enough to be seen from a reasonable distance.
EDIT: How about, similar size to the corner markers, but 1m high and 80cm wide, reasonable proportions for letters?
Last edited by Scawen, .
Another 12 days have passed and some of you may be interested to read the log. The super short version is I've been fixing things, doing things that needed to be done, getting rid of lists of things to do. I'm trying to get all the important things out of the way ready to focus on tyre physics. Things that are less important, I plan to do after the release (apart from the odd thing here or there that I simply feel like doing).
The attached images show what tyre smoke looks like in a tunnel with and without a lightmap!
Log of changes:
Some small tasks to finish the delayed texture loading system
- updated per-frame task sequencer so if a car model was built a texture is not loaded
- renamed / reorganised some of the new functions to make more sense when reading code
- prevented delayed texture loading in modeller and vehicle editor (prefer instant)
- fixed single frame with headless driver standing up when exiting animation editor
- the option to switch between compressed and full skins now uses new reload system
- used MP replay to test switching between high and low resolution auto-download skins
- added critical section to make sure DDS saving cannot coincide with loading DDS skin
Spent a day on Fern Bay in the editor - various fixes (not creative work)
- unlike other tracks, Eric does not plan major Fern Bay updates in the near future
- there were shadow holes due to buildings and footbridges without top surfaces
- as an old favourite I wanted to see it in good condition suitable for release
- it's good for me to spend a little time in the track editor occasionally
Fixed minor issue: players joining in entry screen could trigger texture purge events
- host and guests did a quick load and delete of the new player's car to check setup
- as this car was loaded in "in-game" mode it would trigger a check for unused textures
- but cars no longer point to a setup in the player so this seemed to have no purpose
- so instead of preventing the cars triggering a texture purge, simply avoid this code
Off-topic interface update: Provide a left and right arrow for multi-state options
- it bugged me that to switch off replay saving I had to pass through an extra state
- now I can simply click left arrow to switch off saving / right arrow to enable
- the arrow button is greyed out if you reach the last option in that direction
- the 'greyed out' logic was easily applied to option slider bars so did that too
- tempting to do it for the integer nudge buttons but would have to change all calls
- too much to do so will forget that until the inconsistency bugs me in the future
Some development version updates
- new feature to help search for textures in the editor (in objects and world mappings)
- fixed system to load most recent version of a track for a lesson (not exact match)
- update to allow replays to load most recent version of a track (or currently loaded)
- fixed a thread protection notification exiting from editor using the window X button
Training lesson fixes
- fixed start time of training lessons which were always at midnight on 1 January 1601
- fixed some small issues around loading tracks that triggered thread warning messages
- fixed a "Game call from main thread" thread warning message during training lessons
General fixes
- fix for a thread protection notification when LFS does a full D3D recovery
(I have not seen a D3D recovery other than by deliberately forcing it to happen)
Fix for a problem noticed in MPR but would affect multiplayer generally
- symptom was a puff of smoke when clicking timeline to a certain point in the replay
- took a while to track down the cause (depended on where car was before fast forward)
- related to tyre's 'previous ground position' which is compared with current position
- this previous position was wrong if car was at a different angle before pos packet
- this has very minimal difference if pos packet is for a car that is currently viewed
- bigger difference if moving to a car that has not been viewed (physics not updated)
- solution is to get a good estimate for previous position using velocity and rotation
- testing shows that car velocity gives a good estimate so will leave out rotation now
The problem described above took me into angular momentum, rotation, position updates
- some things were still waiting since the 1000Hz updates (on my notes for months)
- now there is no sub-update, some things can be rearranged a little (for accuracy)
- a position accumulator is needed for low speeds (to avoid a 'minimum speed' issue)
- seems good to be pulling me back into physics as the tyre updates are waiting
- converted old variable FloatPos (was related to sub-updates) to position accumulator
- now super-slow speeds are possible and car cannot be stuck on 'digital rails' (xyz)
Have noticed an issue for some time - physics objects resisted starting to move
- seems to be related to 1000Hz update: object velocity not fast enough after 1 frame
- fixed by reducing the speed at which an object is considered to have started moving
Cleaned up code from recent changes / discarded finished notes / browsed old notes
- copied a few things from the old notes onto a short list of tasks to do for release
- although we are still a way from there I want to know what remains other than tyres
- random OT: made arrow keys work to move between options screens (seems like should)
- old notes reminded me that smoke particles do not pick up lighting from lightmap
- the lightmap stores info about artificial light and sky visibility, in an octree
- that means smoke looks black in the night and also too bright in tunnel during day
- made smoke particles read lightmap - see the attached images for before and after
The attached images show what tyre smoke looks like in a tunnel with and without a lightmap!
Log of changes:
Some small tasks to finish the delayed texture loading system
- updated per-frame task sequencer so if a car model was built a texture is not loaded
- renamed / reorganised some of the new functions to make more sense when reading code
- prevented delayed texture loading in modeller and vehicle editor (prefer instant)
- fixed single frame with headless driver standing up when exiting animation editor
- the option to switch between compressed and full skins now uses new reload system
- used MP replay to test switching between high and low resolution auto-download skins
- added critical section to make sure DDS saving cannot coincide with loading DDS skin
Spent a day on Fern Bay in the editor - various fixes (not creative work)
- unlike other tracks, Eric does not plan major Fern Bay updates in the near future
- there were shadow holes due to buildings and footbridges without top surfaces
- as an old favourite I wanted to see it in good condition suitable for release
- it's good for me to spend a little time in the track editor occasionally
Fixed minor issue: players joining in entry screen could trigger texture purge events
- host and guests did a quick load and delete of the new player's car to check setup
- as this car was loaded in "in-game" mode it would trigger a check for unused textures
- but cars no longer point to a setup in the player so this seemed to have no purpose
- so instead of preventing the cars triggering a texture purge, simply avoid this code
Off-topic interface update: Provide a left and right arrow for multi-state options
- it bugged me that to switch off replay saving I had to pass through an extra state
- now I can simply click left arrow to switch off saving / right arrow to enable
- the arrow button is greyed out if you reach the last option in that direction
- the 'greyed out' logic was easily applied to option slider bars so did that too
- tempting to do it for the integer nudge buttons but would have to change all calls
- too much to do so will forget that until the inconsistency bugs me in the future
Some development version updates
- new feature to help search for textures in the editor (in objects and world mappings)
- fixed system to load most recent version of a track for a lesson (not exact match)
- update to allow replays to load most recent version of a track (or currently loaded)
- fixed a thread protection notification exiting from editor using the window X button
Training lesson fixes
- fixed start time of training lessons which were always at midnight on 1 January 1601
- fixed some small issues around loading tracks that triggered thread warning messages
- fixed a "Game call from main thread" thread warning message during training lessons
General fixes
- fix for a thread protection notification when LFS does a full D3D recovery
(I have not seen a D3D recovery other than by deliberately forcing it to happen)
Fix for a problem noticed in MPR but would affect multiplayer generally
- symptom was a puff of smoke when clicking timeline to a certain point in the replay
- took a while to track down the cause (depended on where car was before fast forward)
- related to tyre's 'previous ground position' which is compared with current position
- this previous position was wrong if car was at a different angle before pos packet
- this has very minimal difference if pos packet is for a car that is currently viewed
- bigger difference if moving to a car that has not been viewed (physics not updated)
- solution is to get a good estimate for previous position using velocity and rotation
- testing shows that car velocity gives a good estimate so will leave out rotation now
The problem described above took me into angular momentum, rotation, position updates
- some things were still waiting since the 1000Hz updates (on my notes for months)
- now there is no sub-update, some things can be rearranged a little (for accuracy)
- a position accumulator is needed for low speeds (to avoid a 'minimum speed' issue)
- seems good to be pulling me back into physics as the tyre updates are waiting
- converted old variable FloatPos (was related to sub-updates) to position accumulator
- now super-slow speeds are possible and car cannot be stuck on 'digital rails' (xyz)
Have noticed an issue for some time - physics objects resisted starting to move
- seems to be related to 1000Hz update: object velocity not fast enough after 1 frame
- fixed by reducing the speed at which an object is considered to have started moving
Cleaned up code from recent changes / discarded finished notes / browsed old notes
- copied a few things from the old notes onto a short list of tasks to do for release
- although we are still a way from there I want to know what remains other than tyres
- random OT: made arrow keys work to move between options screens (seems like should)
- old notes reminded me that smoke particles do not pick up lighting from lightmap
- the lightmap stores info about artificial light and sky visibility, in an octree
- that means smoke looks black in the night and also too bright in tunnel during day
- made smoke particles read lightmap - see the attached images for before and after
Hello everyone.
As you know, we are working hard and trying to get to the long awaited release. I've discussed a little with Eric about the need for us to try to bring our work to a close and really get to the release.
There's always a problem of wanting to do more but sometimes we need to wrap up what is done and get it out there.
So that's the aim. Currently I am trying to get the last notes off my lists of things to finish and bugs to fix, related to the 1000 Hz updates, multithreading and the lighting changes.
That will leave me with the tyre physics to dive into once again to figure out where it's strong, where it's weak, what parts need to be improved before the big release and what can be done later.
On Eric's side, I know he has been very involved with South City and its architecture, making a really beautiful area with so many ways to drive around. I guess he he will be able to delay some of the planned updates, to focus more on filling holes and there are also holes to fill at Kyoto.
In case you haven't seen already, there are a lot of pictures of South City and other new tracks on the 20th Anniversary report from August:
https://www.lfs.net/20th-anniversary
If you want to know what I have been doing, I have listed it in extreme detail on recent threads.
Multithreading progress: (not adding to this one)
https://www.lfs.net/forum/thread/100464-Progress-on-Multithreading
Development progress: (still ongoing)
https://www.lfs.net/forum/thread/101348-Development-Progress
So I think we are keeping you pretty well informed. I'm sure everyone can understand that it is in no way possible to finish everything before Christmas and we can't really think of a way to produce a new progress report at the moment.
But we are trying to get there as the release is very important!
I will close this thread as it doesn't really serve a useful purpose any more.
As you know, we are working hard and trying to get to the long awaited release. I've discussed a little with Eric about the need for us to try to bring our work to a close and really get to the release.
There's always a problem of wanting to do more but sometimes we need to wrap up what is done and get it out there.
So that's the aim. Currently I am trying to get the last notes off my lists of things to finish and bugs to fix, related to the 1000 Hz updates, multithreading and the lighting changes.
That will leave me with the tyre physics to dive into once again to figure out where it's strong, where it's weak, what parts need to be improved before the big release and what can be done later.
On Eric's side, I know he has been very involved with South City and its architecture, making a really beautiful area with so many ways to drive around. I guess he he will be able to delay some of the planned updates, to focus more on filling holes and there are also holes to fill at Kyoto.
In case you haven't seen already, there are a lot of pictures of South City and other new tracks on the 20th Anniversary report from August:
https://www.lfs.net/20th-anniversary
If you want to know what I have been doing, I have listed it in extreme detail on recent threads.
Multithreading progress: (not adding to this one)
https://www.lfs.net/forum/thread/100464-Progress-on-Multithreading
Development progress: (still ongoing)
https://www.lfs.net/forum/thread/101348-Development-Progress
So I think we are keeping you pretty well informed. I'm sure everyone can understand that it is in no way possible to finish everything before Christmas and we can't really think of a way to produce a new progress report at the moment.
But we are trying to get there as the release is very important!
I will close this thread as it doesn't really serve a useful purpose any more.
Eleven days since the last report, here is some more progress. Not much on multithreading but a couple of thread-related bug fixes. This period started with some work on the skin downloads which now work more smoothly and with a smaller glitch when the texture is applied to the car.
More interesting was an increase in the number of available objects. I had to overcome a technical limitation that object indices were 16-bit numbers, for historical reasons, which meant there was a hard limit of 65536 objects in the world. Objects mainly include actual objects, track cross-sections (we call them simply 'sections') and the segments that link sections, with curves and surfaces. Also flags, marshals, trees, and abstract objects like cameras, start points, grids and pit zones count as objects too.
The new South City has been getting close to that limit and I wanted to add a few more, which were related to an improved way of timing laps. Now that timing can be done to an accuracy of 0.001 seconds, the old path-based timing really wasn't up to the task. The path nodes don't align perfectly with the visual finish line which could give some strange results if there was a photo finish. To be fair these new checkpoints would only add 20 or so objects to a track but when I mentioned them to Eric he did talk about the shortage of object slots and that's why I decided to get down and sort that out. Actually it turned out not to be too bad, as in recent years the obstacles preventing me from changing to 32-bit object indices have been removed. Primarily it was the old 'optimiser' data that switched on and off objects as you drove around the track. It was huge data but now we use an occlusion octree that works in a different way and does not store the indices of individual objects.
There is more explanation in the log below. To illustrate the checkpoints update I have attached 3 screenshots. Because timing no longer relies on paths, it is interesting to note that open configs can now naturally do lap timing even without custom checkpoints being added. Paths still have some advantages such as instantly updated race position list and the colour coding for other cars on the small map, and these functions still work on configurations that do have a path.
Log of changes:
Skin downloads are now converted to DDS and saved from the download thread
- this reduces a graphical glitch when a skin is loaded onto a remote car
- simplified some texture loading code that was mixed up with skin saving
Cleaned up more code around texture loading and skin downloading
- the car's model is no longer rebuilt after its skin is downloaded
- instead the car holds a placeholder skin which is replaced behind the scenes
Support for ALPHA in section ends (tracks are made of segments between cross sections)
Fixed crash bug in the unused texture removal system (could remove some still in use)
Noticed a thread-related bug to do with setting the exposure while restarting
- game code does an 'illegal' D3D call that can cause corruption
Separated "set up lighting" into physical and graphical sections to fix the bug
- considered that this section of code has not yet been separated properly
- the physical part should be done every physics frame (sun could affect physics)
- graphical part needs to be done every graphical frame (shader constants, etc)
Realised that Eric was spammed with too many code-related debug messages in editor
- added a debug level option so he can see more relevant but not excessive messages
- used special macros to simplify the adding of messages for 3 different debug levels
- searched for and updated around 600 debug messages to use the new switchable system
- removed obsolete messages, e.g. a config without a defined path is valid these days
Encountered a thread-related crash, again during restart (clash with drawing humans)
Fixed a zoom bug in one type of trackside TV camera (probably was there a long time)
Removed another thread warning message that appeared in track editor (on undo or load)
Made car ambient shadows, lightmap lighting and headlight effect work in track editor
Considered a new timing system that uses proper checkpoints like in the layout editor
- existing timing is based on path nodes and is misaligned with visible finish lines
- Eric mentioned a concern with the number of objects in map approaching a hard limit
Converted object indices to 32-bit to increase the number of objects that can be added
- previous 16-bit indices only allowed a maximum of 65536 objects to be added to a map
- number includes objects, buildings, cameras, track cross sections and segments, etc.
- in the past the occlusion data relied on object indices and took up a lot of memory
- now we have a totally different occlusion system that storage issue no longer exists
- it took only a bit more than a day to update the remaining object indices to 32-bit
Moved onto the new system that allows accurate alignment of checkpoints and finish line
- started by analysing all path nodes over marked track segments to detect checkpoints
- this produces many checkpoints, often duplicates, e.g. a finish line for every config
- the duplicate checkpoints are combined and config switches enable them appropriately
- this leaves fully working checkpoints that Eric can adjust to improve accuracy
- worked on the editor side of it (the checkpoints are a type of invisible object)
- on the driving side, checkpoint detection use existing code for layout checkpoints
- timing is no longer path-based but paths have uses, e.g. instant race position list
- interestingly open configs can now do timing even without adding custom checkpoints
More interesting was an increase in the number of available objects. I had to overcome a technical limitation that object indices were 16-bit numbers, for historical reasons, which meant there was a hard limit of 65536 objects in the world. Objects mainly include actual objects, track cross-sections (we call them simply 'sections') and the segments that link sections, with curves and surfaces. Also flags, marshals, trees, and abstract objects like cameras, start points, grids and pit zones count as objects too.
The new South City has been getting close to that limit and I wanted to add a few more, which were related to an improved way of timing laps. Now that timing can be done to an accuracy of 0.001 seconds, the old path-based timing really wasn't up to the task. The path nodes don't align perfectly with the visual finish line which could give some strange results if there was a photo finish. To be fair these new checkpoints would only add 20 or so objects to a track but when I mentioned them to Eric he did talk about the shortage of object slots and that's why I decided to get down and sort that out. Actually it turned out not to be too bad, as in recent years the obstacles preventing me from changing to 32-bit object indices have been removed. Primarily it was the old 'optimiser' data that switched on and off objects as you drove around the track. It was huge data but now we use an occlusion octree that works in a different way and does not store the indices of individual objects.
There is more explanation in the log below. To illustrate the checkpoints update I have attached 3 screenshots. Because timing no longer relies on paths, it is interesting to note that open configs can now naturally do lap timing even without custom checkpoints being added. Paths still have some advantages such as instantly updated race position list and the colour coding for other cars on the small map, and these functions still work on configurations that do have a path.
Log of changes:
Skin downloads are now converted to DDS and saved from the download thread
- this reduces a graphical glitch when a skin is loaded onto a remote car
- simplified some texture loading code that was mixed up with skin saving
Cleaned up more code around texture loading and skin downloading
- the car's model is no longer rebuilt after its skin is downloaded
- instead the car holds a placeholder skin which is replaced behind the scenes
Support for ALPHA in section ends (tracks are made of segments between cross sections)
Fixed crash bug in the unused texture removal system (could remove some still in use)
Noticed a thread-related bug to do with setting the exposure while restarting
- game code does an 'illegal' D3D call that can cause corruption
Separated "set up lighting" into physical and graphical sections to fix the bug
- considered that this section of code has not yet been separated properly
- the physical part should be done every physics frame (sun could affect physics)
- graphical part needs to be done every graphical frame (shader constants, etc)
Realised that Eric was spammed with too many code-related debug messages in editor
- added a debug level option so he can see more relevant but not excessive messages
- used special macros to simplify the adding of messages for 3 different debug levels
- searched for and updated around 600 debug messages to use the new switchable system
- removed obsolete messages, e.g. a config without a defined path is valid these days
Encountered a thread-related crash, again during restart (clash with drawing humans)
Fixed a zoom bug in one type of trackside TV camera (probably was there a long time)
Removed another thread warning message that appeared in track editor (on undo or load)
Made car ambient shadows, lightmap lighting and headlight effect work in track editor
Considered a new timing system that uses proper checkpoints like in the layout editor
- existing timing is based on path nodes and is misaligned with visible finish lines
- Eric mentioned a concern with the number of objects in map approaching a hard limit
Converted object indices to 32-bit to increase the number of objects that can be added
- previous 16-bit indices only allowed a maximum of 65536 objects to be added to a map
- number includes objects, buildings, cameras, track cross sections and segments, etc.
- in the past the occlusion data relied on object indices and took up a lot of memory
- now we have a totally different occlusion system that storage issue no longer exists
- it took only a bit more than a day to update the remaining object indices to 32-bit
Moved onto the new system that allows accurate alignment of checkpoints and finish line
- started by analysing all path nodes over marked track segments to detect checkpoints
- this produces many checkpoints, often duplicates, e.g. a finish line for every config
- the duplicate checkpoints are combined and config switches enable them appropriately
- this leaves fully working checkpoints that Eric can adjust to improve accuracy
- worked on the editor side of it (the checkpoints are a type of invisible object)
- on the driving side, checkpoint detection use existing code for layout checkpoints
- timing is no longer path-based but paths have uses, e.g. instant race position list
- interestingly open configs can now do timing even without adding custom checkpoints
FGED GREDG RDFGDR GSFDG