YAPF - Testers needed!

KUDr · Post by **KUDr** » 10 Jul 2006 17:43

R2: yes, I agree. Just not sure how to achieve that with just a pathfinder (normally it should find the shortest way). I am now thinking about path driven signals (the next step towards new PBS) where this behavior can be a side effect of negotiation between trains heading to the same junction (the cost of that shorter path will be temporarily higher because of another train that is planning to use the path that whould cause the conflict). In such case the train driver will choose the path that is not the best only for him but that is the best for the current traffic situation (like in real life - where there is a traffic dispatcher).

Any other idea how to achieve similar behavior would be appreciated. We can find an easier way how to do that.

mart3p · Post by **mart3p** » 13 Jul 2006 21:41

I have been having a problem with road vehicles when using YAPF. The sceenshot shows a test game that illustrates the problem. The vehicle always takes the route with all the bends rather than the faster straight route.

This problem causes my vehicles to follow a zigzag route through towns instead of following the straight bypasses that I have built around them.

At present there is no setting for a “road curve penalty” (as there is for NPF) perhaps it should be added.

KUDr · Post by **KUDr** » 13 Jul 2006 22:37

mart3p: yes, you are right. Probably I missed something in the cost calculation. I will revisit RV YAPF soon and will look at it. Thanks for that comment.

Tiberius · Post by **Tiberius** » 14 Jul 2006 08:54

The train mysteriously decided to use the already-occupied platform while there's another platform available ... making presignal useless. Not sure what caused this.

richk67 · Post by **richk67** » 14 Jul 2006 09:41

Tiberius wrote:The train mysteriously decided to use the already-occupied platform while there's another platform available ... making presignal useless. Not sure what caused this.

You need to use 2 way signals on the platform entrances. As well as two way, they also mean "choose between".

sc79 · Post by **sc79** » 14 Jul 2006 10:38

2-way signals arnt necessary for NPF or YAPF.

KUDr · Post by **KUDr** » 14 Jul 2006 19:55

Tiberius: I hope you don't expect me to work on it without reproducible case with savegame and .cfg ...

Brianetta · Post by **Brianetta** » 14 Jul 2006 21:25

Looks like normal NTP behaviour to me. Sure YAPF was actually on for trains?

Tiberius · Post by **Tiberius** » 15 Jul 2006 04:39

To richk67:
Thanks. Changing entrance signals to 2-way signals fixes this problem indeed. What I don't understand is the implication of path selection of 2-way signals: Those signals will NEVER be passed reverse. I thought if there's a need of distinction, then it should use another signal type or so to make it more verbose.

To KUDr:
This game uses LOTS of GRF files so I think it may not helpful for debugging. I'll try reproduce this problem and pack a savegame + GRF for you, maybe start again with clean MiniIN later and try reproduce it again.

XeryusTC · Post by **XeryusTC** » 15 Jul 2006 09:19

Tiberius wrote:To richk67:
Thanks. Changing entrance signals to 2-way signals fixes this problem indeed. What I don't understand is the implication of path selection of 2-way signals: Those signals will NEVER be passed reverse. I thought if there's a need of distinction, then it should use another signal type or so to make it more verbose.

Red 2 way signals are indentified as dead end by YAPF, this means that a train will never go there unless there is no other choise (which you can prevent with pre-signals).

KUDr · Post by **KUDr** » 15 Jul 2006 20:56

Tiberius: theoretically it can be YAPF bug related to the first station tile position (where you started to build the station from). If you can reproduce it without newgrf with only trunk (nightly) build i will appreciate that a lot. I am currently working on another bug (MP desync) caused by YAPF cache.

thanks, KUDr

mart3p · Post by **mart3p** » 17 Jul 2006 15:58

I have found a bug when using YAPF for road vehicles. Vehicles trying to find a depot, can be sent to an opponent's depot if that is nearest. In the attached test savegame, one of the AI's buses (green vehicle 4) is continually trying to enter one of my depots. It is unable to enter so loops around and tries again.

If I switch off YAPF for road vehicles, it fixes the problem.

This is a great way of sabotaging the opponent's road vehicles but I‘m sure it‘s not intended.

I’m using the nightly build at r5508.

Panzerfather · Post by **Panzerfather** » 20 Jul 2006 20:22

Got a bug which ends in a fatal error:

openttd: yapf/hashtable.hpp:228: void CHashTableT<Titem_, Thash_bits_>::Push(Titem_&) [with Titem_ = CYapfRailNodeT<CYapfNodeKeyExitDir>, int Thash_bits_ = 10]: Assertion `&slot.Find(new_item.GetKey()) == __null' failed.

Added the savegame, the game crashes around the 8th October.

mart3p · Post by **mart3p** » 22 Jul 2006 15:07

KUDr: While working on my patch to implement drive-through road vehicle stops, I came across a few problems with YAPF. Some, I have already reported in posts above, but I thought it might be useful for you to see the solutions I came up with. I'm not sure that my changes/hacks are the correct way to fix these problems, but thought they might at least show you where the problems are.

1. Road vehicles preferring bends (as reported above).
Making the cost for road bends YAPF_TILE_LENGTH + 2 seems to work ok. Of course it would be best to make '2' a 'road_curve_penalty' config setting.

2. Road vehicles finding opponents depot (as reported above).
I added a line to FindNearestDepot in yapf_road.cpp, that returns false if the depot found, is not owned by the vehicle's owner. It would be better to only search for the owner's depots in the first place but I couldn't see an easy way of doing that.

Code: Select all

 Node& n = Yapf().GetBestNode();
   TileIndex depot_tile = n.m_segment_last_tile;
   assert(IsTileDepotType(depot_tile, TRANSPORT_ROAD));
+  if (!IsTileOwner(depot_tile, (Owner)v->owner)) return false;
   Depot* ret = GetDepotByTile(depot_tile);
   return ret;

3. Multistop problem.
In function YapfRoadVehDistanceToTile in yapf_road.cpp, the scaling of the distance returned by the function is 10 times what it should be. There is a TODO note already in the code regarding this.

Code: Select all

// TODO: change road YAPF unit from 10 to YAPF_TILE_LENGTH

To determine which road stop bay to use, Multistop uses the returned distance plus a weighting based on the number of vehicles already using the bay. Because the returned distance is 10 times the correct value, this has the predominant effect. Replacing the values of 10 with YAPF_TILE_LENGTH, fixes the problem.

4. The goto depot command is not always working for road vehicles.
This is not a YAPF problem but effects YAPF's depot finding. See bug report at: http://bugs.openttd.org/task/249 There is a note in the code in SetOriginFromVehiclePos:

Code: Select all

// sometimes the roadveh is not on the road (it resides on non-existing track)
// how should we handle that situation?

- this bug is why it happens.

Darkvater · Post by **Darkvater** » 01 Aug 2006 13:00

Thank you for the comment on SourceForge mart3p. I will leave this up for KUDr to look over and fix when he comes back.

Please also close any bugreports then.

Luckz · Post by **Luckz** » 02 Aug 2006 11:46

mart3p wrote:2. Road vehicles finding opponents depot (as reported above).
I added a line to FindNearestDepot in yapf_road.cpp, that returns false if the depot found, is not owned by the vehicle's owner. It would be better to only search for the owner's depots in the first place but I couldn't see an easy way of doing that.

But what if you enable the option to let vehicles actually use other players' depots? IMO it would be advisable to have it check for that option.

mart3p · Post by **mart3p** » 02 Aug 2006 16:28

Luckz: I presume you are referring to the "Allow depot sharing" option for the subsidiaries patch in the MiniIN. My bug report above is relating to the trunk code which doesn't have this option.

But thanks for pointing this out anyway. I will check if depot sharing is working using YAPF in the MiniIN and I'll post a MiniIN fix if a change is required.
Edit: I've checked the MiniIN code and YAPF depot finding does check the "depot sharing" option.

Darkvater · Post by **Darkvater** » 14 Aug 2006 22:37

mart3p wrote:2. Road vehicles finding opponents depot (as reported above).
I added a line to FindNearestDepot in yapf_road.cpp, that returns false if the depot found, is not owned by the vehicle's owner.

r5897

mart3p wrote:4. The goto depot command is not always working for road vehicles.
This is not a YAPF problem but effects YAPF's depot finding

r5898

I've added these two fixes as KUDr seems away for a very long time and didn't feel appropiate to wait any longer as there are working fixes for these. When you (KUDr) get back, you can refine these commits if you like.

Thank you mart3p for the patches.

suikerpluimpje · Post by **suikerpluimpje** » 22 Aug 2006 14:18

I've bin using yapf for a savegamae with more then 800 vehicles, and the started to slow down after about 750 vehicles.

With the normal pathfinding meganism, the game would have been unplayable.

I realy like YAPF.

Now, the only thing I need to do is find a way to create highway's...

KUDr · Post by **KUDr** » 26 Aug 2006 23:32

mart3p: thanks a lot for your hard work on YAPF. Just fixed the
2. Road vehicles finding opponents depot (r6160)
so, that it doesn't fail to find the depot if opponent's depot is closer.

the rest I'll check soon (hopefully)

Edit: done (r6162-3, r6164)

Transport Tycoon Forums

YAPF - Testers needed!

Who is online