Time Nick Message 02:43 MTDiscord Okay, afte 15 minutes I think I understand mapgen. my initial question I had going in, was is a vmanip during mapgen actually pointing to the underlying map, or was it a copy. Answer: it's a copy, that is later written to the map. This is good, my plan to tackle the multithreaded c++ mapgen issue, is to force all overgenerated +-1 on mapchunk bounds to always be content ignore at start. My thinking is, the first chunk always works, 02:43 MTDiscord so if they all think they're the first chunk, they will all work. Now to try it 🙂 02:48 MTDiscord I wonder if anyone has run TSan on Luanti. 03:14 MTDiscord Interestingly, my solution had zero effect, I wonder if it's how we write blocks back or something 03:36 MTDiscord > after 15 minutes I understand mapgen 03:36 MTDiscord What did we learn today? 03:39 MTDiscord Nothing! :D 03:41 MTDiscord well, we either read from the existing, generate, or do nothing. the chunk is generated separate from mapblock writing, which is done later in a big old queue, where the server env has a lock. Allowing our mapchunk emergeThreads to just go hog wild on generation. 03:42 MTDiscord the vmanip during this process is a COPY of the map, not a pointer to the underlying map memory - thank goodness in this case. 03:43 MTDiscord No solutions yet found to the +-Y overgeneration issue with multiple emerge threads. I can how this feature is both useful, and broken 😛 03:43 MTDiscord can see* how 03:44 MTDiscord What's especially interesting, is how consistent the issue is with multithreaded mapgen on the same seed, same mapgen, across different games. 03:44 MTDiscord Like, I'm getting 100% repeatability so far, so IF a solution is devised, I'll be confident it's fixed 07:18 nore just to make sure, will there be a dev meeting today? 07:38 [MatrxMT] nore: my bad, I forgot to create the reminder. Just done, so theoretically yes 07:45 nore ok thanks! 08:45 sfan5 @y5nw works for me 08:46 sfan5 >my plan to tackle the multithreaded c++ mapgen issue, is to force all overgenerated +-1 on mapchunk bounds to always be content ignore at start. 08:46 sfan5 this should already be the case 09:07 sfan5 anyway regarding the release we're basically blocked on #16141 (decision) 09:07 ShadowBot https://github.com/luanti-org/luanti/issues/16141 -- Fix handling of skinned meshes for nodes, second try by appgurueu 09:30 sfan5 planning to merge #16095, #16150, #16142 in 15m or more 09:30 ShadowBot https://github.com/luanti-org/luanti/issues/16095 -- Remove PrefersNonDefaultGPU from desktop file by Jan200101 09:30 ShadowBot https://github.com/luanti-org/luanti/issues/16150 -- Clean up menus properly on client exit by sfan5 09:30 ShadowBot https://github.com/luanti-org/luanti/issues/16142 -- Update credits for 5.12.0 by sfan5 15:38 Desour @josiah_wi: I've run tsan before. and there are issues (after filtering out false (I assume false) positives in libs), some easy to fix, some not so much. but I was too lazy to fix or open an issue 15:39 Desour @luatic: or rename the label to CPCSM 17:49 Krock Meeting in 11 minutes 18:00 Krock Pinging those who reacted to the meeting announcement. nore, sfan5, y5nw, @luatic, cx384 18:00 nore Hi! 18:00 MTDiscord hello 18:00 SFENCE_arch Hi 18:00 Krock hello there 18:01 sfan5 hello 18:01 Krock Today's topics: https://github.com/luanti-org/luanti/milestone/26 ---> towards a release 18:02 Krock Merging #16130 in 5 minutes while we're at it. Unless there are objections. 18:02 ShadowBot https://github.com/luanti-org/luanti/issues/16130 -- Mainmenu: Fix error after ESC in dialog windows by SmallJoker 18:03 Krock that would fix one of the open issues. The other being: #16063 18:03 ShadowBot https://github.com/luanti-org/luanti/issues/16063 -- Package with _game suffix not found after rename 18:03 nore I'm good with 16130 18:03 Krock I don't think this is a new issue and judging by the reactions it's not occurring too often 18:05 Krock Is there any other remaining topic? Shall we release today? 18:05 MTDiscord i have not opened an issue for it yet but #16141 fixes two other regressions (rigidly animated gltf node meshes now being broken, the scaling factor for non-skeletally animated gltf meshes having changed) i would like to see fixed. see https://github.com/luanti-org/luanti/pull/16141#issuecomment-2883811012. 18:05 ShadowBot https://github.com/luanti-org/luanti/issues/16141 -- Fix handling of skinned meshes for nodes, second try by appgurueu 18:05 [MatrxMT] It isn't new, but it will occur for everyone who has MTG installed from CDB, from before when it was moved to the Luanti account 18:05 sfan5 #16141 18:05 ShadowBot https://github.com/luanti-org/luanti/issues/16141 -- Fix handling of skinned meshes for nodes, second try by appgurueu 18:05 cx384 I'm here too 18:05 Krock grorp: I see. that explains why it didn't occur to me - it's a git clone. 18:06 [MatrxMT] Fixable by manually installing MTG again and accepting to overwrite 18:06 Krock but didn't this already happen one release ago, when the rename actually happened? 18:06 Krock or was the author changed afterwards? 18:08 [MatrxMT] appgurueu: I suggest mentioning using visual_scale/size as a remedy where the scaling factor mess is documented for nodes/entities 18:08 [MatrxMT] (just a documentation nitpick) 18:08 nore I thought the repository name change wasn't done immediately after the annoucement/the release? 18:09 MTDiscord grorp: sure. nore: yes, the repo rename, but the CDB user was probably renamed later (but i don't know). 18:09 Krock nore: yes, but in this case it depends on the "author" field of the game config 18:10 Krock https://github.com/luanti-org/minetest_game/commit/312a67b40c77395a6c1a791c1f9efaa803635925 18:10 [MatrxMT] more specifically on the author on CDB, I think CDB might overwrite the author in game.conf 18:11 [MatrxMT] Krock: I don't actually know when that move happened 18:12 Krock It's not blocking; there's a workaround, thus it could wait until after 5.12.0. Some LTS distros might be delayed by a few releases anyway 18:12 Krock unless you have a quick and easy solution I suppose we can ignore it for this release 18:13 [MatrxMT] anyway, I don't have time to PR a fix soon. feel free to move ahead without a fix. a fix shouldn't be too hard to accomplish either, just have to handle _game in the alias code. 18:17 Krock okay thanks for the explanation. 18:18 Krock #16141 was mentioned too. Needs reviews, I suppose. 18:18 ShadowBot https://github.com/luanti-org/luanti/issues/16141 -- Fix handling of skinned meshes for nodes, second try by appgurueu 18:18 sfan5 reviews are good but more importantly we need to decide if we want this for the release or not 18:20 Krock Okay. From what I understood so far, the situation doesn't get worse (as in functionality) if this PR is not merged into 5.12.0 18:20 MTDiscord it does 18:20 MTDiscord i can open an issue if you want, but the gist is: the scaling of gltf nodes has changed 18:21 sfan5 when did we add gltf again? 18:21 Krock when has it changed? in #16112? 18:21 ShadowBot https://github.com/luanti-org/luanti/issues/16112 -- [no squash] Fix handling of skinned meshes for nodes by appgurueu 18:21 MTDiscord and gltf models which rely on transforms are now broken 18:21 Krock sfan5: 5.10.0 18:21 MTDiscord it is not super problematic, i doubt many games use it; it will be tolerable if broken, but it will hurt gltf adoption 18:22 MTDiscord Krock: it changed (unknowingly to me) when i took out the hack which implemented rigid animation via skeletal animation. 18:22 Krock > // Compatibility: Only apply BS scaling to static meshes (.obj). See #15811. 18:22 ShadowBot https://github.com/luanti-org/luanti/issues/15811 -- Mesh scaling factor madness 18:23 Krock most likely this section in the code 18:23 MTDiscord because our code for node meshes did not handle the rigid default pose up until now. (this also affects x but i don't think anyone noticed) 18:23 MTDiscord yes, what's responsible for much of the mess is the fact that skeletally animated models simply were not scaled 18:24 nore I have a quick commit to try to fix #16063 https://github.com/Ekdohibs/minetest/commit/4be8fc59a7f5260b4d3b5f465c5539c9cf437b68 if we want to test 18:24 ShadowBot https://github.com/luanti-org/luanti/issues/16063 -- Package with _game suffix not found after rename 18:24 MTDiscord to summarize there are three issues: 18:25 MTDiscord 1. visual_scale doesn't apply to skeletally animated models. this bug is old, we don't necessarily need to fix it now, but it's good if we do because visual_scale is essential for modders to cope with the visual scale being wrong. 18:25 MTDiscord 2. models which rely on transforms are broken. this may affect x models. it affects gltf models. it used not to affect gltf models. this is a regression i introduced. 18:26 sfan5 ok sounds like we should have it then 18:28 MTDiscord 3. similar to other models, BS scale now applies to non-skeletally-animated gltf models. this means e.g. wuzzy's eyeballs have a scale that's 10x too large now. 18:28 Krock I see that you've checked a few mods against compat. That's great to see. If you're certain that it does not break any existing (let's say) old mods, then I don't see much of an issue there. 18:28 Krock Assuming that these changes only target gltf models which are relatively new 18:29 MTDiscord the fix for (1) also affects non-gltf models, that's what i analyzed in my survey of the server list. 18:29 MTDiscord i looked at node defs for the whole server list. those few mods are just what's left after the filtering described in the comment. 18:30 MTDiscord it shows that not many mods should be impacted by fixing (1). (and if a mod is impacted, the fix is trivial.) 18:31 sfan5 will this put any mods in a situation where they can't have a nodedef that's compatible with 5.10, 5.11 and 5.12? 18:31 MTDiscord no 18:31 sfan5 ok, good 18:32 nore (@grorp if you can look at #16157 to see if that is the fix you had in mind) 18:32 ShadowBot https://github.com/luanti-org/luanti/issues/16157 -- Try to fix cdb aliases for games by Ekdohibs 18:37 sfan5 so if we need to get these PRs reviewed, when is the most likely release date? 18:40 Krock heh same day as they're merged I suppose :3 18:40 nore so these = #16157, #16130 and #16141? 18:40 ShadowBot https://github.com/luanti-org/luanti/issues/16157 -- Try to fix cdb aliases for games by Ekdohibs 18:40 ShadowBot https://github.com/luanti-org/luanti/issues/16130 -- Mainmenu: Fix error after ESC in dialog windows by SmallJoker 18:40 ShadowBot https://github.com/luanti-org/luanti/issues/16141 -- Fix handling of skinned meshes for nodes, second try by appgurueu 18:41 Krock yes, I'd say so 18:41 Krock merging my PR now. forgot about that. 18:41 nore 16157 should be very quick to review, I just don't see how to really test it fixes the problem -- I checked the alias is now correct, but that's all 18:43 nore 16141 is the hardest one to review, I think 18:45 Krock testing those PRs... 18:53 nore from what I read of the code of 16141 it appears to be good and to do what it says it does, but I don't know that part of the code well (and I haven't tested the PR yet) 18:59 rubenwardy there's no release candidate 18:59 [MatrxMT] Also keep in mind that we're having a fast release after this, in July (instead of August) 19:00 Krock Zughy: or skip one release such that the one for Game Jam is even greater :P 19:00 [MatrxMT] Krock: skip this and release in July? 19:01 Krock Zughy: that's not what I meant. We're almost done for 5.12.0. The following version is still far away, thus likely to early to plan anything. 19:02 rubenwardy better to release sooner than later 19:03 Krock we could argue about this all day long. every practice has its advantages and drabacks 19:04 [MatrxMT] rubenwardy: we should start not arriving last minute with issues still on the plate to do that. If I recall correctly I suggested a RC almost a month ago but there were things going on 19:04 rubenwardy we have an agreement to do more regular releases, every 3 months. If we're shifting by a month then it's better to release after 2 than wait for 5 19:05 [MatrxMT] +1 19:05 rubenwardy https://docs.luanti.org/for-engine-devs/releasing-luanti/ 19:05 rubenwardy Release candidate is supposed to be done at the start of a freeze yet always gets forgotten 19:06 MTDiscord do you mean release now and wait for 5? 19:06 rubenwardy that seems to be what Krock is suggesting by skip one release 19:07 MTDiscord That doesnt make any sense 19:07 Krock always? The RC at least happened in the last two versions 19:07 rubenwardy with much delay 19:08 MTDiscord The plan was to release 2 months after this one to shift the schedule and then continue as normal. Alternatively you could do this release and then wait 5. 19:09 [MatrxMT] Waiting 5 means more chances to have new bugs all at once 19:09 MTDiscord Agree, so I would say stick to the original plan 19:13 rubenwardy Krock: are you planning on merging #16146 19:13 ShadowBot https://github.com/luanti-org/luanti/issues/16146 -- Formspec: make style bgimg_middle pixel-perfect by SmallJoker 19:18 Krock rubenwardy: not planned for 5.12.0 but I wouldn't mind 19:18 Krock is it a regression? I don't think so. 19:18 rubenwardy it's a regression at some point 19:23 [MatrxMT] Looking at the calendar, there are 23 weeks (from now) up to 26 October; I suppose we can have two releases à 10 weeks then? (with three weeks of buffer space) 19:23 Krock rubenwardy: you approve; I merge :P 19:25 Krock I'll try to propose the initial writeup of the changelog tomorrow. 19:26 Krock oh nice. there's also this summary: https://github.com/luanti-org/docs.luanti.org/issues/214 20:02 sfan5 can someone tell me a good reason why the engine reads {} as a valid position apparently equal to {x=0,y=0,z=0} 20:02 sfan5 ? 20:05 sfan5 or in other words, why does read_v3s16 vs. check_v3s16 exist at all? 20:08 sfan5 you could argue that {x="1", y="2", z="3"} should be allowed since tonumber works on them but nil values are really just a bug waiting to happen 20:11 Desour lua_tonumber returns 0 if not convertible to number, tonumber returns nil 20:13 Desour idk why we don't use check_vfoo everywhere. would make more sense to me 20:15 sfan5 immediate proposal: for read_v3s16 disallow nil values 20:16 sfan5 someone else can do the change to use check_* everywhere another day 20:51 sfan5 Desour: #16158 20:51 ShadowBot https://github.com/luanti-org/luanti/issues/16158 -- Do not allow vector components to be nil by sfan5