Time Nick Message 01:06 erle https://tracker.debian.org/pkg/minetest seems minetest fails to build from source in debian 01:07 erle https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052671 01:07 erle dh_install: warning: minetest-data missing files: src/unittest/test_world/world.mt 01:14 rubenwardy looks like a debian problem 01:15 rubenwardy "nocheck" isn't a Minetest thing at all 01:19 rubenwardy there's no need to report distro problems to us unless it's confirmed to be an actual MT problem 01:20 rubenwardy in the latest MT version as well 01:38 erle okie dokie 03:41 Wuzzy will there be a string freeze? 03:41 Wuzzy or does it go straight to release? 04:04 MTDiscord My primary Minetest development environment is Debian, and it worked fine a few weeks ago. 04:09 MTDiscord When the weather gets too cold, the strings tend to freeze up 04:10 MTDiscord Yes, sfan5 confirmed string winter 10:34 sfan5 I will merge #13984 and do string updates shortly 10:34 ShadowBot https://github.com/minetest/minetest/issues/13984 -- Get rid of hidden settings in settings_translation_file.cpp by grorp 11:10 sfan5 btw has anyone updated the builtin translation files? were there any changes? 11:10 sfan5 maybe Wuzzy? 11:15 sfan5 commits here https://github.com/minetest/minetest/commits/ci 11:23 sfan5 pushing once ci finishes 11:43 sfan5 all done 12:23 [MTMatrix] hi hi everyone, I have a doubt: how does the schematic placement rotation work? I mean, I'd like to save an area of the map as a schematic, to then restore it later, but I noticed that it is placed in a different rotation. Is there a way of reobtaining/saving the original rotation? 13:53 appguru does anyone have any architectural insights into how our AO / SAO / UnitSAO / PlayerSAO class hierarchy came to be? 13:53 appguru I have something which I think belongs in SAO (since it would apply to players and entities alike), but SAO is remarkably empty 13:53 appguru UnitSAO and PlayerSAO also seem to duplicate some code 13:54 erle what's it 13:54 erle in before invisible players 13:58 appguru erle: that is kinda what i'm planning to work on, yes 13:59 appguru (a feature to control to which clients entities get sent) 13:59 erle this is going to be hairy lol 13:59 appguru some aspects are hairy, yes, but the overall plan is pretty simple 14:00 appguru I wonder how I should deal with static save. I could save a set of names of players the object should get sent to. 14:00 erle LOL 14:00 erle this will be funny 14:00 appguru if it wouldn't be funny, i wouldn't be discussing it here beforehand 14:00 appguru i'm trying to get rid of the funnies before they happen 14:02 erle okay but what exactly is the feature here 14:02 erle like invisible players you can already do by custom textures right? 14:02 erle i mean the use case 14:02 MTDiscord Rather than dealing with static save yourself, you could just leave that the responsibility of the entity and ensure it doesn't get sent to anyone before it activates and has a chance to reconfigure itself. 14:02 erle i have to go to bed 14:03 appguru am I right in deducing from GCC 7.5+ that I can use C++17 features? 14:03 appguru good night 14:03 erle let me guess: an entity has a property ”not being sent to everyone” and if that is true, a list attached to it with player names is evaluated 14:03 erle right? 14:04 appguru something like that, yes 14:04 erle that's the model? 14:04 erle what else? 14:04 erle you wrote ”something like” 14:04 erle like how not exactly that 14:04 erle what is different in your approach 14:04 appguru well, i'll probably do the details differently 14:04 erle in what way? 14:04 appguru i'd use a set, not a list, to begin with 14:04 erle right 14:05 appguru this is what I'm planning to implement: #8045 14:05 ShadowBot https://github.com/minetest/minetest/issues/8045 -- Allow Changing Entity Visibility On A Per-Player Basis 14:05 appguru (but not limited to visibility, and not limited to entities) 14:06 appguru this could also be leveraged to cut down on network traffic for purely visual entities that only some players should see 14:06 erle if you want to cut down on network traffic i think there is some lower-hanging fruit to pick, but i guess that's less interesting for you 14:06 appguru but really there's no need to repeat all the opportunities this opens up, that has already been done in the issue 14:06 erle okie dokie 14:07 erle so question 14:07 erle if i attach a to b and make b visible to warr1024 only, is a then hanging in thin air? 14:07 erle or also only visible to warr1024 14:07 appguru erle: I already considered attachments. 14:08 appguru I will require that parents have a superset of observers of their children. 14:08 erle require or ensure? 14:08 appguru ensure, as in assertions and throwing lua errors 14:08 erle the first seems the easier to implement the latter the easier to use api 14:08 erle why not propagate it 14:08 erle oh i see 14:08 erle forget about it :D 14:10 appguru As for the API, I'm considering 4 methods: obj:set_observers{[name] = true}, obj:get_observers(), obj:add_observer(name), obj:remove_observer(name) 14:10 appguru technically only get/set are necessary, but i think removing/adding observers to entities will be quite useful 14:10 erle how do you atomically add a group of people 14:11 erle or remove them then 14:11 appguru you could use set_observers for that 14:11 appguru but you're right, the add and remove methods should probably take multiple names 14:11 appguru i'm also wondering whether using varargs here would be appropriate? 14:11 erle uh no 14:11 appguru obj:set_observers("foo", "bar") doesn't seem particularly dirty to me 14:11 erle NO 14:12 MTDiscord Atomicity doesn't seem like it should make much difference anyway, since changes should take effect only at the end of the current server step. 14:12 appguru it makes it harder / impossible to add extra parameters later on 14:12 appguru but you could just deprecate the old methods and add new ones 14:12 MTDiscord Adding extra parameters is pretty evil 😂 14:12 erle look 14:12 erle do you want a usable API? 14:12 appguru yes 14:13 appguru that's why I'm asking here 14:13 erle well, i probably have a list of player names. make it possible to stuff the stuff into the stuff. 14:13 MTDiscord But I'd probably rather do something like the way privs work and just take a table keyed on name. 14:13 appguru warr1024: yeah, that was my initial suggestion 14:13 erle what's the issue with privs though? 14:13 erle table keyed on name is fine isn't it? 14:13 erle no methods necessary 14:13 appguru privs became a footgun problem in the end 14:13 erle why 14:14 appguru well for one, people assumed that set privs would be incremental like set properties, but it isn't 14:14 MTDiscord Lua would benefit from a first class set type though because the fact that setting privs to {interact=false} GRANTS it rather than revokes it is kind of cockamamie 14:14 appguru ^ and that 14:14 erle wait what 14:14 appguru (strictest has a warning for this btw ^^) 14:15 appguru erle: https://github.com/appgurueu/strictest/commit/5f0a93b9ffb7b0f42b2748b420b57195ca9b67e1 14:15 erle i don't get it 14:15 erle why would anyone set it to false or 254435 or "potato" anyway? 14:16 appguru because the docs don't make clear that it is a set 14:16 appguru the docs just say: "minetest.set_player_privs(name, {priv1=true,...}): Set privileges of player name." 14:16 erle yes 14:16 erle they say nothing about false here 14:16 appguru that is.. not very helpful, because that ... could be anything 14:16 erle so how do people think it is a valid value? 14:17 appguru because they infer the ... differently 14:17 erle yeah hmm 14:17 MTDiscord MT should at least make a special case for false as it's pretty clear what is intended in those cases, and for the "potato" case it's truthy anyway so there's no confusion. 14:17 erle uh the special case could just be a warning 14:18 erle nil is pretty useful 14:18 appguru i think i wanted to make a PR for that but got demotivated 14:18 MTDiscord That ... is ironically extra unhelpful in a lua context because somebody could take it too literal and end up trying to grant the 1, 2, etc. privs. 14:18 erle just to be clear, but minetest.set_player_privs(name, {priv1=nil}) removes it? 14:18 appguru that removes *all privs* 14:18 appguru because that's just minetest.set_player_privs(name, {}) 14:19 erle yes good 14:19 MTDiscord Yeah, set privs also lacks an incremental API 14:19 appguru yeah 14:19 appguru but usually modders want an incremental API 14:19 appguru so as it is not documented, they imagine what is more convenient.. that it is incremental like e.g. set_properties 14:19 erle i think the issue here is that sets are not first class citizens but yeah 14:19 MTDiscord Which is ironic since there are incremental events. But those are only hooked to the chat commands, not all grants and revokes. 14:20 appguru erle: yeah, first class sets would solve this 14:20 appguru as would just documenting types 14:20 erle indeed 14:21 MTDiscord Ironically set_properties looks incremental on the surface but what it actually does under the hood is way less incremental than it should be 😂 14:21 appguru i had an issue for set privs specifically on the minetest_docs issue tracker, but well.. that project died down pretty much 14:21 erle did it? 14:21 erle it documented a bunch! 14:21 appguru yeah we did, but the last real work was in may 14:22 erle i have to add some stuff i think 14:22 erle later 14:22 erle now i sleep 14:23 appguru good night 14:23 appguru hi Wuzzy 14:23 appguru thoughts on #8045? 14:23 ShadowBot https://github.com/minetest/minetest/issues/8045 -- Allow Changing Entity Visibility On A Per-Player Basis 14:26 Wuzzy hmmm 14:26 Wuzzy this approach feels fishy 14:26 Wuzzy because ALL entities of that type may need updating once a player joins or leaves 14:26 Wuzzy and even worse: what if such an entity was unloaded when a player joined? 14:27 Wuzzy i like the idea of making entities invisible on a per-player basis but I am sceptical of the suggested solution 14:30 appguru Why is the updating a concern? 14:30 appguru It's worth discussing whether the set of observers should only be allowed to contain only players, I suppose 14:31 appguru online players* 14:33 appguru I don't see the problem with the unloading. When loading entities within a range, the entity would be activated. It could then decide to set its observers to include or exclude the player and will accordingly be sent or not be sent to the player. 16:56 MTDiscord Rebased #13020 16:56 ShadowBot https://github.com/minetest/minetest/issues/13020 -- 3d line rendering. by Andrey2470T