The International Simutrans Forum

 

Author Topic: r6520 Bugged long block signals when placed one tile before station tile  (Read 3204 times)

0 Members and 1 Guest are viewing this topic.

Offline Spacethingy

  • *
  • Posts: 177

I think I'm right in saying that a long-block signal is just like an ordinary signal - except it ignores stations.


If so, the attached save shows a tram and a train apparently jammed buggily at a longblock signal with a suitable signal up ahead to complete the long block. (Note the steam loco still emitting steam, even though it's "waiting for clearance", and is "moving" steadily at 50 km/h).


After some experimentation, I've noticed that the jamming occurs when the longblock signal is placed on the tile adjacent to a station. With one tile gap, the normal behaviour is observed. See the save file.


Hope that helps!


r6520, pak64 Linux Lubuntu (sorry, can't seem to get the nightlies working on my Linux box)

Offline kierongreen

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 2269
Confirmed.

Offline kierongreen

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 2269
The condition occurs when a long block signal is placed one tile before the end of the next station. This wouldn't be a normal place to put a long block signal however simutrans should still cope with this condition in a way which makes sense.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9568
  • Languages: De,EN,JP
It is rather strange. The code returns correctly everything. Debugging this, a convoi should not be able to pass a normal signal, the way the code is handling it. Hmm, will need to dig much deeper.

Offline kierongreen

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 2269
Indeed, that's as far as I got!

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4603
  • Languages: EN, DE, AT
In the savegame, if you remove the normal signal on the tracks with the running train, it stops moving, too. I think route search for reserving the block reaches the tile, on which the train is standing.

I think the problem here is convoi_t::set_next_stop_index: it is called from waggon_t::is_weg_frei_longblock_signal with an INVALID_INDEX, thus the routine sets the next stop on the tile before the target, which is the signal again -> infinite loop.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9568
  • Languages: De,EN,JP
Very well spotted. Thank you, this is indeed the reason.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4603
  • Languages: EN, DE, AT
This problem is still there:
In the savegame, if you remove the normal signal on the tracks with the running train, it stops moving, too. I think route search for reserving the block reaches the tile, on which the train is standing.
If there is only one long block signal on a circle, the train will stop forever at the signal.

Offline kierongreen

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 2269
Even if there are other signals also? A long block signal will intentionally block if it's the only signal present on a loop.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4603
  • Languages: EN, DE, AT
Even if there are other signals also? A long block signal will intentionally block if it's the only signal present on a loop.
No other signals, only one long-block on a loop.

The code has a check for this situation to allow passing the signal, if only train on track is the train sitting at the signal. It also shows the same behavior as in the original report: Train is waiting at signal but steam engine is running.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9568
  • Languages: De,EN,JP
Should work again in r6578