[patch] Choose signal

[gerw]

I've tested my suggestions from http://forum.simutrans.com/index.php?topic=2973.msg29354#msg29354 and it works fine.

If you place an end-of-choose, the convois will also drive through stations (with choose-signal), where they shouldn't halt. Since an end-of-choose signal is a roadsign and not a signal, they will reserve the rails until the next signal after the end-of-choose. If there isn't an end-of-choose after a station with a choose signal, through-trains will stop at the choose signal (as usual).

You can also place choose and end-of-choose signs outside of stations. Trains will look for a free way to the end-of-choose sign on their way. But I think, there isn't any benefit from this (yet?).

tu-chemnitz.de/~gerw/patches/choose_signal_2611.patch

[whoami]

This sounds very interesting.

However, I can't get patch to integrate any of your changes to a copy of r2611 (e.g. by "patch -p0 <file") - which command do I need?

[gerw]

For me, it applies fine with "patch -p0 < ../choose_signal_2611.patch" (to r2611 and r2614). Which error messages does occur?

[whoami]

This is on Windows, using Mingw dev tools. I hadn't used patch before in this setup.
This problem happens with all tested patches from other people here, so it must be caused by the environment (any of: problem with linefeeds, character encoding, filenames, directory seperators, or messed-up repository copy).

Anyway, I downloaded your patch again, and used a fresh copy of the trunk:

C:\local\games\ST\dvlp\compile\patch-test\choose-signal_trunk-directcopy>patch --dry-run -p0 <..\STIF3001_gerw_DL2_choose_signal_2611.patch
patching file besch/roadsign_besch.h
Hunk #1 FAILED at 56.
Hunk #2 FAILED at 86.
Hunk #3 FAILED at 97.
3 out of 3 hunks FAILED -- saving rejects to file besch/roadsign_besch.h.rej
patching file dataobj/route.cc
Hunk #1 FAILED at 55.
Hunk #2 FAILED at 283.
2 out of 2 hunks FAILED -- saving rejects to file dataobj/route.cc.rej
etc.

[gerw]

That's odd.

Here comes a new feature - only for you: Zip file with all changed files
tu-chemnitz.de/~gerw/patches/choose_signal_2614_full.zip

Happy testing!

[whoami]

Thank you for the premium service. I have been able to compile this.
As Change request: Limiting the effect of choose signals shows, I am quite interested in optimization of the choose signal and of the end_of_choose sign (EOC). 

Since an end-of-choose signal is a roadsign and not a signal, they will reserve the rails until the next signal after the end-of-choose.

This has been my main wish, and it works in my test situation. The player just has to be a little more careful when setting the signals. The deadlocks that Prissi predicted can be avoided with the correct setup, I think. There is still no actual documentation on "best practices for track layout, signalling and train schedules in ST".

According to my tests with Pak128 and Pak64, there is one major problem: the EOC does not (completely) serve its original purpose any more: to exclude station tracks for the choose signal. This is used to avoid that trains take dead-end tracks that should be roll-on roll-off, or tracks that lead to the wrong destination after the stop at the station. The EOC can also be used to avoid deadlocks on station tracks with signals, but these can be excluded by different track+signal layout.

Furthermore, it seems that trains at choose signals disregard platforms that are too short, unless it's the one in the schedule, no matter if an EOC is placed in front. Therefore, another purpose of the EOC appears to be fulfilled automatically. Is this a new feature?

[gerw]

Furthermore, it seems that trains at choose signals disregard platforms that are too short, unless it's the one in the schedule, no matter if an EOC is placed in front. Therefore, another purpose of the EOC appears to be fulfilled automatically. Is this a new feature?

