IRC logs for #openttd on OFTC at 2024-09-30
⏴ go to previous day
01:35:44 *** Wormnest has quit IRC (Quit: Leaving)
02:15:54 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
02:27:04 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:01:15 *** D-HUND is now known as debdog
04:47:12 <DorpsGek> - Update: Translations from eints (by translators)
05:12:23 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:16:03 <DorpsGek> - Add: summary for week 39 of 2024 (by OpenTTD Survey)
08:58:30 *** mindlesstux has joined #openttd
09:36:49 <peter1138> Hmm, so JGRPP changes AddStringForMapping but whatever reason.
09:37:38 <xarick> _glx_: this example is a little bit misleading
09:41:41 <xarick> oh, and the other line after
09:42:48 <peter1138> That's probably meant to be two examples.
09:43:07 <peter1138> There's no point in your first line without an argument.
09:43:27 <xarick> local vehs_in_depot = GSVehicleList(GSVehicle.IsInDepot);
09:43:27 <xarick> local IsType = function(vehicle_id, type)
09:43:27 <xarick> return GSVehicle.GetVehicleType(vehicle_id) == type;
09:43:28 <xarick> local road_vehs = GSVehicleList(IsType, GSVehicle.VT_ROAD);
09:51:01 <xarick> yeah, I noticed they're 2 examples
09:51:15 <xarick> the 2nd example is the one that's misleading
10:25:02 <xarick> can you make savegaming use multiple threads for compressing?
10:25:45 <xarick> or is it too hard to do
10:32:33 <peter1138> 2.7ms to map 2,201 strings on load. So speed isn't the issue.
10:33:24 <_glx_> Savegame compression and writing is already in another thread
10:39:19 <peter1138> To use lzma's multithread code, you'd need to replace the call to lzma_easy_encoder() at the least I'd think.
11:11:33 <xarick> lzma_stream_encoder_mt
11:14:30 <xarick> not sure how helpful that is
11:15:18 <xarick> then there's decoding... so... maybe it won't work
11:16:16 <xarick> meanwhile, my testings of yesterday night have resulted in no asserts!
11:17:26 <xarick> i have a new type of testing
11:17:53 <xarick> 70000 ships searching for nearest depot, but with a penalty
11:18:45 <xarick> bam! asserted immediately
11:19:20 <xarick> probably hlpf penalty related
12:59:24 <xarick> im getting a very strange case of low level pf not finding a path
12:59:33 <xarick> that has previously found
13:00:48 <xarick> did i break binary heap?
13:11:23 <xarick> service orders triggered a bug in my code... 🙂
13:16:03 *** keikoz has quit IRC (Ping timeout: 480 seconds)
13:17:36 <xarick> nop, it's not the binary heap
13:19:07 <xarick> it's my assertive code that is lacking :p
13:24:37 *** mindlesstux has quit IRC (Read error: No route to host)
13:32:39 <xarick> how do I backup an order
13:33:30 <xarick> get current ships order, destination, type, etc..., test a pathfinder command which updates the orders, but then revert back
13:36:39 *** mindlesstux has joined #openttd
13:36:52 <xarick> maybe i can workaround this
13:44:09 *** mindlesstux has quit IRC (Read error: Connection reset by peer)
13:49:47 <xarick> I'm so slow... took 2h30m to solve this issue
13:51:47 *** mindlesstux has joined #openttd
13:56:30 *** mindlesstux is now known as Guest5004
13:56:30 *** Guest5004 has quit IRC (Read error: Connection reset by peer)
13:56:31 *** mindlesstux has joined #openttd
14:12:02 *** mindlesstux has quit IRC (Read error: No route to host)
14:41:08 *** HerzogDeXtEr has joined #openttd
14:43:40 <xarick> automatic servicing being a pita :=)
14:50:41 <kuhnovic> I was looking at it yesterday evening for a bit, and yes, it is indeed a pain
15:01:24 <_glx_> and it's not better for trains with path signals
15:13:32 <xarick> i suspect the trouble comes from when the path_cache is empty
15:13:52 <xarick> and chooseshiptrack at that point picks a random track...
15:15:26 <xarick> it's so slow to debug 70000 ships
15:15:43 <kuhnovic> That's why I generally stick to one, maybe a handful
15:19:55 <xarick> > With my changes, the ship will never look for a new depot if it's already heading for a depot.
15:19:55 <xarick> I'm experimenting with sticking with the same path, by actually repeatedly returning the same path every day CheckIfShipNeedsService is called
15:21:50 <kuhnovic> There is a problem with that. The ship has the liberty to go outside of the regions returned by the HL PF. But if you then call the ship from such a region your path might change. In some cases you can end up going back-and-forth.
15:22:36 <xarick> my understanding is that the cost can only go lower if the path returned still overlaps the previous returns
15:23:17 <xarick> so, if it was less than 2000 the first time when the ship was still far away, the next times, would only get lower
15:23:27 <kuhnovic> The solution I'm playing with now is to just check if the depot is still reachable using the HL PF only. That is fairly simple actually. The hard part is determining when to give up, otherwise the ship might end up sailing across the entire map just because there still is a path.
15:24:18 <xarick> so no dummy order to cancel the go to depot should happen
15:25:09 <kuhnovic> xarick: Yes but there lies the problem: your path will not overlap if called at the "wrong time". And checkIfShipNeedsService is called at the wrong time, because the ship might be outside of the HL path.
15:25:35 <kuhnovic> xarick: It should if the depot is unreachable or too far away
15:28:44 <kuhnovic> The regular ship pathfinding mechanism uses the path cache to make sure the ship travels from region-on-HL-path to other region-on-HL-path without doing PF calls in between. But the ship servicing is time based, it doesn't wait for the ship to finish its cached path.
15:57:39 <xarick> just figured something
15:59:54 <xarick> ship is at the edge of a region, hlpf found a path in the region the ship is at, but llpf pathes to the adjacent region, results in a path_cache.clear() as the last command
16:00:09 <xarick> then it checks if the cache is clear
16:00:26 <xarick> and generates a random track 😦
16:01:01 <xarick> insufficient checks perhaps
16:01:19 <xarick> or there should be no random path choice
16:01:45 <xarick> and use the track chosen from the llpf
16:02:38 <xarick> i need to dig the PR history for this
16:04:42 <xarick> it decides to get a random track 😦
16:06:13 <xarick> I remember 279 was a fix to some edge case already 😮
16:14:13 *** Wormnest has joined #openttd
16:21:56 <xarick> the path was never cached at any point
16:23:03 <xarick> it did the checks whether to cache at some point, but always returned path_cache.clear()
16:26:37 <xarick> I'm confused, i need to re-do the tests 😦
16:41:48 <kuhnovic> Keep in mind that the PF always returns the next track(dir). The cache just stores any subsequent dirs. So an empty cache is perfectly ok.
16:53:33 *** gelignite has joined #openttd
16:53:37 <xarick> trying to make sense of what's happening here
16:54:07 <xarick> the ship is behind the building, going into NE direction
16:54:23 <xarick> red line is the hlpf choice
16:54:31 <xarick> green line is the llpf choice
16:54:44 <xarick> ship is at the edge of the region
16:55:44 <xarick> now, what tracks did it pick...
16:59:37 <xarick> stoopid random choice sometimes makes track == track2
16:59:45 <xarick> so difficult to debug this way
17:20:27 <xarick> **first call**: all depots, 1 region 65,85 on hlp, depot at 64,85 chosen by llpf, path_cache is filled, return track from cache.
17:20:27 <xarick> **second call**: depot at 64,85, 2 regions 65,85 + 64,85 on hlp, depot at 64,85 chosen by llpf, path_cache is not filled, return random track due to empty cache.
17:21:15 <xarick> assert(track1 == track2) fails sometimes, sometimes not, thx to random
17:24:21 <xarick> node_water_patch_on_high_level_path is always false on first call
17:24:21 <xarick> node_water_patch_on_high_level_path is always true on second call
17:30:07 <xarick> oh, the red line is wrong on that screenshot
17:33:30 <xarick> nevermind it's correct
17:35:32 <xarick> is this while buggy? `while (node->m_parent) {`
17:35:48 <xarick> shouldn't it be while (node)
17:36:08 <xarick> otherwise, the last one is skipped!
17:50:12 <_glx_> no it's fine, last node is the vehicle itself
17:50:24 <_glx_> there's an assert ensuring that
17:52:15 <xarick> the last node doesn't go through the tests... doesn't have a chance to be added to the cache
17:52:28 <_glx_> it doesn't need to be in the cache
17:53:30 <michi_cc[d]> kuhnovic: If the HL path cost is deterministic, I'd just store the last cost along with the depot. If the new cost is equal or lower, keep the depot (and update the cost), otherwise chuck the depot and start a fresh search.
17:54:37 <_glx_> it is deterministic, but there are specific corner cases I think
17:55:59 <kuhnovic> michi_cc[d]: It's not that simple. The LL pathfinder is allowed to steer the ship outside of the proposed HL path. That could mean going through a water region that is further away (from the perspective of the HL, which has limited information). That could indeed lead to nasty corner cases with the ship finding-and-chucking its depot over and over again.
17:56:27 <_glx_> but checking cost is between a given range might work
17:57:29 <_glx_> old_cost +/- reasonable difference
17:58:02 <kuhnovic> Yeah that's indeed what I'm trying out right now
17:58:10 <michi_cc[d]> Or a double cache, store last LL cost too, and if the HL cost rises, double check with a LL run.
17:58:46 <xarick> I think I understand now
17:59:05 <michi_cc[d]> I don't think a second int will break the bank 😛
18:00:15 <xarick> it's CheckIfShipNeedsService bothering the pf while not entering a new tile
18:01:07 <xarick> but checkshipreverse is somehow working
18:01:37 <xarick> gonna investigate better
18:06:54 <kuhnovic> CheckIfShipNeedsService can bother the PF any time it wants, and it actually does it very often
18:07:31 <kuhnovic> checkShipReverse is not any better at fixing this. It might just happen to do the right thing in your specific case, but in essence it does the same thing as a regular chooseShipTrack call.
19:24:11 <kuhnovic> So... oneplus nord 4 or google pixel 8a...
19:28:21 <_glx_> pixel is often overpriced
19:30:38 <xarick> - FindNearestDepot must account for a ship departing from a dock where it may reverse. If it reverses, simulate the ship being on the reversed position. The next call comes from CheckShipReverse, where the ship actually reverses. And the next one is the ship actually doing a normal ChooseShipTrack to the depot.
19:30:38 <xarick> - FindNearestDepot must account for user to manually send ship to depot. Ship does not reverse, but the path should be searched both ways to prevent no nearest depot error when there's depots nearby.
19:30:38 <xarick> - FindNearestDepot must account automatic service. Ship does not reverse in this case. Path has a cost limit, meaning the first path chosen must stick when the next automatic service is called.
19:35:34 <kuhnovic> Whether or not the ship reverses shouldn't really be much of a concern. That's already too much of a low level detail if you ask me. Focus on the high level goals first (the first part of your sentences)
19:42:50 *** ChanServ sets mode: +v tokai
19:49:44 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
19:55:54 <xarick> I wonder if i should just call CheckShipReverse unconditionally
19:57:33 <xarick> checkshipreverse with a buttload of depot tiles 😮
20:07:24 <xarick> lost my debugging commit 😐
20:07:43 <xarick> let me check recycle bin
20:36:03 *** j0anjosep has quit IRC (Quit: User went offline on Discord a while ago)
20:51:49 <xarick> my new testing playground
20:51:59 *** gelignite has quit IRC (Quit: Stay safe!)
21:08:15 <johnfranklin> added dP and peter1138...
21:09:49 <xarick> time for another night for assert testings
21:11:55 <xarick> well... short lived night, already got an assert
21:15:55 <xarick> oh, it's the same ship
21:16:26 <xarick> looks like I didn't handle the issue at all
21:16:36 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:30:05 <xarick> it's the same situation as my last screenshot :p
21:31:49 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:33:56 <belajalilija> johnfranklin: What did i do?
21:34:12 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:18:14 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:35:36 <_pruple> you know what you did, etc.
22:41:08 <belajalilija> I actually don’t xd
22:41:21 <belajalilija> Though it may have been something a long time ago
22:41:33 <belajalilija> Simo is mentioned there and he’s long gone
23:32:03 *** Flygon has quit IRC (Read error: Connection reset by peer)
continue to next day ⏵
