Priority through signals

Topic: Priority through signals (Read 24987 times) previous topic - next topic

Re: Priority through signals

Reply #35 – November 06, 2009, 10:58:03 am

It needs programming. No other solution is possible, since the train has to try at each steps to reserve the next block.

Re: Priority through signals

Reply #36 – November 06, 2009, 11:25:16 am

Would it be easier to keep the block reservation check like it is now, i.e. only a few tiles before a signal, but expand the check to the 2nd and 3rd block, and places a reservation if possible, but does not stop a train if the reservation on the 2nd and 3rd block fails? I'm willing to learn some programming. Basically, it would be a pre-signal but with an optional reservation rather than stopping a train until a whole 2 block reservation is made... By the way, I can't find a pre-signal in Pak96.comic, is that my bad?

Re: Priority through signals

Reply #37 – November 08, 2009, 08:38:35 am

Since this topic has been silent, another related question. Can someone provide me with a dat file for a random rail signal? I really want to put effort in achieving what I want, but I sense some unwillingness since my question about signals and how to code a signal by myself. At least, if it's really not possible, let it be a waste of my own time. But I need to know where to start, and a good start would be a dat file of a random rail signal or a push in the right direction... Anyone?

Re: Priority through signals

Reply #38 – November 08, 2009, 10:35:11 am

Quote

dat file of a random rail signal

Code: [Select]

# images S, N, E, W red, then green, then yellow (for presignal)
# repeat (if you like) for electrification
#
# normal signal
obj=roadsign
copyright=prissi
name=Signals
waytype=track
cost=750
is_signal=1
intro_year = 1810
intro_month = 9
Image[0]=rail-signals.0.0
Image[1]=rail-signals.0.1
Image[2]=rail-signals.0.2
Image[3]=rail-signals.0.3
Image[4]=rail-signals.0.4
Image[5]=rail-signals.0.5
Image[6]=rail-signals.0.6
Image[7]=rail-signals.0.7
Image[8]=rail-signals.1.0
Image[9]=rail-signals.1.1
Image[10]=rail-signals.1.2
Image[11]=rail-signals.1.3
Image[12]=rail-signals.1.4
Image[13]=rail-signals.1.5
Image[14]=rail-signals.1.6
Image[15]=rail-signals.1.7
Icon=> rail-signals.0.12
Cursor=rail-signals.0.13

Quote

a push in the right direction

This is from the open source pak64 which has all kind of signals in it.

If you are ok with german (and as you speak Dutch that language should not be too difficult to understand) you will find all available information in the wiki at http://simutrans-germany.com/wiki/wiki/tiki-index.php?page=en_SignalsDef

Re: Priority through signals

Reply #39 – November 08, 2009, 11:32:52 am

Thanks a lot Combuijs! Now I can spend my Sunday afternoon wisely!

Re: Priority through signals

Reply #40 – November 29, 2009, 11:49:39 pm

For the record, as a humble player-without-coding-knowledge but a frequent user of rail, I would really like this kind of signal. It would go half-way to the creation of fast and slow loop lines, allowing mixed speed trains to use the same track and holding slow trains on such a loop whilst the fast trains p**** - a feature I've been trying unsuccessfully to work out a way to create with current signalling for some time!

Re: Priority through signals

Reply #41 – November 30, 2009, 11:41:22 am

I've still been studying on some programming languages, I am not done yet, so if it solely depends on me, it might take a while, but I really want to make it happen. The dat file is useful, until a certain extent, as it only points to basic information like introduction date, which rotation to use when, and that it is in fact a signal. In the source files, there are more settings like what kind of signal it is. That's I guess where to work needs to be done. Any help, would still be very useful.

Re: Priority through signals

Reply #42 – November 30, 2009, 12:36:52 pm

For new functionality, it's likely that not only the signal must be modified, but also the vehicle code, in order to give them the desired behavior for this kind of signal.

Re: Priority through signals

Reply #43 – November 30, 2009, 04:11:36 pm

The other alternative would be something similar to the functionality in Railroad Tycoon, where trains are ****igned priorities high/medium/low. In Simutrans, with block reservation, both high and medium trains could reserve two blocks in advance, with low reserving one block in advance, as is the present behaviour. The far block reserved by a "medium" could then be over-ridden by a "high". This might be simpler for players to understand and implement, and more effective, than having priority signals.

Re: Priority through signals

Reply #44 – November 30, 2009, 09:15:57 pm

Hmm... I like the sound of that idea, but I'm trying to think how it wouldn't end up making deadlocks, as the slower train might well be in the way of the faster train, and any solution I can think of (make it stop; force it to re-route) makes it likely in my mind that it would cause stuck trains.

Unless, perhaps, there's a way to code it like p****ing cars - where it won't actually reroute until:
1. Faster train checks for all routes. If it wants to "take over" a slower train's route, the slower trains must attempt to reroute themselves, taking into account the faster train's desired route.

2. If [all of] the slower train(s) can reroute out of the way in X number of tiles, it does so, and the rerouting of all the trains succeeds.

Re: Priority through signals

Reply #45 – November 30, 2009, 10:31:08 pm

Quote from: Isaac.Eiland-Hall – on November 30, 2009, 09:15:57 pm

Hmm... I like the sound of that idea, but I'm trying to think how it wouldn't end up making deadlocks, as the slower train might well be in the way of the faster train, and any solution I can think of (make it stop; force it to re-route) makes it likely in my mind that it would cause stuck trains.

My idea is simpler than that: it would just require faster trains to reserve two blocks ahead instead of one. If this is done, then slower trains may indeed sometimes block faster trains, but they would be less likely to do so.

Re: Priority through signals

Reply #46 – December 02, 2009, 03:23:13 pm

Sounds like three-aspect absolute block signals. Red means the next block is occupied; Yellow means the block-after-the-next-block is occupied (trains proceed at reduced speed); Green means both following blocks are free.

Re: Priority through signals

Reply #47 – January 25, 2010, 05:55:13 pm

I would personally like to see the reduced speed ability implemented. Quite often I find a heavy train finally gets to speed only to slam on the brakes for the second or two that the preceding train takes to clear the block.