| 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 |
