IRC logs for #openttd on OFTC at 2024-11-01
⏴ go to previous day
02:05:18 *** Wormnest has quit IRC (Quit: Leaving)
02:21:45 *** gelignite is now known as Guest8097
02:21:49 *** gelignite has joined #openttd
02:29:09 *** Guest8097 has quit IRC (Ping timeout: 480 seconds)
03:38:38 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:46:52 <DorpsGek> - Update: Translations from eints (by translators)
07:56:08 <andythenorth> 50% increase in single core performance
08:18:12 <DorpsGek> - Add: summary for Q4 of 2024 (by OpenTTD Survey)
08:20:09 <ketsuban[d]> Can I request a review of #13036? It seems like the discussion ended satisfactorily and there's nothing else to do on my end other than rebasing to keep the PR up to date, and in the interests of not spamming everyone I was only going to do that if there's a conflict.
08:52:52 *** mindlesstux has joined #openttd
08:54:58 <peter1138> andythenorth: They haven't thrown any cache at it, like AMD do.
09:09:29 <truebrain> owh, Q4 reporting worked automatically .. except it is Q3 😛
09:09:49 <LordAro> Q0, Q1, Q2, Q3, right?
09:10:10 <truebrain> for some reason, I did not notice it earlier, that I call the results of Q3 as Q4 😛
09:10:17 <truebrain> (same for Q3, Q2, and .. Q1? 😛 )
09:10:43 <truebrain> this Q4 reporting just went in too early
09:10:45 <truebrain> `2024-10-01 to 2024-12-31. `
09:11:32 <truebrain> `'0 8 1 * *'` .. something feels wrong with this crontab
09:11:36 <truebrain> not sure what I was smoking, tbh
09:12:39 <truebrain> okay, with some git magic, removed the Q4 report
09:13:29 <LordAro> OTTD developers secretly collecting data?!?!
09:14:23 <truebrain> someone mind checking if that actually means it runs on the first day after a quarter closes? (so 2025-01-01, 2025-04-01, etc)
09:15:51 <truebrain> there is a button in that PR to press 😉
09:16:53 <andythenorth> Multicore grf compiles?
09:20:27 <LordAro> truebrain: sorry, busy screaming at our windows gitlab runners
09:24:43 *** gelignite has quit IRC (Read error: Connection reset by peer)
09:25:01 <locosage> andythenorth: Doable 🤭
09:25:58 *** gelignite has joined #openttd
09:26:45 <locosage> When bonky revives I'm thinking of making aseprite calls multicore at least
09:29:38 <LordAro> truebrain: the worst bit is that the provided workaround only worked for 1 server. or it only worked for the first few builds and then breaks in a different way
09:30:41 <LordAro> maybe i've misunderstood the implications of setting that NETWORK_PER_BUILD, idk
09:30:50 <LordAro> but i'm going through and downgrading them all now
09:37:17 <andythenorth> locosage: Probably not with nmlc though
09:57:24 <locosage> well, depends on where the bottleneck is
09:58:02 <locosage> sprite encoding can probably be parallelized fairly easily
10:00:34 <andythenorth> I’m away from laptop, but I forgot the nmlc steps
10:16:42 *** HerzogDeXtEr has joined #openttd
10:23:14 *** HerzogDeXtEr1 has quit IRC (Ping timeout: 480 seconds)
10:41:15 <ahyangyi> locosage: And caching helps a lot 😛
10:42:11 <xarick> why negative production is even considered
10:44:03 <LordAro> truebrain: asdfjkasdfj the machines upgraded to 24H2 overnight which gl-runner does not support ;_;
10:44:07 <LordAro> workaround was working fine
10:45:05 <xarick> can't we have framerate window in scenario editor?
10:53:18 <xarick> comparing just `if (IsTileType(dest, MP_WATER)) continue;` on the left vs `if (GetFloodingBehaviour(dest) != FLOOD_NONE) continue;` on the right, on a scenario with only water 4096x4096 size
10:54:30 <LordAro> explains why one of the runners was still working though - it never got the upgrade...
10:56:00 *** Smedles has joined #openttd
10:58:38 <locosage> ahyangyi: well, nml does caching already
10:59:04 <locosage> it just can't into anything more than pngs
11:55:40 <xarick> I just realized MP_RAILWAY has no waterclass
12:04:58 <peter1138> xarick: I think that made it worse...
12:05:38 <peter1138> Although I don't know which is before and after, nor what you were trying to do.
12:05:51 <xarick> I'm trying to synthesize GetFloodingBehaviour
12:07:44 *** maverickfischer has quit IRC (Quit: Connection closed for inactivity)
12:08:30 <xarick> void tiles also have no waterclass
12:09:13 <xarick> all these edge case handlings are probably slowing down my attempts
12:22:51 <andythenorth> locosage: It’s a shame it can’t cache the parse tree and only reparse against a diff of the nml file
12:23:13 <xarick> I don't think i can trust this TicToc thingie
12:23:42 <andythenorth> Also, for bigger nml files, it’s a shame it can parse multiple nml fragments on a worker pool, then assemble the tree from that
12:29:51 <_jgr_> xarick: You're not going to get reliable results instrumenting such a tiny function like that
12:32:07 <peter1138> You'd get more luck with the old rdtsc stuff but we got rid of that.
12:32:21 <peter1138> But yes, it's no use for something very tiny.
12:35:54 <locosage> andythenorth: that's a bit too much to ask from any compiler tbh
12:36:01 <locosage> even python only does caching per file
12:57:41 *** D-HUND is now known as debdog
13:16:43 <andythenorth> Parsing multiple input files in parallel though? (I assume for token extraction, although I don’t know what compilers actually do)
14:24:47 <xarick> I found some locks with WATER_CLASS_SEA in the middle tile
14:25:02 <xarick> shouldn't it be canal?
14:25:47 <xarick> they're on the opntitle save
14:30:20 <_glx_> seems fine if the middle tile was coast
14:42:02 <xarick> it's not possible to keep the SEA currently, only from loading old saves
14:42:17 <xarick> some conversion is missing
14:42:55 <xarick> or buildlock is not keeping sea
14:44:24 <_glx_> WaterClass wc_middle = HasTileWaterGround(tile) ? GetWaterClass(tile) : WATER_CLASS_CANAL;
14:44:55 <_glx_> it keeps water class if there's one
14:45:45 <_glx_> same for upper and lower
14:46:08 <xarick> this has my hand in it
14:52:57 <xarick> ah i remember, it's cause of objects that I went with this fix
14:55:47 <xarick> HasTileWaterGround returns false for shores
14:55:56 <xarick> so it doesn't keep water_class_sea
14:56:21 <_glx_> it's not really an issue, shore will be flooded after locks demolition anyway
14:57:01 <xarick> well... GetFloodingBehaviour is kinda...
14:57:58 <xarick> regarding the sloped lock tile
14:58:54 <xarick> river and canal = FLOOD_NONE
15:00:50 <xarick> sea is also FLOOD_NONE here
15:01:20 <xarick> wait, i need to retest, I'm a bit confused
15:02:40 <xarick> okay, river and canal = FLOOD_NONE, sea = FLOOD_ACTIVE
15:04:43 <xarick> tile 17537 is the middle tile of a lock with water class sea, which is only possible loading old savegames
15:09:56 <_glx_> this function is weird, why using Chance16 when beh1 and beh2 are expected to be the same ?
15:41:26 <_glx_> why not HasTileWaterClass() ?
15:42:43 <_glx_> seems more logical as GetWaterClass() is used in this case
15:45:30 <xarick> HasTileWaterClass(t) && IsTileOnWater(t)
15:53:34 <xarick> this function is really pesky...
15:55:35 <xarick> wc_lower and wc_upper are different between DC_TEST and DC_EXEC, I remember
15:58:47 <xarick> it miraculously keeps the river if the upper part is an object on water
15:58:56 <xarick> very delicate handling
16:16:01 <xarick> Should Flood dry up receive the same treatment?
16:22:46 *** Wormnest has joined #openttd
17:03:36 <xarick> it would mean GetFloodingBehaviour would be exclusively used only on water_cmd.cpp
17:17:00 <xarick> can i give waterclass to MP_RAILWAY?
17:21:07 <Rubidium> what does the documentation tell you?
17:21:34 <xarick> they have no waterclass
17:22:40 <peter1138> The only possible water class for rail half-tiles is sea.
17:23:23 <xarick> those OO's are WaterClass on every other
17:24:25 <xarick> there's also rail-ground-water on those vertical sloped tiles
17:24:25 <peter1138> Half-tile canals and rivers do not exist. (Despite andy's efforts)
17:24:47 <xarick> and that has a flooding of DRYUP
17:26:36 <xarick> which means... they would get waterclass too :p
17:28:44 <andythenorth> peter1138: Did I do it?
17:31:48 <xarick> some inconsistency I'd like to fix up...
17:32:40 <xarick> rail, road and tunnelbridge with waterclass
17:33:05 <xarick> not sure about MP_CLEAR whether they would also benefit in some way
17:34:38 <xarick> void are not listed but they would have waterclass too
17:35:08 <peter1138> There is no point to any of them having a water class.
17:35:37 <xarick> if i could get everything right, it would be much simpler to query for their flooding behaviour
17:44:48 *** gelignite has quit IRC (Read error: Connection reset by peer)
17:45:05 *** gelignite has joined #openttd
17:50:59 <xarick> why are objects handled differently
17:51:38 <xarick> objects on a coast get WATER_CLASS_INVALID, which in turn get FLOOD_NONE
17:53:02 <xarick> trees on a coast get WATER_CLASS_SEA, which in turn get FLOOD_DRYUP
17:53:22 <xarick> rail on a coast get nothing, but still get FLOOD_DRYUP
17:56:30 <xarick> gonna experiment maintaining the same flood behaviour regarding coasts across all tile types
17:56:56 <xarick> am I expecting graphic glitches?
18:21:45 <peter1138> Okay, we have ZeroedMemoryAllocator which is a left over from "the old ways"
18:22:06 <peter1138> But also, we have objects that have no explicit initialisation that always seem to be zero initialised anyway...
18:49:03 <xarick> I have a problem with object tile types.. cup half-full or half-empty problem
18:50:29 <xarick> depending on the object, it makes sense to consider a coast with a corner raised as land
18:50:42 <xarick> some other objects, makes sense as water
18:53:27 <peter1138> Trying to read the spec to determine the rules but it's a bit... chancy.
18:56:43 <peter1138> > If T is a (possibly cv-qualified) class type ([class]), then let C be the constructor selected to default-initialize the object, if any.
18:56:43 <peter1138> > If C is not user-provided, the object is first zero-initialized.
18:56:43 <peter1138> > In all cases, the object is then default-initialized.
18:59:21 <_glx_> I think you misunderstand flooding behaviour
19:00:44 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
19:28:47 *** Wormnest has joined #openttd
20:17:31 *** Borg has quit IRC (Quit: leaving)
20:42:43 <xarick> how to mix these flags `bool clear_water = (spec->flags & OBJECT_FLAG_DRAW_WATER) != 0 || (spec->flags & OBJECT_FLAG_HAS_NO_FOUNDATION) == 0;`
20:45:55 <xarick> this doesn't work the way I want because someone misunderstands specs
20:46:15 <peter1138> Is that "someone" you?
20:47:38 <xarick> if you draw water, you don't want to clear water
20:47:50 <xarick> if you have a foundation, you want to clear water
20:53:03 <xarick> i fail at bit operations
20:53:24 <LordAro> my powerline adapter managed to connect to someone else's network
20:53:30 <LordAro> pretty sure it's not supposed to be able to do that
21:00:05 <andythenorth> LordAro: Shared building or not?
21:01:03 <LordAro> they've lost connection to each other before now, but never as far as "oh here's a new IP on a different network"
21:02:28 <LordAro> fighting DHCP servers is always fun
21:19:14 <peter1138> Pfft, get a proper network!
21:20:12 <LordAro> running an ethernet cable even vaguely neatly would be >50m
21:20:17 <LordAro> but i'm open to other ideas
21:21:11 <peter1138> Well within the spec of Ethernet cable.
21:22:03 <LordAro> mm, still a pain though
21:23:54 <peter1138> Fibre? Point-to-point wireless?
21:25:06 <LordAro> fibre isn't particularly different to ethernet, and wireless probably would work but it'd be stretching it a bit - lots of concrete walls
21:25:10 <LordAro> also i don't like wifi
21:25:33 <peter1138> No, but you get nerd-factor 😄
21:29:43 <LordAro> given the only thing on the other end is my tv, it feels a bit overkill too
21:29:57 <LordAro> (yes, it's probably already overkill, but eh)
21:36:10 <andythenorth> I waa surpised how ok powerline is
21:39:16 <andythenorth> I have cat 5 in my house but some of it doesn’t work
21:44:53 <andythenorth> Powerline is about 50% as fast as the wifi in bandwidth up/down, but 200% more stable
21:51:54 *** tokai|noir has joined #openttd
21:51:54 *** ChanServ sets mode: +v tokai|noir
21:58:56 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:06:28 <_glx_> not ideal with 3 phases
22:11:28 <johnfranklin> WenSim became zorg?
22:18:34 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:23:01 <xarick> object_cmd.cpp feels half-done
22:33:16 <xarick> I need to pass the waterclass from CmdBuildObject to BuildObject
22:33:36 <xarick> and it's not as easy as I thought
22:34:33 <xarick> and these monstrosities can be 15x15 size, right?
22:50:56 <xarick> `void BuildObject(ObjectType type, TileIndex tile, CompanyID owner = OWNER_NONE, struct Town *town = nullptr, uint8_t view = 0, std::unordered_map<TileIndex, WaterClass> wc);`
22:50:56 <xarick> > error C2548: 'BuildObject': missing default argument for parameter 6
22:51:22 <xarick> there is no default argument
22:51:42 <xarick> why does it require it
22:52:09 <LordAro> cannot have a required argument after optional arguments
22:52:15 <LordAro> think about it, how would what work?
22:56:35 <xarick> maybe it needs a default 😦
23:15:18 <xarick> i can't make a default, still don't get pointers
23:19:22 *** gelignite has quit IRC (Quit: Stay safe!)
23:43:09 *** Flygon has quit IRC (Read error: Connection reset by peer)
23:48:44 <xarick> im utterly confused at unordered_map
continue to next day ⏵
