IRC logs for #openttd on OFTC at 2024-10-06
⏴ go to previous day
01:15:03 <talltyler> DorpsGek is mean! (When can we get it to police the PR template?)
01:21:15 <peter1138> Never seen that one before...
02:08:59 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
02:20:59 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:54:05 *** Wormnest has quit IRC (Quit: Leaving)
03:03:15 *** gnu_jj_ has joined #openttd
03:06:34 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
06:07:14 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:07:58 *** akimoto has joined #openttd
07:23:43 *** akimoto has quit IRC (Remote host closed the connection)
07:36:05 *** gelignite has joined #openttd
08:24:11 *** Flygon has quit IRC (Read error: Connection reset by peer)
08:30:30 *** ialokin has joined #openttd
08:48:27 *** reldred has quit IRC (Quit: User went offline on Discord a while ago)
09:17:42 <truebrain> it is also incredible how much they butchered the template. That is an impressive feat.
09:36:06 *** ChanServ sets mode: +v tokai
09:38:38 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
09:41:55 <peter1138> "CC_NON_POURABLE" : 12,
09:41:55 <peter1138> "CC_NEO_BULK" : 12,
09:42:07 *** HerzogDeXtEr has joined #openttd
09:42:12 <peter1138> NML has these two on the same bit, where did the latter one come from?
09:42:52 *** tokai|noir has joined #openttd
09:42:52 *** ChanServ sets mode: +v tokai|noir
09:43:54 <andythenorth> I probably have an irc transcript
09:44:55 *** andythenorth is now known as Guest5562
09:44:56 *** Guest5562 is now known as andythenorth[d]
09:45:17 <peter1138> (It's listed in the NML side, but doesn't explain naything else there.
09:45:32 <peter1138> Having two meanings to one bit is not very useful.
09:47:08 *** tokai has quit IRC (Ping timeout: 480 seconds)
09:47:45 <andythenorth[d]> I can find transcripts about it, but nothing useful 😛
09:47:49 <andythenorth[d]> I think they're synonyms
09:50:25 <andythenorth[d]> TL;DR - bulk cargos, but you can't run them through a hopper
09:52:10 <andythenorth[d]> I've added a note in nml docs
09:55:34 *** D-HUND is now known as debdog
10:00:12 *** ChanServ sets mode: +v tokai
10:04:09 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
10:09:27 <ahyangyi> The letters: no, we don't want to stay here on the wall
10:13:24 *** tokai has quit IRC (Ping timeout: 480 seconds)
10:13:49 *** ChanServ sets mode: +v tokai
10:36:40 <truebrain> truebrain: I wonder if this bot has the same bug as my rewrite ...
10:36:47 <truebrain> it does not .. interesting 😄
10:37:34 *** tokai|noir has joined #openttd
10:37:35 *** ChanServ sets mode: +v tokai|noir
10:38:11 <truebrain> ah, I see what I did wrong 🙂
10:38:18 <truebrain> Thank you all for being part of my test 😛
10:41:34 *** tokai has quit IRC (Ping timeout: 480 seconds)
10:53:44 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
10:59:39 *** ChanServ sets mode: +v tokai
11:06:44 *** tokai|noir has joined #openttd
11:06:44 *** ChanServ sets mode: +v tokai|noir
11:07:44 *** tokai has quit IRC (Ping timeout: 480 seconds)
11:08:38 <peter1138> Is it 14.1, vanilla or JGRPP...
11:11:38 <Rubidium> isn't 14.1 kinda vanilla?
11:13:19 <peter1138> Yeah, but vanilla is vague enough to also mean nightlies / master.
11:26:37 *** ChanServ sets mode: +v tokai
11:26:59 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
11:29:05 <xarick> got another binary heap false positive 😦
11:29:13 <xarick> almost certain it is it
11:29:38 <xarick> but this time it's the llpf triggering it
11:37:57 *** messenils has joined #openttd
11:37:57 <messenils> I released a new version of openTTD splitscreen on splitscreen.me. The new version have hexedited CreateWindow. Dwstyle, and X,Y pos
11:42:21 <peter1138> Why do people do crazy things like that
11:50:31 <peter1138> Interface scale below 100 is not supported.
12:21:54 <xarick> there are 2 depots nearby at equal distance to the ship. As the ship advances, the path becomes shorter, but binary heap does its things and alternates between the 2 depots.
12:25:16 <xarick> they don't like the idea
12:25:52 <ahyangyi> 🤔 I mean, you don't need a new value to break the ties. The depot ID should do the job already?
12:28:55 <Rubidium> ahyangyi: something along those lines has been suggested many days ago, but the underlying question is: why is it important that a specific depot is chosen all the time? (It has to be deterministic though) I'd even argue that having some randomness is more realistic
12:29:15 <_glx_> If destination is stored there's no issue
12:29:54 <ahyangyi> Rubidium: Alright, hash(departure time stamp, depot ID) should do the trick?
12:30:19 <truebrain> the first question is: is there an issue? 🙂
12:30:48 <ahyangyi> I'm assuming that heap alternating between solutions cause extra computational burden
12:30:56 <ahyangyi> But if that's not the case, then there's nothing to worry about
12:31:08 <truebrain> the fact it calculates the route is the burden
12:31:16 <truebrain> whether the outcome is either A or B is not relevant in terms of performance
12:31:27 <ahyangyi> Yeah, but I remember you use a two-tier approach
12:31:38 <ahyangyi> that's where the misunderstanding begin 😛
12:31:54 <xarick> nono, this one is solely responsive of llpf
12:35:46 <Rubidium> ahyangyi: but what does adding that hash to the calculation improve over the current situation? Currently it is deterministic. Only someone doesn't fully understand what is going on, starts tracing the code and finds more things that are not understood, and each of those things that are not understood are considered "bugs" that need to be fixed. Next to that all the suggestions made already are
12:38:05 <ahyangyi> Rubidium: Deterministic != In control
12:38:15 <ahyangyi> Though it doesn't matter in this case.
12:38:59 <truebrain> wth does "in control" means in this context? 😄
12:39:35 <ahyangyi> the result is defined in a simple way
12:39:48 <truebrain> isn't the simplest way being deterministic?
12:39:50 <truebrain> what am I missing? 😄
12:40:23 <peter1138> What was the problem?
12:40:37 <ahyangyi> A heap is deterministic but you can't really predict the order of its tying elements
12:40:44 <ahyangyi> Unless you emulate that heap
12:40:52 <ahyangyi> Anyway, I agree that it doesn't matter
12:41:01 <ahyangyi> peter1138: There's no problem
12:41:15 <truebrain> okay, I think you misunderstood the "problem" here 🙂 Look at this: a ship is going to a crossroad. Left and right are equally long. When going to it, it keeps tihnking: left, no right, no left. But nobody sees it nor knows it
12:41:25 <truebrain> so up till the crossroad
12:43:38 <truebrain> the only really important part is that it is deterministic at the crossroad, basically. So yeah, fully in control here 🙂
12:43:39 <ahyangyi> truebrain: And the switching of the destinations is caused by pushing and popping elements in a heap, which doesn't care about the ordering between equal values anyways
12:43:51 <truebrain> exactly; the paths are equal of value/length
12:43:55 <truebrain> so both right and left are perfectly fine
12:44:05 <truebrain> there is no "right" or "wrong"
12:45:36 <ahyangyi> Yeah, I don't think I misunderstood the "problem", I was just explaining the difference the hypothetical tie-breaker would have made
12:46:36 <ahyangyi> i.e., a human with access to enough data could predict the end result in O(1) time instead of O(n log n) time
12:46:46 <ahyangyi> Whether that is of any use is another question
12:49:24 <truebrain> the PF will still run as often as it does now. So I am still not sure what you meant 😄 But it is okay. We all agree it is a non-issue, that is more important 🙂
12:50:29 <ahyangyi> Also, my hash suggestion was partially a response to Rubidium's "having some randomness is more realistic"
12:50:40 <ahyangyi> which is not something I personally care about, but still
12:51:11 <ahyangyi> I don't get why you guys keep asking my when obviously I was not the one who raised the randomness question.
12:51:26 <truebrain> owh, no, I was just curious about your thinking
12:51:34 <truebrain> it became purely academic at that point 🙂
12:51:42 <truebrain> I wanted to understand your point 😄
12:56:17 <truebrain> ahyangyi: anyway, sorry ahyangyi , wasn't meant bad. I was just curious about your "in control" 😄
12:57:45 <ahyangyi> Unfortunately there wasn't much thought attached to that term -- I just wanted to tell the difference between deterministic and easy-to-calculate verses deterministic but hard-to-culculate :S
12:58:00 <truebrain> ah! And only now I get you 😄
13:23:42 <peter1138> Hmm, using a class destructor to execute code when leaving a scope.
13:23:57 <peter1138> RAII-but-for-lazy-code
13:25:06 <truebrain> golang has a keyword for that 😄
13:28:08 <xarick> I am trying to debug whether subsequent calls to CheckIfShipNeedsService keep returning the same depot, but these false positives make things harder. I want to catch real issues
13:29:45 <peter1138> CheckIfShipNeedsService doesn't return a depot.
13:30:01 <peter1138> It updates the orders to go to a specific depot.
13:30:36 <peter1138> If it is called later, when it needs to find a depot again, it absolutely does not matter if it chooses a different depot.
13:33:15 <xarick> okay, i guess, as long as it doesn't make the ship goes in circles
13:34:17 <peter1138> Why would it? It's got an order to go to a specific depot.
13:52:50 <xarick> forgive me but I am using the tie-breaker again, just for debugging purposes, wanna get rid of these false positives
13:58:27 <xarick> Need a solution for this. It is unsolved and I have no idea how to fix it.
14:33:32 *** xarothbrook has joined #openttd
14:33:32 <xarothbrook> Isn't it well established that you're chasing a non-issue?
15:14:03 <xarick> i just feel like... turning path_found to false after it said found
15:26:04 <_glx_> well in red arrow situation, path (and cost) is not really checked when searching for any depot, hlpf will just see there's a depot in the region, and the 2 water tiles are somehow linked, but it doesn't know it needs to cross 2 other regions to actually reach the depot
15:39:15 <ian01223> what is xarick trying to do anyways? i'm reading through the commits and I don't get it
15:40:40 <ian01223> granted that's partially because I'm ignorant in general
15:41:24 <peter1138> That's the thing...
15:41:49 <ian01223> something to do with ships reversing and finding the way to depot tiles?
15:47:23 *** gelignite has quit IRC (Read error: Connection reset by peer)
15:54:58 <xarick> I'm hunting for cases on my attempts at implementing a find nearest ship depot that actually uses YAPF to search for it.
15:56:34 <ian01223> peter1138: there's the thing about "Don't use the entire docking area when computing closest station tile", but that seems to be a bug only when someone makes a much bigger dock than is usually allowed by the settings, and doesn't the cargo get delivered to everything in the catchment zone anyways?
15:57:35 <peter1138> No, the thing is that the problem isn't adequately described, and there's lot of 'XY problem' going on.
15:57:36 <xarick> that one is a separate issue
15:58:36 <xarick> it is only vaguely related due to me reusing code from the fix
15:59:39 <ian01223> so it's about finding the nearest depot? does it use a different pathfinder for that then than it normally does?
15:59:50 <_glx_> I think one of the "issues" is trying to compare apple and oranges
16:02:46 <_glx_> currently, find nearest depot creates a list of reachable water patches, then enumarate all depots to find the closest reachable one
16:04:24 <_glx_> but depending on map, this closest one may not be the closest in travel time
16:07:43 <ian01223> i guess that would be a problem on some map layouts, though it's only much of a problem when you manually send ships back to the depot
16:07:59 <ian01223> so the idea is to pathfind to every single depot instead and then go to the one with the shortest distance
16:08:29 <_glx_> but that implies a lot of changes 🙂
16:13:58 <xarick> manual sending ships is much easier to deal with
16:14:11 <xarick> it's the automatic service that's causing headaches
16:15:09 <ian01223> I was thinking of timetabled depot runs as opposed to just clicking the depot button but yeah that's true, and that'd happen more often
16:53:37 <xarick> I wanna get to the bottom of these path cost discrepancies
17:04:03 *** gelignite has joined #openttd
17:16:00 <xarick> 3 calls to CheckIfShipNeedsServicing, 1st on the left, 2nd on the middle, 3rd on the right. It first decided on one depot, second decided the other depot was better while following the path from 1 up until the arrow... why didn't it stick with the path. I added costs to see and understand what made it change
17:22:05 <xarick> is the estimate flawed?
17:28:44 <xarick> it made the right thing switching to the other depot, 1171 < 1294... how didn't it pick the right depot in the first attempt?
18:03:48 <messenils> peter1138: i did test it with different resolution scalings. did not see any problems. a coordinate is a coordinate no matter the scaling isnt it?
18:06:53 <messenils> or you talking about this?
18:19:25 <peter1138> Yeah, 100 is the minimum.
19:30:38 <xarick> question, how much km/h do i need to set for travelling if i want 1 tile per day?
19:31:35 <xarick> nevermind, there's a tile/day metric
19:36:39 <kuhnovic> xarick: Yes, otherwise it wouldn't be called an estimate
19:43:07 <xarick> can't quite understand this
20:06:39 *** gelignite has quit IRC (Quit: Stay safe!)
20:31:46 <xarick> there is a bug somewhere in the pathfinder and I can't quite point it out where
20:36:03 <xarick> this would be the other path if the depot on the left didn't exist
20:37:01 <_glx_> it's not the pf fault if destination is not fixed
20:38:15 <xarick> 45 degrees and 90 degrees costs are involved...
20:38:42 <_glx_> I mean if it's heading to a given depot it will stick to it
20:39:04 <_glx_> changing target is not the pf fault
20:39:24 <_glx_> your looking at the wrong end
20:39:31 <kuhnovic> If the PF doesn't do what Xarick wants then it's a bug
20:40:06 <xarick> Im trying to understand what happened
20:40:36 <xarick> taking a snapshot of costs each tile
20:40:43 <_glx_> what happens here is outside the pf
20:40:57 <_glx_> something changes the destination while it should not
20:41:19 <_glx_> pf just reacts to the new destination given to it
20:41:51 <_glx_> but all that is outside pf
20:41:52 <kuhnovic> I think he's now focusing on cost changes between PF runs, leading to a different target depot being picket
20:44:05 <kuhnovic> And since it's all a balancing act between costs and estimations, things can change between different initial conditions. Coupled with the fact that the PF is called for each new tile if the ship is close to the target, and things might change
21:02:52 <truebrain> I see you are describing the normal inner workings of any pathfinder again? 🙂
21:10:31 *** Wormnest has joined #openttd
21:28:59 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:37:15 <xarick> this is weird, I cannot explain this
21:37:53 <xarick> 2 depots, but i forced that path, yet it now picks the one to the right
21:38:51 <xarick> there's something fishy with the pf...
21:43:19 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:44:00 <xarick> i forced it to walk the same path up to that part in the video where it switches from left to right depot. If the path is now the same, why does it now decide the right depot is the better one from the let go?
21:50:53 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:04:02 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
continue to next day ⏵
