Lol Dave => "It was great with movables001...999.ini. Why was that abandoned?"
You got the answer to your question
Well, there are pros and cons. Having a feature there that doesn't have to be used isn't damaging developers unless they want that complexity for larger projects.
For example, like in the head of shader files, or defining pacejka sets for car tyres, we can nest common data. This is fantastic for movables, since if we have 200 cones on a track then we can condense 200 entries for hit box type, inertia and mass, in one place.
However, currently, Racers trackEd tool will unravel ALL nested information, even if it information in that files is not altered.
That alone makes a 5kb movables file a 70kb movables file and much harder to change a simple inertia or mass value for the cones.
Throw that information into the geometry.ini file and suddenly you have a mess you don't even want to begin editing either in trackEd or by hand!
These are not problems in an environment where you are not developing but simply pushing ONCE to a final build... but they are massive problems when you don't know how much inertia to set for your cone types, or tyre types, or what bounding box types change the performance best, or simply testing and looking for bugs.
So it's not so much about having too many files, but having the ability to break things up sensibly to make development/bug fixing nice and easy, and give that content flexibility in deployment.
Right now I have about 10 cone layouts on my track for various test layouts or track layouts, but rather than store 10 small 5kb files that users can happily swap in and out of the folder, I have to have 10 large geometry.ini files that ALL have to store 95% of the same data, be maintained as such, just to have the different layouts.
Ideally I want MORE layouts and more custom things like scripts running for each one too (to reset the slaloms etc), but it's just mad trying to bug-fix and develop and maintain 10+ geometry.ini files when I only really want to be editing a tiny part of it for these things.
It's a difficult situation. Ruud has historically added things that give flexibility but then removed them for clarity, when they were no harm simply being passive features IF people still wanted to use them.
I believe this is a case where movables.ini files could be used by an author to allow more flexible diverse content, be put in the track skins folder on their own, and the data found in them is simply appended to the geometry.ini at runtime
(Ruud has mentioned this is easy and it makes sense
)
I'm all one for simplicity and clarity, but development speed and flexibility are also important in a development environment where we have no 'formal' tools to use that allow us easy management of these HUGE data sets and entries we end up with!
Everything post 3D export is currently lossy in Racers development environment. Stuffing everything into one big ini file is then even more demanding on developers time... then having the Racer tools destroy nesting to make life even HARDER during development is even more silly
I think things should be able to be all together OR split up, to make the life easier for developers... ie, the addition of multiple models for a cars body improved artistic possibilities massively, yet it didn't add complexity for those who didn't want to use it, they simply ignored it
Dave
