Testing v8.004

[eric]

I'd rather find errors so they can be fixed. This is a flawed engine shape.

Next version 8.004d will have a setting to ignore the errors and autocorrect them.

[rdayt]

Eric, I'm not sure I fully understand what you mean.
This is the way I work.
I have 10,811 unique shapes in my master shapes folder that I share across four routes I tinker with. These shapes are from all over the place.
Most of them require a little work on the textures to make them fit in better where I intend to use them. Almost all of them utilize .ace textures.
When I find a shape I want to use that needs a little modification I'll open it in Shapeviewer and export the texture or textures that need work.
When I'm done I save the texture/s as a .dds and go on my merry way. Sometimes, if it's handy, I'll go ahead and delete the .ace.
I never touch the shape file. It's not a big deal to change the .ace to .dds in the texture name but there has never been a reason to do it.
It works the same in the Trains folder. I only change the textures that need it so I have a mixture of .ace and .dds textures in the equipment folder. OpenRails sorts it all out. TSRE, not so much.
The only time I touch the shape file is when I actually change the name of the texture, not the extension.
I have thousands of examples of this.
If TSRE is going to error out on the wrong texture extension name I'm in trouble.

Randy

[eric]

It's going to log an error if your shape calls for an ACE and there isn't an ACE. Likewise if it calls for DDS and its not present.

If you want it to swap when the specified suffix isn't available, simply use the override that will be in 8.004d.

imageSubstitution = true

[eric]

Also in 8.004d.... for the Consist Editor, mass calculations should be a little more usable.

An earlier idea to specify a threshold and divisor gave way to using actual values and normalizing to metric tons.

[I] Eng.cpp 253 BLW_E8B_IC_4105.s  Adjusted Mass:      138.346  was  138346kg
[I] Eng.cpp 253 BLW_E9B_IC_4106.s  Adjusted Mass:      138.346  was  138346kg
[I] Eng.cpp 253 BLW_E9B_IC_4108.s  Adjusted Mass:      138.346  was  138346kg
[I] Eng.cpp 253 NAVS_ATSF_Hilevel_Baggage.s  Adjusted Mass:      60.782  was  134000lb
[I] Eng.cpp 253 NAVS_ATSF_Hilevel_Baggage.s  Adjusted Mass:      60.782  was  134000lb
[I] Eng.cpp 253 NAVS_ATSF_Hilevel_Baggage.s  Adjusted Mass:      60.782  was  134000lb​
[I] Eng.cpp 253 WP_WOODCHIP_5103_LD.s  Adjusted Mass:      96.1617  was  106t-us
[I] Eng.cpp 253 WP_WOODCHIP_5103_MT.s  Adjusted Mass:      30.1186  was  33.2t-us
[I] Eng.cpp 253 WP_WOODCHIP_5110_LD.s  Adjusted Mass:      96.1617  was  106t-us
[I] Eng.cpp 253 WP_WOODCHIP_5110_MT.s  Adjusted Mass:      30.1186  was  33.2t-us

[pschlik]

On the topic of textures, it is a "feature not a bug" that a shape calling for .ace textures will load a .dds of the same name. This was introduced to ease the transition between .ace and .dds textures as one shape could load either depending on a now-depreciated setting in the options, letting the user decide which format they preferred (folks are very stuck in their ways, but we all know that). Some creators got creative and made sets that would load up fine in MSTS or OR, just with less compressed textures in OR, by including .ace shapes and both texture formats simultaneously. That's not a flawed shape, that's working as intended.

Now the reverse does not happen, at least not yet. That is worth throwing a warning for since that will actually cause trouble, as many people have found when they try to install an MSTS freeware route in the same install as any TrainSimulations route. I swear someone has tried to move forward with allowing .ace textures to be used as a fallback for a missing .dds but that just didn't go through and I don't know why. A texture is a texture, and automatically picking the best texture for the moment has the exact same effect as modifying the shape file or converting textures but doesn't punish every user who doesn't understand a 20 year old file format and the 5 different 20 year old programs required to manipulate it.

[docmartin]

Be sure to have backups of your Trains and Route folder before testing with it. TDB corruption may occur with testing versions.

Sound advice. I've been placing new track in v8.003c and have found that this version fails to save to the .tdb file correctly with the result that OR crashes.

Martin

[eric]

On the topic of textures, it is a "feature not a bug" that a shape calling for .ace textures will load a .dds of the same name.

With the new toggle "imageSubstitution = true" then TSRE will do so again. Those of us purists can continue to turn the substitution off to discover errors.

