YAPF & PBS Question

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Hazelrah
Traffic Manager
Traffic Manager
Posts: 196
Joined: 13 Apr 2005 05:41

Post by Hazelrah »

I was drawn in by this topic and looking at the signals here in Japan. At least on the Keisei line from Ueno to Narita. They appear to exhibit the behavior that KUDr is talking about.

Odd thing though is that there apear to be two types of signals. The ones that lead in and out of stations have the green light on the top, but signal blocks in between stations have the green light on the bottom. I guess since normal traffic signals are placed horizontaly instead of vertically, there would be no confusion. I read on wikipedia that that's why normally train signals have the green light at the top.

-Hazelrah

PS Sorry if I annoyed you with that last comment KUDr! But actually I am interested in PBS and didn't know the story. :oops:
User avatar
Brianetta
Tycoon
Tycoon
Posts: 2567
Joined: 15 Oct 2003 22:00
Location: Jarrow, UK
Contact:

Post by Brianetta »

Signals in the UK are placed such that the red aspect is as close to the driver's line of sight as possible. As a result, trackside signals have red at the top, whereas overhead signals have red at the bottom. Seeing a red aspect is more important than seeing a green.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
User avatar
Dave
Moderator
Moderator
Posts: 17249
Joined: 26 Dec 2005 20:19
Location: North London

Post by Dave »

So... in any situation where the driver's Line of Sight would involve looking up at the signal, the red light is at the bottom? Nearly all the signals I have seen (overheads and trackside) have all had the red at the bottom.
Official TT-Dave Fan Club

Dave's Screenshot Thread! - Albion: A fictional Britain
Flickr


Why be a song when you can be a symphony? r is a...
User avatar
Brianetta
Tycoon
Tycoon
Posts: 2567
Joined: 15 Oct 2003 22:00
Location: Jarrow, UK
Contact:

Post by Brianetta »

Dave Worley wrote:So... in any situation where the driver's Line of Sight would involve looking up at the signal, the red light is at the bottom? Nearly all the signals I have seen (overheads and trackside) have all had the red at the bottom.
Yes, certainly on all mainlines in the UK. By trackside, I was thinking about literal trackside, rather than on a post. These are more common in tunnels.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
Hazelrah
Traffic Manager
Traffic Manager
Posts: 196
Joined: 13 Apr 2005 05:41

Post by Hazelrah »

Ah, that makes sense then. Car traffic wouldn't be looking into train tunnels then ;)

-Hazelrah
KUDr
OpenTTD Developer
OpenTTD Developer
Posts: 219
Joined: 11 Jan 2006 21:36
Location: Czech Republic

Post by KUDr »

Many thanks to Patchman and DaleStan for TTDP PBS details. And to all about default-red signals.

In Europe it is also so, that default signal state it red and the path is "opened" just for train that is comming and can proceed. Also when train comes to choice, only one exit is green, so you can see what path it will follow.

fabca2: look at signals of your railways in France. Quite sure it will be the same.
And to correct small misunderstanding: in your second example - signal [1] becomes red immediatelly after locomotive passes it, so all wagons will pass red signal - this is also how it hebaves in real life. You can call it weird but it has reasonable logic behind.

And about opening signals from red to green state: it is expected that the distance between train and signal that is opened will depend on the current train speed. So it can happen that train passing signal [1] will need to open not only signal [2] but also [3] and [4] at the same time.
Hazelrah
Traffic Manager
Traffic Manager
Posts: 196
Joined: 13 Apr 2005 05:41

Post by Hazelrah »

KUDr wrote:And about opening signals from red to green state: it is expected that the distance between train and signal that is opened will depend on the current train speed. So it can happen that train passing signal [1] will need to open not only signal [2] but also [3] and [4] at the same time.
So does this mean that YAPF assumes that a fast train will need more than one tiles worth of stopping distance? It's probably out of bounds of YAPF, but I'd love to see trains start to slow down before they actually hit a red light instead of the instantaneous stop they do right now. This would definitly be a first step in the right direction.

-Hazelrah
KUDr
OpenTTD Developer
OpenTTD Developer
Posts: 219
Joined: 11 Jan 2006 21:36
Location: Czech Republic

Post by KUDr »

Hazelrah: yes, at least support for stopping (or slowdown) the train in advance is expected to be in that new signalling too (YAPF will be used only as pathfinder that returns some usefull information for this). Also better load balancing should be there - this point is still unclear. This project didn't start yet, because we will need to think more about some simple algorithms how to achieve all that.

I am now embedding light weight scripting engine (LUA) into ottd to simplify the prototyping phase of such features. Currently i am excited how well that LUA script works with ottd and i am connecting it to all interesting structures and variables inside the game. Probably it will be worth new branch (so others can use it too). But i still need to learn how LUA engine works, how to handle errors and so on. My first simple test script finds and clears all trees on the map.
CRC32
Engineer
Engineer
Posts: 1
Joined: 06 Jul 2006 10:52

Post by CRC32 »

Some thoughts about YAPF or next pathfinder:
(sorry for my english)
(for trains only)

0. If there is red signal on short path it may be better to wait, then to choose long path. This is always true if short*2 < long.

1. Road map (level 1) ("path" (name needed) from junction 1 to junction 2) http://theory.stanford.edu/~amitp/GameP ... ns.html#S6
Length and penalty must be calculated as time(!) needed for [this, average, slowest, fastest ... ] train to move from junction 1 to junction 2.
"Length for new train" (as time) =(time to clear start of "path") + (trains in queue) * ("Length"). This solves 0.
Trains must be added to "path's" queue at least 2 blocks before (depending on speed), better ASAP.
"Paths" may be stored in memory, update needed only when player builds.
IRL blocks are calculated same way: block's length differs, but time needed for train to move each block is same (at least in USSR / Russia).

