IRC logs for #openttd on OFTC at 2023-12-07
⏴ go to previous day
01:19:56 <bigyihsuan> is there a command to force restart a game script?
01:32:39 <Rubidium> don't think such a command exists (yet)
02:13:45 *** keikoz has quit IRC (Ping timeout: 480 seconds)
03:29:21 *** Wormnest has quit IRC (Quit: Leaving)
04:04:51 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:51:32 *** thelounge345 has joined #openttd
04:56:53 *** thelounge34 has quit IRC (Ping timeout: 480 seconds)
04:56:53 *** thelounge345 is now known as thelounge34
06:44:52 <_pruple> looks like it's catching andythenorth
06:55:31 <_pruple> bigyihsuan: newmap or reload?
07:18:36 <andythenorth> _pruple: Improved, IMHO 🙂
07:29:57 *** tokai|noir has joined #openttd
07:29:57 *** ChanServ sets mode: +v tokai|noir
07:36:55 *** tokai has quit IRC (Ping timeout: 480 seconds)
08:15:15 *** jlx__ has quit IRC (Read error: Connection reset by peer)
08:15:26 <peter1138> So it worked until it was ... fixed.
08:19:16 <andythenorth> it works great for me 😛
08:19:22 <andythenorth> accidental improvement?
08:22:18 <peter1138> If it's broken does that make replacing it with cargodest easier?
08:22:42 <andythenorth> just ship it like this for a year, see what happens?
08:47:35 *** jlx__ has quit IRC (Read error: Connection reset by peer)
10:38:16 <pickpacket> I'm listening to the OpenTTD portion of the jingle jam stream from Dec 1st (can't watch; working) and I just want to plaaaaaay
10:48:20 <LordAro> pickpacket: or do you just want to drink gin and crash trains?
10:56:07 <xarick> `ODATFB_NEAREST_DEPOT`is in 20 places
11:24:08 <peter1138> Dear window, stop getting wider.
11:49:53 <pickpacket> LordAro: I don't drink alcohol and I prefer it when my trains don't crash :)
11:59:26 <xarick> ` if (v->current_order.GetDepotActionType() & ODATFB_NEAREST_DEPOT) {
11:59:26 <xarick> if (v->dest_tile != 0 || TimerGameTick::counter % Ticks::DAY_TICKS == 0) {`
11:59:26 <xarick> this kind of fixes the issue
12:02:06 <xarick> though it may break "legitimate" v->dest_tile == 0
12:03:05 <xarick> that 0 is being abused for so many purposes
12:05:42 <truebrain> frosch123: see ^^ and info@ mailbox 🙂
12:15:06 <pickpacket> is there such a thing as an optimal station design?
12:22:51 <peter1138> I've been refactoring all morning, this is annoying :(
12:42:40 <FLHerne> pickpacket: definitely not in general. If you rigorously specify the requirements there must logically be one for each situation
12:43:05 <FLHerne> most "optimal" designs are poor for my purposes because they look ugly :p
12:44:18 <pickpacket> FLHerne: The situation I find myself in *all the time* is that trains have to wait for other trains at some point. Usually at merges
12:46:50 <peter1138> Optimal design: One line and one platform at each station per train.
12:47:50 <FLHerne> I don't think that's really avoidable leaving a station, except by thorough timetabling
12:48:25 <pickpacket> timetabling won't work because I really need all platforms to have a loading train at them at all times
12:48:27 <FLHerne> priority merges are useful on mainlines where there's an advantage to not stopping trains on one line over another
12:48:48 <FLHerne> but doesn't apply to stations
12:49:17 <FLHerne> just make sure the merges are as localised as possible (start/stop is a waste of time) and ideally waiting space between platforms and the merge
12:50:19 <FLHerne> if very serious you can use various magic openttdcoop devices to distribute trains evenly across lines but I rarely find it's worth doing
12:51:03 <FLHerne> by 'localised', I mean if you have 4 platform lines merging into one exit line, just do that at one point rather than 4->2->1 or something
12:55:04 <Eddi|zuHause> i once tried to solve a maglev merge by timetabling, that is crazy tedious
12:55:45 <peter1138> Trains do wait in real life, so... maybe it's realism? :D
12:57:59 <bigyihsuan> _pruple: Height map > save > renamed scn > deleted towns > saved as scn > renamed sav > load game
13:00:14 <peter1138> Oh, you can't load a heightmap into the scenario editor?
13:01:13 <peter1138> bigyihsuan, Scenario Editor -> Disk Menu -> Load Heightmap.
13:01:44 <peter1138> Right, have I sorted out this window by unifying the code?
13:01:56 <bigyihsuan> I did it this way so i could get trees generating map-wide
13:02:26 <bigyihsuan> If there is a button to generate trees map-wide in the scenario editor, I can't find it
13:06:21 <emperorjake> bigyihsuan: It's right there
13:06:26 <Eddi|zuHause> i thought there was a "place many trees" button
13:06:53 <LordAro> it could have a clearer name
13:07:26 <Eddi|zuHause> but does that button run the same tree algorithm as the map generation?
13:07:31 <emperorjake> Perhaps it should be "many random trees" to match "many random industries/towns"
13:09:57 <bigyihsuan> Speaking of the scn editor it'd be nice of it showed the world gen progress bars instead of freezing
13:10:38 <peter1138> No, it's not the same as map generation.
13:10:49 <peter1138> It's part of what map generation uses.
13:16:08 <pickpacket> what's "Remove all trees"? I've never seen that one
13:19:46 <peter1138> JGRPP I would assume.
13:20:07 <peter1138> Or locosage... he hates trees.
13:20:16 <peter1138> Although if it was his there'd be no tree menu at all.
13:21:34 <peter1138> Well, I did all that and still the window gets wider :o
13:35:23 <locosage> I like trees, I don't like the overhead they come with :(
13:42:20 <peter1138> It really eats into the terabytes of storage I have.
13:45:14 <locosage> It mostly matters in multiplayer
13:45:23 <locosage> And for game archives
13:47:27 <locosage> On empty maps trees take like 9/10 of the save size iirc
13:48:26 <locosage> As there aren't any other significant sources of entropy
13:49:25 <locosage> Heightmap is like 1 bit/tile and houses/industries are too few to matter
13:50:35 <_zephyris> Could always make it worse... Trees NewGRF anyone?
13:51:31 <locosage> Well, I have an idea how to newgrf them without extra storage overhead
13:53:38 <locosage> Basically #11263 can be newgrf'ed
13:54:24 <locosage> Though it would be nice to figure out a way to make growing tress procedural too first
13:57:36 <xarick> Why do these colours feel washed out?
14:01:47 <peter1138> Forgot the title :D
14:21:03 <talltyler> Definitely splitty split 🙂
14:33:16 <xarick> looks better, doesn't it? HDR is off now
14:36:49 <_zephyris> Interesting. I think it _looks_ bright/washed out on my Win 11 laptop, but screenshots work fine.
14:37:00 <_zephyris> How did you disable HDR? I'll check
14:40:36 <xarick> somewhere in windows definitions screen
14:44:44 <peter1138> How much splitting I wonder.
15:16:19 <xarick> oh well, looks like HDR was a mistake
15:16:49 <peter1138> I bet you notice a big different when playing video though...
15:17:04 <LordAro> sounds like some sort of misconfiguration or incompatibility somewhere
15:28:56 <peter1138> Hmm, I think the other changes will conflict without #11533.
15:33:17 *** Wormnest has joined #openttd
16:03:41 <FLHerne> looking at the NewGRF download list after a couple of years not keeping up, this is absurd
16:04:30 <FLHerne> it's just an immense list of random content with no way to tell which are new, good, or in any way relevant
16:04:47 <FLHerne> [and no I don't have a solution for that :-( ]
16:10:52 *** gelignite has joined #openttd
16:12:43 <xarick> okay, I turned hardware acceleration on OpenTTD, and now the screenshots are captured with correct colors
16:16:47 <xarick> is it a bug in OpenTTD, or on windows or AMD being sucky? what is it?
16:18:06 <peter1138> Hmm, maybe I should rework that last one.
16:18:13 <peter1138> xarick, it's not a bug in OpenTTD.
16:21:30 <LordAro> peter1138: tbh, i'd have said don't split
16:21:51 <LordAro> these PRs are falling down the hole of "changes for changes sake"
16:22:13 <talltyler> Even though we know they’re building toward something else?
16:22:32 <peter1138> The reason I "split", is because I think the initializer changes work better in the *next* change :)
16:22:50 <LordAro> it's not too much more effort to review per-commit rather than per-PR
16:23:02 <LordAro> we know they're building toward something now, but in future? less obvious
16:23:17 <peter1138> Because in the next change, the parameters and members of the class get changed, so what that commit changes it to is not useful anyway.
16:23:18 <talltyler> #11554 is definitely a standalone improvement
16:24:00 <LordAro> it's a tricky distinction to get right, for sure
16:24:12 <talltyler> #11553 too, although maybe it’s not noticeable until the new dropdown list type gets added
16:24:26 <LordAro> many of my work MRs have "other stuff i noticed along the way" in them, that aren't strictly necessary but help things along
16:24:33 <xarick> I can't show you a screenshot how it looks like by watching at the screen, unless I bring a camera, but I can tell that the colours on the right are slightly more vivid than that of the left, but not to that degree the screenshot portrays it. Maybe I need a camera shot at the monitor
16:24:37 <LordAro> which inevitably get blocked by something else
16:24:50 <LordAro> (MR because gitlab ;) )
16:25:36 <LordAro> even then, half of my MRs seem to get stuck - of 54 currently open MRs, 9 of them are mine
16:28:46 <peter1138> Okay, so let's skip this one, and make a larger one for all the initialization changes.
16:33:14 <peter1138> Description updated.
16:34:14 <peter1138> This is, indeed, change for change sake, but I think the new initialization is a bit clearer.
16:37:21 <peter1138> But, uh, that's just me :-)
16:39:26 <peter1138> Right, now I know this Doom level requires setting up in-fighting because last time I ran out of ammo :o
16:50:01 *** gelignite has quit IRC (Quit: Stay safe!)
17:03:29 *** HerzogDeXtEr has joined #openttd
17:04:12 <peter1138> Oops, terrible reviewer.
17:06:05 <LordAro> feels like that could be a compile time assert
17:07:32 <talltyler> Hmm, if OrderBackup inherits from BaseConsist, it could be nice if it could inherit saveload stuff too.
17:07:40 *** virtualrandomnumber has joined #openttd
17:08:05 <talltyler> (My computer is in a box preparing to move house tomorrow, so I cannot look at it right now)
17:09:48 *** virtualrandomnumber has quit IRC ()
17:11:00 <peter1138> Hmm, those ticks being unsigned means my negative start year patch isn't going to work ;)
17:15:50 <peter1138> Hmm, I can't seem to trigger the assert.
17:17:16 <_jgr_> An easy way to do it is to use multiplayer, have another client join after you've just created an order backup
17:21:21 <peter1138> Damn, I was hoping a bump wasn't needed but it seems it is :/
17:21:50 <peter1138> (As the table header is saved whether or not there's any data in it, and without a bump it's different)
17:31:17 <xarick> PNG doesnt support HDR?
17:31:33 <xarick> maybe that's why the images come fuzzy
17:34:01 <talltyler> Does it need a new SaveLoadVersion since nothing could be saved since the last one?
17:37:21 <peter1138> Yes, I wrote that here not long ago :)
17:38:13 <talltyler> Oh wow reading comprehension fail
17:38:36 <talltyler> In that case, I assume you’ve tested (since I cannot)?
17:41:26 <_zephyris> xarick: PNG can do up to 16bit IIRC, not sure if that's RGB or grayscale though
17:44:53 <talltyler> Thank you for fixing my bug
17:47:17 *** virtualrandomnumber has joined #openttd
18:09:14 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
18:17:03 <peter1138> Only been broken for a 10 months ;)
18:17:25 <talltyler> I guess that shows how many people use nightly
18:18:39 <_glx_> well I was checking the broken commit before approving
18:19:19 <talltyler> Yeah, I looked at that too. I have no idea what restricted vs unrestricted means, but the broken commit clearly shows the error 🙂
18:19:41 <_glx_> easy to do mistake, hard to spot
18:20:32 <talltyler> I have been known to make mistakes before 😛
18:21:25 <_glx_> oh not the first time (nor the last) we'll miss this kind of stuff when reviewing
18:22:02 <_jgr_> Restricted vs unrestricted is to do with vehicles can load at source node or not
18:23:53 <peter1138> I'm implementing a compile time SL variable size check.
18:23:55 <peter1138> And there's one that's wrong.
18:24:02 <peter1138> (Other than just fixed.
18:24:25 <peter1138> No, it's a brainy one ;)
18:26:01 <talltyler> Well, if we all approved…who’s going to merge? Is there a LordAro around here still? 😛
18:26:18 <truebrain> pinky pinky pinky and the brain brain brain brain
18:27:00 <_glx_> anyway the bug might have been hidden before #11494
18:37:57 *** Smedles has quit IRC (singleton.oftc.net coherence.oftc.net)
18:37:57 *** APTX has quit IRC (singleton.oftc.net coherence.oftc.net)
18:39:07 *** Smedles has joined #openttd
18:42:25 <xarick> Okay, apparently OBS Studio doesn't like HDR
18:43:32 <xarick> I took a screenshot from in-game in Path of Exile, and compared to a screenshot taken with OBS, and they differ! 😦 I thought ... HDR was cool 😭
18:44:09 <peter1138> No shit. As I said when you asked earlier, no, it's not a bug in OpenTTD.
18:44:17 <peter1138> (And yet you still reported it as one.)
18:45:02 <xarick> the in-game screenshooter is accurate to what I see on the screen... OBS, both Force SDR on and off fail
18:45:34 <xarick> one is too dark, the other is too foggy
18:53:05 <peter1138> Ah yes, systems where size_t can't hold a UINT64_MAX :D
18:53:57 <talltyler> Not your code, but that’s one ugly cast in saveload.h
18:54:57 <talltyler> Is the `true == function()` needed for constexpr to work properly? Seems silly 🙂
18:58:09 <truebrain> `changes value from 18446744073709551615 to 4294967295`, lol @ warning
19:04:32 <peter1138> talltyler, no it's not, I forgot to remove that :)
19:04:42 <peter1138> But yes, the whole thing is a bit ugly.
19:05:23 <peter1138> Like it's abusing the fact that the function is there to be able to have a static_assert in the middle of an array initalizer in the first place :)
19:05:59 <peter1138> std::chrono::minutes is probably not uint64_t on all systems either.
19:06:39 <peter1138> Nice of MSVC to not actually show the static_assert, only that it failed :D
19:09:34 <peter1138> Ah, GetVarMemType is defined too far down :o
19:38:19 <peter1138> Well, no longer fails in an unexpected place :)
20:14:15 <xarick> well, it's maybe how it treats the station's town...
20:15:49 <xarick> i believe a station is assigned to a town, maybe he placed an airport where the majority of its tiles are affecting two different towns... hmm i don't recall, but yeah, there's some weird stuff in the way it calculates noise
20:18:35 <xarick> only one town claims the airport, i need to investigate... it's been years since I touched that part
20:28:36 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
20:36:45 <xarick> AirportTileIterator, is this new?
20:37:45 <peter1138> git will tell you that.
20:55:26 <xarick> ah, i think it's town_council_tolerance causing issues...
20:57:10 <xarick> uint8_t town_tolerance_distance = 8 + (_settings_game.difficulty.town_council_tolerance * 4);
20:57:50 <xarick> but the last tolerance level is supposed to be super friendly
21:36:44 <peter1138> Why focus on that line?
21:37:33 <xarick> 3 means super friendly, so the tolerance distance should be less
21:38:12 <xarick> caused by f92cf38ab5150dc6b8b00369028ac3a87db47dd1
21:40:34 <peter1138> Ah, so 0, 1, 2 mean one thing, and then 3 means something else.
21:43:31 <peter1138> Possibly station_noise_level should be turned off town_council_tolerance is permissive.
22:01:28 <peter1138> Although maybe it could just force station_noise_level to false.
22:01:31 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:05:57 <Eddi|zuHause> "permissive" means "disabled"?
22:06:17 <peter1138> Yes. It's a bit weird :)
22:07:46 <xarick> wow, you found so many more issues
22:08:28 <peter1138> Well, they're only issues if you decide that station noise level should be ignored for permissive. And I did.
22:08:29 <xarick> isn't that assert going to risk how NewGRF's use it?
22:08:54 <peter1138> NewGRFs can't use it.
22:09:29 <peter1138> All calls to it are guarded by a town_council_tolerance test.
22:10:06 <Eddi|zuHause> wait, you can override town noise by getting town population to 0?
22:10:07 <peter1138> So technically it's not needed, but then that's the point of asserts :)
22:10:24 <peter1138> Eddi|zuHause, I think it means the noise limit is 0.
22:22:05 <xarick> wow, you can remove stuff from bananas!
22:23:10 *** frosch123 has joined #openttd
22:23:24 <frosch123> just read mail, and wanted to open a PR
22:23:39 <frosch123> but then there was already one, and then it was approved, and then it was merged
22:23:45 <truebrain> It is why I pinged you 😄
22:23:46 <frosch123> i missed like 4 things in seconds :p
22:23:59 <frosch123> well, i just came home :p
22:24:37 <truebrain> Isn't it lovely, shit being unshitted for you
22:27:14 <peter1138> Might as well go to bed.
22:28:19 <xarick> PeterNviaGitHub: Aren't you going to deal with `GetAirportNoiseLevelForDistance`?
22:29:36 <xarick> afterload calls that for all towns
22:29:57 <frosch123> well, i sent an mail reply 🙂
22:30:52 <xarick> ` uint8_t town_tolerance_distance = 8;
22:30:52 <xarick> if (_settings_game.difficulty.town_council_tolerance == TownCouncilAttitudes::TOWN_COUNCIL_PERMISSIVE) town_tolerance_distance += _settings_game.difficulty.town_council_tolerance * 4;`
22:32:03 <truebrain> frosch123: Tnx. Report was btw originally made on Discord, but I like a record of these things in our mailbox 😛
22:33:30 <xarick> it can't be 0, there is a division by town_tolerance_distance afterwards
22:33:56 <xarick> not sure if 8/2 would be okay...
22:34:00 <peter1138> Why bother calculating noise level at all?
22:36:19 <peter1138> That seems to be an answer to a different question.
22:36:25 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:37:03 <xarick> settings_table.cpp line 301
22:38:24 <peter1138> Seems like write-only IRC is back.
22:45:52 <peter1138> I dunno, maybe not the right approach.
22:54:44 <xarick> the AirportNoise calculations seem flawed imo anyway
22:56:51 <xarick> Must investigate all instances of town->noise_reached, how is this being calculated
22:57:25 <xarick> and added up or so, there may be some inconsistency somewhere
22:59:27 <peter1138> If AirportGetNearestTown can return a different town between building and removing an airport, that'll go wonky.
22:59:47 <peter1138> Judging by the value of 6553something, that's more likely the issue.
23:01:11 <peter1138> I suspect it can, it's a very dynamic looking function.
23:02:36 <xarick> can a station still be considered an airport if the airport was removed?
23:02:50 <xarick> as a timeout sign or so?
23:03:00 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:03:04 <xarick> that would end in an airport without tiles
23:05:18 <Eddi|zuHause> what would be the point of that?
23:06:33 <xarick> it would make AirportGetNearestTown return UINT_MAX then
23:06:52 <peter1138> It's a valid question, the airport facility will be removed from the station when the airport part is removed.
23:11:07 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:15:18 <xarick> CmdBuildAirport: I see `Town *nearest = AirportGetNearestTown(as, tile_iter, dist);` and `Town *t = ClosestTownFromTile(tile, UINT_MAX);`
23:16:00 <xarick> two different methods trying to determine the town which is supposedly to be the same, but they're not
23:16:23 <xarick> one takes the airport layout into consideration, the other just takes the top tile
23:17:25 <peter1138> Two solutions -- record which town was nearest when adding the noise, to ensure it removes from the correct town.
23:18:00 <peter1138> Or just recalculate noise for all nearby towns when adding/removing an airport.
23:35:43 <_glx_> requested vs actual size ?
23:36:14 <peter1138> No, it's the same in both cases.
23:36:35 <_glx_> yeah size has not effect for sprite
23:37:02 <peter1138> Okay, to be clear, I am changing the medium font, but it is affect the small font in the map window.
23:37:23 <_glx_> fallback mechanism maybe
23:37:55 <peter1138> It's not the fallback stuff, because that only applies if it was an invalid font.
23:38:09 <_glx_> like freesans missing glyphs for medium
23:39:02 <_glx_> hmm but if it was the case it would show the chosen font
23:40:53 <_glx_> hmm small text is a substring of a normal text string ?
23:42:56 <_glx_> but it looks like font size is changing, but the font style didn't
23:44:05 <peter1138> Font style is the same, but yes, it's because it's "{SMALL_FONT}string"
23:44:42 <peter1138> If I tell add FS_SMALL to the DrawString() it renders the same regardless of what the medium font is set to.
23:45:10 <_glx_> we did this change in some locations already
23:46:24 <_glx_> maybe for cargo abbrev (not sure)
23:49:16 <peter1138> Not sure, we added support with SetTextStyle() but not everywhere uses that.
23:49:26 <peter1138> (And this isn't widget-rendered text anyway.
23:49:45 <peter1138> But yes, this is an argument for deprecating {SMALL_FONT}
23:49:59 <peter1138> Oh, it's TINY_FONT :)
23:50:51 <peter1138> But GS is allowed to use them for some reason.
23:53:29 <peter1138> Also it's probably ICU rather than freetype or the font rendering itself.
continue to next day ⏵
