Time |
Nick |
Message |
01:41 |
|
kilbith joined #minetest-dev |
03:51 |
|
YuGiOhJCJ joined #minetest-dev |
04:00 |
|
MTDiscord joined #minetest-dev |
05:00 |
|
nrz joined #minetest-dev |
05:01 |
|
calcul0n_ joined #minetest-dev |
06:51 |
|
lionkor joined #minetest-dev |
09:04 |
|
Warr1024 joined #minetest-dev |
09:06 |
|
appguru joined #minetest-dev |
09:14 |
|
appguru joined #minetest-dev |
09:54 |
Baytuch |
Greetings. I probobly fix my internet connection. I am sorry for re-connections recently. |
10:06 |
|
Baytuch joined #minetest-dev |
10:16 |
|
Fixer joined #minetest-dev |
10:29 |
|
HuguesRoss joined #minetest-dev |
11:32 |
Zughy[m] |
Meeting reminder, in about 7:30h |
11:45 |
|
Baytuch joined #minetest-dev |
12:14 |
|
Baytuch joined #minetest-dev |
12:28 |
MTDiscord |
<savilli> Android fixes: https://github.com/minetest/irrlicht/pull/128 https://github.com/minetest/minetest_android_deps/pull/2 https://github.com/minetest/minetest/pull/12700 |
12:31 |
|
Baytuch joined #minetest-dev |
14:56 |
|
lionkor joined #minetest-dev |
15:10 |
|
kilbith joined #minetest-dev |
15:12 |
|
vampirefrog joined #minetest-dev |
16:53 |
|
Taoki joined #minetest-dev |
17:52 |
|
lionkor joined #minetest-dev |
18:17 |
sfan5 |
merging #12692, #12641, #12417 in 5m |
18:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/12692 -- Limit force shadow update to urgent blocks by x2048 |
18:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/12641 -- Add handling of environment variables to control terminal/logging colors by lionkor |
18:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/12417 -- Docs: add "flip moon texture" into breakage file by Zughy |
18:27 |
MTDiscord |
<savilli> How many core devs does it take to add one line to docs? :D |
18:28 |
celeron55 |
looks like github hates me. no pages will load and i can't write more hype comments to my PR |
18:29 |
celeron55 |
now it works again |
18:32 |
rubenwardy |
meeting in 30 minutes |
18:45 |
celeron55 |
i'm sleeping in 30 minutes... good timing |
18:46 |
celeron55 |
well, should be |
19:03 |
nrz |
celeron55, time to stop sleeping, you will join NATO to be with us soon ? |
19:04 |
|
YuGiOhJCJ joined #minetest-dev |
19:10 |
Zughy[m] |
?️ |
19:13 |
|
behalebabo joined #minetest-dev |
19:24 |
rubenwardy |
!dev Meetings |
19:24 |
ShadowBot |
Meetings - Minetest Developer Wiki -- http://dev.minetest.net/Meetings |
19:25 |
rubenwardy |
sfan5, Krock, @x2048, HuguesRoss, nrz, nore |
19:25 |
rubenwardy |
maybe we should move an hour earlier |
19:27 |
Krock |
oh. totally missed it. |
19:30 |
rubenwardy |
my internet connection is playing up |
19:30 |
Krock |
> https://github.com/minetest/minetest/issues?q=is%3Aopen+is%3Aissue+label%3AQuestion |
19:30 |
Krock |
I suppose this is to process? |
19:34 |
Krock |
IMO the "Question" label should be avoided. Nobody knows when to close it |
19:34 |
Krock |
they stay open forever, even if there's nothing more to discuss or answer |
19:37 |
celeron55 |
these seem like one of the least productive issues to discuss |
19:38 |
rubenwardy |
I think it's more "please look at these questions at some point" than discuss now |
19:38 |
Krock |
> #12367 |
19:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/12367 -- Add minetest.get_player_window_information() by rubenwardy |
19:38 |
Krock |
concept question? |
19:39 |
rubenwardy |
I don't think sfan5 was happy with the privacy element |
19:44 |
Krock |
I don't see much of an issue, but at the same not much of an use-case |
19:46 |
Krock |
although the maximal non-shrinking formspec size would be a helpful addition |
19:46 |
rubenwardy |
this is one of the highest requested features from modders |
19:46 |
rubenwardy |
just look at the reactions |
19:47 |
MTDiscord |
<GreenXenith> privacy is simply an irrelevant argument |
19:47 |
|
Baytuch_2 joined #minetest-dev |
19:48 |
MTDiscord |
<GreenXenith> I dont mean to say that in a provocative way, but it is simply true. As a game developer and by extension application developer, having the window size is a basic and integral need for visuals |
19:48 |
celeron55 |
i agree mods need a way to know the fullscreen formspec size |
19:48 |
rubenwardy |
yeah seems like a non issue to me. If users complain then we can add a setting later |
19:49 |
MTDiscord |
<GreenXenith> And it may feel like semantics, but its more games that need to know than mods. A game is an entire experience, where knowing the visual setup of the user can make or break the feel. |
19:50 |
Krock |
I mean there might be a more helpful was for modders. formspecs: maximal dimensions. HUD: x/y position increment per "size" unit |
19:50 |
MTDiscord |
<GreenXenith> Absolutely useful for mods, but it is integral for games |
19:50 |
Krock |
s/was /ways / |
19:51 |
MTDiscord |
<luatic> Krock: Idealized solutions would be considerably more work to implement |
19:51 |
MTDiscord |
<luatic> Consider the simple use case of drawing a circle on the screen (e.g. sniper scope) |
19:51 |
Krock |
luatic: maybe more work, but it's supposed to be usable by mods |
19:52 |
MTDiscord |
<GreenXenith> Side-note, in the future will there be a client-sent window change event? Because with this PR (which is great, mind you) we'll have to do regular polling to detect changes |
19:52 |
MTDiscord |
<luatic> Suddenly you need to introduce vh / vw units like CSS to make this possible |
19:52 |
MTDiscord |
<luatic> IMO the PR should have been designed using events |
19:52 |
MTDiscord |
<luatic> https://github.com/minetest/minetest/pull/12367#issuecomment-1140455557 |
19:52 |
MTDiscord |
<GreenXenith> Well you need a server request to request the data in the first place |
19:52 |
MTDiscord |
<luatic> but yes, ruben answered "that can come later" |
19:53 |
MTDiscord |
<GreenXenith> Ah, thank you |
19:53 |
MTDiscord |
<luatic> no, we might as well have the client push it when it changes |
19:53 |
MTDiscord |
<GreenXenith> Well no, the client can choose to never send it |
19:53 |
MTDiscord |
<luatic> the client can also choose to not respond to server requests |
19:53 |
MTDiscord |
<GreenXenith> You need both |
19:53 |
MTDiscord |
<GreenXenith> Irrelevant anyway |
19:53 |
MTDiscord |
<GreenXenith> Moot point |
19:53 |
MTDiscord |
<GreenXenith> My two cents given, moving on |
19:53 |
MTDiscord |
<luatic> the client should send at join and then at every change IMO for minimum unnecessary network traffic |
19:54 |
Krock |
I don't see much point in introducing an API now that needs additional code so that it's actually reliably usable |
19:54 |
rubenwardy |
it's already reliable, just needs polling |
19:54 |
Krock |
for example, you need to know the spacing of HUD elements, or their size respecively |
19:54 |
rubenwardy |
the client pushes the data at join and when the data changes. There's no need for the server to request |
19:54 |
Krock |
also size considerations for formspecs |
19:55 |
rubenwardy |
Krock: you can already use this for fullscreen formspec . See the devtest code |
19:55 |
MTDiscord |
<luatic> ah, so ruben implemented it properly at the network level |
19:55 |
MTDiscord |
<luatic> yay |
19:55 |
MTDiscord |
<luatic> Krock: Since when do HUD elements have spacing? |
19:55 |
MTDiscord |
<luatic> Text is hard to deal with, granted |
19:55 |
MTDiscord |
<GreenXenith> That smells like a tangent |
19:56 |
MTDiscord |
<GreenXenith> rubenwardy: So adding the event feature would be dead simple later then? Since it already sends it upon changes? |
19:56 |
celeron55 |
the lua api event could be added at any point. eg. now, in a year, or never |
19:56 |
Krock |
luatic: exactly they don't come with any. that's why mods need to make sure they're far enough apart so that large scalings do not make it look bad |
19:56 |
MTDiscord |
<luatic> I'd add the clean Lua API now and keep the polling API internal |
19:56 |
rubenwardy |
We've been arguing for better approaches for about 8 years, and yet modders have been left hanging |
19:56 |
rubenwardy |
yes, it would be nice to have proper containers or sizing or whatever, but this is useful now |
19:57 |
MTDiscord |
<luatic> ^ |
19:57 |
MTDiscord |
<MisterE> I have used screen information to make fullscreen formspecs. It works, and if we have that information, then we can make fullscreen formspecs. Krock: it is useful, it is something we want |
19:57 |
rubenwardy |
god, this is unusuable. WTF is Virgin media doing. 11 second latency |
19:57 |
MTDiscord |
<GreenXenith> I think we've diverged far from the original point |
19:58 |
celeron55 |
what is the polling luatic is talking about |
19:58 |
rubenwardy |
mods need to call minetest.get_player_window_information() to get the info, there's no callback |
19:58 |
Krock |
MisterE: there's many ways to Rome. the one in the PR does it by letting modders calculate everything manually |
19:58 |
celeron55 |
the client sends events over the network, and the lua api is effectively a local getter method on the server |
19:58 |
rubenwardy |
yeah |
19:59 |
MTDiscord |
<MisterE> yeah. Better to do it that way, and then later add helper functions, than to gicve mods too little precomputed information |
19:59 |
Krock |
MisterE: yet it could be reached easier by retrieving the formspec size directly |
19:59 |
MTDiscord |
<GreenXenith> what else actually needs to be discussed on the PR? |
20:00 |
MTDiscord |
<MisterE> I do not understand how getting the formspec size lets modders know the screen size |
20:00 |
MTDiscord |
<MisterE> but, I am now retreating from this conversation, this is a dev meeting |
20:00 |
Krock |
why do you need the screen size if you have the maximal formspec size? |
20:01 |
MTDiscord |
<GreenXenith> We dont currently have max form size do we? |
20:01 |
MTDiscord |
<GreenXenith> If we did that would effectively be the screen size, no? |
20:01 |
celeron55 |
i think the screen size is useless, mods don't draw anything using it, right? |
20:01 |
rubenwardy |
you can calculate the max formspec size from the screen_size and real_gui_scaling |
20:01 |
MTDiscord |
<GreenXenith> you guys are killin me |
20:01 |
MTDiscord |
<MisterE> They would |
20:01 |
Krock |
GreenXenith: defined by the maximal dimensions where it does not downscale |
20:01 |
MTDiscord |
<GreenXenith> Im lost, is this an existing API feature? |
20:02 |
MTDiscord |
<MisterE> celeron, I have made fulscreen formspecs using the screen size in the main menu api |
20:02 |
Krock |
you could still add or subtract 20%, send it to fullscreen and it would look okay |
20:02 |
rubenwardy |
here's how you calculate max_fs_size using my PR: https://github.com/minetest/minetest/pull/12367#issuecomment-1133929847 |
20:02 |
MTDiscord |
<MisterE> Looks ok ~= full control ? |
20:02 |
rubenwardy |
I don't want to document this yet as the client-side code is still a bit buggy |
20:02 |
celeron55 |
can someone explain what is the thing mods couldn't do if they only got the maximum non-scaling formspec size? |
20:03 |
MTDiscord |
<MisterE> Calculations with HUDs |
20:03 |
celeron55 |
not the screen size |
20:03 |
celeron55 |
so what is the unit huds use? |
20:03 |
MTDiscord |
<GreenXenith> You asked what they couldnt do with only form size. The answer is HUD calculations. |
20:03 |
MTDiscord |
<MisterE> We really need both |
20:03 |
MTDiscord |
<MisterE> both maximal formspec size and screen size |
20:03 |
celeron55 |
do huda use pixels? |
20:03 |
celeron55 |
huds* |
20:03 |
MTDiscord |
<MisterE> yes |
20:04 |
MTDiscord |
<GreenXenith> I believe so |
20:04 |
rubenwardy |
huds use scaled pixels, so pixel * real_hud_scaling |
20:04 |
rubenwardy |
but I imagine there's hud elements that render pixels directly or something |
20:05 |
MTDiscord |
<GreenXenith> Ill be blunt: Window information is a basic part of applications. It's not up to anyone to decide if it is "useful" for game developers. It is an important feature to have. |
20:05 |
MTDiscord |
<MisterE> and besides that, it is useful |
20:05 |
MTDiscord |
<MisterE> well, would be if we had it |
20:05 |
MTDiscord |
<GreenXenith> What else needs discussing on the PR to get it merged? |
20:07 |
MTDiscord |
<MisterE> Modders who know what they need, to do what they want, have repeatedly asked for this feature over many years. Please, dont say that they dont know what they need. |
20:07 |
celeron55 |
as long as someone does a code quality review and adds the necessary formulas to docs that modders need to know i think it's fine |
20:07 |
MTDiscord |
<GreenXenith> Fantastic |
20:07 |
MTDiscord |
<MisterE> claps |
20:08 |
celeron55 |
the network protocol looks ok to me, that's what i really only care |
20:08 |
celeron55 |
+about |
20:10 |
MTDiscord |
<GreenXenith> Next item then? |
20:14 |
MTDiscord |
<GreenXenith> Guess that lived long |
20:15 |
rubenwardy |
next item is https://github.com/minetest/minetest/pull/12480 |
20:16 |
rubenwardy |
how important is keyboard navigation support, and what should be done to improve it |
20:16 |
rubenwardy |
formspecs are lacking generally in keyboard support |
20:16 |
rubenwardy |
!title |
20:16 |
MTDiscord |
<GreenXenith> Important to support but outside the scope of the PR |
20:16 |
ShadowBot |
[Manual Squash] Redesign/unify mainmenu settings interface by rubenwardy · Pull Request #12480 · minetest/minetest · GitHub |
20:16 |
MTDiscord |
<GreenXenith> (imo) |
20:16 |
rubenwardy |
It's relevant because the old advanced settings supported keyboards very well, and someone complained in the issue |
20:16 |
MTDiscord |
<GreenXenith> Oh, it did? |
20:17 |
rubenwardy |
I agree that it's a larger formspec issue to be improved though, and this redesign will improve things for more users |
20:17 |
MTDiscord |
<GreenXenith> Yeah I thought you meant it needed support for key-controls in forms in general |
20:17 |
rubenwardy |
Yeah, the current All Settings dialog can be used 100% with a keyboard faily easily |
20:18 |
MTDiscord |
<GreenXenith> Interesting |
20:18 |
|
pumpkkin[m]1 joined #minetest-dev |
20:21 |
pumpkkin[m]1 |
hello everyone. I'm hoping to become part of this community one day, and my desire is to aid this game in gaining the popularity it deserves. |
20:21 |
MTDiscord |
<MisterE> pumpkin, please move to #minetest-irc |
20:22 |
rubenwardy |
Hey! o/ General discussion is in #minetest |
20:22 |
MTDiscord |
<MisterE> there is a meeting occuring here |
20:22 |
Zughy[m] |
frankly, the average is user is way more important than the geeky advanced one |
20:23 |
Zughy[m] |
*average user |
20:23 |
Zughy[m] |
the geeky can still find some way to implement an easy navigation because they know where to put their hands, the average user will just quit |
20:27 |
rubenwardy |
Ok, I've gone through the questions, there's only one left: https://github.com/minetest/minetest/issues/7917 |
20:27 |
rubenwardy |
!title |
20:27 |
ShadowBot |
minetest.register_schematic · Issue #7917 · minetest/minetest · GitHub |
20:27 |
rubenwardy |
I don't know the answer to this, might be a bug or documentation issue |
20:32 |
Zughy[m] |
actually two: #12684 |
20:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/12684 -- Falling in liquids doesn't take viscosity into account for half a node |
20:33 |
Zughy[m] |
basically no one knows what that register schematic function does? |
20:36 |
rubenwardy |
that's new |
20:36 |
rubenwardy |
*one old one left |
20:38 |
Zughy[m] |
how about deprecating that function and then nuking it in 6.0? |
20:40 |
MisterE[m] |
register_schematic? isnt that for making lua schematics? Im pretty sure Ive seen that used in commonly used mods |
20:41 |
rubenwardy |
most use minetest.create_schematic and minetest.place_schematic |
20:41 |
MisterE[m] |
please, zughy, do not go yeeting out functions that mods use :P |
20:41 |
MisterE[m] |
oh, does that use lua tables? |
20:41 |
MisterE[m] |
then I guess it is redundant after all? |
20:42 |
Zughy[m] |
an example of the function can be seen in #10669 code snippet |
20:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/10669 -- minetest.place_schematic fails to update surrounding liquids |
20:43 |
rubenwardy |
register_schematic is used by 6 packages: https://content.minetest.net/zipgrep/0512a97e-e61d-45fb-b289-eda3809510ff/ |
20:43 |
rubenwardy |
4 unique |
20:44 |
MisterE[m] |
the nether mod uses place_schematic: |
20:44 |
MisterE[m] |
https://github.com/minetest-mods/nether/blob/52038017f385382fb43c9d0aa1e081e6618ce1aa/portal_api.lua#L1192 |
20:45 |
MisterE[m] |
we cant very well deprecate these |
20:45 |
rubenwardy |
we're talking about register_schematic, not place_schematic |
20:46 |
Zughy[m] |
don't create_schematic and register_schematic do the same thing or I'm missing something? |
20:46 |
|
diceLibrarian joined #minetest-dev |
20:46 |
rubenwardy |
no, create_schematic saves an area of the map to a file |
20:47 |
rubenwardy |
register_schematic loads a schematic into Minetest, either by filename or definition |
20:47 |
rubenwardy |
but you don't need to register, you can just place directly |
20:47 |
rubenwardy |
I think register_schematic allows preloading |
20:48 |
rubenwardy |
weird how it's not documented at all in the schematic section, and is instead in another section |
20:52 |
rubenwardy |
I think this is a documentation issue and an unconfirmed bug |
20:59 |
sfan5 |
I get the feeling todays meeting was(?) very inefficient |
21:01 |
sfan5 |
anyway someone should review #12695 so essentially trivial changes don't take 2 weeks again |
21:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/12695 -- Cut back on Gitlab-ci & misc. updates by sfan5 |
21:01 |
sfan5 |
applies to some other PRs too |
21:02 |
fluxionary_ |
https://github.com/minetest/minetest/blob/aa2fdc6ef6300f6b6683f96305bb1d9e63ba8ebb/src/network/connection.cpp#L1006 |
21:02 |
fluxionary_ |
should that `&&` be an `||`? |
21:02 |
fluxionary_ |
(apropos nothing anyone is talking about) |
21:04 |
rubenwardy |
sfan5: looks good to me |
21:05 |
rubenwardy |
and yeah, today's meeting was pretty bad |
21:06 |
MTDiscord |
<GreenXenith> offer improvements |
21:07 |
sfan5 |
you need a person who takes initiative, leads through the agenda and pushes forward |
21:08 |
MTDiscord |
<GreenXenith> you also need persons in general. |
21:08 |
MTDiscord |
<GreenXenith> seems like not many devs were available today |
21:08 |
MTDiscord |
<GreenXenith> er, consistently available* |
21:10 |
sfan5 |
fluxionary_: no, definitely not |
21:11 |
fluxionary_ |
sfan5: is the part that comes after the `&&` redundant then? the size will be 0, and 1 is less than 1/2 the minimum window size? |
21:11 |
sfan5 |
queued_commands != queued_reliables |
21:11 |
fluxionary_ |
oh i see |
21:11 |
fluxionary_ |
ok, got it |
21:12 |
sfan5 |
commands are things to send before they're split into packets (and assigned a seqnum) |
21:12 |
sfan5 |
and since data must not be reodered you can't bypass the queue if it's not empty |
21:13 |
fluxionary_ |
yeah i need to read more of this before commenting again. trying to figure out why there's a flood of "Possible packet stall" messages in the log |
21:15 |
sfan5 |
I think very useful would be to attach prometheus to the queues/lists/whatever in the connection code |
21:16 |
sfan5 |
then you could easily monitor for this specific case how big the queue is, the window size and how fast commands are converted to packets and how fast they end up being sent |
21:16 |
sfan5 |
all in production |
21:16 |
fluxionary_ |
i've suggested that to the server owner, will suggest it again |
21:29 |
|
proller joined #minetest-dev |
21:58 |
Zughy[m] |
RE: you need a person who takes initiative, leads etc. |
21:58 |
Zughy[m] |
I'm very good at that, but since I'm not a core dev I didn't chime in |
22:02 |
Zughy[m] |
I've already created the note for the next meeting, just in case |
22:03 |
MTDiscord |
<savilli> Aren't you a core manager or smth? |
22:04 |
MTDiscord |
<savilli> It makes sense that a manager leads meetings |
22:04 |
MTDiscord |
<savilli> At least it's how it's usually done in IT companies |
22:08 |
Zughy[m] |
I still see myself as a subordinate. But if core devs are fine and I'm available in those days (like today), I'll be more than glad |
22:32 |
|
panwolfram joined #minetest-dev |
23:08 |
|
diceLibrarian joined #minetest-dev |
23:42 |
|
Baytuch joined #minetest-dev |
23:53 |
|
vampirefrog joined #minetest-dev |