| Time |
Nick |
Message |
| 00:05 |
|
Eragon joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:22 |
|
hwpplayer1 joined #minetest-dev |
| 06:59 |
|
hwpplayer1 joined #minetest-dev |
| 08:55 |
|
Eragon joined #minetest-dev |
| 09:05 |
|
hwpplayer1 joined #minetest-dev |
| 10:23 |
|
hwpplayer1 joined #minetest-dev |
| 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:32 |
|
hwpplayer1 joined #minetest-dev |
| 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 |
<greenxenith> 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:35 |
|
TheCoffeMaker joined #minetest-dev |
| 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:10 |
|
hwpplayer1 joined #minetest-dev |
| 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 |
| 14:49 |
|
hwpplayer1 joined #minetest-dev |
| 15:59 |
[MatrxMT] |
<Zughy> 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] |
<Zughy> Asking since they seem off the radar |
| 16:40 |
MTDiscord |
<josiah_wi> From the PR comments, it's unclear to me whether UUIDv4 was agreed upon as the implementation. |
| 16:46 |
MTDiscord |
<josiah_wi> Ah, looks like it was informally agreed upon in the review comments. |
| 16:48 |
MTDiscord |
<josiah_wi> 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] |
<Zughy> It's not just for me, it's for all those modders that have been requesting a GUID for years |
| 16:50 |
[MatrxMT] |
<Zughy> it's frankly ridiculous how we still don't have a way to uniquely identify entities |
| 16:51 |
MTDiscord |
<josiah_wi> If you find someone willing to mentor me through making the contribution, I am willing to learn. |
| 16:51 |
MTDiscord |
<josiah_wi> It has to be a core dev of course. |
| 16:52 |
[MatrxMT] |
<Zughy> [@appguru:matrix.org](https://matrix.to/#/@appguru:matrix.org) was reviewing the PR earlier 👀 |
| 16:53 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> He's also a very new core dev. Still green behind the ears. |
| 16:54 |
MTDiscord |
<luatic> that comes with being a kakapo |
| 17:01 |
MTDiscord |
<josiah_wi> 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:03 |
|
hwpplayer1 joined #minetest-dev |
| 17:05 |
MTDiscord |
<josiah_wi> 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 |
<luatic> one sec, let me write it up on github |
| 17:14 |
MTDiscord |
<herowl> Fwiw, we have a sort of UUID implementation in VL done in Lua |
| 17:15 |
MTDiscord |
<herowl> 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 |
<herowl> 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 |
<josiah_wi> 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 |
<luatic> 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 |
<josiah_wi> Thanks for the answers. I'll put it on my TODO. |
| 17:26 |
MTDiscord |
<herowl> 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 |
<exe_virus> Oh, I figured if unloaded, the entity returned by get entity by UUID would say as such... |
| 17:27 |
MTDiscord |
<herowl> Essentially, modify their state, process them ourselves, etc., accessing by UUID |
| 17:28 |
MTDiscord |
<herowl> That supposedly just doesn't work |
| 17:28 |
MTDiscord |
<herowl> You get a nil or such |
| 17:28 |
MTDiscord |
<herowl> I don't know, because it wasn't me who worked on that |
| 17:28 |
MTDiscord |
<luatic> You can always pair UUIDs with mod storage to get that |
| 17:28 |
MTDiscord |
<herowl> And we still have some (rare) bugs in our implementation (entity duplication, somehow) |
| 17:29 |
MTDiscord |
<herowl> That's what we are doing |
| 17:41 |
[MatrxMT] |
<teknomunk> I am the developer who worked on the minecart update. |
| 17:41 |
[MatrxMT] |
<teknomunk> For VoxeLibre. |
| 17:43 |
[MatrxMT] |
<teknomunk> 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] |
<teknomunk> 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] |
<teknomunk> Though now that I worded it that way, perhaps forceloading the block would have worked. |
| 17:46 |
[MatrxMT] |
<teknomunk> 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] |
<teknomunk> I would prefer to not have our own, incompatible, version if at all possible. |
| 17:47 |
[MatrxMT] |
<teknomunk> And there is still an entity duplication bug that I am looking into. |
| 17:48 |
MTDiscord |
<luatic> This PR will not solve the "work with unloaded entities" problem yet |
| 17:49 |
MTDiscord |
<luatic> 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] |
<teknomunk> That is essentially what I am already doing. |
| 17:50 |
[MatrxMT] |
<teknomunk> 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] |
<teknomunk> I might have the details a bit off, I'm reciting this from memory, but that is the gist of it. |
| 17:52 |
[MatrxMT] |
<teknomunk> 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] |
<teknomunk> The result is a stack of entities all at the same location. |
| 19:12 |
|
hwpplayer1 joined #minetest-dev |
| 21:02 |
|
hwpplayer1 joined #minetest-dev |
| 21:54 |
|
YuGiOhJCJ joined #minetest-dev |
| 22:27 |
|
Sharpman joined #minetest-dev |
| 23:33 |
|
panwolfram joined #minetest-dev |
