Minetest logo

IRC log for #minetest-dev, 2021-06-21

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

All times shown according to UTC.

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:20 kilbith joined #minetest-dev
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:25 queria joined #minetest-dev
02:31 queria^clone joined #minetest-dev
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
03:30 kilbith joined #minetest-dev
03:56 kilbith_ joined #minetest-dev
04:02 MTDiscord1 joined #minetest-dev
04:02 T^4im joined #minetest-dev
04:03 Alias2 joined #minetest-dev
04:03 rubywarden joined #minetest-dev
04:09 specing joined #minetest-dev
04:13 kilbith joined #minetest-dev
04:27 wsor4035 joined #minetest-dev
04:39 v-rob joined #minetest-dev
05:04 kilbith joined #minetest-dev
05:16 nrz joined #minetest-dev
08:01 specing_ joined #minetest-dev
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:11 calcul0n__ joined #minetest-dev
09:24 hecks joined #minetest-dev
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 kilbith joined #minetest-dev
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 entuland joined #minetest-dev
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 Fixer joined #minetest-dev
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:44 calcul0n_ joined #minetest-dev
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 Wuzzy joined #minetest-dev
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 Noisytoot joined #minetest-dev
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:31 Alias joined #minetest-dev
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:30 olliy joined #minetest-dev
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 nrz joined #minetest-dev
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 nrz joined #minetest-dev
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 appguru joined #minetest-dev
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:36 lhofhansl joined #minetest-dev
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 kilbith joined #minetest-dev
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 kilbith_ joined #minetest-dev
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 queria joined #minetest-dev
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 specing joined #minetest-dev
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 Jordach joined #minetest-dev
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
18:34 Noisytoot joined #minetest-dev
18:36 kilbith joined #minetest-dev
18:40 kilbith__ joined #minetest-dev
18:48 kilbith_ joined #minetest-dev
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:08 v-rob joined #minetest-dev
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:26 queria joined #minetest-dev
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 pgimeno joined #minetest-dev
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:07 pgimeno joined #minetest-dev
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 pgimeno joined #minetest-dev
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:16 pgimeno joined #minetest-dev
21:17 v-rob Thanks
21:17 pgimeno joined #minetest-dev
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 YuGiOhJCJ joined #minetest-dev
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:04 Alias2 joined #minetest-dev
23:11 calcul0n joined #minetest-dev
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

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