Trainz 2022 performance is still so bad

On Linux for me Trainz actually performs better. Windows biggest problem has been excessive bloat which has been an issue since Windows 1.0.

We should also consider that hardly anyone uses ECC RAM, and we all should be. You can pump a ton of RAM into your computer but it will always fail, because it can't self repair. Linus Torvalds recently mentioned this at PC Gamer recently. Why this matters is performance isn't one thing it's multiple.

Do we need 10K computers just to play trains at low settings? Maybe N3Vs choice of game engine when it was changed in T:ANE was a bad one. Unity might have been better, just look at Railroader and Derail Valley. Far and away better performing games with a tiny dev team.

I don't think any of us will ever get the answers that make sense. Trainz is virtual model railroading. If it does one thing right it's that.

We expect far too much in a game that isn't high bar. None of the HD or PBR textures should have been added until the game itself was not killing drives or GPUs.

20 years ago I graduated from college with a degree in Network Admin. All that has changed is our demands and unrealistic ones at that.
I agree with you on the ECC RAM. If you remember, we all had RAM with parity. Then manufacturers got cheap, they ditched the parity row and developed ECC RAM for workstations and servers only.

It may very well be bloatware, but I'm thinking it's Microsoft's Smartscreen that's doing it or is contributing to it. I noticed yesterday that Smartscreen kicks in when TRS-Plus starts up and I wonder if this is scanning and chunking away at the program.

The excessive writes though are a different story. I mentioned this back in TS12 days. The disk was constantly thrashing every time I loaded up a route or did anything with the program. At the time, I thought it had something to do with caching, which I still think is next to none. I'm not talking about the precaching of content to a file, yet again disk access, I'm talking about memory caching because the program acts as though it ignores the RAM and constantly loads off the hard disk then flushes again with constant writes.

During my test yesterday with Process Explorer, the content read rate was about two to three times what the writes were while I opened and edited my large route. This was constant throughout the test with a maximum of 760K reads and 256K writes with this being a count and not bytes or megabytes.

N3V developed their own game-engine inhouse. At the time, when TANE came out, Unity wasn't exactly a great performer, and the newer Unreal Engine was just showing up on the scene. They also said that these other prebuilt game engines didn't allow them to import older content or support what they needed. I think it was also cost due to the licensing.

In many ways, I agree that this homebrew wasn't a good move. While I enjoy running old routes I developed in the past, they should've gone all guns in and gone forward with a modern game engine.

In the past, I ran some Solaris machines at work including a SPARC server and I had a Sun setup at home with a few retired SPARCs I got from Polaroid when they were retiring the old SPARC 10s and an Ultra 5. The hardware really was spectacular and never failed unlike the PCs running Windows. I have looked into running Linux on my PCs. The problem is software support. I do some music editing with software that is not available with Linux support at least right now. Setting up yet another box or dual booting will make yet another thing to do just to play a game.
 
Last edited:
Always make sure you have Exclusions or rules to ignore the Trainz folders and / or processes in Windows Security or if you have some other thing that is doing it.
 
Always make sure you have Exclusions or rules to ignore the Trainz folders and / or processes in Windows Security or if you have some other thing that is doing it.
I already have done that and also excluded the various file types but that made zero difference.
 
I think Trainz is by nature a database-driven simulator, but I don't think the database procedures are optimized for efficiency. Of course, I am saying that blind because I have no view into the way it is run, but it just seems like it from outside the black box.
 
I think Trainz is by nature a database-driven simulator, but I don't think the database procedures are optimized for efficiency. Of course, I am saying that blind because I have no view into the way it is run, but it just seems like it from outside the black box.
It for sure is database software, which really should be changed or moved to something that can handle it better/faster. I don't know how much it has changed since 2012, other than being less annoying with the onscreen stuff showing what it is doing in the background being gone now.
 
I think Trainz is by nature a database-driven simulator, but I don't think the database procedures are optimized for efficiency. Of course, I am saying that blind because I have no view into the way it is run, but it just seems like it from outside the black box.
But why would you not simply do reads to load the assets into memory? Why the writes?

John
 
I think Trainz is by nature a database-driven simulator
It certainly is. Content Manager is, at the very least, a DBMS (DataBase Management System). The assets, once installed into Trainz, are records in a giant database.
It for sure is database software, which really should be changed or moved to something that can handle it better/faster.
Such as?

