| Time |
Nick |
Message |
| 01:03 |
|
ShadowBot joined #minetest-dev |
| 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 |
| 02:12 |
|
v-rob joined #minetest-dev |
| 03:31 |
|
v-rob joined #minetest-dev |
| 03:41 |
Wuzzy |
will there be a string freeze? |
| 03:41 |
Wuzzy |
or does it go straight to release? |
| 04:04 |
MTDiscord |
<josiah_wi> My primary Minetest development environment is Debian, and it worked fine a few weeks ago. |
| 04:09 |
MTDiscord |
<jordan4ibanez> When the weather gets too cold, the strings tend to freeze up |
| 04:10 |
MTDiscord |
<jordan4ibanez> Yes, sfan5 confirmed string winter |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:49 |
|
Warr1024 joined #minetest-dev |
| 07:01 |
|
calcul0n joined #minetest-dev |
| 09:07 |
|
Evergreen joined #minetest-dev |
| 10:12 |
|
appguru joined #minetest-dev |
| 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] |
<giov4> 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:26 |
|
calcul0n joined #minetest-dev |
| 13:45 |
|
appguru joined #minetest-dev |
| 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
|
Wuzzy joined #minetest-dev |
| 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:32 |
|
calcul0n joined #minetest-dev |
| 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 |
<andrey2470t> Rebased #13020 |
| 16:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/13020 -- 3d line rendering. by Andrey2470T |
| 17:03 |
|
Fleckenstein joined #minetest-dev |
| 18:36 |
|
Krock joined #minetest-dev |
| 18:36 |
|
Desour joined #minetest-dev |
| 18:52 |
|
vampirefrog joined #minetest-dev |
| 19:07 |
|
sofar joined #minetest-dev |
| 19:31 |
|
fluxionary joined #minetest-dev |
| 19:44 |
|
v-rob joined #minetest-dev |
| 20:02 |
|
v-rob joined #minetest-dev |
| 20:33 |
|
imi joined #minetest-dev |
| 21:34 |
|
v-rob joined #minetest-dev |
| 22:18 |
|
calcul0n joined #minetest-dev |
| 22:56 |
|
YuGiOhJCJ joined #minetest-dev |
| 23:32 |
|
panwolfram joined #minetest-dev |
