IRC logs for #openttd on OFTC at 2023-04-16
β΄ go to previous day
00:38:23 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
01:05:57 *** Wormnest has joined #openttd
01:42:36 *** WormnestAndroid has quit IRC (Remote host closed the connection)
01:42:41 *** WormnestAndroid has joined #openttd
01:58:38 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
02:15:46 *** Wormnest has joined #openttd
02:50:06 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:41:29 *** D-HUND is now known as debdog
06:58:01 *** gelignite has joined #openttd
07:33:25 *** sla_ro|master has joined #openttd
07:54:08 <dwfreed> is there a reason the windows release process signs twice?
07:54:56 <dwfreed> or maybe I'm not reading this quite right? I guess the CMake one is the actual game exe and the one in GH Actions is actually the installer part
08:12:16 <LordAro> dwfreed: does seem to be very duplicatey
08:14:02 <Rubidium_> well, the main question is whether openttd.exe is signed. The github workflow does not seem to extract and repackage files, just sign the bundle results that are executables (i.e. the installers)
08:14:43 <Rubidium_> so, if openttd.exe is signed, then the other signing is for the actual game executable. Otherwise you'd be signing the installer twice, so I hope it's the former
08:15:01 <dwfreed> the cmake signing appears to be for openttd.exe
08:15:26 <dwfreed> the signing in the GH workflow thus appears to be the installers
08:17:18 <Rubidium_> yes, both openttd.exe and the installer are signed. So it is indeed for the game and installer executables
08:48:16 <LordAro> forced opntitle to use YAPF instead of NPF - runtime drops from 3.5s to 2.4s
08:48:50 <Eddi|zuHause> is that a thing we need to optimize?
08:49:22 <Eddi|zuHause> and shouldn't we optimize that by throwing out NPF?
08:50:11 <jfs-> the main criticism against YAPF is probably that it's hard to follow because of all the templates and stuff
08:50:30 <Eddi|zuHause> and that affects like 3 people?
08:50:49 <jfs-> as long as it works, it only matters for developers yes
08:51:41 <JGR> The YAPF code is well written and not significantly harder to follow than the NPF code really
08:52:35 <Rubidium_> less is more, and removing NPF removes some 'local variable address stored in non-local memory' warnings
09:04:32 *** sla_ro|master has quit IRC ()
09:11:13 <TrueBrain> did not know C++ had a `std::put_money` .. that is just funny π
09:14:03 <LordAro> locale is full of stuff that's almost never useful
09:14:20 <TrueBrain> but it does contain exactly the things we need π
09:14:32 <LordAro> we'd have to create our own locale objects... somehow
09:14:33 <TrueBrain> did you happen to try? Mostly curious how slow it is .. as it reads like it is slow π
09:15:26 <TrueBrain> it reads like someone actually put effort in making this right π
09:15:38 <LordAro> the other factor is that we're not actually (exclusively) formatting currency
09:16:00 <TrueBrain> no, but that isn't an actual problem π
09:16:15 <TrueBrain> the main drawback is, that you need a float for this π
09:16:30 <TrueBrain> not really a problem either, I would guess, but it would be an actual float in OpenTTD π
09:16:38 <TrueBrain> (it isn't a problem, as we don't use it for anything but client-side rendering)
09:17:27 <TrueBrain> but again, no clue what speeds we are talking about here .. so no clue if it is viable
09:17:34 <TrueBrain> I am just amazed STL supplies π
09:17:51 <Rubidium_> well, maybe it makes sense to split FormatNumber into different specialisations. FormatNoCommanNumber doesn't need to do anything complicated. Reimplementing it as something like buff + seprintf(buff, last, OTTD_PRINTFI64, number) would probably suffice there.
09:17:59 <TrueBrain> also didn't know you could 'imbue' a stream to switch locale
09:19:05 <Rubidium_> and practically using a float for printing something to the console shouldn't be a problem
09:19:35 <LordAro> Rubidium_: yeah, i checked and the zerofill stuff is *only* used by 2 strings in the
09:20:12 <TrueBrain> too bad the string system still uses C strings π
09:20:27 <LordAro> TrueBrain: converting it is a massive rabbit hole :p
09:20:35 <Rubidium_> except maybe pedantic people that set the currency to be a factor of a billion or so, and then complain the money isn't a nice multiple of a billion everwhere anymore
09:22:22 <LordAro> "So maybe we should talk with these imaginary players about their imaginary needs..."
09:22:28 <TrueBrain> and funny, that `FormatHexNumber` just use seprintf, but the others don't
09:22:29 <LordAro> Are these imaginary players in the room with us right now?
09:22:52 <Eddi|zuHause> is it a complex room?
09:23:05 <TrueBrain> LordAro: if I rotate my head 90 degrees, I can see you, so I guess
09:24:54 <TrueBrain> that whole conversation? Yes
09:31:34 <TrueBrain> funny, the one thing we have hard-coded is our grouping size? π
09:32:01 <LordAro> which does actually vary by locale :D
09:32:18 <TrueBrain> so why did nobody ever complain about that? π
09:32:39 <Eddi|zuHause> perhaps nobody was indian? :p
09:33:05 <LordAro> (even better because it's not a constant)
09:33:37 <Eddi|zuHause> which is probably why no one implemented it
09:34:38 <TrueBrain> owh no, another recompile, nooooooo
09:43:59 <Rubidium_> oh... numpunct's going to be a bit of an issue for non-1-ascii-character separators
09:44:31 <LordAro> luckily there are none of those?
09:44:38 <LordAro> unless you want to support the arabic version
09:46:09 <LordAro> nothing important then
09:46:12 <TrueBrain> that is just a space, not?
09:46:34 <Rubidium_> a special space, as in it does not break the number over multiple lines
09:47:07 <Rubidium_> \xa0 gets encoded in UTF8 as two characters
09:49:26 <TrueBrain> I am more worried about the floating part .. and I totally forgot how that worked in OpenTTD π
09:50:08 <TrueBrain> where do we ever draw floating numbers ..
09:50:53 <Rubidium_> nowhere, but for the fractional part thing to work you need to resort to floating point numbers
09:52:07 <TrueBrain> there we go, there they are
09:54:48 <Eddi|zuHause> we still have no builtin font picker
09:55:02 <LordAro> yeah, but that's the sprite font
09:55:02 <TrueBrain> okay, fractions are a lot easier than I expected
10:02:24 <Rubidium_> maybe it's even possible to construct a format string in strings.cpp that just builds the whole string in one go. Not quite sure how that's going to work exactly though, and maybe the NewGRF stuff is throwing the proverbial spanner in the works
10:03:28 <LordAro> Rubidium_: that's what i was playing around with when i decided i wanted fmt::group_digits
10:07:20 <TrueBrain> a naive implementation with `std::numpunct` is ten times slower π
10:07:47 <TrueBrain> (was curious how efficient it would be :P)
10:08:33 <LordAro> it's probably not intended to be called N * 60 times a second
10:08:47 <TrueBrain> the current function measures somewhere below 1us
10:10:23 <TrueBrain> making it not-thread-safe helps a lot, but still slower π
10:11:42 <TrueBrain> turns out that constantly setting the locale is expensive π
10:12:43 <TrueBrain> but doing the fraction is easy .. it is send as 2 numbers
10:12:53 <TrueBrain> so just "number1<sep>number2", and done
10:13:07 <TrueBrain> so it is only the grouping π
10:13:20 <TrueBrain> but yeah ... don't use the std::numpunct, I would say π
10:21:59 <TrueBrain> isn't 2x on retina like 1x for us normal human beings? π
10:22:22 <TrueBrain> I really dislike what they did with terina
10:22:27 <TrueBrain> they made it so much more complex
10:25:56 <TrueBrain> oof, a library that uses "SHARED_DIR" as internal variable ... that gives a nice collision with OpenTTD's definition π
10:25:58 <TrueBrain> stupid generic names
11:20:45 <LordAro> ooh, my 3k tick wentbourne profile completed
11:29:58 <LordAro> 36% RoadVeh tick, 47% Train tick
11:30:21 <LordAro> perhaps not unexpected
11:31:05 <TallTyler> #10596 desperately needs some graphs and stats amongst the pure unadulterated conjecture
11:31:39 <TallTyler> It seems some people think open source = democracy
11:31:43 <TrueBrain> it does; it even has a site that shows you different graphs π
11:32:13 <TallTyler> And the democracy is currently looking like the alternate facts democracy where I live π
11:32:18 <LordAro> although, YapfTrainChooseTrack appears to be 1.3%, whereas YapfRoadVehicleChooseTrack is 34%
11:32:27 <TrueBrain> but 10596 really is very simple: the spirit of the game was that cargo value kept decreasing; due to old limitations, this was capped. It no longer is. The only problem there is that it is "different from before". There is nothing fundamental about any of the arguments π
11:32:53 <TallTyler> Yes, one side of the arguments has a custom tool that shows the effects of the change, the other side has βdoes the Silk Road mean anything to you?β
11:34:02 <TrueBrain> 10596 is just a bug-fix; and it would have been better if it was introduced as such π
11:34:20 <LordAro> give everyone involved a warning, then lock it as soon as it gets violated
11:34:28 <TallTyler> Agreed. But facts will never win against emotions, Iβm afraid π¦
11:34:31 <LordAro> a warning about unfounded opinion*
11:34:49 <TrueBrain> and that is why the constant replies are just not helpful to anyone
11:34:53 <TrueBrain> people have opinions; good for them
11:35:39 <TrueBrain> but comparing an older version with a current and complaining things are different is just a pointless argument you don't like change π
11:35:57 <TrueBrain> but I like LordAro's approach π
11:36:06 <TrueBrain> might be better than mine .. I would just lock the topic π
11:36:52 <LordAro> it's not like dP is getting special treatment in this case, we go against him more often than not :p
11:36:54 <TallTyler> I do too, although since Iβm mostly responsible for βdestroying the essence of the game, past present and future,β perhaps Iβm not the best person to shut down the discussion π
11:37:10 <LordAro> you should frame that
11:37:18 <TrueBrain> TallTyler: welcome to the club; you are only really an OpenTTD developer if someone told you you are ruining the game
11:40:31 <Kuhnovic> LordAro: You don't include any ship profiling?
11:40:58 <LordAro> Kuhnovic: i don't think there are many ships in the wentbourne save
11:42:18 <LordAro> road vehicles are supposed to have a pathfinder cache as well as everything else, right?
11:42:25 <LordAro> the above would suggest to me that it's not working
11:42:43 <LordAro> although i'm not actually sure where all the time on the train controller is going
11:42:58 <Rubidium_> LordAro: have you looked at the road network?
11:43:42 <Rubidium_> less than every other tile is a junction, and each junction it needs to check. Whereas junctions for trains are very far apart
11:44:16 <LordAro> even so, pathfinder cache should mean that's a one time cost, no?
11:44:28 <LordAro> or a not-many-time cost
11:45:06 <Rubidium_> not quite sure, but doesn't it consider some 'local' penalties?
11:45:35 <LordAro> Kuhnovic: oh, it does have quite a lot of ships
11:45:41 <LordAro> not a huge amount of water though
11:48:54 <Kuhnovic> Ah ok, so not really a scenario I should use for region based ship pathfinder then I guess
11:50:08 <Rubidium_> by the way, YapfXChooseTrack; road 88076 times, train 60031 times. So it's not that different in number of calls; it somewhat correlates with the number of vehicles
11:52:56 <JGR> LordAro: When you load the wentborne save, all the caches will be empty because it's an old save. It will take a while for the benefit of the caches to become apparent.
11:53:38 <LordAro> that could well be a factor, but even after 3000 ticks?
11:54:35 <Eddi|zuHause> pathfinder cache is per segment, so if you have very short segments, that shouldn't help you much
11:57:25 <Rubidium_> LordAro: to be honest, it looks like yapf only caches aggressively for rail
11:59:08 <Eddi|zuHause> apparently, on this 20km x 10km map, i've put 1.000km of track.
11:59:08 <Rubidium_> primarily based on PfCache being CYapfSegmentCostCacheNoneT for road/ship and CYapfSegmentCostCacheGlobalT for train
12:00:09 <Eddi|zuHause> !calc 1000/(2*(20+10))
12:00:15 <Eddi|zuHause> @calc 1000/(2*(20+10))
12:00:15 <DorpsGek> Eddi|zuHause: 16.666666666666668
12:04:25 <Eddi|zuHause> @calc 1032.819/(2*(11.264+22.528)
12:04:25 <DorpsGek> Eddi|zuHause: Error: unexpected EOF while parsing (<unknown>, line 1)
12:04:30 <Eddi|zuHause> @calc 1032.819/(2*(11.264+22.528))
12:04:30 <DorpsGek> Eddi|zuHause: 15.282004616477272
12:04:34 <TrueBrain> I am benchmarking WASM a bit, inside OpenTTD .. and I picked FormatNumber to do the benchmarking with, as, why not
12:04:39 <TrueBrain> it is crazy how fast it is ..
12:04:53 <TrueBrain> with the JIT enabled, it is only twice as slow in a debug build
12:05:10 <TrueBrain> with an AOT precompiled binary, it is only 25% slower
12:05:18 <TrueBrain> this is much faster than I expected π
12:06:08 <TrueBrain> too bad AOT doesn't seem really viable, as .. well .. you would need to distribute those files per OS you support .. which is kinda defeating the purpose π
12:07:11 <TrueBrain> time to see what a release-build does ... takes a bit of time to build π
12:09:04 <TrueBrain> owh, there is another JIT, which seemly gives better performance (but takes longer to do its job)
12:18:44 <TrueBrain> it is surprisingly easy to integrate WASM in your code; the header definition is also pretty clear .. I am a bit surprised by all of this π
12:18:56 <TrueBrain> took me a few minutes to build a wasm file from cpp .. even that was rather clear
12:19:07 <TrueBrain> I expected this to be much less mature π
12:20:01 *** sla_ro|master has joined #openttd
12:33:24 <TrueBrain> and if you think building OpenTTD takes a while ... try building LLVM π
12:34:31 <LordAro> done it, repeatedly while setting up a CI for a custom build of it
12:34:48 <TrueBrain> so you know the pain! π
12:34:52 <LordAro> though i did have a 40 core machine for much of it
12:38:46 <TrueBrain> that would be nice to have π
12:40:52 <TrueBrain> hmm, when adding LLVM JIT, our code no longer compiles π
12:40:58 <TrueBrain> something about dynamic_cast and no-rtti
12:47:02 <TrueBrain> I am sure there are ways to fix that, but I can't be bothered atm π
13:00:46 *** lobstarooo_ has joined #openttd
13:04:21 <petern> #10660 happens if you set the games max sprite zoom to 1x
13:04:54 <petern> I need to somehow log in to GitHub on my phone π
13:08:36 <LordAro> feels like sprite zoom shouldn't affect scaling?
13:08:49 *** lobstarooo_ has quit IRC (Ping timeout: 480 seconds)
13:09:12 <petern> Sprite font is sprites ..
13:11:04 <petern> Andythenorth uses sprite font and osx and I terrace scaling, we'd know if it didn't generally work
13:16:16 <petern> Time for post-ride lunch
13:19:32 <frosch> i did not know about std::put_money. i wonder whether some company ever went bankrupt because it used it
13:19:52 <frosch> taking a double and printing it as some "random" currency sounds insane
13:25:40 <TrueBrain> what is the worst that can happen? π
13:30:42 <petern> Hmm, although bottom aligned might fit with the "name-plate" nicely
13:31:36 <petern> Of course that face causes issues with non-integer sprite scaling as it's made up of overlapping parts... and some pixels don't overlap all that they need to.
13:33:52 <petern> Woo, salad & small piece of cake achieved.
13:35:16 <petern> Aw crap, LordAro's poor knees π¦
13:35:31 <andythenorth> fishfingers & chips petern
13:35:52 <petern> Oh, I've already eaten. Maybe for dinner, but I'll have to go shopping for it.
13:36:36 <andythenorth> we only had 5 fishfingers for 2 humans though
13:36:45 <andythenorth> trolley problems?
13:37:23 <andythenorth> hmm 10596 I read and it reminded me why a break from the game is good now and then
13:37:49 <andythenorth> just add a setting, if ever there was a case for supporting spacebar heating its that
13:43:46 <TrueBrain> owh, this WASM executor is per thread .. lol, took me a bit too long to figure that out π
13:47:51 <petern> I could have a beer though.
13:48:28 <petern> One wafer-thin little beer.
13:50:32 <TrueBrain> owh, right, I forgot how many symbols C++ drags in when you compile that to WASM π
13:50:38 <TrueBrain> bad_array_new_length and other friends
13:51:39 <petern> Well that was a wasted effort...
13:52:14 <andythenorth> maybe next time it will pay off π
13:52:14 <petern> My effort up the steep part was on par with my PB, but much slower getting up to speed on the flatter part. Hmm.
13:52:49 <TrueBrain> it is funny how I have no clue how to read that graph π π
13:53:24 <TrueBrain> mostly as it is 2 graphs in one, with no indication which is the left axis and which is the right
13:53:46 <TallTyler> I thought I figured it out until I saw there are two Y-axis π€
13:53:47 <petern> the lines are time, the area is altitude.
13:54:06 <petern> It is hard to read, and I know what I'm looking at...
13:55:29 <petern> Ok, 5 years ago I was 42s faster. But I was also 5 years younger, I guess.
13:55:59 <petern> And LordAro is looking at it like "where's the hill?"
14:03:55 <TrueBrain> I am still looking at: who invented such graph, and how dare they? π
14:08:26 <petern> It's confusing to me because "+ seconds" is actually seconds *less*
14:16:40 <LordAro> petern: it being relative to something else is what does it for me
14:24:37 <TrueBrain> `out of bounds memory access`
14:24:59 <andythenorth> no memory for you
14:26:31 <TrueBrain> HeightMapCoastLines causes it, sad
14:29:37 <TrueBrain> no, hmm .. something bad happens in that function, don't know what yet π
14:30:27 <TrueBrain> ah, yes, I do ... I used MapSizeX instead of MapLogX
14:30:58 <andythenorth> is this your Unity port? π
14:36:47 <TrueBrain> no, I just ported TGP to a WASM module
14:36:59 <TrueBrain> that was a lot easier than I expected
14:37:22 <TrueBrain> and it actually works π
14:38:12 <TrueBrain> this means that if we go this route, it would be very easy to distribute different terrain generators via BaNaNaS π
14:38:38 <TrueBrain> let's see how much difference in CPU time there is
14:39:59 <TrueBrain> the main "issue" is that we have some nasty classes that use static variables to store information
14:40:10 <TrueBrain> so it wasn't always as clear that I couldn't just include that header in my WASM file
14:40:15 <TrueBrain> main example: Map::SizeX()
14:40:30 <TrueBrain> for all the right reasons, but that uses a static piece of memory .. but that isn't available in the wasm module π
14:41:45 <andythenorth> JGRPP, but it's WASM modules π
14:41:49 <andythenorth> perhaps not π
14:42:19 *** lobstarooo_ has joined #openttd
14:42:26 *** lobstarooo_ has quit IRC ()
14:42:46 <TrueBrain> okay, first time it hits the function the JIT kicks in, making it twice as slow as the next call
14:42:49 <TrueBrain> which makes total sense
14:43:07 <TrueBrain> time for a release build π
14:50:16 <TrueBrain> via C, a 256x256 map takes ~3.3ms. Via WASM, it takes ~7ms.
14:50:40 <TrueBrain> that .. is a lot less difference than I expected for something like TGP π
15:00:56 <petern> TBH it makes sense to pass things like x & y to the API method, rather than having it looked up from a static method.
15:01:25 <TrueBrain> yeah, but for TGP you need to know how big the map is too π
15:02:58 <TrueBrain> now I am confused π
15:03:53 <petern> I just made myself a nice frothy coffee.
15:09:40 <TrueBrain> pfffff, HOW COULD YOU π
15:15:14 <andythenorth> I could explore git reflog looking for commits I assumed were missing
15:15:27 <andythenorth> or I could look at the actual code and uncomment the commented parts
15:18:48 <petern> I went to Tesco but didn't buy either fish fingers nor chips.
15:20:26 <andythenorth> so you bought chips?
15:20:35 <andythenorth> I can't do booleans with either/nor
15:21:30 <TrueBrain> mostly to check what the CI thinks ^^
15:23:17 <TrueBrain> ironically emscripten is the first to fail
15:24:37 <TrueBrain> no 32bit support for the JIT .. lol; not surprising, I guess, but disappointing for sure π
15:25:35 <TrueBrain> and fails on MSVC, that is interesting ..
15:29:16 <TrueBrain> hmm, better would be to make the PR against my own fork .. still runs CI, less spam in this chat π
15:31:51 <TrueBrain> without JIT, it is about 8 times slower than native .. still impressive, if you ask me. I don't want to benchmark Squirrel π
15:32:14 <petern> Oh I was going to play Doom but forgot. Hmm
15:35:15 <TrueBrain> well, that was fun π
15:35:25 <andythenorth> TrueBrain: eh go on, benchmark squirrel π with charts
15:47:35 <LordAro> oh wait, andy's been here for a while
15:54:01 <andythenorth> project crap was getting in the way of that, lot of noise
15:57:35 *** WormnestAndroid has quit IRC (Remote host closed the connection)
16:03:51 <andythenorth> hmm are variants also categories?
16:03:56 <andythenorth> nah probably not
16:04:26 <andythenorth> is it weird to nest this hopper as a variant of the van?
16:04:38 <andythenorth> I guess I can use the fancy callback
16:05:56 <andythenorth> "Farm Products Wagons"
16:08:14 *** WormnestAndroid has joined #openttd
16:43:57 *** Wormnest has joined #openttd
17:01:05 <petern> #10596 probably needs locking... it's merged already.
17:03:13 <Rubidium_> then it's quite likely a new bug or discussion ticket is opened
17:45:55 <petern> > string(APPEND SQUIRREL_EXPORT "\ntemplate <> const char *GetClassName<${CLS}, ST_${APIUC}>() { return \"${API_CLS}\"; }")
17:46:08 <petern> `string(APPEND SQUIRREL_EXPORT "\ntemplate <> const char *GetClassName<${CLS}, ST_${APIUC}>() { return \"${API_CLS}\"; }")`
17:46:26 <petern> Does that `ST_` refer to an OpenTTD enum?
18:03:08 <jfs-> PeterNviaGitHub: cute, should probably be case sensitive replacement
18:03:50 <petern> Yeah I did that but cos that file doesn't get compiled for me missed that I messed up that one π
18:05:44 <petern> Looks like that's the only one.
18:10:34 <petern> There are probably some other enums that collide but this touches quite a lot of files already.
18:18:16 <andythenorth> ok the fancy name callbck
18:18:28 <andythenorth> let's find the PR for that and read the diff π
18:21:59 <andythenorth> ok so we need a new bit for context: 'autoreplace - left side panel'?
18:22:16 <andythenorth> grf stuff is such a cluster
18:22:35 <andythenorth> all grf devs use jgrpp now, jgrpp is behind trunk
18:22:41 <petern> Technically the left hand side is purchased vehicles, not a purchase list.
18:22:47 <andythenorth> if I don't test it and anticipate every weird thing π
18:22:57 <andythenorth> then at least 2 people turn up and complain
18:23:09 <andythenorth> but I ain't a great developer and don't think of all the cases
18:23:42 <andythenorth> purchased_vehicles sounds good
18:25:04 <JGR> andythenorth: I can assure you, they do not
18:25:16 <andythenorth> loose use of the word 'all'
18:25:33 <andythenorth> got hunger rage π
18:25:35 <andythenorth> I should fix that
18:27:10 <andythenorth> I wonder what other contexts we need π
18:28:32 <andythenorth> let's eat a orange, that's healthy
18:29:44 <andythenorth> EmperorJake: you here? π
18:37:56 <andythenorth> ok I can't find (by clicking around the game) any other contexts where vehicle name is shown
18:40:48 <DorpsGek> - Update: Translations from eints (by translators)
18:42:24 <andythenorth> will `WID_N_VEH_NAME` get me all the places engine name is show?
18:43:30 <petern> Those WID enums are (usually) unique for each window.
18:43:53 <andythenorth> I was hoping we had a function to get engine name, and I could find all callers,
18:44:22 <andythenorth> but I'm searching current master, where it's all been changed to PackEngineNameDParam
18:45:53 <andythenorth> we don't have a hidden 'vehicle designer' or anything I've never stumbled across?
18:46:08 <andythenorth> sometimes I still find new undiscovered features in the game afte 15 years of it
18:47:04 <andythenorth> any hidden settings to make vehicle names show in e.g. vehicle list windows, station windows etc?
18:58:18 *** Orang has quit IRC (Quit: User went offline on Discord a while ago)
19:03:24 <frosch> andythenorth: 0x10-0x1F is meant for specific vehicles
19:03:30 *** ChanServ sets mode: +v tokai
19:03:35 <frosch> the autoreplace gui does not show specific vehicles, but a purchase list
19:03:42 <frosch> as such both sides should use 0x20-0x2F
19:03:54 <andythenorth> 'not built yet' put me in the wrong conclusion π
19:04:12 <petern> Well, left is not exactly a purchase list, but it's not individual vehicles either.
19:04:43 <andythenorth> specifically "reserved for other future GUIs with non-purchased vehicles" threw me π
19:04:55 <andythenorth> shall I change? It's just a bit, so eh
19:04:56 <frosch> well, "purchase" is newgrf context :p
19:05:11 <frosch> andythenorth: please change, makes future easier
19:05:23 <andythenorth> isn't it nice to have a civil conversation about it
19:05:27 <andythenorth> without the drama
19:07:24 <frosch> when people post newspapers, it's less drama, more entertainment
19:08:29 <frosch> i guess sometimes i only look at the pictures and skip the text π
19:10:37 <andythenorth> do we need to update nml for an extra bit?
19:10:48 <andythenorth> there are no special var names assigned to pick bits out for this feature
19:41:34 <andythenorth> now can I break it with vehicle purchase name cb?
19:42:41 <andythenorth> hmm there is extra cb info for 'levels deep in purchase list'?
19:42:52 <andythenorth> what meaning would that have here?
19:55:48 <andythenorth> appears not to get the variant depth level in autoreplace
20:03:17 <petern> Is there any reason why you'd want that label to the different from the normal purchased engine name? heh
20:03:47 <petern> Or this extending it because the mechanism is there, it makes sense to allow it anyway?
20:04:12 <petern> (More flexibility to do that now that to just not do it at all, I guess)
20:04:13 <andythenorth> I just want it to show the engine name personally, but eh
20:04:22 <andythenorth> not the parent variant
20:04:35 <andythenorth> who knows what people will think up π
20:04:53 <andythenorth> "My best engine (This engine is no longer available, please replace it)"
20:05:11 <andythenorth> all the stuff George wants to do with realistic timeline
20:05:32 <andythenorth> "This engine is red, replace it with the blue one"
20:05:54 <petern> Hmm, I might need to turn down my compilation concurrency, it's making Twitch/YouTube/whatever stutter when I compile π
20:07:21 <petern> Oh it made Doom and Discord freeze now
20:12:36 <andythenorth> petern: would it be simpler to use the normal purchased engine name?
20:12:56 <andythenorth> this bit route requires the grf to explicitly handle autoreplace context, which could be easily forgotten
20:14:03 <Brickblock1> this way is more flexible
20:14:16 <Brickblock1> would it be possible to do both?
20:14:44 <andythenorth> maybe, but I can't see how π
20:15:06 <andythenorth> some complicated handling of the callback result maybe
20:17:09 <petern> Is it not just another value?
20:18:42 <andythenorth> confused-face-emoji π
20:19:52 <andythenorth> so we change the default name in this context?
20:20:05 <andythenorth> but allow grf to handle it explicitly if it chooses?
20:24:54 <petern> How do you test for context?
20:27:09 <petern> "bit 0x22" is not a bit
20:27:23 <petern> The *value* is 0x20 for PurchaseList
20:27:42 <petern> If you are testing for the value of 0x20, then it won't match the value of 0x22.
20:29:57 <andythenorth> in nml grf, it's picked with `getbits(extra_callback_info1, 0, 8)` then tested for as `0x22` or `0x20` and friends
20:30:42 <petern> Yes, it's a byte. They have 8 bits. So "bit 22" is not possible π
20:30:52 <andythenorth> I've amended the GH comments
20:33:31 * andythenorth trying to figure out how to get autoreplace 'in use' to default to the name string shown for the vehicle, not the parent
20:34:10 <andythenorth> I could abuse 'VehicleDetails` but obviously that's wrong
20:34:32 <LordAro> /home/lordaro/dev/OTTD/openttd/src/town_gui.cpp:1202:36: warning: βbufβ may be used uninitialized [-Wmaybe-uninitialized]
20:36:03 <LordAro> was that me? i feel like it shouldn't have been me
20:37:58 <LordAro> you know, i think that was me
20:38:07 <LordAro> but it's been uninitialised this whole time
20:38:47 <petern> It's filled by GetTpwnName though...
20:39:11 <LordAro> might just be some LTO incremental compile weirdness
20:40:09 <LordAro> see what the CI says, i guess
20:40:15 <andythenorth> hmm item.indent π
20:40:20 <andythenorth> no, I did not win
20:41:37 <andythenorth> I think I just need to find the param for PackEngineNameDParam, and then autoreplace 'in use' will show the default vehicle name π
20:42:50 <andythenorth> /me guess things
20:42:52 <petern> Probably the issue is that the left is isn't indented, so you get top-level name (lol group) instead of the actual name.
20:43:20 <petern> So if you only check the level and not the context, you've done it wrong.
20:43:45 <andythenorth> the grf all works fine, I'm just curious if we can change the default case
20:43:51 <andythenorth> without handling it in grf
20:44:11 <andythenorth> oh wait, compiling would help
20:44:20 <andythenorth> ./openttd doesn't do that π
20:44:40 <andythenorth> remember 'make run' ? π
20:44:58 <petern> No, I never used that.
20:45:01 <LordAro> yeah, no more warning after touching things
20:46:26 <petern> Hmm, mind you if only check indent then it'll be wrong everywhere I guess.
20:48:54 <andythenorth> I am going to file 'change the default' under 'no'
20:49:10 <andythenorth> just handling it explicitly in grf works fine
20:58:23 <petern> Well I wish I'd bought some chocolate or something
20:58:47 <petern> But no.. just lettuce and stuff for prepping meals... how "sensible" :/
20:59:46 <michi_cc[d]> Sorry andy, could've noticed that the first time around.
21:00:52 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:02:46 <GeorgeVB> I'm trying to make GRFs interact and want to count how many specific vehicles from the other GRF are attached to current vehicle. Is it possible to do?
21:07:36 <andythenorth> michi_cc[d]: do we actually need the comment?
21:07:45 <andythenorth> I was playing it safe...but maybe it's obvious?
21:08:14 <michi_cc[d]> Eh, comment itself is fine.
21:08:40 <andythenorth> I could ternary, I'd have to read which order true / false is π
21:09:03 <petern> I dunno if ternary is better there or not.
21:09:26 <petern> But the comment is useful, because otherwise it's not clear why it's on the "show_count" parameter.
21:10:03 <andythenorth> I mean....it's a smell π But I'm not ready to introduce a new var for that / rename it
21:10:36 <glx[d]> as long as there's a comment it's not that smelly π
21:12:58 <andythenorth> count_veh_id looks like it's var 0x60
21:14:01 <andythenorth> GeorgeVB: what does OpenTTD src say for 0x60?
21:14:31 <petern> It checks local grf ID, but doesn't check that it's the same NewGRF.
21:15:13 <petern> parameter is uint32, so there's no way to stuff both an engine ID and a GRF ID into it.
21:15:32 <andythenorth> GeorgeVB: you can probably count them yourself with a recursive loop and a register
21:15:52 <glx[d]> if (v->GetEngine()->grf_prop.local_id == parameter) count++;
21:15:52 <andythenorth> just walk the consist, and do count ++
21:16:43 <andythenorth> grfid in register 101 or something maybe?
21:17:34 <glx[d]> oh so if you mix vehicles from different newgrf but they use the same id both are counted
21:18:05 <petern> I guess that's my fault when I did the engine pool π
21:18:24 <glx[d]> a way to add some filtering would be nice π
21:19:22 <glx[d]> possibly a new var and a register
21:20:45 <andythenorth> we could....do it in nml π
21:20:50 <andythenorth> just some fancy varact 2
21:21:31 <glx[d]> yeah it's doable in nml, but not very efficient π
21:22:29 <glx[d]> walk the consist, check grfid and id and increment a temp for each part
21:23:33 <petern> Mmm, slow varaction chains
21:23:45 <andythenorth> I mean it's only a few hundred KB of nml / nfo π
21:23:52 <glx[d]> andy likes huge varact2 chains
21:23:59 <andythenorth> maybe a MB, depends how long consist you want to check
21:24:19 <andythenorth> 'likes' is a strong word, more like I find them lolz
21:25:00 <petern> Executing a huge long chain every tick to determine what to draw? π
21:25:44 <andythenorth> and we wonder why the game is slow? π
21:28:11 <GeorgeVB> Yes, persistent storage for vehicles would be great. Just calculate once with can_attach_wagon callback and use precalculated values while drawing it on the map
21:30:35 <andythenorth> hmm...if I make Horse commits assuming cb 161 has 0x22, worst that happens is I never get that value in the grf
21:32:00 <petern> Yeah but why would you want to use a non-default name there
21:33:21 <glx[d]> the callback is called anyway there, and in current form it's impossible to know if the default name is a valid return
21:34:13 <glx[d]> only the indentation is available and in this case it's a false positive
21:34:27 <JGR> GeorgeVB: You can almost do this via vehicle variable 42/property 25/callback 36 already
21:34:40 <andythenorth> we debated prop 25 a lot π
21:34:48 <JGR> But in practice it's extremely awkwardly designed
21:34:55 <andythenorth> there's some reason we concluded no to persistent vehicle storage
21:34:59 <andythenorth> was it RAM use or something?
21:35:34 <glx[d]> well think about the number of vehicles
21:35:44 <glx[d]> compared to industries or towns
21:36:10 <andythenorth> well if it was 16KB and we have 9999 vehicles in a game
21:36:56 <JGR> "Vehicle" includes every wagon and articulated part. not just leading engines
21:37:30 <JGR> Really struct Vehicle is too big already
21:38:04 <glx[d]> there are some ideas to split with Consist
21:38:50 <andythenorth> petern: you mean in autoreplace 'in use' panel?
21:39:10 <petern> Yeah, I mean specifically in Horse.
21:39:24 <andythenorth> I'm going to group a lot of wagons under 'hopper wagons' etc
21:39:32 <andythenorth> then the variants will have names
21:39:48 <andythenorth> so I don't want them all to be labelled 'hopper wagons' in autoreplace in-use
21:39:52 <glx[d]> and indentation 0 is used to find out it's the group name
21:40:55 <petern> But you only need to test for 0x20, as that's the purchase list flag.
21:41:11 <petern> If it's not 0x20 it can fail and just use the real name.
21:41:44 <andythenorth> this is why chatGPT does not replace discord yet π
21:43:57 <glx[d]> but replace list uses purchase list context
21:44:04 <andythenorth> not in my patch π
21:45:48 <petern> Time to watch John Romero create a Doom map.
21:46:10 <andythenorth> ha all trains will now be named 'train icon'
21:46:13 <andythenorth> much more usable
21:47:54 <glx[d]> hmm but couldn't in_use panel just use the vehicle detail context ?
21:48:24 <petern> That is what I originally suggested tbh but someone had a different idea I guess.
21:49:03 <petern> As it's not technically details of a vehicle, only a list that happens to only include purchased vehicles.
21:49:45 <andythenorth> it could just use that context yes
21:49:52 <glx[d]> yeah detailed name might be different than the name in available list
21:49:53 <andythenorth> I think it's potato / potato
21:50:03 <andythenorth> who knows what grf authors will do?
21:50:10 <glx[d]> authors can have weird ideas
21:50:37 <andythenorth> I don't think we ran out of bits, so might as well name the context
21:52:23 <michi_cc[d]> I think a 0x2? value is better as 0x1? is conceptually for concrete vehicles and not abstract CBs with only purchase list vars available. (Never mind that for performance reasons name CB is always only purchase context and not vehicle context like sprite resolve.)
21:52:29 <glx[d]> only 5 of 255 possible values are used
21:54:02 <andythenorth> codeQL still running eh
21:54:09 <andythenorth> on my 5 line patch
21:54:30 <glx[d]> anyway in most use cases the important change is it's not 0x20 π
21:55:52 <petern> That confused andy and he's writing it π
21:57:52 <andythenorth> I do one thought at once
21:57:56 <andythenorth> and that takes a while
21:58:41 <andythenorth> I look forward to looped GPT doing my thinking for me
22:16:38 <andythenorth> do I need to install anything for catch2?
22:16:58 <andythenorth> I rebased to latest vanilla, local build fails
22:17:06 *** gelignite has quit IRC (Quit: Stay safe!)
22:18:00 <andythenorth> well to be strict, it's produced a viable binary, but the make run reports fatal errors, which look like test / QL reports
22:20:14 <andythenorth> oh and this is new
22:20:41 <andythenorth> ok I guess sleep time π
22:23:12 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:27:25 <glx[d]> your local build env runs tests on each build ?
22:28:29 <TallTyler> Hmm looks like I messed up
22:40:17 <glx[d]> but windows is not macos, and andy uses a weird setup needing a modified format.h
22:43:07 <andythenorth> TallTyler: that's a new error since I pulled openttd upstream
22:43:25 <andythenorth> I haven't bisected to find which commit as I need to go to sleep π
22:43:30 <andythenorth> or my build is broken or both
22:43:40 <petern> It'll be my change to unique_ptrs probably.
22:44:17 <andythenorth> release early, release often etc π
22:53:17 <petern> Oh, I see the difference.
22:53:57 *** audigexJon has quit IRC (Quit: User went offline on Discord a while ago)
22:54:46 <petern> Redefining the same house ID no longer copies over the substitute type after the one definition. Oops.
22:59:50 <petern> For all the other newgrf features, it only copies on the initial definition, just houses it was different.
23:00:16 <glx[d]> there's always a feature doing things differently
23:00:47 <glx[d]> (like stations defining layout in action 0)
23:00:50 <petern> otoh, it's a unique_ptr, so I can just remove the nullptr check.
23:01:01 <petern> Yeah, that was designed before all the rest
23:04:39 <petern> I'm not convinced this isn't a bug either.
23:06:43 <petern> > Only the first property 08 setting copies properties; if you later change it, properties will stay.
23:11:02 <petern> > House flags 40 and 80 are exceptions; these flags are never set automatically.
23:11:09 <petern> We don't clear those either.
23:13:35 <petern> So my change is wrong, but the original code is not to spec either.
23:15:24 <jfs-> so why did I stay up to 1 am on a sunday night to code a parser for a boring file format
23:16:44 <jfs-> I at least hope it won't crash anyone
23:17:32 <jfs-> oh, looks like emscripten also needs special treatment for this
23:26:12 *** sla_ro|master has quit IRC ()
23:27:35 <petern> Some of my reindenting went wrong π
23:31:59 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:57:56 <petern> I keep reading reindenting as reindeering... :/
continue to next day β΅