One of the main reasons why the database management system was introduced (and I cannot recall when or which Trainz version that was) was to replace the previous system where every single asset was stored in its own folder inside a huge directory structure. This made access faster (or as fast as Windows would allow) but the price was a far greater risk of corruption by Windows, other software and in particular by users who have an insatiable desire to "muck around" with asset files and their contents. This meant that every time you started up Trainz it had to check every single entry in that directory for corrupted data. And the more assets you had the longer this took and users, who are also notoriously impatient, starting complaining.

With the current Content Manager/database system, every change you make to an asset is checked and validated before it can be committed. Content Manager also gives you the option of reverting an edited asset to its original condition because, like many DataBase Management Systems, it assumes that uses will make changes that they did not really want or did not know what they were doing (my money is on the latter).

So, I am sure that N3V would be interested in hearing about possible better and faster data access systems that don't have any serious downsides and can be implemented to everyone's satisfaction.

My thoughts.
 
It certainly is. Content Manager is, at the very least, a DBMS (DataBase Management System). The assets, once installed into Trainz, are records in a giant database.

Such as?

One of the main reasons why the database management system was introduced (and I cannot recall when or which Trainz version that was) was to replace the previous system where every single asset was stored in its own folder inside a huge directory structure. This made access faster (or as fast as Windows would allow) but the price was a far greater risk of corruption by Windows, other software and in particular by users who have an insatiable desire to "muck around" with asset files and their contents. This meant that every time you started up Trainz it had to check every single entry in that directory for corrupted data. And the more assets you had the longer this took and users, who are also notoriously impatient, starting complaining.

With the current Content Manager/database system, every change you make to an asset is checked and validated before it can be committed. Content Manager also gives you the option of reverting an edited asset to its original condition because, like many DataBase Management Systems, it assumes that uses will make changes that they did not really want or did not know what they were doing (my money is on the latter).

So, I am sure that N3V would be interested in hearing about possible better and faster data access systems that don't have any serious downsides and can be implemented to everyone's satisfaction.

My thoughts.
Such as a better, faster, more reliable (if possible) database and manager.
 
faster, more reliable (if possible) database and manager.
OK, so no specific examples of existing products in mind.

The problem here is obvious. Reliable, fast, efficient and above all user friendly DBMS software is one of the most difficult types of applications to create. How much time, effort and resources should N3V devote to building it - and. of course. everyone will want a fully working bug free version by noon yesterday. Sorry but that is the cynic in me after decades of dealing with users.

Content Manager can certainly do with some improvements. But a rigid data dictionary that defines, in detail, all the types of data it can handle and their relationships (i.e. what is legal and what is not in assets) would be an essential first step. Many of the problems we are having with assets today stem from the original "sloppy rules" that allowed users to create badly designed assets, textures, scripts, etc in the early days. And every time N3V has tightened the rules there has been an outcry from some users.
 
Trainz’s custom DB is specialized and tightly integrated, but if you were designing a next‑gen Trainz‑like system, a graph database + key‑value cache hybrid would likely outperform it in dependency resolution and repeated lookups, while still keeping binary data external.
 
I think Trainz is by nature a database-driven simulator, but I don't think the database procedures are optimized for efficiency. Of course, I am saying that blind because I have no view into the way it is run, but it just seems like it from outside the black box.
It is an SQL-Lite database that lacks the tools to allow us to build our custom views and reports which could be very helpful. The indexing could be much faster as well outside of Content Manager and within the program. Content Manager can handle the data very quickly, but when we're in the program, accessing the same data is much slower. I noticed lots of data validation going on constantly while in both Surveyor and Driver. This constant I/O in the background really does hammer on performance and is much the same as it was in TS12.
But why would you not simply do reads to load the assets into memory? Why the writes?

John
I would like to know why as well. Is it because the underlying TADDaemon is constantly validating and updating content records as I've noted? Why would the program have to do this if the content has already been error checked and loaded by Content Manager? This only adds in additional overhead causing slower performance due to poor I/O on the slowest subsystem in the computer. As you know storage devices are the slowest devices whether they're spinning rust or SSDs. SSDs are faster but far slower than RAM and are still bound by the host's buss speed and I/O ports depending upon the configuration.
 
Deleted. JCitron posted before I hit enter and actually answered some questions I had as well as verified some guesses I stated. 🤠
 
Deleted. JCitron posted before I hit enter and actually answered some questions I had as well as verified some guesses I stated. 🤠
I was just about to respond to your other post and the quote changed!

I agree with what you said regarding the licensing, etc. There's a lot of things they could probably do, but like everything we have with Trainz it's not optimized or completed 100%.
 
SQL-Lite is a poor performer for a game like Trainz, it would be better if the MariaDB was used, but that might have other inherit problems.

@JCitron The fact that the R/W is hit excessively hard is why I get so worried about ruining my drive. No games should be pushing R/W that hard unless we are talking a datacenter. Again this could be their game engine's poor handling of processes. It's also concerning that the lighting and skybox update is being worked on with the current game engine. That eventual update could have a significant impact on our SSDs. Funny I always said Trainz could do far better with nightime lighting with actual reflections, but it's not worth it if our SSDs would be crushed more with R/W.
 
No games should be pushing R/W that hard unless we are talking a datacenter
Following these forums as long as I have (not as long as some), there always seems to be an inordinate number of Trainzers who suffer from computer crashes and losing their data. Backups aside, it seems to happen here much more frequently than other places and has made me wonder about just this.
 
SQL-Lite is a poor performer for a game like Trainz, it would be better if the MariaDB was used, but that might have other inherit problems.

@JCitron The fact that the R/W is hit excessively hard is why I get so worried about ruining my drive. No games should be pushing R/W that hard unless we are talking a datacenter. Again this could be their game engine's poor handling of processes. It's also concerning that the lighting and skybox update is being worked on with the current game engine. That eventual update could have a significant impact on our SSDs. Funny I always said Trainz could do far better with nightime lighting with actual reflections, but it's not worth it if our SSDs would be crushed more with R/W.
This is why I use spinning rust. It may be slower but at least the disk won't wear out.

They always work on the glitter.
 
Following these forums as long as I have (not as long as some), there always seems to be an inordinate number of Trainzers who suffer from computer crashes and losing their data. Backups aside, it seems to happen here much more frequently than other places and has made me wonder about just this.
It could be the demographic too. Many people treat their computers horribly and are careless about data regardless of the platform and programs. Unlike Steam-hosted games with cloud backup, everything in Trainz is local. People have no idea that when something crashes badly, it takes out everything.

Trainz is very data-heavy with a large database and asset load making the loss worse. In some ways this is a good thing about the cloud, but then again what cloud platform will want to backup 1.5 TB or more in content and be able to restore that quickly. The only way around this would be for N3V to implement the same system they use for Multiplayer Surveyor. Maybe someday in the future, this will be the way everything will be. We're heading that way now with small local disks and online subscriptions not only for data storage but also, for programs.
 
Most are no longer used to local game saves and backing up like it was not too long ago. Everyone relies on the cloud (for absolutely stupid reasons as we've found out with Cloudfare and AWS recently) as the safety net. Not everyone comprehends this because the people helping have zero patience/tolerence to those that do not have the equal understanding as they do. People are going to treat their computers like they do because no one wants to help. Those that help will give up out of frustration "do as I say", and tell the end user to pound sand. Not everyone was born with expertise (takes 10,000 hours to become that with one thing)

Maybe we should just say that Trainz is forever perfect, no flaws, no performance issues, and will never lag computers. Every model maker is brilliant for a making 20,000 (or higher) poly with no LOD assets. And ultimately we are all just omnipotent.
 
What computers are y'all using? and have much Storage y'all got on y'all computers?
Dell XPS 8950:
i9-12900K
64GB RAM
RTX3080
Storage:
2x 8TB Seagate Iron Wolf hard disks
1x 10 TB Seagate Iron Wolf hard disk
1x 2 TB Seagate Barracuda --- used for swap
1x 2TB SSD for programs

Trainz has its own 8 TB drive and takes up 1.5 TB

The system is used for other tasks including music editing. This is why there is a large amount of storage. Raw audio files are huge with a mere 5 minutes being about 500 MB
 
Back
Top