IRC logs for #openttd on OFTC at 2024-09-29
⏴ go to previous day
00:01:54 *** Tirili has quit IRC (Remote host closed the connection)
00:55:28 <talltyler> Oops, thanks. Definitely not intended. 🙂
01:14:02 *** gelignite is now known as Guest4840
01:14:07 *** gelignite has joined #openttd
01:21:14 *** Guest4840 has quit IRC (Ping timeout: 480 seconds)
02:13:42 *** gnu_jj_ has joined #openttd
02:16:59 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
02:20:45 <bigyihsuan> how can i fix the dropdown being too small for the max speed to be drawn inside of it?
02:22:42 <talltyler> Fix your code to measure the string width and assign said width to the proper element, I’d imagine 😉
02:23:26 <talltyler> Looks like maybe you assigned the calculated width to the full dropdown including the “expand” button
02:25:27 <talltyler> Full disclosure, I haven’t touched dropdown code in a while so I am not an expert
02:28:19 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:29:24 <talltyler> Another possibility, are you measuring the width of the string AND the icon?
02:29:33 <talltyler> Hard to say without seeing the code 🙂
02:30:38 <bigyihsuan> adding the passed-in padding seems to work
02:30:39 *** D-HUND is now known as debdog
02:31:48 <talltyler> Well that looks more like it 👍
02:32:35 <bigyihsuan> quite a few other dropdowns use padding.width, so i'm just gonna follow along with that
02:35:48 <bigyihsuan> time to look into doing this for the new game menu as well
03:52:31 *** gelignite has quit IRC (Quit: Stay safe!)
04:45:35 <DorpsGek> - Update: Translations from eints (by translators)
06:52:24 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:22:09 <peter1138> bigyihsuan: Your padding for the vertical container is wrong, though 🙂
08:59:46 *** gelignite has joined #openttd
09:28:29 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
09:49:29 <xarick> which expression looks nicer?
09:50:37 <Rubidium> that depends on the context I'd say
09:51:55 <xarick> ``` const bool a_less_than_b = *std::get<0>(a) < *std::get<0>(b);
09:51:55 <xarick> const bool b_less_than_a = *std::get<0>(b) < *std::get<0>(a);
09:51:55 <xarick> const bool a_first_than_b = std::get<1>(a) < std::get<1>(b);
09:51:55 <xarick> if (!a_less_than_b && !b_less_than_a) return a_first_than_b;
09:51:55 <xarick> return a_less_than_b;```
09:52:29 <xarick> trying to avoid using the operator!=
09:57:04 <xarick> if not false and not false return who came first
09:59:29 <xarick> 0 < 1 = true ; 1 < 0 false; if not true.... skip; return 0 < 1
10:00:04 <xarick> !a && !b has less characters
10:11:50 <peter1138> As loing as a and b are bools
10:22:07 <xarick> wow copilot is too smart
10:22:20 <xarick> inline bool Compare(const std::tuple<T *, size_t> &a, const std::tuple<T *, size_t> &b)
10:22:20 <xarick> const auto& a_priority = *std::get<0>(a);
10:22:20 <xarick> const auto& b_priority = *std::get<0>(b);
10:22:20 <xarick> if (a_priority < b_priority) return true;
10:22:22 <xarick> if (b_priority < a_priority) return false;
10:22:22 <xarick> // If priorities are equal, compare by counter
10:22:24 <xarick> return std::get<1>(a) < std::get<1>(b);
10:24:14 <xarick> it just made the 'operator<' irrelevant
10:25:42 <xarick> i have a feeling this won't compile
10:28:21 <xarick> it still uses operator<
10:29:23 <peter1138> Normally we do `if (a_priority != b_priority) return a_priority < b_priority`
10:29:50 <xarick> there is no operator!=
10:30:05 <xarick> there could be, but that requires writing more code
10:31:21 <xarick> wanted to avoid touching yapf internals
10:31:45 <peter1138> I would not be surprised if you barking up completely the wrong tree, of course.
10:37:20 <xarick> inline bool Compare(const std::tuple<T *, size_t> &a, const std::tuple<T *, size_t> &b)
10:37:20 <xarick> if (*std::get<0>(a) < *std::get<0>(b)) return true;
10:37:20 <xarick> if (*std::get<0>(b) < *std::get(0>(a)) return false;
10:37:22 <xarick> // If priorities are equal, compare by counter
10:37:22 <xarick> return std::get<1>(a) < std::get<1>(b);
10:38:36 <_jgr_> The usual concise way to do this is with std::tie
10:39:19 <xarick> hmm let me explore that option
10:39:24 <_jgr_> Though tuple's comparison operators should do even that for you
10:45:12 <peter1138> Ah yes, tuple has magic
10:56:38 <xarick> return std::tie(*std::get<0>(a), std::get<1>(a)) < std::tie(*std::get<0>(b), std::get<1>(b));
10:57:40 <xarick> could I use std::pair instead of std::tuple? since it's only 2 elements
11:06:41 <xarick> heh return first.first;
11:06:57 <kuhnovic> I'm still wondering why you are doing all of this 😉
11:08:11 <xarick> because binary heap makes my code assert due to handling ties badly 🙂
11:09:04 <xarick> there's yet some other issue I found
11:09:28 <xarick> which is the order the origin patches are added, also influence the resulting path
11:09:52 <xarick> paths that have equal costs, that is
11:10:15 <xarick> m_origin_keys is a std::vector 😦
11:11:25 <xarick> also affects my PR about dest_tiles
11:11:42 <xarick> I also used std::vector 😦
11:12:28 <xarick> for example, the order i placed depots
11:13:02 <xarick> they have their own index, when i add depots to the list of dest_tiles, it adds them by the index order
11:13:24 *** michi_cc[d] has joined #openttd
11:13:24 <michi_cc[d]> Equal cost is equal cost, so literally, who cares?
11:13:49 <xarick> if the path is a tie, a ship would end up going to a very different depot
11:14:04 <xarick> if all u did was just remove one depot
11:14:55 <michi_cc[d]> So? Equal cost is still equal cost. Unless your problem is that you actually think they shouldn't be equal cost, but then the binary heapa is still the wrong spot to look at.
11:16:02 <_jgr_> It would still need to be deterministic if you had equal costs, as otherwise you'd get MP desync problems
11:16:53 <michi_cc[d]> Well, things like depot index order is determinsitic.
11:17:06 <xarick> it is still deterministic, though, from a viewer standpoint, a ship that used to go to depot to the north, suddenly goes to a depot to the east just because i removed a depot from somewhere else
11:17:44 <xarick> it's the binary heap shuffling the ordering of ties
11:19:46 <Rubidium> xarick: how often do you look for the nearest depot at the same distance to all other depots? Isn't it something that happens every N ticks, so depending on where the ship is exactly it will make different choices too
11:21:16 <xarick> deterministically shuffle
11:22:16 <andythenorth> but they're equal distance?
11:22:43 <xarick> technically yes, visually not
11:23:05 <xarick> let me find that screenshot of yesterday
11:23:10 <andythenorth> I can see why you'd want to solve it, but eh, life is short, interesting problems are many
11:23:21 <andythenorth> this wouldn't be something I'd spend time on
11:23:36 <andythenorth> but I've been moving around pixels in sprites that are never seen, just to be correct, so eh
11:24:49 <xarick> all those depots in the image have equal costs to where the ship is
11:25:26 <xarick> if i remove one depot, for example, the one on the left, the ship would next time head to a different from the remaining ones
11:26:13 <andythenorth> all these wagons are covered hoppers, do we need so many?
11:26:19 <andythenorth> no, but I wanted to draw them 😛
12:00:52 <_glx_> xarick: and this kind of setup is highly improbable in a real game
12:01:14 <_glx_> real use is the only thing that should matter
12:17:05 <xarick> std::tie does some weird stuff
12:17:23 <xarick> what is <=> supposed to do
12:17:57 <xarick> what happens if they're equivalent a second time
12:18:12 <xarick> (which I made sure that won't happen, btw)
12:34:06 <xarick> std::tie(this->data[child + 1]) < std::tie(this->data[child]))
12:34:06 <xarick> is std::tie smart enough to understand that this->data[child + 1] is a std::pair?
12:34:41 <xarick> how's it uncoupling it, let's investiagte
12:35:28 <_glx_> "std::tie may be used to unpack a std::pair because std::tuple has a converting assignment from pairs"
12:35:58 <peter1138> How is this 15 commits already 😦
12:36:49 <michi_cc[d]> std::tie with a single variable is completely pointless
12:41:55 <_glx_> yeah tie is to make a tuple when you don't already have it
12:51:39 <xarick> oh, it's not smart enough
12:52:45 <xarick> std::tie(*this->data[child + 1].first, this->data[child + 1].second) < std::tie(*this->data[child].first, this->data[child].second))
12:54:29 <xarick> it became ugly quickly
12:57:50 <xarick> maybe I don't need the *, not sure
13:24:56 <kuhnovic> Xarick, while I respect your enthusiasm and determination, I do want to point out that your PR will likely not be accepted. You are fixing a non-issue, and you are complicating the code in the process. Your code could even make the PF slower since the binary heap has to do more work, although I doubt it makes a measureable difference. But all in all this is simply not an improvement.
13:37:31 <xarick> kuhnovic: I'll change to draft
13:56:14 <xarick> my main goal: make automatic servicing of ships to stick with a path once it finds one
13:57:10 <xarick> for that I need the path found by find nearest depot to be equal to the path found on the next chooseship track
13:57:15 <_glx_> store the chosen depot until it's reached
13:59:24 <_glx_> if service finds a depot, store it
14:00:57 <_glx_> that can be handled in the controller
14:01:54 <kuhnovic> xarick: Now we're talking. I really doubt you can fix that problem by fine-tuning the binary heap. I looked into that issue as well, and IIRC the problem is that the depot search is called very often, and that can cause the ship to go in circles in certain cases. Not a great explanation, I don't remember all the details.
14:03:08 <_glx_> for me if automatic servicing found a depot, cache it and don't retry to check for servicing if already found
14:03:17 <peter1138> Yeah, store the depot until either it's reached, or is no longer reachable..
14:03:48 <kuhnovic> _glx_: That was my solution to this problem. Works well, but if terraforming occurs and there is still a route to that depot, the ship will go there no matter what. Even if that means travelling all across the map.
14:04:51 <_glx_> you can also cache the cost to see if it increase in an unusual way
14:04:55 <peter1138> Ok, store the depot and cost until either it's reached, or is no longer reachable, or the cost goes up.
14:05:27 <kuhnovic> Something like that. I still have plans to look at it at some point, but I've had zero time
14:05:44 <xarick> the cost limit aka max_penalty by default is 2000
14:06:59 <_glx_> you want to prevent "useless" tries to find depot for automatic service
14:07:02 <xarick> problem i have right now find nearest depot brings up a path with a cost within 2000, but then chooseshiptrack going to the depot that was chosen by find nearest depot, goes over 2000 😦
14:07:18 <kuhnovic> Fiddling with penalties is not a structural solution. It will tip the balance in your favor for certain situation but it will create problems in others
14:08:29 <xarick> it picks a different trackdir which affects costs 😦
14:08:34 <kuhnovic> xarick: This shouldn't be an issue as long as the ship sticks to that depot, instead of looking for another depot. That could lead to the ship going back and forth
14:09:25 <_glx_> anyway the solution should be in the controller, not in the pathfinder
14:12:08 <xarick> it's the intermediate destination mingling around, the high level pf penalty not equivalent to low level pf penatly, and the matter of being able to reverse on the spot 😦
14:12:38 <_glx_> you focus too much on pathfinding
14:16:18 <kuhnovic> xarick: No issue with this. The LL and HL pathfinders are completely different beasts and their results (and costs) can't be compared
14:19:32 <kuhnovic> The HL PF simply tells the LL PF where to go, instead of directly going to the target. As long as the the next call to the HL PF is called from a water region patch that was on the path returned by the last HL PF call, then the HL path should be the same (minus the last region). If this doesn't happen then the back-and-forth-behavior can emerge in certain cases. This is what you are seeing.
14:20:21 <kuhnovic> By extention, if the HL PF consistently produces the same path then the LL PF should be able to consistently follow it all the way to the final destination
15:14:50 <peter1138> Hmm, badges be configurable or just on-off... Hmm.
15:34:28 *** gelignite is now known as Guest4889
15:34:28 *** Guest4889 has quit IRC (Read error: Connection reset by peer)
15:34:32 *** gelignite has joined #openttd
15:51:19 *** Wormnest has joined #openttd
15:55:38 <xarick> what's a good alternative for std::vector that automatically orders stuff during insertion
15:56:06 <xarick> and is not expensive of course
15:56:47 <xarick> CoPilot says std::multiset
16:13:08 <xarick> he's telling me to go with std::map and use a dummy value
16:15:06 <xarick> guess i'm gonna test them all
16:17:11 <_jgr_> "can sort before insertion" seems like actively bad advice?
16:19:23 <xarick> which apparently isn't an int, it's a weird struct
16:19:56 <xarick> using TileIndex = StrongType::Typedef<uint32_t, struct TileIndexTag, StrongType::Compare, StrongType::Integer, StrongType::Compatible<int32_t>, StrongType::Compatible<int64_t>>;
16:23:04 <_glx_> it's an int with something around to not be directly usable as an int
16:25:08 <_glx_> but it has all stuff needed to order elements
16:54:24 <kuhnovic> xarick: A binary heap 😆
17:03:08 <johnfranklin> There is no baked beans today.
17:06:08 <johnfranklin> - What do you eat today?
17:06:09 <johnfranklin> - The day before yesterday?
17:06:11 <johnfranklin> - The other day before yesterday?
17:06:13 <johnfranklin> - Hmm, so what did you eat on the first day in the UK
17:06:13 <johnfranklin> - 5GBP bottled water
17:07:34 <FLHerne> Someone really likes their baked beans
17:08:22 <FLHerne> Today I am eating plain pasta because it's the only food I have and I don't want to walk two miles to the nearest shop in the rain
17:12:45 <xarick> sorting std::vector<TileIndex> with an average of ~500 tiles
17:14:53 <LordAro> FLHerne: baked beans are pretty good tbf
17:14:55 <xarick> i wonder how fast it is at inserting
17:15:21 <LordAro> johnfranklin: highly recommend baked beans & cheese on a large baked potato
17:16:17 <johnfranklin> This cannot taste bad
17:16:57 <peter1138> Bit of Worcestershire sauce
17:17:22 <johnfranklin> I only know Worcester in Massachusetts
17:19:27 <xarick> generating the list is slow... it's not exactly the act of just inserting, it's iterating Depot
17:20:42 <johnfranklin> Hmm, I am curious is the new ship pf in 14.0 completely different from previous one
17:23:35 <peter1138> High level yes, low level no. But essentially yet.
17:24:01 <_glx_> there was no high level before 14.0
17:25:10 <LordAro> _glx_: so completely different!
18:01:02 <xarick> can't achieve consistency, even with sorted tileindexes, tie breaker and such 😦 gonna give up
18:01:41 <xarick> can't upload video for some reason
18:09:29 <andythenorth> I don't understand any of the details
18:10:50 <andythenorth> but my limited programming experience suggests that there might be a triangle composed of
18:10:50 <andythenorth> - sequence entropy (order)
18:10:56 <johnfranklin> Never gonna give you up?
18:11:03 <andythenorth> and possibly you're running up against it
18:13:45 <peter1138> Basically, if we want to try remembering the depot, we've got to do it ourselves 😉
18:38:13 <xarick> it's now always taking the depot with the lowest tileindex, that's something
18:38:31 <kuhnovic> It's definitely not a fix for the actual issue
18:40:04 <xarick> i can't upload videos to discord anymore?
20:31:55 <xarick> github desktop is such a good app
20:34:07 <xarick> I am forced to use SaveRandomSeeds
20:34:30 <xarick> because of ChoseRandomTrack :/
20:34:58 <xarick> such an abysmal implementation
20:35:21 <xarick> eh... strong word, sorry
20:36:56 <andythenorth> I have repainted a lot of sprites
20:45:19 <andythenorth> probably not very noticeable on average, but eh
20:46:48 *** gelignite has quit IRC (Quit: Stay safe!)
21:04:15 <xarick> i still can't get the track == track2 assert to not fail
21:15:26 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:29:59 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:34:19 <xarick> I'm leaving this running the 70000 ship savegame overnight, to see if any assert occurs
22:01:59 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:04:22 *** Flygon has quit IRC (Read error: Connection reset by peer)
continue to next day ⏵
