How many TSRE's do we have now?

[TrainSimJack]

Hi,

Just noticing a few posts on here about TSRE - if I'm reading correctly do we now have 4 different versions?

Original TSRE
TSRE based on QT6 by Goku
Eric's TSRE
Scott's TSRE

With all these versions, it might help to have a sticky post with a title like "Which TSRE to choose" or something like that.

Open Source is great, but the downside is that multiple different forks dilute and devalue the code as a whole.
Also I could not quite tell, but is Goku back and doing new updates to his version now as well?

- Jack

[eric]

I look at it this way.... there are more versions of ORTS than there are TSRE...

If there's a fault with how TSRE evolved, it's that it serves a too many different constituencies. There are activity builders, route modifiers, route creators, and consist builder/modifiers. There are multi-editor users, there are Linux and Mac users. Each of us use the tool slightly differently.

Personally, I'm fine with this -- I'd much rather have lots of innovation taking place knowing that the three active versions can and will eventually see some convergence or at least some code sharing and merging of features/functions.

Just as an example, the work Goku did earlier in 2026 to bring DDS support into TSREvc already found its way into my iteration of the QT6 fork. I'll probably do a deeper comparison at some point between his master and my fork to see how much more convergence is possible. Likewise with Scott's code texturing and activity code.

I'd much rather see this than what happens with ORTS, where feature sets get sidelined by other sprints... right now, all three of these versions can co-exist fairly easily.

And yes, it does appear Goku is back to some developmental features, including spline track and now dynamic roads, both of which are pretty cool. Not sure if I'd use either of them, but it's good to know the option is there.

[CSRX]

It's better to have too many editors, than none at all from other sims... Shrugs.

[TrainGuy6550]

As the situation stands right now, I'd say
eric's version for serious projects
scott's version because it looks cool and has a TON of improvements
goku's tsre5vc if you want gltf support
original version can be left behind (use eric's instead)

I'm currently using scott's version... :-)

[GokuMK]

I look at it this way.... there are more versions of ORTS than there are TSRE...

Exactly. In fact, multiple ORTS versions is an issue for content creator, because you have to think how to support all of them, or what to ignore.
More design tools is not an issue as long as those tools are free and you are not forced to pay multiple times for almost the same.

But, there are caveats ...

[scottb613]

Hi Folks,

Hah — and here I am with the opposite take — Open Source is the greatest thing that’s ever happened to this community. Without it, NONE of us would be here. We’ve already seen what proprietary software does — MSTS, MSTS2, DEMEX, MOSAIC — imagine if we had the actual source for all of those. Think how much further ahead we’d be today.

For developers to graciously share their source with the community — after countless midnight struggle sessions — alone — lit only by the glare of the monitor — wrangling the code to make it behave — for days, weeks, or years — for no other reason than to make life a little better for a couple hundred people they’ve never met — that’s something else. I can’t thank Piotr and Eric enough — along with the rest of the Open Rails development team.

I started this because Jerry was always lamenting the poor terrain control in TSRE compared to MSTS — and he wasn’t wrong. Once I decided to take a look, it took a while to get my bearings and get all the tools lined up to finally produce a clean compile. After spending that time, I thought: “Why stop there?” And when one little drink turns to shots — grit your teeth — off you go.

I don’t think we’re “diluting” the code base. Forks are what allow innovation, not what prevent it. If anything, the couple hundred people who might look at this will now be split or diluted — making our efforts *seem* less worthwhile. But the code itself? I think we all try to clean it up as we go — make it better, tighter, more efficient. Eric already said it, and I strongly agree — when you give code a hard look with fresh eyes, with feedback and experience from actual use, the second‑gen code is almost always better than the first.

Just my 2 cents.

Regards,
Scott

[TrainSimJack]

It's better to have too many editors, than none at all from other sims... Shrugs.

Why what other sim could you possibly be referring to?

[railrunner112]

I did not realise there were different ones, so a good list for them and what they differ would be nice. Personally I dont mind different editors when I can use them together, once one starts to bite the other it becomes a bit more difficult but I assume that is impossible since they all work for the original Open Rails version. (Having said that I still hope the new year mg environments one day end up in the default OR but that is off topic.)

[rdayt]

Actually, I'm still using v0.689. But I'm about to make a big leap.

