SLI Poll Results

[R. Steele]

This is from the polling done on the SLI website....

bandicam 2016-06-18 09-02-41-266.jpg

[smiljacc18]

Hopefully SLI will now produce content that fully utilizes OR's full potential That is what OR needs for the future.

[MCDemuth]

Hopefully SLI will now produce content that fully utilizes OR's full potential That is what OR needs for the future.

Huh?

Do you mean...

Stop making MSTS compatible content? With almost 40% of the voters still using MSTS, that doesn't sound like a good business decision.

or Do you mean...

With 87% of the voters now using Open Rails, TrainSimulations should start taking their Open Rails compatible content to the next level, and start designing it to utilize more of the unique features that are available in ORTS?

[CSRX]

Honestly, going straight to Open Rails only, would be a smarter choice. In my opinion.

[lateagain]

Huh?

Do you mean...

Stop making MSTS compatible content? With almost 40% of the voters still using MSTS, that doesn't sound like a good business decision.

or Do you mean...

With 87% of the voters now using Open Rails, TrainSimulations should start taking their Open Rails compatible content to the next level, and start designing it to utilize more of the unique features that are available in ORTS?

Totally agree as I use both.

However apart from the physics surely until TrainSimulations (as SLI are now called) could include engs and wags for both UNTIL such time as they produce models that NEED OR to run? They've already got the MSTS physics so all that's required is to pack OR physics and make the selection optional. For whatever reason folk could then use the same stock in a route used in MSTS and others used in OR. It doesn't matter if some folk don't see the point right now because late adopters will benefit when they switch to OR and those already using OR exclusively can delete unneeded files.

EVERYBODY happy? What's the problem?

[PerryPlatypus]

Totally agree as I use both.

However apart from the physics surely until TrainSimulations (as SLI are now called) could include engs and wags for both UNTIL such time as they produce models that NEED OR to run? They've already got the MSTS physics so all that's required is to pack OR physics and make the selection optional. For whatever reason folk could then use the same stock in a route used in MSTS and others used in OR. It doesn't matter if some folk don't see the point right now because late adopters will benefit when they switch to OR and those already using OR exclusively can delete unneeded files.

EVERYBODY happy? What's the problem?

Furthermore, OR already has the option to have a folder named "OpenRails" within each engine (and probably rolling stock) folder that has a copy of the .eng file in it, but with everything modified to adhere to Open Rails' way of doing things. When OR sees the .eng file within this OpenRails subfolder, OR will only load that one, and not load the main one. And when running MSTS, the OpenRails subfolder is ingored. A win-win!

[crstagg]

Furthermore, OR already has the option to have a folder named "OpenRails" within each engine (and probably rolling stock) folder that has a copy of the .eng file in it, but with everything modified to adhere to Open Rails' way of doing things. When OR sees the .eng file within this OpenRails subfolder, OR will only load that one, and not load the main one. And when running MSTS, the OpenRails subfolder is ingored. A win-win!

Not actually the way it works. OR loads the data from the .eng file in the main folder and then replaces it with data from the .eng file in the OpenRails folder. The .eng file may or MAY NOT be a "complete" .eng file. Also whatever is on the Name line in the .eng file in the main folder is what will be on the list of engines to be selected to drive NOT what is in the Name line on the OpenRails folder .eng file.

[PerryPlatypus]

Not actually the way it works. OR loads the data from the .eng file in the main folder and then replaces it with data from the .eng file in the OpenRails folder. The .eng file may or MAY NOT be a "complete" .eng file. Also whatever is on the Name line in the .eng file in the main folder is what will be on the list of engines to be selected to drive NOT what is in the Name line on the OpenRails folder .eng file.

Understood. In my opinion, this is still fine, I don't see any drawbacks from doing this, as having the name stay the same alleviates the need to create new consists specifically for OR that use a separate .eng file. That way someone can run older consists designed for MSTS and it will automatically load any replacement data from the file in the OpenRails subfolder, no need for an OR-specific consist.

[crstagg]

Understood. In my opinion, this is still fine, I don't see any drawbacks from doing this, as having the name stay the same alleviates the need to create new consists specifically for OR that use a separate .eng file. That way someone can run older consists designed for MSTS and it will automatically load any replacement data from the file in the OpenRails subfolder, no need for an OR-specific consist.

Yes there is no need for a "OR consist file," but not because of the reasons you state. The engine file's Name line has nothing to do with it. Consist files do not use the data from .eng or .wag file. Consist files identify the contents of the consist by the filename and folder name NOT by the Name line data.

[trainman_47]

I agree. Why not simply produce both? There still making money off the other 40%.

[baldwin]

As MSTS ignores what it is not programmed to read in an eng file, there is no need for a separate Open Rails sub folder with another eng file unless you are going to use includes for common data structures.

[geepster775]

Its not 40%. Its only 14% that would truly lose out if they went O/R only. If I were them, I'd drop MSTS. As the feature sets of both sims diverge more, it will be increasing the workload to custom tailor products to service both sectors. To me, the 14% wouldn't be worth the added time commitment.

[gkhager]

That is sort of discounting the fact that maybe the people who claimed to use both sims want products that can work in both sims. I know that that was what I meant by putting both! Sometimes I like using MSTS and sometimes I feel like running in OR and I would like my stock to work in both for the time being. As OR only features come online, than I can see a time when things will not work in MSTS.

Also, I do not require the models to be 50,000+ polys. Maybe I am of the minority here, but there are many fine examples of shape files within MSTS that are very realistic for all but the most hardcore rivet counters.

Geoff

[crstagg]

Also that is discounting the numerous posts about Exhaust not looking correct. OR needs the exhaust parameter data tweaked. This is the same lines MSTS reads and uses BUT the values need to be different.

[geepster775]

But if I'm a vendor, I will prefer selling some additional packs that include patched ENG files for previous MSTS-only releases to bring them up to OR standards. The SLI Priority Z train set added a handful of stock, new engine numbers, and added another activity for Seligman 2, but it also included a bunch of shape patches to fix the container cars that were undersized. Point being, they "sold" fixes in the past, and there is plenty of opportunity to do more of that in the future.

Besides, smoke is the least of the concerns. Things like the Maxpower line, which has to be native in Open Rails but is "compromised" by a manual efficiency calculation for MSTS ENG files has the propensity to over-power and under-power and screw up activity timings if you use a one-size-fits-all ENG file for both sims.

and I would like my stock to work in both for the time being

Then I would sell for OR and put any added burden of making any eng file modifications like a reduction to the Maxpower value so trains don't over-power when run in MSTS on the backs of the 26% who "like things to work in both for the time being". If I were them, I wouldn't carry that on my back.

Up until now, its been on the OR'ers to make the file mods on their own if they wanted their stock to perform accurately in OR. And many, once making the changes, appear to leave MSTS behind. Woah the pain if that modification burden ever gets shifted to the smaller percentage of "dualers" and MSTS'ers.