gpz, on 05 February 2014 - 03:33 AM, said:
Dave,
I'm just wondering why we should mess with these old .sd files at all. The modifications you propose mean a complete restructuring of the .eng format, which would mean we move away from it completely. Rather than trying to fit everything into the old format, a new tech data format specification could be made.
It is true a different file format could be created -- and in several instances should be created. In the meanwhile...
The only text file that is paired to every mesh file is the .sd; I'm of the opinion KUJU chose the letters .sd to signify shape description. They used it to designate texture replacement, calling it ESD_Alternative_Texture()... choosing to use a numeric code to designate a different path instead of a different filename. And so
the principle of texture replacement is already in place. What should, IMO, be different is how that principle is implemented as an expansion of what KUJU has already done: Rather than use incomprehensible numeric codes to do more put in into ordinary structured language -- SIMIS of JSON... it doesn't matter to me (whichever is technically better to use) and so to example how that could open up new features I've written a few examples... how to replace one texture format with another... how to replace one LOD value with another. Stuff each end user can do on their own. If you can accept that as a broader principle of what KUJU gave us then it is just a small step further to add brand new features to a shape that were never coded into the mesh file: Time of day for the use of night textures for example.
So let's step back for a second.... There are a number of attributes of each mesh that are fixed by its creator but are often a problem for different end users. One is the texture, another is the file type of that texture. Add, bias, LOD distance too. There isn't any place for an end user to alter those outside of
uncompressing the .s file and editing it which has certain risks attached to it. That need to change values becomes the question of where should such changes occur?
Now look at what KUJU saw as issues: how the mesh file dealt with seasonal textures, how the mesh file dealt with assembly of meshes, and how the mesh file did not deal with display loads on the PC. They chose the .sd file to deal with those because the mesh file could not. So why not use the .sd file to deal with those issues where the what's in the mesh file needs to be altered? Or features that could not be put into the mesh file?
Moving that new principle over to .wags and .engs reveals other possibilities... most useful of which is normalizing the data found in .wags. I don't know about your roster but most of my .wags are less than 100 lines line (no lights). I scroll down to around line 10, where IntertialTensor() is located and delete all of the remain lines. ALL of them. And then I plug in replacements: The same Coupler()data. The same Buffer() data. The same Brake() data. Friction & derailment data computed on total weight. New Name().
IOW 80-90% of what goes in is the same from one .wag to another. Have any idea of how many times ALL of that data got tweeked over the years as a better understanding of real world performance came to be expressed in MSTS terms? Loads of times. And EVERYTIME it did that work I resented the fact there were not a handful of standard reference files that contain that data in just one place: One coupler file to update, not hundreds.
Take one step forward: If there were those standard reference files... what's left of the .wag? Hardly anything. So little in fact what remains could have been put into the .sd of the car file. IOW it's quite plausible KUJU flattened the normalized data into a single file -- the .eng file because they had not anticipated the huge growth of content, the huge frequency of reskinning, or the huge amount of corrections to their original data that would occur. If they had known what would happen (and let's not be too harsh, crystal balls aren't too easy to find) they probably would have left the data normalized and there would not be a .wag file. Plausibly, no .eng either. But now there is a E_Type_Coupler.sd and a D_Type_Coupler.sd. Why not add .s file to go with them? Have to figure out how to do an assembly but that shouldn't be too hard to do. Right?
But that's not what we've got and so the question should be this: Is the KUJU design the go forward solution or are there good enough reasons to re-think it? For me, the answer is obvious: OF COURSE it should be re-thought because it opens up huge avenues of opportunity (equally obvious is that is should not released before 1.0).
Is the objective to do MSTS and let it go at that? Or finish MSTS compatibility and move on to Open Rails? If the later, then ignore all of my ideas (which AFAIK is the only result that has occurred). If the later... are there aspects that can be useful to do before 1.0? Yes: Texture replacement, LOD replacement, Time of day for using night textures... all of those can be implemented
at any time -- and the ideas were proposed several years ago -- w/o interfering in any way w/ MSTS compatibility.
And so yes, the .sd files, an appendix to KUJU's work, are indeed important. The final OR version need not be called .sd but there should be one user editable "text-like" file that goes with each mesh file that allows people to enhance, alter, or turn off certain features encoded in the mesh. As for .wag and .eng files... if you look at how much of them is really in the mesh (e.g., wheel diameter), implied by the mesh (e.g., boiler capacity), or too application specific to put into the mesh (e.g., what to do with lights when a penalty occurs)... what are they but great big .sd files passing themselves off under another name?
Log In
Register Now!
Help
