[conductorchris]

Goku's new route editor is pulling me into working on route-building. This is my first question on the subject, but I'm sure I'll have more. I'm planning my next moves and wondering . . .

With the MSTS route editor the gospel formed from hard experience was that one NEVER altered track after interactives (signals, car-spawners, etc) were put in. Due to risk of big corruption and blowing the route up for good.

Is this still true with Goku's editor? Or is it untested?

Sorry if this is already answered and I've lost track. I don't recall it having come up before.

The answer to this will determine which direction my plans go.

Christopher

[rickloader]

Hi Christopher. With TSRE5 under continuous development, I fear it is impossible to say.It depends largely on what element of risk you personally are comfortable with.
The gospel with MSTS is backup constantly, and of course this still holds true. The snag is if a buried tdb fault comes to light months later, you may be faced with discarding months of work.
What we really need is a tdb verification / repair tool. (better than tsutils)

Having said that, I am placing interactives, and altering track with TSRE5. I have found TSRE5 absolutely stable, and it has created no known route faults. 30 route miles completed, and a lot more track mileage. When Goku updated the jnposnnode, I found I had laid 96 switches.
I even run train paths over the part completed section, and when tracks are altered OR complains in the mildest terms. (just remake the paths)
Obviously, I don`t do silly things like delete track with out removing signal links first. And I treat car spawners very carefully as they tie the tdb, rdb and world together.
I have also used TSRE5 to update the terrain, and just un buried the track.
I have just one area where TSRE5 does crash. These are some double sized tiles where track accidentally strayed, years ago. These were reduced to normal size tiles, and track relaid. There must be some residual defect in the tile / world file relationship. Not really TSRE5 fault

Actually I have been quite cavalier with MSTS RE, but my rule there is to work on sections remote from tiles with interactives. I believe a big cause of MSTS blow ups is lack of memory, both system, and the allocated mem switch on MSTS launcher. With 16gb system and allocated mem 2048 MSTS RE is quite well behaved.

So there is the result of 1 TSRE5 test. I will certainly post if I run into trouble! Any other route builders tried it?
Rick

[rickloader]

I have now found a minor snag. ORTS handles signal animation differently to MSTS. I have some custom signals with animated extra parts in addition to the semaphore signal arm / head. ( balance arms, operating rods etc).
When TSRE5 saves these signals it seems to see the extra parts as signal sub objects, and I think it writes them to the track database. Neither msts nor ORTS are happy with this! MSTS RE can save without problems.
I will see if rebuilding the signal shape can solve this snag, before contacting Goku. It may not be TSRE5 fault
So if routebuilders have complex signals with multiple parts, it might be worth running a test route with TSRE5 or at the least making careful backups