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