IRC logs for #openttd on OFTC at 2025-01-05
⏴ go to previous day
00:09:34 <peter1139> Hacked around it :S
00:12:51 <truebrain> okay, indeed, new `git push` fixed the BaNaNaS issue
00:12:58 <truebrain> temporary DNS failure 🙂
01:27:04 *** Flygon has quit IRC (Read error: Connection reset by peer)
01:31:21 <peter1139> Is this why Rubidium fixed the potential matrix range issue?
01:36:50 *** gelignite has quit IRC (Quit: Stay safe!)
02:54:43 <peter1139> I guess #11452 says I shouldn't make anything dynamic...
02:55:03 *** Wormnest has joined #openttd
03:15:03 <peter1139> Whatever this is...
03:18:00 *** gnu_jj_ has joined #openttd
03:21:01 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:23:04 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:41:50 <DorpsGek> - Update: Translations from eints (by translators)
08:43:10 *** kuka_lie has joined #openttd
10:39:16 *** gelignite has joined #openttd
11:34:20 <LordAro> in the strongtype header
11:36:18 <xarick> I tried putting inside the `namespace StrongType {` block
11:37:41 <xarick> gonna try several places
11:50:12 <xarick> nop, I don't understand the error
11:59:41 <peter1139> No, it can't be in the namespace as it's defining something in the `std` namespace.
12:00:25 <peter1139> So it should be placed at the end, after StrongType is defined.
12:08:01 <xarick> doesn't work, i asked copilot for a solution
12:08:31 <xarick> template <typename TBaseType, typename TTag, typename... TProperties>
12:08:31 <xarick> struct hash<StrongType::Typedef<TBaseType, TTag, TProperties...>> {
12:08:31 <xarick> std::size_t operator()(const StrongType::Typedef<TBaseType, TTag, TProperties...>& t) const noexcept
12:08:32 <xarick> return std::hash<TBaseType>()(t.base());
12:08:36 <xarick> this works, but i have absolutely no idea what it's doing. 😐
12:08:51 <xarick> i placed it after StrongType is defined on both cases
12:10:21 *** nielsm has quit IRC (Ping timeout: 480 seconds)
12:17:34 <johnfranklin> oh it's okay now
12:23:32 <LordAro> xarick: seems reasonable
12:23:53 <LordAro> std::hash is an odd function
12:34:31 <peter1139> orudge probably needs to poke something.
12:42:24 *** D-HUND is now known as debdog
14:36:18 <peter1139> So many destructors, heh.
14:45:24 <xarick> IsTileFlat is annoying me
14:47:54 <peter1139> Change it to `uint`?
14:47:59 <_glx_> what's wrong with it? it's just a pointer for when you want to get TileHeight during the call
14:48:34 <peter1139> Or is that not what you meant?
14:49:31 <xarick> change to uint everywhere?
14:49:33 <peter1139> If it's because of int vs uint, then *h is assigned from a uint anyway, so no issues converting it that side.
14:49:46 <peter1139> The output parameter is barely used.
14:50:17 <_glx_> uint would make more sense anyway, we don't use negative heigts
14:50:33 <xarick> alright, gonna make a new PR to change it
14:52:24 <_glx_> looks like it's used only for lighthouses and transmitters
15:05:43 <xarick> pretty sure codeql will complain
15:05:58 <xarick> doing a int == uint somewhere
15:09:59 <peter1139> Only when comparing your reference_height with GetTileMaxZ()
15:11:12 <peter1139> Maybe one day we'll want under sea-level features...
15:12:04 *** aperezdc has quit IRC (Ping timeout: 480 seconds)
15:12:12 <peter1139> If you go deep enough do you end up back at surface in on the opposite side of the map?
15:16:37 <Rubidium> though, if going under-sea, won't it be easier to just say... there are 5 under-sea levels and water level is at 5, and you can only go to level 250. I doubt there are many maps that will get broken on conversion, though adding a sign to height makes it much more expensive to access
15:21:59 <peter1139> Yes, if was to happen having sea-level be non-zero would be the way.
15:22:26 <peter1139> (New disaster: sea-level rising due to climate change)
15:23:24 <peter1139> I don't think that's the way the old deep sea patch worked though.
15:24:08 <peter1139> Rebasing x of 38 :S
15:25:05 <xarick> change gettilemaxz to uint? 😛
15:25:30 <peter1139> You are entering rabbit hole territory, but I think it's actually a reasonable change.
15:25:41 *** aperezdc has joined #openttd
15:26:17 <peter1139> I suppose the difficulty is when you convert height to difference in height, which can be negative.
15:27:25 <_glx_> weird, usually only MSVC complained about that
15:28:09 <peter1139> There's a compilation flag you can set which ruins everything for everyone :
15:28:52 <_glx_> but yeah changing GetTileMaxz return type will trigger warnings everywhere
15:30:11 <peter1139> What got changed that made a train passing a signal "at danger" (force proceed) behave so oddly?
15:31:40 <peter1139> Hmm, although with a simple test case I'm not seeing it.
15:35:26 <peter1139> I don't remember it doing this in the past, but I think it probably has been that way for a while.
15:47:54 <xarick> omg I'm dropping the PR
15:49:35 <xarick> v->z_pos < GetTileMaxZ(v->tile)
15:49:52 <xarick> if GetTileMaxZ becomes uint, this will be the next complaint
15:51:35 <xarick> I prefer to change my stuff to ints
15:53:32 <peter1139> There's a reason that Java doesn't (didn't?) have unsigned integers.
15:53:59 <kuhnovic> peter1138: A bit too cautious in the turns?
15:56:09 <peter1139> It completely stops every tile, not just the turns.
15:56:27 <peter1139> Maybe it's intended behaviour though.
16:02:42 <xarick> i'm making this more complicated than it should be
16:03:19 <xarick> FlowRiver and MakeLake should be one PR, it would avoid this back and forth dependency
16:13:08 <LordAro> xarick: might as well
16:15:40 <xarick> do you agree rubidium?
16:18:23 <peter1139> Hmm, perhaps returning a string instead of pushing parameters into a vector would be better.
16:31:46 *** Wormnest has joined #openttd
17:40:09 *** urdh has quit IRC (Ping timeout: 480 seconds)
17:55:07 <peter1139> Oh pants, I broke orders again.
17:55:20 <peter1139> Maybe that was a stash that I didn't apply :S
17:57:10 <peter1139> Okay, as well as filling the parameters, using them is useful.
18:31:27 <peter1139> Okay, that seems cleaner.
18:47:10 *** ChanServ sets mode: +v tokai
18:54:09 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
19:12:07 <peter1139> Yeah, that looks wrong to me.
19:12:47 <peter1139> But that's not testing CC_LIQUID though, so that one probably isn't the culprit.
19:15:04 <peter1139> It's definitely the class detection that's wrong.
19:22:53 <peter1139> Okay, that doesn't actually seem to be the correct fish :p
19:23:15 <peter1139> FISH 2. This user is using FISH 1.
19:25:39 <peter1139> So, revert #12975 for compatibility and never talk about adding classes again?
19:28:24 *** ian01223 has joined #openttd
19:28:24 <ian01223> peter1138: uhhhhhhhhhhhh
19:29:16 <ian01223> yeah I think that's a discord bug
19:29:21 <andythenorth> peter1139: how does 12975 cause the issue? 😛
19:29:41 <peter1139> "Is the cargo class CC_LIQUID?"
19:29:52 <peter1139> Rather than "Is CC_LIQUID set in the cargo class"
19:30:12 <peter1139> The cargo class is not CC_LIQUID. It's CC_LIQUID | CC_NON_POTABLE.
19:32:25 <peter1139> I'm guessing authors thought using bitmask() there would just test that bit?
19:32:27 <andythenorth> well grf authors should do better
19:33:12 <andythenorth> can we withdraw it on bananas?
19:33:25 <andythenorth> player can make a warranty claim
19:33:27 <peter1139> Players are using FISH 0.9.2 still, so...
19:33:33 <peter1139> But it worked in 14.1.
19:33:44 <peter1139> Therefore the NewGRF is fine.
19:33:46 <andythenorth> oh wait this isn't a grf providing the cargos
19:33:51 <andythenorth> this is base game cargos?
19:35:06 <peter1139> `if (grf_version < x) cargo_classes &= 0x1F;`?
19:36:29 <peter1139> What's the current grf version?
19:38:19 <andythenorth> where's grf version determined? 🙂
19:38:39 <peter1139> `uint16_t classes = cs->classes; if (object->ro.grffile->grf_version < 8) classes &= 0x1FF;`
19:38:46 <peter1139> Hacky workaround...
19:39:10 <peter1139> And var 0x42 only cares about the lowest 8 cargo classes anyway.
19:41:28 <Rubidium> so, basically you're saying that for every addition to the cargo classes we need to bump the GRF version?
19:42:07 <peter1139> No, this is a bad workaround that I'm just toying with.
19:42:27 <andythenorth> pff if it was cargo from grf....that would be fine
19:42:31 <andythenorth> "all bets are off"
19:42:55 <peter1139> We can't mask based on version alone as that would mean all current v8 grfs that use more than the original classes would break.
19:43:12 <peter1139> Maybe a compatibility flag like with dos/windows palette?
19:43:29 <Rubidium> I wonder if my workaround is worse... if NewGRF was added to the game in version < #12975, then classes &= 1FF, else let it be b0rked for not obeying the spec ;)
19:44:10 <peter1139> So if you start a new game it's broken? Hmm, interesting... :p
19:44:28 <_jgr_> The GRF version has been 8 for about 13 years now, it is not really a useful signal of newness
19:44:39 <peter1139> _jgr_, that was exactly my point.
19:45:18 <peter1139> (Also, I calculated the mask properly and it's 0x3FF, but the value is now irrelevant because it's done properly)
19:45:41 <peter1139> Hmm, allow/deny list?
19:45:50 <andythenorth> I'd just break FISH
19:45:57 <andythenorth> but players and author others....
19:46:03 <peter1139> And we got a bug report.
19:46:20 <peter1139> Not the first one, although the others are at least NewGRFs that are vaguely in development.
19:46:24 <Rubidium> or maybe take the superset of cargo classes in a NewGRF and use that for filtering? I would assume a vehicle NewGRF to cover all the cargo classes it knew of at the time of construction
19:47:02 <peter1139> Runtime-patch the NewGRF to test for classes properly? :D
19:49:19 <peter1139> That variable even existing in NML causes the problem...
19:50:35 <andythenorth> I'm not sure I'd have understood how it works
19:50:51 <andythenorth> I'd still write the same code in 2024 as 2012
19:51:09 <andythenorth> the nml looks like it's picking out a single bit for true / false
19:57:53 <LordAro> andythenorth: what about 2025?
19:58:04 <andythenorth> reading the nml spec
19:58:30 <Rubidium> obviously andy isn't writing code anymore, that's what LLMs do, right?
19:59:27 <andythenorth> the amount of nml written for me by LLMs is zero
19:59:35 <andythenorth> GPT wrote me a few python methods
20:00:20 <andythenorth> ach ok so the bitmask isn't checking for a specific bit being set
20:00:31 <andythenorth> dunno why I thought it would
20:00:41 <andythenorth> the nml docs for this are spartan
20:04:00 <andythenorth> so is the correct method `cargo_classes & bitmask(CC_LIQUID)`?
20:04:07 <andythenorth> then test boolean true for that?
20:05:04 <andythenorth> this is how Iron Horse detects tanker containers
20:05:04 <andythenorth> ` switch (FEAT_TRAINS, SELF, switch_spritelayer_cargos_${spritelayer_cargo.id}_generic_by_class_liquid, cargo_classes & bitmask(CC_LIQUID)) {
20:05:04 <andythenorth> 0: return switch_spritelayer_cargos_${spritelayer_cargo.id}_random_box_DFLT;
20:05:04 <andythenorth> return switch_spritelayer_cargos_${spritelayer_cargo.id}_random_tank_DFLT;
20:06:11 <peter1139> Yes. There may be other ways, but that will do the right thing.
20:29:10 <xarick> CreateRivers has that annoying /* Run tile loop to update the ground density. */
20:29:33 <andythenorth> I've found with Iron Horse, it's adding code for features that makes it slow
20:29:40 <xarick> gonna investigate whether I can get rid of it
20:30:14 <xarick> by ground density, I assume grass to desert transition
20:33:45 <xarick> SetClearGroundDensity exists
20:37:42 <xarick> actually it's desert to grass transition
21:28:55 <xarick> I need access to TileLoopClearDesert
21:29:04 <xarick> to make this more professional
21:45:33 *** duckfullstop has joined #openttd
21:45:33 <duckfullstop> quick fire question; did something change in the last couple of years to the default `PERSONAL_DIR` definition at build time? the `redditopenttd/openttd` container suddenly wants to start saving stuff to `PERSONAL_DIR/.config/openttd` even though `PERSONAL_DIR=/` has been set for yeaaaars
21:45:47 <duckfullstop> something to do with XDG possibly?
21:46:14 <_glx_> XDG is supported for a long time now
21:46:27 <duckfullstop> how long, like 5y+?
21:48:14 <duckfullstop> I mean, I note `docs/directory_structure.md:71-72`
21:48:14 <duckfullstop> ```When built with XDG base directory support, openttd.cfg will be
21:48:14 <duckfullstop> created in $XDG_CONFIG_HOME/openttd which is usually ~/.config/openttd.
21:48:58 <duckfullstop> _glx_: trying to avoid -c if at all possible, it feels like it should be possible to define at runtime?
21:55:45 <_glx_> yeah your cmake call seems correct
21:56:07 <duckfullstop> hence my grave confusion why this has suddenly broken at some point in the last year or two
21:56:35 <_glx_> if you can find exactly when
21:58:06 <duckfullstop> but that seems to just be a chore change to a for loop
22:00:15 <_glx_> hmm seems PERSONAL_DIR is not supposed to be a full path
22:00:24 <duckfullstop> [2025-01-05 22:00:01] dbg: [misc:1] /config/.config// found as config directory
22:00:24 <duckfullstop> [2025-01-05 22:00:01] dbg: [misc:1] /config/.local/share// found as personal directory
22:04:28 <_glx_> what is $XDG_CONFIG_HOME ?
22:05:52 <duckfullstop> curiously defining that makes it work as expected (stuff gets saved to /config) but the debug messages claim the same...
22:06:15 <_glx_> so $HOME should be used then
22:06:28 <duckfullstop> $HOME is defined correctly
22:08:10 <_glx_> `/config/.config//` is `$HOME/.config/$PERSONAL_DIR` (as set in DeterminePaths)
22:09:25 <duckfullstop> only `if (xdg_config_home != nullptr)` (`:887`)
22:10:02 <duckfullstop> otherwise it should be `${XDG_CONFIG_HOME}/${PERSONAL_DIR}`
22:10:03 *** kuka_lie has quit IRC (Quit: leaving)
22:10:06 <_glx_> yes that means no $XDG_CONFIG_HOME
22:12:11 <duckfullstop> okay defining that appears to give the intended results now
22:12:18 <duckfullstop> I dunno why it didn't work the first time around 🤷
22:12:28 <duckfullstop> ```[2025-01-05 22:11:27] dbg: [misc:1] /config/ found as config directory
22:12:28 <duckfullstop> [2025-01-05 22:11:27] dbg: [misc:1] /config/ found as personal directory
22:12:56 <_glx_> there are so many search paths defined via DetermineBasePaths
22:14:07 <duckfullstop> I kinda feel like it should be possible to override xdg more definitively with a build time flag
22:14:35 <_glx_> like SP_PERSONAL_DIR_XDG can be `$XDG_DATA_HOME/$PERSONAL_DIR` or `$HOME/.local/share/$PERSONAL_DIR`
22:14:42 <xarick> I got it right this time, I swear
22:15:40 <_glx_> then you also have SP_PERSONAL_DIR set to `$HOME/$PERSONAL_DIR`
22:19:45 <_glx_> oh actually DeterminePaths() might be wrong
22:22:08 <duckfullstop> would be kinda interesting to roll back to find out which version this functionality changed in
22:22:14 <duckfullstop> unfortunately I don't have infinite time at the moment
22:32:35 <peter1139> Weird. Has ability to create a NewGRF to fix an issue, but not the ability to... realise that isn't necessary.
22:34:35 <_glx_> yeah we provide our own grf just for original baseset (and outdated 3rd party ones)
22:35:24 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:45:12 <_zephyris> On that subject, anything I can do to get opengfx building with the new road waypoints?
22:46:26 <peter1139> Ah it needs a new NML release for OpenGFX to be able to build.
22:48:52 <_zephyris> 👍 That's what I suspected.
22:49:48 <_zephyris> (I'm still a total noob with make)
22:53:21 <peter1139> Have we 'vendored' OpenGFX 2 yet, anyway? :p
22:59:53 <_glx_> lol 8k*8k is not enough
23:02:47 <_zephyris> peter1139: Well... is it finished and bug free enough? 🤪
23:13:00 <LordAro> _glx_: duckfullstop: depending how old your previous version was, could be the change from libxdg-basedir to just reimplementing it? i.e. your possibly custom build wasn't built with xdg support
23:16:49 <reldred> _zephyris: Yes. I've long since thought it should have been the default shipped considering all the 14.0/14.x promo material was taken using OpenGFX2.
23:18:11 <duckfullstop> LordAro: Hm, it has occurred to me that it could well be a change to the underlying distribution (I just build against debian:latest-slim which probably isn’t a great idea…)
23:21:11 <_zephyris> reldred: It is pretty much there, not many bugs have turned up
23:25:46 <FLHerne> that is an absurdly large map
23:35:48 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:38:24 <reldred> oh! they like it,that's unexpected.
23:38:44 <reldred> it is indeed a new year full of new possibilities.
23:50:47 <FLHerne> eh, Zorg often has good ideas
23:51:12 <FLHerne> they're just a bit insistent sometimes
continue to next day ⏵
