IRC logs for #openttd on OFTC at 2023-07-07
01:57:58 *** Wormnest has quit IRC (Quit: Leaving)
02:22:02 *** D-HUND has joined #openttd
02:25:41 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:04:49 *** keikoz has joined #openttd
04:16:25 *** tokai|noir has joined #openttd
04:16:25 *** ChanServ sets mode: +v tokai|noir
04:23:22 *** tokai has quit IRC (Ping timeout: 480 seconds)
04:29:33 *** D-HUND is now known as debdog
06:36:29 *** nielsm has joined #openttd
08:15:35 <peter1138> Is this thing on?
08:17:17 <FLHerne> no
08:23:16 <pickpacket> Not really
08:24:44 <truebrain> 10 hours of silence .. it finally happened ...
08:24:51 <truebrain> this game is dead
08:25:00 <truebrain> nobody cares anymore πŸ˜›
08:37:53 <pickpacket> Indeed
08:38:07 <pickpacket> we’ll soon see the downloads plummet
08:38:21 <pickpacket> tomorrow they’ll be down to zero and stay that way forever
08:40:50 <andythenorth> I have left already
09:06:19 <truebrain>
09:06:19 <truebrain> I hate stupid validations
09:06:56 <FLHerne> #
09:06:59 <FLHerne> ########################
09:08:54 <FLHerne> oops
09:10:17 <truebrain> you leaked your password mate
09:10:22 <truebrain> guess you should change it now πŸ˜›
09:10:36 <truebrain> also, weird password, all the same key .. don't do that πŸ™‚
09:26:46 <pickpacket> hunter2
09:26:56 <FLHerne> no, that's just the revised version of the hunter2 scheme
09:27:12 <FLHerne> it's a much more complex password, but it looks like ##### to you
09:27:38 <pickpacket> lol
12:38:07 <DorpsGek> [OpenTTD/workflows] TrueBrain opened pull request #35: Change: [CI] publish docs on Cloudflare Pages
12:38:12 <truebrain> once again a PR I cannot really test .. hmmm
12:38:34 <truebrain> either I make a dummy commit to add workflow-dispatch, so I can test
12:38:42 <truebrain> or I just merge this and fix any issue that comes out afterwards πŸ˜›
12:38:51 <truebrain> so either it is always 2 commits, or possibly 1 πŸ˜„
12:39:27 <truebrain> well, maybe _glx_ can give it a looksy, and we just go for the 1-commit approach πŸ™‚
12:40:11 <_glx_> I can try to spot mistakes
12:43:03 <DorpsGek> [OpenTTD/workflows] glx22 approved pull request #35: Change: [CI] publish docs on Cloudflare Pages
12:44:05 <_glx_> but I looks correct
12:45:47 <truebrain> YOLO! πŸ˜„
12:45:48 <DorpsGek> [OpenTTD/workflows] TrueBrain merged pull request #35: Change: [CI] publish docs on Cloudflare Pages
12:46:09 <DorpsGek> [OpenTTD/workflows] glx22 commented on pull request #35: Change: [CI] publish docs on Cloudflare Pages
12:46:47 <_glx_> and of course I noticed something on 3rd read
12:48:52 <truebrain> πŸ˜„
12:49:03 <truebrain> and yet you missed the mistake πŸ˜›
12:49:47 <DorpsGek> [OpenTTD/workflows] TrueBrain opened pull request #36: Fix: [CI] publish the right folder for docs
12:49:54 <truebrain> so still 2 commits πŸ˜„
12:52:57 <truebrain> and now I could test it, and I can tell you it works πŸ™‚
12:56:13 <DorpsGek> [OpenTTD/workflows] TrueBrain merged pull request #36: Fix: [CI] publish the right folder for docs
13:01:09 <truebrain> hmm, for some reason things are missing their health-checks pretty frequently .. which is causing restarts of the services ..
13:01:13 <truebrain> not sure what that is about yet ..
13:10:36 <truebrain> but first, let's address the preview, and where it is published .. I have all the pieces, let's slamp it together!
13:14:28 <_glx_> oh of course the folder
13:14:42 <truebrain> yeah, I copied it from the website .. and I knew I had to change it .. I didn't πŸ˜›
13:15:08 <_glx_> similar to "preview_" in all other PRs
13:17:55 <truebrain> hmmm .. if I migrate previews to CF, it will not have a pretty URL anymore .. that is to say, it will be something like
13:18:25 <truebrain> the View Deployment button will bring you to the right URL, ofc
13:20:07 <truebrain> owh, but I can add a Cloudflare Worker for that, to make that look pretty .. yeah, that will work fine πŸ™‚
13:24:09 <truebrain> what will be a consequence, that all current preview will no longer work, and PRs will need to rebase .. but I guess we can manage that
13:24:29 <truebrain> although we have 39 (!) PRs open with the preview label
13:24:36 <truebrain> someone is slapping that on those PRs like they are cookies πŸ˜„
13:24:39 <truebrain> (it is fine really)
13:25:46 <_glx_> with recent OOM in CI previews will be a pain
13:26:02 <truebrain> something to figure out for sure
13:43:03 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #11116: Change: [CI] rework preview flow and use Cloudflare Pages to publish
13:43:15 <truebrain> I really need to figure out a way to test this before I merge this .. which most likely means finding a way to get the secrets on my fork πŸ™‚
13:43:51 <truebrain> but, that is something to take care of another time πŸ™‚ At least this workflow is much easier to follow πŸ˜„
13:43:54 <_glx_> hmm maybe we could try `--oom-kill-disable`
13:44:11 <truebrain> or we look into why emscripten uses so much memory, and see if we can fix that a bit πŸ™‚
13:45:16 <truebrain> _glx_: as we don't use `-m`, that is a bit odd, honestly
13:45:20 <truebrain> it will kill something else
13:46:01 <truebrain> these runners have 7GB of RAM .. so it is just a bit odd
13:46:24 <_glx_>
13:46:32 <_glx_> could be related
13:47:21 <_glx_> oh CI does a debug build IIRC
13:47:26 <_glx_> let's change that
13:47:45 <truebrain> well, I would expect it to do a debug build πŸ˜›
13:49:02 <_glx_> preview had no OOM issue as far as I can see, but it does a release build
13:49:20 <truebrain> yeah, but that is a weird reason to make the CI do release builds πŸ™‚
13:49:30 <truebrain> I rather have we spend some time looking into why it actually uses so much memory
13:50:06 <_glx_> <> seems to imply -g causes it
13:50:26 <truebrain> someone making an educated guess, as it doesn't seem to change anything for that user
13:50:29 <truebrain> but that is what we need to figure out
13:50:32 <truebrain> does it help us?
13:50:36 <truebrain> or are there other things
13:51:23 <_glx_> IIRC we use debug builds for CI because it's faster (yeah MSVC I'm looking to you)
13:51:34 <truebrain> also make a balance between errors we get
13:52:02 <_glx_> but a debug build for emscripten might not be needed
13:52:17 <truebrain> yeah, but you are not actually fixing anything by saying: owh, now we don't run out of OOM
13:52:27 <truebrain> because a release might also be affected, just might take a few weeks longer before we hit it
13:52:35 <truebrain> it is much more useful to understand why it is doing this
13:52:39 <truebrain> as we might be doing something stupid here
13:53:56 <truebrain> especially as we really should use RelWithDebInfo for our previews
13:54:29 <_glx_> ah <> might be something to try
13:56:25 <truebrain> in general, we should have `WASM_BIGINT` enabled, but for completely different reasons πŸ˜›
13:57:07 <truebrain> but yeah, looking a bit further what is going on really helps with emscripten .. as it is a maze of weird settings and options, where you have to guess what is doing what
13:57:34 <truebrain> it really is a project that was build one block at the time .. and now looking back you go: what the actual fuck have we build! πŸ˜›
14:03:15 <Eddi|zuHause> my firefox is broken and i don't have time to fix it right now...
14:38:40 *** Flygon has joined #openttd
15:17:07 *** HerzogDeXtEr has joined #openttd
15:41:44 *** merni has quit IRC (Quit: User went offline on Discord a while ago)
15:48:26 <DorpsGek> [OpenTTD/OpenTTD] DexterIV opened pull request #11117: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
15:49:01 <DorpsGek> [OpenTTD/OpenTTD] DexterIV updated pull request #11117: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
16:01:32 <_glx_> that change feels wrong
16:03:55 <jfs> psst,
16:05:29 <LordAro> _glx_: unnecessary at best
16:08:30 <_glx_> for me, with the reference, pixel contains the value, so ++ don't go to the next value, but I may be wrong
16:08:52 <jfs> the ++ line is removed entirely
16:09:02 <_glx_> the last one yes
16:09:08 <_glx_> but there are others
16:09:30 <jfs> oh... yes
16:09:43 <jfs> no
16:10:11 <jfs> those are incrementing the pointed-to value, not the pointer
16:10:37 <jfs> no uh, ignore me I've been away from C++ for too long or something
16:11:24 <locosage> it's probably faster to add to the pointer than recalculate it every loop though
16:12:23 <DorpsGek> [OpenTTD/OpenTTD] nielsmh requested changes for pull request #11117: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
16:14:10 *** Wormnest has joined #openttd
16:16:12 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
16:21:34 <DorpsGek> [OpenTTD/OpenTTD] DexterIV updated pull request #11117: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
16:21:43 <DorpsGek> [OpenTTD/OpenTTD] DexterIV commented on pull request #11117: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
16:22:13 <DorpsGek> [OpenTTD/OpenTTD] DexterIV updated pull request #11117: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
16:25:49 <DorpsGek> [OpenTTD/OpenTTD] DexterIV updated pull request #11117: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
16:26:12 <DorpsGek> [OpenTTD/OpenTTD] DexterIV updated pull request #11117: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
16:47:13 <LordAro> well now it's definitely definitely wrong
16:47:36 <LordAro> oh, well
16:47:46 <LordAro> i guess that was unnecessary
17:00:48 <DorpsGek> [OpenTTD/OpenTTD] DexterIV commented on pull request #11117: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
17:00:51 <DorpsGek> [OpenTTD/OpenTTD] DexterIV closed pull request #11117: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
17:06:26 <_glx_>
17:06:26 <_glx_> debug build locally (OOM killed)
17:06:45 <_glx_> that's without any extra flags
17:07:59 <_glx_> retrying with WASM_BIGINT
18:41:21 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master
18:41:22 <DorpsGek> - Update: Translations from eints (by translators)
19:03:22 <truebrain> That is a long time for memory pressure .. I hope that isn't all due to that one call πŸ˜„
19:07:53 *** Wolf01 has joined #openttd
19:08:08 <_glx_> I think it is
19:08:16 <_glx_> it's the linking step
19:10:15 <truebrain> Don't remember linking took that long for me .. wow .. 50% of the time ..
19:10:40 <_glx_> at first I retried with just modifying CMakelists.txt and not deleting the build dir, it linked fine and without memory spike, then I cleaned build and rerun (still waiting)
19:10:56 <truebrain> Promising at least
19:11:30 <_glx_> before I was doing release builds, linking was faster
19:11:34 <truebrain> What I know now and didn't know then, is that WASM has all these extensions, like int64 .. most browsers support that fine, but as it is an extension, emscripten makes it optional
19:12:05 <truebrain> And as we heavily depend on int64 .. it helps to have that on πŸ˜„
19:12:38 <_glx_> ah 97% (waypoint_gui.o)
19:14:14 <_glx_> linking
19:16:51 <_glx_>
19:16:51 <_glx_> finished
19:16:55 <_glx_> way better
19:17:20 <truebrain> funny how that works out
19:17:21 <truebrain> also a lot quicker?
19:18:03 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #11109: Add: [Emscripten] support for bootstrapping
19:18:16 <_glx_> yeah linking step was faster too
19:18:22 <truebrain> good good
19:18:45 <_glx_> hmm I should check the output still runs πŸ˜‰
19:18:48 <truebrain> you make a new PR out of it?
19:20:01 <_glx_> for now I included it in the other PR
19:20:14 <truebrain> okay, let me rephrase: please make a new PR out of it πŸ™‚ It deserves its own reasining
19:20:17 <truebrain> for future reference πŸ™‚
19:20:47 <_glx_> yeah yeah, but as #11109 needed 3 tries to pass CI it's a good test
19:20:56 <truebrain> good πŸ™‚
19:22:12 <_glx_> I guess it was luck if we didn't trigger OOM more often
19:22:31 <truebrain> seems so
19:22:42 <_glx_> and activating json support for real just passed the limit
19:23:01 <truebrain> and I am pretty sure this makes everything run a tiny bit faster too πŸ™‚
19:23:18 <truebrain> for debug-builds, that is
19:23:47 <truebrain> from what I read, this allows WASM to talk to Javascript in 64bit; and for debugging there is a lot more code that might do this (I think?)
19:24:20 <andythenorth> has it been 24 hours since I mentioned unmentionable things?
19:24:27 <_glx_> can't really tell, debug build is slow πŸ™‚
19:25:27 <_glx_> debug build doesn't even reach 1x
19:26:45 <truebrain> nice write-up about bigint
19:29:50 <_glx_> yesterday first try failed in 18m21s, second try failed in 15m33s, third try passed in 13m11s
19:30:14 <_glx_> the new version passed in 6m10s
19:30:59 <_glx_> skippin all the i64 to something else conversion really helps
19:32:17 <truebrain> good πŸ˜„
19:32:23 <truebrain> I like proper solutions for actual problems πŸ™‚
19:32:54 <truebrain> means I also feel safe changing Release to RelWithDebInfo πŸ™‚
19:47:36 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #11118: Codechange: [Emscripten] enable WASM_BIGINT
19:48:07 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #11118: Codechange: [Emscripten] enable WASM_BIGINT
19:48:56 <_glx_> I reused the screenshots, they really help πŸ™‚
19:51:58 <truebrain> right, made a test-setup on my fork for previews .. lets see how it works
19:53:13 <DorpsGek> [OpenTTD/OpenTTD] DexterIV opened pull request #11119: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
20:03:02 <truebrain> _glx_: thinking back, already for a while we had that emscripten could have random compile-times, which always made me wonder a bit wtf it was doing
20:04:03 <_glx_> other targets have random compile-times too
20:05:11 <_glx_> I checked preview compile time before and after and it's still around 14m
20:05:33 <truebrain> `fatal error: 'nlohmann/json.hpp' file not found`
20:05:38 <truebrain> meh .. guess I have to do a full rebuild πŸ˜›
20:05:52 <_glx_> yeah that fixed it for me
20:06:36 <truebrain> (making the PR for RelWithDebInfo btw)
20:06:52 <truebrain> while my new Preview code is running on my fork .. at least it is compiling .. let's see if the rest works out too πŸ˜„
20:07:24 <_glx_> should build fine now in RelWithDebInfo (when I tried yesterday it OOM)
20:08:10 <truebrain> hmmmmmm ... still the above error
20:08:34 <_glx_> restarted the container too ?
20:08:38 <truebrain> yup
20:11:03 <truebrain> mostly a bit odd that detection does work πŸ˜„
20:12:25 <truebrain> I think I know why it happens .. but .. hmm .. let's check
20:12:57 <truebrain> I am missing `-sUSE` statements in the compile line
20:13:05 <truebrain> so it means it only works if you run cmake in the same container instance run
20:13:46 <_glx_> but it should pass the -sUSE if I follow the FindXXX
20:14:07 <truebrain> exactly
20:15:16 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #11119: Codechange: Unnecessry ptr incrementation, max_sprite_size constant
20:15:18 <truebrain> but it did download and install the other libraries
20:15:20 <truebrain> just not this one
20:15:27 <_glx_> weird
20:17:18 <truebrain> argh, preview failed as I was using a cloudflare action .. but that is being run inside the container
20:17:25 <truebrain> so annoying you can't say: stop using the container πŸ˜„
20:17:45 <truebrain> Docker image had Node15 installed .. lol
20:19:54 <truebrain> hmm .. about the `-s`, it is just weird .. it is there for other files, but not for the network_survey .. how about other network files ..
20:20:25 <truebrain> they are there
20:20:33 <truebrain> just missing `-sUSE_NLHOMANN_JSON`
20:21:00 <truebrain> ah, was looking wrong, the `-s` are there, just not nlhomann
20:21:02 <truebrain> so why not .. hmm
20:29:22 <truebrain> bug in our LinkPackage.cmake
20:29:34 <truebrain> not sure why other libraries don't really have that issue
20:31:50 <truebrain> well, no, and yes, hmm .. it is a problem how I patched nlohmann for emscripten
20:32:37 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #11118: Codechange: [Emscripten] enable WASM_BIGINT
20:32:47 <truebrain> there we go
20:36:45 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #11120: Fix: [Emscripten] actually link against nlohmann_json
20:39:30 <truebrain> so now I can do what I actually wanted to do πŸ˜„
20:46:47 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:53:06 *** HerzogDeXtEr has joined #openttd
20:54:13 <_glx_> oh and it worked for LZMA because we link to LibLZMA::LibLZMA
20:55:13 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11120: Fix: [Emscripten] actually link against nlohmann_json
20:57:14 <truebrain> yup
20:57:25 <truebrain> owh, lol, RelWithDebInfo makes the WASM 201MiB in size
20:57:28 <truebrain> yeah .. that is not helping anyone
21:00:22 <truebrain> I am sure there is a way to split debug information from the main stuff, but .. I don't feel like diving into that now πŸ™‚ Getting the preview to work is more important πŸ˜›
21:21:48 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #11120: Fix: [Emscripten] actually link against nlohmann_json
21:35:52 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:45:04 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:49:21 <_zephyris> I'm looking at the loading of the extra newgrf with basesets...
21:49:23 <_zephyris>
21:50:08 <_zephyris> This indicates its not loaded as a static newgrf, `FillGRFDetails(master, false, BASESET_DIR);` where `FillGRFDetails` takes the arguments `FillGRFDetails(GRFConfig *config, bool is_static, Subdirectory subdir = NEWGRF_DIR);`
21:51:39 <_zephyris> I'd have thought it should be actually handled as static newgrf - though would that mess up the load order?
21:52:02 <_zephyris> (It's all to do with this behaviour:
21:52:14 <_glx_> static are loaded after everything
21:54:07 <_zephyris> Hmm
21:55:17 <_zephyris> So I've set up a settings newGRF for OpenGFX2 which is just sets some parameters, which the OpenGFX extra grf can read.
21:57:14 <_zephyris> But setting the settings newGRF as a static newgrf triggers a multiplayer async warning. Presumably because a static newgrf (in this case the settings newgrf) parameter is being read by a "non-static newgrf" (the base set extra grf). Even though the extra grf is really more of a static.
21:58:50 <_glx_> basesets are not static, they are outside _grfconfig
22:01:09 <_glx_> that's why it's better to have a dedicated way to set parameters for extra grf
22:03:17 <_glx_> maybe with extra stuff in `graphicsset` setting
22:04:13 <_glx_> similar to how it's done for frivers
22:16:00 <truebrain> funny, I need to upgrade emscripten to .42, as it has node16 (instead of node15), which I need to make uploading to Cloudflare Pages work πŸ˜„
22:16:05 <truebrain> guess we will be doing that too πŸ˜›
22:16:22 <truebrain> curious if the patches still apply
22:16:30 <truebrain> they do \o/
22:18:54 <_zephyris> _glx_: Makes sense, but well beyond my ability I suspect πŸ™‚
22:48:36 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:07:21 *** urdh has quit IRC (Quit: Boom!)
23:08:37 *** urdh has joined #openttd
23:23:59 <_glx_>
23:23:59 <_glx_> RelWithDebInfo linking was flirting with danger