| Time |
Nick |
Message |
| 00:15 |
|
Taoki joined #minetest-dev |
| 01:34 |
|
specing_ joined #minetest-dev |
| 03:28 |
|
TechDude joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:16 |
|
olliy joined #minetest-dev |
| 08:41 |
|
Fixer joined #minetest-dev |
| 08:41 |
|
hlqkj joined #minetest-dev |
| 09:13 |
|
hlqkj_ joined #minetest-dev |
| 09:53 |
|
absurb joined #minetest-dev |
| 10:06 |
|
amk joined #minetest-dev |
| 10:07 |
|
calcul0n__ joined #minetest-dev |
| 11:39 |
|
Fleckenstein joined #minetest-dev |
| 11:56 |
|
calcul0n_ joined #minetest-dev |
| 12:01 |
MTDiscord |
<appguru> the changes of the model formspec appear to be compatibility-breaking |
| 12:01 |
MTDiscord |
<appguru> 5.4 doesn't accept model elements with more than 9 entries, 5.5 expects exactly 10 |
| 12:03 |
MTDiscord |
<appguru> 5.5 expects at least 5 and at most 10 it seems |
| 12:04 |
MTDiscord |
<appguru> nvm |
| 12:10 |
rubenwardy |
Needs new formspec version |
| 12:14 |
|
Fleckenstein joined #minetest-dev |
| 13:15 |
|
appguru joined #minetest-dev |
| 13:16 |
pgimeno |
https://github.com/BOINC/boinc#user-content-want-to-help I don't know if that's legally binding, but if it is, maybe Minetest should include a similar notice in README.md |
| 13:19 |
sfan5 |
standard for open source projects is that by submitting code you implicitly agree to the current licenses of the respective code files |
| 13:19 |
sfan5 |
such a notice goes much further allowing relicensing (even turning proprietary) without having to ask contributors |
| 13:21 |
pgimeno |
it would have been nice to have since the beginning, it would allow relicensing later |
| 13:25 |
pgimeno |
I don't see a problem with that; if it turns proprietary, people just stop contributing, but all versions prior to turning proprietary are still free, so it can be forked |
| 13:28 |
pgimeno |
the problem of relicensing for many projects is that you have to ask each and every contributor if they agree, therefore having a single person responsible for that is a big advantage |
| 13:29 |
MTDiscord |
<y5nw> I am not sure why relicensing is/needs to be considered at the moment |
| 13:29 |
pgimeno |
I'm not saying it has to be at the moment, but it will be a problem if it's desired in future |
| 13:30 |
sfan5 |
it goes the other way too: contributors may not want to make easy for the project to be relicensed to any license without the ability to have a say |
| 13:31 |
pgimeno |
yes, and they have the option of not contributing too |
| 13:32 |
|
specing_ joined #minetest-dev |
| 13:35 |
MTDiscord |
<y5nw> There is the consideration that the "allow project maintainer to relicense the project" point only makes sense when all existing contributors agree to allow relicensing. Otherwise you can end up having to revert certain commits, which can be a maintenance problem |
| 13:37 |
pgimeno |
exactly, and if you assign copyright to the maintainer, you're implicitly agreeing to allow relicensing, as you are waiving any copyrights |
| 13:38 |
MTDiscord |
<y5nw> ... but if you can't get existing contributors to agree then it's a problem. And one of them who doesn't can bring enough trouble |
| 13:39 |
pgimeno |
right, that's why I said it would have been nice to have it since the beginning |
| 13:40 |
MTDiscord |
<y5nw> ... which only makes sense if you manage to change the history |
| 13:42 |
MTDiscord |
<y5nw> There is also the possibility to do it now, but that would likely mean that the devs would only be allowed to relicense certain commits. Then you would have to remove all the other diffs that can't be relicensed or implement them cleanly |
| 13:49 |
|
hlqkj joined #minetest-dev |
| 13:52 |
MTDiscord |
<appguru> I think publishing a PR is a form of distribution of a derivative work. As our code is LGPL, the distributed derivative work has to be LGPL as well, due to copyleft. |
| 13:53 |
MTDiscord |
<Warr1024> You can't just remove a commit from the middle of a history to cleanse a contributor's influence from a project, because all commits made afterward are derivative of the state of the code that includes that commit. Even if the subsequent commits all applied cleanly (which they won't) you still have a clean-room problem with subsequent commits. |
| 13:54 |
MTDiscord |
<Warr1024> Also, it's possible for a contributor to also license their original work separately using a different license, but probably only units that can operate separately, i.e. some integration code may not be similarly licensable. For example, I could MIT-license my NNAA upscaling code, but arguably not the parts where I hook it into the engine to be actually used. |
| 13:56 |
sfan5 |
oh since you're here |
| 13:56 |
sfan5 |
@Warr1024 do you remember for what purpose you originally added texture_clean_transparent? and why was it not enabled by default? |
| 13:56 |
sfan5 |
(I don't expect a comprehensive answer since 2016 was 5 years ago after all) |
| 13:57 |
MTDiscord |
<Warr1024> I added it because of things like tall grass or leaves using transparency but with texture filtering enabled that uses naive linear algorithms. |
| 13:58 |
MTDiscord |
<Warr1024> What happens is image optimization software throws away the RBG channels on fully-transparent pixels, assuming they're "don't-cares" and increasing the repetition that way to improve compression. |
| 13:58 |
sfan5 |
by texture filtering are you also referring to mipmapping? |
| 13:58 |
MTDiscord |
<Warr1024> no, I mean bilinear |
| 13:58 |
sfan5 |
I see |
| 13:58 |
MTDiscord |
<Warr1024> The problem is that linear filtering smoothly interpolates each RGBA channel smoothly from one texture-pixel to the next, but the A value ends up clamped. |
| 14:00 |
MTDiscord |
<Warr1024> This means that if you have a red pixel fully opaque next to a blue pixel fully transparent, then then the rendered screen pixel just on the closer-to-red side of the line between them will have it RGBA values interpolated to a half-transparent purple pixel, but because the A value is clamped, it becomes a fully opaque purple pixel |
| 14:00 |
MTDiscord |
<Warr1024> hence you end up with strange colored (usually black) halos around all naively-filtered things. |
| 14:01 |
MTDiscord |
<Warr1024> So what clean transparent does is fill in the border pixel RGB values with an average of surrounding pixels, but doesn't touch the A channel, so that when that interpolation happens, the RGB values of that "halo" area become similar to the colors they're next to, bringing the filtered texture presentation closer to the unfiltered. |
| 14:01 |
MTDiscord |
<Warr1024> There are reasons to use bilinear: you need it to enable aniso, and aniso is needed to make mipmapping not look like arse for distant surfaces that are at steep angles. |
| 14:02 |
sfan5 |
I just recently worked with the code so you wouldn't have needed to explain |
| 14:02 |
MTDiscord |
<Warr1024> With full trilin+aniso, MT looks much better for distant surfaces, but can get blurry up close. Adding the texture_min_scale thing mitigates the blurriness up close. |
| 14:02 |
MTDiscord |
<Warr1024> Eh, my explanation is available for posterity :-) |
| 14:04 |
MTDiscord |
<Warr1024> Basically I wanted to try to maintain MT's "pixely" visual style, while also minimizing moire/aliasing artifacts, and these options that I added allow low-to-mid-end systems to do that efficiently enough for most within-surface pixels. |
| 14:06 |
|
luk3yx joined #minetest-dev |
| 14:06 |
MTDiscord |
<Warr1024> On the other hand I've seen shaders that can do similar stuff without the VRAM hogging that texture_min_size does, and my ~8 year old computer with an ivy bridge IGPU can handle them as far as I've seen, so it might not be unreasonable to move where it happens in the pipeline, if that's feasible. |
| 14:08 |
MTDiscord |
<Warr1024> Clean-transparent could be replaced by just doing alpha-weighting in the upscale filter for the RGB channels. The texture_min_size thing could be replaced by replacing linear interp with a different curve function, and the parameters might even be tunable based on depth to optimize it at any distance. |
| 14:38 |
pgimeno |
uh, I didn't notice that /help privs was no longer available in text format, would it be possible to bring it back? |
| 14:39 |
pgimeno |
or /help with no params, for the matter |
| 15:03 |
|
TechDude joined #minetest-dev |
| 15:05 |
|
DS-minetest joined #minetest-dev |
| 15:20 |
|
Taoki joined #minetest-dev |
| 15:24 |
|
Wuzzy joined #minetest-dev |
| 15:29 |
|
I_am_6r1d joined #minetest-dev |
| 15:32 |
Krock |
pgimeno: you can still double-click entries to copy to the chest |
| 15:32 |
Krock |
*chat |
| 15:32 |
pgimeno |
that's not very practical for getting them logged, though |
| 15:32 |
Krock |
but the text-only output is gone if you wanted that |
| 15:33 |
Krock |
previous messages were not logged either |
| 15:33 |
pgimeno |
apparently some of it was reinstated, #8869 |
| 15:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/8869 -- Also print help commands to chat for server terminal by TranslucentSabre |
| 15:33 |
pgimeno |
oh but they went to the console, and I have modded my client to log the console |
| 15:35 |
pgimeno |
would a patch to add a `--text` option to the /help command be accepted? like: `/help --text` would send command help to the console, and `/help --text privs` would send all privs and their help to the console |
| 15:36 |
Krock |
that whole thing is already kinda messy and I'd love to have this separated |
| 15:36 |
pgimeno |
separated how? |
| 15:36 |
Krock |
as you said. /help with an additional argument to output text only |
| 15:37 |
Krock |
it would also be very helpful in this case to know whether the admin is connecting from CLI or is in-game |
| 15:37 |
Krock |
perhaps a get_player_by_name would help there |
| 15:39 |
pgimeno |
Krock: I'm not very clear about whether you gave a response to my question of whether a patch would be accepted |
| 15:39 |
Krock |
would be accepted |
| 15:40 |
Krock |
FYI: Wuzzy is going for the short-hand notation ("-r") here, rather than "--reconnect", for example #11031 |
| 15:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/11031 -- Fix misleading builtin command syntax of /shutdown by Wuzzy2 |
| 15:40 |
Krock |
since that's the only command so far with an optional boolean flag |
| 15:40 |
Wuzzy |
"--reconnect" was never a thing actually |
| 15:40 |
Krock |
but "--text" would perhaps be |
| 15:41 |
Wuzzy |
it was actually "yes"/"true"/etc. |
| 15:41 |
Wuzzy |
because it was checked with minetest.is_yes() |
| 15:41 |
Wuzzy |
so the syntax was very misleading |
| 15:41 |
MTDiscord |
<appguru> I would prefer plain reconnect |
| 15:42 |
pgimeno |
either is fine with me, if you prefer e.g. -t that's fine |
| 15:42 |
Wuzzy |
but this was rejected by a core dev |
| 15:42 |
Wuzzy |
personally, i also like "-r" more, its also explained in help text |
| 15:42 |
Krock |
also regarding that PR, Wuzzy. does `+(-r)` really work? I thought "-" needs escaping |
| 15:42 |
Krock |
anyway will test that sooner or later |
| 15:43 |
Wuzzy |
Krock: shutdown is not the only command with a flag, there is also set with -n |
| 15:43 |
Krock |
oh right! |
| 15:45 |
pgimeno |
could we maybe add some sort of getopt processing for commands? |
| 15:45 |
pgimeno |
(to help standardization) |
| 15:45 |
Krock |
needs a shameless plug from ruben |
| 15:45 |
Krock |
I think he wrote a mod for that |
| 15:46 |
Krock |
https://forum.minetest.net/viewtopic.php?t=14899 |
| 15:47 |
Krock |
but from what I can see there's no optional command arg handling |
| 15:47 |
pgimeno |
so it seems |
| 15:48 |
pgimeno |
I'll go with very simple processing for now |
| 15:51 |
pgimeno |
of course, `/mods -t` would be next |
| 15:51 |
Krock |
I'd love to supersede #8869 with these new args |
| 15:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/8869 -- Also print help commands to chat for server terminal by TranslucentSabre |
| 15:52 |
Krock |
seems much cleaner |
| 15:55 |
Wuzzy |
Krock: for some strange reason, a "(-r)" seems to work, but I just escaped it "(%-r)" just to be sure. must be some undocumented behavior of lua patterns, but better to comply with documentation just to be sure |
| 15:55 |
Krock |
right |
| 15:55 |
Wuzzy |
and yes, the "-" is a magic char |
| 15:55 |
Krock |
Wuzzy: I noticed that string.split() has a mode where it does not trim empty entries |
| 15:55 |
MTDiscord |
<y5nw> I think "(-" works because "(" is not a parttern by itself so you can't repeat it |
| 15:56 |
Krock |
still, escape it to be sure anyway |
| 15:56 |
Wuzzy |
the documentation isnt really clear on what happens with a "runaway" "-" |
| 15:58 |
pgimeno |
yes, it's undefined, meaning it might change in future. For example, (? was used for special stuff in Perl and other RE engines because it's undefined in POSIX regular expressions. |
| 15:58 |
MTDiscord |
<y5nw> Is Lua 5.1 still updated? |
| 15:59 |
Krock |
probably not |
| 15:59 |
Krock |
there were a few fix releases but those already happened a while aho |
| 15:59 |
pgimeno |
" The last release was Lua 5.1.5, released on 17 Feb 2012. There will be no further releases of Lua 5.1. " http://www.lua.org/versions.html#5.1 |
| 16:00 |
|
Taoki joined #minetest-dev |
| 16:00 |
MTDiscord |
<y5nw> ... and I am not sure whether the LuaJIT devs want to change the behavior of string matching, but anyway |
| 16:01 |
pgimeno |
it's still relying on undefined behaviour, either way |
| 16:01 |
|
hlqkj joined #minetest-dev |
| 16:02 |
Wuzzy |
doesnt matter anyway, since i escaped it ? |
| 16:04 |
MTDiscord |
<appguru> it does matter |
| 16:04 |
MTDiscord |
<appguru> don't do it this way |
| 16:05 |
MTDiscord |
<appguru> -r implies a certain syntax which just isn't present; it's not a flag, you can't put it anywhere |
| 16:06 |
Wuzzy |
... |
| 16:06 |
Wuzzy |
but it works |
| 16:07 |
Wuzzy |
This is the syntax: "[<delay_in_seconds> | -1] [-r] [<message>]" |
| 16:07 |
Wuzzy |
if you want to argue against my PR, test it. |
| 16:08 |
MTDiscord |
<appguru> This syntax is poor UX |
| 16:09 |
Wuzzy |
suggest a better one |
| 16:10 |
Wuzzy |
but why is it bad? |
| 16:10 |
Wuzzy |
this is an admin command btw, so we are already in power user territority |
| 16:10 |
pgimeno |
I guess it's because -r depends on being at a specific position and that position is not at the beginning of the command |
| 16:11 |
MTDiscord |
<appguru> 1. delay_in_seconds = -1 is absolutely hacky: There should instead be a command /shutdown cancel, because that's a lot more readable |
| 16:12 |
Wuzzy |
note the main goal of the PR is a bugfix. the current /shutdown command has broken syntax |
| 16:12 |
MTDiscord |
<appguru> 2. -r implies a flag; this isn't a flag, and we don't really want to establish this kind of syntax here - I preferred "reconnect" |
| 16:12 |
Wuzzy |
"reconnect" was rejected by a core dev, sorry |
| 16:13 |
pgimeno |
@appguru we don't? why? |
| 16:13 |
MTDiscord |
<appguru> Well, at least I don't |
| 16:13 |
Wuzzy |
When appguru says "we", "I" is actually meant ? |
| 16:13 |
pgimeno |
granted, it's not friendly for people used to gettext, but we can add some kind of option processing later, and then -r could maybe be anywhere |
| 16:14 |
MTDiscord |
<appguru> of course: "we" = me, me and me |
| 16:14 |
MTDiscord |
<appguru> me and my precious |
| 16:14 |
Wuzzy |
i noticed you still did not suggest a new syntax |
| 16:14 |
MTDiscord |
<appguru> umm, I did |
| 16:14 |
appguru |
let me repeat though: |
| 16:15 |
appguru |
"/shutdown cancel" (instead of "/shutdown -1 ...") to cancel a shutdown |
| 16:15 |
pgimeno |
FWIW I agree with that |
| 16:15 |
Wuzzy |
this doesn't count. full syntax please |
| 16:16 |
hlqkj |
that's not a syntax suggestion, that is just «change '-1' with 'cancel'» |
| 16:16 |
pgimeno |
"[<delay_in_seconds> | cancel] [-r] [<message>]" |
| 16:17 |
hlqkj |
which, given that this command is for admins only, only adds unnecessary key strokes imho |
| 16:17 |
pgimeno |
@appguru: any alternative for reconnecting besides 'reconnect' which is ambiguous? |
| 16:18 |
appguru |
"cancel | ([<delay>] [show-reconnect] [<message>])" |
| 16:18 |
Wuzzy |
note that both "-1" and "-r" are explained in the /help text |
| 16:18 |
appguru |
also note that if show-reconnect is to be optional, delay may as well be too |
| 16:18 |
DS-minetest |
suggestion: syntax = "[<delay_in_seconds>] [<message>]" and cancel if delay_in_seconds<0 and set -r iff the least significant bit of the mantissa of delay_in_seconds is 1 |
| 16:19 |
Wuzzy |
LOL |
| 16:19 |
appguru |
he is the messiah! |
| 16:19 |
hlqkj |
LMAO |
| 16:20 |
appguru |
the "in seconds" information should be moved to the help text |
| 16:20 |
Wuzzy |
note my goal is primaraily to make the syntax help compatible with the *real* syntax. which currently it isnt |
| 16:21 |
Wuzzy |
so i have no real strong feelings towards any particular syntax as long it works |
| 16:21 |
Wuzzy |
however, there has been no agreement at all so far, so i wont change |
| 16:21 |
pgimeno |
there has been agreement that 'cancel' is better than '-1' |
| 16:22 |
Wuzzy |
what about -c? |
| 16:22 |
MTDiscord |
<appguru> I say omit the hyphen. Not a flag. |
| 16:22 |
pgimeno |
in fact, using - for options has the problem of being used for number signs too |
| 16:23 |
MTDiscord |
<y5nw> is the '/' from DOS commands better? |
| 16:23 |
pgimeno |
that will cause trouble in a getopt-style parser |
| 16:23 |
pgimeno |
I was thinking of that @y5nw |
| 16:23 |
appguru |
We could shorten cancel to c and show-reconnect to s-r or something. |
| 16:23 |
Wuzzy |
-c or -r cannot possibly be confused with a number |
| 16:24 |
pgimeno |
no, but if getopt parsing is implemented later, -1 can be confused with an option |
| 16:24 |
Wuzzy |
also, remember that "reconnect" is rejected by coredev, so thats not an option. so, i bet "show-reconnect" has the same fate |
| 16:25 |
pgimeno |
that's an argument for avoiding '-' as option prefix in general |
| 16:25 |
appguru |
which coredev has rejected that? |
| 16:25 |
pgimeno |
and to stay consistent, it should not be introduced |
| 16:25 |
DS-minetest |
"-1" can't be confused with an option if you don't allow option names to start with numbers |
| 16:25 |
Wuzzy |
we already have -n in /set |
| 16:25 |
pgimeno |
DS-minetest: true |
| 16:25 |
pgimeno |
hm |
| 16:25 |
Wuzzy |
this discussion is so boring. this is a perfect example of bikeshedding |
| 16:26 |
hlqkj |
how doesn't the -r fit in place of a confusing out-of-no-where 'true' we had before? i think no one using minetest expects the chat to be a bash interpreter |
| 16:26 |
pgimeno |
ok, we can do that |
| 16:26 |
pgimeno |
Wuzzy: maybe, but IMO the future of command options is into play. Anyway, DS-minetest has made an interesting point. |
| 16:27 |
Wuzzy |
Krock rejected a literal "reconnect" FYI |
| 16:28 |
pgimeno |
hlqkj: it seems that we are beginning to need more and more options for commands in general, so it might sort of become a bit bash-like |
| 16:28 |
appguru |
hmm |
| 16:28 |
Wuzzy |
no matter what I do, I will always annoy at least one of you. |
| 16:28 |
Wuzzy |
there is no way for me to win. every possible move is a losing move |
| 16:28 |
pgimeno |
haha, count on that Wuzzy |
| 16:28 |
appguru |
I would in fact prefer y/n for reconnect to be used |
| 16:28 |
hlqkj |
good, if that's the case there will be no issue with -r |
| 16:28 |
appguru |
as long as you don't annoy me, everything is fine, at least on my part |
| 16:29 |
Krock |
"reconnect" would surely be possible, but in terms of translating it's easier to have flags rather than written text |
| 16:29 |
Wuzzy |
ok i do have a strong opinion on "true/yes"/etc. as an argument for reconnect. this is just very awkward to explain in the command help and takes up precious space |
| 16:29 |
appguru |
no? it's how all commands work: what a certain argument does is explained in syntax / help |
| 16:30 |
appguru |
Minetest uses numbered arguments, as opposed to named arguments or flags / sets. |
| 16:31 |
appguru |
Let's keep it that way |
| 16:31 |
pgimeno |
that causes problems in that you can't omit one in the middle |
| 16:31 |
appguru |
Indeed, you can only omit at the tail |
| 16:32 |
appguru |
But does "reconnect" need to be omittable? Delay can't be omitted either. |
| 16:33 |
pgimeno |
according to the help, 'reconnect' and the message can be omitted independently. Not sure if that's because the help is wrong and it should be [-r [message]] instead of [-r] [message] |
| 16:33 |
appguru |
So how about "(<delay> | cancel) [reconnect] [message]" |
| 16:34 |
appguru |
Detecting whether reconnect or message was omitted requires slightly hacky things |
| 16:35 |
hlqkj |
that'd be [<message>] |
| 16:36 |
pgimeno |
'reconnect' could be part of the message: /shutdown 5 reconnect after we're done, please |
| 16:36 |
pgimeno |
-r is less likely to be part of the message |
| 16:36 |
appguru |
/reconnect 42 yes reconnect after we're done, please |
| 16:37 |
appguru |
or /reconnect 0 no don't even try to reconnect, this server is down for good |
| 16:38 |
Wuzzy |
the command syntax in my PR is 100% correct. you can test if you dont believe me. Enusring the correctness of the command syntax is the ONLY goal of this PR, after all |
| 16:39 |
DS-minetest |
strings with whitespace should be in "s imo. those example invocations^ are hardly readable |
| 16:39 |
Wuzzy |
stop hijacking my bugfix PR with feature request |
| 16:40 |
appguru |
:P |
| 16:40 |
appguru |
well, I could live with -r |
| 16:40 |
Wuzzy |
especially if you cant really agree on a particular syntax ? |
| 16:40 |
appguru |
TBH -r should be removed |
| 16:40 |
appguru |
I haven't seen a single server where I didn't time out after pressing reconnect |
| 16:41 |
Wuzzy |
aaaand another off-topic comment ? |
| 16:41 |
hlqkj |
fascinating... |
| 16:41 |
Wuzzy |
-r cant be removed because thats a feature of core.request_shutdown |
| 16:42 |
Wuzzy |
remoing -r means removing reconnect feature in request_shutdown, i.e. altering the api |
| 16:42 |
Wuzzy |
this WOULD break things |
| 16:42 |
appguru |
no |
| 16:42 |
appguru |
chatcommand != API |
| 16:42 |
appguru |
changing the syntax already breaks things, removing it altogether would IMO be fine |
| 16:43 |
appguru |
("breaks things" if you considered chatcommands to be a part of the API) |
| 16:43 |
Wuzzy |
if you're questioning the validity of reconnect, why keep it in the api? |
| 16:43 |
Wuzzy |
I do not consider chatcommands to be part of the api, lol |
| 16:44 |
Wuzzy |
hmmm but u have a point. reconnect feature in the shutdown command seems a bit questionable. but again, this is still irrelevant to the PR |
| 16:45 |
pgimeno |
I'd suggest http://www.formauri.es/personal/pgimeno/pastes/shutdown-help-fix.patch instead |
| 16:45 |
Wuzzy |
making reconnect a mandatory parameter is a terrible idea |
| 16:45 |
Wuzzy |
a clear downgrade to what i was doing |
| 16:46 |
MTDiscord |
<appguru> I like pgimeno's thing |
| 16:46 |
pgimeno |
ok, let me try again |
| 16:46 |
Wuzzy |
also, since <reconnect> is a non-literal parameter, you must specify the possible value |
| 16:47 |
Wuzzy |
"<reconnect> is a boolean" ... this is even more terrible.. boolean can mean many things to the user. thats what i mean "it is awkward to explain in the help" |
| 16:48 |
pgimeno |
http://www.formauri.es/personal/pgimeno/pastes/shutdown-help-fix-2.patch |
| 16:48 |
Wuzzy |
ugh... |
| 16:48 |
pgimeno |
actually there's a syntax for that, but it's a bit awkward for an end user |
| 16:48 |
Wuzzy |
"If <message> is specified, <reconnect> should be present." <<< this is describing something that the syntax expresses. also a bad suggestion |
| 16:49 |
DS-minetest |
pgimeno: why not "... [<reconnect> [<message>]]"? |
| 16:49 |
DS-minetest |
not that awkward imo |
| 16:49 |
Wuzzy |
so far all suggestions you made to me are clearly inferior. |
| 16:49 |
Wuzzy |
except the "cancel" thing maybe, this might be debatable |
| 16:49 |
pgimeno |
http://www.formauri.es/personal/pgimeno/pastes/shutdown-help-fix-3.patch |
| 16:49 |
pgimeno |
wait |
| 16:50 |
Wuzzy |
congratulations, your syntax is now less flexible than mine. its another downgrade. |
| 16:50 |
pgimeno |
reload the last one if you loaded it |
| 16:51 |
pgimeno |
I think it matches current behaviour, doesn't it? |
| 16:52 |
DS-minetest |
imo the worst problem with the positional -r is, that you can't specify a message without setting reconnect to true. the current behaviour lets you insert the default value false |
| 16:52 |
DS-minetest |
-no-r could fix that |
| 16:52 |
Wuzzy |
thats not true |
| 16:52 |
Wuzzy |
/shutdown my_message works in my syntax |
| 16:53 |
Wuzzy |
also /shutdown 5, or /shutdown -r |
| 16:55 |
Wuzzy |
One argument I have against using literal "cancel" is that it is a word that might be confused with message e.g. "/shutdown cancel this server" will have "this server" as message parsed, not "cancel this server" |
| 16:56 |
DS-minetest |
but what about "/shutdown -r makes it hard to find an example sentence that starts with it" |
| 16:57 |
Wuzzy |
yeah thats not really possible to start message with "-r" literally unless you specified -r for reconnect as well |
| 16:57 |
Wuzzy |
a small price to pay |
| 16:57 |
Wuzzy |
yes it is a pretty esoteric limitation |
| 16:57 |
Wuzzy |
-r is more esoteric than cancel tho |
| 16:58 |
DS-minetest |
suggestion: syntax = "[-d <delay_in_seconds>] [-r] [-m <message>] | -c" |
| 16:58 |
Wuzzy |
seems a bit overcomplicated... |
| 16:58 |
Wuzzy |
no other command does this |
| 16:58 |
DS-minetest |
yet |
| 16:59 |
Wuzzy |
i see -r not really as a flag, just as a short boolean param |
| 16:59 |
Wuzzy |
that just happens to start with a dash |
| 17:00 |
Wuzzy |
besides, if you are going full "flag mode" anyway, you should support random order as well. but this will blow up the required command help massively. sadly not practical... for now at least |
| 17:00 |
DS-minetest |
can't the help text be multiline? |
| 17:01 |
Wuzzy |
pgimeno: btw I believe your patches wont work anyway because iirc the command parsing was pretty broken in general as well. i had to replace the parsing completely. not sure tho |
| 17:01 |
Krock |
DS-minetest: it can |
| 17:01 |
Wuzzy |
but 1-line help texts are still preferrable |
| 17:01 |
Wuzzy |
the more complex you make the syntax, the more words you need to pay in the help text, which is bad |
| 17:02 |
MTDiscord |
<y5nw> Are we introducing manual pages to Minetest now? |
| 17:02 |
DS-minetest |
please, yes! |
| 17:02 |
Wuzzy |
? |
| 17:02 |
pgimeno |
anyway, the future of command options is not in danger anymore. I am OK with the PR as is. |
| 17:03 |
DS-minetest |
the help text should document the features, not only the syntax. and if the shutdown command can do many different things, it needs more documentation |
| 17:03 |
Wuzzy |
... |
| 17:03 |
Wuzzy |
I can't even! |
| 17:04 |
Wuzzy |
have you even read the PR? ? |
| 17:05 |
Wuzzy |
but there are some commands in MT that are really complex |
| 17:05 |
Wuzzy |
like rollback or profiler |
| 17:05 |
Wuzzy |
but thats a different can of worms! |
| 17:07 |
Wuzzy |
oh speaking of killing reonnect from the command entirely: I belive there might be someone who has configured minetest in a way to automatically restart the server ASAP when it was shutdown. so a reconnect option even for the command can be useful. |
| 17:08 |
MTDiscord |
<y5nw> Seriously though, while the MT devs are reviewing my string input event handler patch I do have time to implement MT manual pages ... |
| 17:08 |
DS-minetest |
well, the shutdown command can do arbitrary correct invocations of request_shutdown (, which needs multiple lines of documentation), so I consider it being able to do many things |
| 17:08 |
Wuzzy |
How is "Shutdown server (-1 cancels a delayed shutdown, -r allows players to reconnect)" complicated, again? |
| 17:09 |
|
hlqkj_ joined #minetest-dev |
| 17:10 |
Wuzzy |
I have the feeling you are trying to review a PR without even looking at it. here's the actual code btw: https://github.com/minetest/minetest/pull/11031/files |
| 17:11 |
DS-minetest |
indeed not very complicated, but you could theoretically still split the -1 cancels a delayed shutdown and -r allows players to reconnect into separate lines |
| 17:12 |
Wuzzy |
y5nw: be patient. sometimes it can take years for a PR to be accepted. you must also be willing to update your PR constantly because it frequently might become outdated. be prepared for long periods of nothing happening, no matter how high-quality ur PR. thats how Mt development usually works |
| 17:12 |
Wuzzy |
Mt has a serious shortage in official reviewers. |
| 17:13 |
Wuzzy |
only core devs can give offiicial approval, right? |
| 17:13 |
sfan5 |
yes but |
| 17:13 |
sfan5 |
I don't think they meant that |
| 17:15 |
DS-minetest |
(I'm sorry, I tend to say too much about things that I don't really care much about. to be fair, I've not said anything about your concrete code, just about the concepts) |
| 17:17 |
MTDiscord |
<y5nw> Wuzzy: I understand. I meant by "while the devs review my PR" that I can spend time working on other things related to Minetest instead of sitting in front of my computer 24/7 waiting for a review |
| 17:18 |
Wuzzy |
heh, ok |
| 17:20 |
Wuzzy |
btw I have now 20 PRs in the pipeline right now, more than anyone else |
| 17:20 |
Wuzzy |
i'm surprised by myself. i have been more obsessed about minetest than usually, i guess |
| 17:20 |
Wuzzy |
probably because i left MineClone 2, there was a vacuum ? |
| 17:22 |
Wuzzy |
I am in a good mood right now. Anyone, suggest any PR to me for me to review. |
| 17:24 |
MTDiscord |
<y5nw> dumps the list of open PRs at Wuzzy |
| 17:25 |
Wuzzy |
*20 years later* |
| 17:25 |
Wuzzy |
how about 1 PR? |
| 17:25 |
MTDiscord |
<y5nw> "I reviewed all the PRs for now ... oh there are more ..." (getting off-topic btw) |
| 17:27 |
MTDiscord |
<Jonathon> on the topic of reviewing PR's, could a core dev other than rubenwardy review https://github.com/minetest/minetest/pull/10731 since it missed being in 5.4 and hasnt been really touched since |
| 17:32 |
pgimeno |
what's the difference between S(...) and core.gettext(...) in builtin? |
| 17:32 |
Krock |
S() is custom client-side translation using media |
| 17:32 |
Krock |
gettext is .po |
| 17:33 |
Krock |
so client-only code should use gettext, and server-provided content should use S() |
| 17:35 |
pgimeno |
so, a server error message should use S(), right? |
| 17:35 |
pgimeno |
guess so, ok, thanks! |
| 17:36 |
Krock |
<wa |
| 17:36 |
Krock |
yes |
| 17:39 |
Wuzzy |
as the one who localized builtin, i can confirm |
| 17:39 |
Wuzzy |
gettext is for stuff like the main menu |
| 17:39 |
Wuzzy |
while S() is for stuff like server command descriptions |
| 17:40 |
Wuzzy |
at least in builtin |
| 17:40 |
Wuzzy |
pgimeno: why did you ask? |
| 17:40 |
pgimeno |
Wuzzy: I'm working on a patch for builtin that emits a server error message, I wanted to know which one to use |
| 17:41 |
Wuzzy |
ok. if its a new file, don't forget to add core.get_translator at the top (see other .lua files) |
| 17:41 |
|
tech_exorcist joined #minetest-dev |
| 17:42 |
Wuzzy |
dont worry about updating template.txt. this can be done separately. |
| 17:44 |
pgimeno |
no, not a new file, but thanks for the heads-up |
| 17:48 |
sfan5 |
@Jonathon the code of thast doesn't really need more review but we'd need to decide on what to do about the API |
| 17:49 |
sfan5 |
that* |
| 17:49 |
|
Kimapr joined #minetest-dev |
| 17:49 |
sfan5 |
or the approach it takes in general |
| 17:50 |
Wuzzy |
whats the problem specifically? |
| 17:50 |
MTDiscord |
<Jonathon> ah, ok, would appreciate some activity on it when yall have time (which i know is sparse) |
| 17:50 |
Wuzzy |
is it about add vs multiply? |
| 17:50 |
Wuzzy |
sfan5: so the code is verified functional? great! |
| 17:51 |
sfan5 |
verified? no, but it's been reviewed |
| 17:51 |
sfan5 |
Wuzzy: https://irc.minetest.net/minetest-dev/2021-02-17#i_5787077 |
| 17:51 |
Wuzzy |
verified as in, tested for bugs, etc. |
| 17:53 |
|
tech_exorcist joined #minetest-dev |
| 17:54 |
Wuzzy |
"I think 10731 is missing a method to at least retrieve all modifiers" <<< i agree, all modifiers should be gettable |
| 17:55 |
|
tech_exorcist joined #minetest-dev |
| 17:55 |
Wuzzy |
i still dont know why additive modifiers are supported. what's the use case for that? |
| 17:56 |
Wuzzy |
im not opposed to that, just confused |
| 17:56 |
Wuzzy |
is numberZero available in chat? |
| 17:56 |
Wuzzy |
i mean, like, at all? |
| 17:56 |
Wuzzy |
!seen numberZero |
| 17:56 |
ShadowBot |
Wuzzy: I haven't seen numberZero in #minetest-dev. |
| 17:56 |
sfan5 |
!seen numzero |
| 17:56 |
Wuzzy |
? |
| 17:56 |
ShadowBot |
sfan5: I saw numzero in #minetest-dev 4 days, 21 hours, 16 minutes, and 33 seconds ago saying "make yet another PR that won’t ever be merged?" |
| 17:57 |
|
tech_exorcist joined #minetest-dev |
| 17:57 |
Wuzzy |
ahhh ? |
| 17:58 |
sfan5 |
Wuzzy: having items that do "increases speed by +2" *and* ones that do "increases speed by 10%" are very common game mechanics |
| 17:58 |
|
tech_exorcist joined #minetest-dev |
| 17:59 |
Wuzzy |
but thats the thing... |
| 17:59 |
Wuzzy |
"increase speed by +2" doesnt make sense with the physics system |
| 17:59 |
Wuzzy |
in the raw override table, the "speed" value is a factor to the actual player speed, not an addition |
| 17:59 |
sfan5 |
well idk |
| 18:00 |
sfan5 |
someone will probably need it someday |
| 18:00 |
MTDiscord |
<Jordach> probably me |
| 18:00 |
|
tech_exorcist joined #minetest-dev |
| 18:01 |
Wuzzy |
i.e. if you add +2 to this raw speed value, the resulting speed can be wildly different depending on it was before |
| 18:01 |
Wuzzy |
if the start speed was 1, and you add 2, you get a speed of 3. meaning you are 3 times as fast |
| 18:01 |
Wuzzy |
but if the start speed was 2, and you add 2, you get a speed of 4. meaning you are only 2 times as fast as before |
| 18:03 |
Wuzzy |
if you want to add a constant speed, the addition method actually doesnt do what you want |
| 18:03 |
Wuzzy |
since you add to a *multiplier* not the actual speed |
| 18:04 |
Wuzzy |
anyway, not really opposed to the 'add' method, i just doubt there's any real use case in that |
| 18:05 |
MTDiscord |
<Jordach> fwiw there's no difference between multiplier and percentage |
| 18:06 |
Wuzzy |
give me a real-world usecase for add, in the way its implemented right now |
| 18:06 |
MTDiscord |
<Jordach> i was more thinking add being "add this to the base physics modifier" |
| 18:06 |
sfan5 |
the more important part of what I linked was "<sfan5> maybe the engine should merely make it easy for games to provide their own implementation?" btw |
| 18:06 |
MTDiscord |
<Jordach> "this does not stack with multiplacative pieces" |
| 18:07 |
MTDiscord |
<Jordach> also that |
| 18:09 |
Wuzzy |
well, supporting multiplicative support is extemely important, it makes life for mods SO much easier |
| 18:09 |
Wuzzy |
which is what the PR does. this part of the PR i completely support |
| 18:09 |
Wuzzy |
and in case of games rolling their own implemenattion.... thats already possible. see my mod [playerphysics] |
| 18:10 |
Wuzzy |
however, i dont see any demand for such specific mod implementations |
| 18:11 |
Wuzzy |
in mineclone2, i have used the multiplicative method (like ruben uses) for years and it worked perfectly |
| 18:15 |
|
hlqkj_ joined #minetest-dev |
| 18:21 |
celeron55 |
if a game wants to add rather than multiply, it could do addition by itself and only apply the final result as a multiplier, thus the engine would only need to support multiplication |
| 18:22 |
celeron55 |
or a mod |
| 18:24 |
celeron55 |
i think that would make sense |
| 18:31 |
pgimeno |
impulse by definition adds speed |
| 18:32 |
pgimeno |
I think it does make sense |
| 18:34 |
pgimeno |
(it actually adds momentum, but since the mass is assumed constant, it effectively adds speed) |
| 18:34 |
pgimeno |
so, if an object needs an impulse applied, like e.g. when hitting it with another object that must be done through an addition of speed |
| 18:35 |
Wuzzy |
the weird part is that you add to the speed *factor* rather than the speed itself |
| 18:35 |
pgimeno |
s/object that/object, that/ |
| 18:35 |
pgimeno |
uh |
| 18:35 |
Wuzzy |
and what happens when you add -5 when the initial speed is 1? |
| 18:36 |
pgimeno |
final speed is -4, think of it like an object moving forwards at speed 1 hit by another object with the same mass going at speed -5 |
| 18:36 |
Wuzzy |
is negative speed even supported by minetest? |
| 18:36 |
pgimeno |
well, I was actually talking about velocity (a vector) |
| 18:37 |
Wuzzy |
i am talking about speed as in physics_override, which is a factor |
| 18:37 |
pgimeno |
sorry, I think I missed that part of the context |
| 18:37 |
pgimeno |
then it probably doesn't make sense to add something to it |
| 18:38 |
Wuzzy |
yep... if you do set_physics_override({speed=-4}), effective speed is 0 |
| 18:39 |
Wuzzy |
but negative gravity works ... interesting |
| 18:40 |
pgimeno |
anyway, I was going to ask, would it make sense to rename minetest/irrlicht to minetest/irrlichtmt ? (taking into account that GitHub leaves a redirection automatically) |
| 18:40 |
Wuzzy |
yes |
| 18:41 |
pgimeno |
I was going to clone it, and I noticed I already had an irrlicht/ dir where I was going to clone, so I wondered |
| 18:41 |
sfan5 |
hm I dunno |
| 18:42 |
sfan5 |
(not that there are good reasons against but it works so why not leave it) |
| 18:43 |
pgimeno |
because it has changed the name, I guess |
| 18:44 |
pgimeno |
here's an example of a project that was renamed: https://github.com/vrld/Quickie |
| 18:44 |
pgimeno |
now it's called SUIT; if the creator left the old name in place, it would be harder to find for those who look for it |
| 18:49 |
Wuzzy |
IrrlichtMt is still relatively new, so its still pretty safe to rename it |
| 18:50 |
Wuzzy |
i mean the repo name |
| 18:50 |
Wuzzy |
speaking of IrrlichtMt: #11163 |
| 18:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/11163 -- Rename “Irrlicht” to “IrrlichtMt” by Wuzzy2 |
| 18:54 |
pgimeno |
preferably before the release |
| 19:05 |
|
TechDude joined #minetest-dev |
| 19:15 |
|
hlqkj joined #minetest-dev |
| 19:29 |
rubenwardy |
[19:06] <Wuzzy> give me a real-world usecase for add, in the way its implemented right now |
| 19:29 |
rubenwardy |
Potions based around +25% |
| 19:29 |
Wuzzy |
but wouddn't that be just a 1.25 multiplier? |
| 19:30 |
Wuzzy |
can u be more specific maybe? |
| 20:04 |
celeron55 |
of course not |
| 20:05 |
celeron55 |
altough it's almost the same |
| 20:11 |
pgimeno |
is there a way to determine if the console where a command is issued supports formspecs? |
| 20:13 |
pgimeno |
specifically, if it's sent from the terminal or from the GUI |
| 20:27 |
sfan5 |
not directly |
| 20:27 |
sfan5 |
but you can check if the player actually exists in the server, commands from ncurses won't satisfy that condition |
| 20:28 |
pgimeno |
how do I check that? get_player_by_name? |
| 20:29 |
sfan5 |
yes |
| 20:29 |
pgimeno |
thanks |
| 20:33 |
|
absurb joined #minetest-dev |
| 21:29 |
pgimeno |
https://codeberg.org/pgimeno/minetest/pulls/1 |
| 21:30 |
pgimeno |
any takers? |
| 21:35 |
pgimeno |
sfan5: what happens if the admin is logged in as a player while the terminal console is being used? wouldn't that method (get_player_by_name) fail? |
| 21:38 |
sfan5 |
I guess |
| 21:39 |
Krock |
why would an admin use both at once? |
| 21:39 |
Krock |
there's always a case, but I'd simply ignore it for simplicity |
| 21:39 |
pgimeno |
not sure, anyway it's not a biggie if they use /help in the terminal and it shows a formspec in their client, I suppose |
| 21:40 |
pgimeno |
and they always have -t |
| 21:49 |
pgimeno |
added a commit (aesthetic) to https://codeberg.org/pgimeno/minetest/pulls/1 |
| 23:10 |
|
Seirdy joined #minetest-dev |
