Config
Log for #openttd on 29th August 2021:
Times are UTC Toggle Colours
10:32:31  *** tokai has quit IRC
10:42:09  <Samu> alright, so initial testings when there's more than one docking tile reveals that the penalty is too low for having ships separate
10:43:55  <Samu> docking tile penalty needs to be higher for separating ships, but lower for avoiding ship is lost
10:44:03  <Samu> double-edged sword
10:44:53  <Samu> we can't have both
10:54:05  *** tokai has joined #openttd
10:54:05  *** ChanServ sets mode: +v tokai
11:00:50  *** tokai|noir has quit IRC
11:13:58  <Samu> I tested a penalty of 400, it's better for ship separation
11:14:06  <Samu> and worse for ship is lost
11:14:19  <Samu> ba dum tss
11:14:47  *** virtualrandomnumber has joined #openttd
11:15:07  *** virtualrandomnumber has quit IRC
11:15:31  *** gelignite has joined #openttd
11:15:57  *** D-HUND is now known as debdog
11:23:58  <Samu> funny bug I just found
11:24:33  <Samu> on a multidock station, if i remove one of the docks while there's a ship loading/unloading, it still continues to load/unload
11:34:35  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick opened issue #9521: [Bug]: on a multidock station, if i remove one of the docks while there's a ship loading/unloading, it still continues to load/unload https://git.io/JE6tY
11:51:55  <TrueBrain> so basically Samu , you made #9514 without testing for multi-docks at all?
12:01:08  *** tokai|noir has joined #openttd
12:01:08  *** ChanServ sets mode: +v tokai|noir
12:07:56  *** tokai has quit IRC
12:08:02  <debdog> I wonder why the suggestion to alter the commit 31db4f8 so it acts only on ports with more than one docking point is not considered? is that somehow not feasible?
12:17:40  <Samu> I didn't feel the need to test multi-docks for #9514
12:18:43  <Samu> I thought splitting ships was working, so I didn't test that
12:19:21  <Samu> main focus with the PR was ship is lost
12:19:31  <Xaroth> Always test more than you think needs testing.
12:21:23  <Samu> it kinda is working, but only in certain situations
12:21:44  <Samu> a higher penalty would make it more reliably separate ships
12:27:05  <Samu> btw, https://github.com/OpenTTD/OpenTTD/pull/8009#issuecomment-591030106
12:27:34  <Samu> tested 25 Feb 2020
12:27:46  <Xaroth> "kinda working" means "mostly broken" :P
12:28:01  <Samu> so, I tested it in the past
12:31:20  <Xaroth> before or after your changes?
12:34:01  <Samu> which changes, the one from #8009?
12:38:44  <Samu> debdog, can you link me that commit you mentioned
12:38:57  <Samu> apparently I can't manage to find it
12:40:15  <Samu> ah, nevermind, found it
12:40:21  <Samu> https://github.com/OpenTTD/OpenTTD/commit/31db4f8d5ef61e49e006b39864e38584fc2f485d
12:40:38  <debdog> https://github.com/OpenTTD/OpenTTD/commit/31db4f8d5ef61e49e006b39864e38584fc2f485d
12:40:41  <debdog> right
12:42:21  <Samu> your suggestion seems good, but there's not a way to count how many docking tiles there are yet, I may take a look
12:43:04  <Samu> there's a TileArea, so i guess i can iterate the tile area looking for docking tiles that belong to a station, hmm
12:43:15  <Samu> get a count out of it
12:43:21  <debdog> how does the pf know there're more docking points?
12:47:06  <Samu> i think, the pf is given a destination tile, this destination belongs to a tile area where the docking tiles are located. But it's a little bit confusing when there are multiple points for destination, will investigate better
12:47:36  <Samu> it tries to give the closest destination manhathan dist based
12:47:45  <Samu> brb
12:49:07  <Samu> m_destTile      = CalcClosestStationTile(m_destStation, v->tile, STATION_DOCK);
12:50:03  *** Wolf01 is now known as Guest5722
12:50:05  *** Wolf01 has joined #openttd
12:51:50  <Samu> https://github.com/OpenTTD/OpenTTD/blob/master/src/pathfinder/pathfinder_func.h#L16-L48
12:53:50  <Samu> the tile given out of there may not even be a docking tile, so this is the part I get slightly confused. It actually finds the real destination but how? Need to find out
12:54:46  *** Guest5722 has quit IRC
12:57:14  <Samu> https://user-images.githubusercontent.com/43006711/75067102-395e9d00-54e4-11ea-865d-618cd8e8631e.png
12:57:29  <Samu> for this multi-dock, the tile area is that white rectangle in the image
12:57:40  <Samu> only 2 of those tiles are docking tiles
13:04:55  <debdog> hmm
13:09:00  <debdog> so, it's either magic or the project accidentally created an AI :)
13:28:40  <Samu> i can't figure this out
13:28:55  <Samu> if only I could use debug signals or something to see what's happening
13:32:25  <Samu> okay, i got to a point where the pf finds the 2 docking tiles, it has the cost of both
13:32:56  <Samu> it decides to chose the cheapest, which is actually a dock without ships in there
13:33:56  <Samu> that's fine and all, but my question still remains... how did it search for them, considering the given destination tile is not a docking tile
13:34:17  <Samu> was it a blind search?
13:36:06  <Samu> and how did it manage to find the 2 docking tiles in the same pf instance? why didn't it quit right away right when it found the first one?
13:36:26  <Samu> i still don't understand yapf fully :(
13:43:53  *** andythenorth has joined #openttd
13:46:04  <andythenorth> well
13:50:26  <Samu> https://i.imgur.com/t8z3UpZ.png
13:50:37  <Samu> this is the situation I observe
13:51:01  <Samu> that ship #4 already knows it's going to the dockign tile 2
13:51:46  <Samu> m_destTile is not a dockng tile
13:52:25  <Samu> what happens between m_destTile and docking tile 1/2 is unknown to me, I just don't get it
14:03:35  *** Tirili has joined #openttd
14:41:49  <Samu> after further investigation, that m_destTile is being used for estimation calculation costs, it is NOT the real destination
14:42:17  <Samu> but the pf is being based on the lowest estimation costs though
14:42:58  *** glx has joined #openttd
14:42:58  *** ChanServ sets mode: +v glx
14:44:28  <Samu> going past that point, estimation costs increase! it really seems like it just keeps adding nodes blindly until one of it is the real destination, a docking tile
14:45:49  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9514: Change: Cap docking tile occupancy penalty to a max of one ship https://git.io/JE6QZ
14:45:52  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed pull request #9514: Change: Cap docking tile occupancy penalty to a max of one ship https://git.io/JEgDG
14:47:28  <TrueBrain> debdog: indeed it is a bit weird that the amount of available docking points is not considered in the penalty
14:47:42  <Samu> estimation doesn't serve as a guide from that point on, but more like the opposite effect, it's directing the path in a circle around m_destTile until one happens to be the docking tile
14:47:44  <TrueBrain> but it shouldn't be a real cause for a ship to be considered lost or not .. it just makes the PF work a tiny bit more :P
14:48:22  <TrueBrain> for every ship ~40 tiles more are considered, so it shouldn't be that big of a deal
14:48:30  <TrueBrain> (for every ship docked)
14:48:54  <Samu> TrueBrain, it's not a "tiny bit more", it's the difference between 3000 search nodes to 14000 search nodes, I addressed that in #8001
14:49:25  <TrueBrain> which just repeats the sta

Powered by YARRSTE version: svn-trunk