Randy

[GokuMK]

As the situation stands right now, I'd say
eric's version for serious projects
scott's version because it looks cool and has a TON of improvements
goku's tsre5vc if you want gltf support
original version can be left behind (use eric's instead)

Honestly, scott's version may be the choice to go for serious projects. He merges eric changes, so no lost features, he uses AI assistance, so less risk of code failure.
But not yet today.

AI doesn't understand all TSRE secrets perfectly yet, so today there is still risk of failed feature implementation. The curse of no documentation.
But the progress is very fast. I expect next year, top models will be able to handle everything well even without docs.

My vc version only for cutting edge experimental features. I am not interested in developing UIs etc.
And for data stability.

[eric]

I've used AI heavily for most of V8.005 and almost all of 8.006, including the QT6 deprecation remediation.

The entire settings dialog and the launcher were done in Gemini, and I had an entire blueprint done in Claude to migrate to C# and get away from QT.

Sent from my SM-S911U using Tapatalk

[Brot]

very confusing

[TrainSimJack]

Hi Folks,

Hah — and here I am with the opposite take — Open Source is the greatest thing that’s ever happened to this community. Without it, NONE of us would be here. We’ve already seen what proprietary software does — MSTS, MSTS2, DEMEX, MOSAIC — imagine if we had the actual source for all of those. Think how much further ahead we’d be today.

For developers to graciously share their source with the community — after countless midnight struggle sessions — alone — lit only by the glare of the monitor — wrangling the code to make it behave — for days, weeks, or years — for no other reason than to make life a little better for a couple hundred people they’ve never met — that’s something else. I can’t thank Piotr and Eric enough — along with the rest of the Open Rails development team.

I started this because Jerry was always lamenting the poor terrain control in TSRE compared to MSTS — and he wasn’t wrong. Once I decided to take a look, it took a while to get my bearings and get all the tools lined up to finally produce a clean compile. After spending that time, I thought: “Why stop there?” And when one little drink turns to shots — grit your teeth — off you go.

I don’t think we’re “diluting” the code base. Forks are what allow innovation, not what prevent it. If anything, the couple hundred people who might look at this will now be split or diluted — making our efforts *seem* less worthwhile. But the code itself? I think we all try to clean it up as we go — make it better, tighter, more efficient. Eric already said it, and I strongly agree — when you give code a hard look with fresh eyes, with feedback and experience from actual use, the second‑gen code is almost always better than the first.

Just my 2 cents.

Regards,
Scott

Thanks Scott - It's definitely exciting to see the innovation and progress being made.

Rereading my original post - I think that second to last sentence could have been more clearly written.
I'm with all of you on the value of open source - and did not mean the code itself was less valuable as a result of the forks, It was really more about what you might call "Brand dilution"

Multiple concurrent active competing forks dilute the brand, make it harder for outsiders to understand what they should be using, what's available, what's been abandoned, etc..

What's being done here is great, but the sooner this can be consolidated into a single code base, the better. Nothing would be better for the community than to have Everyone working together on the same code base - with a single TSRE release, that everyone could safely download the latest version of without worrying about who's version they should download.

My 2 cents - still love what you're all doing here.

[eric]

Right now, the casual user will get the same functionality and experience regardless of the version, because +90% of the code is identical.

With all three seeing development and testing, I’ll acknowledge that indeed could be confusing, but at least we are all aware of each other’s efforts and it’s all in GitHub to see. I have no idea what has been done with some of the forks in India or China, which do exist from what I’ve heard.

Again, we all thought this was dead in 2023. To be able to argue about which new variant is best is a blessing, not a problem.

[GokuMK]

I've used AI heavily for most of V8.005 and almost all of 8.006, including the QT6 deprecation remediation.

The entire settings dialog and the launcher were done in Gemini, and I had an entire blueprint done in Claude to migrate to C# and get away from QT.

I would not trust Gemini, it is too stupid for TSRE. For frontend UI may be great, but not for the backend. I test new models regularly and first that could understand TSRE right, was GPT 5.4 xHigh. 5.5 was a disappointing regression, but 5.6 sol is another impressive improvement in understanding TSRE. I know my code well, so I can see who is wrong in their thinking and who isn't. This helps a lot.
Claude opus models are probably good too, but I don't test them, because they are too expensive.