Choose signal options

[Vladki]

In czech practice, if you get 'drive 40, expect clear', the train can accelerate to line speed when it is completely out of the switches. No need to go slowly to the next signal, which may well be on entry to next station a few km ahead. Simutrans trains do the right thing already, no need to code it into signals.

[jamespetts]

Thank you both: that is helpful.

[Ves]

Is restricting the speed of trains into stations like this wise given that the scale system of Simutrans means that they will be restricted for a significantly higher proportion of their journeys than would be the case in reality?

Aahh, I completely forgot about this point! X(
Yeah probably best to leave it out then! :p

[kierongreen]

Speed signalling, so far as I understand it, works in relation to two matters: (1) forthcoming stop signals; and (2) forthcoming route based speed restrictions. It does not necessarily tell the driver which of those two things requires a reduction of speed. It is unlikely to add anything to the gameplay to make players add signals just to give warnings of speed limits (in any event, what would happen if players failed to do this?), so I agree that modelling route speed restriction based speed signalling is unlikely to be sensible. However, if I understand item (1) correctly, it works a little differently to UK multiple aspect signalling. In UK MAS practice, a train is given an indication of what the next signal will be. This does not give rise to a specific speed limit, save that a driver should drive slowly enough to stop at a forthcoming red signal making the most pessimistic assumption possible given the train's braking capabilities and the state of the signals. Line speed will generally be set to allow a train to stop from a clear indication to a danger indication. In Simutrans-Experimental, the system is that the train will always work out where the next signal that could possibly be at danger is, and go slowly enough to stop for that. It will only be treated as knowing the aspect of any given signal when (1) it is in sighting distance of it; or (2) it is in sighting distance of a signal that predicts its aspect. Thus, the speed at which trains travel is automatically calculated based on the train's braking capabilities and the state and position of forthcoming relevant signals. Do I understand correctly that speed signals in effect require a train to travel a signal showing a restrictive aspect at a speed slow enough to stop within the sighting distance of the next signal (or the signal after next if relevant, etc.)? If so, this would be a significant difference from UK practice, which allows trains to decelerate to this speed in the block approaching the next signal. If this is not correct, then speed signals need work no differently in Simutrans-Experimental to UK type multiple aspect signals (save that I need to allow for five aspects rather than four, which I am planning on doing in any event, using the LMS speed signals, which had five aspects, as a prototype).

Also BR 5 aspect route signalling (flashing green aspect on ECML).

[jamespetts]

Flashing aspects are very difficult to accommodate in the Simutrans graphics system, alas.

[Ves]

Will you make the presignals be able to warn for the different "choose" aspects from a choose signal?
I know there probably will be no gameplay effects to be gained from that, other than that the graphics could be changed on the distant signal.
As earlier in this discussion, the distant signals in Sweden can show three states, expect clear, expect stop and expect drive 40. Although the speed restriction itself are left out, the graphics of the drive 40 message I think will be used as the choose aspect in the choose signal, then it would be awesome if the distant signal could show the corresponding distant message.

[jamespetts]

I had not planned to do this, and whether it makes sense will in part depend on precisely how I implement the choosing aspects, which I have not yet decided.

[Spenk009]

Aren't we forgetting that a presignal simply "books" the next signal along the train's chosen route? The train arrives at the presignal and reserves the next piece of its route (after the presignal followed signal, up to the next stop or signal). In this case, the train should call the function of the next signal, in this case a choose signal, and reserve its track or platform for it.

Multi-aspect signals are complicated and will we ever see every aspect displayed in one? Stop and go are a current given, a sensible addition would be to display the next signal in-line's state. Proceed with caution? Either the way is reserved, or it's not. Limit speeds? Someone (or thing) has to make the decision to apply a limit or not apply a limit.

On the topic of speed displays in a signal, signal induced speed limitations for schedule management are unrealistic in Simutrans. Over complicating signals to ensure that trains can travel at their most efficient is micromanaging on a microscopic scale. I understand the possible benefits and the realism this creates, but (usually) people don't play at 24 bits per month. Instead of hundreds of trains per month, the scope in Simutrans is tens of trains per month. A speed limit sign is easy to place and see. A de-restriction sign is too. The code has minimum speeds, so maximum speeds for a convoy shouldn't be too far off. Maybe such a sign could help reduce wear on ways and/or have a context menu to select lines, vehicles or traction type to be limited.

Ok, so the cab signaling will basicly be a signal like other signals, only with a higher (unlimited) sighting distance? ... So now every signal is both a normal signal with normal sighting distance (for non cab-signal-vehicles) and cabsignal-signal for the cab-signal-vehicles with unlimited sighting distance.

If the idea is simulated by a vastly superior viewing distance, then we have a simple solution for the possibly complicated problem. Setting a value for maximum viewing distance if the vehicle is fitted with cab-signalling and a default if not, is a simple addition to the code.

[Octavius]

Many systems are a mixture of speed and route signalling. The Netherlands use a relatively pure and simple speed signalling system, so it may be worth having a look into it.

Signals don't indicate the speed at which they may be passed. A driver only sees the signal a few seconds before he passes it, so there would be no time to adjust speed anyway, unless he was already driving at low speed. Signals don't indicate the aspect of the next signal either. Instead, signals indicate the speed at which the next signal can be approached. There are three exceptions to this rule:
(1) Red: Stop, always preceded by (4) Expect stop
(2) Flashing yellow: Drive by sight, always preceded by (4) Expect stop.
(3) Flashing green, possibly with a number: Proceed at the indicated speed (40 km/h if not indicated) until past the points, then accelerate to line speed. Always preceded by (5) Expect limited speed

The other aspects can always be passed at the speed the train was running during approach, although this is also true for (3).
(4) Yellow: Expect to stop at the next signal, sometimes preceded by (6) Expect further reduction
(5) Yellow with a number: Decelerate to the indicated speed, sometimes (theoretically at least) preceded by (6) Expect further reduction, but with a higher number
(6) Yellow with a flashing number: Decelerate to the indicated speed, expect further deceleration, sometimes (theoretically at least) preceded by (6), but with a higher number
(7) Green: Proceed at line speed

The number can be 4, 6, 8 or 13, indicating speeds of 40, 60, 80 or 130 km/h. Aspects (3) and (5) serve no purpose in simutrans. The difference between (5) and (6) is only for technical reasons. After passing (6) the driver is not supposed to release the brakes even when he has reached the target speed, unless he can already see that the next signal does not order further speed reduction or he can stop within sighting distance. This is because releasing and reapplying the brakes can take a while.

Note that there is no aspect for "Red signal two blocks ahead". Instead, if the block leading to a red signal is shorter than the braking distance of a train from line speed, two blocks ahead of the red signal is signal (6), with the indicated speed chosen such that the braking distance from the indicated speed to a complete stop is slightly less than the length of the short block leading to the red signal. If there are two consecutive blocks together shorter than a braking distance, there could be two signals with aspect (6), but I don't think this is the case anywhere in the real Netherlands. It could happen in simutrans though, and on high speed lines it's common, except that the signals are displayed in-cab.

Some signals can show all aspects. Most cannot show numbers, block signals cannot show (2) or (3), pre-signals (which are almost identical to other signals) cannot show (1), (2) and (3). There exist some additional signals for heavy trains that may have difficulty climbing steep inclines.

=======

There are purely informational signals indicating how the points are set. They can be safely ignored by the train driver, but may alert him that the points have been set wrongly, allowing a quick stop and correction of the points. These signals are attached below an ordinary signal and consist of three white lights arranged as a V, or four arranged as a T. The lowest light is always lit, the upper left if the left route has been set, the upper right if the right route has been set, or the upper centre if the straight route has been set, in case the line branches in three directions. They could be used in a choose signal. Any speed limits for these routes are indicated by the normal signal.

=======

As for the original question: Sounds useful. Working with end-of-choose signals can sometimes be a little inconvenient.

=======

Mathematically, a moving block system is the limit of a fixed block system with the blocks infinitesimally short and infinitely many speed reductions, using infinite-aspect signalling. In simutrans space has been quantised, so a moving block system in simutrans is a fixed block system with blocks of one tile.

=======

Trains often pass through stations at full line speed. In my country however they are not allowed to pass along a platform with possibly waiting passengers at more than 140 km/h, or 160 km/h if special warnings are in place. If the line speed is much higher, the platforms are in most countries placed on a loop.

[Vladki]

There exist some additional signals for heavy trains that may have difficulty climbing steep inclines.

Steep inclines in Netherlands ? Hmmmm.

There are purely informational signals indicating how the points are set.

These might be nice to use for different choose aspects, if someone makes Dutch signals addon.

Trains often pass through stations at full line speed. In my country however they are not allowed to pass along a platform with possibly waiting passengers at more than 140 km/h, or 160 km/h if special warnings are in place. If the line speed is much higher, the platforms are in most countries placed on a loop.

I was on a platform, cca 2 m from the edge, when a fast train at some 140-160 km/h passed by... I knew it was coming, but still was surprised by the strenght of the blow. It took off my hat. It could be dangerous for elderly people, especially if it would be unexpected.

[Octavius]

Steep inclines in Netherlands ? Hmmmm.

Yes, steep inclines, not long. 1km @ 20‰ or so. We have quite some bridges over and tunnels under important waterways. Anyway, it's all relative. If most of the track is less than 10‰, then 22‰ is really steep. These signals make sure that heavy or underpowered trains wait more than 1 km before the beginning of the climb (in case of a tunnel they wait before the tunnel entrance) until the track is clear until at least one train length past the end of the climb, so that the train can use its kinetic energy to climb. Better than stalling on the incline and being unable to continue. Quite a useful invention if most inclines are short, although really low priority in Simutrans I guess.

[Ves]

That was some other way of signaling!
I think in the future for the Simutrans Experiemental project, this kind of signaling should be possible. Obviously not all of the described dutch aspects makes sence in Simutrans Experiemental, but I like the idea that the line speed is not automatically the track maximum speed or the train maximum speed, but depends on what types of signals you use, eg a choose signal in a certain aspect only allows a certain speed, or new types of signals allow higher speeds to be used, but without replacing the tracks. I know you have planned a variation of this with the sighting speed, although this potentially allows the train to accelerate to its maximum speed when the signal is passed.

To use the Dutch example (for the future Dutch Experiemental pak ), the distant element of a signal will in some caution aspects force a speed restriction to which the train will decelerate until the next signal.

If the idea is simulated by a vastly superior viewing distance, then we have a simple solution for the possibly complicated problem. Setting a value for maximum viewing distance if the vehicle is fitted with cab-signalling and a default if not, is a simple addition to the code.

Do you think this could work, James?

[jamespetts]

Do you think this could work, James?

I should say that the cab signalling code is already largely finished (subject to testing and bug fixes), and does not rely on trains being equipped: as I had pointed out, ETRMS Level 2 can work with portable equipment, and even preserved steam trains have run with it, so this does not seem sensible. Cab signalling is not simply ordinary signalling with a greater sighting distance: the code path taken by each is quite different (for example, caution aspects and quasi-automatic signals are not provided for in cab signalling).

As to the sighting speed, this is a property of the signal, set in the .dat file, and has the effect that the train's speed limit in the whole section between it and the previous signal will be this sighting speed. Having speed limits hard coded in the .dat file that depend on things other than inherent properties of the signal (such as the speed at which it can safely be seen) does not make any sense; this would instead have to be based on properties dynamically extracted from the simulation, but I am not clear on what those properties could or should be.

[Ves]

I should say that the cab signalling code is already largely finished (subject to testing and bug fixes), and does not rely on trains being equipped: as I had pointed out, ETRMS Level 2 can work with portable equipment, and even preserved steam trains have run with it, so this does not seem sensible. Cab signalling is not simply ordinary signalling with a greater sighting distance: the code path taken by each is quite different (for example, caution aspects and quasi-automatic signals are not provided for in cab signalling).

I was thinking about this the other day, and although you may have portable ETRMS level 2 to equip a steam engine, the equipment, I guess, is not very cheap?

As to the sighting speed, this is a property of the signal, set in the .dat file, and has the effect that the train's speed limit in the whole section between it and the previous signal will be this sighting speed.

Aha! That I didnt understand from your earlier post. So in practice, you already implemented a kind of route speed signaling? Sighting speed of the next signal = max speed train is allowed to travel until that signal?

Having speed limits hard coded in the .dat file that depend on things other than inherent properties of the signal (such as the speed at which it can safely be seen) does not make any sense; this would instead have to be based on properties dynamically extracted from the simulation, but I am not clear on what those properties could or should be.

The simplifying method would be to hardcode in the .dat, certain speeds for certain aspects. In that way its the players responsibility to arrange the signals to make it flow the best way possible. To do it otherwise, I think would be overkill and unnessecary for the scope of Simutrans.

[jamespetts]

I was thinking about this the other day, and although you may have portable ETRMS level 2 to equip a steam engine, the equipment, I guess, is not very cheap?

I do not know how much that these cost - do you have any idea? The cost relative to other things (such as the regular maintenance of a rail vehicle) is what is really needed.

Aha! That I didnt understand from your earlier post. So in practice, you already implemented a kind of route speed signaling? Sighting speed of the next signal = max speed train is allowed to travel until that signal?

This is not quite how I understand route based speed signalling working.

The simplifying method would be to hardcode in the .dat, certain speeds for certain aspects. In that way its the players responsibility to arrange the signals to make it flow the best way possible. To do it otherwise, I think would be overkill and unnessecary for the scope of Simutrans.

The trouble with hard coding speeds is always what incentive a player ever has to use a signal with a slower speed over a faster one. In reality, safety is the incentive, but we do not have crashes in Simutrans, so that does not work. The only incentive that a player has to use signals with slower sighting speeds are either that they are the best that are currently available or that they enable permissive block working whereas signals with faster speeds do not.

[Vladki]

As far as I understand it, in general there are two types of speed signalling:
- route based - the speed limit is based on the route taken - position of switches, curves on the track, etc. - used in CZ/SK
- distance based - the speed limit is based on distance to next signal at danger - used at TGV.
- and of course some combinations of those are possible.
In general, the second is needed only if the blocks are shorter than safe braking distance. This system can be further split. Either the speed is prescribed exactly, or just telling the driver how many blocks ahead are clear (preliminary caution, advanced caution, repeated caution, etc.).

In simutrans the train knows the placement of signals, max speed of curves and switches, as if there are invisible (max speed) signs on the right place automatically. The only thing the simulated train does not know is the aspect of the signal, so that is what we need to simulate - distant or multi-aspect signals. It is not necessary to limit the speed by signals, just to show how many blocks are clear. More aspects needed for higher speeds.

Please do not overcomplicate things. On straight track, the only thing limiting the speed should be the track quality and trains capability.

There are more in-cab signalling methods, then just ETRMS, that can improve the visibility of signal. And the proper equipment must be on track, train and signalbox. I would suggest to concentrate this kind of stuff to the new signalboxes - if I build expensive signalbox equipped for in-cab signalling, then all signals connected to it get the long or unlimited sighting distance (for all trains).

[jamespetts]

As far as I understand it, in general there are two types of speed signalling:
- route based - the speed limit is based on the route taken - position of switches, curves on the track, etc. - used in CZ/SK
- distance based - the speed limit is based on distance to next signal at danger - used at TGV.

I thought that the TGV used TVM cab signalling? TVM signals and a specific TVM signalling tower have been produced for Pak128.Britain-Ex. Cab signalling inherently checks the distance to the next signal at danger and begins to brake for it far enough in advance.

There are more in-cab signalling methods, then just ETRMS, that can improve the visibility of signal. And the proper equipment must be on track, train and signalbox. I would suggest to concentrate this kind of stuff to the new signalboxes - if I build expensive signalbox equipped for in-cab signalling, then all signals connected to it get the long or unlimited sighting distance (for all trains).

The way that it works in Pak128.Britain-Ex is that cab signals can only be connected to compatible signalboxes, of which there are two types: one for TVM and one for ETRMS (and the ETRMS one can handle both ETRMS Level 2 cab signalling and the yet to be implemented (both in the game and in real life, although the latter should come before the former) ETRMS level 3 high speed moving block signalling). The cab signals are either the TVM or the ETRMS Level 2 types, and must be built connected to an appropriate signalbox.

[Ves]

I do not know how much that these cost - do you have any idea? The cost relative to other things (such as the regular maintenance of a rail vehicle) is what is really needed.

I found somewhere that the costs for equipping a motorcarset or a loco with ERTMS is arround 2 million Swedish crowns (around 156.000 GBP).
A new Rc-loco (the youngest locos, built in Sweden) costed in the year 1985 5.7 million Swedish crowns, which in todays worth is 11,5 million (ca 898.000 GBP)
The regular maintenance of that particular vehicle, I could not find, only the description "cheap", which could be anything.

This is not quite how I understand route based speed signalling working.

Well, yes and no. Not in a way that a signal can show an aspect to restrict the speed, but a paksetdesigner could use the sighting speed to simulate new signal systems allowing higher maximumspeeds allowed through the times by the government. Not only as a physical sighting distance.

The trouble with hard coding speeds is always what incentive a player ever has to use a signal with a slower speed over a faster one. In reality, safety is the incentive, but we do not have crashes in Simutrans, so that does not work. The only incentive that a player has to use signals with slower sighting speeds are either that they are the best that are currently available or that they enable permissive block working whereas signals with faster speeds do not.

The idea overall with speed signals in simutrans, and the only reason I could think they should eventually be there, is that the government of a country has specified under what rules the trains may operate. There is no incentive whatsoever for the player to put a slower speed signal instead of a faster equal. But if the government has ruled out that "drive, expect stop" also means that you must slow down to 30kmh and continue that speed until you find the stop signal, then that's what the player has to deal with and place the signals to get the most effective network.
The government maybe also has decided that when the train passes a signal that shows: "clear, expect clear, then expect stop", the train must slow down to say 100kmh (just making up numbers and examples) only to accelerate, keep speed or further deceleration dependent on the state of the next signal.

This is the way I foresee speed signaling done in simutrans, as it's adjustable in the dats and the pakset author can for most countries or at least (I assume) simplify their countries rules to adapt to this.

[jamespetts]

I have spent several hours trying to implement the request to allow choose signals to work to and end of choose sign rather than just into a platform, but I am afraid that I cannot make it work for reasons that I do not understand connected to the routing.

I have left in (commented out) my code in this commit here in case anyone else wants to have a go at making this work, but I am afraid that this does not seem to be possible at present, at least with my coding ability/understanding of the Simutrans code.

[zook2]

May I ask that regardless of what new features you implement, you put "Update the $%&§ In-game Help File" somewhere on the to-do list? The current version seems to date back to the days when John Major was PM.

[Isaac Eiland-Hall]

Or perhaps someone can volunteer to update it. People work on things as they have time and the desire. Nobody gets paid.

[zook2]

Yes, exactly! And I consider it my job to prod people to get off the couch and jolly well get things done. I have years of experience.

[Octavius]

I read once in a magazine (years ago, the magazine has probably been recycled by now) that the ATB cabinets, containing the on-board equipment of the dutch automatic train protection system, cost about 200,000 guilders (ca. €90,000). That must have been in the 1990s. The ATB cabinets were by far the most valuable part of old locomotives. The state railways, after privatisation, didn't want to sell old locomotives with their ATB cabinets to their competitors, preferring to keep the cabinets in indefinite storage. One time they sold some old locomotives to a metal recycler with the ATB cabinets still inside (by mistake), and their competitor quickly bought the machines.

Heritage locomotives and foreign maintenance vehicles were allowed to use dutch railways without ATB equipment by waiver, but stricter safety rules stopped this practice. As heritage organisations couldn't afford normal ATB cabinets, full of 1960s technology, they developed simplified and portable equipment using mostly modern solid state electronics. The simplified equipment doesn't show all warning signals. It has no cab signalling, which is present in normal ATB. It just applies the brakes when the drivers doesn't do so after passing a signal ordering a speed reduction. Cost went down to €10,000.

ETCS equipment is even simpler, using standard electronic components. In principle, all one needs is an RFID chip reader, a smartphone, a couple of relays, valves to activate the brakes and cut power, some software and a power supply, all very cheap. But one needs specially approved and heavily patented versions, making the equipment still quite expensive.

[Isaac Eiland-Hall]

Yes, exactly! And I consider it my job to prod people to get off the couch and jolly well get things done. I have years of experience.

It is not your place to try and force people to do things you want. Please refrain from such behaviour here.

Positive feedback is welcome. Constructive criticism is definitely allowed. But we consider ourselves a very polite community.

Do not "prod" people here, please. Nobody needs to "jolly well get things done". Things will happen when they happen.

If someone takes kindly to positive feedback and excitement about a project, awesome! But if they don't, then it is not your place to demand that they do something.

[jamespetts]

I am aware that the help files are rather old; the trouble is that updating them at present is rather like trying to hit a moving target as there is substantial development ongoing at present. There is also a limit on the amount of time that I have, and so great are the number of things that I need to do before I can even begin balancing the pakset, those things generally take precedence, as there is no point in writing the help files until the game is in a state where it can at least be properly balanced.

If anyone else would like to update the help files in the interim, that would be of help.

[Ves]

My brain have been thinking alot about signal issues lately and I must get the questions out of my head, if you dont mind!

The way that it works in Pak128.Britain-Ex is that cab signals can only be connected to compatible signalboxes, of which there are two types: one for TVM and one for ETRMS (and the ETRMS one can handle both ETRMS Level 2 cab signalling and the yet to be implemented (both in the game and in real life, although the latter should come before the former) ETRMS level 3 high speed moving block signalling). The cab signals are either the TVM or the ETRMS Level 2 types, and must be built connected to an appropriate signalbox.

How will this be coded in the game? What I mean is, how costumizable will the ERTMS-levels be? Can I as a paksetbuilder create more versions of a system, say choose what kind of signals can connect to what kind of boxes, or will they be hardcoded?
I think I read somewhere in this thread that the ERTMS signals wont use aspects, will that mean that its the same graphics for all aspects?
What is the difference between ERTMS and TVM? What will the different effect be in Simutrans?

Thankyou, by the way, for the effort to try to implement the "choose drive by path" function! Lets hope there is some other genious out there to make it work!

[jamespetts]

The difference between ETRMS Level 2 and TVM is purely at pakset level: both are coded as "cab_signalling" types. The differences are the type of signalbox with which each can work, the introduction date, cost and maximum speed (TVM is limited to 320km/h, whereas ETRMS Level 2 can reach 500km/h). ETRMS Level 3 will be coded as the "moving_block" working method, which has yet to be implemented in the code. It is possible for pakset authors to determine to which signalboxes that different types of signals connect by choosing the signal groups in the .dat files for both signals and signalboxes.

ETRMS Level 2 (and indeed TVM) signals are indeed just marker boards; however, cab signals can have two separate aspects (danger and clear) if these are encoded in the .dat files.

[Ves]

The difference between ETRMS Level 2 and TVM is purely at pakset level: both are coded as "cab_signalling" types.

So would i hypothetically be able to create a third and a fourth cab signal system?

The differences are the type of signalbox with which each can work, the introduction date, cost and maximum speed (TVM is limited to 320km/h, whereas ETRMS Level 2 can reach 500km/h).

I guess this depends a bit on the first question, but then the speeds can be adjusted in the datfiles of the boxes (The sighting speed you talked about earlier)?

It is possible for pakset authors to determine to which signalboxes that different types of signals connect by choosing the signal groups in the .dat files for both signals and signalboxes.

Ok, so I could specify that a signal works under this, this and this box?

ETRMS Level 2 (and indeed TVM) signals are indeed just marker boards; however, cab signals can have two separate aspects (danger and clear) if these are encoded in the .dat files.

Great that it's possible to put graphics on the two aspects, then you can troubleshoot in deadlocks! I guess the "choose signal ertms version" have more aspects?

[Junna]

So would i hypothetically be able to create a third and a fourth cab signal system?

I assume you want to make some manner of ATC, then yes, as long as it has a box and signals associated with this.

Ok, so I could specify that a signal works under this, this and this box?

Yes.

[jamespetts]

So would i hypothetically be able to create a third and a fourth cab signal system?

Indeed, so long as you only need to change the parameters that are set in the .dat files.

I guess this depends a bit on the first question, but then the speeds can be adjusted in the datfiles of the boxes (The sighting speed you talked about earlier)?

This can be set per signal.

Ok, so I could specify that a signal works under this, this and this box?

You can specify in both signals and boxes: signal_groups=x,y,z, and if any of the numbers on any signal and any signalbox match, the signal can be associated with the box.

Great that it's possible to put graphics on the two aspects, then you can troubleshoot in deadlocks! I guess the "choose signal ertms version" have more aspects?

Yes, indeed, it is possible to display them with two aspects. I think that selective choosing aspects may still work for cab signalling, but I have not tested this.

[Ves]

Yes I was thinking about ATC,and how to acomplish that.
Since ATC was implemented in the 1970, I would think its too early to force the removal of all the different kinds of optical signals, or all are forced to be just ordinary drive/stop signals (today, as far as i know, almost all optical signals are still in places).
However, unless signals are (re-)placed automatically, i can see that there would be no incentive to place a "Cab-threeaspect-signal" as the pre-aspect of the signal would just be worthless and from that perspective, no need to code multiaspects cab-signaling.

Therefore a question (Nooo, really!? ):
When you are about to upgrade a line with a better signalbox or better signals (eg semaphores to light signals, or light signals to cab-signals), would it be possible to 'drag' the upgrade over the tracks? Meaning that instead of the way the current signal type drag works, which removes all signals in order to place new ones, the 'upgrade-drag' would instead just upgrade all existing signal (possibly also removing unnecesary signals).
Now, I can ask if you would consider add the more aspects for the cab signals? as if the upgrade-drag would be considered, all the variation of the existing signals would just be upgraded to cabsignals (but would in Pak.sweden keep their original graphics). Then all existing presignals and variation of signals would not necesarily be demolished already in 1970-ies!

[Junna]

From what I understand, nothing would stop a signal to have both visual aspect and cab-signalling set as the signal types? ATC would probably entail enlarging the sight distance as well to allow a more flexible "moving block".

[jamespetts]

I am somewhat unclear on how multiple (i.e > 2) aspect cab signalling would actually work; can you elaborate? The signalling work is taking quite a lot of time, so I am keen to avoid additional complexities that are not really necessary.

As to dragging to upgrade, there is new code that allows signals to be upgraded automatically whenever the underlying track is upgraded and the signal type is obsolete, but this is not really suitable for upgrading from one signalling system to another, nor between signals that need different types of signalboxes, as, in the former case, there will often need to be a different arrangement of signals, and, in the latter, there is no practical way of making sure that the signals are added to an appropriate signalbox.

[Junna]

I assume they mean that there will be regular/conventional signals while also a "cab-signalling" in use at the same time (because Swedish ATC still uses conventional signals in addition to the in-cab signalling, which I assume is what is wished for implementation.)

[Ves]

I think it got a little too complicated now
Yes, my goal was to make the behavior adapt to Swedish ATC (=cab signals AND normal light signals), but Junna actually pointed a way that it could be done inside the pak, by merely add a bigger sighting speed to a 'normal' system.