Minetest logo

IRC log for #minetest-dev, 2021-04-03

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext