News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

Discussion of new signalling system

Started by Octavius, October 26, 2015, 09:37:24 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ves

Ok, would this work?

Pre signal:
CLEAR0, CAUTION0

Normal stop signal:
CLEAR1, DANGER1

Three aspect signal would be:
CLEAR2, CAUTION2, DANGER2

Four aspect signal would be:
CLEAR3, CAUTION3, DANGER3

  ....

With all variations as to "no_choose" etc.
Think the number as the number of blocks the signal can represent.

Vladki

Better would be:
clear2, danger2 on 2-aspect,
clear3, caution3-1, danger3 on 3-aspect
clear4, caution4-2, caution4-1, danger4 on 4-aspect
clear5, caution5-3, caution5-2, caution5-1, danger5 on 5-aspect

cautionX-Y ... X = how many aspects on the signal, Y = how many blocks ahead of danger signal

distant signal could be X=1 or 0
for time interval - "caution" could be replaced with "slow" or something like that. Although it fits the 3-aspect signalling, the meaning - and thus translation is different.
Choose signals: branch/straight
call_on - another translatable string

Ves

Ok, however, is the "Y" parameter in your naming convention not already covered by the existing names (caution, preliminary caution, auxilary caution)?

The names of the 5 aspects would be with my version:

clear5, auxilary caution5, preliminary caution5, caution5, danger5

Is that not what you meant?

I have already thought that time interval needs another translation. The ingame name will be something recognizable, and you will have to translate it into something usefull on your end.
The choose signals already show main route or alternate route, however I will implement the X parameter from the above equation to them as well.
Call_on will also have the X parameter

Vladki

Quote from: Ves on November 08, 2016, 08:59:22 PM
Ok, however, is the "Y" parameter in your naming convention not already covered by the existing names (caution, preliminary caution, auxilary caution)?
oh yes, whatever can be used to distinguish them. In your previous post there was only caution 3, caution4, but no preliminary caution... I thought the number would be more "neutral".

Quote
clear5, auxilary caution5, preliminary caution5, caution5, danger5
OK

Quote
The choose signals already show main route or alternate route, however I will implement the X parameter from the above equation to them as well.
Call_on will also have the X parameter

I think the number of aspects is not necessary in choose and callon aspects, but it should not be a problem (only more texts that will have the same translation). Probably danger may be also without X

Ves

#144
Yeah, was a bit unclear there, sorry!

You are right, maybe danger5 is overkill. That will just be known as "danger" if no one else complains. I dont think there are any in game mechanisms that allows a train to pass a signal at danger (except call_on, and some of the current bugs..)?

Call_on, I can only think of the difference of shunting and following behind another train on the track. I think I will keep it, you never know what ideas might arrise :)

edit Vladki, Try have a look at my newest version on github: https://github.com/VictorErik/Simutrans-Experimental-Ves/commit/28cd6334df5aef21cff44163f776d02118e0c7ea.
It is currently not translated, so the internal names are visible. However, that makes it easier to check it out!

edit2: Now the translation files should also be correct to be included in devel-new-2: https://github.com/VictorErik/Simutrans-Experimental-Ves/commits/signal-in-infowindow-2

jamespetts

Thank you for this work, and apologies for not having had a chance to look into this yet: I am currently busy at work and spending all of my Simutrans time working on multi-threading (which early testing shows greatly improves performance on larger maps, but is hard to get right).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Quote from: Vladki on February 07, 2016, 12:31:04 PM
With the help of Leartin, I got some nice source of information: https://archive.org/stream/geschichtedereis03aust#page/56/mode/2up
Now I have to refresh my knowledge of German and pick up the relevant info from there. However at quick blick, it seems that many of the incomplete sources I came upon earlier were referring to this book.

Hi I went back to this book, and refreshed my knowledge of german. Just a few interesting picks:
- absolute block was introduced in austria-hungary in 1877 (line Wien - Stadlau)
- time interval began with interval of 30 minutes. It was later reduced, with different intervals for summer/winter and day/night. Further reductions were done with final interval of 10 minutes in 1877.  Not too many details. (page 50-51) I could not find any info about letting the train earlier, though at reduced speed, neither if the interval was enforced along the whole line (at each waechterhaus) or only at stations.
- double tracked lines were really an exception. Traffic on single tracked lines (in absence of telegraph) was organised by strict adherence to timetable. If an expected train was delayed by more than 1 hour (or half hour in later years), a rescue engine was to be send to help (driving carefully - i.e. by sight). Also the train drivers had to run carefully, when they were too late, as they could expect a rescue train in the opposite direction. (page 50)
- there were no platforms in the beginning. Portable steps were brought by station staff if necessary. (nice picture on page 17).
- early flag signals were - black = danger, red = caution.
- maximum allowed speeds described at page 46-47.

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

reading further i found info about "quittirungssignale" from 1872, which fit as time interval singals on the line (beween stations). page 68-69.
They were a sort of T-signal, perhaps modification of those on page 61. With following aspects: both arms down - nothing (no train announced)
Trains were announced by bell signal (telling the direction). If track was in good condifion, road crossing closed, one arm (according to expected direction) was raised to upper quadrant "clear". After passing the train the arm was put horizontal "danger", after 5 minutes to lower quadrant "caution=slowly". However, i found no info if after further 5 (or more) minutes the arm could be raised to clear, or went down and next train had to be announced by bell signal.
However, it seems that many railway companies were reluctant to build these signals and wanted to stay at hand flag/lamp signals.

For single track lines, there was a departure signal (wendescheibe, page 69), that was interlocked with bell signalling, and turned to danger upon train announcement from neighbouring station. This signal was only one for each direction (not for each station track).

Entry to station was protected (since 1863, page 71-77) by "distanzsignal" - inspired in France. This had two aspects: danger/clear, but orginally was not absolute. If a train arrived and stopped at danger, it was allowed to move forward, so that the whole train was ahead of the signal, but it did not enter the station yet. My speculation is that it was to protect the train from the possible following train (in time interval). As these were quite far (a few hunderd meters) from the station (therefore the name distant signal), they were operated electrically. Later (with introduction of absolute block), they were converted (repainted) to vorsignals (equivalent to UK's distant/advance signals), and new entry/home signals were built much closer to the outermost switch. Interesting is also that they were converted from electric operation to mechanic (wire) operation. Distant signals did not have any advance counterpart, but they wer equipped with electric bell that was constantly ringing if danger was shown. The wires continued to the next waechterhaus and another bell was installed there, so the watchman could signal "caution" by hand (flag/lamp).



jamespetts

Quote from: Ves on November 08, 2016, 10:18:36 PM
Yeah, was a bit unclear there, sorry!

You are right, maybe danger5 is overkill. That will just be known as "danger" if no one else complains. I dont think there are any in game mechanisms that allows a train to pass a signal at danger (except call_on, and some of the current bugs..)?

Call_on, I can only think of the difference of shunting and following behind another train on the track. I think I will keep it, you never know what ideas might arrise :)

edit Vladki, Try have a look at my newest version on github: https://github.com/VictorErik/Simutrans-Experimental-Ves/commit/28cd6334df5aef21cff44163f776d02118e0c7ea.
It is currently not translated, so the internal names are visible. However, that makes it easier to check it out!

edit2: Now the translation files should also be correct to be included in devel-new-2: https://github.com/VictorErik/Simutrans-Experimental-Ves/commits/signal-in-infowindow-2

My apologies for not having got to this until now: having spent some time with other matters, this had slipped my mind. I have now incorporated it - this is most helpful: thank you.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

When I was reading about https://en.wikipedia.org/wiki/Abbots_Ripton_rail_accident I noticed that at that time there was an early block system (although simpler than THE absolute block system), which could be implemented with normal_danger=0. Semaphores were lower quadrant, with arm vertically down for clear - and that was the cause of accident, it was frozen and stuck at clear.

Vladki

Further reading discovered one very interesting piece of signalling. The picture #50 on page https://archive.org/stream/geschichtedereis03aust#page/86/mode/2up and text on page 85 describes and early absolute block system (1864) used on double track line (Přerov - Ostrava / Prerau - Ostrau)

It used optical telegraph with balloons. They had to be close enough that the signalman clould see the next signal in both directions. When the train has passed the signal, signal man put it to danger (balloon half-way down). When the previous signalman saw that the next signal is at danger, he could put his own signal to caution (balloon down), and when the next signal was at caution, he could rise the ballon up again to signal clear line.

Unfortunately I did not find if and how was this optical telegraph used on single tracked lines. There is a mention of "signal-less" absolute block, where blocks were delimited by stations (passing loops), and arrival / departure of trains was acknowldged by telegraph.

jamespetts

Balloons - intriguing! One wondered how this system worked in high winds.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

Quote from: fam621 on December 26, 2016, 05:53:25 PM
Is this forum good for future signals that could be added in the future for example LU signals?

I am afraid that I do not follow - what do you mean "is this forum good for" in this context? Also, as I have already stated, we already have London Underground signals.

Incidentally, please do not reply to this post by private message.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Balloons: Have a look at the linked picture. They were not hot-air balloons, but rather a sort of balls puled up on a mast in similar way to flags. I think that on some of my previous post a better picture was linked. Now I'm writing from my phone so I can't find the link easily.

jamespetts

Ahh - perhaps "balloon" was not quite the right word. This makes more sense. Interesting!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

laos

regarding the new signaling system. I noticed the video series is not yet near electronic signaling, and I was wondering if someone can suggest a good place to read or view a diagram of proper signal placement. I'm having an especially hard time with getting absolute choose signals to say anything other than danger. I did read the instructions in the help section of the simturans experimental, but it doesn't seem to be helping me.

Here's a quick screenshot for reference as to what i'm screwing up: http://i.imgur.com/44WZIgD.png. I've got nothing at the end of the station platform, but earlier tried end of choose signals, stop signals, and combined signals to no avail. The choose signal remains in danger and the entire station is being considered as one giant block that the train doesn't want to move in.

jamespetts

Hello - sorry that you are having problems. I am afraid that, for some reason, I can never see images posted to Imagur. Are you able to upload your screenshot elsewhere?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

It looks weird that it says "No route". Are you sure it can reach its next destination (all tracks connected, no oneway signs at the wrong places)?
Asuming the locomotive should reverse (and not continue to the right out from the picture) I think this is a more correct positioning of signals:

You need normal stop signals at the platform ends facing the trains leaving the station.
You need to place "one way" signs at the passing loops, facing the directions the train is NOT allowed to take. The line connecting to one of the passing loops, you could consider connecting it at the junction right before the station for more efficiency, however if you prefer not, take care that you put the "one way" sign between the line branch and the station to avoid strange behavior.

Hope this is of help! :)

laos

Very strange! I must have done something wrong, as I started over, added the stop signals and one-way signs, and everything is peachy now :) - I thought I had (mostly) the right idea, but looks like it might have been the one way signs causing routing issues, as I might have at some point put them backwards and a stubborn one was still screwing with things.

Thank you both!

Ves that info is very helpful. For anyone else who ends up building a similar design, make sure one-way signs are also placed in the station to encourage trains to route through to the exit route and keep things flowing smoothly.

Ves

I had been thinking of a principle thing about the speed restrictions of the signals for a while, not being able to wrap my head properly around my thoughts. However, I try to have a go at explaining:

The current speed-limit of a signal determines what speed the signal may be passed at. When a train approach the signal it will adjust the speed accordingly. That is everything as you would expect it to be.
When the train has passed the signal, the speed limit of the signal is also enforced to the entire route behind the signal up to another signal with a higher speed limit. This is where my head starts to warp:
Is the most logical thing that the route between the two signals are speed limited by the departed signal, the arriving signal, or whichever has the highest speed limit?

Rephrased: The speed limit is ultimately existing to simulate the safe speed that a signal might be passed at. But we assume that the traindriver has route knowledge, therefore knowing that the upcoming signal in our case has a much higher speed restriction. Therefore, he could drive faster immediately.

In the other direction (when upcomming signal has a lower speed restriction), I think the driver does the sensible thing and drive fast only to brake upon the arrival of the following (slower) signal.

jamespetts

The purpose of this was to simulate the fact that trains are not permitted to travel over 125mph (200km/h) without cab signalling because, at higher speeds, the drivers simply cannot see the signals. One might extrapolate from that that drivers cannot see older types of signals (i.e. those without modern very bright lamps) at faster than around 100mph (160km/h), and so forth. This restriction has had a substantial effect on the development of high speed rail in the UK, so it is worth simulating, I think.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

I'm sorry I didn't understand which you found worth simulating, the current behavior or my proposal?

I see the point with the cab signals though. However, we only see and place the signals, not all other equipment along the track. One could assume that there is equipment already behind the previous signal, preparing the vehicle? Only that the vehicle working method would not show "cab signal".

A bit more work could be to hardcode the cab signal and moving block working method to behave as they do currently.

A more flexible way could be to introduce a new variable in the dat file, "departure speed", which, if specified, would be a speed restriction behind the signal until the next (like the current behavior).

jamespetts

I was referring to the current system: the idea that the overall maximum speed is determined by the type of signalling is something that needs to be simulated. Are you aware of any real life examples in which the speed of passing the signal specifically (but not the speed of actually travelling along the line thereafter) is limited by something specific to the signal?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

I'd like to add my few cents. A short excerpt from Czech rules:

Signal must be visible from distance of 100m (from standing train), or at least for 12 seconds from a train at full speed. It can be reduced to 7 seconds if there was a repeater signal before, special signs telling that the train is approaching a signal, or if cab signaling is used.

If cab signaling is NOT available (either permanently or temporarily), speed is limited to 120 km/h. The reason is not only the visibility, but also the distance between distant and main signal (or between signals in 3-aspect automatic track-circuit block). If signal at caution would be passed at higher speed, the train might not brake before the next signal. Therefore trains running faster, need cab-signaling and start braking as soon as caution is signaled on board.

The availability of cab signaling for next signal is obvious to the driver immediately (or very soon) after passing a signal. So I think in simutrans, train should adjust its speed according to the max_speed defined for the signal ahead. Not by the signal just passed as it is now.

There is also the case of dwarf signals, which also have somewhat worse visibility than normal signals on mast. These are forbidden to be built on the main track (straight through the station), which can be passed at full speed. Dwarf signals are allowed only in sidings where speed is reduced due to the speed limits of switches being passed in non-straight way - usually 40 or 50 km/h. Also the train can accelerate to full speed once it is out of the station (switches). So for these it would also be more reasonable to limit the speed of the train as it approaches and passes the signal, but no more when the train has passed the signal.

Octavius

Quote from: jamespetts on January 07, 2017, 11:30:28 PM
Are you aware of any real life examples in which the speed of passing the signal specifically (but not the speed of actually travelling along the line thereafter) is limited by something specific to the signal?
Yes, in the Netherlands a green blinking signal (sometimes with a number) indicates a speed limit for passing that signal. After the train has passed the points directly behind the signal, it's allowed to accelerate to line speed. It's mostly used for diverging points.

In fact, along with yellow blinking (drive-by-sight/call-on) and red (don't drive at all), this is the only aspect that tells how fast you can pass the signal. All other signals can be passed at any speed and only tell the speed at which the next signal can be approached.

The question is to what extend this is relevant to simutrans.

Quote from: Vladki on January 08, 2017, 04:40:06 PM
The availability of cab signaling for next signal is obvious to the driver immediately (or very soon) after passing a signal. So I think in simutrans, train should adjust its speed according to the max_speed defined for the signal ahead. Not by the signal just passed as it is now.

The standard safety system here includes a crude form of cab signalling, without which trains aren't allowed to go faster than 40km/h. If a train has passed a signal at caution (yellow), this safety system can tell the driver when the next signal is no longer at danger (red). But even when that happens, he has to act as if he's still expecting a signal at danger until he can actually see the signal. It has something to do with not relying on a single system for changes that allow an increase in speed. The safety system may allow an increase in speed after passing a signal at danger, as it may then receive information meant for another train.

Vladki

Quote from: Octavius on January 08, 2017, 07:42:47 PM
Yes, in the Netherlands a green blinking signal (sometimes with a number) indicates a speed limit for passing that signal. After the train has passed the points directly behind the signal, it's allowed to accelerate to line speed. It's mostly used for diverging points.
Yup, that is similar to Czech signaling. Just the color/blinking combinations are different, than in Netherlands. But the principle is the same.

Ves

QuoteAre you aware of any real life examples in which the speed of passing the signal specifically (but not the speed of actually travelling along the line thereafter) is limited by something specific to the signal?
Not really. The speeds are mostly shown on signs along the route, with the exception of speed signalling (which we discussed in length earlier, but I would still find it interesting to implement ;) ) Octavius and Vladki says there are some real life examples in their countries though.

However, there is one aspect of that suggestion that would need resolvement: the time interval signal. Its potential speed restriction, I think should always be in effect and override any upcomming speed restrictions.

jamespetts

Octavius' example from the Netherlands refers, in effect, to junction signals. This is a system for communicating to the driver the speed at which the train may pass over a diverging junction involving a potentially sharp corner for the train. This is already simulated to an extent by the feature requiring trains to slow for corners. How the upcoming corner is communicated to the driver I do not think that we need to simulate.

One difficulty with defining the signal's speed by the type of the signal ahead is that there may not be a signal ahead (e.g. at a station, as the train does not check the line beyond the station). I should note, however, that, once a train comes within the sighting distance of the next signal, that signal's speed limit will apply from that point onwards (in the existing code), rather than the train having to wait until the signal has been passed.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

QuoteOne difficulty with defining the signal's speed by the type of the signal ahead is that there may not be a signal ahead (e.g. at a station, as the train does not check the line beyond the station). I should note, however, that, once a train comes within the sighting distance of the next signal, that signal's speed limit will apply from that point onwards (in the existing code), rather than the train having to wait until the signal has been passed.
If there is no signal in front of a station (ie, no choose signal) the max speed of the departed signal would be the most sensible thing I think. Likewise, also in those working methods that the train has to stop (token block, one train staff), whose max speed practically would be zero due to the train anyway needs to stop at the signal/post.

Vladki

Quote from: jamespetts on January 08, 2017, 10:28:22 PM
Octavius' example from the Netherlands refers, in effect, to junction signals. This is a system for communicating to the driver the speed at which the train may pass over a diverging junction involving a potentially sharp corner for the train. This is already simulated to an extent by the feature requiring trains to slow for corners. How the upcoming corner is communicated to the driver I do not think that we need to simulate.
I agree with that. Trains slow down for sharp corners by themselves, and the "slow speed" aspects can be (and are) used on chose signals to show that alternate route is chosen.

Quote
One difficulty with defining the signal's speed by the type of the signal ahead is that there may not be a signal ahead (e.g. at a station, as the train does not check the line beyond the station). I should note, however, that, once a train comes within the sighting distance of the next signal, that signal's speed limit will apply from that point onwards (in the existing code), rather than the train having to wait until the signal has been passed.
In case there is no signal ahead, then the limit of last signal could apply. Anyway, the train will probably slow down soon to stop in the station. Applying the speed limit in sighting distance may be too late if the speed is to be reduced significantly.

jamespetts

I should note that it would take a significant amount of work to change the behaviour to use the speed of the next signal ahead unless there is no signal ahead or unless the current signalling method is time interval. I must say that I am doubtful that it is likely to be worthwhile to do that in the short term at least given the other things competing for my time.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

I know I might be buggying with this question which has been discussed before so please forgive me!
I can not help as I can see many possibilities with this feature, and I never felt that the previous discussion where absolute conclusive.

Is there, in any way, a possibility that you would consider adding a two block signal?

Let me back up my question with why I think it is an important feature of signalling. I wrote the long post a page or two ago, which held some arguments, but this should outcome shorter!
The two block signal would be redundant on simple signal layouts, as the existing signals would cover that perfectly fine. It is in more complex layouts and where you start to mix different working methods when directional reservations would not suffice, and the two block signal would come in really handy.
As an answer to the fact that you can build your way around it, I admit that nothing, including the scenarios below, is impossible in the existing state of signalling. It just demands more trackwork, which in turn means that more land is occupied, more track is bought and potentially more signals are used, ie more 'clumpsy' and it takes more time to build (adding second track lead, setting up one way signs etc).
Regarding how a player intuitively would build a signal layout, I think that higly depends on what tools the player is offered. If there is no such signal, the player would probably just build as you suggest (every token block stretch has a doubble tracked lead), but if the player is presented a way to avoid doing that, I think the feature would be used.

