| Time |
Nick |
Message |
| 00:00 |
|
ireallyhateirc joined #luanti |
| 00:22 |
|
diceLibrarian joined #luanti |
| 00:30 |
|
liceDibrarian joined #luanti |
| 00:40 |
|
diceLibrarian joined #luanti |
| 00:53 |
|
CRISPR joined #luanti |
| 00:55 |
|
FileX joined #luanti |
| 01:08 |
|
liceDibrarian joined #luanti |
| 01:16 |
|
diceLibrarian joined #luanti |
| 01:22 |
|
diceLibrarian joined #luanti |
| 01:29 |
|
diceLibrarian joined #luanti |
| 01:40 |
|
liceDibrarian joined #luanti |
| 01:42 |
|
frostsnow joined #luanti |
| 01:49 |
|
diceLibrarian joined #luanti |
| 02:01 |
|
diceLibrarian joined #luanti |
| 02:32 |
|
fling joined #luanti |
| 02:41 |
|
diceLibrarian joined #luanti |
| 03:01 |
|
Baytuch joined #luanti |
| 03:04 |
|
sys4 joined #luanti |
| 03:19 |
|
Baytuch joined #luanti |
| 03:42 |
cheapie |
Someone wanted me to make a Roomba... this is kind of the same thing, right? https://cheapiesystems.com/media/2025-04-25%2022-39-09.webm |
| 03:44 |
|
Verticen joined #luanti |
| 04:00 |
|
MTDiscord joined #luanti |
| 05:28 |
|
shinbet joined #luanti |
| 06:31 |
|
FileX joined #luanti |
| 07:04 |
|
FileX joined #luanti |
| 07:09 |
|
dabbill joined #luanti |
| 07:09 |
|
Meli joined #luanti |
| 07:44 |
|
jaca122 joined #luanti |
| 08:20 |
|
Baytuch_2 joined #luanti |
| 08:21 |
|
sys4_ joined #luanti |
| 08:49 |
|
cheek_pain joined #luanti |
| 08:50 |
|
liceDibrarian joined #luanti |
| 09:11 |
|
mrkubax10 joined #luanti |
| 09:11 |
|
sinvet joined #luanti |
| 09:20 |
|
shinbet joined #luanti |
| 09:33 |
|
diceLibrarian joined #luanti |
| 09:48 |
|
diceLibrarian joined #luanti |
| 11:18 |
|
Talkless joined #luanti |
| 11:38 |
|
silverwolf73828 joined #luanti |
| 12:22 |
|
sparky4 joined #luanti |
| 12:56 |
|
ireallyhateirc joined #luanti |
| 13:10 |
|
sparky4 joined #luanti |
| 13:37 |
|
diceLibrarian joined #luanti |
| 13:41 |
ireallyhateirc |
Using sfence's experimental block callback PR I found out that there could be a bug in the way (map)block position is hashed on the C++ side and could differ from the Lua side. Here's my reasoning: https://github.com/luanti-org/luanti/pull/15999#issuecomment-2831734490 |
| 13:42 |
ireallyhateirc |
I'd be glad if someone could verify this and/or tell me why that code doesn't work if the bug is on my side and not in the engine |
| 14:16 |
MinetestBot |
[git] appgurueu -> luanti-org/luanti: Fix glTF reader not ignoring parent transforms for skinned meshes 5113fca https://github.com/luanti-org/luanti/commit/5113fcaeddc73ad50be48d2291dbfcb399e6dae6 (2025-04-26T14:15:05Z) |
| 14:16 |
MinetestBot |
[git] appgurueu -> luanti-org/luanti: glTF: Clean up rigid animation 01e4395 https://github.com/luanti-org/luanti/commit/01e439597730371f0ff2f9d89141c05c74f81597 (2025-04-26T14:15:05Z) |
| 14:28 |
|
TheCoffeMaker_ joined #luanti |
| 14:35 |
|
wew left #luanti |
| 14:37 |
sfan5 |
ireallyhateirc: I don't understand what exactly you are comparing in your comment |
| 14:39 |
ireallyhateirc |
Okay so the code I provided in that comment generates a blockpos hash from absolute node position |
| 14:39 |
ireallyhateirc |
so position -> block coordinates -> hash |
| 14:40 |
ireallyhateirc |
the function from the PR: 'core.blocks_callback' passes blockpos hash to the callback function as an argument |
| 14:40 |
[MatrxMT] |
<Blockhead256> if they differ, create a series of tests to compare them side by side, and find a counterexample |
| 14:42 |
ireallyhateirc |
and the problem is: blockpos hash generated by my code (attached in that commit) for given coordinates does not correspond to block coordinates obtained from the hash from the callback |
| 14:42 |
ireallyhateirc |
I could write a full example, yes |
| 14:46 |
|
oneeyedalien joined #luanti |
| 14:50 |
ireallyhateirc |
This implies that either blockpos decoding or encoding (or both?) on the C++ side works differently than the Lua side |
| 15:05 |
[MatrxMT] |
<lemon> I did a complete walk through the networking code and wrote an issue about it. My ultimate goal is implementing network encryption. Happy to chat about it and need some direction so I work on something that can actually be accepted. |
| 15:06 |
|
Pokey joined #luanti |
| 15:23 |
|
mrkubax10 joined #luanti |
| 16:04 |
ireallyhateirc |
Further testing this bug, I wrote a minimal reproducer and it appears to be working correctly now. In the most complex case where the bug is present I use mapblock hash as key for mod storage and assign labels to each mapblock. So another hypothesis is that mod storage somehow messes up the hash (key) |
| 16:15 |
|
ireallyhateirc joined #luanti |
| 16:20 |
|
jaca122 joined #luanti |
| 16:37 |
ireallyhateirc |
sfan5, I found the cause of the bug - I assigned "labels" to a mapblock in mod storage by using mapblock hash as the key |
| 16:38 |
ireallyhateirc |
for some reason this confuses mod storage |
| 16:38 |
ireallyhateirc |
I did my own hashing mechanism: coords.x.."_"..coords.y.."_"..coords.z |
| 16:38 |
ireallyhateirc |
And unhashing: local a = hash:split("_") |
| 16:38 |
ireallyhateirc |
return vector.new(a[1], a[2], a[3]) |
| 16:39 |
ireallyhateirc |
And when I use this hash in mod storage as the key then mapblock coords match |
| 16:39 |
ireallyhateirc |
Should I report this as a bug or is it to be expected because there are some good reasons behind this? |
| 16:39 |
ireallyhateirc |
I tried to do tostring(hash) for the key but that also did not work correctly |
| 16:43 |
ireallyhateirc |
is perhaps the key too long? |
| 16:44 |
|
Oblomov joined #luanti |
| 16:47 |
ireallyhateirc |
so TL;DR mod storage somehow cuts/alters the key if the key is a node hash returned by core.hash_node_position |
| 16:47 |
|
Talkless joined #luanti |
| 16:49 |
|
Oblomov joined #luanti |
| 16:55 |
[MatrxMT] |
<y5nw> I wonder whether it's a JSON-related limitation with floating-point keys |
| 16:59 |
SwissalpS |
core.hash_node_position returns a number, right? So your table becomes a list with new indexes. |
| 16:59 |
ireallyhateirc |
yes |
| 17:00 |
ireallyhateirc |
from a quick search it turns out that JSON shouldn't have any limit for key length so the issue could be with the implicit tostring() |
| 17:01 |
MTDiscord |
<luatic> tostring loses precision |
| 17:01 |
MTDiscord |
<luatic> NEVER use tostring for serialization |
| 17:01 |
ireallyhateirc |
luatic, but there seems to be implicit tostring when I pass the hash to mod storage |
| 17:01 |
ireallyhateirc |
so I was losing precision without knowing it |
| 17:01 |
pgimeno |
during concatenation, I presume |
| 17:01 |
MTDiscord |
<luatic> beware |
| 17:02 |
MTDiscord |
<luatic> the engine often uses 32-bit floats |
| 17:02 |
MTDiscord |
<luatic> i recommend you do the stringification and destringification yourself |
| 17:03 |
ireallyhateirc |
is there any advantage of encoding block hash as a number vs a string in the engine? |
| 17:06 |
ireallyhateirc |
I learned the hard way about the FP precision issue because I've been chasing elusive bugs in my mod for a year |
| 17:11 |
MTDiscord |
<luatic> numbers are more lightweight than strings |
| 17:12 |
MTDiscord |
<luatic> how much that matters in which scenario would remain to be seen |
| 17:14 |
ireallyhateirc |
I'll probably add a warning for this to mod storage documentation because it sounds like a "common knowledge" for software engineers |
| 17:32 |
|
sparky4 joined #luanti |
| 18:16 |
|
Fleckenstein joined #luanti |
| 18:18 |
|
Fleckenstein joined #luanti |
| 18:31 |
|
jaca122 joined #luanti |
| 18:46 |
|
liceDibrarian joined #luanti |
| 19:45 |
cheapie |
lawnmowercycle https://cheapiesystems.com/media/2025-04-26%2014-44-16.webm |
| 20:03 |
|
diceLibrarian joined #luanti |
| 20:07 |
|
sparky4 joined #luanti |
| 20:08 |
|
LizzyFleck joined #luanti |
| 20:10 |
|
diceLibrarian joined #luanti |
| 20:15 |
|
Fleckenstein joined #luanti |
| 20:41 |
|
luk3yx joined #luanti |
| 20:44 |
|
CRISPR joined #luanti |
| 20:53 |
sfan5 |
ireallyhateirc: do you have an example number that doesn't come out of mod storage unharmed? |
| 20:54 |
ireallyhateirc |
sfan5, I could deliver that but I'm busy debugging another thing right now. Can this wait or do you want me to do that now? |
| 20:54 |
sfan5 |
no hurry |
| 20:55 |
|
liceDibrarian joined #luanti |
| 20:57 |
ireallyhateirc |
it appears that it's always the x coordinate affected and the order is ZYX so I assume it just cuts out the last part |
| 21:00 |
MTDiscord |
<luatic> ireallyhateirc: well, the docs for set_float already say: "The range for the value is system-dependent (usually 32 bits)." |
| 21:00 |
MTDiscord |
<luatic> we should probably have a set_number that uses 64-bit floats. |
| 21:11 |
MTDiscord |
<luatic> wait actually this seems to be false, turkeymcmac fixed that, and set_float / get_float uses lua to do the conversion. but lua's tostring may actually round too... |
| 21:20 |
|
Verticen joined #luanti |
| 21:28 |
ireallyhateirc |
https://www.lua.org/manual/5.3/manual.html#pdf-tostring |
| 21:28 |
ireallyhateirc |
"Receives a value of any type and converts it to a string in a human-readable format. (For complete control of how numbers are converted, use string.format.)" |
| 21:29 |
ireallyhateirc |
you may want to use these control options in whatever pieces of code cause this |
| 21:29 |
sfan5 |
well first we need to confirm and figure out what is happening |
| 21:31 |
ireallyhateirc |
will deliver data later |
| 21:32 |
ireallyhateirc |
it is 100% reproducible |
| 21:36 |
|
sinvet joined #luanti |
| 21:38 |
ireallyhateirc |
finding bizarre Luanti bugs is my passion |
| 21:40 |
MTDiscord |
<luatic> sfan5: i'll submit a fix (including unit tests) shortly. |
| 22:03 |
|
Kimapr_ joined #luanti |
| 22:10 |
|
diceLibrarian2 joined #luanti |
| 22:11 |
MTDiscord |
<luatic> ireallyhateirc: #16090 |
| 22:11 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16090 -- MetaDataRef: `set_float` exactness electric boogaloo by appgurueu |
| 22:12 |
ireallyhateirc |
@luatic, do you want me to try this? |
| 22:12 |
ireallyhateirc |
lmao this line: |
| 22:12 |
ireallyhateirc |
["0.3"] = "0.29999999999999999", |
| 22:12 |
ireallyhateirc |
["0.1+0.2"] = "0.30000000000000004", |
| 22:13 |
ireallyhateirc |
looks cursed |
| 22:16 |
MTDiscord |
<luatic> this line is an important lesson for everyone who works with floats 😁 |
| 22:16 |
ireallyhateirc |
I was schooled by floats back when I worked on my road generator |
| 22:16 |
MTDiscord |
<luatic> ireallyhateirc: you can try it, i'd expect this to fix your issue. |
| 22:17 |
ireallyhateirc |
dump() conveniently displayed "0.30000000000000004", etc. as 0.3 |
| 22:17 |
MTDiscord |
<luatic> ireallyhateirc: as it so happens, i got a fix for that too! |
| 22:18 |
ireallyhateirc |
but vector.equals(a, b) told me the vectors are not equal and I wasted hours debugging that |
| 22:18 |
ireallyhateirc |
great |
| 22:18 |
MTDiscord |
<luatic> #16083 |
| 22:18 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16083 -- Revamp `dump` by appgurueu |
| 22:19 |
ireallyhateirc |
I wrote a shallow dump that prints recursively linked objects without freezing the game |
| 22:19 |
ireallyhateirc |
dump() frose the game if I tried to dump an object which contained a linked list |
| 22:19 |
ireallyhateirc |
froze* |
| 22:20 |
ireallyhateirc |
it detects simple cyclical objects but it fails to do so for more tangled ones |
| 22:20 |
|
diceLibrarian2 joined #luanti |
| 22:20 |
MTDiscord |
<luatic> my PR fixes that too |
| 22:22 |
ireallyhateirc |
amazing, it'd save me hours of smashing my head against a wall 2 years ago. Nice to see it fixed. |
| 22:27 |
ireallyhateirc |
to test that PR I'd need to merge your PR into sfence's block callbacks one |
| 22:31 |
|
diceLibrarian2 joined #luanti |
| 22:32 |
|
panwolfram joined #luanti |
| 23:02 |
|
Baytuch joined #luanti |
| 23:04 |
|
sparky4 joined #luanti |
| 23:05 |
|
Eragon joined #luanti |
| 23:08 |
|
Eragon_ joined #luanti |
