Genma Saotome, on 09 July 2020 - 04:54 PM, said:
There have been posts in teh past arguing the .s format is easily extendable (tho nobody has tried). I always wondered what exactly was possible given the OR team does not have it's own 3dmodeling software.
I dunno... seems like it would get a monkey off the OR teams back. It's not like there is an unlimited about of volunteer time available to modify both old and new. IMO it's a perfect opportunity to do a Marie Kondo culling: "Thank you OR-MSTS for teaching us how to do a train simulator", bow humbly, give it a url and move on to newer and better accomplishments.
The benefit to keeping the S format is that all of the available programs can export to it. Switch to obj and us GMax users need to:
A. Fork over $180 per month for 3DS
B. Export from two or three different programs, probably losing animations and smoothing along the way
C. Switch to Blender, which has a clunky interface, makes simple tasks unnecessarily tedious (like hard edges), and can't perform some basic UV mapping functions (for example, a simple planar map at a definite resolution of 1/4 inch per pixel). Blender is geared towards people making sci-fi and figure models, not people building scale replicas.
Got news for y'all - a third of the five or six people actually building models for OR are using GMax. If the S format is capable of supporting new features, there's no point in changing formats just to look cool and modern because we're using some perceived "standard."
Genma Saotome, on 09 July 2020 - 09:37 AM, said:
Yup.
This does beg the question of how does the model file gain enhancements when the 3dmodeling software does not export into .s?
How do we add winter, night, and other maps to existing models? The only other major enhancement beyond materials that I can see is possibly attach points, but that's something that can be handled with dummies and part names. The thing is there isn't a huge difference between most model formats besides how data blocks are organized anyway. You could argue that other formats and new exporters could allow us to hard code in new animations, sort of like the XML code in MSFS, but it's actually kind of ridiculous that animations are hard-coded into models anyway. Why don't we script rolling stock animations the way route builders script signal animations? Even in the MSFS world, it was always more efficient to have gauges controlling the custom animations, which is why a lot of developers stopped hard-coding their parameters into the XML code for their parts, instead opting to have it scripted externally. For our purposes, there should be an animation script file, much like an SMS files, that defines part names, animation triggers, looping and playoneshot parameters, speeds, and so on, that controls animations. You name your parts whatever you want, use however many frames you want, then define the script file to use in the ENG file, and the script file parses the part names and commands the model accordingly.
It also strikes me as somewhat absurd that, passenger views notwithstanding, we're limited to two SMS files per piece of stock. It's absolutely insane that every SMS files I write has to have the same control sample streams in it instead of a single, dedicated SMS file for control samples, another one for the horn, and the ability to tag individual streams as internal or external in a single SMS file (which may be possible already, I've been meaning to experiment). Users wouldn't need to edit SMS files to change a horn out, I'd simply release horn packages with their own dedicated SMS files to be inserted into the ENG file at-will.
I'm digressing a bit. I'm afraid you've poisoned my thinking with your common.fleet idea, and I keep thinking about how we could, in the future, perform most functions with plug'n'play modules like I am presently doing with physics, instead of a single, large file with loads of data in it for each function (ENG, SMS, WAG, et c).
Anyway, given the fact that the S format can do what it might conceivably need to do if we gain more advanced materials, the pro/con list looks like this:
PROS:
-The format is already well-understood by content developers and the platform's developers
-The format can be adapted to whatever additional features are added in the future
-All available modelling programs can export to it
CONS:
-The techwarrior iCrowd™ Dudebros feel it makes the sim seem less "contemporary" and doesn't give it "cool feels brah"
From where I sit, that's not a difficult choice.
Anyway, I don't see why anybody would worry about alienating the die-hard MSTS crowd. They're all using MSTS and make sure to loudly point it out any time there's a new OR-only release... ad nauseam.