2. Level 2 road map same as level 1, but only stations, medium/big junctions (as whole) (IRL all junctions are/belong to station) counts, small junctions like loadbalancing, passing loops, ... are ignored (because they are part of big junction/station) and similar ways (same start and destination) counts as same.

3. Station dispatchers may be needed only in crossings of road map level 2. Each dispatcher finds only local paths (on his station/big junction). Dispatcher should add trains to queue and then find friendly paths (no crashes) and reserves them for as much as possible trains to drive at same time. Dispatcher must set all switches (so train newer chooses pach, it's set for him) so this must be replacement for pre-signals, PBS and unrealistic station and switch layouts. If switches are realistic then for each tile only one byte is needed (0 - switches set straight; 1 - switches set right or left). Station paths may be predefined, IRL they are. Player also could predefine paths if he/she don't like CPU's paths.
meowsqueak
Engineer
Engineer
Posts: 48
Joined: 05 Jul 2006 22:25

Post by meowsqueak »

KUDr wrote:I am now embedding light weight scripting engine (LUA) into ottd to simplify the prototyping phase of such features.
Ok, that news is officially awesome! :)
dunkleself
Engineer
Engineer
Posts: 6
Joined: 02 Nov 2004 07:19

Post by dunkleself »

KUDr wrote:Hazelrah: yes, at least support for stopping (or slowdown) the train in advance is expected to be in that new signalling too (YAPF will be used only as pathfinder that returns some usefull information for this). Also better load balancing should be there - this point is still unclear. This project didn't start yet, because we will need to think more about some simple algorithms how to achieve all that.
So what kind of signalling would this allow us? I am really interested in signalling systems, as I would like to model my states (Queensland, Australia) railroads signaling system. But think it would be cool if I could model others at the same time :-)
empirical
Engineer
Engineer
Posts: 5
Joined: 28 Jul 2006 00:23

Post by empirical »

I'm really looking forward to PBS. For a time I worked on a 3D train management game and completed this aspect. I doubt there is anything here that the Devs don't already know, but here is how I did it.

Not all of this can exactly apply to OpenTTD because OpenTTD needs to be a bit more flexible.

Sequence.

1. Train about to depart works out the route to its next destination and records it. (OpenTTD, may only need to route 4 blocks)

2. (if a signal exists) The train scans along the route until one or thew following is true: The tracks 'reserved for' value is none zero or it has reached a fourth signal. (OpenTTD, may 'timeout' ealier if too long between signals - would leave a permanent yellow state and user is prompted not to be so mean!)
Each of the (max 4) signals is recorded.

3. A path is reserved ONLY up to the last good signal (IE entire blocks are reserved only)

4. Each signal is set to a color. How this bit works:
If the last signal reached is red, then the next nearest signal is yellow, then double yellow (if 4 aspect) and then green.

So if the train reserves two blocks the Last Signal is red, the next signal is yellow and the signal in front of the train is double yellow.

5. Rear setting.
This is the bit that prompted me to make this post. I thought long and hard about how much processing time would be eaten by working back along all the junctions recursively... until I realised.. i didn't have to!

When the train leaves a section, a marker is 'sent out' along the track setting the signal colors to: Red, then Yellow, then green.
If this marker reaches a junction.. it stops!

This will have the effect that all signals gaurding a junction will always be on red. Which is exactly how it working in UK (at least) signalling.
But signals on a normal stretch will be left on green.

6. User
If the user modifies a reserved track the train's path is revoked. The train tries to set a new path. If it fails it simply shut down (OpenTTD suggestion: Tell the train route revoked. The train removes its path (BEFORE editing takes place). The train returns TRUE if it is not too close and can safely slow down and stop. If FALSE the user has a "Track in use" message OR do a cartoon 'sudden stop'

OpenTTD specific modifications:

The train chooses a route and allocates as far as possible up to 3 or 4 blocks (depending on the type of signal). As described in section 2 it reserves as much as possible.

When each train is processed OpenTTD checks if the train has allocated the required number of blocks ahead, if not it then pathfinds from the last block its allocated again. In other words it pathfinds in advance.

Allocation of track.

In my game the actual Train ID is recorded on the track for two reasons:
1. To revert the path.
2. For delay attributation (doesnt apply to openTTD)

Im not sure if you have 16 bits per tile free. If not then reservations will have to be a flag, and will have to iterate though all trains to find out which has allocated a section if its being edited.

Like I said, you probably know all this, but just wanted to throw in everything I worked out as I wont be making my game.

Oh and I called it semiautomatic signalling after the real type. :)
User avatar
Brianetta
Tycoon
Tycoon
Posts: 2567
Joined: 15 Oct 2003 22:00
Location: Jarrow, UK
Contact:

Post by Brianetta »

empirical wrote:2. For delay attributation (doesnt apply to openTTD)
It might one day, if we get shared rails.

I think the devs have already discussed the idea of a "default red" system throughout (even on straights), and IIRC the concensus was that it was the best (and realistic) approach.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
empirical
Engineer
Engineer
Posts: 5
Joined: 28 Jul 2006 00:23

Post by empirical »

Brianetta wrote:
empirical wrote:2. For delay attributation (doesnt apply to openTTD)
It might one day, if we get shared rails.

I think the devs have already discussed the idea of a "default red" system throughout (even on straights), and IIRC the concensus was that it was the best (and realistic) approach.
If that comes to pass, I guess I'll have to do a bit of tinkering then.
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: Google [Bot] and 14 guests