I am currently in the process of refurbishing the railway signalling system in Simutrans-Experimental, and I should like views, if possible, on one potential change to the choose signal that I am considering.
Currently, a choose signal will route a train to the next free platform/goods yard siding ahead regardless of whether it is the particular platform at which the train is scheduled to stop, so long as it is part of the same station. This is often used just before terminus or other major stations to allow trains to select from one of a number of platforms. It is typically represented in the game by graphics of a junction signal, with the "clear" state being represented as the junction signal with a route indication set. There is no state in which the signal will show clear without a route indication set.
I wonder whether it might be helpful for a player to be able to specify in a convoy's (train's) schedule whether to allow a choose signal to have effect for any given stop. If this is enabled for the next stop in the train's schedule, the train would behave as it does now. If it is disabled for the next stop in the train's schedule, it would treat any choose signal as an ordinary stop signal.
This could be represented graphically by having a different display for the signal's clear (or caution) aspect(s) if choosing were enabled or not, perhaps, for example, by displaying the junction feather on a colour light signal as illuminated if choosing is enabled, but not otherwise, or showing a clear signal on the primary route when it is disabled, and on the secondary route if when it is enabled on a semaphore junction signal.
One reason that I suggest this specific change is because it will probably be quite easy to implement in the code (especially as I am in any event going to add new types of signal aspects to the code and new types of schedule parameters for other purposes), so please note that alternative suggestions are unlikely to have this advantage.
I should be interested in people's views on this, and in particular on whether this parameter ought to be enabled or disabled by default.
This would be useful -- currently I have to have a "end of choose" signal for the specific platform which I wish not to be affected by the choose (for example, a small bay platform only accessible from one side for a reversing service).
By the way -- currently end of choose signals cause dramatic slow-downs in certain conditions (to 1km/h), especially if it's on a bend.
Also, you need to look into how one-way signals cancel out communication between signals.
Thank you for your feedback: that is useful.
Can you post the other two issues in separate threads with saved games or instructions to reproduce reliably? I should be very grateful.
I imagine the dialogue to permit adding "Ignore signal at (x,y)" − the default surely would be that all visible signals would be in effect. An historic rule-book might have a line: "Trains on the Glen Line adhering to schedule are superior to (will ignore) signal at milepost 135.7" right?
The idea is not that the train will ignore the signal, but that it will treat it as an ordinary stop signal rather than as a choose signal. It will thus still have the signalling function, but not the choosing function.
Quote from: jamespetts on August 18, 2015, 09:20:07 AM
... I wonder whether it might be helpful for a player to be able to specify in a convoy's (train's) schedule whether to allow a choose signal to have effect for any given stop. If this is enabled for the next stop in the train's schedule, the train would behave as it does now. If it is disabled for the next stop in the train's schedule, it would treat any choose signal as an ordinary stop signal.
...
I should be interested in people's views on this, and in particular on whether this parameter ought to be enabled or disabled by default.
I don't think I have ever been in a situation where I would want vehicles of a certain line not to respect a placed choose signal. Therefore I'd suggest that default behaviour should be to respect the signal (pre-set: enabled).
I havent either been in a situation where i would want a train to ignore a placed choose signal.
QuoteOne reason that I suggest this specific change is because it will probably be quite easy to implement in the code (especially as I am in any event going to add new types of signal aspects to the code and new types of schedule parameters for other purposes), so please note that alternative suggestions are unlikely to have this advantage.
I dont know how far away alternative suggestions starts to struggle, but I would suggest that you aim to make it simulate more like a proper 'entry signal' (that is the last signal, protecting the station).
It can basicly show "Stop", "Drive, expect stop" and "drive, expect drive(through the station)".
The "stop" makes sence, the "drive, expect stop" makes it behave like the current choose signal. "Drive, expect drive" would be shown for trains not stopping at the station, only having a route through it AND the track on the other side of the station is free. In the last case, the signal would find a route through the station till eg end of choose or a signal, and if succesfull show "drive, expect drive".
There is much to be said for Jando and Ves's preference for default, in that people with saved games from an earlier version will have set things up assuming that all vehicles will treat a choose signal as such.
As to Ves's reference to what is described as an "entry signal", may I ask to which signalling system that you are referring? This is not UK terminology, so it is not so easy for me to understand. The choose signal is more about convoys using whichever platform (etc.) is free rather than telling the (imaginary) driver what the next signal will display. I have already planned in some detail the system that will have that latter function.
I believe the suggestion is that through trains should choose a platform to pass through the station using (as opposed to just going onto the track right ahead, even if this is occupied by another service)? I might be wrong though.
He's referring also to Swedish practice of four aspect colour lights where each signal also works as a pre-signal for the next as well as speed signalling (two blinking green being pass at full line speed, etc) which I guess makes it a bit confusing an explanation.
Junna is right in the interpretation of my poorly description. :-p
Basically a three aspect signal, with the normal choose behavior and a function to guide trains through a station (In case the default track is already occupied).
In Sweden it looks like a normal signal (it is physical just a standard 3, 4 or 5 light signal) but has a sign and the function to tell the driver what is to be expected at the station in order to stop or pass. In Denmark I know it's a special signal telling if it's clear through the station or not and then with a big square underneath the signal which can show geometric pictures telling what speed to keep.
I'm sure there in Britain also is some kind of similar practice.
Another good use will come if you combine the two: you can put several platforms after each other (that is: say three platform tiles in a row, a tile gap and then three other platform tiles on the same track) and make trains navigate through a designed layout of parallel tracks until they reach their given platform.
Why this layout you may ask, but many stations in at least Sweden has this layout. Then the tracks are labelled 1a, 1b, 2a etc to keep them separated. Else if you have a very big and complex station layout with many sidings.
We do not have speed signalling in the UK, but I am aware that it is common in other parts of the world. There was a very small part of the country (Mirfield) that had experimental speed signalling from 1932 to 1970, and I have made graphics for this type of signal to allow a speed signalling mode in Pak128.Britain-Ex, which will allow me to test this feature which should be able then to be added to other paksets simulating railways in other parts of the world.
The UK signalling practice has, with that limited exception, always told drivers which route that they are taking and what the next signal aspect is going to be, and drivers have to work out how fast to go from that information. Choose signals in Pak128.Britain have always represented junction signals (telling drivers which route that they are taking).
Speed signalling aside, however, what appears to be requested is a new feature for choose signals that work outside stations. This is actually likely to be really rather complicated to implement (how far ahead does it look to determine freedom of blocks? Looking 100km ahead would be silly, for example, but where exactly would it stop, and how much of a diversion should it tolerate?), so this is unlikely to make it into this next round of signalling improvements.
Quote from: jamespetts on August 19, 2015, 11:01:47 PM
Speed signalling aside, however, what appears to be requested is a new feature for choose signals that work outside stations. This is actually likely to be really rather complicated to implement (how far ahead does it look to determine freedom of blocks? Looking 100km ahead would be silly, for example, but where exactly would it stop, and how much of a diversion should it tolerate?), so this is unlikely to make it into this next round of signalling improvements.
I think Ves'es point, as far as I can tell, was that the junction signal would apply to trains not stopping at a particular station, but would only apply to the station premises (platforms and their signals) up to around a signal beyond. This would be useful - as it is now, I find I have to set goods trains to stop at passenger stations in order for them to "choose" a platform rather than wait for a long time to get a clear path straight through the platform straight ahead, when this block happens to be occupied by a waiting or reversing service.
Interesting with speed signaling! Looking forward to see that!
It could stop where the player put the "end of choose" sign? It has to be put strategical and if no sign is put, the feature is off by default.
A Ctrl-click on the signal brings up a menu where the feature may be switched on or off. Also here you could have a field instead of the end of choose sign, for the player to specify how many tiles/meters the signal should look.
Isn't route calculation done by adding penalty costs for every turn and hill? If that cost really is a number, add a field in the mentioned menu for the player to specify how much the diverge is allowed to cost. Some experimenting is however needed to find out how to tweak that number.
I understand if it's too complex to add now, but this is something I've thought about for a long time and I hope it some day will make it to the game!
Edit: I read now that you wrote "outside stations". This is not meant to be outside stations in another way than the current choose signal is outside the station. As Junna points out, it's specific for the stations in order to let traffic pass through when the straight most track is occupied.
I agree With Junna and Ves that a method to let non-stopping trains pass through a station would be a nice addition. I have frequently been in a situation as well where goods trains have to wait because another train occupies the direct route through a station. Also happens with trains passing through a station on their way to or from a depot.
The luxury version would be to have the passing train slow down while passing through the station. :)
Quote from: Jando on August 20, 2015, 10:39:07 AMThe luxury version would be to have the passing train slow down while passing through the station. :)
Qould maybe be achieved by making station tiles force a speed restriction to the underlying rail? Either specified in the datfiles or a general speed restriction for all station tiles in simuconf.
Quote from: Ves on August 20, 2015, 04:09:44 PM
Qould maybe be achieved by making station tiles force a speed restriction to the underlying rail? Either specified in the datfiles or a general speed restriction for all station tiles in simuconf.
What real life mechanic would this be simulating? In the UK, trains often pass through stations at full line speed without stopping, even when full line speed is 200km/h.
I dont know if there exist rules with that, it was just a brainstorm. however I remember an episode in Denmark with a freight train that maybe had driven too fast through a station, but I can't say if it was a restriction to just that station or a general speed restriction through all stations. Anyway, it's maybe best to wait till speed signaling :-)
That would presumably be speed limit of the train or speed limit due to the points (usually when speeds are restricted through a station, it is due to pointwork not being set to allow high speed).
I would much rather have a schedule feature for "smart platform choice". Such a feature to allow reverse schedules to choose the opposite platform when running through a centre station of a double line. Currently each stop in such a line has to be added twice, once for each direction.
Quote from: DrSuperGood on August 20, 2015, 08:16:29 PM
I would much rather have a schedule feature for "smart platform choice". Such a feature to allow reverse schedules to choose the opposite platform when running through a centre station of a double line. Currently each stop in such a line has to be added twice, once for each direction.
This already exists, although it is not optional.
Hi everybody,
I have a lot of things on my mind, I hope not to get too far off topic.
First to (obeying/ignoring) choose signals. Currently I'm quite satisfied with how it works, but sometimes I have considered this: I want some trains to choose from a set of platforms, and other trains from other set of platforms. My idea was that it could be implemented in the schedule, where you could exactly specify all alternate platforms/waypoints. That would make for quite a lot of micro-management, so a switch for choose-all would be needed to emulate choose signal. Eventually such change in schedules would make choose signals obsolete. (And end-of-choose signals as well.)
If the signal is going to be as it is, I would like to see a three or four aspect behavior that mimicks the speed signalling in CZ/SK (and perhaps other continental countries). Danger - Red, Clear to scheduled platform - Yellow (full speed expect stop), Clear to alternate platform - 2x Yellow (reduced speed, expect stop). For trains passing through - Yellow or Green (warning or clear) acting as a distant signal for the next signal at the end of platform. This is how real "station entry" signals work nowadays. Older entry signals (pre 1950's) did not act as a distant signal, so the driver had to slow down in the station and be ready to stop.
In my games I usually put choose signal at the entry of station, so it seems to me natural to use entry signal graphics (and behavior) for czech (and swedish) pak.
As to the speed signalling it is always bound to switches and tells the driver the max speed for the path that was set for him. Typically just if he goes straight (full speed permitted) or to a siding (reduced speed). But I have seen stations with a few high speed (100 km/h) switches and bunch of ordinary (50 km/h) switches. It must be a nightmare to remember and signal that safely in UK.
Anyway we do not need full blown speed signalling in simutrans. But using it to show, that alternate platform was chosen, might be a nice eye-candy. For UK singnals you could show clear on one arm form scheduled platform and on the other for alternate platform. (Or enable the indicator only when alternate platform is chosen.
And one side note to signal-boxes. I understand that they add more realism, like control towers on airports. But from a game play view they are just adding more clutter to the game, and make it harder for beginners: "Uh hey, I'm a newbie and I can't build signals, WTF is going on?" Please make them optional.
If you wanted to simulate the operating costs of signalbox, wouldn't just adding monthly maintanence fee for signals do the job? High maintenance for semaphores, low for electric light signals.
Last thing about pre-signals (distant signals). IMHO they should depend only on the immediately next stop (or choose) signal.
If the UK practice is different please consider this behavior as an option.
In CZ/SK all signals outside of station have a pre-signal (unless the previous signal is a 3-state signal). On the other hand there could be a repeater pre-signal half way between pre- and stop signal. For simutrans it would be more or less just eye candy. Signals within station are usually 3-state since 1950's (except for the departure signal). There are no pre-signals within station, with the exception of repeater pre-signals. Those often appear in curved stations, where the departure signal cannot be seen from the platform.
Historically there used to be signals without pre-signal, and the drivers had to know, where they are, and slow down accordingly, but the were abolished in 1920's-30's. Pre signals were introduced about 1890's. In those times it might have happened that you got some signals with pre-signal and some without, but pre-signal showed only the aspect of immediately next signal.
Uff, that's it.
Choosing from an arbitrary set of platforms would be quite a substantial amount of work (especially with the GUI, which is very difficult to work with in Simutrans), so it is unlikely to make it to the next version, but it is something to bear in mind for the future. A choose signal is still likely to be required to determine the precise point at which the train should consider deviating from its standard route.
As to speed signalling, this is a somewhat complex subject. As you may know, apart from a short lived experiment in the 1930s (lasting until the 1970s), the UK does not and never did have speed signalling, and instead relied and relies on a driver's route knowledge. My knowledge of the workings of speed signalling is somewhat limited, but, from what I understand, the signals determine the speed at which a train may pass them. (If that is so, that suggests that a driver will need to know of an upcoming speed signal in advance by virtue of an earlier signal that is not itself a speed signal, suggesting in turn that speed signalling requires multiple aspect signalling; if I am wrong about this, please let me know how it does work).
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).
I think that the station entry signals (both old and new type) that you suggest can be modelled using the states and types that I am planning on encoding, but let me set out those states to be sure. One will be able to have a two, three, four or five aspect signal using the track circuit block working method. A two aspect signal shows just stop or clear (meaning that the next signal might or might not be stop, and the driver must proceed accordingly). Three, four and five aspect signals can show aspects showing that the next, second next and third next signals respectively are at danger, but that the line is clear to there. An signal of between two and five aspects will be able to be a choose signal, which will work as now, save that a train will be able to specify in its schedule to ignore choose signals for any given next destination. Each choose signal will have different graphics to the underlying base signal. Further, for all aspects other than danger, there will be different graphical states for where the signal is cleared with choosing enabled and with choosing disabled. I am also planning on adding repeaters, which give a warning of the aspect of the next signal. Does this seem sufficient for Czech or Swedish signalling?
As to signalboxes, the plan is for these to be optional at a pakset level, with one exception, which is that signals using the absolute block working method will need to have signalboxes defined. This is because signalboxes will be part of the simulation logic for absolute block signalling. Signals using the track circuit block working method (as with multiple aspect signals, described above) will not need to have signalboxes defined. The differences between absolute block and track circuit block signalling for Simutrans purposes will be:
(1) in absolute block signalling, a distant signal is clear only when all stop signals on the route ahead assigned to the same signalbox as the distant signal are also clear, whereas a distant signal (or multiple aspect signal showing caution) in the track circuit block working method applies only to the next signal;
(2) in absolute block signalling, all signals will be at danger unless a specific route is cleared, whereas in track circuit block signalling, any unidirectional signal whose route to the next signal in its direction involves no converging or diverging routes (i.e. points) will automatically clear when the train has left the block (this will be only of graphical effect, but is significant in multiple aspect signalling); and
(3) multiple aspect signalling will be permitted in the track circuit block working method, but not absolute block.
Signalboxes are important, though, not just for operating cost, but for operational flexibility: the old mechanical signalboxes, which had to be placed frequently along a route, and which operated in the manner described above for absolute block, restricted in real terms the capacity of trains on that route compared to more modern systems. The need to place signalboxes regularly and have signals within a certain distance of that signalbox significantly affects signal placement; it is very common at present to see long lines of evenly spaced signals in the mid-Victorian period in the game, which would simply not have been possible at the time.
I hope that this assists.
That was at long post to pull quotes out from, only using a small phone screen! Quickly getting lost :p
Quote from: jamespetts on August 26, 2015, 09:38:32 PM
An signal of between two and five aspects will be able to be a choose signal,
Do you mean that you can put a choose signal between multiaspectsignals and make the choose signal interrogate with the multiaspectsignals? Or do you mean that the choose signal can BE a multiaspectsignal (like the earlier described multiaspectsignals) and behave like a say 3 or 4 or 5 -iaspectsignal when the train is just passing through?
Quote
Each choose signal will have different graphics to the underlying base signal.
This really woke my curiosity! If you wouldn't mind to elaborate :)
Quote
I am also planning on adding repeaters, which give a warning of the aspect of the next signal.
May I ask, how will you make the player place this sign? What will the consequence be if you don't? Could it be automated, so it's automagically being built say 5 tiles, or in the middle between the presignal and the main signal?
Quote
Does this seem sufficient for Czech or Swedish signalling?
For Czech signaling I come too short, but for Swedish, all we need in aspect of entry signal (choose signal) is that beside from stop and drive expect stop, it should be able to show drive expect drive.
Which makes it a three aspect "choose" signal!
May I ask, did you get any further on the consideration to implement the idea that trains driving through a station get to "choose" a track to make the drive by?
Quote from: Ves on August 26, 2015, 11:08:15 PM
Do you mean that you can put a choose signal between multiaspectsignals and make the choose signal interrogate with the multiaspectsignals? Or do you mean that the choose signal can BE a multiaspectsignal (like the earlier described multiaspectsignals) and behave like a say 3 or 4 or 5 -iaspectsignal when the train is just passing through?
The latter. If one has a five aspect choose signal, the plan is to have the following distinct slots for different graphics for it:
(1) danger;
(2) caution (without choose);
(3) caution (with choose);
(4) advance caution (without choose);
(5) advance caution (with choose);
(6) preliminary caution (without choose);
(7) preliminary caution (with choose);
( 8) clear (without choose); and
(9) clear (with choose).
There is also a possibility of adding a further "call on" aspect graphics slot at a later time for permissive working into stations if and when I implement convoy/train recombination. Precisely when the "with choose" and "without choose" aspects are displayed I have not yet decided finally, as I have not reached the point of getting to the simulation code yet: I am still working on signalboxes.
Quote
This really woke my curiosity! If you wouldn't mind to elaborate :)
I hope that the above is an adequate explanation? Note that the above list of graphics are for a specifically choose signal and its aspects. There would be a further set of graphics for a normal multi-aspect signal (assuming 5 aspects):
(1) danger;
(2) call on*;
(3) caution;
(4) preliminary caution;
(5) advance caution; and
(6) clear.
* Call on will be used for permissive block signalling where a train, having been brought to a stand at a danger signal, may proceed beyond it in drive by sight mode if the path to the next signal is nothing but straight track with no converging or diverging routes.
QuoteMay I ask, how will you make the player place this sign? What will the consequence be if you don't? Could it be automated, so it's automagically being built say 5 tiles, or in the middle between the presignal and the main signal?
The reason that I thought to add repeaters is that they were used for early time interval signalling. They are intended to work in the same way as a pre-signal; it may well be that they do not need to be coded differently from pre-signals at all. The consequence of not having a repeater or a pre-signal is that a driver would have to slow to a speed at which the train can stop within sighting distance of the next signal.
QuoteFor Czech signaling I come too short, but for Swedish, all we need in aspect of entry signal (choose signal) is that beside from stop and drive expect stop, it should be able to show drive expect drive.
Which makes it a three aspect "choose" signal!
Does the explanation above about choose signal aspects satisfy this requirement?
QuoteMay I ask, did you get any further on the consideration to implement the idea that trains driving through a station get to "choose" a track to make the drive by?
I can't say that I did, as I have not yet started on the simulation code.
Incidentally, can you confirm whether my understanding of speed signalling in the above post is correct?
To speed signalling. It's a long topic, and I could not find some nice reference in English. So I'll try to explain, and give link to Czech page with all combinations displayed. However they are definitely not needed for simutrans. As you pointed earlier the trains themselves do the braking as necessary. It would be just a logical way how to display the "with choose" aspects of choose signals.
-- explanation -- skip if not interested --
Have a look at all combinations here: http://vlaky.bestsite.cz/zeleznice/rychlostni-navestni-soustava-2-4.htm
In the first part there are single light signals - those work as distant signal (except for red) - you can pass them at top speed, and they inform you about the speed limit at next signal. Stuj = danger, vystraha = caution, volno = clear, ocekavejte rychlost X km/h = expect speed X km/h. Then there are two (multi) light signals. The top one is the distant signal as above, and those below tell the max. speed for the following array of switches. Descriptions are written bottom up e.g.: rychost 40 a volno = speed 40 (now) and clear (full speed on next signal). There are special aspects for 40, 60, 80 and 100 km/h. Other speeds can be indicated by numbers. If a distant signal cannot show the precise speed it has to show lower speed or caution. (Most mechanical distant signals are not equipped for speed signaling, even though it is possible.)
There are a few special aspects - steady white = shunting allowed, blinking white = call-on (proceed in drive by sight, used only when something is broken).
Real example - train has to go through a station, but the straight track is occupied, so it has to pass through sidings at 40 km/h:
distant signal shows blinking yellow (expect 40), entry signal shows blinking yellow (top) and steady yellow (bottom) = now 40 expect 40, departure signal show green and yellow = now 40 and then clear. If the train has to stop, the entry signal will show two yellow lights (now 40 and caution). The distant signal would show blinking yellow (expect 40).
-- end of explanations --
Repeaters - i think that in game they can be identical to distant (pre) signals. They would be mostly eye-candy. Distant signal in the middle of platform would look awkward. However, on busy lines they may allow a train to avoid full stop after passing a signal at caution, if the main signal clears in the meantime.
The 9 states for choose signal are more than enough for CZ/SK. I think only 1,2,3 and 8 are useful. Those can be shown also on semaphore signals. We do not have advance and preliminary caution in CZ. However speed signaling can be combined with repeater pre-signal, denoted by white light in the middle (or below the color light in case of pure repeater). In real life it appears at complex stations, with signals in the middle of station. I did not have so complex station in simutrans.
To 4,5-aspect signals - I'm not sure if they are worth implementing in game. As far as I understand the automatic (circuit) block signalling - a train should fit completely in one block, and (for 3-aspect signals) the block must be longer that braking distance. In real life, trains are usually shorter than their braking distance, so it is useful to make shorter blocks using 4- or 5-aspect signals to fit more trains on the track. The Czech way to do that was these 4-aspects - clear (green), caution (yellow), repeated caution (yellow+white), danger (red). In that case the block can be half of braking distance. But due to dual scale in simutrans trains are much longer than their braking distance (even in experimental). I know many players put signals every 2,3 tiles to maximize throughput, but it looks awkward.
call on signal - I can't imagine how that would work in game. If the block is free, reserve the block and show clear. If not, show danger. CZ call on signals are used to let a train into station, when something is broken, and failures of any sort are not (yet) implemented in simutrans.
Signalbox explanation accepted ;)
Generally, yes. Swedish speedsignalling is unspecific and only involves slower speed for diverging routes or routes signalled through points, as it is used (since the 1940-50's) with in-cab speed signalling (Automatic Train Control, to automatically brake the train if speed is exceeded or a signal is passed at danger) with Centralised Traffic Control (power box). Frankly, it is not exactly necessary even here, and any ATC in-cab limits override any speed signals (as does any line-side speed limit markers). I think it originally probably drew inspiration and technology from the New York Central's speed signalling & CTC scheme of the 1930's.
Thus, they do not require the train to slow if ATC gives other speed (only 40 or 80 is used; i.e. even full green these days is only "80" should you lack ATC indicator, which essentially works as AWS with ramps in the tracks, although with more details provided) (with exception for the equivalent of a "yellow" aspect, as it is read as "slow to 40 and prepare to stop at next signal", i.e. the practice is similar to how it is operated in the UK in practice though not in shape (German practice is similar as well, but uses those weird half-incomprehensible position lights).
Obviously lines without ATC would not allow higher speeds, but this was generally not a problem, as they were of such standard that 70km/h was often the maximum (Swedish train speeds remained terribly slow until the 1930's high-speed electric locomotives, essentially all steam locomotives were limited to 90km/h at the highest). As an aside, one not-so-unimportant line was when it opened in the late 1800's (I forget which exactly) plagued by a blanket speed limit of 27km/h due to poor track quality.
Quote(1) danger;
(2) caution (without choose);
(3) caution (with choose);
(4) advance caution (without choose);
(5) advance caution (with choose);
(6) preliminary caution (without choose);
(7) preliminary caution (with choose);
(8) clear (without choose); and
(9) clear (with choose).
Ah I see, that looks good! One question though, in which situation will you need advance caution and preliminary caution with choose function? I suppose the "without choose" is for trains passing through the station?
And yes, that made it clear why you will need several choose signal types!
QuoteDoes the explanation above about choose signal aspects satisfy this requirement?
If we for the moment ignore the speed-functions, then to my knowledge: Yes!
QuoteIncidentally, can you confirm whether my understanding of speed signalling in the above post is correct?
For Sweden, yes and no :-)
Although Im no expert, I will try to elaborate from what I know about Swedish signaling:
First of all to clarify, the only speed signaling in Sweden is "drive 40" (= max 40kmh and drive carefully!). Thats the only speed signaling that is done in Sweden and are used when the driver needs to enter a station or pass a junction etc. All other speeds are trackspeeds.
Quote[...] the signals determine the speed at which a train may pass them. (If that is so, that suggests that a driver will need to know of an upcoming speed signal in advance by virtue of an earlier signal that is not itself a speed signal, suggesting in turn that speed signalling requires multiple aspect signalling;
Yes. Presignals will warn if the next signal show "drive", "stop" or "drive 40".
QuoteSpeed signalling, so far as I understand it, works in relation to two matters: (1) forthcoming stop signals; and (2) forthcoming route based speed restrictions.
No, Speed signaling will only be used in the second case. The "route based speed restriction" would typically be a station or a junction or something similar that has to be passed slowly or where the driver need to be carefull.
QuoteIt does not necessarily tell the driver which of those two things requires a reduction of speed.
The signal itself doesnt show whats the cause of "drive 40", however there might be a sign underneath the signal telling the cause.
QuoteIt 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.
Agree!
QuoteHowever, 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.
This is true also in Sweden, as speed signaling (remember, there is only "drive 40") mostly are used at stations etc.
QuoteLine 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.
True. Although if the train had passed a "drive 40" message, it will drive 40kmh and calculate brakedistance etc from this speed.
QuoteIt 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.
True, up until Automatic Train Control (ATC) is implemented in 1980 allowing much higher speeds. This messes it a little bit. Now the allowed max speed and the state of the next signal is at any time showed in the cab. The earlier "Drive 40" message is to ATC-trains only "drive carefully" and they may drive the speed ATC says which could be as high as 70kmh I think. This also outdates the presignals as the next signal state are showed in the cab. It requires installation in the train and on the track. Trains not having ATC onboard are now only allowed to drive 80kmh on rails featuring the ATC equipment. On other rails not having ATC, the old speed signs are still valid for all trains. (in Simutrans, they would behave as normal on non-ATC tracks)
To simplify how to use this:
ATC trains on ATC tracks: The train always drives as fast as it can based on brake etc. and the "drive 40" message is overruled.
non-ATC trains on ATC tracks: Never exceed maxspeed 80kmh, respect the "drive 40" messages.
All trains on non-ATC tracks: Drives as fast as possible based on brake etc. but respecting the "drive 40" messages.
QuoteDo 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.
As the only speed signaling is "drive 40" this is not true.
So, when you in the future start working on speed signals, maybe consider this to give most flexibility:
code the signals so any signal (choose signals, normal signals, X-aspectsignals) at any aspect can set a maximum speed to be used after the signal. Possibly also aditional graphic slots for paksets with other types of speed signal elements.
update the presignal to have corresponding more aspects (from current two aspect to minimum three or more aspect) and additional graphic slots.
Implement some kind of ATC which can be 'installed' in trains (upgrade feature?) and on tracks. Maybe the ATC features already are to be implemented in this first batch?
Hee, both Junna and Vladki managed to reply while I was writing, so sorry if something is then already answered :P
Interesting - that is most useful. I think that I may have misunderstood speed signalling, as, as you have both explained it, it is mainly about the speed of the
route that a train is about to take, and not prescribing a specific speed for the process of slowing down to a stop signal at danger. That makes my life somewhat easier, as it seems to me that this does not need to be specifically implemented in Simutrans at all. However, now that I have drawn the graphics for the Mirfield type speed signals, I will still deploy them in the game (and they will still be useful for testing 5 aspect signalling in any event, which is, as I understand it, used in some parts of Europe).
Quote
Ah I see, that looks good! One question though, in which situation will you need advance caution and preliminary caution with choose function? I suppose the "without choose" is for trains passing through the station?
And yes, that made it clear why you will need several choose signal types!
That is a good question - that would depend on (1) how I implement the relationship between the signal graphics and the option to disable choose signal use; and (2) whether I implement the suggestion of having choose signals used for non-stopping routes.
Quote
True, up until Automatic Train Control (ATC) is implemented in 1980 allowing much higher speeds. This messes it a little bit. Now the allowed max speed and the state of the next signal is at any time showed in the cab. The earlier "Drive 40" message is to ATC-trains only "drive carefully" and they may drive the speed ATC says which could be as high as 70kmh I think. This also outdates the presignals as the next signal state are showed in the cab. It requires installation in the train and on the track. Trains not having ATC onboard are now only allowed to drive 80kmh on rails featuring the ATC equipment. On other rails not having ATC, the old speed signs are still valid for all trains. (in Simutrans, they would behave as normal on non-ATC tracks)
To simplify how to use this:
ATC trains on ATC tracks: The train always drives as fast as it can based on brake etc. and the "drive 40" message is overruled.
non-ATC trains on ATC tracks: Never exceed maxspeed 80kmh, respect the "drive 40" messages.
All trains on non-ATC tracks: Drives as fast as possible based on brake etc. but respecting the "drive 40" messages.
This is cab signalling, I believe: I specifically plan to implement cab signalling as a working method, and have already produced graphics for two systems of cab signalling in use in the UK (TVM and ETC).
Quotecode the signals so any signal (choose signals, normal signals, X-aspectsignals) at any aspect can set a maximum speed to be used after the signal. Possibly also aditional graphic slots for paksets with other types of speed signal elements.
If this is used only for route speed, is this really necessary or desirable in Simutrans?
QuoteIf this is used only for route speed, is this really necessary or desirable in Simutrans?
I dont know if its necessary, Im just thinking about futureproofing. For the swedish pak it would be lovely if the choose signal can add a speed restriction at one condition which at least I think is meaningfull, and then Im just thinking that other future paksets might have other niche-wishes.
QuoteThis is cab signalling, I believe: I specifically plan to implement cab signalling as a working method, and have already produced graphics for two systems of cab signalling in use in the UK (TVM and ETC).
Great to hear! Is it customizable? How are the player implementing it in the game?
incidentally, did you give flashing lights some more consideration?
Quote from: Ves on August 27, 2015, 09:07:06 PM
I dont know if its necessary, Im just thinking about futureproofing. For the swedish pak it would be lovely if the choose signal can add a speed restriction at one condition which at least I think is meaningfull, and then Im just thinking that other future paksets might have other niche-wishes.
Speed signalling is inherently difficult in Simutrans because, unless the player is somehow forced to place signals at very specific intervals and in very specific places, the speed has to be determined on the fly based on the actual track conditions rather than a fixed speed encoded in the signal. In reality, signal placement would be governed, I imagine, by very strict and precise rules, but there is no practical way of enforcing that in Simutrans. How precisely did you imagine this mechanism working? I need to understand whether this is something that can sensibly be implemented. I had a specific idea of how to implement speed signalling if it had been based on the aspect of the next signal, but this is much harder if it is not, and it is difficult to see the relevance of it.
QuoteGreat to hear! Is it customizable? How are the player implementing it in the game?
Cab signalling would be implemented by the player placing cab signals (sign boards, usually). The cab signals would be assumed to have an infinite sighting distance; otherwise, the system would work in the same way as the track circuit block working method.
There will also be a parameter for each type of signal determining the "sighting speed" (that is, the maximum speed at which it can be approached in any state; this is the maximum speed of the signalling system as a whole). This is intended to simulate the restriction of speed based on the type of signal (such as that non-cab signals cannot be approached at greater than 200km/h or else the driver risks not seeing them or that early (i.e., pre-ETRMS level 3) types of moving block signalling can only cope with a train going relatively slowly).
Quoteincidentally, did you give flashing lights some more consideration?
I am looking at the graphics code now, and it seems as though it is not designed with flashing lights in mind at all, and I am not really in a position at present to overhaul the graphics code substantially, but only to make minor alterations necessary for the work.
If someone were to be able to modify the graphics code at some point to accept flashing light signals, they could be added to the simulation code; but, currently, the system is based on the premise of each aspect having a single image.
Quote from: jamespetts on August 27, 2015, 08:45:17 PM
Interesting - that is most useful. I think that I may have misunderstood speed signalling, as, as you have both explained it, it is mainly about the speed of the route that a train is about to take, and not prescribing a specific speed for the process of slowing down to a stop signal at danger. That makes my life somewhat easier, as it seems to me that this does not need to be specifically implemented in Simutrans at all. However, now that I have drawn the graphics for the Mirfield type speed signals, I will still deploy them in the game (and they will still be useful for testing 5 aspect signalling in any event, which is, as I understand it, used in some parts of Europe).
Yes, speed signalling is about max. speed permitted on the route. Braking in time is driver's responsibility (with the help of pre-signal). And yes you are right it does not need to be implemented. As I said before, I would just use it for graphics showing the "choose" aspect. Well I already use some of those aspects for choose and long signals.
I don't know the details, but TGV uses system that signals the max speed according to how many free blocks are ahead. Maybe that was what you had in mind before. In principle I would say it is similar to that 5-aspect system with preliminary and advanced caution. It is needed only if braking distance is much longer then desired block length.
I found description of that UK speed signalling: http://www.signalbox.org/signals/lmsspeed.htm
Wow, that's a mess. It seems that they tried to combine speed, route and 5-aspect signals together...
Yes, I had found that description, too. It does seem somewhat of a random agglomeration of things, but it should be an interesting thing to have as an option.
QuoteCab signalling would be implemented by the player placing cab signals (sign boards, usually). The cab signals would be assumed to have an infinite sighting distance; otherwise, the system would work in the same way as the track circuit block working method.
Ok, so the cab signaling will basicly be a signal like other signals, only with a higher (unlimited) sighting distance? Will you model that the trains needs equipment in order to use the cab signaling (thinking of that old steam locomotive one forgot to replace, suddently getting cab signaling free of charge)?
In real life, although cab signaling works by itself, its coordinated with existing signals so trains without cab signaling still can go there. Have you considered that, instead of replacing the current signals, the cab-signal would add to the existing signals? 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. Combined with an "upgrade for cab signaling" for all powered vehicles, then the vehicles not upgraded would go as before and the vehicles which are upgraded gets the benefits from the cabsignaling (higher speed for instance). Also you can still watch the signalstates in deadlocks etc. which could come in handy. Im not sure if im clear in my writing so please say if its confusing!
QuoteSpeed signalling is inherently difficult in Simutrans because, unless the player is somehow forced to place signals at very specific intervals and in very specific places, the speed has to be determined on the fly based on the actual track conditions rather than a fixed speed encoded in the signal. In reality, signal placement would be governed, I imagine, by very strict and precise rules, but there is no practical way of enforcing that in Simutrans. How precisely did you imagine this mechanism working? I need to understand whether this is something that can sensibly be implemented. I had a specific idea of how to implement speed signalling if it had been based on the aspect of the next signal, but this is much harder if it is not, and it is difficult to see the relevance of it.
Yea both of you might be very right that general route speed signaling arent really needed in Simutrans.
But just to clarify what I was thinking for my own purpose: The Swedish "drive 40" combined with the choose signal would force the train to only drive 40kmh into the station. This is a security precausion (I guess) and sets a natural limit on the number of trains the signal and stations can handle. This would also make the advantages for cab signaling even bigger than it is.
If you wonder how I would specify it in the dat, I would go for something like:
Aspect1=
Aspect2=40
Aspect3=
where nothing specified would mean no speed restriction at all. The speed restriction would only work until next signal or stop at a platform.
What I was proposing is that (if) you decide to implement this at the choose signal, then the step to implement this to all signals maybe not is so huge. Then another paksetmaker maybe wants to make, say Vladkis example with the TGV trains.
Quote from: Ves on August 27, 2015, 11:27:19 PM
Ok, so the cab signaling will basicly be a signal like other signals, only with a higher (unlimited) sighting distance? Will you model that the trains needs equipment in order to use the cab signaling (thinking of that old steam locomotive one forgot to replace, suddently getting cab signaling free of charge)?
In real life, although cab signaling works by itself, its coordinated with existing signals so trains without cab signaling still can go there. Have you considered that, instead of replacing the current signals, the cab-signal would add to the existing signals? 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. Combined with an "upgrade for cab signaling" for all powered vehicles, then the vehicles not upgraded would go as before and the vehicles which are upgraded gets the benefits from the cabsignaling (higher speed for instance). Also you can still watch the signalstates in deadlocks etc. which could come in handy. Im not sure if im clear in my writing so please say if its confusing!
I had wondered about this, but, by my understanding, it is possible for trains that do not have the equipment built in to have portable equipment taken into the locomotive. I know that preserved steam locomotives have used cab signalling on the UK mainline in this way for special trains. As a result of this, it seems to me unlikely to be necessary to simulate incompatible trains reverting to colour light type signalling (and note that both the TVM and ETC/ETRMS Level 2 systems use fixed sign boards incapable of displaying different aspects).
QuoteYea both of you might be very right that general route speed signaling arent really needed in Simutrans.
But just to clarify what I was thinking for my own purpose: The Swedish "drive 40" combined with the choose signal would force the train to only drive 40kmh into the station. This is a security precausion (I guess) and sets a natural limit on the number of trains the signal and stations can handle. This would also make the advantages for cab signaling even bigger than it is.
If you wonder how I would specify it in the dat, I would go for something like:
Aspect1=
Aspect2=40
Aspect3=
where nothing specified would mean no speed restriction at all. The speed restriction would only work until next signal or stop at a platform.
What I was proposing is that (if) you decide to implement this at the choose signal, then the step to implement this to all signals maybe not is so huge. Then another paksetmaker maybe wants to make, say Vladkis example with the TGV trains.
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?
Quote from: jamespetts on August 27, 2015, 11:42:15 PM
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?
No.
Often when the signal is used this way it's like one of those speed protection signals on the underground, where there's a sharp curve (and I think it was installed at Moorgate after that driver commited suicide and drove the train into the wall). No point to simulate that...
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.
Thank you both: that is helpful.
Quote from: jamespetts on August 27, 2015, 11:42:15 PM
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
Quote from: jamespetts on August 26, 2015, 09:38:32 PM
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).
Flashing aspects are very difficult to accommodate in the Simutrans graphics system, alas.
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.
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.
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.
Quote from: Ves on August 27, 2015, 11:27:19 PM
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.
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.
Quote from: Octavius on September 04, 2015, 03:07:32 PM
There exist some additional signals for heavy trains that may have difficulty climbing steep inclines.
Steep inclines in Netherlands ? Hmmmm. ;)
Quote
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.
Quote
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.
Quote from: Vladki on September 04, 2015, 04:46:52 PM
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.
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.
QuoteIf 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?
Quote from: Ves on September 04, 2015, 10:55:17 PM
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.
Quote from: jamespetts on September 04, 2015, 11:27:05 PM
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?
Quote
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? :o Sighting speed of the next signal = max speed train is allowed to travel until that signal?
QuoteHaving 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.
Quote from: Ves on September 04, 2015, 11:55:52 PM
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.
QuoteAha! That I didnt understand from your earlier post. So in practice, you already implemented a kind of route speed signaling? :o 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.
QuoteThe 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.
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).
Quote from: Vladki on September 05, 2015, 10:39:02 AM
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 (https://en.wikipedia.org/wiki/Transmission_Voie-Machine)? 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.
QuoteThere 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.
QuoteI 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.
QuoteThis 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.
QuoteThe 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.
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 (https://github.com/jamespetts/simutrans-experimental/commit/a9e50d38a110d039a98640e453a0b0063fab878a) 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.
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.
Or perhaps someone can volunteer to update it. People work on things as they have time and the desire. Nobody gets paid.
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.
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.
Quote from: zook2 on September 08, 2015, 12:04:55 PM
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.
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.
My brain have been thinking alot about signal issues lately and I must get the questions out of my head, if you dont mind! :P
QuoteThe 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! :thumbsup:
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.
Quote from: jamespetts on September 11, 2015, 09:45:16 AM
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?
Quote
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)?
Quote
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?
Quote
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?
Quote from: Ves on September 11, 2015, 01:23:38 PM
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.
Quote from: Ves on September 11, 2015, 01:23:38 PMOk, so I could specify that a signal works under this, this and this box?
Yes.
Quote from: Ves on September 11, 2015, 01:23:38 PM
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.
QuoteI 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.
QuoteOk, 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.
QuoteGreat 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.
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!
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".
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.
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.)
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.
In the process of fixing another bug, I have found what was causing choosing up to end of choose signals not to work, and I have managed to get this feature to work now. The train will try to find an alternative route to the nearest of its next stop or the next end of choose sign on its route whenever it encounters a choose signal and the route to whichever is the nearest of those points is not free.
Edit: I have just implemented a change whereby cab signals are treated in exactly the same way as track circuit block multiple aspect signals, save that there is an unlimited sighting distance. For ETRMS style signals with no visible aspects, it is recommended to leave the number of aspects at 2 to prevent reserving further ahead than necessary.