YAPP - Yet Another PBS Patch (now in trunk!)

[Progman]

Small glitch:

The attachment halftile.png is no longer available

I can confirm this

halftiles.png (99.51 KiB) Viewed 7294 times

As YAPP use no own sprites it is a bug in the trunk (imo)

[Rubidium]

As YAPP use no own sprites it is a bug in the trunk (imo)

I disagree for the following reasons:
- the overlay for the reserved tile consists of 10 sprites in total. 1 for each of the 4 slopes rail can have and 6 for the flat tiles, i.e. for each rail piece you can build. Therefore all reservation overlays on the tiles must be build up manually. In this case it looks like it doesn't happen in all cases.
- from a code point of view YAPP isn't drawing the overlays in one case; there are two places where railbits are drawn and one of them doesn't add the overlay. This is by the way exactly the reason for that issue (around line 1750 of rail_cmd.cpp, just after the track reservation drawing).

[Ammler]

Hello

YAPP runs quite well here, we had after playing around 20 hours the first assert today:

Code: Select all

src/train_cmd.cpp:3578: void TrainController(Vehicle*, Vehicle*, bool): Assertion `chosen_track & bits' failed.

If you let the train (#48) drive in the reserved path.

assert2.sav

(652.32 KiB) Downloaded 174 times

Greets
Ammler

[SmatZ]

Hello,

it seems YAPP has problems when Convert rail tool is used.
It is possible to convert reserved rail to maglev. Track reservation is not cancelled, and furthermore tiles behind this converted tile aren't unreserved, too.

[Mchl]

That's nasty one

Strange no one noticed it until now.

[planetmaker]

We found another bug.

openttd: /home/openttd/svn-dev/src/yapf/yapf_node_rail.hpp:194: bool CYapfRailNodeT<Tkey_>::IterateTiles(const Vehicle*, Tbase&, bool (Tfunc::*)(TileIndex, T
rackdir)) const [with Tbase = CYapfReserveTrack<CYapfRail_TypesT<CYapfAnySafeTileRail2, CFollowTrackT<TRANSPORT_BEGIN, false, true>, CNodeList_HashTableT<CYa
pfRailNodeT<CYapfNodeKeyTrackDir>, 12, 16>, CYapfDestinationAnySafeTileRailT, CYapfFollowAnySafeTileRailT> >, Tfunc = CYapfReserveTrack<CYapfRail_TypesT<CYap
fAnySafeTileRail2, CFollowTrackT<TRANSPORT_BEGIN, false, true>, CNodeList_HashTableT<CYapfRailNodeT<CYapfNodeKeyTrackDir>, 12, 16>, CYapfDestinationAnySafeTi
leRailT, CYapfFollowAnySafeTileRailT> >, Tkey_ = CYapfNodeKeyTrackDir]: Assertion `KillFirstBit(ft.m_new_td_bits) == TRACKDIR_BIT_NONE' failed.

ps.openttdcoop.org-3979-svn/src/yapf/yapf_node_rail.hpp:194: failed assertion `KillFirstBit(ft.m_new_td_bits) == TRACKDIR_BIT_NONE'

How to reproduce it:
Go to the "FACTORY PICKUP" station. There're actually two parts of it, a used and busy part (right hand side) and a newly built, not yet connected part left of it. Build a connection from the new part to the old part to a track where a train is waiting. The server (and only the server) asserts with above message after the train leaves the station. My client sometimes exits with above mentioned client message (which is the same without debugging info, I think), but sometimes it only looses connection without asserting - which really leaves me wondering.

EDIT: this does not occur, if convert everything left of the old station to e-rail.

[Beardie]

And can anyone help me here, when a train station is full the train seems to turn around and go back down the other line when instead i want it to wait can anyone fix this.

Here is a screenshot to help illustrate.

[ige]

Turn off 90° curves and the train must wait for free path

[Beardie]

Turn off 90° curves and the train must wait for free path

Yhea but the slight problem there is that my trains can't get out of the depots.

As you can see below.

I'm i not doing something wrong with the siganlling maybe, or is this a bug with YAPP. (Previous Post)

[ige]

Look at the screenshots in this topic. There you can see, how to build depots without 90° curves.
http://www.tt-forums.net/viewtopic.php?f=47&t=37886

[Ammler]

Just to bring the thread back to topic...

We are still playing this patch at #openttdcoop PS and wondering about why a train should wait for a path if there will never be a path.

wait_for_pbs_path.png (30.04 KiB) Viewed 6299 times

Firstly, like it is now, do not allow removal of reserved tracks. Downside, it's not really intuitiv if path highlighting is disabled.

I do not see any reason, why you should forbid it, at all. (after playing around many hours...)

Greets
Ammler

[SmatZ]

Hello, another problem:
Unstop Train 432. Two trains will crash and Train 432 will be "stuck" waiting for signal. Trains was moving and only what I did was that I stopped it.
Game sometimes crashes with
src/train_cmd.cpp void TrainController(Vehicle*, Vehicle*, bool): Assertion `chosen_track & bits' failed.

