Time Nick Message 04:01 MTDiscord Shout-out to Luanti: Setup a new Ubuntu mini server today. First time compiling Luanti on Linux, and took exactly 3 copy pastas from our instructions, worked first try each time. So: thank you. That was a wonderful setup experience 09:54 [MatrxMT] The first one was "I'd just like to interject for a moment" 14:46 sfan5 the fact that we still have fallback code for initial_properties is turning out very troublesome 14:48 sfan5 because I just added a new property that happens to collide with a name a mod is using in its bare entity definition 15:19 wrrrzr Can i send PR with replace std string to std string view? 15:23 sfan5 depends 15:23 sfan5 generally yes 15:26 wrrrzr Thanks for answer 15:30 MTDiscord sfan5: could you give me a rundown on what should go in initial_properties and what in the entity def itself? Is initial_properties just for the engine properties or custom ones too? 15:31 MTDiscord sfan5: make an exception? the new property does not need to support the fallback since it's just for older mods anyways. 15:31 MTDiscord Herowl: initial_properties is just for engine properties 15:31 MTDiscord and engine properties should go there and not directly in the entity definition 15:32 MTDiscord And engine properties are what is in the Object definition table in the docs, right? 15:32 MTDiscord it's what's under the "object properties" section 15:33 MTDiscord hold on we got this on dev.luanti.org even, though probably slightly outdated by now: https://dev.luanti.org/docs/object-properties/ 15:34 sfan5 "on what should go in initial_properties" everything you'd give to set_properties 15:34 sfan5 "what in the entity def itself" variables you want to use for yourself 15:35 sfan5 @luatic sure that's what I did and now there's some stupid inconsistency 15:35 sfan5 not that it matters, but it's messy 15:36 sfan5 anyway #15683 is ready for review 15:36 ShadowBot https://github.com/minetest/minetest/issues/15683 -- [manual merge] CAO 'node' visual by sfan5 16:17 MTDiscord currently we log stack traces at a lower log level (info) than warnings. this leads to people with a warning log level not seeing them at all. 16:17 MTDiscord should we log stack traces at warning level too? should we document this better? 16:17 sfan5 i think the intent is to not spam the log with stack traces but make sure the warning is visible 16:18 sfan5 if the log msg said "Stacktrace printed at INFO level." that'd be enough 19:21 sfan5 does anyone want to review #15567? 19:21 ShadowBot https://github.com/minetest/minetest/issues/15567 -- Implement player:get_point_dir() and player:get_point_screen_pos() by grorp 20:05 rubenwardy sfan5: how about not reading new object properties from the base def? could pass a boolean into the parse_object_properties function or w/e 20:05 rubenwardy ahh you did that 20:10 MTDiscord side note, rewriting problematic code is something that should be possible automatically here given a decent lua parser 21:34 sfan5 rubenwardy: sort of, yea 21:35 sfan5 but I think we should change the logic to to "if ent.initial_properties ~= nil then read(ent.initial_properties) else read(ent) end" 21:53 MTDiscord yeah that'd make sense 22:23 pgimeno about #15567, comparing with 0.5 is perfectly fine, just like in Lua comparing with integers is perfectly fine; apart from that, I guess the compiler can optimize out common subexpressions? in this case cos(pitch) is used twice in PlayerSAO::getLookDir() 22:23 ShadowBot https://github.com/minetest/minetest/issues/15567 -- Implement player:get_point_dir() and player:get_point_screen_pos() by grorp 22:26 pgimeno but don't consider that a full review, just a cursory look 23:24 sfan5 merging #15687 #15686 soon 23:24 ShadowBot https://github.com/minetest/minetest/issues/15687 -- Fix CMatrix::getScale returning negative scale by appgurueu 23:24 ShadowBot https://github.com/minetest/minetest/issues/15686 -- Remove built-in knockback from `punch()` in next major release by Zughy