IRC logs for #openttd on OFTC at 2024-12-08
โด go to previous day
02:00:17 *** gelignite has quit IRC (Quit: Stay safe!)
03:13:47 *** Wormnest has quit IRC (Quit: Leaving)
03:17:56 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:53:29 *** godbed has quit IRC (Ping timeout: 480 seconds)
04:44:47 <DorpsGek> - Update: Translations from eints (by translators)
08:17:08 <LordAro> andythenorth: you still on the ground down there?
08:41:14 <merni> and hot chocolate made by melting swiss chocolate ๐
08:49:48 <kuhnovic> Now I want more coffee
09:00:49 <truebrain> LordAro: by validating what you did, and as I had to test `six`, I already had the fix for your PR ready. So I pushed that ๐
09:01:10 <truebrain> will still leave the questions open, as you might have had good reasons to add them
09:01:48 <truebrain> owh, funny, locally I don't need a dependency which remotely is needed. Another interesting case of: wtf? ๐
09:02:01 <truebrain> ah, yes, I run a newer Python versions
09:04:40 <truebrain> ah, okay, so you didn't do anything with the dependabot PR ๐
09:05:01 <truebrain> I can understand that. But it is a bit tricky. In this case, aiohttp is being tricky
09:05:34 <LordAro> looks like aiohttp min python is 3.9
09:05:52 <LordAro> i imagine python could probably by upgraded... but i considered that out of scope ;)
09:05:53 <truebrain> yeah ... but we are 3.10 already with this repo ..
09:06:07 <truebrain> `FROM python:3.10-slim`
09:06:20 <truebrain> "out of scope" for this PR maybe, but not for the work to get the dependabot PR closed ๐
09:06:27 <truebrain> as who else is going to address it ๐
09:07:57 <truebrain> I have no clue why it was like that
09:08:12 <truebrain> since first commit it was like that ๐
09:09:10 <truebrain> the new "merge experience" on GitHub is very nice ๐
09:10:59 <truebrain> LordAro: owh, and the manual closing of dependabot PRs have as consequence that it will skip that version. Which can hide stuff if you update like you did. That is why I keep them open, and after I merged my update PR, I tell dependabot to rebase those PRs. It either closes them, or it still tells: you should update!
09:11:12 <truebrain> a bit annoying, I know, but that way at least it remains visible when our Python is too old
09:11:26 <truebrain> and lately this really is a thing in the Python community, that you need to update your Python a lot more often than you used to
09:11:43 <truebrain> not sure what exactly changed in the attitude, but it is annoying ๐
09:14:13 <truebrain> and it is funny you started with the one repo that doesn't have a preview version ๐ ๐ ๐
09:14:20 <truebrain> so we are going to YOLO the shit out of this ๐
09:15:30 <andythenorth> coffee has happened
09:15:36 <andythenorth> so...I did a silly thing
09:15:53 *** xarick has quit IRC (Remote host closed the connection)
09:15:53 *** brickblock19280 has quit IRC (Remote host closed the connection)
09:15:53 *** kurzov has quit IRC (Remote host closed the connection)
09:15:53 *** andythenorth has quit IRC (Remote host closed the connection)
09:15:53 *** DorpsGek_vi has quit IRC (Remote host closed the connection)
09:15:53 *** _glx_ has quit IRC (Remote host closed the connection)
09:15:53 *** talltyler has quit IRC (Remote host closed the connection)
09:15:53 *** michi_cc[d] has quit IRC (Remote host closed the connection)
09:15:53 *** joehtosis has quit IRC (Remote host closed the connection)
09:15:53 *** johnfranklin has quit IRC (Remote host closed the connection)
09:15:53 *** reldred has quit IRC (Remote host closed the connection)
09:15:53 *** _jgr_ has quit IRC (Remote host closed the connection)
09:15:53 *** squirejames has quit IRC (Remote host closed the connection)
09:15:53 *** peter1138 has quit IRC (Remote host closed the connection)
09:15:53 *** wensimehrp has quit IRC (Remote host closed the connection)
09:15:53 *** merni has quit IRC (Remote host closed the connection)
09:15:53 *** emperorjake has quit IRC (Remote host closed the connection)
09:15:53 *** spy0016158 has quit IRC (Remote host closed the connection)
09:15:53 *** clark_l has quit IRC (Remote host closed the connection)
09:15:53 *** exceptik has quit IRC (Remote host closed the connection)
09:15:53 *** mnhebi has quit IRC (Remote host closed the connection)
09:15:53 *** bohaska has quit IRC (Remote host closed the connection)
09:15:53 *** yozora3 has quit IRC (Remote host closed the connection)
09:15:53 *** belajalilija has quit IRC (Remote host closed the connection)
09:15:53 *** truebrain has quit IRC (Remote host closed the connection)
09:15:53 *** kuhnovic has quit IRC (Remote host closed the connection)
09:16:02 *** DorpsGek_vi has joined #openttd
09:16:12 *** truebrain has joined #openttd
09:16:12 <truebrain> and ugh, `importlib_resources` is the new `six`. That will be "fun"
09:16:52 *** andythenorth has joined #openttd
09:16:52 <andythenorth> `six` gives me memories of `five`
09:16:56 <andythenorth> wonder if it's the same people ๐
09:18:13 <truebrain> What a mess, what a mess ๐ (not your mess; it is just a mess ๐ )
09:18:40 <truebrain> `zipp` is also a polyfill
09:19:02 <truebrain> we used to have only one polyfill dep .. `six`. Now there are many of them
09:19:19 <truebrain> seems Python is going to npm way ๐
09:23:34 <andythenorth> so...I've made a bunch of grfs depend on an nmlc feature that I didn't know is unreleased ๐
09:23:37 <truebrain> grr, and now what is wrong with this annotation check ....
09:23:47 <truebrain> seems the name changed slightly or something
09:24:00 <truebrain> so it wasn't seen as "run", and was waiting for it
09:24:05 <truebrain> slapped it enough for it to continue now ...
09:24:20 <truebrain> LordAro: does this PR now seems right to you? If you run your lines of code again, does it still shows a diff?
09:26:08 <truebrain> and lol @ bug of `uv` .. "I consider that intentional" , to not be pip compatible? Nice ๐
09:31:46 <andythenorth> oh, I can just template in my compile to recreate the missing nmlc feature ๐
09:32:46 <LordAro> truebrain: no further diff :)
09:33:23 <truebrain> `uv` is nice btw; at least helps with getting the right Python version, and testing compatibility ๐
09:33:47 <truebrain> I just can't find how to run `uv pip` in a venv, without going into the venv. That is sad ๐
09:34:32 <LordAro> yeah, i haven't really figured out all its usages yet
09:34:47 <truebrain> right, time to deploy dibridge .. it might be that we can't talk to each other in a moment, but that is all on you then ๐ ๐ ๐
09:36:53 <andythenorth> `A single tool to replace pip, pip-tools, pipx, poetry, pyenv, twine, virtualenv, and more.` is a bold claim ๐ฎ
09:37:06 <truebrain> it is really tricky to see what versions dependabot is ignoring
09:37:25 <truebrain> I can only find how to unignore stuff per dependency, meaning you need to know what you ignored in the first place
09:37:52 <truebrain> anyway, deploy-time
09:37:58 *** DorpsGek_vi has quit IRC (Remote host closed the connection)
09:37:58 *** truebrain has quit IRC (Remote host closed the connection)
09:37:58 *** andythenorth has quit IRC (Remote host closed the connection)
09:38:06 *** DorpsGek_vi has joined #openttd
09:38:19 *** truebrain has joined #openttd
09:38:40 <truebrain> nice! Nice work LordAro ๐ And tnx a lot for helping out!
09:39:03 <LordAro> ah, but does it fix the original issue of the andy sending certain unicode characters?
09:39:07 <truebrain> And yes, I actually do check all these things I mentioned in the last hour or so, when looking at those PRs. Making sure things are sane, and nothing weird gets in, and our Python is actually new enoguh to get the latest, etc ๐
09:39:17 <truebrain> You had an original issue ? ๐
09:39:29 <LordAro> impressive level of dilligence
09:39:53 <truebrain> I reimplemented dibridge in go, but I haven't found the guts to replace the Python version with the Go version
09:40:01 <truebrain> it does add some functionalities that were requested ๐
09:41:29 <truebrain> haha, it seems I didn't even push the code to GitHub yet .. why not? I don't know! Work as taken too much resource cycles .... I should fix that ๐
09:49:52 *** peter1138 has joined #openttd
09:49:52 <peter1138> Urgh, VehicleViewWindow has a 'fun' way to pick different strings.
09:57:08 <truebrain> meh; too many changes to update everything smoothly ๐
09:57:13 <truebrain> (external changes, that is)
10:02:32 <peter1138> andythenorth: what about now?
10:07:33 <truebrain> LordAro: which Python version shall we bump the other repos to? What you think would be a safe version? 3.10? 3.11? Maybe 3.12?
10:07:54 <peter1138> (Global string parameters disabled)
10:08:19 <truebrain> peter1138: I once started on that work; I got mental before I finished the first pass ๐
10:08:42 <peter1138> I'm on my second pass.
10:09:02 <peter1138> Trying to find sections to break it up into is... difficult.
10:09:16 <truebrain> at least your approach doesn't crash the game if you do it wrong ๐
10:10:29 <peter1138> Exceptions are useful ๐
10:10:39 <truebrain> 3.13 really is "too new". 3.10 is good for another 2 years ..
10:11:09 <LordAro> i'd be tempted to say stay on 3.9 unless there's something particularly desirable in newer versions
10:11:24 <truebrain> we are on 3.8, so there is no staying on 3.9 ๐
10:11:45 <peter1138> My Debian Stable system is 3.11
10:11:53 <peter1138> If it's old enough for Debian stable...
10:12:16 <truebrain> there is nothing really in any of the 3.10+ that we "need"
10:12:37 <truebrain> 3.13 is interesting in terms of performance, but it is a long way from being useful
10:16:14 <truebrain> lol, I just received spam on an email I use only for commits .. it starts with: "I am sorry if my mail intruded your privacy."
10:19:20 <truebrain> lol, `uv` does make installing deps scary fast ๐
10:20:37 <truebrain> okay, let's try this ...
10:20:50 <LordAro> i'm only aware of it because it's the same company that makes `ruff`
10:21:08 <LordAro> which is also much faster than flake8
10:21:16 <truebrain> I haven't tried `ruff`. Might be worth trying some day ๐
10:21:26 <truebrain> I have to admit, I am slowly migrating most of my work to Go
10:21:45 <truebrain> as Python is nice, but ... especially for webservers, performance is meh
10:21:57 <peter1138> Hmm, maybe I should start PRing some of this.
10:22:25 <LordAro> truebrain: for webservery stuff, yeah, Go's a good shout
10:22:29 <truebrain> peter1138: sounds like a good idea, yes ๐ If that is possible, ofc ๐
10:22:38 <LordAro> i think it's support in other areas is disappearing
10:22:55 <truebrain> LordAro: yeah, mostly, I was looking into some performance issues with OpenTTD services, and not unexpected, it turns out that if it is handling 1 request which stalls a bit, no other requests are processed
10:23:21 <truebrain> Python ofc tries to fix that, years late, with 3.13
10:23:30 <truebrain> but it will take years for that to settle, I imagine ๐
10:23:46 <truebrain> and although Go is quirky, it is a rather nice language to also quickly build stuff
10:24:06 <truebrain> it just has weird quirks ๐
10:24:28 <truebrain> for example, when using it to produce WASM binaries, the WASM binaries are GIGANTIC, and you need `tinygo` to have them somewhat sane (size-wise) ๐
10:24:57 <truebrain> okay, let's deploy bananas-api to staging, and let's see if it still actually works ๐
10:25:38 <LordAro> heh, yeah, good ol GIL
10:26:03 <truebrain> the GIL is, for most services on openttd.org, much more an issue than I initially expected
10:26:12 <LordAro> how GIGANTIC are we talking?
10:26:17 <truebrain> it adds a lot of latency to services like the TURN service
10:26:27 <truebrain> owh, WASM binaries are 2+ MiB when building with Go
10:26:32 <truebrain> where the same is ~20 KiB with Rust
10:26:41 <LordAro> i was about to say, 2MB not all that much
10:26:51 <LordAro> you should try packaging python as an exe...
10:26:51 <truebrain> it is if you get it every time you visit a webpage ๐
10:27:13 <peter1138> LordAro: Smaller than a temporary buffer for generating deserts...
10:27:16 <truebrain> by now I came to peace with the fact Python will never be able to efficiently target WASM ๐
10:27:38 <truebrain> only a very small subset of Python might, but yeah ... ๐
10:28:01 <LordAro> our "main product" at work is distributed via an installer that is currently 1.2G
10:28:06 <LordAro> i think it expands to around 3/4G
10:29:34 <truebrain> I was porting a WASM library of mine from Rust to Go, to see how it went
10:29:40 <truebrain> it went from 600 KiB to at least 5 MiB
10:29:43 <peter1138> At least it's not 5G, that'll give you brainworms...
10:29:54 <truebrain> I know, just ~10 times bigger, but still, I don't find that acceptable ๐
10:30:10 <truebrain> maybe in modern web day and age it is; but meh
10:30:43 <LordAro> tbf, 25% of that is a copy of the GNAT compiler
10:32:05 <truebrain> okay, new bananas-api seems to run fine on staging
10:32:16 <truebrain> so I guess Ican just merge it? YOLO? ๐
10:32:50 <LordAro> when's our peak time? :p
10:33:01 <truebrain> in a few hours ๐
10:33:14 <peter1138> Perhaps give out a notice first? Then when users complain we can say there was a notice...
10:33:53 <peter1138> Like last time there was that outage and 'some' (probably one) users were getting quite weird about it.
10:34:19 <truebrain> notice given in the channels that would care abou tit
10:37:06 *** gelignite has joined #openttd
10:37:34 <truebrain> I do remember someone was working on bananas-api, to add some authentication handler. Just don't remember the username. Might be important for them to know this too ๐
10:37:56 *** andythenorth has joined #openttd
10:37:56 <andythenorth> peter1138: for lunch?
10:39:22 <truebrain> right ... if after a while this repo hasn't shown any signs of issues, I am pretty sure we can safely bump all other repos too ๐
10:50:58 <xarick> I'm unable to iterate over a DiagonalTileArea
10:55:35 <peter1138> Me too. I let the code do it.
10:58:59 <peter1138> Something like `DiagonalTileIterator it{tile1, tile2}; for (TileIndex tile = it; tile != INVALID_TILE; tile = ++it) { ... }`
11:00:01 <peter1138> (Or pass an existing DiagonalTileArea instead of `tile1, tile2`)
11:09:26 <peter1138> That Create() method is used in some places because the code can use either type, and the unique_ptr is used for type erasure.
11:17:37 <andythenorth> I can't be arsed to fix the grfs ๐
11:18:00 <andythenorth> classes were a misadventure ๐
11:25:42 <andythenorth> maybe I should start something else in a new branch
11:26:04 <andythenorth> currently all my grfs are stuck, can't get any further ๐
11:28:48 <andythenorth> 'sounds like excuses'
11:38:11 <xarick> thx, i did some changes around, I expect this to be faster
11:39:19 <xarick> unless the erase method is too slow
11:41:03 <xarick> got a NOT_REACHED ๐ฆ
11:43:43 <xarick> can't dereference vector bla
11:43:51 <xarick> i always manage to trigger this thing
11:45:55 <xarick> ah, the vector is empty
11:47:32 <xarick> [2024-12-08 11:47:15] dbg: [misc:0] num_tree_tiles = 15246472
11:47:32 <xarick> [2024-12-08 11:47:15] dbg: [misc:0] [GenerateTrees] 3108664 us [avg: 3108664.0 us]
11:47:58 <xarick> down from 900 something seconds
11:50:05 <peter1138> Hmm, maybe I should do encoded strings differently.
11:50:32 <peter1138> They are a bit inefficient if there's no parameters, as the initial StringID still needs to be converted to text.
11:51:09 <peter1138> Gah, why is std::string so large.
11:51:35 <peter1138> Tempted to use char *, 8 bytes instead of 32 bytes. (Yes, I know, SSO).
12:08:06 <xarick> hmm i have a problem, maybe
12:08:48 <xarick> need to test this with lower heights
12:09:17 <xarick> i think this results in tons of trees compared to previous
12:11:23 <xarick> previously, it was doing something akin to 50% chance to place a tree in the area, and then another unknown chance that some tiles in the area remain untree'ed
12:11:58 <xarick> and that's already by bruteforcing
12:13:31 <xarick> but now... hmm it always places a tree in any available spot for a tree each time it's called
12:15:29 <xarick> I need a much lower value for j
12:21:29 <peter1138> You need to reduce j by a factor related to the number of suitable tiles.
12:21:41 <peter1138> Number of unsuitable...
12:22:31 <peter1138> Something simple like `j = initial_value_of_j * suitable_area / full area` perhaps.
12:23:12 <peter1138> Will probably still result in more trees though.
12:38:01 <peter1138> Hmm, probably the first commit shouldn't be there.
12:48:03 <andythenorth> so...is it ok to commit things to main branch of a grf, that can't be compiled?
12:48:15 <andythenorth> used to be absolute **no** for coop grfs
12:48:40 <peter1138> If it's because it's broken, no.
12:48:49 <peter1138> If it's because it needs a pre-release version of a tool, maybe.
12:49:09 *** talltyler has joined #openttd
12:49:09 <talltyler> Are you referring to FRAX constants?
12:49:49 <talltyler> I am not opposed to adding them to NML, but I have no permissions to do anything in that repo ๐
12:49:49 <talltyler> (maybe this is why)
12:50:49 *** johnfranklin has joined #openttd
12:50:49 <johnfranklin> How to deal with 1 and 2 pence?
12:53:35 <talltyler> Anything needed in OpenTTD? The potable/non-potable PR got merged already.
12:53:49 <LordAro> i'd probably have not taken them to begin with
12:55:26 <peter1138> talltyler: If "FRAX" is incompatible with the original cargo classes, then merging anything into vanilla is trying.
13:02:58 <andythenorth> it is incompatible, which is expected ๐
13:03:19 <andythenorth> I wasn't expecting vanilla to change/add constants
13:11:07 <peter1138> That... seems unlikely.
13:11:56 <andythenorth> I guess I'm a bit stuck on what's best
13:12:13 <andythenorth> I can build locally using [whatever]
13:12:30 <peter1138> Which part is broken?
13:12:42 <andythenorth> not sure, trying to figure out the options
13:13:01 <peter1138> Without native support in OpenTTD, I don't think additional constants should really be added to NML itself.
13:13:29 <peter1138> e.g. we don't add all the various railtype schemes people have come up with.
13:14:17 <andythenorth> there are 3 possible ways to insert the classes
13:14:17 <andythenorth> - set the bit numbers directly, using compile-time python constants and templating
13:14:17 <andythenorth> - set the classes, using nml `const` which will be in the next version of nml, with a file of constants resolving to bitnumbers
13:14:17 <andythenorth> - rely on the classnames getting added to nmlc as constants
13:14:51 <peter1138> Isn't 2 the most appropriate way?
13:14:59 <peter1138> Const is already in NML...
13:15:13 <andythenorth> well the next nml release is a bit of a grey area, but yes
13:15:46 <andythenorth> ok, so if the constants file is included in the concatenated firs.nml, that will work with forsk
13:15:56 <peter1138> A grey area? If you mean "when", sure. Nothing is going to be ripped out.
13:16:40 <andythenorth> I just mean 'when', as the majority of nml authors likely can't build nml
13:17:41 <andythenorth> ok, so constants, and they'll be included in firs.nml, as many FIRS forks appear to just copy all 275k lines of firs.nml and edit it
13:18:26 <peter1138> Includes would be nice, though I think that was very much a draft.
13:18:47 <andythenorth> I'm not depending on even more unreleased stuff ๐
13:20:11 <peter1138> No, that one is not merged so no.
13:20:31 <andythenorth> do we also need to delete `CC_NEO_BULK` from nml?
13:20:41 <andythenorth> it redefines `CC_NON_POURABLE`
13:20:59 <peter1138> Don't close anything yet.
13:21:07 <xarick> my diagonal math skills are failing me
13:21:08 <peter1138> I am just one guy with an opinion.
13:21:16 <xarick> 17 * 17 is not 545 ๐ฆ
13:21:24 <andythenorth> mostly I just need to outsource having an opinion ๐
13:21:47 <peter1138> `17*17 + 16*16` is 545.
13:21:49 <andythenorth> ok shops time, brocolli required
13:51:13 <_glx_> ah codeQL and templates, not fully working it seems
13:53:23 <xarick> faster trees was slower
13:55:59 <peter1138> Hmm, this is not working.
13:59:41 <peter1138> Oh. Why did I do that?
14:00:08 <peter1138> Copied and pasted `EncodedString &&caption` to the member variable.
14:00:18 <peter1138> It should, of course, be `EncodedString caption`
14:01:24 <_glx_> not the first false positive for "unused variable" in pack expansion
14:07:16 <peter1138> Before: ๎F0B:5AF:72C
14:07:16 <peter1138> After: ๎Transfer: ยฃ1,455๎ / ๎Income: ยฃ1,836
14:08:08 <peter1138> How short is short string optimisation? Hopefully that before fits...
14:08:41 <Rubidium> was that like 15 bytes?
14:09:06 <peter1138> Could be just under.
14:12:52 <peter1138> It's all _glx_ 's fault, with the suggestion to use string encoding. It's definitely feasible.
14:13:21 <peter1138> Do not trust, this comes from an old Stack Overflow answer...
14:13:21 <peter1138> > On a 32 bit machine, 10 chars will fit in the short string. sizeof(string) is 12.
14:13:21 <peter1138> > On a 64 bit machine, 22 chars will fit in the short string. sizeof(string) is 24.
14:13:54 <peter1138> But *we're* not allowed to type-pun ๐
14:14:39 <Rubidium> peter1138: for which compiler/libstdc++? As it differs. Given the order of the numbers I guess clang
14:14:58 <_glx_> silly me, suggesting an existing way to get rid of global param copies
14:15:18 <peter1138> That's why I said "Do not trust". the answer was vague enough as it is ๐
14:16:46 <_glx_> but the first step looks so clean without the SetDParam
14:16:50 <andythenorth> did I need to fix FIRS tile animation?
14:17:15 <peter1138> Well, one idea was to have vectors of stringparameterdata everywhere.
14:17:22 <peter1138> But that was... yeah, definitely not clean.
14:18:27 <peter1138> Doing it with pack expansion allows us to closely tie everything together.
14:19:31 <peter1138> Actually, GetEncodedString() could probably be rewritten to avoid the MakeParameters call.
14:20:00 <peter1138> Although then it would be inlined everywhere.
14:20:16 <peter1138> We build an array, then pass that to GetEncodedString().
14:23:59 <andythenorth> means that FRAX will map onto the old/wrong class constants
14:24:06 <andythenorth> why did I do that? ๐
14:24:46 <peter1138> WIP that didn't get updated?
14:24:54 <andythenorth> probably made sense at the time
14:28:18 <peter1138> Hmm, although a constexpr ShowErrorMessage() might be nice.
14:28:23 <xarick> which container is ideal for inserting and removing items? still vector?
14:29:06 <peter1138> A constexpr GetEncodedString() might be nice.
14:29:22 <peter1138> xarick: How many items, and to and from where?
14:30:01 <peter1138> Hmm, I can probably special-case a constexpr GetEncodedString() with no parameters, actually.
14:30:02 <xarick> 545 items to 0 items or to when j reaches 0, whichever comes first
14:30:28 <xarick> 545 theoretical maximum
14:30:28 <peter1138> Probably vector is fine then.
14:30:47 <peter1138> Why does it need to change?
14:30:59 <peter1138> Can't you add only candidate tiles to the list?
14:31:58 <xarick> yes, start by doing that
14:32:12 <xarick> but then it enters the j loop
14:32:23 <xarick> and removes from the candidate tiles
14:34:24 <peter1138> Oh, std::string can't be constexpr I think. Never mind.
14:34:28 <_glx_> it mostly depends where you insert and from where you removed
14:34:43 <_glx_> vector is not the best when everything happens in middle
14:36:45 <_glx_> and depending on how you iterate you can have "surprises" with invalidated iterators
14:39:25 <xarick> ``` while (j-- != 0 && !available_tiles.empty()) {
14:39:25 <xarick> std::vector<TileIndex>::iterator it = std::next(available_tiles.begin(), RandomRange(static_cast<uint32_t>(available_tiles.size())));
14:39:25 <xarick> PlaceTree(*it, Random());
14:39:25 <xarick> _num_trees_placed_at_same_height++;
14:39:25 <xarick> available_tiles.erase(it);
14:43:51 <xarick> gonna try some other containers
14:48:07 <peter1138> 545 elements is probably small enough to win.
14:48:32 <peter1138> std::deque will be zero difference.
14:49:05 <peter1138> std::unordered_map will be quicker at removing.
14:49:15 <peter1138> Er, std::unordered_set.
14:49:24 <peter1138> std::set will be slower to iterate.
14:49:40 <peter1138> std::list will require jumping around fro element to element, even for removing.
14:49:45 <andythenorth> hmm possibly mapping to the nml class constants was intended, not sure ๐
15:17:51 <xarick> unordered set was slow, or I did it wrong
15:18:12 <andythenorth> could these be merged? They'd simplify my local nml patch queue? ๐
15:25:40 <peter1138> Okay, I need to faff around with the company error message now.
15:26:18 <peter1138> I may need to extra the code that decodes an encoded string...
15:33:49 <xarick> copilot suggested me to use std vector with unordered map
15:34:55 <xarick> solo vector still better
15:36:51 <_glx_> container in container is often not the best solution
15:37:32 <_glx_> but all depends on the goal
15:38:49 <peter1138> I guess you are not prefiltering your vector for invalid tiles, that may be expensive.
15:39:24 <xarick> let me upload my current code
15:41:37 <peter1138> Hmm, 1000 goes, and j is related to tile height.
15:43:32 <peter1138> Okay, I do have a constexpr GetEncodedString() now, but it's not being constexpr ๐ฆ
15:44:52 <andythenorth> what am I missing? The number is wrong?
15:44:59 <andythenorth> can't see for looking ๐
15:52:54 <_glx_> no you're right, I touched the wrong line ๐
15:52:57 <andythenorth> I only tested for trains ๐
15:54:32 <peter1138> I didn't think my original question was unclear, so I'm wondering what I could have done to make it clearer.
15:54:50 <_glx_> it was clear to me ๐
15:58:59 <andythenorth> quite often my brain doesn't do the thing ๐
16:01:44 <peter1138> clangd is going a bit mad.
16:02:19 <_glx_> updated commit in my branch
16:05:02 <andythenorth> how do I update the PR now? ๐
16:05:10 <andythenorth> I have a glx remote
16:10:19 <peter1138> Is there a constexpr way to convert a constant to a utf8-representation of it?
16:12:53 <peter1138> If CCC = 0x1234, I can use "\u1234" for its utf8 representation I think. But not directly with the constant.
16:14:24 <_glx_> oups nml repo need an update
16:15:00 <_glx_> Error: The version '3.7' with architecture 'x64' was not found for Ubuntu 24.04
16:15:33 <LordAro> that'll be that ubuntu-latest thing it was warning about ;)
16:17:18 <_glx_> regression checks 3.9, 3.10, 3.11 and 3.12, release uses 3.x, but testing is still on 3.7
16:17:56 <_glx_> I'll go with 3.x, should be fine for black
16:23:20 <_glx_> hmm maybe I should do it for codeql too (it's 3.8 right now)
16:24:02 <xarick> at low heights (aka low values of j) I get worse times ๐ฆ
16:31:45 <xarick> okay i see where this shines most
16:32:41 <xarick> the difference in heights around the original tree
16:33:00 <xarick> the lesser the number of tiles, which means the rougher the terrain, the best this gets
16:33:06 <peter1138> But if it's flag...
16:33:09 <peter1138> But if it's flat...
16:33:31 <_glx_> it's always a balance, you may improve for some cases but getting worse results in other
16:33:51 <_glx_> the question is which case is more common
16:33:55 <xarick> if the terrain around the original tree is too flat, too smooth, this vector approach turns out slower
16:47:34 <peter1138> Trying to figure out the best way to get rid of SetDParamsForOwnedBy.
16:49:03 <peter1138> Especially OWNED_BY_OWNER_IN_PARAMETERS_OFFSET
16:49:04 <_glx_> oh this function is not hacky at all
16:50:06 <peter1138> CommandCost could use EncodedString instead of StringID, but I'm wary of that as there are a lot of error behind the scenes that you never see.
16:50:17 <_glx_> nice abuse of the global param array
16:51:00 <peter1138> e.g. water flooding industries every tile loop (because it's not in the non-floodable list) causes an error to be generated, which is ignored because it's user-generated error.
16:51:22 <peter1138> If it starts formatting strings at that point it will definitely cause slow downs.
16:52:07 <peter1138> Probably the path of least resistance is to use a static parameter array, but dedicated to errors, not shared with global parameters.
16:52:21 <peter1138> And also store the owner separately.
16:56:29 <_glx_> yeah SetDParamsForOwnedBy() seems to do 2 things, set OWNED_BY_OWNER_IN_PARAMETERS_OFFSET for errors, and set strings and params for normal cases
16:57:23 <_glx_> I guess it could return an EncodedString for the second part
17:01:53 <_glx_> errors are actually the most complex to move away from global array, as in many cases the args are context dependant and the error is fired (and sometimes not) way after parameters
17:16:04 <johnfranklin> someone said it is over when a tram enters into an โtramway-end road stopโ with an irremovable object (industries) ahead.
17:17:11 <_glx_> it's supposed to be a special case in handling, allowing reversing of the tram
17:17:30 <_glx_> but maybe not for stations
17:18:36 <peter1138> Hmm, seems if I do things too quickly for VS Code it can trash loads of files ๐
17:20:13 <peter1138> `rereturn CommandCostTR_ERROR_SITE_UNSUITABLE);`
17:20:18 <peter1138> How did search and replace do that...
17:25:22 <xarick> use both methods, depending on height differences
17:25:53 <xarick> too little differences in height? use original method.
17:26:11 <xarick> too many differences in height? use area method.
17:26:51 <xarick> it has 3 tiles to check heights, for the decision
17:28:16 <xarick> it's not an exact method, but works okayish
17:28:55 <xarick> let me check the worst case scenario
17:32:30 *** Wormnest has joined #openttd
17:43:04 <johnfranklin> How to pronounce โshouldโveโ?
17:43:31 <johnfranklin> Like, some easy questions hard to describe answers
17:44:40 <peter1138> It's pronounced "should've"
17:44:58 <peter1138> Rhymes with "could've"
17:45:57 <johnfranklin> dโve part like this?
17:46:42 *** belajalilija has joined #openttd
17:47:20 <johnfranklin> So it is a very loud โdโ
17:47:38 <belajalilija> johnfranklin: Yes
17:48:27 <peter1138> I'm going to have to start saying coulDVE, woulDVE, shoulDVE, shouting on the last morning...
17:49:37 <belajalilija> I love double contractions
17:50:29 <belajalilija> Knew Iโd find myself
17:53:38 <peter1138> fo'c'sle is short for forecastle
17:54:08 <peter1138> But forecastle is not pronounced forecastle, so...
17:54:20 <peter1138> (It's also not a hugely common word)
17:54:51 <andythenorth> hmm new FIRS 4 is now on bananas
17:54:58 <andythenorth> changed classes ๐
18:00:48 <talltyler> In the American South, you can suggest an alternative course of action in hindsight by saying โmightโve couldโ ๐คจ
18:18:03 <peter1138> Made something const and it broke everything.
18:22:44 <peter1138> Ah, got it. Too much function overloading and templates.
18:27:56 <truebrain> found a side-effect of the bump earlier ๐
18:36:16 <andythenorth> so what do I need to do make FIRS faster?
18:36:24 <andythenorth> not animate all the tiles?
18:40:00 <_glx_> oh indeed I misread the code
18:41:37 <xarick> unordered_set not as fast as I thought for some things
18:46:02 <peter1138> There is a reason I've been liberally using vector and lower_bound recently ๐
18:52:03 <xarick> i must evaluate the original method by the number of failed attempts
18:52:16 <xarick> i suspect it's failing 99% of the time
18:52:28 <xarick> meaning that j is absurdly high
18:52:40 <xarick> will check this out after dinner
19:13:02 <andythenorth> currently Iron Horse populates the text stack (for every vehicle) differently depending on context, e.g. purchase, autoreplace, etc
19:13:12 <andythenorth> this creates a lot of advanced varact2
19:13:55 <andythenorth> wonder if I could just put all the substrings on the stack, then have just have contextual strings
19:41:35 *** Flygon has quit IRC (Read error: Connection reset by peer)
19:58:34 <andythenorth> is there a string code for discarding a stack value?
19:59:15 <andythenorth> `85 Discard next word from stack`
20:00:04 <peter1138> This might not be workable after all.
20:03:50 <peter1138> /me tries something.
20:13:02 <peter1138> Ah, phew. Just need a different way to flag excised text effects.
20:28:36 <peter1138> Now back to errors.
20:43:23 <xarick> [2024-12-08 19:57:30] dbg: [misc:0] _num_trees_placed_at_same_height = 12724385
20:43:23 <xarick> [2024-12-08 19:57:30] dbg: [misc:0] _num_trees_failed_at_same_height = 94881366655
20:43:32 <xarick> is that 99% fail rate?
20:51:18 <andythenorth> hmm, should I refactor all of Horse name string handling?
20:51:33 <andythenorth> reduces grf size from about 39 MB to about 38 MB
20:51:45 <andythenorth> might cut compile time from 60s to 57s
20:51:52 <andythenorth> will take me a couple of hours
20:53:04 <andythenorth> the (small) (medium) (large) suffixes eh, so useful? ๐
20:54:17 <talltyler> I usually just look at the sprite to tell the size ๐
20:58:00 <andythenorth> I find it a bit weird without the visual cue
20:59:16 <andythenorth> it is simpler though
20:59:29 <andythenorth> will there be badges?
21:09:20 *** reldred has joined #openttd
21:11:08 <peter1138> I'll update the PR at some point, and maybe attach a working GRF.
21:11:31 <peter1138> Oof, okay, have to modify strings to make this error message thing work.
21:12:51 <peter1138> I guess it's better but there's all the language files to fix.
21:18:00 <peter1138> > 54 files changed, 392 insertions(+), 367 deletions(-)
21:18:59 *** gelignite has quit IRC (Quit: Stay safe!)
21:24:09 <andythenorth> should I dump the Horse wagon size strings or not?
21:24:47 <andythenorth> maybe all the sizes should be nested
21:25:53 <peter1138> What are the sizes for? Are they limited by intro dates and lifetime?
21:26:19 <peter1138> Like ukrs has small wagons to start with.
21:33:38 <peter1138> Hm, how long will it take to get to Oxford...
21:37:49 <andythenorth> peter1138: integer length trains mostly
21:37:53 <peter1138> Hmm, 2hr15 by public transport, or 45m by private car, damnit.
21:37:58 <andythenorth> also probably realism
21:38:17 <andythenorth> that's mad, you are literally next to Oxford ๐
21:38:46 <andythenorth> is it naptime yet?
21:39:02 <_glx_> and transport is with a change I guess
21:39:16 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:39:47 <peter1138> Or 2,700,000,000us in xarick measurements.
21:43:14 <peter1138> 2 trains and a bus, or 2 buses.
21:43:41 <peter1138> Oh and some walking.
21:48:40 <xarick> ๐ i'm trying to find a reasonable cap value for j
21:49:36 <xarick> trying a cap of 545 for now
21:50:26 <xarick> 545 * 1000 = 545000, eh...
21:55:35 <xarick> those random values for x and y result in 32*32 = 1024 combinations, only 545 will bypass the abs(x) + abs(y) > 16 check
22:01:06 <xarick> j = 100 and it's still generating 12,6 million trees
22:02:00 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:02:51 <xarick> j = 50 -> 12,1 million trees
22:04:30 <xarick> j = 25 -> 10,4 million trees...
22:05:56 <xarick> j = 1 -> 0,8 million trees
22:06:05 <xarick> heh i was just curious
22:09:32 <xarick> I'm not good at probability statistics
22:09:55 <xarick> what shall be the ideal max value of j
22:14:58 *** wensimehrp has joined #openttd
22:29:11 <xarick> j = 1024 -> 12,7 million trees
22:33:07 <xarick> from master results, the value to match is _num_trees_placed_at_same_height = 12707273
22:38:03 <xarick> i need to test flat terrains too
22:43:39 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:44:04 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:03:23 *** ChanServ sets mode: +v tokai
23:04:36 *** ufo-piloot has quit IRC (Remote host closed the connection)
23:04:54 *** ufo-piloot has joined #openttd
23:10:16 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
23:13:25 <xarick> anyone knows a formula for diminishing returns?
23:14:27 <xarick> 1 to 1 ratio up until j reaches let's say... 10
23:15:04 <xarick> if j is over 100, like 125, treat it as 120 or so
23:15:40 <xarick> i see, thanks, i'll take a look at it tomorrow
continue to next day โต