It is from openttdcoop game, r13501M.

[audigex]

A suggestion - allow faster trains to get priority at signal blocks (facilitating overtaking, and because they clear junctions faster)

Or on the other hand, is there any chance of the weak-reservation strong-reservation being implemented? If so, can we get 2 types of signal, a "Main line" signal which reserves two further main line blocks (or just one non-main line block) and/or a "weak" signal - which gives priority to normal/main line signals.

This would all aid, IMO, the realism aspect of PBS, by giving main lines a priority we can recreate much more easily the side line priorities we see so often, as well as helping out with overtaking tracks and the holy grail of Bi-Di tracks.

I've no doubt the whole Bi-Di question has come up frequently, but there's my 2c regardless, just in case I say something helpful

[Youri219]

A suggestion - allow faster trains to get priority at signal blocks (facilitating overtaking, and because they clear junctions faster)

Or on the other hand, is there any chance of the weak-reservation strong-reservation being implemented? If so, can we get 2 types of signal, a "Main line" signal which reserves two further main line blocks (or just one non-main line block) and/or a "weak" signal - which gives priority to normal/main line signals.

This would all aid, IMO, the realism aspect of PBS, by giving main lines a priority we can recreate much more easily the side line priorities we see so often, as well as helping out with overtaking tracks and the holy grail of Bi-Di tracks.

I've no doubt the whole Bi-Di question has come up frequently, but there's my 2c regardless, just in case I say something helpful

I've read somewhere (I think Tekky posted it) that weak reservations are not possible without a major change in th pathfinder system. The current YAPP (without weak reservation) builds upon the existing pathfinders instead of changing them.

[Beardie]

Look at the screenshots in this topic. There you can see, how to build depots without 90° curves.
http://www.tt-forums.net/viewtopic.php?f=47&t=37886

Well i don't want to move my deopts, there are other places were i have to have 90 degrees turns, shorely there is a way of correcting this using the signals. When i use normal signals the trains don't turn back on them selves when a sation is full but they do when i have the YAPP signals, is this a bug or have i used the signals in a incorrect way?

[Ammler]

Maybe, you have set the patch setting?

no90deg.png (12.16 KiB) Viewed 5890 times

[Dave]

I was under the impression YAPP had to be used with YAPF anyway.

The "90 degrees is less realistic" isn't necessarily true anyway, especially not at the scale you're playing at there.

[Beardie]

Did anyone realise that i want a method of fixing the train turn porblem (posted a few posts up) without using the 90 degree method. Why is everyone still going on about it. I know i can fix my porblem but then my trains can't get round a few corners on the map.

[cmoiromain]

the problem is surely due to the fact that YAPP is based on YAPF, which doesn't handle 90° turns IIRC. Therefore the is no other solution than disabling 90° turns, and change your network to delete them. An that will only be benefic for your trains, who will have to slow down less.

[Michi_cc]

New bugfix relase 8.1 is in the last relase post. Thanks to the #openttdcoop people for testing.

Changes:

Highlighting of tracks on steep slopes.

When 90 degree turns were forbidden, a train could free the reservation of another train. (Rubidium, SmatZ)

Fixed an assert that could happen when forcing a train over an already present reservation. (Ammler)

Extending a path reservation could ignore compatible railtypes. (planetmaker)

All tracks can now be freely demolished with any tool. Already present path reservations are properly cleared and it will be tried to reroute trains. If this fails, the train is marked as stuck. I decided against disallowing track removal completely because some of the posted savegames show that completely disallowing track removal is bad, and implementing some way to circumvent the protection and still clear paths proberly would have been rather inelegant and error-prone.


@Rubidium: For your playing style (i.e. very large spread out stations), setting pf.yapf.rail_pbs_station_penalty to a high value like 4000 gives a better distribution of trains over the platforms.

-- Michael Lutz