Why Are End-of-Track Signals Used In Unsignaled Switching Areas?

[Minneapolitan]

I've run into some problems with End of Track Signals while editing a route to enhance its detail and historical accuracy. I understand the basic premise of EoT signals, that an entire network of signaled track must have a way to know where the signal system ends.

But I'm editing a network of industrial spurs that has no signals (in my particular case, the Homestead Avenue corridor through West Hartford and out to Griffins on the Vintage New Haven-Springfield Route). Yet every single industrial spur has an EoT signal at its end.

Why is this necessary? What would happen if an EoT signal was placed on the only track leading into this industrial switching area and all the others removed?

End of Track Signal.jpg

And on a further note, there's a similar signaling object that uses a barrel as the prop rather than the tiny silver metal box shown above. Shown below, these seem to be found near the switch of the unsignaled industrial spur with the arrow pointing towards the switch. Not only do I not understand the point of this, but I also don't know what it's called in the menu.

End of Track Signal 2.jpg

This is proving to be a real headache in my detail-enhancing endeavors. It's causing error messages to pop up immediately upon opening a scenario, and possibly rendering entire routes unplayable. Can someone please shed some light onto this?

[GreatNortherner]

Hi,

The main reason for why these are as they are and we used them as we did is that back then (early 2010s) we in the VNH team didn't know any better.

The EOT signals are the obvious case here. Our signal script is a modified version of the Kuju US signals, which lead us to believe that we needed those EOT signals (also being from Kuju). However, I'm now quite certain that they are in fact totally redundant for US routes -- we have not used them in any of our subsequent routes and we're still using modified versions of the Kuju signal script for all of them!

The "barrel signals" are a different matter. Those are in effect the simplest possible form of signals, intended purely to separate track sections into signal blocks so that multiple AI trains can operate on them (like in the big yards) without having to place actual signals with lights and all. These signals will NOT cause a SPAD when you run past them, even if the block you're entering is occupied. On our newer routes, we have abandoned the fixed installation of these after Wayne Campbell's breakthrough discovery on the CVP route that signals can be placed in the scenario editor, too.

I would say that you can safely delete the EOT signals from your edit version of the route and it shouldn't affect the dispatcher.

However, I'd recommend leaving the "barrel signals" in place, as deleting them could impact existing scenarios (AI services that were in separate blocks before their removal might suddenly share a block, which the game does not like). Please note that this only matters if you want to keep compatibility to the existing scenarios intact, otherwise you can freely delete or move those "barrel signals", too.

It's causing error messages to pop up immediately upon opening a scenario

Is that the "tracks.bin not found" message? In that case, it's just a message that comes up in any Career scenario when something important has been edited either on the route's track network or in the engine blueprint/simulation that affects service performance. (Probably an "anti-cheat" measure?) You can fix that easily by loading the affected scenario into the editor, flip or move a random rail vehicle, and save changes. You can also use the "compile/rebuild checksums" function in the timetable editor for the same effect.

In any event and because it wasn't clear from your message if you're already doing it like this, I would strongly recommend that you do any edits in a cloned version of the route. That way, any potential re-downloads of the route from Steam won't undo all of your work.

I hope this all makes sense. Please ask if you have any other questions or if something remains unclear.

Cheers,
Michael