| Time |
Nick |
Message |
| 00:33 |
|
SFENCE joined #luanti-dev |
| 00:59 |
|
SFENCE joined #luanti-dev |
| 01:33 |
|
SFENCE joined #luanti-dev |
| 02:00 |
|
SFENCE joined #luanti-dev |
| 02:05 |
|
SFENCE joined #luanti-dev |
| 02:33 |
|
SFENCE joined #luanti-dev |
| 02:34 |
|
aliasalreadytake joined #luanti-dev |
| 02:43 |
MTDiscord |
<exe_virus> 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 |
<josiah_wi> I wonder if anyone has run TSan on Luanti. |
| 03:10 |
|
SFENCE joined #luanti-dev |
| 03:14 |
MTDiscord |
<exe_virus> Interestingly, my solution had zero effect, I wonder if it's how we write blocks back or something |
| 03:36 |
MTDiscord |
<josiah_wi> > after 15 minutes I understand mapgen |
| 03:36 |
MTDiscord |
<josiah_wi> What did we learn today? |
| 03:39 |
MTDiscord |
<nathan4220776> Nothing! :D |
| 03:41 |
MTDiscord |
<exe_virus> 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 |
<exe_virus> 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 |
<exe_virus> 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 |
<exe_virus> can see* how |
| 03:44 |
MTDiscord |
<exe_virus> 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 |
<exe_virus> Like, I'm getting 100% repeatability so far, so IF a solution is devised, I'll be confident it's fixed |
| 03:51 |
|
SFENCE joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 04:43 |
|
SFENCE joined #luanti-dev |
| 04:48 |
|
SFENCE joined #luanti-dev |
| 06:45 |
|
ivanbu joined #luanti-dev |
| 07:18 |
nore |
just to make sure, will there be a dev meeting today? |
| 07:38 |
[MatrxMT] |
<Zughy> nore: my bad, I forgot to create the reminder. Just done, so theoretically yes |
| 07:45 |
nore |
ok thanks! |
| 08:22 |
|
Warr1024 joined #luanti-dev |
| 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 |
| 08:46 |
|
Warr1024 joined #luanti-dev |
| 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 |
| 13:41 |
|
SFENCE joined #luanti-dev |
| 13:55 |
|
SFENCE joined #luanti-dev |
| 14:24 |
|
SFENCE joined #luanti-dev |
| 14:27 |
|
SFENCE joined #luanti-dev |
| 14:27 |
|
SFENCE joined #luanti-dev |
| 14:45 |
|
SFENCE joined #luanti-dev |
| 15:07 |
|
SFENCE joined #luanti-dev |
| 15:33 |
|
Desour joined #luanti-dev |
| 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 |
| 15:55 |
|
Noisytoot joined #luanti-dev |
| 16:00 |
|
Noisytoot joined #luanti-dev |
| 16:31 |
|
SFENCE joined #luanti-dev |
| 16:56 |
|
SFENCE joined #luanti-dev |
| 17:01 |
|
SFENCE joined #luanti-dev |
| 17:14 |
|
SFENCE joined #luanti-dev |
| 17:35 |
|
cx384 joined #luanti-dev |
| 17:36 |
|
SFENCE joined #luanti-dev |
| 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 |
|
SFENCE_arch joined #luanti-dev |
| 18:00 |
nore |
Hi! |
| 18:00 |
MTDiscord |
<luatic> 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 |
<luatic> 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] |
<grorp> 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] |
<grorp> Fixable by manually installing MTG again and accepting to overwrite |
| 18:06 |
|
SFENCE joined #luanti-dev |
| 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] |
<grorp> appgurueu: I suggest mentioning using visual_scale/size as a remedy where the scaling factor mess is documented for nodes/entities |
| 18:08 |
|
SFENCE joined #luanti-dev |
| 18:08 |
[MatrxMT] |
<grorp> (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 |
<luatic> 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] |
<grorp> more specifically on the author on CDB, I think CDB might overwrite the author in game.conf |
| 18:11 |
[MatrxMT] |
<grorp> 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] |
<grorp> 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:18 |
|
turtleman joined #luanti-dev |
| 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 |
<luatic> it does |
| 18:20 |
MTDiscord |
<luatic> 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 |
<luatic> and gltf models which rely on transforms are now broken |
| 18:21 |
Krock |
sfan5: 5.10.0 |
| 18:21 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> to summarize there are three issues: |
| 18:25 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> the fix for (1) also affects non-gltf models, that's what i analyzed in my survey of the server list. |
| 18:29 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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] |
<Zughy> 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] |
<Zughy> 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] |
<Zughy> 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] |
<Zughy> +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 |
<greenxenith> 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 |
<greenxenith> 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 |
<greenxenith> 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] |
<Zughy> Waiting 5 means more chances to have new bugs all at once |
| 19:09 |
MTDiscord |
<greenxenith> 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:15 |
|
imi joined #luanti-dev |
| 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] |
<y5nw> 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 |
| 19:27 |
|
SFENCE joined #luanti-dev |
| 19:46 |
|
SFENCE joined #luanti-dev |
| 19:52 |
|
Desour joined #luanti-dev |
| 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 |
| 21:55 |
|
YuGiOhJCJ joined #luanti-dev |
| 22:32 |
|
panwolfram joined #luanti-dev |
| 23:05 |
|
Eragon joined #luanti-dev |
| 23:25 |
|
turtleman joined #luanti-dev |
| 23:58 |
|
SFENCE joined #luanti-dev |
