Time |
Nick |
Message |
00:05 |
|
Eragon joined #minetest-dev |
00:43 |
|
Marquez43 joined #minetest-dev |
04:01 |
MTDiscord |
<exe_virus> 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 |
05:00 |
|
MTDiscord joined #minetest-dev |
08:47 |
|
Noisytoot joined #minetest-dev |
09:46 |
|
Warr1024 joined #minetest-dev |
09:54 |
[MatrxMT] |
<Zughy> 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 joined #minetest-dev |
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 |
<herowl> 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 |
<luatic> 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 |
<luatic> Herowl: initial_properties is just for engine properties |
15:31 |
MTDiscord |
<luatic> and engine properties should go there and not directly in the entity definition |
15:32 |
MTDiscord |
<herowl> And engine properties are what is in the Object definition table in the docs, right? |
15:32 |
MTDiscord |
<luatic> it's what's under the "object properties" section |
15:33 |
MTDiscord |
<luatic> 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 |
15:40 |
|
hwpplayer1 joined #minetest-dev |
15:48 |
|
wrrrzr left #minetest-dev |
16:04 |
|
Desour joined #minetest-dev |
16:17 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
19:59 |
|
SFENCE joined #minetest-dev |
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 |
<luatic> side note, rewriting problematic code is something that should be possible automatically here given a decent lua parser |
21:02 |
|
SFENCE joined #minetest-dev |
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 |
<luatic> 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<T>::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 |
23:33 |
|
panwolfram joined #minetest-dev |
23:41 |
|
Noisytoot joined #minetest-dev |