Time Nick Message 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 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 02[git] 04appgurueu -> 03luanti-org/luanti: Fix glTF reader not ignoring parent transforms for skinned meshes 135113fca https://github.com/luanti-org/luanti/commit/5113fcaeddc73ad50be48d2291dbfcb399e6dae6 (152025-04-26T14:15:05Z) 14:16 MinetestBot 02[git] 04appgurueu -> 03luanti-org/luanti: glTF: Clean up rigid animation 1301e4395 https://github.com/luanti-org/luanti/commit/01e439597730371f0ff2f9d89141c05c74f81597 (152025-04-26T14:15:05Z) 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] 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: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] 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. 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: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: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:55 [MatrxMT] 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 tostring loses precision 17:01 MTDiscord 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 beware 17:02 MTDiscord the engine often uses 32-bit floats 17:02 MTDiscord 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 numbers are more lightweight than strings 17:12 MTDiscord 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 19:45 cheapie lawnmowercycle https://cheapiesystems.com/media/2025-04-26%2014-44-16.webm 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: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 ireallyhateirc: well, the docs for set_float already say: "The range for the value is system-dependent (usually 32 bits)." 21:00 MTDiscord we should probably have a set_number that uses 64-bit floats. 21:11 MTDiscord 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: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:38 ireallyhateirc finding bizarre Luanti bugs is my passion 21:40 MTDiscord sfan5: i'll submit a fix (including unit tests) shortly. 22:11 MTDiscord 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 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 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 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 #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 MTDiscord 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