IRC logs for #openttd on OFTC at 2023-12-11
β΄ go to previous day
00:03:51 <peter1138> Hmm, quite a bit of effort needed to stop them playing.
00:04:00 <peter1138> Threading is fun ;)
00:06:18 <peter1138> Although it does provide a bit more 'positive feedback'.
00:10:35 <xarick> the way noise increased level is calculated is... flawed?
00:10:59 <xarick> it is always in relation to the center of the town
00:11:38 <xarick> even if the town is gigantic and i place an intercontinental airport in the outskirts, the noise increased is just 1
00:12:40 <xarick> and I can't place more than 64000 stations π¦
00:13:32 <xarick> i may need to tweak the settings a bit
00:17:44 <peter1138> Build over part of the town, instead of around it.
00:17:53 <peter1138> Magic bulldozer etc
00:18:13 <peter1138> Then you can get closer to hit the limit.
00:30:21 <talltyler> I think itβs fine either way. I would expect them to end but not be surprised if they didnβt
00:33:04 <peter1138> > This value is only meaningful in the DOS version, where there are limited mixing channels.
00:33:18 <peter1138> Yeah, actually we only have 8 channels, which I consider limited.
00:36:03 <peter1138> Not that it matters :D
01:06:53 <Eddi|zuHause> 8 is practically infinite :p
01:12:47 *** D-HUND is now known as debdog
01:14:33 <peter1138> Remember when consumer-level soundcards could do hardware mixing...
01:37:53 <Eddi|zuHause> but software got faster :p
01:41:24 <peter1138> The menu "beep" sound is 810 bytes.
01:54:11 <peter1138> Also emscripten UI is broken. Nice.
01:54:32 <peter1138> Means initialization order is wrong :/
02:00:14 <peter1138> It seems like SetupWidgetDimensions() isn't called.
02:03:48 <peter1138> Fix: Don't implicitly ReInit all windows after updating the character width cache.
02:03:53 <peter1138> That broke it. Whew;
02:15:50 <peter1138> Yeah, because of course everything relied on LoadStringWidthTable having side effects beyond doing what it says it does.
02:17:20 *** Flygon has quit IRC (Read error: Connection reset by peer)
02:17:26 <peter1138> Also there's now two ways for windows to be resized on interface scale change because I forgot I already wrote one, it just didn't work for manual changes.
03:06:28 *** Wormnest has quit IRC (Quit: Leaving)
03:13:01 *** Artea has quit IRC (Remote host closed the connection)
03:38:26 *** DorpsGek_vi has joined #openttd
03:46:41 *** belajalilija has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** merni has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** gebik4544 has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** frosch123 has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** notluke2578 has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** emperorjake has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** johnfranklin has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** eratonysiad has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** locosage has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** bigyihsuan has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** truebrain has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** alfagamma7 has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** nairda00 has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** _pruple has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** _zephyris has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** xarick has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** _jgr_ has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** _glx_ has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** wensimehrp has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** michi_cc[d] has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** jfs has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** talltyler has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** peter1138[d] has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** andythenorth has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** brickblock19280 has quit IRC (Ping timeout: 480 seconds)
03:46:41 *** DorpsGek_vi[1] has quit IRC (Ping timeout: 480 seconds)
03:49:36 *** georgevb has quit IRC (Ping timeout: 480 seconds)
03:56:19 <peter1138> dbg: [misc] 3: +ClearFontCache (11)
03:56:26 <peter1138> So we like to clear the font cache I see.
04:01:05 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:03:32 <peter1138> God this is a mess.
04:21:56 *** DorpsGek_vi[1] has joined #openttd
04:30:01 *** DorpsGek_vi[1] has quit IRC (Ping timeout: 480 seconds)
04:35:42 *** D-HUND is now known as debdog
06:18:21 *** keikoz has quit IRC (Ping timeout: 480 seconds)
09:40:48 *** georgevb has joined #openttd
09:40:48 <georgevb> Where can I get station_list_colour and cargo_payment_list_colour for default cargoes?
09:56:53 <peter1138> Hmm, with #11552 the "station_list_colour" (13) is mostly irrelevant.
10:17:37 <peter1138> This version of Iron Horse has 400,000 NFO lines.
10:17:53 <peter1138> 399982 to be precise.
10:21:30 <peter1138> 5000 lines just for reordering the purchase list.
10:22:15 <peter1138> Variants is a bad feature.
10:26:02 <peter1138> When loading the intro game, any configured newgrfs are loaded to find out if they have town names.
10:26:44 <peter1138> If you have iron horse in your newgrf list, that takes time because skipping 400000 lines isn't quick.
10:30:34 *** andythenorth has joined #openttd
10:31:19 <peter1138> I'm wonder if there's a slowlution.
10:31:46 <peter1138> It's not that bad with a release build.
10:44:43 <peter1138> Is it acceptable to stall for ~100ms when opening a depot for the first time?
11:49:21 <peter1138> dbg: [misc] 3: +InitDepotWindowBlockSizes (15) [5343]
11:49:21 <peter1138> dbg: [misc] 3: -InitDepotWindowBlockSizes 2ms
11:49:29 <peter1138> Hmm, I guess that's not too bad, even in debug.
11:49:50 <peter1138> I think 100ms+ for a release build is when the sprites aren't already loaded.
11:52:05 <peter1138> Oh, that wasn't debug :D
12:16:50 <xarick> CmdExpandTown gets buggy at some point during the expansion. It stops placing houses, and instead only places roads.
12:17:18 <xarick> i think it reached some kind of limit
12:18:30 <xarick> gonna try the 2x2 layout next time
12:33:11 <peter1138> Be nice if we didn't load the intro game twice on start up.
12:33:25 <peter1138> We've made a dependency tree nightmare :/
12:34:40 <peter1138> e.g. it should be possible to load custom currencies and newgrf town name definitions behind the scenes without changing the newgrf config.
12:37:01 <peter1138> We call ClearFontCache 11 times to get to the intro menu.
12:44:31 *** _zephyris has joined #openttd
12:49:04 *** peter1138[d] has joined #openttd
12:49:04 <peter1138[d]> I have some SVG glyphs I already designed for window decorations...
12:49:11 *** talltyler has joined #openttd
12:49:11 <talltyler> My game is super slow to load the main menu and exit the GRF config window. Probably because I have a ton of GRFs in my folder. But it would be nice to not have to wait on it.
12:49:58 <talltyler> Does _jgr_ have any improvements to this or am I imagining that things load much faster in JGRPP?
12:50:09 <peter1138> Exiting the config window shouldn't be slow, unless you've changed the config in which case it then loads it all.
12:50:19 <peter1138> Are you using a debug build :p
12:50:37 <talltyler> Yes, I have usually changed something. Iβm running 13.4 from Steam.
12:51:16 <peter1138> If you have a lot of NewGRFs in your config, they are all loaded again even though they aren't used.
12:51:27 <talltyler> Not worth a bug report, just replying to your posts above about scanning many lines of code in Horse
12:51:30 <peter1138> As part of currency/town name detection.
12:51:41 <peter1138> Well, it's not really a bug.
12:51:51 <talltyler> What do you mean by βconfigβ in this case?
12:52:12 <talltyler> Ah, yes. Might be Horse doing that. π
12:52:24 <_glx_> Hmm maybe we could cache townname presence during newgrf scan
12:52:59 <talltyler> Why do we need to detect town names? So theyβre ready when we try to select them in genworld?
12:53:10 <talltyler> And currencies arenβt part of GRFβ¦?
12:53:29 <_glx_> Townnames need to be known for the menu
12:54:01 <peter1138> Not sure if they are preloaded though.
12:54:11 <peter1138> They might just be available only in game.
12:57:42 <_jgr_> talltyler: The MD5 step is parallelised, so the scan goes a bit faster, but it shouldn't otherwise be that much different in my branch
13:08:25 <talltyler> Ah, might be worth cherry-picking π
13:16:02 <LordAro> that's a lot of mingw specific code there
13:16:06 <LordAro> what's all that doing?
13:16:27 <peter1138> 2019, so probably pre-we-moved-everything-to-std-c++17
13:29:04 <peter1138> There might also be more commits after that that are in the main branch.
13:29:31 <peter1138> So more "rewrite so it's understandable, concise, and documented" rather than "cherry-pick"
13:30:41 <_glx_> as usual, will be easier to rewrite
13:40:19 <_glx_> nightly looks weird and crashes
13:41:38 <peter1138> Yes, that's what I'm working on :)
13:42:09 <peter1138> I found a few rabbit holes.
13:46:50 <rau117> merni: not bad as an option
13:46:50 <rau117> disgusting without the ability to return it to how it was
13:47:31 <Eddi|zuHause> rau117: sounds like windows.
13:47:36 <LordAro> i recognise that screenshot
13:50:23 <peter1138> Well it was handed to me ;)
13:51:21 <peter1138> 04:03 <@peter1138> God this is a mess.
13:51:34 <peter1138> 12:33 <@peter1138> We've made a dependency tree nightmare :/
13:51:51 <peter1138> Definitely a rabbit hole I fell in with this.
13:54:08 <_glx_> unexpected side effects are "fun"
13:58:28 <peter1138> For me it did not trigger becuase unless the blitter is forced, it is changed during start up. And that causes a ReInitAllWindows(), though it's triggered via GfLoadSprites, which is called during AfterLoadGame, etc...
13:59:39 <_glx_> at least I had an easy way to crash π
13:59:41 <peter1138> I was hesitant about just randomly adding calls everywhere, this seemed most appropriate.
14:01:20 <_glx_> nightlies are well tested π
14:01:39 <_glx_> 4 days to notice the issue
14:02:44 <peter1138> Do you have a blitter forced in your config?
14:03:54 <peter1138> Not sure why mine autochanges on load, but that was enough to hide this bug.
14:04:11 <_glx_> nope, blitter line is empty
14:04:33 <peter1138> Maybe because I'm using SDL1 with hw_accel off as well.
14:04:41 <_glx_> but hardware acceleration is off
14:04:59 <_glx_> (happens anytime openttd crashed)
14:05:45 <_glx_> because it assumes it was hw accel
14:06:26 <peter1138> ^ here's the initialization path it is following...
14:06:29 <_glx_> even when it's because I was debugging and kill it
14:06:36 <peter1138> Things are called... a lot :p
14:06:44 <peter1138> Including loading the intro game twice.
14:07:13 <_glx_> yeah intro loaded twice is a known thing
14:07:40 <peter1138> Format is depth, + means enter, - means leave, number in brackets is number of times it's been called, and 0ms is, well, time :)
14:08:05 <peter1138> Yes, it loads the intro game before newgrf scan so that you don't look at a blank blue screen.
14:08:27 <peter1138> Then it loads the intro game again with your newgrf config once the scan is complete.
14:08:38 <_glx_> load intro, scan grf, reload intro
14:08:50 <talltyler> Intro game canβt have GRF, so does it really need to be reloaded?
14:08:51 <peter1138> But if you don't reload the intro game again, it crashes because game settings are wrong.
14:08:52 <merni> peter1138: but does intro game even use grfs?
14:09:08 <peter1138> talltyler, it's because of the town-name scna :)
14:09:24 <peter1138> 13:51 <@peter1138> 12:33 <@peter1138> We've made a dependency tree nightmare :/
14:10:07 <merni> couldn't the town names be detected when the world generation screen is opened?
14:10:27 <peter1138> Possibly but then you'd spend seconds opening the new game window.
14:10:28 <merni> I feel like creating a new world would be a lot less frequent action than just opening the game for most
14:10:42 <_glx_> town names used to be available in option window
14:10:47 <merni> peter1138: as opposed to the same seconds when loading the game each time?
14:11:10 <peter1138> merni, you don't notice it because it's happens once just after the newgrf scan is complete, which already takes time.
14:11:22 <peter1138> Same with the depot block size init...
14:11:31 <peter1138> 10:44 <@peter1138> Is it acceptable to stall for ~100ms when opening a depot for the first time?
14:11:47 <peter1138> Those 100+ ms are hidden by everything loading at start (or in that case on new game)
14:12:06 <peter1138> You would notice them when you open a depot and the game glitches...
14:12:37 <merni> Okay but the whole grf scan procedure takes only a few seconds. Checking for town names must be only a fraction of that; which I feel is OK on world gen screen
14:13:02 <merni> Depot is a different matter because players would probably click a depot every time they play the game, unlike with generating a world
14:13:02 <peter1138> Not quite, grf scan only checks md5sum, checking for town names has to parse the content of the GRF as well.
14:13:24 <_glx_> oh the scan can be slow (it's faster now with my new pc)
14:13:28 <merni> In that case if we can make grf scan significantly faster by omitting this that's an even bigger win
14:13:37 <talltyler> Whatβs the depot scanning for?
14:13:53 <merni> maybe a progress-bar before opening worldgen so people don't get confused by the delay
14:14:04 <peter1138> talltyler, to ensure the size of the depot is correct, it checks the sprite of every engine in the game.
14:14:11 <peter1138> If you have Iron Horse loaded, that's a lot of engines...
14:14:20 <talltyler> Because of different heights?
14:14:29 <peter1138> That's a "variants are a bad feature" that I didn't think of ;)
14:15:21 <talltyler> Depot init just happens when loading a game, right? You canβt click depots in the title game.
14:15:21 <peter1138> And it's not even correct technically as it can't processes all the different graphics chains, it only knows what it seen as the default sprite.
14:15:31 <_glx_> well looking for actionF finals in huge grfs like FIRS is already a problem
14:15:52 <peter1138> Well, incorrect, it happens earlier anyway, because of the dpendency mess.
14:16:19 <merni> could it be done as part of loading the save?
14:16:41 <andythenorth> can't the grf supply metadata (or bananas do it)?
14:16:49 <merni> and perhaps that could limit to only grfs that are actually used
14:16:50 <peter1138> merni, it depends in gui zoom too.
14:17:36 <merni> andythenorth: If the grf author supplies wrong metadata things may look wonky :p
14:17:50 <andythenorth> no the compiler would do the metadata π
14:17:52 <merni> peter1138: Ok, but isn't gui zoom known at the time of loading a save?
14:17:52 <_glx_> never trust newgrf authors π
14:17:55 <peter1138> merni, the depot scan is never an issue
14:18:05 <peter1138> merni, gui zoom changes when you change gui zoom...
14:18:10 <_glx_> they usually have silly ideas
14:18:50 <peter1138> merni, the depot scan on the intro game is nothing because there's only the default graphics loaded
14:18:50 <talltyler> Can confirm, am NewGRF author π
14:19:14 <peter1138> It only takes longer with something like Iron Horse, and of course then it only happens when you are loading the game anyway. Or changing gui zoom.
14:19:25 <talltyler> Yesterday I tried to make a train produce both steam and sparks, but itβs not possible to use two generation modes (puffing and random sparks)
14:20:00 <merni> peter1138: Alright that makes sense. In that case I don't think it makes sense to shift it to when first opening a depot
14:20:31 <talltyler> Wait, what happens every time you change GUI zoom?
14:20:37 <merni> The town name thing still feels weird that it needs to be done on starting OpenTTD rather than on opening the worldgen window though, if that significantly impacts the time taken for grf scan
14:20:53 <peter1138> Yeah, basically I was looking at deferring it to avoid having to do it unnecessarily, but it turns out that deferring it is more annoying than having to wait when you do need it.
14:21:11 <peter1138> merni, it's about 1 second. It's not massive.
14:21:21 <peter1138> And that's only if yuou have a lot of large NewGRFs loaded.
14:21:40 <peter1138> Also release/no asserts is quicker still.
14:22:06 <merni> In that case it could be even better pushed to the worldgen menu (if a progress bar is possible there); saving 1 sec on 90% of times you start the game :P
14:22:28 <merni> I get that it might not be worth the effort though
14:22:31 <peter1138> No because if you *don't* reload the intro game the whole thing crashes anyway
14:22:40 <peter1138> So I didn't bother looking further.
14:23:21 <peter1138> I'm not sure why. There's a division by zero due to a game setting, which I think means settings are not applied, but I don't know why it needs the reload for that to work.
14:23:26 <merni> [18:03] BOT peter1138: We've made a dependency tree nightmare :/
14:24:58 <peter1138> I could set that up on a timer...
14:27:59 <peter1138> ^ Now the preview build might be useable :)
14:30:46 *** berndj has quit IRC (Remote host closed the connection)
14:42:47 <_zephyris> Can I force OpenTTD to let me do this stupid thing?
14:47:09 <_glx_> of course with vanilla compatible is always the same
15:21:25 <peter1138[d]> _zephyris: there shouldn't be too much outside of plain ASCII that is needed though.
15:22:00 <peter1138[d]> The debug console should tell you what glyph it was trying and failed to find.
15:22:26 *** Extrems has joined #openttd
15:23:29 <_zephyris> 0x28, open parenthesis
15:23:47 <_zephyris> Yeah, getting the core ASCII set together should be fine
15:23:52 <_zephyris> At least for testing
15:24:36 <merni> you could also have some placeholder boxes in the font for things you haven't drawn yet
15:24:41 <peter1138[d]> Hmm, you could try changing strings.cpp:2122 from true to false π
15:25:22 <xarick> squared_town_zone_radius[0], the 0 has a name, it's HZB_TOWN_EDGE
15:25:32 <xarick> shall I make a PR and change numbers to names?
15:26:00 <peter1138[d]> No because that's not right.
15:26:50 <peter1138[d]> Oh maybe they were. I've looked at that before and decided not to. Maybe there was some other thing holding it up.
15:27:43 <_glx_> yeah the enum seems right
15:28:50 <_zephyris> merni: Good point, I'll just link the space character
15:29:27 <_glx_> static const uint32_t _town_squared_town_zone_radius_data[23][5] = { <-- the 5 should be HZB_END then
15:29:59 <_glx_> _zephyris: use ? not space
15:30:30 <_glx_> ? is the usual missing glyph one
15:32:24 <_glx_> but a distinct specific one might be a good idea too
15:32:28 <xarick> newgrf town stuff has lots of uint32 being clamped to uin16 π¦
15:32:32 <_zephyris> Haven't made that one yet!
15:34:09 <_glx_> xarick: required to match newgrf specs
15:37:16 <peter1138[d]> Overall geometry needs tweaking a bit.
15:38:06 <peter1138[d]> Too much space above the text. It looks centred, but it's not actually meant to be π
15:38:25 <merni> Is pen D a better game than openttd?
15:39:00 <Eddi|zuHause> otherwise you'd have heard of it before
15:39:11 <peter1138[d]> If the geometry is wonky then it might look okay but things like the vehicle type indicators in station signs will be off.
15:39:53 <Eddi|zuHause> anyway. russian? hebrew? arabic? japanese?
15:42:09 <Eddi|zuHause> also, if the german translation of "chinese" is "chinesisch", why is the translation of "japanese" not "japanesisch", but "japanisch"?
15:42:40 <merni> because languages are not logical...
15:43:56 <merni> why does english have "japanese", "chinese" but not, say, "philippinese" or "francese"
15:45:50 <_zephyris> peter1138[d]: The main visual distance is the line height, geometry is surprisingly close rendered at 1x
15:45:58 <_zephyris> It's 12px font, gaining 2px above the text.
15:46:16 <peter1138> If you can avoid gaining 2px above the text, that'd be nice :)
15:46:16 <_zephyris> I've designed it aligned on 2px descender, 8px ascender, 2px space for diacritics at the mo. Really it should be a 10px, with no head space for diacritics
15:47:09 <_zephyris> Yeah, that's my internal struggle. Nice diacritics vs. original line height
15:47:36 <peter1138> FreeSans manages to do it by having the diacritics overflow. Hmm.
15:48:00 <_zephyris> Yeah, drawing out of the 1em height bound is fine, but can clip weirdly
15:48:09 <_zephyris> TBH depends on OpenTTD font drawing behaviour
15:48:22 <_zephyris> This isn't one to test in Office and Adobe π
15:48:23 *** johnfranklin has joined #openttd
15:48:23 <johnfranklin> LordAro: odd art
15:49:50 <johnfranklin> merni: The suffix -ese is mostly from Portuguese, IIRC
15:50:15 <peter1138[d]> Overflowing *seems* to sort of work.
15:50:29 <peter1138> Not much of an overflow though.
15:50:34 <_zephyris> It's how OpenGFX1/2 does it too
15:50:35 <merni> how about in, say, the town list
15:51:01 <merni> or with those vietnamese letters with lots of diacritics
15:51:51 <Eddi|zuHause> original TT had a weird input bug where you could type ΓΓΓ but not Àâü (but it would display fine in autogenerated names)
15:52:22 <xarick> isn't 0 << 16 still 0?
15:52:46 <LordAro> xarick: i'd expect so
15:53:30 <peter1138> Usually done for consistency.
15:54:17 *** gelignite has joined #openttd
15:54:31 <Eddi|zuHause> xarick: sometimes structural operations like that are maintained because it's clearer to the reader what was originally meant
15:55:18 <peter1138> if HZB_TOWN_EDGE is changed, it'll still work.
15:55:22 <Eddi|zuHause> xarick: to avoid "magic numbers"
15:55:27 <peter1138> (Although in this case it would end up being incompatible, etc...
15:55:45 <LordAro> xarick: i can promise almost any compiler will optimise that operation away
15:55:50 <LordAro> not that it would be slow anyway
15:55:57 <LordAro> computers are pretty good at bitshifting
15:58:48 <Eddi|zuHause> xarick: there is a difference between the meaning of a value and the numerical representation of the value. here the logical meaning is emphasised.
15:59:35 <Eddi|zuHause> a simple "return 0" would do the same thing, but it would obscure the meaning
16:00:31 <Eddi|zuHause> like, a person searching the code for HZB_TOWN_* would miss this function
16:01:57 <Eddi|zuHause> and like LordAro said, even the most basic compilers nowadays recognize this being 0, and simplifies the code.
16:03:23 *** Wormnest has joined #openttd
16:04:58 <xarick> I wonder how many other 0's are there which already have a name
16:14:24 <_glx_> and some times the "wrong" constant is used
16:19:14 <xarick> They are referring to HouseZoneBits. Do I add HZB_END inside the []'s?
16:19:44 <xarick> Like this: _town_road_types[HZB_END][2]
16:20:43 <peter1138> Oh you mean for the definition. Yeah you could.
16:35:02 <_glx_> it would be safer, in case a new zone is added
16:36:06 <LordAro> (something something when all you have is a hammer something something)
16:36:21 <_glx_> every tool has a hammer side
16:40:00 <xarick> gonna ask bing chat for a commit message, cus i'm bad
16:43:13 <xarick> > Change magic numbers to their respective names
16:43:13 <xarick> > Replace all magic numbers in the code with named constants to improve readability and maintainability.
16:46:55 <peter1138> ALL magic number? Uh huh...
16:47:26 <talltyler> `Codechange: Use town zone constants instead of magic numbers`
16:47:36 <talltyler> Donβt overthink it π
16:48:09 <merni> things like "to improve readability and maintainability" should be in "motivation"/"description" of PR and not in commit message, imo
16:48:29 <merni> but then it seems generative "ai" cannot avoid verbosity
16:50:34 <peter1138> The solution is to avoid this llm "ai" bollocks.
16:51:20 <merni> but a lot of people need to write boring text and can't be bothered to do it themselves
16:52:30 <peter1138> Articificial andythenorth
17:06:56 *** Smedles has quit IRC (Remote host closed the connection)
17:08:10 *** Smedles has joined #openttd
17:19:00 *** virtualrandomnumber has joined #openttd
17:20:37 <xarick> DonaldDuck313viaGitH: refitted mail capacity should be halved, honestly
17:22:32 <xarick> when using those vehicles that can refit to multiple types of cargo, they end up with ridiculous amounts of mail capacity
17:28:55 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
17:30:31 <xarick> it grows roads way past the houses
17:32:09 <peter1138> Becuase you keep telling the city to grow unnaturally.
17:55:24 <talltyler> truebrain: If we can get a build of #10543 (new ship pathfinder), I can arrange and host a community game this weekend. I accidentally broke it trying to fix a simple conflict just now though :/
17:55:53 <talltyler> Why does web conflict resolver do a merge commit with no option to change? :widdle_goblin:
17:56:03 *** truebrain has joined #openttd
17:56:03 <truebrain> so you ping me to tell me to do nothing?
17:56:40 <talltyler> Just seeing if you are available for this later π
17:56:47 <truebrain> I am awesome at doing nothing myself, no need no help, tnx π π
17:56:58 <truebrain> you can trigger a build too π
17:57:01 <talltyler> I am going to a meeting, but will try to fix the merge commit later today
17:57:10 <talltyler> I only know the preview tag
17:57:32 <truebrain> Actions, Release, start a new job, follow the "blabla for PR"
17:57:38 <truebrain> or ask glx, if I am not around, he can tell you too
17:57:43 <talltyler> OK, will look later
17:58:33 <LordAro> truebrain's so efficient
17:58:37 <LordAro> doesn't even have to do anything
17:59:22 <truebrain> a skill you can't learn young enough π
17:59:31 <peter1138> I have never used that web conflict resolver...
18:00:12 <truebrain> for good reason it seems
18:18:21 *** HerzogDeXtEr has joined #openttd
18:26:31 *** locosage has joined #openttd
18:26:31 <locosage> lol, I only just noticed there is a slope steepness setting
18:26:38 <locosage> contemplating setting it to 0 on all servers now
18:28:37 <_glx_> truebrain: yeah it's very easy to do, there's even instructions on what to write in the trigger itself
18:29:05 <peter1138> Hills are a BAD FEATURE?
18:31:25 <_glx_> oh and nightly failure rate is not too good
18:32:14 <merni> where is it "night" now
18:32:25 <merni> are nightlies defined with respect to Asia
18:32:48 <_glx_> seems actions have some communications issues
18:33:36 <_glx_> yesterday it was during signing of arm64 windows build, the previous fail was when uploading to CDN
18:39:44 <DorpsGek> - Update: Translations from eints (by translators)
19:29:41 <peter1138> Alright, looking for a NewGRF with lots of sounds...
19:31:29 <merni> I think BRTrains has a good few
19:33:58 <peter1138> Maybe it "hallucinated" that as a good route.
19:35:08 <peter1138> Also choosing, in 1997, a model designed in 1922.
19:37:08 <peter1138> Anyway, 105KiB used. Not much.
20:07:16 *** gelignite has quit IRC (Quit: Stay safe!)
20:30:07 <_glx_> yeah nightly failed again, this time it was signing macos build
20:30:29 <_glx_> /Users/runner/work/OpenTTD/OpenTTD/build-x64/_CPack_Packages/x86_64/Bundle/openttd-20231211-master-gb62fafc5d4-macos-universal/OpenTTD.app: timestamps differ by 237 seconds - check your system clock
20:37:51 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:40:58 <xarick> oh, NewGRF define the multipliers for cargo refits?
20:41:27 <xarick> then those mail trains...
20:41:46 <xarick> erm, forgot the name, it's made by andythenorth,
20:43:43 <peter1138> So the default multipliers are a bit whacky though.
20:43:49 <peter1138> And FIRS seems to stick with them.
20:44:44 <peter1138> that means if you refit a goods van to food it drop you get 100/200 * 25t, so 13t
20:45:05 <xarick> mail pays too well in vanilla
20:45:06 <peter1138> It's working by design. Maybe the design is off?
20:45:30 <peter1138> Default food wagons take 25t
20:45:44 <peter1138> So refitting gies you less than a native wagon
20:47:42 <peter1138> And you can't use the default food wagon because that's not available in temperate.
20:50:40 <xarick> when I was working with my AI chosing best mail wagons, it always picked those that have a ton of capacity after reffitting from goods, the NewGRF is Iron Horse
20:51:28 <peter1138> Maybe it makes sense to enable wrong-climate wagons if the its native cargo type is made available, but... that's kind of a breaking change.
20:51:40 <xarick> the capacity feels adequate for goods, given the other properties like costs, price, but then the mail refit makes it kind of broken OP
20:53:53 <peter1138> I think the maybe the multipliers originally came from what aircraft do.
20:55:50 <xarick> it's half in the original game
20:57:19 <xarick> where do you find those multipliers?
21:14:37 <talltyler> Okay, time to build a release of the PR, I guess
21:16:34 <talltyler> Uh, where does this end up?
21:16:48 <talltyler> I'm not doing something bad to Steam, am I?
21:17:05 <_glx_> no it will be on the CDN
21:21:46 <_glx_> that's the result when I do it on my fork (fails to upload of course), but you can see it skips some steps
21:22:10 <talltyler> Ah man, it doesn't work π¦
21:22:20 <talltyler> I mean, the PR doesn't pass CI
21:23:12 <_glx_> preview workflow failed
21:24:05 <_glx_> strongtype related it seems
21:24:19 <talltyler> static_cast to base() I bet
21:24:59 <talltyler> Wonder if I can fix it myself, or if I need to ask Kuhnovic to fix again... π¦
21:25:15 <talltyler> I feel bad, this is the second time we've asked for a rebase to run a test game
21:28:10 <_glx_> yeah CI failed too, waiting on mingw which should also fail
21:33:10 <talltyler> I am working to fix it
21:33:50 <talltyler> Thankfully it's only one commit so I don't have to organize my fixes
21:34:36 <talltyler> It builds locally, let's see if it passes CI this time π
21:38:09 <peter1138> Quite a bit of feature creep :o
21:38:31 <peter1138> (In 11566, not 10543 :))
21:41:01 <_glx_> I replace all static cast with .base() locally
21:41:54 <_glx_> seems you did the same π
21:43:58 <talltyler> I like base() so much better than static casts
21:46:09 <_glx_> it's shorter, and ensure we don't randomly cast
21:49:03 <peter1138> Yeah, with the cast if you make a mistake it's kinda hidden... because it's a cast.
21:49:45 <peter1138> Hmm, now... what to do with catcodec/grfcodec/nmlc, etc...
21:50:57 <peter1138> For catcodec I bodged it to just not manually read/write the wave header, it just plonks the file straight. No validation.
21:51:28 <peter1138> Maybe there's a simple way to validate an MP3 header.
21:54:23 <peter1138> Hmm, although OpenTTD can read the file, catcodec can't unpack it :D
21:55:49 <peter1138> Ah because ReadSample expects to find the file size in the header, but it doesn't read the header, so I lazily just took the size of the file. Which is fine for encode but not for decode.
22:08:31 <peter1138> Not sure how I'd add libmad to emscripten.
22:09:11 <_glx_> not easy if it's not already supported
22:09:46 <_glx_> IIRC we don't have sounds anyway on previews
22:10:39 <_glx_> oh of course CI failed, but it's the annotations
22:11:40 <_glx_> I think you can retrigger a pr release talltyler
22:12:47 <peter1138> Oh if there's no sound then I won't put any effort in to it :)
22:30:31 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:37:07 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:57:49 <talltyler> Of course we don't have a boolean button widget and the ones in the Settings menu are special...
22:58:30 <talltyler> Time for a dropdown with two items π
22:59:03 <peter1138> They are not that special?
22:59:32 <peter1138> There are toggle buttons in the Game Options window.
23:01:03 <peter1138> Or you can just use DrawBoolButton()
23:01:26 <peter1138> No particular need if it's real widget though.
23:02:25 <talltyler> Actually, a dropdown is probably better
23:02:33 <peter1138> Maybe I should fix "SETTINGS_BUTTON_WIDTH" and "SETTINGS_BUTTON_HEIGHT" which are... not actually constants.
23:02:51 <peter1138> A bit like the recently deceased FONT_HEIGHT_NORMAL.
23:03:29 <peter1138> Maybe I should stick to what I was doing.
23:03:38 <xarick> is this formula for the perimeter always correct? I'm trying to come up with one
23:03:38 <xarick> `perimeter = 2 * (x + y) - 4`
23:04:51 <_glx_> that's for a rectangle I think
23:05:15 <xarick> something akin to AirportGetNearestTown
23:06:15 <xarick> I wanna iterate only the perimeter tiles, but I'd like to assert in the end that all the tiles iterated are counted correctly
23:07:14 <xarick> x and y are the width and height of the rectangle
23:07:49 <xarick> x * y is the total number of tiles in the rectangle
23:08:50 <xarick> looks like the formula is incorrect π¦
23:09:05 <xarick> for a helipad, x and y are 1
23:09:26 <xarick> 2 * (1 + 1) - 4 = 0, should be 1
23:15:59 <xarick> bing chat doesn't know either π¦
23:18:18 <xarick> screw the assert... I can't do it
23:58:17 <talltyler> I should stop working tonight, I'm just digging a hole for myself tomorrow π
continue to next day β΅
