Skip to main content ↑ ↓
Topic: [patch] Choose signal (Read 15281 times) previous topic - next topic

[patch] Choose signal

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

Re: [patch] Choose signal

Reply #1 –
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?

Re: [patch] Choose signal

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

Re: [patch] Choose signal

Reply #3 –
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.

Re: [patch] Choose signal

Reply #5 –
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).  :P

Quote from: gerw – on
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?

Re: [patch] Choose signal

Reply #6 –
Quote from: whoami – on
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  :P - 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.

Re: [patch] Choose signal

Reply #7 –
After testing again: I figure that you implemented something similar to my original extension request, replacing the EOC as we know it. I ****ume 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.

Quote from: gerw – on
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.)

Re: [patch] Choose signal

Reply #8 –
I think that trains have always been "it". Only ships are "she".
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.

Re: [patch] Choose signal

Reply #9 –
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 cl**** of locomotives). There were definitely comments about the fact that 'iron horses' were all mares.

Re: [patch] Choose signal

Reply #10 –
Quote from: whoami – on
After testing again: I figure that you implemented something similar to my original extension request, replacing the EOC as we know it. I ****ume 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'?

Quote
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]
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 p**** 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);
		}
	}
}

Quote
"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.

Quote
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).

Quote
(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".

Re: [patch] Choose signal

Reply #11 –
Quote from: gerw – on
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.

Re: [patch] Choose signal

Reply #12 –
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. :)

Re: [patch] Choose signal

Reply #13 –
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.

Re: [patch] Choose signal

Reply #14 –
Quote from: prissi – on
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? :o

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: [patch] Choose signal

Reply #15 –
Quote from: prissi – on
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:

Quote from: gerw – on
But the new behaviour of the CS - choose signal  :P - 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.

Re: [patch] Choose signal

Reply #16 –
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. 

Re: [patch] Choose signal

Reply #17 –
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.

Re: [patch] Choose signal

Reply #18 –
Quote from: prissi – on
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.

Re: [patch] Choose signal

Reply #19 –
Quote from: prissi – on
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 ****ume that the issue hardly matters to them.

Re: [patch] Choose signal

Reply #20 –
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.

Re: [patch] Choose signal

Reply #21 –
Quote from: prissi – on
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.

Re: [patch] Choose signal

Reply #22 –
Quote from: z9999 – on
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 p**** - 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

Re: [patch] Choose signal

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

Re: [patch] Choose signal

Reply #24 –
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?

Re: [patch] Choose signal

Reply #25 –
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.
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.

Re: [patch] Choose signal

Reply #26 –
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.

Re: [patch] Choose signal

Reply #27 –
Quote from: prissi – on
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....

Re: [patch] Choose signal

Reply #28 –
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.

Re: [patch] Choose signal

Reply #29 –
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...
--Skreyola
You can also help translate for your language with SimuTranslator.

Re: [patch] Choose signal

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

Re: [patch] Choose signal

Reply #31 –
Quote from: prissi – on
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.

 
Quote from: skreyola – on
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 p****ing sidings, which currently simply don't work (the p****ing track is never ever taken).

Re: [patch] Choose signal

Reply #32 –
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.
 

Re: [patch] Choose signal

Reply #33 –
Quote from: prissi – on
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.