Train/Tram Block Signal not working

[matio69]

Simutrans 110.0.2-4388
pak128.open.r527 from Sep 05 2011 at 04:42 (MEZ)



With previous versions of nightly build this streetcar two way/one track configuration worked. After downloading r527, block signal does not work.

[prissi]

Then this is rather an error of pak128.

(What is an end of block signal???)

[VS]

If I understand this, you have a piece of track (in front of town hall) that should be used in both directions, and includes two stations. Since stations act as signals, too, your design will inevitably jam with two trams standing at stations "heads-on". That's a given.

You will need long-block signals (terminology may vary) on entrances; these make vehicles "see through" stations when checking if track is free. But the whole design is weird, why not have the trams always use common track in same direction? Traffic would scale a lot better...

As to the perceived bug, there haven't been any changes to signals in the pakset. At least I'm not aware of any. What was that previous version where this worked? I would rather think that road stops might have been treated as not-stations or something and that changed.

[greenling]

It´s possible too build in the station a Botten who enable it to switch out the signalwork?

[Dwachs]

What do you mean? bottle or button? 

[greenling]

Dwachs
in mean botton!
sorry i was siting in a swamp!

[Bughu Baas]

Why do you need a button?

Either you have to use (long block) signals, then you will built them - or you don't need them, so you will spare the money for them.

Nevertheless, serving a single track station from both sides is a bad idea. Serving even two stations is much more worse. Please rethink about your tram network.

German: Welchen Sinn soll ein derartiger Schalter haben? In einem eingleisigen Bereich zwei Stationen zu haben, die von beiden Seiten bedient werden, engt dich zusehr im Betrieb ein - egal ob da Signale vor sind oder nicht. Die Leistungsfähigkeit deiner Tramlinien geht den Bach runter, da sind dann Busse vielleicht rentabler. Kleiner Tip: eine Bus-Expresslinie Bahnhof - Rathaus (mit nur diesen beiden Stationen) kann Wunder bewirken...

[matio69]

You will need long-block signals (terminology may vary) on entrances; these make vehicles "see through" stations when checking if track is free. But the whole design is weird, why not have the trams always use common track in same direction? Traffic would scale a lot better...

Please look again at my previous post. I did use long/BLOCK signal.
This what this post is about they are not working.

Nevertheless, serving a single track station from both sides is a bad idea. Serving even two stations is much more worse. Please rethink about your tram network.

With all do respect: this thread is not about if this particular design is good or bad, but about bugs in the game. I posted it here, because I tested the same design in nightly build pak128 version r492 and it worked without any problems, and with current version r527 it does not work anymore.

Welchen Sinn soll ein derartiger Schalter haben? (und so weiter...)

Wie ich bereits erwähnt, tatsächlich dieses Design arbeitete ohne Probleme mit früheren Versionen. Bus-Service kann Haufen zusammen und können nicht vor den langsameren Verkehr. Daneben Straßenbahnen hat viel größere Kapazität als Busse. Und schließlich, Straßenbahnen gibt mir viel größer finanzwesen Rendite gegenüber Bussen.
PS. Sie sind wie American sprechen, nicht wie europäische: Straßen über Schienen?

[Bughu Baas]

I messed up matio69 and greenling, the german answer was for the latter, but I thought he also started the thread. Sorry for that. 

But my opinion about the usage of more than one station on a single but two-way track stands. Sometimes in special cases a bus is more efficient than a tramway (in simutrans), albeit the latter should be preferred, for the reasons you stated. (In my games I have extended usage of tram and self-made subway, btw.).

And now back to topic

[matio69]

Then this is rather an error of pak128. (What is an end of block signal???)

If this is inappropriate thread, please move it to appropriate one (this is to the moderator)

Long or as I call it block signal locks a stretch of tracks on its pathway between long (block) signal and a next signal. Next signal it may be again long (block) signal to lock pathway of a train or it may be single light signal - which I call end of the long (block) signal.

Single light signal reserve/locks pathway of the train to the next station or the next signal.
Long (block) signal reserve/locks pathway of the train to the next signal, no matter if there is a station on the way or not.

It seems there is some terminology confusion, but as I looked just seconds ago, one light signal is called "signal (standard type)" and two light signal (one over another) is called "long block signal (standard type)".
To describe the situation I am dealing with I introduced new term "end of block signal" which can be either of those two signals (of course with two different outcomes).

I hope this shed a little more light (pun intended) on my problem.

[VS]

Ok... First, sorry for the perhaps a bit confrontational attitude about layout, that's my fault

I'll try to reproduce this in a similar situation, but I suspect that it's a program bug, if at all. Most likely some mixup between rail/tramway waytypes.

edit: Testing r4811 with pakset r527, I re-created your situation. Sorry, I can't make it happen.

[matio69]

Hey, VS, no offense taken.

As I specified in my first post this layout (design) was not working with:

Simutrans 110.0.2-4388pak128.open.r527 from Sep 05 2011 at 04:42 (MEZ)
(...)
With previous versions of nightly build this streetcar two way/one track configuration worked. After downloading r527, block signal does not work.

Older version which I'm talking about in my post is: 110.0.2-4388 pak128.open.r427 (1.99.0) which originally this layout was built.

That's why I am posting in a bug thread: with OLDER VERSION something WAS WORKING and now with NEWEST VERSION IS NOT WORKING. I think this is what bug report should be about or am I wrong?

Sorry, if I did not spell it out exactly it in my first post.

[prissi]

I think that the older version workings was rather for luck. As written correctly, this design can jam, when there is more than one streetcar on the red line. If it exits the last station on the shared track before the previous one is waiting at the long block signal both trams will face each other head on. Since the track is shorter, this situation is not likely to happen fast, it may require some loading reloading or waiting for load.

