IRC logs for #openttd on OFTC at 2021-08-29
⏴ go to previous day
02:40:25 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:02:01 *** Wormnest has quit IRC (Quit: Leaving)
03:36:45 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
04:08:08 *** Gustavo6046 has joined #openttd
04:33:54 *** Gustavo6046_ has joined #openttd
04:34:06 *** Gustavo6046 has quit IRC (Read error: Connection reset by peer)
04:34:06 *** Gustavo6046_ is now known as Gustavo6046
05:20:42 *** Ttech has quit IRC (Remote host closed the connection)
06:24:26 *** ChanServ sets mode: +v tokai
06:31:00 *** Gustavo6046 has quit IRC (Read error: Connection reset by peer)
06:31:04 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
06:31:30 *** Gustavo6046 has joined #openttd
06:55:43 *** sla_ro|master has joined #openttd
07:05:56 *** Progman has joined #openttd
07:32:47 *** andythenorth has joined #openttd
08:06:27 *** WormnestAndroid has quit IRC (Remote host closed the connection)
08:06:40 *** WormnestAndroid has joined #openttd
09:02:19 *** andythenorth has quit IRC (Quit: andythenorth)
09:39:43 *** iSoSyS has quit IRC (Remote host closed the connection)
09:49:15 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #9509: [Bug]: set signals from another railroad system https://git.io/JEYmY
10:25:35 *** tokai|noir has joined #openttd
10:25:35 *** ChanServ sets mode: +v tokai|noir
10:32:31 *** tokai has quit IRC (Ping timeout: 480 seconds)
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:54:05 *** ChanServ sets mode: +v tokai
11:00:50 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
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: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: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:34 <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 (Ping timeout: 480 seconds)
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: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: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: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:49:07 <Samu> m_destTile = CalcClosestStationTile(m_destStation, v->tile, STATION_DOCK);
12:50:03 *** Wolf01 is now known as Guest5722
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 (Ping timeout: 480 seconds)
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:09:00 <debdog> so, it's either magic or the project accidentally created an AI :)
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: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: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: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: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 statement: seems like something else is going on ;)
14:49:52 <glx> typical pf in open space :)
14:51:02 <TrueBrain> giving a PF a penalty of 3 tiles for each docked ship, should result in a few extra tiles to be considered
14:51:09 <TrueBrain> the issue is not in the penalty if it does
14:56:38 <Samu> that's exactly what's happening, it's checking "half the map" just because of a simple 300 cost
14:57:10 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
14:58:07 <TrueBrain> you seem to be confusing cause with causality
14:58:32 <Samu> i wish i could print debug signals so that I could show it to you
14:58:36 <glx> maybe it just discards the "too high" valid path, and doesn't find any other valid path
14:59:19 *** Gustavo6046 has joined #openttd
15:03:18 <glx> anyway pf probably doesn't know/use the number of docking tiles when it decides to discard
15:04:27 <glx> (but I'm not an expert in pathfinding)
15:11:19 <TrueBrain> "Checks whether the tile is marked as a dockling tile."
15:13:07 <glx> at least finding if there's only one docking tile should not be too hard (size of the tile area is 1 in this case I think)
15:13:12 <TrueBrain> lol, okay, how the docking penalty was implemented has a consequence I think was not considered :D
15:13:19 <TrueBrain> I am guessing the biggest problem happens with oilrigs :P
15:13:44 <TrueBrain> glx: there are always two docking tiles for a dock :D I did not know that, but .. yeah
15:14:12 <glx> oh I though only end tile was valid
15:14:27 <TrueBrain> reading the PR that made this change, suggests otherwise
15:14:35 <TrueBrain> I haven't tested it, just going by what others wrote :)
15:15:27 <TrueBrain> I know, I should use my router for this
15:15:37 *** Speeder_ has joined #openttd
15:15:50 * andythenorth needs some inspiration
15:17:19 <TrueBrain> so two things seem wrong by a first glance .. first is the "count = 1" .. it basically overshoots the cost in all cases
15:17:24 <TrueBrain> I think that should be "count = 0"
15:17:38 <TrueBrain> but second, not less important .. so many more tiles return true on "IsDockingTile"
15:19:30 <TrueBrain> owh, okay .. IsDockingTile are all the tiles around an oilrig
15:19:47 <TrueBrain> that is a lot of penalty being added to path from there
15:20:26 <TrueBrain> pretty sure that is fully unintentional :)
15:22:54 <TrueBrain> and indeed, the docking penalty doesn't resolve "ship is lost" in many use-cases :)
15:23:19 *** Speeder has quit IRC (Ping timeout: 480 seconds)
15:23:50 <TrueBrain> things I did not want to know about the pathfinder :P
15:32:42 *** sla_ro|master has quit IRC ()
15:35:50 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9522: Fix: pathfinders always tried to avoid docking tiles (even if nothing was on them) https://git.io/JEieV
15:36:02 <TrueBrain> debdog: I think ^^ addresses your issue. At least, the supplied savegame works as expected for me now
15:36:49 <TrueBrain> glx: in short summary, more people do not understand our PF and did some things it is not build for :P
15:37:09 <glx> is there anyone understanding our PF ?
15:39:38 <TrueBrain> I do understand how it works in concept; I helped writing / wrote earlier PFs of OpenTTD :P
15:39:43 <TrueBrain> just the C++ magic is a bit lost on me
15:39:54 <TrueBrain> luckily, that doesn't really matter for these kind of things
15:40:02 <TrueBrain> but overshooting your cost just results in terrible results
15:41:11 <TrueBrain> (it is important to realise that for heuristic based PFs, the penalty is added to the score of the parent tile .. so high penalties can propagate throughout your system)
15:41:47 <glx> at least allowing to go through free docking tile without a penalty should improve a lot
15:41:58 <TrueBrain> yeah, I really think that was unintended
15:42:25 <TrueBrain> I would also think that it is even unintended to do this calculation for anything not your destination
15:43:10 <TrueBrain> but I couldn't see an easy way to check if the docking tile belongs to your docking point
15:44:52 <glx> IsShipDestinationTile() can tell things
15:45:34 <TrueBrain> maybe that is even a better solution, to restrict it to destination dock only
15:45:39 <glx> because a docking tile can be shared by different stations
15:45:45 <TrueBrain> it doesn't really matter, honestly
15:46:00 <glx> so only a bit is stored in the map
15:46:25 <TrueBrain> I think using IsShipDestinationTile would be a bigger CPU hit with slightly better results than not doing it
15:46:48 <TrueBrain> but yeah .. using YAPF for Ship PF is just a terrible idea, and we all know that :D
15:47:37 <glx> well any A* in open space has issues
15:48:19 <TrueBrain> I do not agree. It works fine, as long as you can calculate cost correctly, and estimate the estimation kinda
15:48:34 <TrueBrain> I mean, AIs use it to make train routes, and that works mostly okay
15:48:48 <glx> yeah cost estimation is hard
15:49:00 <TrueBrain> the open space is not the real issue; the restrictive landscape kinda is :p
15:49:13 <TrueBrain> I would argue that A* is designed for open space even :D
15:49:45 <TrueBrain> but we kinda expect a dynamic result, where ships adjust to the changes happening, including where other ships are etc
15:50:07 <TrueBrain> A* (and mesh-based) PFs are really good in static surroundings
15:50:44 <TrueBrain> but it also seems the ship PF is not caching anything?
15:51:38 <TrueBrain> CYapfSegmentCostCacheNoneT
15:51:43 <TrueBrain> yeah, seems no caching is done
15:53:20 <nielsm> I think caching for open area pathfinding is difficult
15:53:49 <TrueBrain> you kinda want to make "routes", cache does, and reuse them as much as possible
15:53:55 <nielsm> you'd probably need to somehow split the water areas into "seas" and "lakes", some kind of BSP
15:53:59 <TrueBrain> we can explain that with saying REALISM :P
15:55:03 <nielsm> flood fill and run a dilute filter to discover large bodies of water, perhaps
15:55:11 <glx> rivers and canals are probably easy to cache, but they are not the cpu intensive part of pf
15:55:13 <nielsm> but that's expensive and the world is dynamic
15:55:43 <TrueBrain> recalculating can be expensive, yeah
15:55:47 <TrueBrain> similar with a mesh-based approach
15:56:49 <TrueBrain> I wonder if we can cheat, and add virtual buoys in the middle of rivers, lakes, etc
15:56:54 <TrueBrain> and navigate via those
15:56:58 <TrueBrain> a slightly longer trip for ships
15:57:04 <TrueBrain> but again, I can just say: REALISM :P
15:57:55 <glx> btw I don't remember getting ship is lost for missing locks
15:58:29 <TrueBrain> when do we trigger "ship is lost" .. is that only when the PF aborts because it visited too many tiles?
15:58:44 <nielsm> have the ships store a list of virtual buoys as it navigates its route (maybe every 10-20 tiles travelled) and try to follow those next time
15:59:32 <nielsm> maybe do some optimization in post, test if there is a clear line between pairs one apart in the list, and see if that would be shorter
15:59:46 <andythenorth> water industries in small lakes
16:00:13 <TrueBrain> either way, my PR should address most of the weirdness reported for now :P
16:03:22 <TrueBrain> I just love how YAPF is just NPF with a lot of C++ templating :P
16:03:33 <TrueBrain> not a bad thing, just I hate C++ templating .. impossible to find anything :D
16:04:29 <TrueBrain> okay, so "ship is lost" is reported when it considered more than 10k nodes .. which are tiles + exitdir .. so I guess ~2k tiles? Something like that
16:04:41 <TrueBrain> or if it tried all possible solutions and the destination was not found
16:04:44 <TrueBrain> that sounds sane enough
16:05:30 <TrueBrain> so a missing lock -should- (but I did not test this) also trigger "ship is lost" instantly
16:06:44 <glx> well we did test missing locks during new network testing ;) but I can't remember if I got the notice or not
16:07:02 <TrueBrain> I was also thinking I didn't get the memo
16:07:09 <TrueBrain> but I just tested it, and it does tell me instantly the ship is lost
16:07:13 <TrueBrain> what is annoying, it only tells you once
16:07:29 <TrueBrain> and it doesn't tell it anywhere else other than in the news
16:07:34 <TrueBrain> while it does float around the destination
16:07:45 <TrueBrain> it would help if it says in the status of the vehicle too: "clueless"
16:08:48 <TrueBrain> so currently if you miss the news the first time, you won't really notice it, as it will go towards the dock .. but never get there.
16:12:41 *** ChanServ sets mode: +v tokai
16:18:16 <Samu> starting with count = 0 is a good idea!
16:19:30 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
16:21:39 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #9523: [Bug]: "ship is lost" is only reported via news https://git.io/JEimw
16:21:50 <TrueBrain> glx: there, made it a ticket :)
16:22:41 <TrueBrain> especially 8 and 9 is what I walked into
16:23:51 <TrueBrain> seems like a trivial thing to fix
16:23:57 <TrueBrain> mostly figuring out what works best :)
16:24:06 <TrueBrain> I updated my comment with a suggestion
16:24:52 <TrueBrain> also true for RVs ofc
16:29:44 <Samu> Finally! I was able to build debug signs via YAPF
16:34:31 <Samu> and looking at viewport 1 the nodes it visited are already past the dock
16:35:04 <Samu> gonna test with count = 0
16:37:08 <Samu> oh crap, ship still lost because i got a ship in the dock, brb
16:40:47 <andythenorth> currently I am totally uninspired to do grf
16:40:50 <andythenorth> but I would like to be :)
16:41:04 <andythenorth> just got nothing interesting enough to do right now
16:41:07 <andythenorth> and lots of unfinished things
16:41:25 <peter1138> Is it beer o'clock?
16:42:13 <Xaroth> Somewhere, undoubtedly.
16:42:13 <andythenorth> I just opened one
16:42:22 <peter1138> andythenorth, coincidence eh
16:43:24 <peter1138> Bit overcast here now, even a few specks of rain on the way home.
16:43:34 * andythenorth can't actually see any sun
16:43:37 <andythenorth> but morally speaking
16:49:07 <peter1138> I have no morals and therefore no sun.
16:49:52 *** Wormnest has joined #openttd
16:50:08 * andythenorth could do some code quality crap
16:50:14 <andythenorth> maybe merge a few WIP branches
16:50:16 <andythenorth> something to do eh
16:50:37 <peter1138> Gotta play this 25 year old game again.
16:51:33 <andythenorth> is it multiplayer?
16:51:44 <andythenorth> hmm I have to do stuff though
17:01:48 <peter1138> "petererer becomes bored with life"
17:02:02 <peter1138> Is Quake multiplayer. Hmm....
17:05:14 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick commented on pull request #9522: Fix: pathfinders always tried to avoid docking tiles (even if nothing was on them) https://git.io/JEiWu
17:05:33 <nielsm> the new quake port to a new engine does have multiplayer, but only with itself, not with any classic quake-derived quake version
17:10:40 <peter1138> That's okay, OpenTTD doesn't have multiplayer with TTD either.
17:13:39 <peter1138> That would be a weird mashup
17:35:16 *** sla_ro|master has joined #openttd
17:41:20 <Samu> #9522 addresses something I addressed in #8009 but in just a simple manner, so it's all good
17:41:35 <Samu> but I went further still :(
17:43:17 *** gelignite has quit IRC (Quit: Stay safe!)
17:51:06 *** Gustavo6046 has quit IRC (Remote host closed the connection)
17:51:15 *** Gustavo6046 has joined #openttd
18:16:45 *** tokai|noir has joined #openttd
18:16:45 *** ChanServ sets mode: +v tokai|noir
18:21:07 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
18:24:10 *** tokai has quit IRC (Ping timeout: 480 seconds)
18:37:21 <TrueBrain> < 10% of OpenTTD sessions are via TURN now
18:37:36 <andythenorth> I don't actually know if that's good or bad :)
18:37:42 <andythenorth> but I wanted to be encouraging
18:37:49 <TrueBrain> we pay for the traffic over TURN :)
18:37:54 <TrueBrain> but I appreciate your reaction :)
18:38:55 <TrueBrain> only 8 timeouts (where 20 seconds passed to wait for a connection); most likely people not reacting to the "allow relay?" popup
18:39:10 <TrueBrain> 2 times where it failed to find any means to connect 2 people .. no clue what can cause that
18:39:31 <TrueBrain> and 75 times someone retried a connection before the current one was established / failed .. this is most likely people that don't appreciate the 3 second wait they can have if STUN fails :P
18:39:43 * andythenorth tries to dig up some grf motivation :)
18:39:45 <TrueBrain> of the ~500 attempts
18:40:00 <TrueBrain> so that looks promising
18:40:53 <TrueBrain> the only weird stat is that 30 (out of the 300) server attempts failed because the server closed before it finished the initial server probe
18:41:11 <TrueBrain> basically, someone starts a server and stops it before they see their invite-code
18:45:33 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9522: Fix: pathfinders always tried to avoid docking tiles (even if nothing was on them) https://git.io/JEiKY
18:48:34 <DorpsGek> - Update: Translations from eints (by translators)
18:51:57 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9522: Fix: pathfinders always tried to avoid docking tiles (even if nothing was on them) https://git.io/JEi6q
18:52:15 <TrueBrain> I hope that wording makes a bit sense .. explaining what the PF can be a bit tricky ;)
18:54:40 <TrueBrain> and I just edited, but LordAro , ship PF doesn't do caching
18:55:37 *** NGC3982 has quit IRC (Ping timeout: 480 seconds)
18:56:47 <Samu> there is caching for ships
18:56:55 <Samu> unless you mean some other type of cache
19:03:49 *** NGC3982 has joined #openttd
19:05:58 <TrueBrain> owh boy ... the more I look at the ship PF ...
19:06:06 <TrueBrain> when it is within 16 tiles of the destination
19:06:10 <TrueBrain> it checks every tile for a better route
19:06:27 <TrueBrain> I cannot really tell if that was intended or not
19:11:12 <glx> common path to near of final dest, then the actual docktile can be checked later ?
19:11:29 <TrueBrain> it seems like that was more the intention
19:11:37 <TrueBrain> but .. yeah .. bit of guesswork is involved :)
19:11:39 <Samu> that's the ship cache! Basically every 25 hops (usually tiles), the ship follows the cache. Once it's 16 hops closer to the goal, it won't cache it
19:12:01 <Samu> and ask the pathfinder every hop
19:12:26 <glx> but it doesn't use pf "internal" cache then (because for ship pf it's none)
19:12:27 <TrueBrain> the PATH is "cached". The PF doesn't do caching for ships
19:12:47 <TrueBrain> and the path-length is 32
19:16:11 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9522: Fix: pathfinders always tried to avoid docking tiles (even if nothing was on them) https://git.io/JEi1u
19:16:36 <TrueBrain> might help to understand why the image "doesn't look at bad", but for the PF it is a lot more :P
19:19:38 *** gelignite has joined #openttd
19:28:50 <Samu> it's 24677 "x" signs vs 10309 "x" signs
19:29:06 <Samu> just for a 300 penalty difference
19:35:09 <Samu> the way that commit is named... "Avoid caching end of ship path, to allow penalties to apply"
19:35:23 <Samu> ... makes me think of #8009 again
19:37:28 <Samu> it kind of implies the penalties were not supposed to be added before the end of ship path
19:38:41 <Samu> or is it the other way around?
19:39:19 <TrueBrain> I wonder why the shipPF uses exitdir, and not trackdir ..
19:39:22 <TrueBrain> exitdir kinda only works for rails
19:39:45 <Samu> ship tracks are basically invisible rail tracks
19:40:10 <TrueBrain> hmm, road PF also does the same stuff .. what was the intention here
19:40:26 <TrueBrain> ah, yeah, that makes sense, road can only exit on the exitdirs
19:41:11 <TrueBrain> ah, right, as long as the curve penalties are wrong, it uses trackdir after all
19:41:17 <glx> exitdir indicates the orientation too
19:41:20 <TrueBrain> basically a lot of code for a case that is rarely used
19:41:28 <TrueBrain> glx: ships can move in 8 directions, not 4 :)
19:41:55 <glx> and can turn on a dime too :)
19:42:27 <TrueBrain> okay, I would say that 99% of the players use trackdir instead of exitdir
19:42:37 <TrueBrain> so someone just added a bunch of lines of code for something never really used :P
19:42:42 <TrueBrain> fine :) I can ignore it just fine :D
19:43:41 <TrueBrain> I was checking if the costs are at least consistent
19:43:49 <Samu> maybe it has something to do with hitting coasts and having to reverse?
19:43:56 <TrueBrain> that they appear to be .. so at least it is returning an optimum
19:44:20 <Samu> so the exitdir is not the trackdir?
19:44:35 <glx> exitdir depends on trackdir
19:46:17 <TrueBrain> I now really wonder how difficult it would be to use navigation meshes, and if it fixes anything :P
20:06:36 <TrueBrain> I wonder, is TrackDir important for ships ... as in, is there a way you can get to a tile only from a single direction?
20:06:47 <TrueBrain> euh .. let me rephrase:
20:06:53 <TrueBrain> is there a way to get on 2 parts of a tile that do not connect
20:07:04 <TrueBrain> with rails this is the case of course
20:07:34 <TrueBrain> can you make an aquaduct over water ..
20:07:46 <TrueBrain> guess that would be a clear scenario
20:08:14 *** gelignite has quit IRC (Quit: Stay safe!)
20:09:00 <glx> you can have aquaduct over water, it's called a bridge
20:09:39 <TrueBrain> okay, the ExitDir is there because it was the only one that existed initially
20:09:41 <glx> but it's of course handled by bridge magic
20:09:45 <TrueBrain> later on it was made the "rarely used" variant
20:10:29 <TrueBrain> hmm .. does the bridge magic for aqueducts teleport?
20:11:29 <glx> for pf only bridge ends are checked (and penalty is based on bridge length)
20:11:46 <TrueBrain> in that case we don't even need TrackDir, I think
20:11:54 <TrueBrain> that would heavily reduce the amount of nodes the PF checks
20:12:04 <TrueBrain> the estimation is always lower than the real cost
20:12:12 <TrueBrain> which means that the cost is never overestimated
20:12:29 <TrueBrain> and as long as we don't overshoot the cost from one direction which isn't overshot from another
20:12:38 <TrueBrain> there shouldn't be any issue
20:13:17 <Samu> the estimation is always lower than the real cost this is false
20:13:27 <TrueBrain> that in turn would mean we have a very lower chance of hitting the "ship is lost" isuee
20:15:31 <Samu> the target tile is the first one
20:15:40 <Samu> the others are the parent tiles
20:18:07 <Samu> tile 91793 is the docking tile 2 in the image
20:20:42 <Samu> the estimate cost is based on m_destTile on the picture, but the pf doesn't detect that as destination, and keeps walking more nodes until it gets to the docking tile
20:22:30 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:23:51 <Samu> the estimate cost go up past a certain point, past tile 92809 in this example, which gives me the idea the pf is now just blinding walking nodes until it detects the dokcing tile
20:24:51 <TrueBrain> I have no clue what you are on about. The estimation is a crows-distance; it would be difficult for the real cost to be lower than that .. but okay, so far the assert() I added also doesn't trigger, so shrug
20:27:07 <Samu> it's about how m_destTile is computed, somewhere in CalcClosestStationTile
20:27:55 <Samu> it gets a TileArea of the docking tiles, in which is 7x7 rectangle where only 2 of them are the real docking tiles
20:28:21 <Samu> m_destTile is the reference for computing the estimate cost
20:28:46 *** virtualrandomnumber has joined #openttd
20:28:56 *** virtualrandomnumber has quit IRC ()
20:29:00 <TrueBrain> pathfinder/yapf/../../misc/hashtable.hpp:222: Titem_& CHashTableT<Titem_, Thash_bits_>::Pop(const Tkey&) [with Titem_ = CYapfShipNodeT<CYapfNodeKey>; int Thash_bits_ = 10; CHashTableT<Titem_, Thash_bits_>::Tkey = CYapfNodeKey]:
20:29:04 <TrueBrain> this is why I don't like templates :P
20:29:39 <TrueBrain> I remember why I didn't like touching YAPF :D
20:41:41 <TrueBrain> lol, okay, so YAPF first calculates cost, then estimation. Bit odd, but sure, why not
20:44:54 <TrueBrain> the deeper I read into the YAPF, the more confused I get :P Not sure this is good for my health :D
20:45:06 <Samu> did you get an assert? not sure where you put your assert at
20:45:06 <TrueBrain> I am used that an A* first dismisses neighbours that are already on the closed-list
20:45:21 <TrueBrain> but it seems YAPF first calculates the cost and estimate, and after that checks if it is on the closed-list
20:45:40 <Samu> i prepared a savegame to test your assert
20:46:00 <Samu> can i upload it to your PR?
20:46:55 <TrueBrain> I wonder why it does it this way .. I miss a bit of high-level detail why these choices were made .. most likely with a good reason, but .. hmm
20:49:08 <TrueBrain> well, at least it seems we can get some extra performance out of YAPF if we like .. not sure if it is ever a bottleneck CPU-wise :D
20:49:42 <Samu> with the cache it's no longer an issue
20:49:58 <Samu> as long as max search nodes is still 10000 of course
21:03:47 *** Samu has quit IRC (Quit: Leaving)
21:13:10 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9522: Fix: pathfinders always tried to avoid docking tiles (even if nothing was on them) https://git.io/JEiAL
21:13:30 <TrueBrain> oof, reading back your own description sometimes make it clear that your head was way too much in the code, and not in the "wtf does this do" mode :P
21:14:16 <TrueBrain> and I am going to walk away from this C++ templating stuff. It makes my head hurt :(
21:33:51 *** sla_ro|master has quit IRC ()
21:37:46 *** jottyfan has joined #openttd
21:43:18 *** Progman has quit IRC (Remote host closed the connection)
21:44:20 <andythenorth> why is action 14 bool 1 if unchecked?
21:45:52 <andythenorth> more likely my code is wrong?
21:58:53 <andythenorth> let's go with 'my code is wrong' :)
22:05:23 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:26:19 *** andythenorth has quit IRC (Quit: andythenorth)
22:41:45 *** jottyfan has joined #openttd
22:56:09 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:05:59 *** Gustavo6046_ has joined #openttd
23:07:25 *** Gustavo6046 has quit IRC (Read error: Connection reset by peer)
23:07:26 *** Gustavo6046_ is now known as Gustavo6046
continue to next day ⏵
