Questions on signal upgrade groups

[Ves]

If two signals in different eras share the same upgrade groups, but are not compatible with the same signal boxes, what will then happen? Will the upgrade be ignored or will the signal upgrade be forced through?

Im going through the swedish signals and try to plan the signal box layout. One feature I would love, and that I think is quite realistic to some extend, is if the signalbox where to be upgradeable: To my understanding, in many cases the buildings themself are contained but the equipment inside are upgraded. Obviously not in all circumstances, and that should be why all signal boxes should not be possible to upgrade to every other signalbox.

Currently if you want the new version signalbox to be at the same location as the old one, you have to build another building next to the old signalbox, transfer all the signals, delete the old building and build a new building in its place and finally transfer the signals back and delete the "dummy" signalbox. A hassle, especially when the space is limited!
Upgrading the signalbox, if the new signalbox is not compatible with the existing signals, maybe the upgrade of the signalbox could trigger the signals to upgrade as well? That obviously require pakset maintainers to maintain upgrade patterns.

[jamespetts]

Signalbox upgrading raises enormous potential complexity, as there is no way of constraining users (or even pakset developers) to do sensible things. Retaining signals in the existing place may not be sensible when changing to a new signalling system, and in many cases there are not even equivalent types from one signalling system to the next (and even if such types are possible in the code, they may not be implemented in the pakset).

In reality, re-signalling on a railway is usually done by a process of installing a set of new signals and signalboxes, then, when they are ready, decommissioning the old ones. The new signals are usually in at least slightly different places to the old ones and often are in a completely different arrangement.

The automatic signal upgrading is intended to work only between signals that are functionally identical (save for maintenance cost). The idea is to prevent unrealistically old-fashioned signals from hanging around for a long period of time merely because the basic function remains constant (e.g. flag signals into the 1860s), and also to help the player to upgrade signals to types with a lower maintenance cost (e.g. from flag signals to vane signals to slotted post semaphore signals).

Thus, to answer your question, I cannot remember from the code what exactly will happen if incompatible signals are set to upgrade, but the feature is not intended to be used in this way.

[Ves]

Signalbox upgrading raises enormous potential complexity, as there is no way of constraining users (or even pakset developers) to do sensible things. Retaining signals in the existing place may not be sensible when changing to a new signalling system, and in many cases there are not even equivalent types from one signalling system to the next (and even if such types are possible in the code, they may not be implemented in the pakset).

In reality, re-signalling on a railway is usually done by a process of installing a set of new signals and signalboxes, then, when they are ready, decommissioning the old ones. The new signals are usually in at least slightly different places to the old ones and often are in a completely different arrangement.

The automatic signal upgrading is intended to work only between signals that are functionally identical (save for maintenance cost). The idea is to prevent unrealistically old-fashioned signals from hanging around for a long period of time merely because the basic function remains constant (e.g. flag signals into the 1860s), and also to help the player to upgrade signals to types with a lower maintenance cost (e.g. from flag signals to vane signals to slotted post semaphore signals).

Thus, to answer your question, I cannot remember from the code what exactly will happen if incompatible signals are set to upgrade, but the feature is not intended to be used in this way.

Thank you!
I see the point that an arrangement of signals potentially is very different depending on the working method. In other words, the way the upgrade feature is implemented, it should basically mainly be upgrading the graphics and some of the parameters like speed, maintenance etc?

I guess I am looking for a way to reduce the tedious work of manually replacing every signal at big and complex stations, where the functionally is usually the same across many working methods (all choose signals work the same as well for starter signals, save for token block, one train staff and moving block. The time interval/w telegraph starter signals I would also consider suitable to upgrade to absolute block in this situation). If you don't want to disturb your network too much, you have to replace one signal at a time, making you switch between the delete tool and the signal "tool" a multitude of times (twice for every platform + choose signals + presignals).

[jamespetts]

I can see the work involved in resignalling, but I can see no easy solution to making this more efficient. In upgrading from absolute block to track circuit block, for instance, even for choose signals, how is the computer to know whether you want 2, 3, 4 or 5 aspect signals?

[Ves]

Manually placing a new signal on top of an old one, thus replacing the signal? Would eliminate the need to destroy the old signal.

[jamespetts]

Perhaps - but this might be too easy to do by accident, might it not?

[Ves]

What about ctrl-click? Or a checkbox in the signal spacing window that you can check or uncheck to allow it?

[jamespetts]

CTRL+click for direct replacement might work. I shall have to look into that when I get a moment, which might not be for a while, I am afraid.

[Ves]

That is nice you consider doing it!

[jamespetts]

I have added it to the bottom of the very long list.

[Ves]

I have added it to the bottom of the very long list[url].

Hahaha, my gosh!