Here's the problem: TSRE was doing substitutions in both directions --

1. a DDS for a missing ACE
2. an ACE for a missing DDS

TSRE has gone by what the shape defines, so if you've provided both, it's only calling what the shapefile defined.

A texture is a texture, and automatically picking the best texture for the moment has the exact same effect as modifying the shape file or converting textures but doesn't punish every user who doesn't understand a 20 year old file format and the 5 different 20 year old programs required to manipulate it.

In the context of rolling stock, this approach doesn't punish the end user.

In the context of scenery..... it's an issue. Textures are in a common directory, so if someone has "warehouse.ace" and someone else has "warehouse.dds" then it's not going to be flagged on installation as a conflict, but ORTS will presumably load the wrong texture within the game unless it's managed to fence that processing off to only rolling stock. If someone knows for certain, feel free to chime in.

Regardless, TSRE hasn't been choosing the higher quality image unless it's defined. Doing an automatic upgrade isn't rocket science, but would a few more lines of code and possibly a new setting switch to enable/disable for those who want to find actual errors in their work.

Now the reverse does not happen, at least not yet. That is worth throwing a warning for since that will actually cause trouble, as many people have found when they try to install an MSTS freeware route in the same install as any TrainSimulations route. I swear someone has tried to move forward with allowing .ace textures to be used as a fallback for a missing .dds but that just didn't go through and I don't know why.

I was actually fighting for the reverse, so that you could mix and match TrainSimulations.net routes in a common folder vs a dedicated content installation.

At the pace things seem to move as far as changes in ORTS, I'd have to re-install VisualStudio and re-learn C# to try and make it happen anytime soon.

[eric]

Sound advice. I've been placing new track in v8.003c and have found that this version fails to save to the .tdb file correctly with the result that OR crashes.

Martin

docmartin I don't remember releasing a version 8.003c --- are you referring to v8.004c which was released on the 19th or 8.004b which was released on the 17th?

There were definite issues in 8.004a and most versions of 8.003.


That should be corrected starting with 8.004b --- if you have a route which appears corrupted, what's worked for most people is to

1. Open and save your route using TSRE v8.002 or any version of TSRE 7.0
2. Open the route in OpenRails to confirm it's a legible TDB
3. Re-open it in 8.004b or higher.
4. Make changes to delete track and add new track (you need to both delete an older node and add new nodes for the problem to materialize)
5. Open the route again in OpenRails to confirm the TDB is still legible

Step 1 should correct any discrepancies causing OR to crash, and Step 2 will confirm it quickly.

That's confirmed as working from users over on ElvasTower as well as here.

Opening in 8.004b or 8.004c has worked for me to recover, and two users here confirmed the same back on the 17th.

(root cause was identified as a mismatch between the value shown in the TrackNodes field and the actual count of tracknodes read from the TDB resulting in an index out-of-bounds error)

If there are still issues occurring, I need to know where in those steps above it's failing.

[eric]

Testing version 8.004d is available
-----------------------------------------------
Mass calculations into metric tonnes for commonly supported units (lb, kg, t-us, t-uk)
Reduced logging messages while debugOutput = false

New settings tokens to disable ORTS texture handling:

imageSubstitution = false

imageUpgrade = false

No need to set either one unless you want to use explicit textures as defined in the shapefile

[docmartin]

docmartin I don't remember releasing a version 8.003c --- are you referring to v8.004c which was released on the 19th or 8.004b which was released on the 17th?

My typing mistake - yes, of course I meant v8.004c. Anyway, we shall see whether the problem persists in v8.004d.

Martin

[eric]

Let me know.

To help validate, I downloaded the Chiltern update that was synch'd 8 hours ago. It opened fine in ORTS after downloading. I made multiple track add/deletes and saves in TSRE 8.004d, and each one opened fine again in ORTS.

Hopefully you get similar results.

[Icik]

8.004d works for me. But I had to adjust the imageSubstitution option = true to settings.txt, otherwise TSRE was not stable and overwhelmed all RAM.

[docmartin]

Many thanks, Eric, for taking the trouble to test v8.004d with my route. I agree that this version seems be to saving to the .tdb just fine.

Martin

[eric]

otherwise TSRE was not stable and overwhelmed all RAM.

Odd... was the route in the library or your own creation?

[Icik]

Hi eric,
I'm sorry, I meant the "imageUpgrade = true" option. I have no idea why I had microtex.dds texture in the TERRTEX directory in each route. And that's where it collapsed. After deleting the texture of the dds, it's ok.

obrazek.png

obrazek.png