Time  Nick             Message
00:28 MTDiscord        <Warr1024> A confirmation dialog would be a nice feature to offer users, but don't make it mandatory.  Anyone who already has an external confirmation/selection process is going to be annoyed.
00:29 MTDiscord        <Warr1024> A lot of apps already have undisablable confirmation dialogs, don't be part of the problem.
00:37 rubenwardy       there could be a setting to turn it off
00:37 v-rob            With appropriate dire warnings
00:37 rubenwardy       the problem is that you can't otherwise preview the URL before opening it
00:38 MTDiscord        <Warr1024> Hidden settings to turn it off would be fine, yeah, no need to advertise it...
00:39 MTDiscord        <Warr1024> I preview URLs in the program I have registered as my "browser" before picking which browser to send it to.
00:39 v-rob            Out of curiosity, why do you use multiple browsers?
01:12 rubenwardy       you're not an average user
01:12 v-rob            Me or him?
01:18 MTDiscord        <Warr1024> If I were an average user I probably wouldn't be a Minetest user either.
01:27 Pexin            most users just have a single default browser. anyway, how extensive are the formspec proposals? specifically, would tooltip popup text be feasible?
01:28 Pexin            actually, a popup confirmation box wouldnt necessarily be very intrusive if positioned in a smart way
02:12 v-rob            Success! I have fixed the source of the setViewPort bug in Irrlicht in irr#41! Now #10801 can start moving again
02:12 ShadowBot        https://github.com/minetest/minetest/issues/10801 -- Add CSM 2D Drawing API by v-rob
02:12 ShadowBot        https://github.com/minetest/irrlicht/issues/41 -- Fix `getViewPort` returning incorrect results by v-rob
02:13 v-rob            I would appreciate it if someone could review the Irrlicht PR. It's pretty simple.
02:40 v-rob            Also, Irrlicht is a liar: irr#42
02:40 ShadowBot        https://github.com/minetest/irrlicht/issues/42 -- Fix incorrect documentation on `setRenderTarget(Ex)` by v-rob
08:13 VanessaE         something's gotta be done about how lagy the crack animation when I'm using HDX.
08:14 VanessaE         this is right after restart, I tried to dig some grass:
08:14 VanessaE         https://imgur.com/4dycFe6.png
08:15 VanessaE         this has been an ongoing problem for all of HDX's existence, so a number of year, but this is the first time trying to dig something actually triggered an error message
08:15 VanessaE         years*
08:15 VanessaE         I'm pretty sure I already filed an issue ages ago, but damned if I can remember.
08:38 VanessaE         laggy*
08:40 VanessaE         and by that I mean, start to dig and it isn't dig-and-gone.. it's more like:  d....hang...i...hang....i...hang....i...hang..ig!-and-gone-and-gone (i.e. it will sometimes insta-dig one or two mode nodes)
08:41 VanessaE         more*
09:41 celeron55        hecks, my man
09:41 hecks            hi =]
09:41 hecks            bad times are upon us...
09:41 celeron55        i was surprised you didn't rip liso's shadows apart more than you did
09:42 hecks            well, i simply wasn't around for the PR, I was busy
09:42 hecks            and I've already got enough of a reputation of being literally Hitler for criticizing this feature
09:42 celeron55        not that i particularly like them either, i think we might need more map renderers
09:42 hecks            so I must be careful
09:42 hecks            but the dismissive attitude of the maintainers is what bothers me the most
09:42 celeron55        one for toasters and one for stuff with some kind of performance
09:44 celeron55        what do you think of the irrlicht fork
09:44 hecks            we already have a toaster renderer technically, the no-shaders mode but
09:44 hecks            well the fork is a step in the right direction, it lets us fix some issues
09:44 hecks            I need to migrate the EJUOR_CONTROL bone fix when I get the time
09:44 celeron55        the fork is a bit of a "if only we had time" thing
09:44 hecks            although
09:45 hecks            the fork should be a stepping stone to divorcing irrlich entirely, there's no reason to layer one engine on top of another
09:45 hecks            irrlicht's bad design is part of the everyday tech debt you have to deal with when fixing things, I'm dealing with SMaterial issues right now for instance
09:45 hecks            and might do a shader system to replace it
09:45 hecks            one compatible with rawdogging OpenGL if you ever decide to go that route
09:46 hecks            anyway, this isn't good: https://a.uguu.se/exKcC7M3IuFt_after.png
09:46 hecks            can I enlist your moral support in this issue?
09:47 hecks            the maintainers, all due respect to them, keep breaking my upstream and it's been very stressful to deal with
09:47 celeron55        well again shadows are a stylistical feature and i think games should have control over those
09:48 hecks            yup
09:48 hecks            no engine ever leaves this up to the end user, it's always something the developer has to expose first
09:48 hecks            and it just so happens that in minetest, the game is the server
09:48 kilbith          sfan5: I recommend to go easy on hecks. this tone may be unbearable sometimes but they have a lot to bring to MT
09:49 hecks            there's no need to go easy on me as in being overly polite, i don't require that of anyone ;]
09:49 hecks            but I wish people actually listened when I point out problems
09:49 hecks            cause I'm often the only one doing anything complex enough to expose said problems
09:49 celeron55        kilbith: that's almost parodic coming from yourself
09:50 hecks            minetest_game doesn't look much worse with shadows because the visuals are too abstract for that to matter
09:50 kilbith          celeron55: because I find myself in hecks somehow and I know how he may feel
09:50 hecks            there are no soft normals on meshes or anything that could produce those artifacts
09:51 hecks            my plan is to make a game that only requires the vanilla Minetest client to run, without the need to install anything
09:52 hecks            this can promote MT as a platform and it also frees me from burdens of distributing things
09:52 celeron55        i have a plan like that too, the likelihood of me finding time for it within other projects sometime is about 20%
09:53 hecks            I ideally need some sort of covenant with the maintainers that they will not spill bugs all over it, but they just keep doing it
09:54 hecks            so if you could at least use your clout as the first developer to nicely ask them to start considering it, I'd be grateful
09:55 hecks            My intention is not to block any new features or graphical experiments, I just need a safety valve on those
09:55 sfan5            we do (and have for a long time) needed a definition of what engine actually means
09:55 hecks            well why not ask the guy who's been using a lot of engines in his life? =]
09:55 sfan5            currently it's stuck in an undefined place between "you can make Minecraft clones" and "you can make anything you want"
09:55 hecks            it's like
09:55 hecks            following my advice will not make MT any worse, quite the opposite
09:56 hecks            anything I ask for is leaning towards supporting everyone's cases
09:56 sfan5            nobody says that, hopefully
09:56 hecks            hopefully, but I sense some paranoia that I want to take people's features away, or something
09:56 hecks            when all I ask for is an option that's present in every engine I've been dealing with to date
09:57 hecks            Unity lets you just make a game that doesn't use shadows, and that's a valid choice - the more cartoony an art style is, the more difficult it is to make it work with dynamic features
09:57 hecks            I'm not even opposed to shadows per se, but I would require server-sent-shaders and possibly SSCSM to even consider it - in short, I'd be implementing them myself
09:58 hecks            that and I think shadow volumes like Doom 3 would look lovely compared to this
09:58 kilbith          that's what I recommend to Liso
09:59 kilbith          recommended *
09:59 hecks            If shadow volumes aren't feasible for some reason, then high-res unfiltered shadows would at least look similar
09:59 hecks            I got an almost acceptable result with those, but sadly Z precision and resolution were very lacking and I can't roll with that
10:00 kilbith          aren't shadow volumes more computationally expensive than shadowmapping?
10:00 hecks            it's a different kind of cost
10:01 hecks            it's a CPU cost of extruding meshes, but sampling is easier, and no shadowmap render targets are used
10:13 hecks            so yeah uh. stop breaking my stuff? thanks. https://a.uguu.se/WS7e5GmEzsKh_monch.png
10:15 pgimeno          what are we looking there?
10:16 hecks            nothing, just the game looking as it ought to
10:16 pgimeno          ah
10:16 hecks            as opposed to this https://a.uguu.se/xTLnFFagF6JL_after.png
10:17 kilbith          interestingly your screens are still 4:3
10:17 hecks            small side monitor...
10:18 hecks            but for UI I use a reference resolution of 1280x720
10:18 pgimeno          FWIW I think the request to have the server limit the client features is necessary, and not new. Fly, run, minimap, debug are all server-limitable.
10:19 hecks            also FOV
10:19 pgimeno          I guess that the argument here is that shadows are not a cheat, therefore there's no priority for it.
10:19 hecks            no, they only make everything look like a nightmare and make the game go from 70 to 17 fps
10:20 hecks            there isn't even a way to control casting/receiving behavior yet so have fun with FX like fire casting shadows...
10:25 pgimeno          OTOH I always dreamt with something like this for Minetest: http://www.formauri.es/personal/pgimeno/temp/Minecraft-shader_00235143.jpg
10:25 pgimeno          even if only to take pictures
10:25 hecks            that looks like SSAO and actual tonemapping (not the weird LDR kind we do)
10:26 hecks            I also see some DOF
10:27 pgimeno          the DOF isn't called for in my opinion
10:30 hecks            none of it is called for in my opinion =] it's a block game...
10:31 celeron55        sharp blue shadows, yellow light, tone mapping to make a bit of an overexposure look to the light and SSAO to make variation to the shadows
10:31 hecks            the blueness of the shadows is from the color grading / tonemapping curve
10:31 hecks            using different black and white points or gamma for different color channels
10:32 celeron55        mapped as darker = bluer?
10:32 hecks            let's see, to make bluer shadows you uh....
10:32 kilbith          all of that isn't difficult to reach - it just needs a proper postprocessing framework
10:32 hecks            I think you raise the black point of R and G?
10:32 celeron55        obviously
10:32 hecks            there was a server sent shaders PR... it went to rot in hell
10:32 celeron55        that kind of tonemapping wouldn't hurt
10:32 hecks            there was also a postprocessing stack PR
10:33 pgimeno          I mean, it doesn't contribute much, maybe except the sensation to be a miniature
10:33 kilbith          there was at least 3 different ones
10:33 hecks            yeah tonemapping should be applied as a screen effect, putting it into the fragment shader was a mistake and we ought to delete that
10:33 kilbith          all aborted
10:33 hecks            how come things like that are aborted but this half finished shadow mapper wasn't...
10:33 celeron55        i don't even recall a postprocessing stack PR, probably was busy at the time doing something else... eh, like usual
10:33 hecks            I'd gladly take a half finished shader API "so that we can improve it later" over this
10:34 hecks            someone did that a couple years back
10:34 celeron55        inb4 fist comment to it is from myself
10:34 celeron55        first*
10:34 hecks            =]
10:34 hecks            anyway this shadows PR also gave us some tech debt
10:35 hecks            we now urgently need shader variants in order to control it, this should've been Liso's job but I bet he'd have some choice words about me for this as well
10:35 celeron55        my only personal issue with these shadows is they're too slow for my haswell integrated graphics and my nvidia card doesn't work
10:35 celeron55        the lowest setting works and looks like garbage
10:35 celeron55        but whatever, i run weird settings anyway
10:36 hecks            something is wrong with the shadow sampling, it's way slower than I've ever seen
10:36 celeron55        in true linux fashion default settings should be unusable and only those who dig themselves up from the settings grave are worthy of using the product
10:36 hecks            normally I've never had problems with like 3x3 or 5x5 PCF but somehow this implementation sucks on anything other than sharp hard shadows
10:37 hecks            celeron55: cool but the game developer should also have this way out
10:37 hecks            I'm fine with everyone else's stuff looking like crap if they don't read the manual, but keep me out of it =]
10:38 hecks            either way I've been a little busy https://paste.uguu.se/?612aadce1e3503bd#BM4hAL4wTkXQA5Tc89iFthuYJz72dMRY8NV5jTBhnxd
10:38 hecks            but before I do this I'd appreciate a resolution on this... organizational issue
10:39 hecks            I'll clean up after Liso and continue contributing if I can get some sort of agreement that this will never happen again
10:40 celeron55        i think the only way that's possible is you make all the requested features so that others can't make them badly
10:42 celeron55        i don't think we even have a document stating what things are subject to change and what things are not
10:42 celeron55        so we can't add visual style of games to it
10:43 celeron55        i'm certain there are two camps regarding to graphics
10:43 hecks            can't you help me in any way here
10:44 celeron55        one is what you represent, those who think games should decide what they look like
10:45 celeron55        the other one is what i think is actually more prevalent, those who think the engine is like a viewer that you can adjust which which you view the world and whatever content is in it
10:45 celeron55        the same camps apply to for example web browsers
10:45 hecks            well, browsers are a little different
10:46 hecks            and I cannot stop anyone from forcing shadows on with an engine edit even after a fix
10:46 kilbith          and then there is the one who ultimately decide between these two camps...
10:46 hecks            I just don't want to make it that easy for the user to shoot himself in the foot
10:47 hecks            also if I'm forced to make all the requested features so that nobody else breaks it, well, we're back to battered wife mode
10:47 hecks            I have other things to do as well...
10:49 celeron55        what i'd like to write down is "games should be able to define what they look like in every aspect and the player should be able to easily make them look the way they want to"
10:49 celeron55        however i don't have a place to put this where people would read it and care about it
10:49 celeron55        umm
10:50 hecks            that's a bit ambiguous, it doesn't define anything at all almost
10:50 celeron55        "games should be able to define what they look like in every aspect and the player should be able to easily make games look the way the games want to look like"
10:50 hecks            how about simply
10:50 celeron55        well it just efficiently takes into account the fact that the user will probably always be able to force all kinds of settings if they want to
10:51 hecks            well I don't have a problem with engine edits, but
10:51 celeron55        they just need to be aware of when they've done it
10:51 hecks            https://a.uguu.se/nt1esNVwuEd7_after.png you know...
10:51 hecks            also consider that most users are idiots and they'll blame the wrong person
10:52 celeron55        well okay, tell me what you would write
10:52 hecks            "visual features significantly affecting a game's artwork should always be controllable by the server"
10:52 celeron55        be the CEO and we'll look at how many start laughing
10:53 hecks            that means a feature like shadows is gated with an AND gate, it must be enabled on both the client and the server
10:54 hecks            if you make no concessions for content creators, nobody will want to make anything nice in this
10:55 celeron55        a feature then should be defined so that always a change towards configurability adds a feature, i.e. if something has been hardcoded and is removed, then removing it is a feature and hardcoding is the default; if something didn't exist then the feature obvious
10:56 celeron55        is obvious*
10:56 celeron55        well, actually no
10:56 hecks            that was a bit confusing
10:56 celeron55        that doesn't work right either
10:57 hecks            the expectation should be that existing content can be presented the way it was made
10:57 hecks            I started making this in 0.4, which had no gouraud shading or shadows
10:57 hecks            literally the first thing I did was import a model and try to probe the capabilities of the engine to see what I have to work with
10:57 hecks            and pulling this featureset from under me now isn't fair
10:59 celeron55        well then it should be defined exactly so: "development should be made so that existing content doesn't change functionally or (emphasis) visually"
10:59 celeron55        the "functionally" part has always been followed... mostly
11:00 celeron55        the problem there too is, stuff happens and some interfaces and settings have been so stupid nobody wanted to see them ever again
11:00 hecks            well in case something is so terrible that nobody wants it, like the auto normal maps, delete it
11:00 hecks            the test should be "will anybody miss this"
11:00 pgimeno          as a user, I would like the possibility of forcing shadows on even in games that want them off
11:00 celeron55        well in case of shadows, somebody could think nobody would miss not having shadows
11:01 celeron55        and somebody probably thought so
11:01 pgimeno          the settings should be something like: off, on, force off, force on; and while in off/on, the server has control over that
11:01 hecks            wellll
11:01 hecks            that brings us back to the point, why do you even want to do this
11:02 hecks            what's so great about this https://a.uguu.se/ho20HHpzSdMB_after.png
11:02 celeron55        personally, i don't care, but i think what people are thinking is http://www.formauri.es/personal/pgimeno/temp/Minecraft-shader_00235143.jpg
11:02 celeron55        and there's a desire to make that possible
11:02 hecks            well yeah, except that's not what we got here
11:02 pgimeno          hecks: I may want to take a picture with shadows of a part of the game that doesn't include a close-up of the character
11:02 hecks            and I think even if you put my artwork in that renderer, it wouldn't look good
11:03 hecks            pgimeno: okay then, but bury this deep in the .conf
11:04 celeron55        i think we need to review the current game settings model
11:04 celeron55        actually
11:04 hecks            that is true, some settings live in the wrong place
11:04 celeron55        it's probably wrong and useless
11:04 celeron55        not even looking at it
11:04 hecks            or shouldn't be settings, or should be API instead of settings
11:05 hecks            what do you mean by useless, like
11:05 hecks            the per-game section of .conf?
11:06 celeron55        actually, let's go through a thing first
11:06 hecks            uh huh?
11:07 celeron55        no games had shadows until this point, and then shadows were added. in the model you suggest no games would now have shadows even while they were added, while i guess 90% of them want shadows and 10% don't want
11:07 hecks            uhhh I suggest something different, like
11:07 celeron55        are you still saying the default "game setting" for having shadows should be false?
11:07 hecks            I'm okay having to add a few lines of code to suppress it on my end
11:07 hecks            it's fine if it's all on by default
11:07 celeron55        or are you saying the default game setting could be true, but the client would follow the server
11:08 hecks            it's more like
11:08 hecks            by default the game doesn't care (I'd rather have this be a matter of lua scripts rather than server .conf)
11:08 hecks            and so all games get the new feature by default
11:08 celeron55        (i agree game settings should be a lua interface)
11:09 hecks            I mean just for the reason that
11:09 pgimeno          again, the setting should be (functionally) like: on / off / force on / force off - where on could be the default, but on/off is overridable by the server (but not force on/force off)
11:09 hecks            this is a game's decision and so it should come with an installed game too without extra config
11:09 hecks            anyway
11:10 hecks            everything is on by default, and a game gets to call some sort of API to forbid it
11:10 hecks            anything is fine as long as it can get the desired effect
11:10 hecks            like
11:10 celeron55        well i guess game could set a setting like "legacy mode", which would cause the engine to not automatically enable any new features
11:10 hecks            if I get a sun/moon flag to stop rendering shadows, that's an acceptable workaround and I'll stop bitching about it
11:10 celeron55        and the game would have to exclusively enable new features
11:10 hecks            just like I'm fine with setting shaded=false; on all CAOs
11:10 celeron55        that would make it future proof
11:10 celeron55        or i guess "compatibility mode"
11:10 hecks            it's okay to expect the developer to follow the git repo and keep up with this
11:11 hecks            as long as there's some opt-out that can be toggled at minimal cost
11:11 hecks            and by that I mean, very little code to support it and no unreasonable bandwidth demand on the server
11:12 hecks            so let's say sending each player a packet on login to say that this game shouldn't be rendered with shadows is an acceptable burden
11:12 hecks            while let's say that using shadow caster/receiver flags on every material in the game to suppress it would not
11:13 celeron55        so actually what's needed is not "existing content can be presented the way it was made" as in it automatically would be, but as in the server can make clients show existing content as it was made (functionally or visually), assuming the user hasn't forced some settings and having been bashed for it by the engine
11:13 hecks            and in the case of something like shadows, the performance cost must be entirely mitigated (which is why I have to do this variant thing now...)
11:13 hecks            yeah that's about it
11:13 hecks            as long as a game is maintained, it should be able to not have to deal with forced art style changes like this
11:13 hecks            but it's fine to require the developer to add a line here and there
11:14 hecks            this is all that this drama has been about, I just asked Liso for this stupid trivial opt-out feature
11:14 hecks            and I want any nontrivial feature like this to come with that
11:16 celeron55        "as long as a game is maintained, it should be able to maintain its function and art style without players having to change settings"
11:16 hecks            yes
11:16 hecks            and for the long term, as an ideal
11:16 celeron55        that took a moment to type
11:16 hecks            "the game server should ideally not have to beg the player to change their config"
11:17 hecks            this is for any future de-hardcoding of things like camera control
11:17 celeron55        there's the guide, now where to put it
11:18 hecks            your roadmap thread that everyone links to, dev wiki, the recently added roadmap thing
11:18 celeron55        MT does have a long history of compatibility with old content and it is one of its selling points so this does make sense and not really a new thing
11:18 celeron55        *isn't really a new thing
11:19 celeron55        the art style part is something nobody had really cared about, it's a new concept around here that somebody is trying to have an art style
11:20 celeron55        i guess i said that already
11:20 hecks            yes, I'm aware that nobody else has had this sort of requirement
11:20 hecks            at least that we know of
11:21 celeron55        oh man this devwiki certificate thing too
11:21 hecks            huh? oh yeah
11:22 hecks            let me guess, letsencrypt?
11:22 celeron55        you won't believe how big a project that is, don't ask
11:22 celeron55        you'll lose all hope
11:22 hecks            the uh
11:22 hecks            the dev wiki?
11:22 celeron55        :D
11:22 celeron55        let's continue
11:22 hecks            I mean if we have a documentation problem I can start helping out...
11:23 celeron55        i mean the "getting the certificate sorted out" thing
11:24 hecks            haha
11:24 hecks            the wiki could use a cleanup cause at the moment the best source of knowledge about the code is groveling it manually
11:24 hecks            or maybe the documentation should just be in the code, that's easier to maintain
11:28 celeron55        oh yes we have this now https://github.com/minetest/minetest/blob/master/.github/CONTRIBUTING.md
11:28 celeron55        of course it's completely impossible to find being in that silly .github subdirectory
11:29 celeron55        and https://github.com/minetest/minetest/blob/master/doc/direction.md
11:34 hecks            right, even better
11:36 celeron55        my roadmap is a museum of sorts
11:37 celeron55        it's not necessarily outdated, it's like electric cards in the 60s
11:37 celeron55        the time will come
11:37 celeron55        lol
11:37 celeron55        eh
11:37 celeron55        electric cars*
11:39 celeron55        the formatting was messed up in some forum update too... i'll at least fix  that
11:46 MTDiscord        <Liso> I was reading the conversation and I didn't want to get into, I've said it before I'm not here to fight, but the personal references force me to do it.  Just remove the shadows PR if you want, I'm not going to get mad at all and there is a lot of work to do. And I'm nobody to say anything else about this behavior, so that's all I'm going to say.
11:46 hecks            it's not wrong, we just need a complete rewrite and cold fusion before we even begin with most of that =]
11:58 celeron55        in the end all it's really missing is just an on/off switch in the right place
11:58 hecks            yes, though it'll be a bitch to add now
11:58 hecks            I already wrote this off switch actually and it works but
11:59 hecks            now I've got shaders trying to use nonexistent shadows and still consuming fill - and it turns out, all this stuff is decided in client init
11:59 hecks            and then worse, shader IDs are propagated by value to all new objects on creation with no anticipation that the GL program might ever want to change
11:59 VanessaE         Liso: no, it's got its warts but its better to have it than not.  it just needs some TLC.
11:59 hecks            so the whole shader API must be replaced with one that supports variants, and works with references, not by value
12:02 MTDiscord        <Warr1024> I think the shadow merge as it is already is a net positive, even though I maintain a game that can't benefit from it in its current form and I had to disable it server-side.  If we wait until things are perfect before adding them, they'll never get tested in the field and thus never can actually improve, and we'll just have nothing.
12:04 MTDiscord        <Liso> probably just force the setting, like server send a ¨force_enable_shadows: false¨ and just disable the setting for that game, could be a good option and can work with all the settings ( like tonemapping, shaders, etc)
12:04 celeron55        https://forum.minetest.net/viewtopic.php?p=396525#p396525
12:04 celeron55        surprising how many roadmap items were done in a way or another
12:05 hecks            ah, VAEs
12:05 hecks            I'll want VAEs at some point so there's a nonzero chance of this happening... someday
12:05 hecks            cause I want sky pirate fights on airships and whatnot
12:05 MTDiscord        <Warr1024> I have an 8-year-old business-grade laptop (not a gaming rig) with an Ivy Bridge iGPU and shadows run perfectly fine for me at the lower quality end, don't have a measurable drop on my FPS, look as good as anything else in the engine, and I don't even have to bother turning them off when playing a game that doesn't utilize them.
12:05 celeron55        yeah... yeah
12:05 celeron55        we'll see
12:05 hecks            >Measure and fix rendering bottlenecks
12:05 hecks            also on my list
12:05 celeron55        i'd make a hacky implementation if i knew i could force it upstream
12:06 celeron55        but i know i really can't
12:06 hecks            actually the measurement is done, I know where the bottlenecks are
12:06 hecks            well, some really dedicated people have made hacky implementations in lua
12:06 VanessaE         apart from the judder/stutter problem, shadows work mostly fine for me too, once I landed on some good settings.
12:06 hecks            but I think MT needs a concept of multiple worlds in a client environment for VAEs to work elegantly
12:07 hecks            VanessaE: Most models used in Minetest are flatshaded, with hard edges and flat faces - I use a model with round features and few hard edges, which exposes a lot of problems
12:07 celeron55        yeah, i'm not willing to implement multiple worlds
12:07 celeron55        they would require their own lua environments too
12:08 celeron55        what i would be willing to do is allocate a node volume from the main world to be used as VAE content
12:08 celeron55        so that the single signed 16-bit x,y,z space remains
12:08 celeron55        and mods are happy, and the network protocol is happy, everything is happy
12:08 celeron55        but
12:08 hecks            but there isn't a whole lot of off-map space to use for this
12:08 celeron55        with multiple lua environments mods would be happy, just make everything else happy too
12:08 hecks            and it's limited, you can run out of it
12:09 MTDiscord        <Warr1024> VanessaE, even with well-tuned settings you didn't manage to get rid of the judder?  That's a shame ... also having a conversation involving abbreviations for Voxel Area Entities while VanessaE is present is confusing.
12:09 celeron55        you could even partition the main world into multiple server-side lua environments to use multithreading
12:09 hecks            hey, I didn't even think of that
12:09 celeron55        the scale (at least in potential resource use) could get almost MMORPG-like
12:09 VanessaE         Warr: nope, the judder is very much still there.
12:10 hecks            also, multiple worlds solves a lot of other problems like... multiple worlds =] and possibly extending the map boundary
12:10 VanessaE         but Liso said he has an idea why
12:10 celeron55        a 32-core server with a terabyte or RAM? no problem
12:10 celeron55        just mix in the users
12:10 hecks            you could designate the current MT concept of a "world" as a superchunk with its own execution environment
12:11 hecks            just have a way to dock those worlds together seamlessly, possibly by duplicating entities at boundaries
12:11 hecks            so an entity is "visible" to both worlds temporarily
12:11 celeron55        i'll add this to my roadmap that i'll never do but it sounds cool
12:11 hecks            look, if I can get mibi off the ground, this will become realistic
12:15 MTDiscord        <Liso> Yes, working on it
12:16 MTDiscord        <Warr1024> multi-world seems like it could be implemented a lot more simply with just multiple servers and the ability for a server to redirect a client to log into a different server with the same credentials...
12:16 celeron55        but it's the most boring VAE usecase
12:17 hecks            well of course, movable ships are a part of this
12:17 hecks            also if you have multiple world-sized VAEs available, and a bigger coordinate space to work with, you can have the space game you've always wanted
12:17 celeron55        really i'm wondering, why nobody has made the voxel MMORPG with movable ships open source project
12:18 celeron55        or engine
12:18 hecks            it's hard!
12:18 celeron55        nah
12:18 hecks            we're the ones holding this bag
12:18 celeron55        it's not hard
12:18 celeron55        just do it shitty enough
12:18 celeron55        my motto
12:19 hecks            :o
12:19 celeron55        can somebody come mow my lawn? i could write cool ideas on my roadmap instead
12:19 hecks            get a goat
12:19 celeron55        it'd die when winter comes
12:20 freshreplicant[m Veloren has airships, but it's a pretty different beast to MT.
12:20 celeron55        not very nice
12:20 hecks            oh right uhhhh
12:20 hecks            get one of those fluffy cows
12:20 hecks            that wouldn't die
12:21 hecks            you made me briefly wonder why hasn't anyone made a lawn mowing roomba but then realize that putting that on a stupid robot is not a brilliant idea
12:21 celeron55        umm
12:21 celeron55        well there are lawn mowing robots
12:22 celeron55        not very cheap if you have a big lawn but don't have to waste the time then
12:22 hecks            uhhhhhhh yeah
12:22 celeron55        if there was an open source one maybe i'd get one
12:22 hecks            knowing the quality of software around the world in general, you won't catch me going anywhere near one of those
12:22 celeron55        the proprietary crap with android apps and other things make me puke
12:23 hecks            just in case I become a floating point rounding error statistic
12:24 celeron55        that being said, why isn't there a minetest mod where grass grows stupidly high and annoying if you don't mow it every week
12:24 celeron55        and mosquitoes live in the long grass
12:24 hecks            yeah actually why is grass height randomized and not growing
12:25 VanessaE         there was.
12:26 VanessaE         I had junglegrass mod that would spawn it, make it spread kinda like flowers do now, and it would grow in height over time.  if you didn't "mow the lawn" now and then, well, you get the idea.
12:26 VanessaE         it ... wasn't well received.
12:26 hecks            great, now we can have homeowners associations on minetest servers
12:26 hecks            trim your lawn or ELSE
12:27 VanessaE         ha.
12:27 hecks            I've already seen rental flats in minetest... nothing would surprise me
12:27 hecks            MT servers are depressingly realistic
12:28 hecks            you start as a broke hobo in a gigantic city where everything is owned by someone and you can't even pilfer an apple to save your life
12:31 celeron55        well at least there's no lawn anywhere to be seen
12:32 VanessaE         (but then again, that was before MT has its own tall grasses, maybe they'd work-out better, considering junglegrass is huge by comparison)
12:32 celeron55        it for sure is funny how, when given an imaginary world where you can do anything, most people start copying the real world to the most depressing details
12:33 VanessaE         I think that's a matter of control.
12:33 hecks            this is why I sympathize with griefers
12:33 VanessaE         you build a realistic-ish world, but doing things in-game in ways you can't or are forbidden from in the real world.
12:33 hecks            don't leave me unattended with a lava bucket next to a mall... just in case
12:34 celeron55        griefers completely understand the situation, and ruin it for all the others
12:34 celeron55        it's an interesting dynamic
12:34 hecks            I just actually call them mall servers, that's what they feel like
12:34 hecks            only Just Test got it right because the city was all there was
12:34 hecks            and it felt more like a Fallout kind of game
12:35 hecks            JT also more importantly used vending machines and had an economy, based on heavy scarcity
12:35 hecks            it wasn't that easy to just claim a big patch of wilderness
12:35 hecks            and not as desirable
12:36 hecks            any of you played Gundul's 3xile server?
12:36 hecks            well crap, we're kind of in the wrong channel for this, sorry
12:37 celeron55        i mostly used my editor for ruining the game for people rather than actually opening the game and playing
12:40 celeron55        i think i should run a devs-only minetest server
12:41 celeron55        altough, i would expect nobody to be there
12:41 hecks            i would
12:42 hecks            until i get banned for nsfw pixel art or something
12:42 celeron55        it would have no rules, other than your code being included in what's running
12:43 celeron55        i mean, the code of the persons on the invitation list
12:43 hecks            uhhh um
12:43 hecks            at least one commit in the repo?
12:43 hecks            and pure anarchy otherwise? excellent :DDD
12:43 hecks            hide your buckets
12:44 celeron55        i think anarchy is the only way to go for something i run
12:44 celeron55        by running it, i have the biggest hammers
12:44 hecks            what if we ran another exile server... but i'd have to ask Gundul for his version
12:44 hecks            he patched that game to sort of work online
12:45 hecks            so what's the link that I have to use next time someone tells me visual breakage is not a bug?
12:54 pgimeno          <celeron55> [multiple worlds] would require their own lua environments too
12:54 pgimeno          what problem is that intended to solve?
12:54 hecks            the API assumes a single world
12:54 hecks            it's best to leave it that way
12:54 rubywarden       I can see that causing issues
12:54 rubywarden       For example, what about more global state like chat and player connections
12:55 hecks            that doesn't really depend on a world, does it?
12:55 rubywarden       I think doing something like virtual mapping of memory would work better
12:55 rubywarden       Where different worlds occupy different coordinate spaces
12:55 hecks            sparse worlds?
12:55 hecks            but I see no reason to like
12:55 hecks            pin a VAE ship in the space of some other world
12:56 hecks            this offers no utility other than not needing a new VM environment, however
12:56 hecks            the separate VM thing is a cool opportunity to use more CPUs on a server
12:56 hecks            entities would simply be visible to all worlds that they are reasonably within the range of
12:57 celeron55        https://forum.minetest.net/viewtopic.php?p=396527#p396527
12:57 hecks            as for docking, I think that a docked VAE ship is best handled by temporarily blitting it to the world it just docked into
12:57 hecks            avoiding all problems
12:58 hecks            celeron55: https://a.uguu.se/RFFBknhFfmZp_3.png
12:58 MTDiscord        <josiah_wi> Small bump for irr#39
12:58 ShadowBot        https://github.com/minetest/irrlicht/issues/39 -- Fix unintentional introduction of public variables by NeroBurner
12:58 celeron55        it's just my roadmap though, anyone is free to call me an idiot and not follow it
12:59 hecks            well
12:59 hecks            it's a step in the right direction
12:59 hecks            people tend to listen to you
13:05 pgimeno          <rubywarden> For example, what about more global state like chat and player connections
13:05 pgimeno          <hecks> that doesn't really depend on a world, does it?  <--- In a way. Imagine worldediting with chat commands. These chat commands need to reach the world being edited, so they need to be broadcast. Also, if each world has its own players, chat needs to be passed from world to world.
13:05 pgimeno          Hm, the second part may not be true.
13:05 hecks            yeah there's stuff like this to solve
13:06 hecks            for legacy purposes I'd just broadcast actions like this to all worlds
13:06 rubenwardy       The only compatible solution here would be to have a chat per world, in which case it could be better to have different servers
13:06 hecks            and allow extra parameters to specify a world
13:06 rubenwardy       Then you end up with duplicate consumption
13:06 rubenwardy       For example, an IRC bridge
13:06 hecks            well chat itself per se has no relation to the voxel map
13:06 hecks            it's a part of the server environment
13:07 hecks            but right, separate VMs would all consume the same message
13:07 hecks            so you'd need like
13:07 hecks            a master VM and map VMs
13:07 celeron55        i'd say it would only go to the world where you are
13:07 hecks            and that's a hell of a restructuring
13:08 celeron55        the mods in the world would be responsible for broadcasting it to other worlds
13:08 celeron55        if the message needs to be
13:08 hecks            well in the case of VAEs, which world are you really in?
13:08 hecks            you're kind of in both temporarily
13:08 celeron55        it doesn't matter, either or
13:08 hecks            your SAO is visible to both, and collides with both
13:08 pgimeno          ugh, so local world mods? like, multiple servers in one?
13:08 hecks            if you shout from a ship, people on the ground ought to hear it
13:08 rubenwardy       I think there's a bit of confusion here with VAEs Vs dimensions
13:08 celeron55        maybe it is displayed to the player whether the player is on the VAE or the static world
13:09 hecks            well that's because the discussion started with the two sharing functionality
13:09 celeron55        so that the player knows which worlds' worldedit they're commanding
13:09 hecks            VAEs with their own maps would be "clean" for lack of a better word
13:09 hecks            as opposed to allocating them dynamically off map
13:09 hecks            but okay, I kinda see the merit of like
13:10 hecks            a unified coordinate space, but I'd rather introduce a W coordinate for this purpose
13:10 hecks            where w is the world index
13:10 hecks            if w=0, we're referring to the "base world"
13:10 hecks            but at the same time we are not playing with fire by pretending that VAEs or dimensions are somewhere off map
13:11 hecks            even though this is how we're hacking dimensions and instances right now
13:12 pgimeno          I can understand having multiple worlds being like having multiple servers except maybe sharing the network, where the benefit over running multiple servers would be the inter-thread communication speed. But writing a game for multiple servers would be N*trouble for game creators, where N is the number of worlds (double the trouble for two worlds like nether and normal)
13:13 hecks            I simply see two constraints on this design
13:14 hecks            one is that mods must still work, another is that the VAE and dimension implementation shouldn't be too hacky
13:14 hecks            separate voxel maps in memory and a new W coordinate in positions seems to satisfy this?
13:15 hecks            the question of entities remains but I think the entity would just be in superposition over several world layers
13:15 hecks            like
13:15 celeron55        the lua api is completely incompatible with any added coordinates, even if the engine supported both coordinate formats (assuming whatever for when there's no fourth coordinate), mods provide interfaces to other mods that will drop the 4th coordinate when they're trying to use it and where would the location even point to when the 4th coordinate is missing
13:15 celeron55        basically there would have to be a new generation of mods (or updated old ones) that support the 4th coordinate, and if you use multiple worlds or VAEs, you couldn't use any non-updated mods
13:16 pgimeno          I was thinking more about minetest.setWorld(w) to work on a different world, and entity:moveToWorld(w) to move entities between worlds
13:16 hecks            in one way or another mods will have to start supporting VAEs
13:16 hecks            I don't think this can be done without *any* upgrades
13:16 hecks            just the entity superposition is puzzling enough
13:16 celeron55        well, that's  what the 4th coordinate update problem looks like
13:16 hecks            say you have a ship that's allocated somewhere off-map
13:17 hecks            and you want to compute a distance between one of its nodes and a player that's on the ship
13:17 hecks            and maybe another SAO that's off the ship
13:17 celeron55        the "multiple lua environments" update problem looks different, basically some mods have to start supporting inter-environment communication with other instances of the mod
13:17 celeron55        but not all mods, only those that want to have global effects
13:17 celeron55        many mods are local
13:17 hecks            the problem wardy pointed out is pretty serious
13:18 hecks            you need a "master VM" for certain global things
13:18 celeron55        yeah, or maybe just assign one world as such
13:18 hecks            so basically
13:19 hecks            dimension/VAE api comes with a new VM per instance and it's stated with big red letters
13:19 celeron55        i've done a segmented MMORPG that's quite like this, it's not really a problem
13:19 hecks            and if you want to support it, you must deal with that
13:19 celeron55        of course nothing came of it but it worked
13:19 hecks            "i've done an MMORPG, nothing came of it but it worked"
13:19 hecks            hey that's my line
13:19 celeron55        altough, it did have the master server
13:19 celeron55        not a master world
13:19 rubenwardy       You can't add a 4th coordinate, which is why my suggestion is to use virtual mapping
13:20 hecks            we (the server crew) considered server side engine modifications to utilize all the spare computer junk we've got
13:20 hecks            so maybe we'll do some more R&D on this
13:24 celeron55        "You can't add a 4th coordinate" is wrong, i just described the problem it creates, it's not that serious if we look at the long term. it's just really annoying in the short term
13:24 rubenwardy       virtual coordinate mapping would map multiple worlds onto the same coordinate system
13:25 rubenwardy       I'm aware
13:25 hecks            it's just two versions of the same problem
13:25 hecks            or rather moving the problem
13:25 hecks            offworld coordinates could be handled by mods without being dropped but
13:25 celeron55        the main thing that will make this choice is whether the CPU load split is desired or not
13:25 hecks            they would no longer correspond to valid XYZ coordinates for things like distance calculations
13:26 hecks            meanwhile with a W coordinate, the XYZ space calculations for things like entity positions would always be consistent
13:26 celeron55        whatever the answer to that is already forces our hand
13:26 hecks            or at least sane
13:26 hecks            I mean in the end, if a mod doesn't support this it's hosed anyway
13:26 hecks            no matter which way it's implemented
13:27 rubenwardy       you could do both - virtual mapping for a legacy api, 4th coord for a new api
13:27 hecks            VAEs will need extra work from modders to support
13:27 hecks            what purpose does the virtual mapping provide though, other than maybe not losing the W coord in transit
13:27 rubenwardy       it prevents mods from breaking
13:28 rubenwardy       or at least breaking so much
13:28 hecks            won't they still be broken if they don't know how to interpret this strange vector?
13:28 rubenwardy       not in most cases
13:28 celeron55        i guess you could support a 4th coordinate somehow so that when calling a mod, the engine will set a global variable in the lua environment to indicate which 4th coordinate it is in, and any calls back to the engine will assume that 4th coordinate if the 4th coordinate isn't set
13:28 celeron55        i think it would allow compatibility surprisingly far
13:28 rubenwardy       and they'd still be broken with 4th coord and VAEs: as VAEs are freefloating
13:29 hecks            I mean sure, maybe provide pack/unpack functions to map XYZW to XYZ and back when you want to hand this to a legacy mod
13:29 rubenwardy       that's an interesting approach
13:29 hecks            and oh right
13:29 celeron55        i don't want virtual mapping, it's too hacky and it creates persistent problems
13:29 hecks            you can metatable W to the current world ID
13:30 hecks            I still think no matter what happens, VAE support will require explicit work on the modders' part, just because it's such a huge upheaval
13:31 celeron55        i think no matter what happens there will be enough compatibility for someone to install a mod with say a furnace-type thing and it will still work, and anything less complex than that
13:31 celeron55        anything with entities will probably act weird on VAEs
13:31 hecks            ABMs and pipelines will work without any modifications
13:32 hecks            while yeah, any inter-VAE calculations are inherently complicated
13:32 hecks            but, hear me out
13:32 hecks            which is easier, using a VAE's transform matrices to translate between consistent XYZ coords
13:32 rubenwardy       given how the other longterm feature is going (client-side scripting), I have doubts about VAEs ever working
13:32 hecks            or doing the same but with the VAE space offset on top?
13:33 hecks            VAEs aren't a hairy security risk like CSS
13:34 hecks            if nothing else, a W coordinate makes the math easy
13:35 hecks            you're just one matrix mul away from converting a point in one map's space to another's
13:37 hecks            maybe even w isn't necessary, like
13:37 hecks            the coordinates just depend on who's asking
13:39 pgimeno          that's where minetest.setWorld(w) comes into play
13:39 hecks            what you'd need is APIs like
13:40 hecks            ObjectRef:get_world(), ObjectRef:set_world() to set the current reference world for a SAO
13:40 pgimeno          it seems you're ending up at what I suggested :)
13:40 hecks            then, a WorldRef type with
13:41 hecks            WorldRef:translate_coords_from( WorldRef, vec )
13:41 hecks            and translate_coords_to
13:41 hecks            also any world related APIs are now methods of WorldRef
13:41 hecks            WorldRef:get_objects_in_radius
13:42 hecks            and their legacy versions either fall through to world 0 or maybe a "bound" world
13:42 hecks            like GL makes you bind objects
13:44 pgimeno          something like WorldRef:translate_coords_from seems to assume that the other world's coordinates are translatable to this world, I'm also thinking about parallel worlds and I don't see how it would fit in that model
13:45 pgimeno          parallel worlds as in parallel dimensions
13:48 nrz              hecks, i'd be glad to review your PR about your issues, tell me when it's ready :)
13:52 hecks            nrz: uhh what exactly?
13:55 hecks            my "issues" at the moment are: covenant between maintainers and modders to not break visuals, a shader api upgrade, shadows displaying without a source, sky layers API (in that order)
14:01 pgimeno          and no settings API improvements to allow the server to override client settings?
14:01 hecks            not at the moment, this is outside of the scope
14:01 celeron55        that sounds more of a workaround than a design
14:02 hecks            yeah I don't like the "settings negotiation" idea
14:02 hecks            there's nothing wrong with the current PlayerObjectRef apis controlling things
14:02 hecks            that's the preferred mechanism imo
14:03 hecks            anyway I want a quick fix for this incomplete shadows feature and concidentally fixing one bug with it will give me a way out
14:03 hecks            and then the sky layers will give even better control over it
14:04 hecks            by reframing the sun and moon as generic directional light objects and letting you specify if they should cast a shadow
14:04 celeron55        i also like the ObjectRef client control interfaces
14:05 hecks            there's nothing wrong with how fov or other settings are currently limited
14:05 hecks            so for future fixes like camera mode overrides, we can continue doing it
14:05 celeron55        i think i'll mention this in my roadmap
14:05 hecks            reframing this issue as "settings negotiation" misses the point and kinda bureaucratizes it
14:05 hecks            it's a great way to avoid doing it
14:06 celeron55        so that people don't slip into the setting override mess
14:06 hecks            ha
14:06 hecks            could you believe that I've heard a proposal for a built in feature
14:07 pgimeno          uh, I can foresee something like, "for this game I absolutely need shadows"
14:07 hecks            hmmm
14:07 rubenwardy       definitely a bad idea for a game to require shadows, think of the potatoes
14:07 pgimeno          (it's the other side of the "for this game I absolutely need to disable shadows" coin)
14:07 hecks            anyway... where the client receives a pop-up on login saying that the server recommends certain features and whether you'd like to set them that way, someone suggested that, that's pretty upside down
14:08 hecks            a formalization of begging the client to enable something :DDDD
14:08 hecks            but interesting point pgimeno
14:08 nrz              at a point camera should be decoupled from player and handled diferently, this will permit specific animations, imagine you talk to a NPC and the camera front him :)
14:08 pgimeno          rubenwardy: think of it like an example, we're talking about future-proofing
14:09 hecks            a game that uses light and shadow as a mechanic could be able to force shadows on in at least a minimal capacity
14:09 hecks            I will consider that in the sky layers
14:09 hecks            so that shadow=true can also be shadow="force" in this extreme case and the client will attempt to obey (without being too resource intensive hopefully)
14:10 hecks            >imagine you talk to a NPC and the camera front him :)
14:10 hecks            nrz: you can point the player's view direction at an NPC already
14:10 hecks            I tried it and it felt kinda bad
14:13 pgimeno          again, I believe the user needs to have the power to override server-mandated settings, at least those that don't allow cheating, so a force-on/force-off value should be allowed. Maybe force-on/off could only be set in the file, if you want it well hidden.
14:13 celeron55        https://forum.minetest.net/viewtopic.php?p=396527#p396527
14:19 celeron55        we'll see about those force settings when someone starts actually requesting them
14:19 celeron55        it's just a client addition
14:19 celeron55        we need to have these apis and protocols first
14:20 celeron55        yes, i don't count your request "actually requesting" because you haven't even seen the still non-existing system in action
14:24 hecks            pgimeno: I understand the screenshot sentiment but uh
14:24 hecks            it's risky
14:24 hecks            users are stupid and they'll break things and blame it on the wrong people, can this be no more than an obscure .conf setting?
14:26 celeron55        this is free software, we allow people to be stupid if they want to. but that being said an option only available in the file will already allow people to be stupid
14:26 pgimeno          imagine "My client crashes every time shadows are enabled, but the server activates shadows. Can I have some way to disable shadows even if the server wants them on?"
14:26 celeron55        the goal wasn't to force enable shadows, just force disable
14:27 celeron55        we know some clients can't run with shadows anyway
14:27 celeron55        you can even disable shaders in the client if your hardware needs it
14:27 pgimeno          that's very application-specific, I'm thinking about something more general that applies to more settings, and using shadows as an example
14:28 celeron55        well i am proposing not to make anything general
14:28 celeron55        but make everything have a specific api
14:28 celeron55        then you can make them behave exactly in the way that makes sense in each case
14:29 hecks            yup
14:29 pgimeno          that's the philosophy that makes things a mess, if you pardon my bluntness
14:29 hecks            no, there's no need to shoehorn things into config
14:29 hecks            we've already got too many bad things in there as it is
14:29 celeron55        can you describe the mess it would create, in practical terms or as an example
14:30 hecks            and for instance, things like third person camera don't have a .conf entry, would you make one just to fit it into this settings negotiation system? nonsense
14:31 pgimeno          well... we have a FOV API, a sky API, and we want to have a shadow API, instead of having one common API for FOV, sky, and shadow
14:31 hecks            correction, I want to roll shadows into sun/moon which already exists
14:32 hecks            just as an extra flag
14:32 hecks            and then into the generalized "directional skybox sprite object" form once the road is clear
14:32 celeron55        pgimeno: those seem like well organized APIs, unlike a "settings api" which in actuality is all of those
14:32 hecks            you'll be able to flag any skybox object as a light emitter and whether or not it uses shadows
14:33 hecks            nothing wrong with adding more API as long as there's a use for it
14:33 hecks            much better than creating a server-side option for shadows
14:33 hecks            I'm just gonna make shadows go away when there's no sun and moon initially
14:33 pgimeno          I'm not saying they aren't well organized, I'm saying it explodes the number of APIs instead of having a uniform interface for things that boil down to a client setting that the server can manage
14:34 hecks            so that overcast scenes can look right
14:34 pgimeno          as a result, lua_api.txt grows, the number of functions grows, the complexity grows
14:34 hecks            this is a great attitude but just not in this particular case
14:35 hecks            because settings negotiation is the worse approach of the two
14:35 hecks            I will be adding no new functions to fix this
14:35 pgimeno          negotiation? it's easy, server sends the desired setting, if client doesn't have "force" that's the prevalent setting, if client has "force" then the client's choice prevails
14:37 hecks            ok pgimeno, but now a game wants to force it off, it either has to put it in its root folder minetest.conf (a semi obscure feature) or change a .conf entry in init (is that even possible?)
14:37 pgimeno          no, it just has to send the setting on client login
14:37 hecks            all while introducing a new point of failure, the server admin's home folder minetest.conf which may be shared with other server instances
14:38 hecks            also it's inflexible, what if I want to only disable shadows in specific circumstances?
14:38 pgimeno          Settings:set_client_conf_bool('shadows', false)
14:38 hecks            like when the player is underground
14:39 pgimeno          actually, make that player.settings:set_conf_bool('shadows', false)
14:39 pgimeno          the server-sent setting would be run-time only
14:39 pgimeno          it won't be stored
14:39 hecks            this is an abuse of the concept of settings
14:39 hecks            you might as well be using CAO properties as a communication channel for this, and it's used for some things
14:40 MTDiscord        <Warr1024> I would very much like to be able to send at least "advisory" settings to players too.  Disabling shadows is one of those things.  Recommending a higher base display gamma is another.  However, I still want players to be able to override that decision if they really are sure that their settings are right.
14:40 hecks            it just feels filthy
14:40 hecks            also it's not as simple as
14:40 hecks            setting a client setting to toggle shadows, it's not gonna work the way you think it will
14:40 hecks            the client currently decides to create shaders with the shadow feature on init
14:40 hecks            then propagates this particular shader to objects and MapBlockMesh instances
14:41 MTDiscord        <Warr1024> Yes, it'd have to be done only on_join or even prejoin, so the client has some means of being able to interpret the settings before initializing everything
14:41 MTDiscord        <Warr1024> I'd be fine with that kind of limitation
14:41 hecks            so now if you want to support any dynamic toggling of settings like that, upon receiving the packet for this you have to do the exact same things in the client environment as you would for this in API form
14:42 hecks            and it becomes an API by another name
14:42 MTDiscord        <Warr1024> I mean, I've got a minetest.conf in my game and I'd be fine with the settings being absolutely static based on that and being all-or-nothing for all players all the time, i.e. I can live with mod code not being able to be choosy about it.
14:42 pgimeno          ok, there may be settings that can't be changed during play and can only be changed say on preinit, but the idea remains the same
14:42 hecks            it becomes an RPC invoked by setting a boolean... what the hell?
14:42 hecks            you won't even get less lines in lua_api.txt for it
14:42 MTDiscord        <Warr1024> Maybe simpler would be just sending a game/mod's minetest.conf as part of media, so it can be interpreted by the client as part of the init process
14:43 hecks            but what you'll lose is an autogenerated documentation link to this implicit procedure
14:43 hecks            the point of a config is to store permanent settings
14:43 MTDiscord        <Warr1024> One problem is that MT doesn't really handle "layering" configs very well.  There are cases where I'd like to have a system-wide default that's different from MT's built-in defaults for some things, but I'd want to allow server-level or game-level alternative defaults, BUT clients still need the ultimate say.
14:43 hecks            and you want to abuse it to store ephemeral state? to what end
14:43 hecks            with side effects on reception no less
14:44 MTDiscord        <Warr1024> It feels like what we need is something like CSS's !important flag, but I also hate the way CSS does that too...
14:44 hecks            the only reason you might ever want a settings negotiation API is because someone, at some point, made a setting that shouldn't ever have been a setting
14:44 MTDiscord        <Warr1024> Writing these things back to the settings on disk wouldn't make sense, yeah
14:44 hecks            or because the setting's intent is poorly communicated
14:45 pgimeno          hecks: it's working like that in Second Life. I'm not saying it's a particularly well designed client, but the net result works quite well.
14:45 MTDiscord        <Warr1024> I mean there are plenty of settings that shouldn't be settings.  I have to override time_speed, for example, and then that ends up polluting my settings in all worlds that don't override it back.
14:45 hecks            I wouldn't consider Second Life a good engineering example to take inspiration from, just saying
14:45 pgimeno          heh
14:46 hecks            nothing will convince me that this is just an RPC (remote procedure call) invoked in a stupid roundabout way
14:46 MTDiscord        <Warr1024> There are a lot of things in settings that should be stored in the world, not the client.
14:46 hecks            that this isn't*
14:48 hecks            I already imagine it on the binary side, there is this big Game::HandleSettingsChange function with a gigantic switch statement checking for various settings and producing side effects
14:48 hecks            and you've just created a weird RPC mechanism for no reason to do what was best left to individual code paths
14:49 hecks            what's the point of it being a setting if you have to push notifications about it to things, and if you never save it?
14:49 pgimeno          notifications to things?
14:50 hecks            yes, in case you want this to ever work in runtime, you need to propagate the side effect of the change
14:51 pgimeno          we're talking client side effects here, aren't we?
14:51 hecks            I mean this is just a network packet in this weird form
14:51 hecks            yes
14:51 hecks            what's worst, it's a god packet handling several things
14:51 hecks            there's a reason why we even have packet opcodes and don't do a whole lot of subpacketing
14:52 pgimeno          think FOV, FOV is a client setting; regardless of whether it's stored, there's such thing as the current FOV. Changing the current FOV is a change of the setting. You can call it RPC if you want.
14:52 rubenwardy       server-sent settings is a whole bag of worms
14:52 hecks            so it's now ugly both on the API side (setting a keyed bool to actually dispatch an RPC) and on the plumbing side (opaque network protocol, a mini-VM to decode each so-called setting into the relevant procedure call)
14:53 hecks            server sent settings are just a bad hack solution
14:53 celeron55        <Warr1024> There are a lot of things in settings that should be stored in the world, not the client.
14:53 MTDiscord        <Warr1024> Moving things out of settings would help a lot.  Settings could be used to set defaults, but a lot of things like time_speed or shadows should exist at the game/world/player level...
14:53 celeron55        this doesn't mean everything should be a setting, it means less things should be settings
14:53 hecks            and if it starts turning into people *creating* settings just to support this mechanism, we're all the way in clown town
14:53 celeron55        and if you hate CSS's !important, why on earth do you want it here too
14:53 celeron55        seems like stockholm syndrome
14:54 MTDiscord        <Warr1024> I don't want it, I want something better ... but if the CSS folks couldn't think of something sane, well...
14:54 hecks            it's like
14:55 hecks            following this logic, why isn't player movement speed a setting OH WAIT HAHA
14:55 pgimeno          rubenwardy: stored server-sent settings would be a can of worms. I'm talking about on-the-fly changes to settings that don't get stored. The client would have a copy of the settings in memory that doesn't go to a file. The server can control them, but they wouldn't get stored.
14:55 hecks            why isn't every single thing defining the game a setting
14:55 hecks            let's call this
14:55 hecks            config oriented programming
14:55 MTDiscord        <Warr1024> I could see an argument in favor of keeping some settings around to act as default values where not specified by a game/mod/world/etc.  I could also see an argument in favor of just retiring them entirely and forcing the game/mod/world/etc to specify to avoid muddying the waters and having too much unpredictability in how things work at the client level.
14:55 hecks            write a game just by writing a complicated enough .conf file!
14:56 rubenwardy       Lua was designed partly as a config language
14:56 hecks            =]
14:56 pgimeno          a distinction between "run-time settings" and "permanent settings" would be necessary here
14:56 MTDiscord        <Warr1024> I'd really like to see game creators have more control over how their games are presented and experienced, and use client settings ONLY to manage accessibility and other factors that can't easily be managed by game creators universally...
14:56 hecks            I've no objection to sending Lua scripts to clients...
14:56 hecks            but WHY
14:56 hecks            pgimeno, why must it be a config entry
14:56 celeron55        >config oriented programming
14:57 celeron55        this is genius, it must be like programming in bash
14:57 pgimeno          hecks: to unify changing minor things under a single API to avoid exploding the APIs
14:57 MTDiscord        <Warr1024> Re: code-in-configuation, lately I just call both code and configuration "codefiguration" since I end up keeping default config in the same tree as code, and deploy them together, so there ends up being little reason to differentiate...
14:57 celeron55        or programming in CSS
14:57 hecks            celeron55: *linux users looking around nervously*
14:57 MTDiscord        <Warr1024> The idea that there exists some concept of "configuration" that's easy to change and "code" that's hard to change made sense back in a world before everything was CI and rolling releases.
14:58 hecks            pgimeno: you are still exploding the APIs, just in a very confusing way
14:58 MTDiscord        <Warr1024> If we move a whole bunch of stuff out of settings and into mod code territory, mods still will have the option of reading values out of settings anyway.
14:59 pgimeno          this is about changes that amount to changing a value; in some cases it's true that the change is not as simple as a variable in memory and instead needs supporting code to activate/deactivate
14:59 hecks            lua_api.txt will need as many lines to describe the magic options as it does for an API
14:59 hecks            because putting them anywhere other than lua_api.txt is even worse
14:59 hecks            uhhh
14:59 hecks            there's always side effects
15:00 hecks            there must be, unless a piece of code polls the setting every invocation (also bad design!)
15:00 hecks            it's like
15:00 hecks            we're starting to use settings as registers for flow control or something
15:01 hecks            we're regressing to programming microcontrollers in assembly by writing to magical addresses
15:01 pgimeno          and?
15:01 pgimeno          is there a performance impact to that?
15:01 hecks            there is a readability impact
15:01 hecks            there is a moral impact
15:01 rubenwardy       I would like to see shared architecture/designs for things like feature flags, but mixing it with settings doesn't necessarily feel right. It should be whitelisted, for one
15:01 hecks            you are submitting to the unholy ones and their unclean ways
15:02 hecks            your code will forever be cursed and you will never be free of their tortured screaming
15:02 MTDiscord        <Warr1024> Having to tell players to quit so they can change certain settings and rejoin does suck...
15:03 celeron55        how do you differentiate between settings that you can send to the client and settings you can't send
15:03 hecks            by having a hardcoded list of them, of course!
15:03 hecks            we'll call them... opcodes
15:03 celeron55        what does the documentation look like
15:03 MTDiscord        <Warr1024> Send all the settings, have the clients just ignore the ones that don't apply.
15:03 hecks            documentation is either something in minetest.conf.example or just as many lines in lua_api.txt as an API would take
15:03 MTDiscord        <Warr1024> As for hard-coding settings, settings are already used by hardcode, so it makes sense that way
15:04 hecks            the latter is bad, the former is clawing-my-eyes-out atrocious
15:04 pgimeno          celeron55: by splitting the configuration, what is not tolerable is the current mess of client setting mixed with server settings with world settings with game settings
15:04 MTDiscord        <Warr1024> After all it's not like you can make a setting work or not work based on configuration; all you can really do is apply an additional filter over top of what already has to make sense.
15:04 pgimeno          no, not on minetest.conf please
15:05 celeron55        wait what
15:05 hecks            he wants more .conf files...
15:05 celeron55        so in addition to having all those mixed up, you make it better by allowing even more mixing up?
15:05 pgimeno          what? no
15:05 hecks            they're multiplying... https://a.uguu.se/ZRsSg5aT5wFd_1611960927306.jpg
15:06 pgimeno          what I mean is what hecks said, more .conf files
15:06 celeron55        so what's the configuration file called which contains the settings that the server sends to the client?
15:06 hecks            don't forget it needs documentation in the form of a sister .conf.example file :D
15:06 pgimeno          client.conf
15:06 celeron55        ...what
15:06 celeron55        what's the client configuration file called?
15:07 pgimeno          minetest.conf, for compatibility
15:07 pgimeno          wait, no
15:07 celeron55        what's the server configuration file called?
15:07 celeron55        what configuration files does singleplayer use?
15:07 pgimeno          sorry, the client configuration file is called client.conf
15:07 pgimeno          singleplayer is a client + a server, so both server.conf and client.conf
15:08 hecks            ....haha
15:08 celeron55        how does a person know where to put a setting
15:08 pgimeno          if it's a server setting, in server.conf; if it's a client setting, in client.conf
15:08 hecks            well I do actually support separation of client and server settings but please do not misconstrue me as wanting anything to do with this negotiation idea
15:09 hecks            anyway the original question was, where's the documentation?
15:09 hecks            client.conf.example innit?
15:09 pgimeno          remember that the server sent settings do not get stored in client.conf, they are just overrides (if the client allows them)
15:09 celeron55        i don't support any of this
15:09 pgimeno          but they are run-time overrides
15:09 hecks            now how is this better than a flag in the SunSpec table...
15:10 hecks            what is the goddamn difference other than adding what's actually an extra network opcode
15:10 hecks            unless you want to migrate any client state to this config..... but what would be pure wtf
15:10 celeron55        what if someone makes a minetest client rewrite that uses the same server? then they're forced to use the same setting names and an identical setting system to begin with
15:10 celeron55        that's ridiculous
15:10 hecks            and contrary to the idea of network opcodes, which I've wanted to put on different channels, there's a PR for it
15:11 celeron55        just to make games work that the server runs
15:11 hecks            now
15:11 hecks            there are precedents for this but they're not a good example to copy
15:11 hecks            I think idtech and related engines also abuse cvars a lot but that's bad design
15:12 pgimeno          celeron55: that's happening in SL and the third party clients add their own settings for things that are specific of them
15:12 hecks            we are not second life, thank the gods
15:12 MTDiscord        <Warr1024> How do we make games work under the CURRENT system though?
15:12 MTDiscord        <Warr1024> We can't even check whether the client has certain settings set, we just need to beg them to set them.
15:12 pgimeno          celeron55: it's no different than the client needing to acknowledge an enable shadow API call, really
15:13 celeron55        we have too little examples here now
15:13 celeron55        Warr1024: make a list of settings you have to beg clients to change
15:13 celeron55        now
15:13 celeron55        no talking, instead list making
15:13 MTDiscord        <Warr1024> We end up with a bunch of clients trying to play but their game is basically broken because they have the wrong settings but they ignored the warning about settings, and then other clients being annoyed by the settings warnings that they've already addressed.
15:13 celeron55        i know you have a problem but instead of describing the problem you're force feeding me a solution
15:14 celeron55        that won't work
15:14 MTDiscord        <Warr1024> The biggest one for me right now is display_gamma.  I have to advise players to start with a higher base setting (1.5 or 2, instead of default 1) and then "adjust to taste" from there.  Funnily enough that one is also a quagmire because it can't be FULLY controlled by the game.
15:14 hecks            it's no different, but how about using CODE to represent CODe
15:14 MTDiscord        <Warr1024> I set a higher default in the game's minetest.conf file, under the assumption that that MAY be honored in SP, but I can't do anything about MP as far as I know.
15:15 celeron55        well display gamma is basically a very simple colorless tonemap, it's part of a game's style if you want everyone to change it
15:16 MTDiscord        <Warr1024> Yeah, if there was like a player:set_gamma_adjust(num) or something then that would work for me, but ugh, not more APIs and more packets...
15:16 celeron55        the end user adjustment should be needed only by a portion of players depending on their display and environment
15:16 pgimeno          celeron55: I have described the problem in enough detail, I believe. Hecks wants to be able to let the server mandate settings, and it's a reasonable request, but I *also* want to be able to override whatever settings the server wants on.
15:16 hecks            I think I'm missing some people's messages, I guess there's a discord bridge or something?
15:16 hecks            >Hecks wants to be able to let the server mandate settings
15:16 hecks            wait no
15:16 MTDiscord        <Warr1024> It's really an XY problem anyway, where gamma is the Y and the fact that light intensity and light spread are linked is the X. If I could make brighter light_sources but with faster falloff then that would also solve the issue for me.
15:16 celeron55        there's Warr1024 on discord
15:16 hecks            I just want APIs for things that a game should have control over
15:17 hecks            shouldn't the discord bot echo messages from there?
15:17 celeron55        yes, i'm seeing them here
15:17 MTDiscord        <Warr1024> You have to unignore the bot
15:17 celeron55        maybe you've /ignored the bot
15:17 MTDiscord        <Warr1024> or read the backlog on the log site I guess
15:17 pgimeno          MTDiscord is the name of the bot if that helps
15:17 hecks            i haven't :o
15:18 hecks            maybe he's broke
15:18 celeron55        pgimeno: "Hecks wants to be able to let the server mandate settings" that's simply not true
15:18 hecks            I want sane APIs
15:18 celeron55        pgimeno: that was never even said
15:19 pgimeno          I consider shadows on/off a setting in this context.
15:19 celeron55        that setting will always exist
15:19 celeron55        the server can just turn them off if that's the game's style
15:19 celeron55        next problem please
15:20 MTDiscord        <Warr1024> It is really pretty annoying that there is just one set of settings and they all apply to all worlds, all servers, etc.
15:20 hecks            what were we even...
15:20 MTDiscord        <Warr1024> Wait, what can the server turn off?
15:20 MTDiscord        <Warr1024> Shadows?
15:20 celeron55        worlds need their own settings but not any settings, they can be their own setting namespace completely detached from other settings
15:20 hecks            let's just consider the setting a graphics quality setting
15:20 hecks            where on/off is still a matter of a quality/performance tradeoff
15:21 hecks            and then the game's control over it is a separate concern
15:21 celeron55        or are you saying a world should be able to decide for example what the key mappings should be? or, let's say whether waving leaves are enabled?
15:21 hecks            engines usually have very fine control over this stuff, it's usually a config variable *and* a light flag *and* object caster/receiver flags *and* a shader variant define
15:22 MTDiscord        <Warr1024> Shadows would have bothered me if there weren't a workaround to disable them from the server/game-side, since they're only a positive-quality setting if you use the default skybox.
15:22 hecks            because shadows are a heavy and hacky effect and they must be used with care, it's not something you can expect to toggle on and have it looking good
15:22 hecks            without realtime path tracing, shadows will always be this "trick"
15:22 MTDiscord        <Warr1024> As it is, I can make it so shadows don't cause visual problems in my game by disabling them, but players will still have to suffer any performance impact that calculating null shadows has.
15:23 pgimeno          celeron55: if it's implemented the way I suggest, the server would have that control, yes
15:23 hecks            celeron55: the key mappings thing is an interesting question
15:23 MTDiscord        <Warr1024> Also, anyone who DOES use the default skybox can't use the same hack I did to disable shadows.
15:23 celeron55        if worlds literally should be able to change any settings, yes, then obviously layered settings are needed
15:24 pgimeno          mostly *client* settings, and run-time only, not persistent
15:24 celeron55        it's not even a question for worlds then
15:24 celeron55        but the server only needs to control a few things that are client settings currently, and they can be made to be APIs with client-side quality/performance control
15:24 celeron55        just like for shadows
15:25 celeron55        shadows are a bit special because one performance option has to be disabling them regardless of the server requesting them
15:25 hecks            the only other things I can think of that require controls like this are
15:25 hecks            camera bobbing, FPP/TPP camera modes, and pitchmove
15:25 hecks            those are the only problems left to solve in this domain and all of them can happily be rolled into existing apis
15:26 celeron55        well, and i guess a display gamma multiplier
15:26 hecks            one of them doesn't even have a conf entry
15:26 hecks            gamma too, but an api to like
15:26 hecks            add a relative modification on top would be fine
15:26 hecks            I understand that people need a brightness setting because people have different eyes and monitors and rooms
15:27 hecks            and then the game can further modify that in a relative fashion for a visual effect
15:27 celeron55        but it is obviously something you can make a game's style
15:27 celeron55        also
15:27 hecks            in fact if there was an ObjectRef:set_gamma(num) api, you could have this amazing HDR-like effect
15:27 hecks            that is, eye adaptation based on the light level of the node you're standing on
15:28 hecks            setting tonemapping curves for a client would also be cool
15:28 hecks            but the gamma settings can coexist with that, it's not either or
15:28 MTDiscord        <Warr1024> There's also that PR that's been in limbo for a year or two to allow games to require privs to access certain F5 info...
15:28 celeron55        if you make those, i'm here waiting with my cursor on the "rebase and merge" button
15:28 hecks            a proper tonemapper and color grading?
15:28 MTDiscord        <Warr1024> That one is at the top of my "engine problems that are effectively breaking my game" list.
15:29 hecks            consider it planned ;]
15:29 hecks            todo... soon.... someday....
15:29 celeron55        i mean the things that will make Warr1024 not want server-sent settings
15:29 hecks            ah I can't see his stuff, sorry
15:29 hecks            fix the bot sometime, folks
15:29 celeron55        i.e. the gamma
15:29 celeron55        the bot works, i can't understand why you don't see it
15:30 freshreplicant[m Works for me too, but I'm on Matrix.
15:30 celeron55        it's connected here just like any user
15:30 hecks            Warr, try saying something
15:30 celeron55        the format it's using is "<name> message"
15:30 pgimeno          hecks: are you sure you don't have it in /ignore ? it works fine in the logs, https://irc.minetest.net/minetest-dev/2021-06-21#i_5836179
15:30 celeron55        does your client automatically ignore those somehow
15:30 hecks            maybe I did have it in ignore for some reason
15:31 hecks            but that must have happened on freenode
15:31 MTDiscord        <Warr1024> The gamma adjust would be a big help, and also #9315
15:31 ShadowBot        https://github.com/minetest/minetest/issues/9315 -- Require debug priv to view gameplay-relevant debug info (2nd try), add wireframe priv by Wuzzy2
15:32 Wuzzy            before you go into String Freeze: #11370
15:32 ShadowBot        https://github.com/minetest/minetest/issues/11370 -- Fix some typos in builtin by Wuzzy2
15:32 celeron55        Warr1024: i agree that PR should go in
15:32 celeron55        why is it even hanging there still
15:33 MTDiscord        <Warr1024> Hahaha, SO much why
15:33 celeron55        this is stupid
15:36 pgimeno          see, that can also be implemented via server->client settings override. Just don't have one that allows the client to force them.
15:36 MTDiscord        <Warr1024> As I understand it, merges require 2 core dev approval, but core devs have no obligation to take any action on anything they don't have an interest in, don't feel qualified to evaluate, or maybe just don't want to try to dig through the thread and figure out the current state of consensus.
15:37 MTDiscord        <Warr1024> That means effectively things stay in limbo unless someone is willing to pester core devs and find advocates, and maybe risk being banned for said pestering...
15:37 rubenwardy       that PR just doesn't the hype factor :D
15:37 MTDiscord        <Warr1024> On a 100% volunteer-based project though I'm not sure if there's a good solution...
15:38 celeron55        the solution would be some core devs being actual game developers also
15:38 MTDiscord        <Warr1024> Well, if celeron and ruben both agree that the PR seems to pass a "preponderance of the evidence" decent-idea test, either of you could just hit the merge button?  Rock paper scissors?
15:38 rubenwardy       I'm checking it over now, been on my to do list for a while
15:38 MTDiscord        <Warr1024> You might have to actively recruit from game devs in that case
15:39 rubenwardy       I think I count as a game developer, just a shitty game designer
15:39 celeron55        rubenwardy: i trust you to test it and merge it if it still works
15:39 MTDiscord        <Warr1024> If I were asked to become a core dev, I would consider it, depending on the level of responsibility involved.  By far most of my MT time is spent working on NodeCore, so I have been mostly focused on engine things that affect what it wants to do specifically...
15:39 rubenwardy       well, you could always ask celeron55 for thar
15:40 MTDiscord        <Warr1024> I was under the impression that a core dev needed to contribute a lot of CODE to the core, and I've only done a few scattered bugfix-like things here and there.
15:40 MTDiscord        <Warr1024> but if a core dev is mostly a reviewer/integrator then I suppose I might be useful after all...
15:40 rubenwardy       there's no formal requirements, c55 is the benevolent dictator with some consultation
15:41 celeron55        core devs are the thing that gets good PRs merged and bad PRs not merged
15:41 rubenwardy       but pretty much all the core devs have done plenty of PRs before becoming one, and often PR review too
15:41 celeron55        if somebody can and is willing do part of that, they should be a core dev
15:42 MTDiscord        <Warr1024> Y'all got like a "so you want to become a core dev" guide or anything?
15:42 rubenwardy       telling if someone can do that is typically measured by past involvement, as well other credentials
15:42 rubenwardy       that guide would be 3 lines
15:42 rubenwardy       # So, you want to be a core dev?
15:42 rubenwardy       What is wrong with you?
15:42 MTDiscord        <Warr1024> ha
15:42 rubenwardy       oh, IRC skipped my empty line  there
15:42 hecks            I could do it but it's shitwork and people wouldn't like it =]
15:43 hecks            like I have time to review other people's code, I can barely manage my own
15:43 celeron55        Warr1024: https://dev.minetest.net/All_rules_regarding_to_development
15:43 celeron55        just tell me once you've read those and still want to be a core dev
15:43 rubenwardy       core deving is a bit mixed on my mental health, so I tend to disappear a lot of the time
15:43 MTDiscord        <Warr1024> The certificate for dev.minetest.net expired on 5/24/2021. (in case you weren't already aware)
15:43 hecks            fix the TLS and I'll read it ;]
15:43 celeron55        yeah just trust the old one
15:43 rubenwardy       I guess that means we don't have any rules now? ANARCHY!
15:44 celeron55        my certificates age like wine, they only get better
15:44 hecks            at least I have a sane browser that lets me do this
15:44 MTDiscord        <Warr1024> If there isn't like a huge demand for me to dedicate time to core deving and I can do it on an as-available or when-somebody-gets-my-attention basis then it's possible...
15:44 celeron55        the bigger problem is let's encrypt is completely shot for the regular wiki and forum also, they're ticking time bombs
15:44 hecks            >Be nice
15:44 hecks            I'm fired
15:44 celeron55        and i haven't had time to fix it. fixing it basically means moving all the shit to another host with another OS
15:44 hecks            there's no country for old linuses
15:45 rubenwardy       I made the mistake of switching to LetsEncrypt wildcard certs to simply my nginx config. Unfortunately, this means I need to manually renew as certbot doesn't support namecheap for DNS updates
15:45 rubenwardy       as wildcard certs require DNS verification via a text record
15:45 MTDiscord        <Warr1024> With LE I've found I need to run an update client, AND have external monitoring to warn me when the certs are starting to get too close to expiring, because the clients sometimes break.
15:45 hecks            but honestly with some sort of veto power over really really bad ideas, I wouldn't have to yell at anyone
15:45 hecks            maybe I'd be more polite
15:45 MTDiscord        <Warr1024> Nah, you'd just end up yelling at your fellow core devs.
15:45 hecks            but of course there's always people who take code criticisms personally, and I can't help with that
15:46 celeron55        yeah the problem there is the client i use, which is at the same time the newest client i can find for that version of that OS, doesn't support ACME v2 :D
15:46 celeron55        and let's encrypt stopped supporting v1
15:46 MTDiscord        <Warr1024> I, for one, tend to like bad ideas.  I've found the most effective way to find good ideas is to try a whole bunch of bad ones and see which ones suvive...
15:46 MTDiscord        <Warr1024> NodeCore is a pretty good example of that.
15:46 celeron55        i'm not going to sink any more time to that openbsd box, it's all going to a linux VPS... when there's the time
15:46 rubenwardy       #9315 code changes look good, testing now
15:46 ShadowBot        https://github.com/minetest/minetest/issues/9315 -- Require debug priv to view gameplay-relevant debug info (2nd try), add wireframe priv by Wuzzy2
15:46 sfan5            I use simp_le which should only need a working python3 runtime
15:47 MTDiscord        <Warr1024> Yeah, I think that sounds like what I run on my openbsd systems
15:47 pgimeno          I think a core dev needs to have a fairly decent understanding of the engine as a whole, in order to ensure that the reviews keep the consistency of said whole as much as possible
15:47 celeron55        sfan5: throw me a link and i'll make that shitbox run for 10 more years
15:47 rubenwardy       pls no
15:47 sfan5            https://github.com/zenhack/simp_le
15:47 sfan5            needs manual wiring up, unix-style (not that that's a bad thing)
15:48 celeron55        it's the best thing
15:48 celeron55        i want zero automation
15:48 rubenwardy       the forums are so terrible, so slow
15:48 freshreplicant[m I was wondering, what's the policy for posting here? If you're not a developer, is it considered bad form to post here, even if it's on topic?
15:48 MTDiscord        <Jonathon> the forums are a joke
15:48 celeron55        all paramters as command line arguments - perfect
15:48 celeron55        +e
15:48 sfan5            "chit-chat goes to #minetest" is the policy
15:48 rubenwardy       freshreplicant[m: this channel is for engine development, any one can talk here as long as it's about that
15:49 hecks            if you're looking for a bug you're already a developer
15:49 rubenwardy       I want all the automation
15:50 freshreplicant[m I've found some bugs, but don't look for them. And I seldom share the findings, because I usually forget a few minutes later. I don't mean to hoard them.
15:50 rubenwardy       I made the mistake of rewriting/modernising the Jenkins pipeline at work, to do UI testing and linting and such, now I only get assigned to devops/pipelines/automation/cloud stuff. Not that I'm complaining
15:50 celeron55        i want all the automation, but made by me
15:50 MTDiscord        <Warr1024> > If a core developer is doing almost nothing but blocking everything that comes their way, they will be unassigned. Haha, how long has that rule been in place?  :-D
15:50 rubenwardy       freshreplicant[m: so, bugs can be discussed here as long as they're actual bugs - user help is in #minetest. So go ahead
15:50 celeron55        i can't stand systems made by others breaking
15:50 rubenwardy       haha oh same
15:50 rubenwardy       I prefer bugs to be my own bugs
15:51 rubenwardy       which I why I can't stand unity
15:51 rubenwardy       (Ironically, I'm breaking this channel's rules now)
15:51 MTDiscord        <Warr1024> I hate stuff breaking and don't care whether it's mine or not.  Whether I prefer my own code or not depends on whether I feel like I'd have the time to actually maintain it.
15:52 celeron55        i guess you should prefix your messages with [off] or something if they're offtopic
15:52 celeron55        not a rule but i'm always glad when some people do that
15:53 hecks            why, for filtering?
15:53 MTDiscord        <Warr1024> The [off] prefix is more like "off the record" (don't log or bridge) than "off topic"
15:53 pgimeno          ^
15:53 MTDiscord        <Jonathon> ^
15:54 celeron55        for quick visual filtering, you can skip them if you're only interested in dev stuff and can keep your mind out of the unnecessary stuff
15:54 celeron55        well, any prefix is fine
15:54 hecks            oh well, github is the more formal place anyway
15:54 hecks            I don't grovel IRC logs expecting to find anything useful
15:55 rubenwardy       not sure if this is considered a breaking bug: https://github.com/minetest/minetest/pull/9315#issuecomment-865149416
15:55 rubenwardy       I think it would be
15:55 hecks            any good design draft should probably be written on gh to avoid losing it
15:55 MTDiscord        <Warr1024> As a core dev, are there any "active" obligations, such as attending regular meetings, being available at certain times, or meeting some kind of quota of activity?  Or is it just a matter of following the guidelines when you do act, and just making sure you don't do stuff that would make somebody want you not to be a core dev?
15:56 celeron55        rubenwardy: i don't think that's important, the common use case is to not give the privilege to normal players to begin with
15:56 rubenwardy       The design doesn't really account for this, tbf. I'd personally design this feature differently - as an enum which you'd derive the UI flags from
15:56 rubenwardy       ok, merging #9315 in 10 then
15:56 ShadowBot        https://github.com/minetest/minetest/issues/9315 -- Require debug priv to view gameplay-relevant debug info (2nd try), add wireframe priv by Wuzzy2
15:57 rubenwardy       wait, found another bug
15:57 MTDiscord        <Warr1024> If anybody needs me, I'll be holding my breath for the next 10 minutes :-D
15:57 celeron55        Warr1024: the only obligation is to not do stupid stuff
15:57 rubenwardy       when you first join the game, you don't have any privileges. If the debug UI is shown, this results in the position not being shown until you toggle again
15:57 celeron55        and follow the rules when doing something
15:58 sfan5            that sounds like the same bug
15:58 celeron55        rubenwardy: that's an actual usability problem, needs to be fixed
15:58 celeron55        same bug but this time it matters
15:58 MTDiscord        <Warr1024> celeron55: I apply to become a core dev, then, assuming there are no objections.
15:59 MTDiscord        <Warr1024> I figure if I would have some say in whether things get merged (i.e. I only need one additional vote) then it may motivate me to tackle some of the problems I've been putzing about with, like seeing if there's anything I can do about ABM performance and such...
15:59 celeron55        hecks: design drafts in MT? i've found them to be more like wishlists, code always ends up in some other way 8)
15:59 rubenwardy       yeah, exactly
16:00 rubenwardy       replying to "same bug but this time it matters"
16:00 celeron55        Warr1024: that's the usual motivation for a core dev
16:00 hecks            I don't draft things I don't intend to code
16:00 hecks            but design documents for WIP features would be nice in case the original committer gets hit by a truck before he's done
16:01 hecks            at the very least, please write more comments, folks
16:01 celeron55        yes, assuming the feature was taking more than a day to complete
16:01 MTDiscord        <Jonathon> hecks: do you have any plans to reopen your world line render PR?
16:02 MTDiscord        <Jonathon> https://github.com/minetest/minetest/pull/10619
16:02 celeron55        btw, if someone doesn't deem Warr1024 worthy of core dev privileges, you should /msg me now
16:03 hecks            I think I missed the convo, also the bot is just hopelessly broken for me
16:03 hecks            maybe this will do it...
16:03 rubenwardy       Warr1024: do you have any C++ experience? Have you been involved with professional or any code review before? I'm not familiar with your background
16:04 rubenwardy       Nodecore is pretty good though, so you seem technically competent
16:04 hecks            what's Warr's GH handle?
16:04 rubenwardy       same as username @Warr1024
16:04 wsor4035         ill post from here then, hecks: do you have any plans to reopen/keep working on https://github.com/minetest/minetest/pull/10619 ?
16:05 wsor4035         and on gitlab
16:05 rubenwardy       C++ experience isn't necessarily a hard requirement though, there's still the Lua
16:05 MTDiscord        <Warr1024> The totality of my C++ experience in the past several years is probably the PRs I've submitted for MTE itself, but I think those demonstrate that I'm at least passably competent at it.
16:06 hecks            wsor4035: sadly no, the line renderer is blocked by the lack of a GUID system for objects, there is no way for ObjectRefs to safely point to one another
16:06 MTDiscord        <Warr1024> I never considered myself a C++ "expert" or anything, but it was one of the first languages I learned, and I'm also used to the landscape moving a lot and needing to learn new shit all the time.
16:06 wsor4035         ah ok, thank you
16:06 hecks            any implementation of this without fixing that would be very hacky and need scrapping later
16:06 rubenwardy       ha, very few people are C++ experts
16:06 hecks            oh I finally see the discord bot
16:07 MTDiscord        <Warr1024> hecks you can hear me now?
16:07 hecks            yes
16:07 hecks            you're the nodecore guy right?
16:07 MTDiscord        <Warr1024> weird; what changed?
16:07 MTDiscord        <Warr1024> yeah, that's me.
16:07 celeron55        a GUID system for objects should probably be added
16:07 MTDiscord        <Jonathon> wasnt desour working on one?
16:07 celeron55        it's, like, just an additional data item in each object
16:08 rubenwardy       yeah, there's an open PR for it
16:08 celeron55        eh, that too? lol
16:08 MTDiscord        <Jonathon> https://github.com/minetest/minetest/pull/11050
16:08 MTDiscord        <Jonathon> theres open PRs for a lot of things.....
16:09 hecks            discord was in my ignore list but I had to go and manually delete it for some reason, it wasn't enough to just toggle ignore
16:09 hecks            anyway
16:09 MTDiscord        <Warr1024> (heh, don't get me started on the mess that is the UUID data type specifically...)
16:09 celeron55        Warr1024: you're Warr1024 on github, right?
16:09 hecks            Warr is being considered for coredev now, right?
16:09 MTDiscord        <Warr1024> Yes, I'm Warr1024 everywhere that I'm aware a Warr1024 exists :-)
16:10 MTDiscord        <Jonathon> hecks: correct
16:10 celeron55        doesn't seem like a common nickname but eh
16:10 celeron55        doesn't hurt to ask 8)
16:10 hecks            I wouldn't mind a gamedev being a maintainer but the merged PRs are a bit scant
16:10 hecks            if he gets accepted, I'm applying too
16:10 MTDiscord        <Warr1024> I was Warr back before I first registered for AIM, but they told me Warr was already taken and suggested like Warr11 or something, so I figured I'd just skip WAY ahead and avoid having that problem again :-)
16:12 celeron55        hecks: well, i just added him to the github engine repo
16:12 MTDiscord        <Warr1024> If MT wants to be more enginey and less specific-game-ey then having multiple gamedevs as coredevs seems like it would help.  Only having one gamedev might tend to bias decisions toward specific games still, after all.
16:12 hecks            although in the long run I don't care about formalities, I just don't want maintainers to commit untested crap
16:13 MTDiscord        <Jonathon> i thought core devs would get added to the organization? https://github.com/orgs/minetest/people
16:13 celeron55        i could ask you to read the wiki but i wouldn't believe you read it even if you said so so whatever
16:13 celeron55        so does someone object hecks then
16:14 hecks            probably all the people I've insulted the entire time :] whoops
16:14 rubenwardy       Jonathon: he needs to accept the invite first
16:14 MTDiscord        <Jonathon> ah
16:14 hecks            but if I'm on equal standing I won't have to yell at anyone
16:14 MTDiscord        <Warr1024> I'd prefer the game devs represented among core devs to be maintaining open source published games rather than server-specific experiences, but I don't have an objection against server-specific games being represented either.
16:14 MTDiscord        <Warr1024> I have no objection to hecks
16:14 celeron55        hecks: blackmailing the entire team is a good start, yes
16:15 MTDiscord        <Warr1024> I really appreciate the work hecks did on entity attachment fixing, btw.  It seemed like making that actually work was a real slog, but it's been great and it supports a prominent feature in NodeCore.
16:15 hecks            you won't hear from me unless you're about to do something really stupid, I promise
16:15 pgimeno          that's not blackmailing, just lobbying
16:15 hecks            and so far I haven't lobbied for one feature or fix that doesn't benefit everyone
16:16 hecks            I've worked in videogames before and have my own (offline) engine
16:16 hecks            experience in lua and c++ both
16:16 freshreplicant[m I am pretty much nobody, but I would hope that core devs are also required to possess a certain level communication skills and finesse.
16:16 celeron55        pgimeno: ah good ol' politics
16:16 hecks            as well as some languages MT doesn't need
16:17 hecks            also some former irrlicht experience
16:17 celeron55        what, irrlicht experience
16:17 hecks            I've used it... for a few weeks once ok?
16:17 hecks            before MT
16:17 celeron55        ok so this is like a resume now
16:17 hecks            I'm just shilling myself
16:17 celeron55        tried javascript for an evening = javascript expert
16:18 MTDiscord        <Warr1024> Well, I once got a job programming in C#, and then spent my first week or so on the job learning C#.
16:18 celeron55        it's a nice strategy, you get paid for learning something
16:19 celeron55        win-win
16:19 hecks            c# was my main before MT showed me lua, my code kinda stinks of it a little
16:19 MTDiscord        <Warr1024> Haha, well, the standard learning curve for other departments was like 6 months of training, but we had to train concurrently with our work, so it was a bit of a trial by fire.
16:19 celeron55        on the other hand if you already know C++ and Lua and contribute to MT, you learn nothing and get nothing
16:19 celeron55        lose-lose
16:19 celeron55        wait i didn't say that
16:20 MTDiscord        <Warr1024> If you want your game to work well and you make the engine it depends on work better, then I think you win something at least :-)
16:20 MTDiscord        <Warr1024> (even if you're just wasting your time developing new ways for other people to waste THEIR time)
16:21 rubenwardy       merging #11370 in 5
16:21 ShadowBot        https://github.com/minetest/minetest/issues/11370 -- Fix some typos in builtin by Wuzzy2
16:21 celeron55        Warr1024: 9000 IQ play: make others waste their time than you wasted yours -> you end up ahead
16:21 celeron55        +more
16:23 celeron55        hecks: i'm adding you as a core dev now, try to behave and you might get to keep that status
16:23 hecks            :o wow
16:24 hecks            i promise to only yell at people on sundays
16:24 Krock            ah yes my favourite time
16:24 MTDiscord        <Warr1024> I promise to only provoke hecks Monday through Saturday.
16:24 hecks            what, celeron giving random people commit power?
16:25 celeron55        hecks: the thing they do in churches is called singing
16:25 hecks            actually this is a legit worry, I once attempted to force-push something to master in a stupor...
16:25 celeron55        i recommend disabling force pushes to master, i recall there was a way to do that
16:25 MTDiscord        <Warr1024> Mistakes can be fixed, and they are a risk with anyone anyway.
16:26 MTDiscord        <Warr1024> Yeah, IIRC github should let you configure specific branches with different protection levels
16:26 hecks            I mitigate it now by always naming my remotes manually
16:26 celeron55        well we want to allow force pushes, when they're needed
16:26 celeron55        i think it's mentioned in the rules
16:26 hecks            so I name no remote "origin" just to avoid the "what origin" issue
16:26 hecks            the mt repo is simply "mt"
16:26 celeron55        i do that too, "origin" is an absolutely silly name for a remote, you never know where iti s
16:27 MTDiscord        <Warr1024> I generally have my main/master branches protected, and if I want to force-push, I just go into settings, unprotect, do the push, and then reprotect...
16:27 hecks            it's more like
16:27 hecks            you fork something with github and then you clone it
16:27 hecks            origin is now actually your fork... confusing
16:27 celeron55        github? bitbucket? some server at work? my own server? one of my VPSes? who knows
16:27 hecks            best to add remotes explicitly
16:27 hecks            with good names
16:27 sfan5            I have a remote named "upstream" for minetest/minetest
16:27 MTDiscord        <Warr1024> origin is always "one hop upstream"...
16:28 MTDiscord        <Warr1024> Heh, I use the "upstream" branch name to mean de facto "two hops" too actually
16:28 hecks            also because i have random people's repos in the folder too
16:28 hecks            to make PRs to PRs
16:28 MTDiscord        <Warr1024> If I let things being confusing confuse me I'dn't've gotten anywhere to begin with...
16:29 MTDiscord        <Warr1024> If I want to PR somebody else's PR I make a whole nother clone and just burn disk space.  I can handle some chaos but I also know my limitations...
16:30 freshreplicant[m From an outside perspective the points you made during shadowmap-gate were fair enough and logical, Hecks, but the way you communicated them was pretty abysmal. I really hope that as a core dev this changes. Not trying to stir anything up here, but opinions were being solicited.
16:31 hecks            consider that I communicated this way because there has been this tug of war going for months where I had to fight tooth and nail to even get people to acknowledge that visual bugs are bugs
16:31 Krock            you're literally stirring it up but it has to be mentioned, yes.
16:31 MTDiscord        <Warr1024> In my experience it's easier to be belligerent when you have no power, but once you're handed power, and the accompanying responsibility, it's pretty sobering.
16:31 hecks            if we can get that out of the way, I won't have a reason to yell at anyone
16:32 MTDiscord        <Warr1024> I used to fight authority a lot but authority had the last laugh by must making me one too...
16:32 rubenwardy       I agree with that. The points are valid, but not so much the way they were communicated. So I hope this won't be a problem in the future :) As a core dev, you represent the project
16:32 hecks            and just by being accepted as a dev I have less of a reason to yell at anyone because well I don't know, at least I'm arguing from equal footing, or something
16:32 freshreplicant[m But I just don't personally understand it. Your points were valid, your solution sane. It seems like your Issue would have been a...non-issue...if you didn't write paragraphs upon paragraphs of how useless other people are.
16:33 hecks            instead of having to beg for an acknowledgment that a bug is a bug
16:33 hecks            I'll also work towards formalizing this further
16:33 hecks            I don't know, get c55's opinion about this into the roadmap.md or how it's called
16:34 MTDiscord        <Warr1024> Formalizing the design philosophy of a project is really hard.
16:34 MTDiscord        <Warr1024> I've tried with NodeCore and I still feel like it's not there.
16:34 rubenwardy       I don't think that's a strictly bug, but it's an important feature that should be high priority as it prevents breaking games. Something doesn't need to be a bug for it to be important and a blocker
16:34 rubenwardy       *it's at least an
16:34 hecks            re: shadows I'll clean this mess up myself along the way and then just ensure that this doesn't happen again
16:34 hecks            by not giving a PR like this an approval unless it does the due work of providing compat
16:35 hecks            MT is some people's upstream and we gotta be responsible about it
16:37 rubenwardy       lhofhansl o/
16:38 Krock            but unlike enterprise solutions, Minetest, especially the master branch, is not guaranteed to be stable
16:38 rubenwardy       yeah, things may break in development versions but should/must be fixed by release
16:38 Krock            a 5.5.0 release date is yet not set; and there's surely plenty of time to fix up stuff
16:38 rubenwardy       that being said, MT has had a worrying tendency of breaking APIs recently
16:38 Krock            .. which is exactly now.
16:38 sfan5            which apis would that be?
16:39 sfan5            the milestone for 5.5.0 says roughly August btw
16:39 rubenwardy       the object API nillability and node alpha
16:39 Krock            and for 0.5.0-dev, the player model offste
16:39 rubenwardy       whilst not things guaranteed by the API, they broke a bunch of mods
16:39 sfan5            the latter did not
16:39 rubenwardy       still improvements though, just annoying for modding
16:40 freshreplicant[m As a Minetest user of no real technical skill, as imperfect as shadowmapping may be, I theoretically least get some tangible benefit from it if I want to toggle it on. As an optional engine feature, any potential pluses are also universal and not game specific. I've noticed a few issues with it, but I presume they can be ironed out. But then again, I don't know enough to say that it is or isn't 'redeemable'.
16:40 Krock            node alpha was tested well and did certainly not result in broken mods
16:40 rubenwardy       oh right yeah, it's painful to migrate but didn't break anything
16:40 sfan5            you may be thinking of the first iteration of that pr which was not optimal
16:40 Krock            unless you consider slight alpha shifts in transparent nodes (water) as breakage
16:41 MTDiscord        <Warr1024> freshreplicant: the exception re: shadows always being an enhancement is when a game uses a custom skybox that doesn't have a sun, or otherwise has light sources in positions that don't match the calculations baked into the shader.
16:41 rubenwardy       hecks: I eagerly await you and Liso fixing all our graphics issues :D
16:42 MTDiscord        <Liso> Don't worry about me.
16:42 hecks            liso, we need to talk about the shadow sampling performance
16:43 hecks            I don't know why is it so slow but it somehow is
16:43 MTDiscord        <Warr1024> Re: the alpha thing, having to migrate all the alpha = 160 properties I had to ^[opacity:160 texturemods was not fun, and I had considered doing a monkey-patch to apply this automatically in nodecore ... but in the end decided it was easier to bite the bullet and do it by hand.
16:43 hecks            it's best if you link me to the whitepaper or tutorial you implemented here
16:43 MTDiscord        <Warr1024> Supporting the true/false to clip/blend/none change was a bit trickier but I managed to survive that okay.  I think games/mods are probably okay as long as they don't try to support too wide a range of versions.
16:44 MTDiscord        <Liso> Because it renders  a lot clientmap to get the huge buildings Mt has, and irrlitch doesn't support depth pass
16:44 sfan5            @Liso make sure to send a PR with shadowmapping fixes when you have them
16:44 MTDiscord        <Liso> And it makes an insane amount of drawcalls
16:44 hecks            I'm not talking about the shadowmap creation pass
16:44 hecks            but actually about its use in the fragment shader, that is ungodly slow compared to any implementation I've seen
16:45 Krock            rubenwardy: I think you're familiar with Docker; does #11313 seem reasonable to you? If so, it could be merged
16:45 ShadowBot        https://github.com/minetest/minetest/issues/11313 -- Update Dockerfile and improve build speed on CPUs with a lot of core by bensuperpc
16:45 rubenwardy       will check
16:45 Krock            thank you
16:46 hecks            also consider what I said about normal bias vs linear bias; linear is more reliable
16:46 MTDiscord        <Liso> It's not optimized in any way, but it seems to be related with shadow texture access
16:46 hecks            and lastly I'd like to investigate the cascading as the shadow resolution for the shadowmap size and distance doesn't seem to match my experience
16:46 MTDiscord        <Liso> ?
16:47 hecks            I couldn't get a good shadow even with a distance of 100 and a 4K map
16:47 hecks            maybe the cascade steps could use rebalancing?
16:47 MTDiscord        <Liso> It's not csm
16:47 hecks            oh
16:47 hecks            well f me, it should be
16:47 hecks            for a directional light? we need cascades
16:48 MTDiscord        <Liso> I discarded that because making 3-5 passes to create shadow maps was crazy slow
16:48 hecks            otherwise all the work this does actually happens in places the player doesn't even see
16:48 hecks            like 75% of the work is wasted in the distant under-mipped area of your field of view
16:48 hecks            but oh right, we have a drawcall bottleneck
16:49 hecks            we really need some form of MultiDrawElements in the engine
16:49 MTDiscord        <Liso> No, with PSM we increase the texel density near the camera and reduce the density far away from the camera
16:49 hecks            well it doesn't seem to offer the precision I'm used to with cascades
16:49 hecks            but something like half that
16:50 MTDiscord        <Liso> In fact  there is still some CSM residual names in the impl. Like createSplitFrustum
16:50 hecks            maybe that's why I thought it's CSM, I've been reading it some
16:50 MTDiscord        <Liso> If we reduce by 10x the drawcalls we can use CSM
16:51 hecks            multidraw can do this
16:51 hecks            I'm toying with the idea of a pure GL 4.5 renderer that uses all the tools available
16:51 MTDiscord        <Liso> Also the current shadows have a HUGE bug that makes the frustum too big. I'm fixing it in other branch
16:52 hecks            what are the obstacles if any to just using raw OpenGL in MT? Should I do this in IrrMt instead?
16:52 MTDiscord        <Liso> Me too
16:52 rubenwardy       hecks: technical ability and effort
16:52 hecks            =]
16:52 rubenwardy       oh wait, you meant along side irr
16:52 hecks            yeah, sidestepping irr for it
16:52 MTDiscord        <Liso> The draw pipeline and graph mostly
16:52 hecks            would technically begin the divorce from irrlicht entirely
16:53 rubenwardy       Well, replacing Irr with OpenGL would be great, but we currently lack experience with raw OpenGL for that and it's a lot of effort. But it may be more viable with you around
16:53 hecks            this is relevant to my interests because I'm simultaneously developing a GL4.5 renderer as a toy project and doing a lot of research in the area
16:53 rubenwardy       Using OpenGL alonside Irr is possible I believe
16:53 MTDiscord        <Liso> I was playing with the idea of making an alternative renderer similar to MC optifine
16:53 hecks            the part I'm afraid of is wrangling GL I guess; the part where you manage the OS-specific subtleties
16:53 hecks            talking to xorg won't be fun
16:54 rubenwardy       SDL is a good choice for that
16:54 hecks            so maybe irrmt can be trimmed down to just doing what libs like SDL do
16:54 hecks            or yeah just move to SDL
16:54 rubenwardy       well supported, use a lot with opengl
16:54 hecks            or better yet glfw, if you're minimalistic
16:54 celeron55        irrlight doesn't do much of anything if you don't call it
16:55 celeron55        so for the new renderer just skip the part that calls irrlicht for rendering and call opengl directly
16:55 hecks            well if you made a GL4.5 renderer for mt, there would be no reason to do things like use irrlicht scene nodes and keeping models and textures in irrlicht objects
16:55 celeron55        you might have to add some interfaces to irrlicht to pull up the relevant handles
16:55 hecks            it would be easier to just use internal objects for this stuff and write a fallback for old GL
16:55 hecks            one more thing I'm not familiar with is how different GLES is from GL
16:55 celeron55        well, a gl4.5 requirement isn't acceptable to upstream MT
16:55 hecks            other than some vague correspondence between the versions
16:55 hecks            oh sure, not a requirement
16:56 celeron55        there needs to be some mode that works without
16:56 hecks            but see above; a starting point
16:56 celeron55        oh
16:56 hecks            there's basically a handful of hardware cutoff points that must be considered
16:56 hecks            first one is GL1 itself, anything supports this
16:56 celeron55        i think GLES is mostly a limited version of GL, it has the most common things that are easy to implement on cheap mobile hardware
16:56 hecks            second is probably GL2 where shaders are widely available
16:56 celeron55        the api listings are easily available
16:57 celeron55        i've sometimes compared some of them for some gl projects
16:57 MTDiscord        <Liso> At the end irrlicjt only have the scenegraph and use it to order objs and materials to render in order and then calls gl fn
16:57 celeron55        because webgl is gles also
16:57 hecks            GL3 adds geo shaders and the unified memory model, GL4 gives you compute and almost vulkan-like memory freedom
16:57 celeron55        https://www.khronos.org/registry/OpenGL-Refpages/es2.0/
16:57 celeron55        just look up what you'd be using
16:57 hecks            I have skimmed the khronos specs, just wondering what exactly is the extra work that you have to do to keep supporting android
16:58 celeron55        not much more than a ctrl+f
16:58 hecks            guess the answer lies in irrlicht's code
16:58 MTDiscord        <Liso> IMHO the best option is the one that could be compatible with gles2
16:58 MTDiscord        <IhrFussel> Don't make it so that MT requires a recent OpenGL version though...my pc got 2.1 for example
16:58 hecks            gles levels roughly correspond to desktop GL levels
16:58 hecks            and sure, I have no plans to *require* anything other than GL/GLES 1
16:59 rubenwardy       eh, I think that OpenGL 2.1 is a reasonable requirement these days
16:59 MTDiscord        <Liso> 2.1 has glsl include, texture arrays and up to 16 slots for textures. Good enough for me ?
16:59 celeron55        do you think it would be easier to get rid of irrlicht's scene and related things than to iterate them as-is and render using opengl instead of irrlicht
17:00 rubenwardy       2.1 was released in 2006
17:00 hecks            celeron55: irrlicht's scene and entity system is awful and we're basically using it like 30% of the time
17:00 celeron55        i'm open to getting rid of it
17:00 hecks            irrlicht also duplicates a lot of C++11 features
17:00 celeron55        it has a lot of stuff MT doesn't touch or need at all
17:00 MTDiscord        <Liso> I'm with Hecks. But that's a huge amount of work
17:00 hecks            it has basically clones of STL containers and smart pointers
17:01 hecks            anything you do with IReferenceCounted can be done with a shared_ptr
17:01 celeron55        so, feel free to, essentially, but i'm not much help
17:01 rubenwardy       big rewrites this is one way to kill Minetest development, mind
17:01 hecks            and lastly entity-component systems are superior to irrlicht's loose "bag of nodes" approach
17:01 hecks            and I've written many before, this is a trivial task
17:01 hecks            like
17:01 hecks            the scene and entity stuff
17:02 hecks            minetest already has most of this implemented as far as I know, just in a disorganized way
17:02 rubenwardy       merging #11313 in 10
17:02 ShadowBot        https://github.com/minetest/minetest/issues/11313 -- Update Dockerfile and improve build speed on CPUs with a lot of core by bensuperpc
17:02 hecks            while using SceneNodes in the client environment as rendering dummies
17:02 celeron55        well i don't know about entity-component, it an almost irrelevant detail
17:02 hecks            we also have our own collision don't we?
17:02 hecks            well an ECS is more maintainable, that's all
17:02 celeron55        +'s
17:02 hecks            i would not expose it to the lua api at first at least
17:02 hecks            it's just to compartmentalize the gigantic mess that content_cao.cpp is
17:03 hecks            and lastly
17:03 hecks            it would be an opportunity to really rigidly formalize object lifecycles
17:03 celeron55        i believe irrlicht's scene and node system basically just iterates through objects and renders them one by one, it's almost nothing
17:04 hecks            and possibly introduce a persistent reference system, which is a prerequisite to doing that line renderer thing this plan9 guy wanted but which I couldn't deliver
17:04 hecks            yup
17:04 celeron55        maybe distance culls them, but MT doesn't have much to cull because it manages that due to network and server reasons itself
17:04 celeron55        and rotates
17:04 celeron55        but that's like one matrix operation
17:04 celeron55        of course iterates through the mesh buffers or however a scene node renders itself
17:05 celeron55        did you look at https://github.com/minetest/minetest/pull/11050
17:05 hecks            a part of this rewrite would involve being smarter about this, it's something that interests me a lot
17:05 hecks            hmm interesting
17:05 MTDiscord        <Liso> Or even make a proper culling.
17:05 MTDiscord        <Liso> ?
17:06 Krock            Patch to replace #11187 : https://krock-works.uk.to/u/patches/0001-Server-Ignore-whitespace-only-chat-messages.patch   is there any reason that an error message is necessary? if not; I'll just push that today to close the PR
17:06 ShadowBot        https://github.com/minetest/minetest/issues/11187 -- Disallow empty messages by DiamondPlane
17:06 celeron55        i think a modern renderer wouldn't ask objects to render themselves but instead view objects as data and be more freeform in how to make them all display
17:07 hecks            yes, you'd collect drawcalls, sort and prune them, and then compile them into an optimized command list, and dispatch to GL in one short burst
17:08 hecks            I have done some experiments with this (in pure luajit) https://a.uguu.se/7z5hY8qcoxCV_mdi.png
17:08 MTDiscord        <Liso> And With that you have the gpu culling for "free"
17:08 hecks            actually this is pure irony, luajit is so good you could write almost everything in it...
17:09 celeron55        that's why CSM and SSCSM make sense for graphics, at least 2D and UI
17:09 hecks            well GPU culling ought to ideally occur in a compute shader pruning a MultiDrawIndirect drawcall list
17:09 celeron55        but it's irrelevant to this
17:09 Pexin            [']p----++-3.
17:09 hecks            and as long as you have MultiDrawElements or MultiDrawArrays (much more compatible) present, you can emulate this behavior on the CPU
17:10 celeron55        also, MT is sometimes run with non-jit lua if luajit isn't available on a platform
17:11 celeron55        i think to get started on what you're proposing, you need to start by making the simple stupid gl1 or gl2 renderer for old hardware with the supporting changes in scene management
17:11 celeron55        then get to the gl4 version
17:11 lhofhansl        #10788 is ready for a final (hopefully) review.
17:11 ShadowBot        https://github.com/minetest/minetest/issues/10788 -- Switch MapBlock compression to zstd by lhofhansl
17:12 celeron55        i mean, gles1 or gles2
17:12 celeron55        i assure you it's going to be a bit of a shitshow, we still have users that don't use shaders at all
17:12 rubenwardy       sorry, Krock, not-so-ninja edited https://github.com/minetest/minetest/pull/11338#issuecomment-865199426 for the last time
17:12 hecks            yeah i'm aware
17:12 celeron55        but by this point we should be able to get through it
17:12 hecks            i wouldn't try to drag you into my luajit abuse
17:13 hecks            some of it is real esoteric
17:13 hecks            re: the order in which this is done
17:13 rubenwardy       OK, edited again, typo
17:14 hecks            I would much rather create a GL4 renderer and then make fallbacks because the modern way is good practice anyway
17:14 hecks            of course as a single task, it's just a design philosophy
17:14 celeron55        well either way, just try to get it to a testable state soon enough
17:14 hecks            this is far off on the roadmap but possible
17:15 hecks            i could try monkey hacking MDI into irrlicht for a quick fix
17:15 hecks            which just means making it concat VBOs and produce multidraw lists if the relevant GL extensions are present
17:15 Krock            rubenwardy: yes the inconsistency sucks. we could add a helper function but I don't know whether it would be any good. Rather hijack the metatable or direct table of "io" so that io.lines() behaves correctly
17:15 hecks            this will reduce drawcalls from materials*blocks into just materials
17:16 hecks            and then texture array support would reduce it to just material types
17:16 Krock            where "correctly" is to be debated, since `\r` may also be intended as a new line
17:16 hecks            isn't what counts as a newline in lua locale dependent?
17:16 hecks            er
17:16 hecks            system dependent
17:17 rubenwardy       files are shared between computers
17:17 Krock            that's the problem. it must support line endings universally
17:17 rubenwardy       so all computers should be able to handle all line endings
17:17 rubenwardy       CRLF and LF most importantly, but CR too
17:17 celeron55        hecks: i would expect it to require rewriting quite a lot of irrlicht, but if it's reasonably possible it would be worth it. it should result in basically the same performance as any custom implementation
17:17 celeron55        it would just be uglier
17:17 rubenwardy       I mean, CR is rare enough these days that it's not as important
17:18 Krock            well, Macintosh is long gone, and MacOS uses \n
17:18 hecks            not that much from what I've scouted last time I poked at map rendering
17:18 hecks            it's just a change of how VBOs are committed to GPU memory
17:18 Krock            \r could just be ignored I guess
17:18 rubenwardy       right, might as well ignore \r then
17:18 MTDiscord        <appguru> ignoring \r makes matters harder
17:18 rubenwardy       no, makes it easier
17:18 hecks            don't some systems use CR only?
17:18 rubenwardy       you only need to look for \n then, and remove trailing \r
17:19 hecks            if you only consider unix and windows then you can just drop CRs
17:19 hecks            but I've heard of CR only systems, just don't remember what they were
17:19 Krock            macintosh for example, but that's safely to assume as dead
17:19 rubenwardy       by "ignoring \r" we mean ignore the fact that \r is sometimes used as a line ending, and only support \r\n and \n
17:19 MTDiscord        <y5nw> I don't think MT currently (officially) supports CR-only systems
17:20 celeron55        yeah don't even bother with CR-only
17:20 hecks            then LF only should work
17:20 hecks            even windows mostly tolerates LF only
17:20 rubenwardy       problem is when users edit files or checkout using git, that often introduces \r\n
17:21 hecks            uhhhh
17:21 hecks            that's their fault basically
17:21 rubenwardy       so even if MT only emits \n, \r\n needs to be supported when reading
17:21 celeron55        on windows notably notepad doesn't support \n, it only works with \r\n
17:21 sfan5            never had that happen to me on linux ;)
17:21 hecks            yes but who uses notepad?
17:22 hecks            and i wouldn't be surprised if windows 10 notepad tolerates pure \n
17:22 celeron55        and git has chosen its default really badly, converting text files by default is so stupid
17:22 celeron55        it creates problems both ways, trying to run a BAT file on linux won't work either when git helpfully converts \r\n to \n and the windows cmd doesn't support \n
17:22 Krock            even wine's notepad.exe can read \n line endings properly, and pretty sure windows 10' notepad does too
17:23 MTDiscord        <Warr1024> I would not be surprised if git removes the \r\n <-> \n conversion thing at some point and just starts relying on all modern OS
17:23 MTDiscord        <Warr1024> to handle \n
17:23 rubenwardy       hm, io.lines is never used by MT and *line is only used in the settingtypes
17:23 rubenwardy       I guess there's not that many custom formats
17:23 hecks            git at least shows you big ugly blocks in git show when you accidentally commit something with CRs
17:24 hecks            i just fix that and squash when it happens
17:25 kilbith_         I personally am uncomfortable with Warr1024 being a core-dev, for personal reasons. The guy has been portraying me as the "most insane person to speak with" on Discord and has been mocking me publicly for my alternative job that we aren't supposed to talk about. For these reasons it'll be hard for me to collaborate with Warr1024. I also dislike Discord'ers unhealthy mindset to seek for higher ranking and flashy accolades when an opportunity arises.
17:26 pgimeno          <Liso> At the end irrlicjt only have the scenegraph and use it to order objs and materials to render in order and then calls gl fn  <-- And to hinder extending the coordinate range, and causing coding horrors like the "camera offset", by using single precision floats for positions.
17:27 pgimeno          as for CRLF and git, git has a .gitattributes that unfortunately isn't used as much as it should.
17:27 hecks            camera offset... is that still there? i remember killing it
17:28 hecks            at least in the map renderer
17:28 hecks            it did literally nothing of value
17:28 hecks            and neither does the *BS scale, i'd love to squish that one too
17:28 Krock            you cannot kill the camera offset without, only fix its bugs. the camera offset exists to not cause jerky textures at the world edges
17:28 pgimeno          +1 about BS scale. It's literally BS.
17:28 hecks            uhhhhh
17:28 hecks            oh i remember what it was now
17:29 hecks            the camera offset was literally implemented by shifting mesh vertices around :DDDD
17:29 hecks            good times
17:29 hecks            yeah i guess it's still there, just being done with a matrix
17:30 hecks            honestly if some rare, critical transformations were just done in double precision, this wouldn't matter
17:30 pgimeno          Krock: you can kill it by making it continuous and transparent to the rest of the code, but that basically needs a rewrite of the scenegraph renderer
17:30 hecks            BS scale might have some history in the context of like
17:30 hecks            serializing positions over the network? just a guess
17:30 Krock            pgimeno: wouldn't that rather be "moving it somewhere nobody will ever look again"?
17:30 pgimeno          hecks: mostly position transformations. Rotations and scales can remain single prec.
17:30 hecks            I'd like one of the elder gods to tell me exactly how that happened
17:31 hecks            but even having to mentally convert between world space and BS space in the lua api is taxing
17:31 pgimeno          Krock: yes, making it no longer be a problem anymore. That's also what MC did for what I read once.
17:31 hecks            I've got a vague plan to iron that out actually
17:31 hecks            provide renamed, correct-coordinate copies of properties that use the BS scale and deprecate the originals
17:32 Krock            BS is (still) used for better precision for network-sent positions (as integers) and to notice when a calculation didn't work properly
17:32 pgimeno          And basically what I did for OpenMiner, which has a +-2^31 range of coordinates with leave waving working everywhere.
17:32 Krock            latter is just a "meh" side-effect I guess
17:32 hecks            but in that case BS should just be converted immediately as a packet is constructed or unpacked
17:32 hecks            if it has any use in serialization, that's the only place it should live
17:33 hecks            and not peppered all over the code
17:33 pgimeno          I tried setting BS to 1 just to test, and it affected more than it should, including inertia and scaling of some nodes.
17:33 Krock            summon cccc55. he might know.
17:33 hecks            BS is basically the client environment coordinate space from what I gather
17:33 hecks            the actual space that the irrlicht scene nodes live in
17:33 hecks            while metric space is what the server environment and lua apis use... for the most part?
17:34 hecks            but then any property that is in object space is also in BS, like visual_size
17:34 hecks            anyway there's that deprecation plan if anyone wants to poke holes in it
17:35 hecks            provide good space properties with good names, old ones are only used if present and converted. what could possibly go wrong?
17:35 rubenwardy       god, I hate how attachments are 10x world coords
17:35 rubenwardy       I wish 5.0 had fixed that
17:35 hecks            that's BS space for you
17:35 rubenwardy       also, degrees vs radians
17:35 rubenwardy       yeah, but it sucks that it was leaked into the Lua API
17:35 celeron55        BS means bullshit, it's a mistake
17:35 Krock            rubenwardy: inb4 API breakage
17:36 rubenwardy       :'(
17:36 rubenwardy       5.0 was the opportunity to fix it
17:36 hecks            i think the migration plan is sound
17:36 hecks            we can do it for 6.0
17:36 hecks            also an opportunity to resolve some WTF naming in the api like
17:36 celeron55        i was using BS initially to debug node alignment and other stuff
17:36 hecks            visual_size -> that's a "scale" for you
17:37 celeron55        and then left it as 10 like an idiot
17:37 hecks            and then if someone still uses visual_size, that's read as BS space and converted
17:37 hecks            and by default it's nil and "scale" is used
17:37 rubenwardy       yeah, that's another thing - scale should be an object transformation, not an object property. And there should be a visual size like property that doesn't effect children
17:37 hecks            oh like
17:37 hecks            scrap the property altogether and just have a transform api?
17:37 hecks            sure thing
17:37 rubenwardy       object transformation is position + rotation + scale, and effects children
17:38 celeron55        if you're changing the function name and leaving the old one you don't need a major version to change the api
17:38 celeron55        you can do that any time
17:38 celeron55        it's completely compatible
17:38 rubenwardy       could use `:attach` as the new name, better grammar than `:set_attach`
17:39 pgimeno          remember, all of that has to be done while keeping 100% compatibility. And BS has issues for that. I looked into it a bit.
17:39 hecks            well 6.0 can delete the old apis to trim lua_api.txt
17:39 rubenwardy       problem with this is that it can cause confusion between the different versions
17:39 hecks            and to trim the code we have to maintain
17:39 hecks            the idea is
17:39 hecks            convert all internal coordinates to metric in the client and server env. this is the ground truth
17:39 hecks            use BS for serialization, transparently
17:40 hecks            and then convert BS data quietly to metric in legacy apis
17:40 pgimeno          and for some APIs too
17:40 hecks            for legacy apis, like people still using the visual_size property, that overrides transform scale if present
17:41 hecks            and is converted from BS to metric (and then back when the packet is sent, but that's legacy support for you)
17:41 celeron55        that's a lot of work for effectively no result or new bugs at best, but feel free to 8)
17:41 hecks            overall the lack of *BS in c++ code will remove a lot of noise
17:41 hecks            it's a minor hurdle for new contributors trying to understand the code
17:41 hecks            and anyone trying to maintain it
17:41 hecks            you have to mind the BS space at all times when working with CAOs because they're used arbitrarily
17:43 pgimeno          camera offset space is also an obstacle for the same reasons, I've run into it often enough
17:44 pgimeno          you can identify the issues by setting BS=1 and watching the effects, e.g. the player becomes a lot more slippery
17:44 celeron55        well that just means you'll have to divide something by 10 somewhere
17:45 pgimeno          yeah, but you must make sure not to miss any of these in order to keep compatibility
17:45 celeron55        at least i was wise enough to not propagate the BS in the lua api, lol
17:45 celeron55        imagine not doing that
17:45 celeron55        into*
17:45 hecks            =]
17:45 rubenwardy       merging #11371, #11338, and #11313 in 10
17:45 ShadowBot        https://github.com/minetest/minetest/issues/11371 -- Update builtin locale by Wuzzy2
17:45 ShadowBot        https://github.com/minetest/minetest/issues/11338 -- Strip carriage returns from lines in settingtypes.txt by neoh4x0r
17:45 ShadowBot        https://github.com/minetest/minetest/issues/11313 -- Update Dockerfile and improve build speed on CPUs with a lot of core by bensuperpc
17:45 hecks            oh right, config too
17:46 hecks            gotta find all the places BS is present in .conf, but there aren't many of those are there?
17:46 celeron55        ...none?
17:46 rubenwardy       I don't recall configs for that?
17:46 rubenwardy       you can't set attachments there
17:46 hecks            I mean, any config values that are in BS space
17:46 hecks            do those exist?
17:46 rubenwardy       I don't think so
17:46 celeron55        as i said, possibly none
17:46 rubenwardy       unless there's a camera offset one
17:47 pgimeno          are the player physics settings in config?
17:47 rubenwardy       no
17:47 hecks            there sadly are some player physics in the config (yuck!) but they're in metric
17:47 Wuzzy            I think hecktest has a point about dynamic shadows tho. Yes, is a problem that games cannot defend against dynamic shadows
17:47 rubenwardy       we agree on that
17:48 hecks            I'll tie the shadows to the presence of sun and moon at the moment
17:48 pgimeno          hecks: see what I said above about becoming slippery, maybe there's a bug that makes some physics settings use BS somewhere
17:48 hecks            and then provide a better api for this stuff
17:48 hecks            https://a.uguu.se/Uq0VWazX0teT_physconfig.png anyway we do have physics in .conf sadly
17:48 hecks            let's delete this someday
17:48 rubenwardy       surely that's in metric?
17:48 hecks            yes
17:49 hecks            luckily no BS scale here
17:49 pgimeno          no friction there, I believe it's friction what affects the slipperiness
17:52 Wuzzy            What does the "Roadmap" label do?
17:53 rubenwardy       https://github.com/minetest/minetest/blob/master/doc/direction.md
17:53 rubenwardy       also search for roadmap in here: https://github.com/minetest/minetest/blob/master/.github/CONTRIBUTING.md#code
17:54 Wuzzy            oh. is the Roadmap label new?
17:54 rubenwardy       I think it's been around for a while, but it has a new purpose now
18:02 rubenwardy       hecks: #11130 might be a good one for you
18:02 ShadowBot        https://github.com/minetest/minetest/issues/11130 -- Fix rendering of allfaces nodes with transparent textures by x2048
18:05 rubenwardy       sfan5: why did you add possible close to #10430 ?
18:05 ShadowBot        https://github.com/minetest/minetest/issues/10430 -- Add core.MAX_MAP_GENERATION_LIMIT constant to builtin by kay27
18:06 rubenwardy       guessing the feature is flawed? In which case, it's been a month so can be closed :)
18:08 MTDiscord        <Warr1024> If they're talking about adding a constant to interpret mapgen_limit, then yeah, that'd be flawed.  I tried doing the math for it myself and I got it only like 90% working, but it's definitely not something that can be represented with a single constant.
18:08 rubenwardy       yeah that's what I suspected
18:10 MTDiscord        <Warr1024> I used mapgen_limit on a server and wanted to add a visual effect using particles at the world boundaries.  I tested it on a few values and got it to work for those test cases, but I kept running into fenceposty issues at different scales.  It seems as though very small worlds, or particular round-number effects may change where exactly the boundaries show up.
18:10 MTDiscord        <Warr1024> Probably there's some combination of margins and adjustments plus knowing when to > and when to >= that would fix it for me but I just never figured it out and didn't want to dive into the code for it at the time.
18:11 sfan5            rubenwardy: because of the alternate suggestions probably
18:11 MTDiscord        <Liso> #11130 seems to work fine. And the code doesn't seems to be bad. It has some weird looking glass because the backculling but removing it will break other blocks like water and leaves
18:11 ShadowBot        https://github.com/minetest/minetest/issues/11130 -- Fix rendering of allfaces nodes with transparent textures by x2048
18:12 hecks            I'm concerned about performance
18:12 rubenwardy       has anyone else noticed just how many word wrapping functions minetest has
18:13 Krock            not enough
18:13 rubenwardy       loads of elements have their own implementation, chat.cpp, minetest.wrap_*
18:13 rubenwardy       I need to finish #10853, but text is a pain
18:13 ShadowBot        https://github.com/minetest/minetest/issues/10853 -- Add WordWrapper util (with unit tests, ellipsis truncation, and fixes) by rubenwardy
18:14 hecks            hopefully this sorting is only done when necessary and only on the meshes that actually need it
18:14 hecks            quick check; do we use index buffers...
18:15 MTDiscord        <Warr1024> "text is a pain" ... haha, especially when you're dealing with unicode, and stuff like the fact that you might have UTF-16 text but "string length" functions interpret them as UCS-2...
18:16 rubenwardy       my word wrapper ignores RTL languages :(
18:16 rubenwardy       no wrapper in Minetest correctly deals with RTL languages anyway
18:16 hecks            it seems that we do use indexbuffers and DrawElements
18:16 hecks            in this case x2048's thing probably ought to sort primitives and not regenerate a mapblock
18:17 sfan5            it also changes which side of a node generates the face IIRC
18:17 sfan5            couldn't do that by changing the order
18:17 hecks            hmmmmm
18:18 hecks            can't that be handled with backface culling?
18:18 hecks            you can flip a primitive's winding order by manipulating an index buffer
18:18 hecks            just by changing it from clockwise to counter
18:19 hecks            let's say that
18:20 hecks            if it only regenerates alpha blend and nothing else and nobody suffers too much stutter, it's fine but with a "todo" attached
18:20 hecks            but if it lags even under these constraints, guess we'll need to avoid a full remesh
18:20 hecks            and if it regenerates meshes that don't need it, that's a priority to fix
18:21 hecks            I'll read it in a moment...
18:22 hecks            ok so it satisfies the basic condition
18:22 sfan5            re indexed rendering: Irrlicht is missing the ability to do non-indexed rendering
18:22 hecks            no DrawArrays?
18:22 hecks            that could be easily patched in
18:22 hecks            would help particles
18:22 sfan5            yes
18:22 hecks            although wait, particle sorting is best done with an index buffer...
18:22 sfan5            I think it's mentioned in the "recondier irrlicht workarounds" issue too
18:22 hecks            and particles usually need sorting
18:22 sfan5            reconsider*
18:22 sfan5            particle depth sorting is also broken
18:22 sfan5            and there's a PR for it or something
18:23 hecks            alright
18:23 hecks            link the issue because I might have something to add to it
18:23 hecks            the ejuor_control bone thing
18:23 hecks            if someone hasn't already
18:23 sfan5            #11040
18:23 ShadowBot        https://github.com/minetest/minetest/issues/11040 -- Revisit Irrlicht workarounds
18:23 hecks            there's hacks regarding bones in content_cao and they probably should be fixed properly
18:24 hecks            oh ok i posted it already
18:24 hecks            todo...
18:28 MTDiscord        <IhrFussel> Where do you plan to put the movement_speed_* settings instead? They are useful on servers since they also apply to clients
18:29 MTDiscord        <IhrFussel> I limit 'fast' for everyone that way
18:31 MTDiscord        <IhrFussel> I guess they could be included in the 'set_physics_override' method
19:05 celeron55        obviously in set_physics_override
19:06 celeron55        or something similar, if there's a reason to not use that exact one
19:06 sfan5            oh I get the point of it now
19:06 sfan5            we transparently multiply the movement speed in the .conf into the value set using physics overrides
19:06 sfan5            but obviously you could delegate to games
19:07 celeron55        yeah, the non-override values should probably be set with.... set_physics
19:07 celeron55        lol
19:09 celeron55        which could be extended to eg. a supplied physics lua script to the client, to instead do the physics in a separate sandboxed environment like my demo years ago
19:11 celeron55        https://github.com/celeron55/minetest/compare/297546af3d3b5b3a07a61ade041ad7c26e9a531d..1f4ca9df4219768d7678ccccd5e6ceba720e2930
19:41 rubenwardy       merging #11283 in 10
19:41 ShadowBot        https://github.com/minetest/minetest/issues/11283 -- Move build/android directory to root of project by NeroBurner
19:50 pgimeno          are there any plateforms where Minetest runs that lack support for LuaJIT?
19:51 MTDiscord        <appguru> @《Safari》
19:51 Krock            LuaJIT runs on more platforms than Minetest, all overlapping.
19:51 pgimeno          well, iOS lacks support for JIT
19:51 Krock            iOS is not supported, officially.
19:51 pgimeno          good
19:51 rubenwardy       what about Android?
19:52 pgimeno          works fine there (current 2.1 beta)
19:52 sfan5            pgimeno: I believe we discussed this before and I couldn't come up with one
19:52 rubenwardy       well, for iOS you can disable the JIT of LuaJIT
19:52 Krock            https://luajit.org/luajit.html  iOS and Android are listed there too
19:52 sfan5            (still I wouldn't be okay with dropping non-lj support)
19:52 pgimeno          Krock: it's a politics thing, not technical. App Store rules.
19:53 rubenwardy       in terms of LuaJIT causing security issues, is that just a JIT thing?
19:53 Krock            pgimeno: yes I know
19:53 rubenwardy       I believe there were concerns about having LuaJIT and SSCSM
19:53 sfan5            those were about the jit yes
19:54 pgimeno          rubenwardy: I believe so, if dofile, loadstring, require, etc. are disabled
19:54 rubenwardy       I think those are overridden but not disabled
19:54 pgimeno          otherwise there's also problems with bytecode
19:54 rubenwardy       overridden to not allow bytecode or reading from files
19:54 MTDiscord        <appguru> yep
19:54 sfan5            that's all taken care of by the sandbox we already have
19:55 rubenwardy       any sources on LJ vulns without bytecode or jit.*
19:55 rubenwardy       I guess there's spectre-esque issues
19:55 pgimeno          oh did you mean jit.* or JIT-compiled code?
19:56 rubenwardy       by JIT off I meant `jit.off()`
19:56 pgimeno          ah
19:56 Krock            but can't Lua also generate its own bytecode? perhaps only for newer version though, I'm not sure.
19:56 nrz              nice tech merging :) <3
19:56 pgimeno          with JIT off and with those disabled, it should be pretty safe
19:56 rubenwardy       I've merged 6 PRs today, shock
19:58 pgimeno          of course all assuming that FFI is not available, otherwise it's open season
19:58 MTDiscord        <Jordach> macOS/iOS will kill all unsigned JIT apps by the kernel
19:58 MTDiscord        <Jordach> requiring a developer license
19:58 MTDiscord        <Benrob0329> FFI is already behind mod security
19:59 celeron55        Krock: lua can run bytecode, but it can be disabled (and hopefully is disabled already)
19:59 celeron55        standard thing to do when sandboxing it
20:01 sfan5            random thought: we should write our own linter that catches obvious things like trailing whitespace, spaces vs tabs but leaves everything else alone
20:01 sfan5            it would then actually provide useful feedback for PRs
20:01 MTDiscord        <Benrob0329> Just a Luacheck conf would probably suffice, its the tool for that and has a lot of options.
20:02 sfan5            luacheck on C++ code?
20:02 MTDiscord        <Benrob0329> (Including comment-set ignoring of lines)
20:02 MTDiscord        <Benrob0329> Oh, no sorry. Lua was the last language talked about
20:02 rubenwardy       Yeah
20:02 sfan5            true, I didn't mention it
20:02 rubenwardy       I also think obvious stuff like pointer and brace placement makes sense
20:02 sfan5            but we do already have luacheck for builtin
20:20 MTDiscord        <josiah_wi> There have been attempts to fix the clang format checker, but to my knowledge all of them eventually died; why is that?
20:27 rubenwardy       it's hard to get it to exactly match Minetest's particular code style
20:28 rubenwardy       the closest I've gotten is basing it off of the Linux kernel's clang format config, but that's unfortunately GPL
20:28 v-rob            Ugh, the IRC logs for today are disgustingly long. So, Warr1024 and hecks are core developers now?
20:28 rubenwardy       clang-format just doesn't have a chill mode
20:28 rubenwardy       v-rob: yes
20:29 hecks            i guess?
20:29 hecks            call it the gamedev lobby
20:29 v-rob            Hoo boy, this should be interesting.
20:29 specing          rubenwardy: why are you people using LGPL for Minetest?
20:30 rubenwardy       \o/
20:30 hecks            instead of full GPL? or instead of MIT/BSD
20:30 specing          Instead of full GPL or AGPL, even
20:30 hecks            full GPL would be hairy with regards to the murky definition of linking code
20:30 rubenwardy       Minetest isn't a library. The only real use LGPL has is when wrapping Minetest in a proprietary Java wrapper to show ads on Android
20:30 hecks            AGPL would be a showstopper for me and a nightmare to enforce, many server admins make tiny changes and that's just a mess
20:31 hecks            it's not a library but I'm sure you could find a lawyer who defines the running lua code as linked
20:32 hecks            LGPL avoids all issues and provides decent freedom protection still
20:32 specing          lmao, so put in a linking exception if that ever becomes an issue
20:32 hecks            there isn't much incentive to keep fixes private anyway
20:32 rubenwardy       running Lua code isn't a linkage, I believe the gnu website has an example of thise
20:33 specing          hecks: though as you mention this, SpringRTS is GPL-something and the devs consider lua scripts as derivative works and also covered by the GPL-something
20:33 hecks            only crappy part is unscrupulous android app developers making ad-ridden versions
20:33 pgimeno          <rubenwardy> the closest I've gotten is basing it off of the Linux kernel's clang format config, but that's unfortunately GPL   <-- is that a problem? you're not linking to it are you?
20:33 rubenwardy       it's not strictly a problem, but mixes up the repo
20:33 specing          hecks: so? convert to agpl already
20:33 sfan5            reminder that we have openssl code in our codebase
20:33 sfan5            with who knows what license
20:34 specing          There's no reason to use LGPL other that to say loudly that you wont bother enforcing anything
20:34 specing          But really, do you like seeing ad-wrapped MT on phones and/or heavily modified proprietary servers?
20:34 specing          if you do,then keep the LGPL
20:36 hecks            if someone makes ad wrapped clones as a scam, will a license really deter them?
20:36 specing          With the AGPL, all it would take is one sufficiently pissed off contributor to put a stop to that
20:36 v-rob            No
20:36 hecks            do we even have the resources to enforce this?
20:37 v-rob            No
20:37 hecks            do we care about phone users falling for "free minecraft" apps?
20:37 rubenwardy       the answer for that is very much no, because there are already many violating apps on google play
20:37 hecks            probably no as well
20:37 hecks            I'll just have a disclaimer on the server, if you paid for this, you got scammed
20:37 v-rob            Well, I care, but I can't do anything about it
20:38 pgimeno          sfan5: according to /usr/share/doc/openssl/copyright it's BSD 6(?!)-clause and BSD 4-clause, IIRC that's incompatible with the GPL, not sure about the LGPL.
20:39 sfan5            https://github.com/minetest/minetest/blob/master/src/util/sha256.c#L4 "the OpenSSL license [found in ../../LICENSE]."
20:39 sfan5            very useful thanks
20:39 hecks            the mythical 6 clause license of the ancients
20:40 sfan5            I know other LGPL programs link to it so it'll be compatible
20:41 pgimeno          a frigging SHA-256 routine? I'm sure there are hundreds with very liberal license
20:41 pgimeno          +s
20:42 pgimeno          hm, for what I see, no, the LGPL has the same problem as the GPL with the advertising clause. See https://www.gnu.org/licenses/gpl-faq.en.html#OrigBSD about the reason and https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html section 10 on the same wording used in the LGPL as in the GPL.
20:43 specing          hecks | I'll just have a disclaimer on the server, if you paid for this, you got scammed
20:43 specing          hecks: and what will the player[s] do?
20:44 specing          they can't do anything. The "scam" was legal
20:44 v-rob            Well, often they aren't
20:44 hecks            feel like an idiot? it's a phone user, I don't really care
20:47 pgimeno          https://code.woboq.org/userspace/glibc/crypt/sha256.c.html - LGPL 2.1 ; https://github.com/B-Con/crypto-algorithms public domain
20:48 * celeron55      is licensed under the BSD 12-clause license
20:49 * pgimeno        is licensed under the sanity clause
20:50 * v-rob          is forking celeron55... please wait
20:51 v-rob            sfan5: I made the change to irr#41, could you finish looking over it?
20:51 ShadowBot        https://github.com/minetest/irrlicht/issues/41 -- Fix `getViewPort` returning incorrect results by v-rob
20:52 sfan5            hm a dimension is not a rect why did I propose that
20:52 v-rob            Because the upper left corner is always (0, 0)
20:53 sfan5            >setViewPort(core::recti(0, 0, size.Width, size.Height));
20:53 sfan5            intended or did you forget this one?
20:53 v-rob            That's not setViewPortRaw
20:53 sfan5            exactly
20:53 v-rob            It doesn't use OpenGL coordinates (which seem to be upside down on the Y axis)
20:54 v-rob            But setRenderTarget does internally, so it uses Raw
20:57 sfan5            so it's intended that OnResize calls setViewPort (not raw!) which clips against the current render target?
20:57 sfan5            sorry if I'm asking stupid questions
21:03 sfan5            (because I thought the point was to s/CacheHandler->setViewport/setViewPortRaw/)
21:03 v-rob            Um, I had to think for a moment, and I guess that could lead to incorrect behaviour if a viewport should be preserved between separate driver->begin/endScene, but no one should do that. But otherwise, OnResize will essentially update the viewport (which could be a render target pretending to the the screen) to the new screen size, which is correct.
21:04 sfan5            CNullDriver::OnResize sets the viewport but only if it matches the screen size, huh?!
21:06 v-rob            Wait, that doesn't make much sense. Why is it doing that?
21:06 sfan5            who knows
21:06 v-rob            I don't like Irrlicht
21:10 v-rob            I guess that code is a lame attempt to ensure that the current render target is the screen or a render target pretending to be the screen.
21:10 sfan5            v-rob: added 2 small comments, I swear these are the last
21:11 v-rob            OK, yeah, OnResize doesn't need the setViewPort, you are correct.
21:12 sfan5            if you change CNullDriver that is, or do you mean even without that?
21:12 sfan5            ahh wait
21:12 v-rob            CNullDriver works since it sets ViewPort if it's probably the screen
21:12 sfan5            yeah your explanation makes sense
21:12 sfan5            a bit hacky but it has purpose
21:15 v-rob            OK done
21:17 v-rob            Thanks
21:20 sfan5            the global setting layers are never deallocated and now that my PR does it differently valgrind complains about it
21:20 sfan5            ugh
21:21 MTDiscord        <IhrFussel> If MT used AGPL it still wouldn't affect custom mods right? Then I wouldn't care as long as I can keep the majority of my mods unique
21:21 v-rob            Somehow, I doubt Minetest will be relicensed
21:21 v-rob            Just a guess judging by the numerous discussions in the past.
21:22 MTDiscord        <IhrFussel> I know that but just wanted to know in case it ever happens
21:22 v-rob            We're very good at discussing not-going-to-happen things here at Minetest, such as name changes
21:22 sfan5            there's still opportunity to rename it to Mesetint
21:22 MTDiscord        <IhrFussel> Is there any license that would also affect mods written for the software?
21:28 specing          It doesen't have to be "relicensed"
21:29 specing          just new code under AGPL that will absorb the LGPL one
21:31 Wuzzy            rubenwardy: now the only thing in my pr is the version check. i have no idea what to do ....
21:55 MTDiscord        <Warr1024> So I started looking into that a bit
21:55 MTDiscord        <Warr1024> it seems as though the server has a lot of places where it knows the client's proto version, but the reverse does not seem true
21:55 MTDiscord        <Warr1024> unless it gets stuffed in some other variable of some other name
21:56 MTDiscord        <Warr1024> It seems as though maybe the design here is that the server just tells the client that its protocol version is the same as the client's, and it's the server's responsibility to protocol-downgrade where necessary
21:56 sfan5            sounds accurate
21:56 MTDiscord        <Warr1024> If that's true then protocol version wouldn't be workable in this case.
21:57 sfan5            the client says I support [A, B] the server picks an X out of that
21:57 MTDiscord        <Warr1024> I suppose though that a server would receive PV 40 from a 5.5 client but only be able to talk 39, and protocol upgrade and downgrade are different beasts
21:58 MTDiscord        <Warr1024> so if a newer client can connect to an older server at all then there must be some place this is handled somewhere and I'm just not finding it yet?
21:58 MTDiscord        <Warr1024> TOCLIENT_HELLO definitely includes a protocol version
21:58 MTDiscord        <Warr1024> I just need to figure out where, if anywhere, this is already stored
21:59 sfan5            it contains the version the server has chosen
21:59 MTDiscord        <Warr1024> okay, searching for /protocol_version/i only works well if the client doesn't decide to name the variable /proto_ver/i
21:59 sfan5            it will never be higher than the max version supported by the client
21:59 MTDiscord        <Warr1024> In this case the client would ask for 40, but the server would only be able to send 39, so we'd still be able to detect a server that wouldn't yet know about basic_debug this way.
21:59 sfan5            wait is this for 5.5 client on 5.4 server?
22:00 sfan5            ah yes
22:00 sfan5            the reverse doesn't make sense anyway...
22:01 MTDiscord        <Warr1024> u16 Client::m_proto_ver seems to be where the client remembers this.
22:02 MTDiscord        <Warr1024> Wuzzy's checks are all in game and gameui, so all I need to do is figure out how the 2 are connected to each other...
22:02 sfan5            game should have a m_client or something
22:05 MTDiscord        <Warr1024> client has a gameui
22:05 sfan5            you can't go Client -> Game
22:05 MTDiscord        <Warr1024> it seems that gameui must somehow get the flags to game, but it looks like the wuz has already figured that much out somehow...?
22:05 sfan5            only the other way
22:05 sfan5            wait
22:05 sfan5            ignore what I said
22:05 MTDiscord        <Warr1024> okay, I'll check game again and see if it has a client...?
22:06 MTDiscord        <Warr1024> game does have a gameui
22:06 sfan5            I was thinking you'd check m_client->m_proto_ver somewhere in the game to override the debug check thingy
22:06 MTDiscord        <Warr1024> yeah, if there's a client->gameui instance, then I should be able to just push the flag in from there...
22:07 sfan5            why gameui?
22:07 MTDiscord        <Warr1024> I dunno, that's where I found references to basic_privs
22:08 MTDiscord        <Warr1024> er basic_debug
22:08 MTDiscord        <Warr1024> if I can figure out how client and game talk to each other then I could do it there
22:08 MTDiscord        <Warr1024> it looks like game check m_game_ui->flags anyway?
22:08 MTDiscord        <Warr1024> so gameui seems to be the primary "owner" of this option
22:09 MTDiscord        <Warr1024> oh no wait, there's a gameui option probably for whehter it's requested, and a client->checkPrivilege() call for whether it's allowed
22:09 MTDiscord        <Warr1024> maybe checkPrivilege just needs to check proto version if the priv name is basic_debug
22:10 MTDiscord        <Warr1024> bool checkPrivilege(const std::string &priv) const { return (m_privileges.count(priv) != 0); }
22:10 MTDiscord        <Warr1024> in client.h
22:11 MTDiscord        <Warr1024> seems like it could just be something like return ((priv == "basic_debug") && (m_proto_ver < 40)) || (m_privileges.count(priv) != 0);
22:11 sfan5            you can call client->getProtoVersion() from there
22:11 MTDiscord        <Warr1024> oh, if there's a getter then that works too
22:12 MTDiscord        <Warr1024> wrapping it in a nice allowBasicDebug() or something would be nice instead of copypasta all over, I gues.
22:13 sfan5            that's the only place you need to do it
22:13 MTDiscord        <Warr1024> So basically every if (client->checkPrivilege("basic_debug")) would become if (client->getProtoVersion() >= 40 && !client->checkPrivilege("basic_debug"))
22:13 MTDiscord        <Warr1024> or are you saying to do it inside the checkPrivilege call?
22:13 sfan5            I think that's better yes
22:14 sfan5            even better: you could insert the privilege into the list when the packet is received
22:14 MTDiscord        <Warr1024> Hmm, I thought about doing that
22:14 MTDiscord        <Warr1024> I'll take a peek at how priv receiving happens
22:15 sfan5            src/network/clientpackethandler.cpp
22:15 sfan5            ctrl+f privilege or something
22:16 MTDiscord        <Warr1024> Yeah, adding 2 lines of code to clientpackethandler looks like it'll be easey
22:16 sfan5            don't forget the explanatory comment ;)
22:17 MTDiscord        <Warr1024> Heh, I was gonna turn the code over to Wuzzy once I did some basic verification of it and let him style it up :-)
22:18 MTDiscord        <Warr1024> https://paste.ubuntu.com/p/bF54KhTXZT/
22:19 MTDiscord        <Warr1024> I'm making the assumption there that either a 5.4 server will never send a basic_debug priv, or that duplication in that list is either already handled (like maybe it's a set or something under the hood) or at least that it won't cause problems.
22:20 MTDiscord        <Warr1024> If that's wrong then it shouldn't be hard to fix though, just my machine is already stuttering from the build so I'm not gonna go and try to perfect it just yet.
22:21 sfan5            it's an std::unordered_set<std::string>
22:22 MTDiscord        <Warr1024> nice
22:22 MTDiscord        <Warr1024> I like when people use set types to store set-typed data instead of arrays or naive lists :-)
22:30 MTDiscord        <Warr1024> Wuzzy: https://paste.ubuntu.com/p/2PrvfgY7hz/ I just tested this and it seemed to work: 5.5-dev SP, coords did not show, connected to a 5.4 server, coords showed, all as expected based on my understanding.
22:35 MTDiscord        <Warr1024> I have some concerns that that protocol version bump thing is going to result in some politicking as people who were not part of the conversation want to know what this has to do with protocols.
22:35 MTDiscord        <Warr1024> Protocols are not just about serialization formats; they're about interpretation and meaning too.
22:36 sfan5            I have never seen anyone question protocol bumps
22:37 MTDiscord        <Warr1024> well, I think enough of us agreed that we were okay with this general idea that the only question at this point should be the exact code review: formatting, comments, squash, stuff like that.
22:42 MTDiscord        <Warr1024> If nobody questions protocol bumps then I'd be happy to see them used more :-)
22:45 Wuzzy            OK thanks, added to the PR. Please have fun with the new PR!
23:17 rubenwardy       any objections to ignoring `/irrlicht` in the repo
23:17 rubenwardy       actually, I suppose it should be `/lib/irrlicht` maybe
23:18 rubenwardy       also, reviewed and approved #9315
23:18 ShadowBot        https://github.com/minetest/minetest/issues/9315 -- Require 'basic_debug' priv to view gameplay-relevant debug info (2nd try), require 'debug' priv to view wireframe by Wuzzy2
23:43 Wuzzy            after all those years ... finally approval
23:58 rubenwardy       Wuzzy can finally quit