[infernalmachine]

I decided to have a little look at this, and created a simplified version with two lines, but as it turned out I think I've found the "misunderstanding" using just one line.  The line runs clockwise, and there is a one-way long block signal (what matio69 labelled as "bs") followed by 2 stations and then a one-way normal signal ("ebs").

I ran the game (lastest nightly with latest nightly pak128.open) until a tram just reached the long block signal and used the "b" keyboard shortcut to show the track reservations.  I should add that to start I had the line stop at all the stations.

In the first picture you can see how the game currently reserves track when the tram approaches the long block signal.  It only reserves the path from the tram to the next destination, not to the next signal.



But then, in the second picture, I show what matio69 was expecting to occur.



However, I was only able to produce this by removing the two stations between the longblock signal and the normal signal from the line's schedule.

In other words, the game currently handles long block signals so that the vehicle reserves (when it is allowed through) the shorter of "the path to the next signal" or "the path to the next destination".

Now, I also noticed that the game version/pak version in which matio69 is saying they could successful use this design was over 400 code revisions ago.  Is it possible that long block signals once ignored the destination when reserving track (ie always reserved all the way to the next physical signal) and that this has been changed since then?

[matio69]

OK guys. Here is the proof how long block signal works in previous version 110.0.1-4337 pak128.open.r492 (1.99.0)
This layout does not work with newest version 110.0.2-4388 pak128.open.r529.
Here we go:

Tram #1 drives to the long block signal first (Hitting keyboards "b" shows block reservation). Even if it only shows that tram #1 "reserves' track to the nearest stop, tram #3 has still red light (long block signal).
It means that tram #1 reserves or block long stretch of the tracks [to the "end of the block signal EBS"].


Tram #1, after stopping on first of the two stops, continues to the second stop. But before that happened tram #2 approached long block signal and it received stop light right there.


Only when tram #1 is leaves long block signal zone (crossing what I call EBS), tram #2 receives signal proceed.
If I would move EBS beyond the stop, which tram #1 is approaching, tram #2 would NOT receive proceed signal till tram #1, after stopping, passes EBS.


Only when tram #2, after stopping on both stops, leaves the long block signal zone, tram #3 receives signal proceed.

I hope this show in detail how whole design is suppose to work and it does with previous version and does not with current.

And if anyone will doubt me again I may just pack my toys and move to the next sandbox! LOL!

Seriously, guys. This is what long block signal was designed for: to reserve/block long stretch of tracks ahead, with stations/stops on the way or without, unidirectionallly or bidirectionally!

[VS]

Ummm. You're now seriously investigating this, which is great Still, I can see that the repository is currently at 4811, while you write that your version is 4388, which is from April. That's a no-go for reporting bugs. If there was something broken before, and is not anymore, well...?

So: To actually check this properly, please go grab the most recent program for your shiny new pakset, and try these together. I did exactly that, and everything works. The curious thing is that reservation indeed does not show for the whole track, but signals seem to work as intended. Please share if you get the same results

If you had a typo (twice the same?) in your posts all the time and the revision is more recent, I'm nominating us collectively for a facelpalm



Just to make sure, there is one more possibility. Out of the four types of long-signals, one has is buggy and is actually not long. That would be the next thing to check, if you manage to repeat this somehow

[matio69]

YES, IT WORKS AGAIN!

Thank you, VS. You nailed it right between the eyes!
As you advised I downloaded latest nightly build 4811 and taa-daa! Works

Now I publicly will do facepalm to myself.

Please erase this thread since it is without merit.

Thank you.

[VS]

Great! Thanks for cooperation No facepalm needed, just remember - latest, latest, latest... (hears Dirk explode somewhere in the distance)

[prissi]

Reservation only goes to next stop, but only after NOTHING IS ON THE WHOLE SECTION. The reason for this is, that a train can only delete reservation from tiles currently in its route. And a route ends at a station (or waypoint).

[infernalmachine]

Glad to see that it worked out.  And thanks to matio69 for showing us all that long block signals are more powerful and useful than we might have thought.

I added a second line to my test example above and sure enough it works.  I guess that the long block signal (LBS) stops a train/tram if anywhere between it and the next signal on the vehicle's path is reserved.

I also tried it with several trams on each line, and I noticed that it has some unexpected emergent behaviour.

If Line A, say, has a tram already in the shared portion, a Line B tram (going in opposite direction from A) has to wait until the A tram leaves the shared track before possibly moving past its LBS.  But a second Line A tram, which is approaching its long block signal but hasn't yet reached it can (tentatively) reserve into the the shared track as soon as first tram A has left first station in shared portion.

Here's where it gets weird.  If second Tram A hasn't yet reached its LBS when first tram A passes its regular signal, it retains its reservation up to the first station and "steals" access from the waiting tram B.  However. if it does reach its LBS, then tram B moves first, because B waits for only the shared track to be cleared, while second A now has to wait for normal signal to be passed by first A before it can (actually) reserve shared track. [The overlap of A and B's track use is shorter than the distance from LBS to EBS (using matio69 term) for A or B.]

If you use "b" to watch the reservations, you can see that the second A tram will seem to reserve up to the first station and then lose that reservation when it reaches the LBS.

It's amazing the complex results that can evolve from simple rules!

[prissi]

This behaviour is due to long block signals being quite an internal effort, as the route calculation must be run, which cannot be done during normal driving. Thus in this case (and also in the related choose signals) the signal will act as a normal signal until the last tile before the signal is reached. The reservations you see are rather temporary, depending whether the first or the second train near the choose/LB signal did its test last.

As a side effect, those signals will ne bee passed with more than 50 in case of none-free.