IRC logs for #openttd on OFTC at 2024-09-24
⏴ go to previous day
00:31:14 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
00:38:01 *** akimoto has joined #openttd
01:01:37 *** Wormnest has joined #openttd
01:20:32 *** SigHunter has quit IRC (Remote host closed the connection)
01:21:33 *** SigHunter has joined #openttd
02:13:31 *** Wormnest has quit IRC (Quit: Leaving)
02:17:19 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
02:30:26 *** godbed_ has joined #openttd
02:33:39 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:33:49 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:45:26 <DorpsGek> - Update: Translations from eints (by translators)
05:09:34 *** keikoz has quit IRC (Ping timeout: 480 seconds)
05:30:50 *** akimoto has quit IRC (Ping timeout: 480 seconds)
06:06:44 <andythenorth> hmm, 10,300 lines in a python module
06:07:42 <andythenorth> it's not a god object though, it's a LOT of subclass definitions from a base class
06:38:04 *** greeter has quit IRC (Ping timeout: 480 seconds)
07:04:54 *** greeter has joined #openttd
08:08:54 <peter1138> Look, I don't know how to write python, ok?
08:49:52 <LordAro> just think what you could achieve if you did
08:51:39 *** mindlesstux has joined #openttd
09:12:59 <andythenorth> I have considered splitting the module into multiple files and making a package 😛
09:57:10 <LordAro> "Multiplication got 8x faster compared to the one-bit-at-a-time implementation I had had before."
10:11:27 <_pruple> `//!!Warning (41): All action 1s are 4 or 6 bytes long.
10:11:27 <_pruple> //!!Warning (89): Action 1 declaring no sets.
10:11:27 <_pruple> 174 * 6 01 0f 00 \b22 \b1 \b19 // coastline, in normal tile order
10:11:27 <_pruple> //!!Error (51): Unexpected real sprite found.`
10:31:57 <xarick> I need to revert commit b and commit a, rebase, cherry pick updated commit a and then insert commit b and its conflicts
10:33:31 <xarick> i'm better off with a new branch i suppose
10:33:57 <LordAro> new branch & 2 cherry-picks
10:34:10 <LordAro> you can rename the branches afterwards if necessary for PR purposes
10:51:44 <peter1138> _pruple: It really doesn't.
10:53:58 <_pruple> but I like how "All action 1s are 4 or 6 bytes long" implies it understands the extended format exists, even as it fails to recognise it.
11:01:35 <peter1138> Ah yes, testing performance when the CPU is in a dynamic performance mode is not very helpful.
11:16:33 *** akimoto has joined #openttd
11:57:07 <andythenorth> fishfingers I think
12:00:39 <peter1138> Urgh, silly database transaction errors 😦
12:00:46 <peter1138> "Just retry the query"
12:17:17 <kuhnovic> xarick: I feel that your change adds quite a lot of additional complexity for hardly any gain. A pathfinder should be as generic as possible, and adding more logic just to cover some obscure niche cases is not the way to go. Especially since nothing is really broken in the use case you refer to, it's just a suboptimal result. As a mentioned in my comment on your PR, the ship PF is always going to
12:36:40 *** akimoto has quit IRC (Remote host closed the connection)
12:38:27 *** akimoto has joined #openttd
12:40:31 <_glx_> region pathfinder already handles properly I think, as it does pathfinding in reverse
12:44:29 <_glx_> but `CalcClosestStationTile()` could be improved for the `STATION_DOCK` case
12:45:54 <xarick> I was at one point suggested to make the low lvl pf to be able to work with multiple origins, much like the high lvl pf
12:46:42 <_glx_> that's another option yes
12:46:46 <xarick> so I did that, except that low lvl pf does it the other way around, it uses multiple dests instead
12:47:52 <xarick> a dest tile for the low lvl pf is an origin tile for the high lvl pf
12:48:28 <xarick> the added logic was to prevent recalculating the same tiles
12:49:39 <_glx_> low level could also run backward for ships, as for ships both forward path and backward path should be equivalent (definitely not true for road/rail)
12:52:18 <xarick> if 12206 ends up being accepted, the code for find nearest depot would be much simpler
12:52:36 <xarick> it would be based on that work
12:54:14 <xarick> it would place all of the players depots as possible destinations
12:55:27 <xarick> or possible origins for the high lvl pf
12:55:46 <_glx_> for me ship PF can already be useable with destination tiles put as origin, and v->tile as destination
12:56:09 <_glx_> that's how region PF does it
12:57:10 <_glx_> I don't see a need to pass destination tiles around
13:13:45 <peter1138> Is this the edge-case where the docking area covers is the whole map (but the only tiles are at the far corners) and the ship could be anywhere inside
13:14:42 <xarick> yes, but could be also applied to search closest ship depot
13:16:40 <xarick> (which does not exist as of yet)
13:17:39 <xarick> I have it working here locally, but not on a PR
13:18:04 <xarick> it's pending whether 12206 goes through
13:18:30 <xarick> seems not to be going anywhere 😦
13:25:36 <peter1138> It seems the wrong approach, yes.
13:25:50 <peter1138> There are 3 different paths
13:26:03 <peter1138> So running the path finder 3 times seems more logical.
13:26:40 <peter1138> (Of course that can be expensive so it's not that simple)
13:28:21 <kuhnovic> The pathfinder has to call the "am I at the destination"-check really often, so it makes sense to keep this check as lightweight as possible. Multiple destination tiles means you have to iterate over all of these tiles and calculate an estimate. This can really add up, especially if you have quite a large number of destination tiles.
13:32:21 <xarick> pf ususally prioritizes the nodes with the lowest estimate isn't it? but still...
13:32:33 <kuhnovic> Multiple origin tiles on the other hand is not really an issue, they are just added to the PF's node list as additional tiles to evaluate. The PF will pick the best one and starts expanding the search from there, unless suddenly a different origin tile becomes the best PF node, etc
13:33:56 <_glx_> and really, for ships it's not even a problem to do the pathfinding in backward
13:33:59 <kuhnovic> I will admit that the PF code and the PF-setup-code (adding origins, destinations, etc) is too intertwined, that can make things difficult
13:35:35 <kuhnovic> _glx_: Exactly. Searching backwards you always want to go back to the ship, which them becomes the one and only destination. And that makes the at-destination-check cheap.
13:35:36 <_glx_> but of course many of the internal ship pf functions need to be adapted for the backward handling
13:35:57 <kuhnovic> Well, the weather is turning shitty here now so soon I'll have a bit more time :p
13:38:06 <_glx_> though PF itself should be fine already, `ChooseShipTrack()` of course need some work for it
13:38:57 <kuhnovic> Yeah true. Reversing the path will be a bit annoying, trackdirs will need reversing too.
13:39:10 <kuhnovic> Not impossible, but not a two hour fix for sure
13:40:19 <xarick> first commit is cherry picked from 12206
13:40:56 <_glx_> it's often a matter of not focusing on a tiny part
13:43:11 <_glx_> when adding multiple "destination" handling, "destination" is just a word it doesn't have to be handled like a destination 🙂
13:45:17 <xarick> i might need to make static inline FindDepotData FindNearestDepot a bit more similar to CheckShipReverse, need to unify behaviour
15:04:37 <xarick> I had many ideas to workaround max_penalty
15:12:14 <xarick> one idea that was sound: completely skip high lvl pfing if a max_penalty is provided. A max_penalty is only provided when doing automatic servicing at the nearest depot. The max_penalty value is based on the low lvl pfer costs and can't be directly translated down from the high lvl pfer, as it uses whole different cost methods. By limiting this to only use the low lvl pfer, the max_penalty are
15:13:01 <xarick> HOWEVER.... this goes against the "unified behaviour" principle
15:59:30 <peter1138> Oh dear, another branch that is probably better rewritten than rebased.
16:22:37 *** Wormnest has joined #openttd
16:29:21 *** HerzogDeXtEr has joined #openttd
16:33:05 *** akimoto has quit IRC (Ping timeout: 480 seconds)
16:51:43 <peter1138> Fuck you Discord and your forced updates.
17:19:48 <_pruple> change for the sake of it 😄
17:51:59 <xarick> got a problem with SetIntermediateDestination
17:53:06 <xarick> or maybe not, maybe...
17:54:42 <xarick> I need the high lvl pf to relay back the entire path to extract the depot tile
17:57:30 <xarick> current behaviour, it only relays part of the path, it may not contain the information i need
18:11:07 *** ChanServ sets mode: +v tokai
18:18:09 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
18:42:01 <peter1138> Gnome shell, 18GB resident. Sure.
19:22:37 *** Flygon has quit IRC (Read error: Connection reset by peer)
19:26:08 <xarick> FindWaterRegionPath could be simplified a bit
19:26:34 <xarick> max_returned_path_length seems to always be the same
19:26:56 <xarick> NUMBER_OR_WATER_REGIONS_LOOKAHEAD + 1
19:50:30 <xarick> why isn't NUMBER_OR_WATER_REGIONS_LOOKAHEAD value set to 5
19:50:47 <xarick> i dont see it used anywhere else
19:55:56 <xarick> confuses the heck out of me
20:09:08 <xarick> how do I cast a bool to int?
20:11:12 <xarick> im trying this `for (int i = 1; i != NUMBER_OR_WATER_REGIONS_LOOKAHEAD; i += !find_closest_depot) {`
20:12:07 <xarick> visual studio doesn't give a warning
20:28:32 *** virtualrandomnumber has joined #openttd
20:29:13 *** virtualrandomnumber has quit IRC ()
20:29:40 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
20:49:13 <xarick> `if (is_intermediate_destination) pf.SetIntermediateDestination(high_level_path[std::min(static_cast<int>(high_level_path.size() - 1), NUMBER_OR_WATER_REGIONS_LOOKAHEAD - 1)]);`
20:49:53 <xarick> i can make it slightly less ugly
20:53:50 <xarick> oh, std::min<int> exists
21:00:09 <xarick> uh i think im doing this the wrong direction
21:11:45 <xarick> nop, it's the right direction
21:19:08 *** Etua has quit IRC (Remote host closed the connection)
21:22:49 <peter1138> Can I get my environment to stop hinting about using trailing return types...
21:33:48 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:34:54 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:30:35 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:57:09 *** Wormnest has joined #openttd
23:11:59 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
23:16:16 *** Smedles has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