How To Make Realistic TSRE Consists with AI.

[UnionPacificGP60#1050]

Hello everyone,

I’ve found a new way to build more realistic consists using the existing tools, and I plan to share a clear tutorial on how I did it.

The reason I’m making this post and sharing a tutorial is because the current TSRE5 Consist Generator uses a largely shuffled or randomized approach that doesn’t always reflect how real-world consists are structured. While it works functionally, the results can feel unrealistic in terms of block grouping, car order, and operational logic.

What I’m doing is documenting an alternative method that produces more realistic consists using existing tools and manual logic, without modifying CE itself. The goal is to help others who are looking for more prototypical results understand a practical workflow they can apply today.

This isn’t about criticizing the tool or asking for changes to be made. It’s about sharing a workflow improvement based on observed limitations, so anyone interested in realism has another option available.

[UnionPacificGP60#1050]

Before we get into that there are some things I want to clarify

For those who followed the previous TSRE5 Content Editor (CE) discussion, “Will somebody create an AI-generated Consist for Open Rails Train Simulator?”, I want to revisit it with clearer context about my intentions. I fully understand why the original thread was closed, and I respect the moderators’ decision. I also want to acknowledge that some of my reactions during that discussion may have come across as impulsive or emotional, and I take responsibility for my part in the misunderstanding.

My goal here is not to reopen the debate, challenge any rules, or seek emotional support, but to explain why certain responses affected me and to help future technical discussions remain positively constructive and productive.

When I originally shared the idea, I genuinely believed it might be interesting, useful, or helpful with the community. I answered every question as best I could, despite having no experience contributing to complex tools like CE. Several replies focused heavily on what was unrealistic or impossible, and when multiple users echoed the same points in quick succession, it became overwhelming. That's why what I meant by feeling “hurt” was that I was frustrated because I wasn't getting the help that I needed. While I don’t believe anyone intended harm, it felt discouraging and, at times, like unintentional dogpiling.

Afterward, I had the opportunity to discuss the situation privately with Eric. His explanation helped clarify everything, particularly this point:

“The person who created TSRE5/CE is no longer supporting it. We as a community have learned to work with what we have, and if that’s not to our liking we have to figure out how to build it ourselves.”

Hearing that reframed the situation and made the community’s position much clearer. The direct but informative way it was explained helped me understand why certain expectations weren’t realistic.

I also want to clarify that I never intended to demand development work or act entitled. My intent was to learn and seek guidance from someone with experience working on this tool, in the hope of understanding whether and how it could realistically be improved, not to pressure anyone to do the work for me.

Despite the difficulties, I appreciate the technical knowledge that was shared. It helped me better understand CE’s constraints and how development discussions typically function. I also believe the community can benefit from clear, direct feedback that sets boundaries without making assumptions about someone’s intentions or mental health. As Eric’s response showed, it’s possible to be technically firm while still being respectful and welcoming.

I hope the tutorial I’ve made will help others who are working toward making more realistic AI generated consists as well.

Thank you for your understanding.

Dillon Nickerson.

[UnionPacificGP60#1050]

Heres the Tutorial and AI prompt text.

[ossie]

Well done on taking the time to try to create the result you were after and for putting together the tutorial for the rest of us. I'll add it to my "to-do" list and look forward to seeing what you have come up with.

[UnionPacificGP60#1050]

Much appreciated Pete! If theres anything missing in the tutorial, hit me up and i will upload a new updated file of it.

[crstagg]

Heres (sic) the Tutorial and AI prompt text.

Much appreciated Pete! If theres (sic) anything missing in the tutorial, hit me up and i will upload a new updated file of it.

Your process fails to recognize that Window allows Folders and Files to have spaces in their names. And many rolling stock creators have taken advantage of this feature.

The parsing code used by both MSTS and ORTS (or any third-party utility such as TRSE) to read the WagonData line recognizes this by requiring that if there are spaces in a FolderName or FileName then that name MUST be delineated by quotes. As in: WagonData ( "File Name" "Folder Name" ).

If there are no spaces in the name then quoters are not necessary. As in: WagonData ( FileName "Folder Name" ) or WagonData ( "File Name" Folder Name ) or WagonData ( FileName FolderName ).

However, if there are spaces in the name and quotes are not used as in: WagonData ( File Name Folder Name ) or WagonData ( File Name FolderName ) or WagonData ( FileName Folder Name ), MSTS will choke and fail reading the consist file and probably not even give an error message. ORTS will probably just give an error message in the Log file and will treat the Wagon as if it is a blank space in the consist. TRSE-CE would probably stop reading the consist files at that point and one would have to open the TRSE log to find the problem.

(FYI In case you do not know this: There are Document files (which are not Installed when installing MSTS) in the second MSTS CD that specify the syntax that must be used in creating TXT files to be read by MSTS.) As a general rule any data item with spaces must be delineated with quotes in order to be properly read by MSTS, ORTS or any of the third-party tools such as TSRE, ConBuilder, ActMan, ActivityChanger, etc.)

[UnionPacificGP60#1050]

Your process fails to recognize that Window allows Folders and Files to have spaces in their names. And many rolling stock creators have taken advantage of this feature.

The parsing code used by both MSTS and ORTS (or any third-party utility such as TRSE) to read the WagonData line recognizes this by requiring that if there are spaces in a FolderName or FileName then that name MUST be delineated by quotes. As in: WagonData ( "File Name" "Folder Name" ).

If there are no spaces in the name then quoters are not necessary. As in: WagonData ( FileName "Folder Name" ) or WagonData ( "File Name" Folder Name ) or WagonData ( FileName FolderName ).

However, if there are spaces in the name and quotes are not used as in: WagonData ( File Name Folder Name ) or WagonData ( File Name FolderName ) or WagonData ( FileName Folder Name ), MSTS will choke and fail reading the consist file and probably not even give an error message. ORTS will probably just give an error message in the Log file and will treat the Wagon as if it is a blank space in the consist. TRSE-CE would probably stop reading the consist files at that point and one would have to open the TRSE log to find the problem.

(FYI In case you do not know this: There are Document files (which are not Installed when installing MSTS) in the second MSTS CD that specify the syntax that must be used in creating TXT files to be read by MSTS.) As a general rule any data item with spaces must be delineated with quotes in order to be properly read by MSTS, ORTS or any of the third-party tools such as TSRE, ConBuilder, ActMan, ActivityChanger, etc.)

Fixed

[crstagg]

Within section 4.2 of your process you use the terms "car IDs" and "unique ID". What do you mean? Are they referring to the consist file Line "UiD ( # )"? Or are they referring to Reporting Marks? But if so then they could not be unique as _LD and _MT wagons would have the same reporting marks. If not, where are these "IDs" located in the CSV file?

I just noticed this in 4,2 4 third bullet: "It’s okay to re-use the same car IDs and reporting marks multiple times, even back-to-back, inside different blocks". Now I am really confused as this indicates "car IDs" and reporting marks are two different items. And this raises the question "How can this consist be "REALISTIC" if more than one wagon has the same reporting marks?"

On the rules for empty and loaded how do we account for when the wagon creator has used the convention for naming their files SP1234.wag and SP1234_MT.wag for loaded and empty?

[UnionPacificGP60#1050]

The UiD number in a .con file is only a numbering system TSRE5 uses internally so it can keep track of each wagon in the consist. UiD numbers are not real-world identifiers and they are not the “car IDs” you see discussed in the tutorial.

In the tutorial, “car ID” simply means the filename the wagon creator used in the Trainset folder, such as ASHX1034_LD or SP1234_MT. It is only a shorthand way of referring to a specific wagon entry in your CSV. It is not meant to represent the real-world reporting mark in an official sense. The reporting mark you assign in Column C is separate and only used for sorting, realism, or AI selection, depending on how you choose to configure it.

Sometimes a creator makes two files for the same car, such as SP1234.wag and SP1234_MT.wag, where one represents the loaded version and the other represents the empty version. Even though the reporting mark looks the same, they are treated as two different wagons because they appear in your CSV as two different filenames. This is normal in Open Rails, and it will not break realism because the filename gives the AI enough information to distinguish which one is loaded or empty.

When the tutorial says a car ID can repeat, it simply means the AI is allowed to choose the same filename more than once across different blocks of a train. Real trains frequently have several cars with the same reporting mark class or numbering family, so repeating filenames does not automatically make the consist unrealistic unless you personally want every wagon to be unique.

If you want the system to treat those wagons as unique, or if you want stricter or looser realism rules, you can always change these settings when you instruct the AI. Adjusting the instructions will instantly change the way your consists are built, so you can tune the realism level to whatever you prefer.

[eric]

No, the UID is not used by TSRE. It is used by ORTS and MSTS. Duplicating within the same file or structure can have negative impact.

As Charles noted, reporting mark is the proper term. Not sure why that was never an element in the WAG or ENG file layouts. It would be a lot more useful in the train operations window or for building a switch list.

Sent from my SM-S911U using Tapatalk

[UnionPacificGP60#1050]

Duplicating within the same file or structure can have negative impact.

I have been noticing this alot recently. Sometimes this happens because AI sometimes cant memorize every single row listed in large csv files. Thats my main focus to make sure that AI can read large lists or files and take every row into memory.

[crstagg]

..............

In the tutorial, “car ID” simply means the filename the wagon creator used in the Trainset folder, such as ASHX1034_LD or SP1234_MT. It is only a shorthand way of referring to a specific wagon entry in your CSV.
.................

You obviously have never written a Software System specification. You have defined the content of Column A in a database with a specific name, in this case "Folder/Filename", When you describe rules for how this data is to be used calling it by any other name is confusing and my not result inthe desired results.

AI is nothing new Garbage in still equals Garbage out.

[crstagg]

Can we revert this discussion back to your OP?
Looking at your Tutorial – Building Realistic AI-Generated Consists for TSRE5 / Open Rails leads me to think that your objective to be able to create Consists that look something like:
A block of 50 Boxcars consisting of 15 individual cars. Selectively chosen from some criteria like a group of geography adjacent RRs and randomly sequenced in the block.
Followed with a block of 35 Hoppers consisting of 12 individual cars chosen in a similar manner and randomly sequenced.
And then a block of 40 FBC (Flat Bulk Cars) consisting of 10 individual cars loaded with Lumber products chosen in a similar manner and randomly sequenced.

If this is your Objective, then I just created this consist using the TSRE-CE. Attached

I used the TSRE-CE Search tool along with the Add Rand entry process tool.
I did it one block at a time:
Search for BoxCar
Selected first to use then clicked Add Ran. That opened a dialog window to which I could add the other 14 cars to the list.
Then clicked on the Add Random button at bottom of the Add Rand dialog and the block was added to the consist.
Repeated for the other blocks.

[UnionPacificGP60#1050]

Yes, those are the types of blockings that can be adjusted with AI. But I'm also looking for how you can make long manifest trains using randomized blocks ranging from 1 to 25 cars for each wagon type with randomized reporting marks within a railroad territory, like this: 15 covered hoppers, 7 reefers, 10 tank cars, 4 gondolas, 7 autoracks 5 boxcars, then 22 coal hoppers, and the rest being randomized smaller block sizes again. The purpose of this is to generate consists without making all of those clicks and to see if it can generate multiple consists like this in the same AI prompt.

[crstagg]

My Train Simulation interest is limited to the period of late 1930's to present time in the USA and primarily diesel. But I have been at it for 26 years and have accumulated a lot of rolling stock. After following your procedure thru step 3 and beginning filling in the resulting spreadsheet for columns B onward I have seen that other columns are needed. Weight for one. Not all rollingstock creators use the same file naming convention. Many use _LD and _MT in the file name, but others do not. Many make loaded and unloaded versions of each wagon, other do not so they have no need to add _LD at the end of the filename. Others use the same shape with multi reporting marks some with the Mass line in their WAG file an amount with a normal load and others an amount equal to an empty car. So if one wants to realistically simulate driving up and down hills with a consist of fully loaded coal hoppers then a column for Load/Empty is needed to filter properly as the _LD rule in the filename is insufficient.

Second drawback is the time required to fill-in the era columns. I don't mean entering the data I mean researching to find when each type of car was used. Take 40/50 ft metal boxcars for instance, Originally the had roof walks on the top and ladders that accessed the roof. Yes that were used from the 1930s to today but in 1964 the AAR ruled that the roof walks must be removed by 1974. So to properly enter the Era column data one must open the WAG file with shape viewer to determine how the creator modeled the car pre 1970 or post 1970.

When I have entered data for a few cars and look and realize I have another 5900 plus yet to complete, I see that the task is too large to continue. At 83 what's the point? I would have more enjoyment of using TRSE-CE to stroll thru my trainset files selecting what to use in a consist then writing instructions to an AI to do it for me. Scrolling thru looking at the rollingstock is much more enjoyable than entering data into a spreadsheet.