Time Nick Message 10:31 sfan5 fyi I commented out the flatpak from the download page due to https://github.com/flathub/net.minetest.Minetest/issues/86 10:31 sfan5 a bit ironic that both of the "portable packaging formats" present additonal challenges so that native is still the best way to install Luanti 10:42 rubenwardy I think that bug only happens if you pass in --persist to the cli 10:42 rubenwardy It works fine with default options 10:44 sfan5 doesn't sound like the reporter did that 10:48 rubenwardy where did "Minetest" come from then 10:48 rubenwardy https://github.com/flathub/net.minetest.Minetest/issues/86#issuecomment-2574972599 10:49 rubenwardy although open data directory doesn't work 10:49 rubenwardy so changing MINETEST_USER_PATH is completely pointless 10:55 rubenwardy probably best to just remove that MINETEST_USER_PATH and hope that flatpak fix https://github.com/flatpak/xdg-desktop-portal/issues/591 in the foreseeable future 10:59 sfan5 if this f41 iso would I could test it myself 11:00 MTDiscord Have fun with https://github.com/minetest/minetest/issues/15652 :] 11:03 sfan5 oops I forgot to enable kvm in qemu 11:03 sfan5 no wonder it was so slow 11:14 sfan5 okay the fedora live isos somehow don't expose the ram as writable space so you can't install anything 11:14 sfan5 what a waste of time 11:41 sfan5 ubuntu worked after some messing around and the result is: I can't reproduce the bug 11:41 sfan5 and "open user data directory" works 12:06 sfan5 looks like i18n works in snap too 12:06 sfan5 was that the only reason we removed it from the download page? 12:06 rubenwardy Snap was outdated and unmaintained for quite a while iirc 12:07 sfan5 locale path is wrong but it still works, mysterious 12:12 sfan5 2025-01-07 12:08:07: INFO[Main]: Using static locale directory /usr/share/locale 12:12 sfan5 yet the files are clearly in /snap/minetest/1934/usr/bin/../share/locale/ 12:12 sfan5 maybe snap added a /usr/share/locale -> $snap/usr/share/locale symlink inside the namespace 12:36 sfan5 does anyone have access to https://github.com/snapcrafters/minetest? 12:43 sfan5 they didn't apply the rename yet so that's a good reason not to link it on the downloads page 14:01 sfan5 the scancode PR sure is big 15:59 [MatrxMT] in case sfence doesn't come back before 5.11, is there anyone willing to adopt the entities GUID PR? That'd be absolutely great for modders 15:59 [MatrxMT] Asking since they seem off the radar 16:40 MTDiscord From the PR comments, it's unclear to me whether UUIDv4 was agreed upon as the implementation. 16:46 MTDiscord Ah, looks like it was informally agreed upon in the review comments. 16:48 MTDiscord The PR looks reasonable, but Desour lost interest first, and then sfence's PR has been in the works for over a year. Why should I dedicate my time to working on this for you? 16:50 [MatrxMT] It's not just for me, it's for all those modders that have been requesting a GUID for years 16:50 [MatrxMT] it's frankly ridiculous how we still don't have a way to uniquely identify entities 16:51 MTDiscord If you find someone willing to mentor me through making the contribution, I am willing to learn. 16:51 MTDiscord It has to be a core dev of course. 16:52 [MatrxMT] [@appguru:matrix.org](https://matrix.to/#/@appguru:matrix.org) was reviewing the PR earlier 👀 16:53 MTDiscord And he had good feedback, too. I think I will learn more from someone who doesn't already agree with me on most things, though. 16:54 MTDiscord He's also a very new core dev. Still green behind the ears. 16:54 MTDiscord that comes with being a kakapo 17:01 MTDiscord sfan and luatic had some implementation comments, and TBF that's my biggest worry because that's what people tend to bikeshed about which could result in this fairly trivial piece of code taking 2 years to implement. But the most interesting problem here looks to me like set_guid thing. I would need to talk to luatic about that, because there's not enough context in the comments to fully understand what's going on with that, and 17:01 MTDiscord figuring out how to persist the GUIDs is essentially the hard part of the work, if I understand that right? 17:05 MTDiscord It looks like the world format was updated so that static objects persist their GUID. Why then was set_guid added? Is the PR not already sufficient to load the GUIDs from the world format? There is also the question of what to do if it's loading an old version of the world format and there is no GUID: it looks to me like the current implementation sets a GUID on any object without one when it gets added to the scripting environment. 17:13 MTDiscord one sec, let me write it up on github 17:14 MTDiscord Fwiw, we have a sort of UUID implementation in VL done in Lua 17:15 MTDiscord I'm pretty sure we decided that the implementation in that PR is lacking in some manner and it's not worth waiting for it 17:15 MTDiscord Lemme find the reasons 17:16 sfan5 persisting is not the hard part 17:16 sfan5 generating them requires some careful attention but other than that this is indeed a simple feature 17:21 MTDiscord sfan, you pointed out that there are standards for UUIDs and we ought to keep the implementation standard. It doesn't look like the implementation in the PR is RFC-compliant: it doesn't set the variant and version fields of the UUID. Were you concerned mostly about just the visual format of the bytes? 17:23 MTDiscord https://github.com/minetest/minetest/pull/14135#pullrequestreview-2534982543 17:25 sfan5 i have not reviewed the PR since, but there's no reason to not be standards compliant 17:26 MTDiscord Thanks for the answers. I'll put it on my TODO. 17:26 MTDiscord So apparently our issue was that if we are to have UUIDs, we should be able to access all entities, regardless of their active/processed/loaded/whatever status 17:27 MTDiscord Oh, I figured if unloaded, the entity returned by get entity by UUID would say as such... 17:27 MTDiscord Essentially, modify their state, process them ourselves, etc., accessing by UUID 17:28 MTDiscord That supposedly just doesn't work 17:28 MTDiscord You get a nil or such 17:28 MTDiscord I don't know, because it wasn't me who worked on that 17:28 MTDiscord You can always pair UUIDs with mod storage to get that 17:28 MTDiscord And we still have some (rare) bugs in our implementation (entity duplication, somehow) 17:29 MTDiscord That's what we are doing 17:41 [MatrxMT] I am the developer who worked on the minecart update. 17:41 [MatrxMT] For VoxeLibre. 17:43 [MatrxMT] The main two reasons I went with a mod storage version is this PR wasn't ready (I started the PR development about 10 months ago) and I needed/wanted to be able to have minecarts continue moving thru unloaded blocks and reappear when the re-enter tlloaded blocks. 17:45 [MatrxMT] I haven't been able to find a way to update an entity that is in an unloaded block, change its position to an active block and force it to be loaded. 17:45 [MatrxMT] Though now that I worded it that way, perhaps forceloading the block would have worked. 17:46 [MatrxMT] I think I need to read thru the current status of the UUID PR to see what has changed since the last time I looked at it. 17:46 [MatrxMT] I would prefer to not have our own, incompatible, version if at all possible. 17:47 [MatrxMT] And there is still an entity duplication bug that I am looking into. 17:48 MTDiscord This PR will not solve the "work with unloaded entities" problem yet 17:49 MTDiscord btw rather than trying to forceload an entity, why not create separate entity with the same properties and staticdata, and earmark the old one for deletion instead? 17:49 [MatrxMT] That is essentially what I am already doing. 17:50 [MatrxMT] The entity static data has two fields, a _uuid reference to the cart's data in mod storage and a _seq number that allows removing older versions of the same cart. 17:51 [MatrxMT] I might have the details a bit off, I'm reciting this from memory, but that is the gist of it. 17:52 [MatrxMT] I just have a bug in the logic somewhere that (I think) is allowing cart entities that should have been removed to survive. 17:53 [MatrxMT] The result is a stack of entities all at the same location.