TSRE GenX - MAX OVERHAUL

[tarrant75]

Okay. Reason I ask is that one of the tiles says it has either been baked or is missing OSM data (the tiles around it are fine as far as OSM). The stupid part is that there is no vegetation on the tile yet.

[yellowdog]

I found a potential limitation with the GenX Consist Editor (I'm currently using v0.18). With other versions of TSRE, I can load an independent Consist Editor, which then lets me point to basically any folder I want. This allows me to access a TRAINS folder that I set up to use with mini routes via Junction Link, that doesn't live in a traditional MSTS file structure. GenX doesn't have the stand-alone Consist Editor, and then requires me to point to a MSTS-Typical Root folder before it gives me the option to open its Consist Editor. I tried creating dummy Routes and Global folders alongside my independent TRAINS folder, but that didn't work. I also tried copying/pasting the consisteditor.bat from another version of TSRE to the GenX TSRE folder, which also didn't work/load.

[scottb613]

Okay. Reason I ask is that one of the tiles says it has either been baked or is missing OSM data (the tiles around it are fine as far as OSM). The stupid part is that there is no vegetation on the tile yet.

Hi Chris,

Thanks for the reports — I’ve checked the planting code, and there’s something on my side that needs improving.

The current Area and Ruler tools still depend on the OSM cache, even when using the forest-coverage override. That override bypasses the mapped forest boundary, but it still loads the mapped exclusions. So it isn’t yet a completely independent manual planting mode.

That could explain some of the planting difficulties. However, a tile reporting that it is baked or missing OSM data doesn’t establish which condition is responsible, and I wouldn’t assume the JSON is corrupt without checking it.

I plan to rework PolyVeg so users can switch OSM off entirely and rely on the Area tool or Ruler to define where vegetation goes. With OSM disabled, missing map coverage or mapped exclusions should not prevent manual planting. Density, spacing, slope and the other planting controls would remain available.

I also want better error reporting — identifying the actual file and problem, and clearly distinguishing missing data, invalid JSON, no suitable planting positions and existing baked vegetation.

Along with that, I’ll look at a controlled way to rebuild faulty generated JSON caches from their source data, and make the tile reset/replant process clearer. Rebuilding a cache should preserve the user’s planting definitions and existing route work.

These are planned changes — I still need to work through and test them. The goal is to give route builders more direct control and make it much easier to understand why an operation was stopped.

Regards,
Scott

[scottb613]

I found a potential limitation with the GenX Consist Editor (I'm currently using v0.18). With other versions of TSRE, I can load an independent Consist Editor, which then lets me point to basically any folder I want. This allows me to access a TRAINS folder that I set up to use with mini routes via Junction Link, that doesn't live in a traditional MSTS file structure. GenX doesn't have the stand-alone Consist Editor, and then requires me to point to a MSTS-Typical Root folder before it gives me the option to open its Consist Editor. I tried creating dummy Routes and Global folders alongside my independent TRAINS folder, but that didn't work. I also tried copying/pasting the consisteditor.bat from another version of TSRE to the GenX TSRE folder, which also didn't work/load.

Hi…

Thanks for pointing that out — your shared TRAINS folder setup sounds perfectly reasonable, and you shouldn’t need to create a dummy route installation just to build a consist.

It sounds like GenX’s startup and folder-selection checks are getting in the way. I need to check the standalone launch path before I can say exactly why the copied batch file didn’t work.

I’ll look at restoring a straightforward way to open the Consist Editor independently and point it at your chosen train library, including the arrangement you’re using with junction links.

That requirement should be separate from the folders needed for route editing. No sense making you jump through extra hoops to use the Consist Editor.

Regards,
Scott

[yellowdog]

Hi…

Thanks for pointing that out — your shared TRAINS folder setup sounds perfectly reasonable, and you shouldn’t need to create a dummy route installation just to build a consist.

Once the junction link is created, GenX does recognize the linked TRAINS folder and seems to operate as expected. So maybe this is a non-issue, depending on how many other people access their stand-alone TRAINS folder?

[weichenpfleger]

Hallo, Scott
I’ve noticed that the Activity section of X18 doesn’t allow umlauts [M(ü)nster – M(ue)nster], which disrupts the syntax (Path ID/Service ID).
Could you please look into this, as umlauts are used very frequently in the German language and the older TSRE versions don’t have any issues with them.

Greetings

Franz

[tarrant75]

Scott, this is what I was talking about having issues with "baked tiles", which as far as I know this one hasn't.


image.png

[scottb613]

Hallo, Scott
I’ve noticed that the Activity section of X18 doesn’t allow umlauts [M(ü)nster – M(ue)nster], which disrupts the syntax (Path ID/Service ID).
Could you please look into this, as umlauts are used very frequently in the German language and the older TSRE versions don’t have any issues with them.

Greetings

Franz

Hi Franz,

Thanks for reporting this.

If the older versions of TSRE handle German umlauts correctly, there's no reason GenX shouldn't do the same. This certainly sounds like a regression we've introduced somewhere along the way.

My first suspicion would be a character encoding issue in the Activity Editor, particularly where the Path ID and Service ID are being read, modified, or written back to disk.

We certainly don't want users having to rename their German locations just to accommodate the editor.

I'm away from my development PC until Monday, but I'll add this to the list of things to investigate when I get home.

Thanks again for bringing it to my attention.

Regards,
Scott

[scottb613]

Scott, this is what I was talking about having issues with "baked tiles", which as far as I know this one hasn't.

Hi Chris,

Thanks for the additional screenshot.

The message is interesting. It appears that PolyVeg is finding no eligible planting positions after running its clearance and blocked-tile checks.

I'm wondering whether we're dealing with two related issues here — the existing baked vegetation data and the checks that determine whether a tile is available for new planting.

I'd be interested to know whether you're getting this message on tiles that have already been processed with PolyVeg, or whether it also happens on completely untouched tiles.

If it's only happening on previously processed tiles, that would certainly help narrow things down.

I'm still away from my development PC until Monday, so I can't dig into the code just yet. Once I'm home, I'll take another look at how we're handling the existing tile data and the planting eligibility checks.

Thanks for sticking with the testing. These reports are helpful in tracking down the remaining rough edges.

Regards,
Scott

[railrunner112]

So I ran the SCO LIDEX scan and run commands, the application closed (I assume it was finished.) but I get this error when I want to plant trees
Polyveg.jpg
all that got generated in the route folder was polyveg.json in the submap OPEN RAILS.

Am I forgetting something?

[scottb613]

So I ran the SCO LIDEX scan and run commands, the application closed (I assume it was finished.) but I get this error when I want to plant trees

all that got generated in the route folder was polyveg.json in the submap OPEN RAILS.

Am I forgetting something?

Hi…

Thanks for the screenshot—that helps.

LIDEX should remain open when it finishes, so closing by itself suggests something went wrong during the run. My first suspicion is that the OSM map data wasn’t generated. Processing could take hours, depending on the size of your route.

Let’s check that first. Open your route in TSRE GenX and press M. Does the map appear on the terrain?

Your polyveg.json file contains the vegetation schema you created in TSRE GenX—the shapes to plant, their sizes, and their distribution. LIDEX supplies the separate map data that tells PolyVeg where it can plant. Even ruler planting needs that data.

Before running LIDEX again, please save a copy of SCOLIDEX.log from your Desktop so we don’t lose the details of the failed run.

Then, in LIDEX, select the same route you’re opening in TSRE GenX and check BOTH:

• OSM / Map Tiles
• HD Map Tiles

HD Map Tiles gives you the higher-resolution map imagery; OSM / Map Tiles is the option that generates the map and PolyVeg data. If you’re only adding maps to an existing route, leave Route Tiles, DM Tiles, and HD Mesh Tiles unchecked. Leave Clean Tile Wipe unchecked as well.

Run Scan, then Run. When it finishes successfully, LIDEX should stay open. Your route should have an osm_data folder containing:

polyveg-polygons.geojson
polyveg-exclusions.geojson

If it closes again, or those files are missing, please send me:

• SCOLIDEX.log from your Desktop.
• The newest tsre-log-*.txt from the folder containing TSRE5.exe.
• settings.json and lastSession.json from your TSRE GenX AppData folder. Press Windows+R, enter %APPDATA%\TSRE, and press Enter.

Also let me know which versions of TSRE GenX and SCO LIDEX you’re running, and whether pressing M displays the map.

You can send the files by PM, since they may contain your local folder paths. No need to rebuild your vegetation schema at this point—let’s find out what happened to the map generation first.

Regards,
Scott

[scfe_fan]

Scott,

I just updated TSRE GenX to v0.18 and I see what I THINK is the telephone/telegraph pole auto place feature in it. Does it currently have any poles included? I'd love to wire up a route that is based in 1930's Florida.

[scottb613]

Scott,

I just updated TSRE GenX to v0.18 and I see what I THINK is the telephone/telegraph pole auto place feature in it. Does it currently have any poles included? I'd love to wire up a route that is based in 1930's Florida.

Hi Josh,

Yep - that’s the new SNAP Pole feature. It’s still a work in progress, but it’s functional and should be just what you need for your 1930s Florida route.

I included a sample telephone pole model as a separate download with the previous v0.17 release, along with a user guide explaining how everything works.

You can find it here:

https://github.com/scottb613/TSRE5-SCOmod/releases

Look under the v0.17 release for the SCOsnapPole example download.

The nice thing is that you’re not limited to my pole model. You can use just about any telephone or telegraph pole you want, including existing MSTS models modified to support the new system.

Making your own is actually pretty simple if you’re familiar with Blender.

The trick is adding attachment points to the model where you want the wires connected. These are simply named matrices (SNAP_1, SNAP_2, SNAP_3, etc.) positioned at the appropriate locations on the crossarms.

Once exported to an MSTS .S shape, GenX recognizes those points and uses them to connect the wires between poles. The SNAP matrices need to be preserved in the first LOD hierarchy of the exported model.

Pete has even updated his Blender exporter to recognize and preserve the SNAP naming convention, making the process considerably easier.

You can have as many wire attachment points as you need, and you can mix different pole models. The system matches corresponding attachment points, so you’re not locked into a single design.

For a 1930s Florida route, you could make a simple wooden pole with one or two crossarms, add the appropriate SNAP points, and you’re in business. Once you’ve made one, creating variations is pretty straightforward.

The included example is a good starting point. Open it in the Shape Viewer and examine the hierarchy to see exactly how I arranged the attachment points.

Give it a try and let me know how you make out. I’m particularly interested in seeing what people come up with using this feature.

Regards,
Scott

[scfe_fan]

Hi Josh,

Yep - that’s the new SNAP Pole feature. It’s still a work in progress, but it’s functional and should be just what you need for your 1930s Florida route.

I included a sample telephone pole model as a separate download with the previous v0.17 release, along with a user guide explaining how everything works.

You can find it here:

https://github.com/scottb613/TSRE5-SCOmod/releases

Look under the v0.17 release for the SCOsnapPole example download.

The nice thing is that you’re not limited to my pole model. You can use just about any telephone or telegraph pole you want, including existing MSTS models modified to support the new system.

Making your own is actually pretty simple if you’re familiar with Blender.

The trick is adding attachment points to the model where you want the wires connected. These are simply named matrices (SNAP_1, SNAP_2, SNAP_3, etc.) positioned at the appropriate locations on the crossarms.

Once exported to an MSTS .S shape, GenX recognizes those points and uses them to connect the wires between poles. The SNAP matrices need to be preserved in the first LOD hierarchy of the exported model.

Pete has even updated his Blender exporter to recognize and preserve the SNAP naming convention, making the process considerably easier.

You can have as many wire attachment points as you need, and you can mix different pole models. The system matches corresponding attachment points, so you’re not locked into a single design.

For a 1930s Florida route, you could make a simple wooden pole with one or two crossarms, add the appropriate SNAP points, and you’re in business. Once you’ve made one, creating variations is pretty straightforward.

The included example is a good starting point. Open it in the Shape Viewer and examine the hierarchy to see exactly how I arranged the attachment points.

Give it a try and let me know how you make out. I’m particularly interested in seeing what people come up with using this feature.

Regards,
Scott

Just reading this almost had me salivating. I'm definitely going to try it and see what I can come up with. The route I'm working on has several distinct version of poles, with some not even being poles at all, but A frames mounted on the side of a bridge.

images.jpg

[scfe_fan]

scottb613

Here was about 4 minutes worth of work with it..

Open Rails 2026-10-25 09-39-50.png Open Rails 2026-10-25 09-41-00.png Open Rails 2026-10-25 09-40-15.png Open Rails 2026-10-25 09-38-26.png