Uses of a two block signal:
* If a station serves different lines with different working methods, or even two or more token block lines.
Imagine a big goods hub with lots of industries around. Only one single track is needed to each industry, but each one would require the doubble track lead the length of a train out from the hub which might doubble the size of the station. With some smart track work you could combine some of the returning leads or make some platforms specific to certain lines, but it might easily become messy. Alternatively, you could just use absolute block directly from the station (asuming there are no intermediate stations on the single tracked lines), but that would require another signal in the other end, potentially including a signalbox. If you just put one train staffs directly on the platform ends, you might be blocking tracks for other trains and if you put it on the single track line with no doubble track leads, the track is not secured properly and deadlocks may occur if you operate more than one engine.
Also, one train staff is in fact the most intuitive to use in this situation, since this is exactly what one train staffs exists for: Signalling dead ends.

* When creating signal gates with multiple branches and line crossings, you sometimes dont want trains from a certain direction to hold at a specific stop signal, blocking other traffic either because it is lesser important or it creates hinder for other trains. This one is difficult to explain, as the need would be very subjective to the actual situation. There might be a number of reasons for such a situation to arize, be it many entrances close to a station, or signals in general in tight space.

* If station signal is "two block signal", pakset author can balance in signal speed. The station signal only allowing slow speed for safety reasons and the (expensive) exit signal allows for higher speed. This is a pakset decission, I admit, and could be completely omitted with no other impact than it being less realistic for swedish purposes. But if two block signals become a reality, I will do this with them.

* When going single track to a termini (with token block and no doubble track leads) you dont want more trains than there are tracks available at the termini to be sent. Therefore, a two block station signal and a two block exit signal (token block) from the previous station and then the choose signal in front of the termini would create the desired effect (this example would require that two block signals are 'stackable', ie two "two block signals" in a row would effectively make the first one a "three block signal"). Admitted, if you make the doubble track lead at the termini it would at least add a buffer (but not fail proof, since the train waiting at the lead would have to pass a signal in order to resolve the reservation behind it, allowing a train onto the line, even so if it is in the wrong direction). If the line has no intermediate stations, you can use choose signals directly on the previous station, thus completely eliminate the problem, but in this case, token block is needed.
Again, forcing the player to make the doubble track lead (in the token block case), creates some less slim designs.
Also, this could be resolved by the player creating proper schedules, however misstakes and misshaps happen and it is easy that something goes wrong. Even with this possibility, player would have to administrate proper schedules!

* Some bonus side effect would be that instead of waiting at the token block signal on the double track lead, the train can be held at the station platform for a longer period of time, allowing for longer boarding. That might even be more time efficient since the train dont have to stop twice (one time at the station, one time at the token block signal).


I think I already described it, but I imagine a setting in the dat file is_two_block_signal=1 or something similar, which would allow the paksetauthor to use it on any type of signal.
The two block "search" for next signal would stop at next signal or end of choose sign, alternatively another special sign.

What do you think?

jamespetts

One thing that I was thinking of doing at some point was adding, not a double blocking signal, but to have double blocking as an option in trains' schedules (which would suit faster trains travelling on lines with closely spaced signals, for example; this was actually done for the Blue Pullman to allow it to travel at its maximum speed on the Midland Region in the 1960s). This would potentially give more flexibility.

The difficulty with this and various other ideas is that they are all competing with a very large list of very high priority things for my time. I am increasingly of the view that one of the highest priorities at present, beyond fixing critical bugs, is completing the translation of the code from German to English (by incorporating patches from Standard which do this), as there has been enormous number of people who express an interest in working on the code but never actually do any work on the code in the last year or so, at least two of whom have expressly cited the German in the code as a problem (and others have simply become silent and do not respond to requests).

Even one or two people semi-regularly contributing to the code would make an enormous difference in how much can be achieved in any given time.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Interesting with the Pullman that always reserved two blocks ahead! How did the signalmen actually know that two blocks where free?
And how would you incorporate it in the game, because I could see it being quite problematic if the train always reserve two blocks ahead around stations for instance.

I would love contributing code to the game, my only limitation is my programming skill (and time, abviously, but mostly the skills!). I tried for fun to start on a patch to create two block signals this morning, and looked in roadsign_besch.h to see if I could create something there. Where do you specify the signaling logic?