Config.txt retains all my old errors... why?

hkoster1

Member
As the title says, the config.txt files for my routes and sessions contain a record of all my errors and changes of mind.
For example, half-way through I may change my mind about the naming of junctions, signals, etc. While these changes show up properly in the routes and sessions themselves, I notice that all the old names are still present in the config.txt files.

Is this by design? Is it a quirk of Surveyor? Can it be switched off?
 
Last edited:
I would like to know why as well. :)

I have an older session which I've updated over time and found references in there one day to old no longer to be found consists, when I edited to change the route reference because I updated the route.

I think this is a bug as well and it exists in TS12 as well as T:ANE.

John
 
I agree, it must be a bug. I've on occasion tried to clean the config.txt by editing out all that crud and Surveyor or Driver doesn't complain at all.
I should also add TS2Mac to the list of Trainz versions that exhibit this annoying behaviour.
 
I had a similar problem in SP1(latest download from Sim Central) where I had replaced an asset in the config of a route. The removed asset still shows as a missing dependency even though there is no reference to it.
Also I have a number of routes that show as missing dependencies, when nothing is missing or faulty.
This just started a couple of days ago.
Cheers,
Mike
 
I had a similar problem in SP1(latest download from Sim Central) where I had replaced an asset in the config of a route. The removed asset still shows as a missing dependency even though there is no reference to it.
Also I have a number of routes that show as missing dependencies, when nothing is missing or faulty.
This just started a couple of days ago.
Cheers,
Mike

Don't feel left out or getting something second hand. This has been going on for at least a year now. :)

What's interesting is the same route that shows no missing dependencies in TS12, had a gaggle of them in T:ANE. I spent 6 hours the other day doing the Kuid hunt and now I have 20 assets left which are an elusive bunch which are still referenced, but nowhere to be found.

John
 
Reading these forums every day leads me to wonder if there is even one system left within Trainz that does not have a bug in it? It seems every aspect that used to work properly has some kind of problem now. I hope that's just my perception and not reality.
 
Reading these forums every day leads me to wonder if there is even one system left within Trainz that does not have a bug in it? It seems every aspect that used to work properly has some kind of problem now. I hope that's just my perception and not reality.

Your perception is pretty sharp, unfortunately. :(

What has happened is pretty simple. In the beginning the program was written by people that actually used it. As time went on these people left due to many reasons including the fiasco they called Fury. This left a new management team, and a new Brew Crew, though a couple of senior members remained.

When new versions came out, they reused older code without really knowing what was going on. This is not uncommon and perhaps things weren't touched because when you touch older code it breaks, and when it breaks it breaks other things. I think of it as a giant sweater made of wool. You pull one thread and everything starts to fall apart. Well the same thing can happen with programs because so much stuff is intermixed and intermingled among the different modules.

The other things too is these people had no history with the product, meaning they had no understanding of what was supposed to happen. This is not uncommon either, and is actually getting worse because of the contractual nature of programming jobs. The programmers in many cases are freelance and float between projects, they code and leave. They are not responsible for anything other than the code they write. The problem is they have no understanding of the whole picture.

So we have a team that comes in for a project, writes code, gets stuff done. The product is sold and then upgrades and fixes come along. These are now met with a new team of programmers. Sometimes the company is lucky and can bring back some of the same ones or the same programmers, but that's rare. The new team now makes their changes and usually breaks stuff in the process.

Such is the life in the fast lane...

John
 
Back
Top