I didn't understood your whole post, since I've got not much time now. But the new behaviour of the CS - choose signal  - is the following:
If a train arrives at a CS, he does the following:
- if the current route (to the next schedule entry) contains an EOC, he drives to it (on any free route) and reserve the rails until the next signal after the EOC.
- otherwise: he will go to the next entry in the schedule on any free route (which doesn't contain an EOC). If the next entry is a stop, he will search for a platform which is long enough. If the next entry is a waypoint, he will drive to the waypoint. In both cases he will reserve the whole route.

[whoami]

After testing again: I figure that you implemented something similar to my original extension request, replacing the EOC as we know it. I assume that it's possible to get both in one, but understanding either function is already complicated in itself, the combination would be a problem for newbies.

See line 1 in the attached savegame: in the original behaviour, the trains never take one of the platforms with an EOC in front of them. Trap a train in "Hillock West Station" with either executable, and the difference should show up.

If a train arrives at a CS, he does the following:
- if the current route (to the next schedule entry) contains an EOC, he drives to it (on any free route) and reserve the rails until the next signal after the EOC.

"Current route" means "as given by the schedule"? But both cases that you mention don't explain the changed behaviour, unless I misunderstood.

(BTW: trains and ships are an "it". Traditionally, they can also be a "she", but that's only old-fashioned English, I guess.)

[jamespetts]

I think that trains have always been "it". Only ships are "she".

[mjhn]

I seem to remember early references to trains as 'she', but all of these referred to unique locomotives (in other words, before there was such a thing as a class of locomotives). There were definitely comments about the fact that 'iron horses' were all mares.

[gerw]

After testing again: I figure that you implemented something similar to my original extension request, replacing the EOC as we know it. I assume that it's possible to get both in one, but understanding either function is already complicated in itself, the combination would be a problem for newbies.

What do you mean with 'both functions'?

See line 1 in the attached savegame: in the original behaviour, the trains never take one of the platforms with an EOC in front of them. Trap a train in "Hillock West Station" with either executable, and the difference should show up.

This was a bug. It was caused by the fact, that an EOC isn't a signal, but a roadsign. (I think, a wrong defined pak will mess up the system anyway...). Please update in vehicle/simvehikel.cc the routine waggon_t::ist_befahrbar (I will post a new patch, when I'm at home):

Code Select Expand

bool
waggon_t::ist_befahrbar(const grund_t *bd) const
{
const schiene_t * sch = dynamic_cast<const schiene_t *> (bd->get_weg(get_waytype()));

// Hajo: diesel and steam engines can use electrifed track as well.
// also allow driving on foreign tracks ...
const bool needs_no_electric = !(cnv!=NULL ? cnv->needs_electrification() : besch->get_engine_type()==vehikel_besch_t::electric);
bool ok = (sch!=0)  &&  (needs_no_electric  ||  sch->is_electrified());

if(!ok  ||  !(target_halt.is_bound()  ||  target_koord != koord3d::invalid)  ||  !cnv->is_waiting()) {
return ok;
}
else {
if( target_koord != koord3d::invalid ) {
if( target_koord != bd->get_pos() ) {
if(sch->has_sign()) {
const roadsign_t* rs = bd->find<roadsign_t>();
if(rs->get_besch()->get_wtyp()==get_waytype()  &&  rs->get_besch()->is_end_choose_signal() ) {
return false;
}
}
}
return sch->can_reserve(cnv->self);
}
else {
// we are searching a stop here:
// ok, we can go where we already are ...
if(bd->get_pos()==get_pos()) {
return true;
}
// we cannot pass an end of choose area
if(sch->has_sign()) {
const roadsign_t* rs = bd->find<roadsign_t>();
if(rs->get_besch()->get_wtyp()==get_waytype()  &&  rs->get_besch()->is_end_choose_signal() ) {
return false;
}
}
// but we can only use empty blocks ...
// now check, if we could enter here
return sch->can_reserve(cnv->self);
}
}
}

"Current route" means "as given by the schedule"?

Each train calculates a tile-based route, i.e. a list of tiles on which it will drive to it's target.

But both cases that you mention don't explain the changed behaviour, unless I misunderstood.

In the old implementation, a train in front of a CS searched it's target (but this only worked for halts, not for waypoints) within the next EOC-block. Therefore, a train wainting at a 'wrong' station, couldn't continue and you couldn't build a drive-through-station (this is possible with my implementation).

(BTW: trains and ships are an "it". Traditionally, they can also be a "she", but that's only old-fashioned English, I guess.)

Thank you. I started with 'it', but it sounds very unfamiliar, since in German trains are "he".

[whoami]

What do you mean with 'both functions'?
(...)
This was a bug.

You said it yourself: the loss of the previous function of the EOC was a bug. I will have to test again with the fix.

[whoami]

After little testing (sorry, have to leave again...), I think this patch would be an improvement for ST-main, if included. Prissi will tell us what is wrong with it anyway, once he's back.

[prissi]

Generally I do not like trains getting loss. The TTD routing annoyed me to a very large degree and I added the choose stuff very reluctantly. It does not add any new game play options on properly designed networks (unlike the platform selection, which allows for smaller stations) and a waypoint after a choose signal would still allow for a through track.

Adding the code is not the only thing. Usually it results in complains that the trains are not reading once mind. It got worse and worse. The more freedom a choose signal would introduce the more difficult its management would get.

In that apect maybe choose signal should be only single way, as the double side use would be very advvanced use.

[VS]

In that apect maybe choose signal should be only single way, as the double side use would be very advvanced use.

Of course! It can be built as a both way?

[gerw]

Adding the code is not the only thing. Usually it results in complains that the trains are not reading once mind. It got worse and worse. The more freedom a choose signal would introduce the more difficult its management would get.

Actually, the patch doesn't change the behaviour of the choose sign essentially, it rather fixes some bugs:

But the new behaviour of the CS - choose signal   - is the following:
If a train arrives at a CS, it does the following:
- if the current route (to the next schedule entry) contains an EOC, it drives to it (on any free route) and reserve the rails until the next signal after the EOC.
- otherwise: it will go to the next entry in the schedule on any free route (which doesn't contain an EOC). If the next entry is a stop, it will search for a platform which is long enough. If the next entry is a waypoint, it will drive to the waypoint. In both cases it will reserve the whole route.

[wlindley]

I support the patch, as it does not reduce any previous functionality.  It DOES solve the problem where a train gets routed through a station with a Choose Signal without your having planned for that... or where you add a Choose Signal to  a through-station without having to hunt and see which trains "might" be routed through there. 

[prissi]

This patch will *NOT* solve the issue with a train waiting in front of a choose singal. It will only solve the issue, if you use end of choose signs at each station exit.

But I am only home today, so this will have to wait another 14 days for thourough testing.

[z9999]

It will only solve the issue, if you use end of choose signs at each station exit.

And also it requires one signal. So, it doesn't solve the same problem on road, because there is no signal on road.

[whoami]

It will only solve the issue, if you use end of choose signs at each station exit.

This placement of the EOC is something that I have recommended in general before, because it will prevent the trains from reserving a path through the whole network, using a different (perhaps opposite) entry point to the station. With the patch, the EOC at the same location should serve the new purpose in addition to the existing one. The introduction of a new signal, or different means of telling where the station limits are, wouldn't make it easier for the player or the implementation.

In any case, it will be useful to give the (newbie) players basic instructions ("best practices") on how to design a station with advanced signalling like this. Whoever wants to make a different design, has to understand the signal handling in detail. I recognize that the documentation is still not up to that point. (I really hope that I can get myself to help with that part...)

I'd like to remind of the idea to move the advanced signal functions into the train schedules.

Regarding EOC missing for road vehicles, perhaps airplanes: these are single-tile vehicles that don't depend on consistent way layout (as for tracks), so I assume that the issue hardly matters to them.

[prissi]

If you automatically want to route a bus around another waiting one, and this is the basic request, one would need also something like this. However, the road choose signals do not check for a free route.

[z9999]

However, the road choose signals do not check for a free route.

I don't mind.
Hopefully, end of choose signs on road negate an effect of choose signs as No.3 of attached image.

[whoami]

Hopefully, end of choose signs on road negate an effect of choose signs as No.3 of attached image.

You are right in that there are situations where additional signals for platforms are useful: I build them if short trains use a station with very long platforms, thereby increasing effective transport capacity for the station.
Your screenshot shows already how to avoid the reservation that is too short: by putting the EOC after the platform signal.

EOCs in this setup, together with this patch, can lead to a chain CS-BS-EOC-platform-EOC-BS-BS (BS=basic signal, the last one being the station exit), and the reservation would only happen up to the first BS after the station. However, this is not a problem, because the train will just wait until it can leave the station, and deadlocks still won't happen (as long as no two trains - that are both longer than the platforms that they pass - meet at the station).

I acknowledge that there are many more station setups - it will not be possible to provide optimum support for every irregular station layout, because it's not possible to read the user's mind. As written above, unexperienced users should use standard layouts (meaning the topology of signals and tracks, not the shape of the station).

EDIT: improved readability

[wlindley]

any current status for this patch?  doesn't appear to be in current trunk.

[prissi]

SInce it did not solve the issue mentioned, no it is not. Maybe I am too conservative. I do not know, if it is in Experimental?

[jamespetts]

No, it is not in Experimental. It is very difficult to incorporate .patch files designed for Standard into Experimental, which uses Git and not SVN.

[prissi]

The program patch is about 20 years old and predates SVN as well as GIT. Thus patch should work on any system, given enough fuzz and not too many conflicts. The content management system does not matter at all for integrating code.

[neroden]

This patch will *NOT* solve the issue with a train waiting in front of a choose singal. It will only solve the issue, if you use end of choose signs at each station exit.

As someone else commented, you should usually be doing this anyway.

The only useful function of choose signals is to let a train pick which platform to go into at a single station (simulating the 'tower operator' for the station :-) ).  However, I often have two "parts" to a station (say, an upper level and a lower level, or a tram level and a train level) and end-of-choose signals are necessary to break them up into two groups.

Choose signals and end-of-choose signals are basically only useful to create a "group of platforms" -- at least, I haven't figured out any other way to use them.  This patch improves their usefulness for that purpose by allowing through trains to run through the platforms.

Some version of this patch should go in as it would be a great improvement.

As commented by someone else, choose signals should be one-way only -- I can't think of any possible way they're useful two-way -- perhaps for two very-very nearby stations or something....

[prissi]

Usually I find choose signals most useful on terminals; and then the end_of_choose is usually not needed ... but playing styles may differ. I will have a look at the patch, although it was never a complete patch as the second part is only part of the posting.

EDIT:
The cleanup part is incorporated. The code for the waypoint search is a little hacky. I am considering slightly other ways to achieve this function.

[skreyola]

Choose signals would also be useful on multi-path routes, if end-of-choose worked how I always used to think it did, i.e., the choose signal stops trying to reserve past it and lets the train go on one of the possible routes if one is clear.
But...

[prissi]

Choose signals are now handled as normal signals, if another choose_signal or and end_of_choose is on the same route.

[neroden]

Choose signals are now handled as normal signals, if another choose_signal or and end_of_choose is on the same route.

I don't understand what this means.   Could you give more detail?  Does this mean
(1) The path is only reserved to the next signal;
or
(2) The path is not recomputed
or both?

(1) is desirable behavior.  (2) is not, the path should be recomputed.

Choose signals would also be useful on multi-path routes, if end-of-choose worked how I always used to think it did, i.e., the choose signal stops trying to reserve past it and lets the train go on one of the possible routes if one is clear.
But...

Yes, if gerw's patch went in as described, or something else which allowed for a new route computation at a choose signal, it might allow proper use of passing sidings, which currently simply don't work (the passing track is never ever taken).

[prissi]

This patch did not introduced route chooses; it just avoid route search if there are end_of_choose signals or another choose signal on the route. This part is in the trunk.

[neroden]

This patch did not introduced route chooses; it just avoid route search if there are end_of_choose signals or another choose signal on the route. This part is in the trunk.

OK, so (1) and (2).  Thanks.