| Time |
Nick |
Message |
| 00:13 |
hmmmm |
<rubenwardy> I believe we decided on a cutoff of high end 12 years ago I guess this is reasonable |
| 00:14 |
hmmmm |
removing features just reminds me of nightmares where i needed that feature, and then it has dependencies that require the old version as well... but wait, those don't build because of some other dependencies that broke along the way... but you can't compile a couple of those dependencies because they require an older compiler... et cetera |
| 00:14 |
hmmmm |
you need to recreate the entire toolchain from that era to effectively get what you need back |
| 00:15 |
hmmmm |
for some applications it's harder, sure, (e.g. try building an old version of Chromium to practice exploit development, it's an adventure all by itself) |
| 00:16 |
hmmmm |
it sucks that voxelland is dead because that would have filled the niche i am describing |
| 00:16 |
hmmmm |
but yeh most people who would play minetest probably aren't using intel gma graphics anymore |
| 00:18 |
hmmmm |
kinda wonder if any of this matters since somebody's gonna come along and rewrite minetest in rust |
| 00:18 |
hmmmm |
lmfao |
| 00:27 |
rubenwardy |
win32 is often used to play very old games for this reason |
| 00:27 |
rubenwardy |
it doesn't break much |
| 00:28 |
hmmmm |
well how about a compromise |
| 00:28 |
hmmmm |
can somebody start creating/maintaining docker images with old stable releases installed? |
| 00:29 |
schwarzwald[m] |
I'm awed that people have the time and dedication to maintain a project like this as is. If someone came and rewrote the thing to the same quality in Rust I would be mindblown. |
| 00:30 |
hmmmm |
ohhhh you don't understand the depth of some peoples' obsession with rust |
| 00:31 |
rubenwardy |
It doesn't have the same goals, but Veloren exists |
| 00:31 |
schwarzwald[m] |
Someday people will hate Rust. |
| 00:32 |
schwarzwald[m] |
Well, maybe not... I don't know anyone who hates C, come to think of it. |
| 00:33 |
rubenwardy |
Hate is a strong emotion |
| 00:33 |
hmmmm |
i hate rust |
| 00:34 |
rubenwardy |
Try wk40 |
| 00:34 |
rubenwardy |
*wd40 |
| 00:34 |
hmmmm |
but i sorta have to deal with it because the writing's on the wall with linux's adoption of it |
| 00:35 |
rubenwardy |
I haven't had much opportunity to use it but I've enjoyed what I've seen |
| 00:36 |
MTDiscord |
<savilli> I believe that minetest will be replaced with other voxel engine written in Rust rather than someone will rewrite it |
| 00:36 |
MTDiscord |
<savilli> It has too much legacy |
| 00:36 |
hmmmm |
minetest IS the voxel engine |
| 00:36 |
MTDiscord |
<savilli> Yup, a voxel engine that will die one day |
| 00:37 |
hmmmm |
but the games live on? |
| 00:38 |
MTDiscord |
<savilli> Nice of them will be rewritten for other engine |
| 00:38 |
hmmmm |
yeah i could see that, but the way the API works might force the engine to work in a specific manner |
| 00:38 |
MTDiscord |
<savilli> Or someone will bother to add a compat layer |
| 00:38 |
MTDiscord |
<savilli> How many minetest games in active development do you know? |
| 00:38 |
hmmmm |
not even a slightest clue |
| 00:39 |
hmmmm |
the number of revisions i've made to the schematic format was like... 4... yet it required a ton of compatibility support |
| 00:39 |
MTDiscord |
<savilli> Their live cycle is rather small |
| 00:39 |
MTDiscord |
<savilli> *life |
| 00:39 |
hmmmm |
it's likely that it would just be recreated using the new api for the new game engine than imported over |
| 00:40 |
MTDiscord |
<savilli> One day, people will consider engines other than minetest, and old games will just die |
| 00:40 |
hmmmm |
that's not necessarily a bad thing i suppose |
| 00:41 |
schwarzwald[m] |
It'd be nice to have some kind of roadmap for maintenance and feature work with estimates of priority and work required. |
| 00:43 |
hmmmm |
as long as somebody makes an attempt to preserve the past (a manner like i described above would be sufficient imho), i guess i would find removing meshgen cache acceptable |
| 00:44 |
MTDiscord |
<savilli> Veloren looks quite nice actually. I'm impressed. |
| 00:44 |
schwarzwald[m] |
What's the downside of keeping the feature? |
| 00:44 |
hmmmm |
or what if you trim down meshcache for specific common meshes? 2 in particular |
| 00:44 |
hmmmm |
a fully solid mapblock, and a fully empty mapblock |
| 00:45 |
hmmmm |
downside to keeping the feature? none in my opinion, only time somebody will complain about it is when something doesn't work with it |
| 00:45 |
MTDiscord |
<Warr1024> Re: docker images with old versions, yeah, a few of us are already doing this. You just have to wait about 10 years for the versions we started on to become "old" too now. |
| 00:46 |
MTDiscord |
<Warr1024> In princple someone could extend the work backwards in time, but it would have to be somebody passionate about that history. |
| 00:46 |
hmmmm |
if there are quirks that it happens with when paired with newer gpus, could just make a disclaimer |
| 00:47 |
MTDiscord |
<Warr1024> There is the standard downside to keeping any feature, of course, i.e. that you now have one more feature to maintain, work around when adding other things, wait for it to compile, deal with the potential for it to kick out bugs, etc. |
| 00:47 |
hmmmm |
that's good that others have the foresight to keep a working copy of past MTs |
| 00:47 |
hmmmm |
lmao you've already lost the compilation speed war by virtue of using C++ |
| 00:47 |
hmmmm |
and making the system of header files a wreck |
| 00:48 |
MTDiscord |
<Warr1024> I've only ever seen like one or two really hardcore "archivists" who keep very old stuff in working order going way back in history, but I've seen a few people get really ancient MT versions to compile, and apparently they work fine. |
| 00:48 |
schwarzwald[m] |
Why don't we fix the header system instead of axing the feature? |
| 00:48 |
hmmmm |
i would begin to worry about compilation speed when it gets actually painful like a web browser |
| 00:49 |
MTDiscord |
<Warr1024> Even if you delete features or functionality wholesale, it will always be in the history, and deletions can always be reverted. |
| 00:49 |
hmmmm |
erm you misunderstand, the header system is one of the systemic issues leading to slow compilation |
| 00:49 |
hmmmm |
i'm not saying that's the reason for removing the feature |
| 00:50 |
hmmmm |
yeah that's the argument i heard back then as well |
| 00:50 |
hmmmm |
the thing is, out of sight == out of mind, and without old code being there (even block commented out with some #if 0s) people tend to forget what was tried, what didn't work, why not, and repeat history again |
| 00:51 |
hmmmm |
the lineage of the code gets lost when the file gets split into new files as well |
| 00:51 |
hmmmm |
git blame stops working, i've seen it with nerzuhl's first 'contributions' |
| 00:52 |
hmmmm |
people run way too fast with scissors imho |
| 00:52 |
MTDiscord |
<Warr1024> If you're never willing to delete old features, then you basically discourage any developer from adding any new features, because you raise how certain they need to be that the new feature is really exactly what they want. Eventually you raise the bar high enough that you'll ONLY ever have old features. |
| 00:52 |
schwarzwald[m] |
I'm suggesting focusing effort on improving the compilation as opposed to removing a feature. Although, improving the compilation probably isn't that pressing either. |
| 00:52 |
hmmmm |
isn't that good?? could you imagine the linux kernel being developed like that? |
| 00:53 |
MTDiscord |
<Warr1024> you mean not developed? |
| 00:53 |
MTDiscord |
<Warr1024> Of course I can imagine it; I run Debian. |
| 00:54 |
hmmmm |
no i mean, people keep repeating mistakes because they didn't know why feature XYZ wasn't that way to begin with |
| 00:54 |
hmmmm |
the only reason why linux gets away with it I think is because there's just such a wide body of knowledge |
| 00:54 |
hmmmm |
not so much with MT |
| 00:54 |
rubenwardy |
It's silly to keep a feature with no affect that no one uses, if that is the case |
| 00:54 |
schwarzwald[m] |
I don't care whether the feature is removed, but I'd like to find others who are willing to have some formal organization of work rather than doing things haphazardly. |
| 00:55 |
hmmmm |
you need to put rules in place because nobody is going to be principled in their development otherwise |
| 00:55 |
hmmmm |
everybody wants to add new stuff, nobody wants to maintain |
| 00:56 |
hmmmm |
nobody wants to fix the microstudder they added when they so helpfully "fixed" some STL container usage |
| 00:56 |
hmmmm |
nobody wants to write documentation or a story |
| 00:56 |
MTDiscord |
<Warr1024> Personally, I'd love to see some bugs get fixed, and some features we already have start to work well. I hear a lot of people talk about adding stuff that MT doesn't have, but I'd rather it complete delivery on a selection of existing promises first... |
| 00:57 |
hmmmm |
which you won't get from this bazzar model of development |
| 00:58 |
hmmmm |
I don't think it'll ever get high quality until there's actual funding behind it |
| 00:59 |
hmmmm |
I think the best thing MT could do for itself as a project is to seek industry partners somehow. that one guy who wanted to product-ize MT by creating an educational game with a rich set of game assets seemed to be our closest bet |
| 00:59 |
MTDiscord |
<Warr1024> Bazzar model doesn't mean everybody develops new features only, it means everybody scratches their own itch. It's basically just a question of whether somebody will be bothered enough by something working half-ass to actually fix it. |
| 01:00 |
schwarzwald[m] |
I turn on a couple aggressive warning flags and the list of warnings doesn't fit in my terminal history. People may argue that those warnings aren't indications of errors and some are false positives, but warnings aren't supposed to indicate errors, they're supposed to indicate code that is following patterns that often lead to errors. I think having so many warnings is an indication of sloppy work at a really fine-grained level. |
| 01:00 |
MTDiscord |
<Warr1024> I came pretty close to attempting a fix of the "ABM scheduler is trash" bug, but it went just a little too deep into the system for me to work on without risking actually learning C++ in the process. |
| 01:00 |
hmmmm |
some of those warnings are bollocks though, in which case it's best to add a comiler flag or pragma to ignore them |
| 01:00 |
schwarzwald[m] |
At a higher level, there's a big list of Coverity reports. |
| 01:01 |
hmmmm |
Warr1024: No, practically speaking, nobody will care about fixing and maintaining aside from the overworked core devs who actually want to see MT succeed |
| 01:01 |
MTDiscord |
<Warr1024> Gamedevs |
| 01:02 |
MTDiscord |
<Warr1024> I've got 2 core issues that are holding my game back. |
| 01:02 |
MTDiscord |
<Warr1024> One of them, at least, it sounds like there's already core dev attention on |
| 01:02 |
MTDiscord |
<Warr1024> the other one, nobody seems interested in, so I went in to tackle myself, but I'm just not ready for it yet. |
| 01:02 |
hmmmm |
gamedevs are gamedevs becaue they want an outlet for their creativity, I think most good ones are going to prefer making their own game instead of fixing somebody elses' |
| 01:02 |
hmmmm |
oh, you mean developers for the MT games |
| 01:03 |
MTDiscord |
<Warr1024> Yeah |
| 01:03 |
hmmmm |
yeah, that's one small demographic who would also help |
| 01:03 |
MTDiscord |
<Warr1024> Haha, how many of us are there? Like, 3 to 5 maybe? |
| 01:03 |
hmmmm |
right |
| 01:04 |
hmmmm |
you have no idea how guilty it makes me feel to just talk and not put in code myself while talking about how more people need to put in the code |
| 01:04 |
hmmmm |
maybe one day after I retire lol |
| 01:04 |
MTDiscord |
<Warr1024> We periodically get drafted into core roles. Some "stick" and end up focusing on engine dev and then forget about their games, others end up staying with game dev and don't do as much core stuff. |
| 01:05 |
schwarzwald[m] |
It comes down to a question of how much we are willing to invest in things like fixing warnings in order to maintain things long term. But I don't think we're putting too much effort into stuff like that rn. |
| 01:05 |
MTDiscord |
<Warr1024> I've only "soft" given up on fixing the ABM scheduler, myself :-D |
| 01:06 |
hmmmm |
you know what I wanna see fixed in my lifetime? |
| 01:06 |
hmmmm |
if i could only have one feature |
| 01:06 |
hmmmm |
i wanna make envlock mostly go away |
| 01:07 |
hmmmm |
maplock i mean |
| 01:07 |
MTDiscord |
<Warr1024> So, like, parallel access to the map? |
| 01:07 |
hmmmm |
ye |
| 01:07 |
hmmmm |
see I had this freaky concept long ago on how to make maplocks per-block |
| 01:07 |
rubenwardy |
Rejoin as a core dev, fix that, and then retire and sleep happy |
| 01:07 |
hmmmm |
using very lightweight sync primitives |
| 01:07 |
hmmmm |
that would be something similar to RCU but not quite |
| 01:08 |
hmmmm |
had the idea, but never coded it, and then got busy |
| 01:08 |
MTDiscord |
<Warr1024> Do you need to be a core dev? You can work on it without being a core dev, and you only need the core dev thing if you want to push the PR through with a 50% reduction in red tape. |
| 01:08 |
hmmmm |
lol sure |
| 01:08 |
MTDiscord |
<Warr1024> but if you could eliminate that big of a lock, I think you'd have a pretty good case either way. |
| 01:08 |
hmmmm |
yeah, next time I get that itch |
| 01:08 |
hmmmm |
so has anybody done the active mapblock idea? |
| 01:09 |
MTDiscord |
<Warr1024> We got multiple Lua threads now, so I guess it would be interesting if the "worker" lua states could ask for mapblock locks independently |
| 01:10 |
schwarzwald[m] |
Warr, I have a little time on Sundays I'd be willing to use for pairing on the ABM scheduler thing. I know the programming language at a basic level, and it sounds like you would have an idea of the algorithm perhaps. |
| 01:10 |
MTDiscord |
<Warr1024> I think I opened an issue for it long ago. It might be buried. It might have been closed with a half measure. |
| 01:13 |
MTDiscord |
<Warr1024> I want to stagger ABM runs across multiple globalsteps. Right now, when an ABM's timer goes off, it tries to batch every active mapblock into its queue and process them all in the current globalstep. I'd like to at least allow modders the option of spreading that out. It's a bit tricky because we run all ABMs per mapblock, not all mapblocks per ABM, so spreading them out is not so simple. |
| 01:13 |
MTDiscord |
<Warr1024> There are also implications, i.e. modders would have to opt IN, because some may have made the assumption that their ABMs run everywhere in one burst the way it is now. |
| 01:14 |
MTDiscord |
<Warr1024> It seems to me like we might need a queue of some kind, and I don't know the C++ standard library, or the preferred way to declare data structures like that, well enough. |
| 01:14 |
MTDiscord |
<Warr1024> I think I know the ABM system itself mildly well now; at least, I was able to successfully test my "pass all node positions to Lua in one table instead of calling the callback hundreds of times" thing. |
| 01:15 |
schwarzwald[m] |
If the problem and solution are well specified, implementation should hopefully just be busywork. |
| 01:15 |
MTDiscord |
<Warr1024> Though that was "successful" in the sense of "prove that it actually didn't make a difference." |
| 01:16 |
MTDiscord |
<Warr1024> I'll have to read through the code again sometime to make sure I remember/understand how ABMs are scheduled right now. If I'm going to defer execution of anything, I need to have a good idea exactly what it is I'm deferring and what I can't. |
| 01:16 |
schwarzwald[m] |
What's the behavior right now if the processing of the batched map blocks takes longer than the globalstep? |
| 01:17 |
schwarzwald[m] |
Or maybe we don't know? xD |
| 01:17 |
MTDiscord |
<Warr1024> If you have a globalstep of 0.1, an ABM timer interval of 1.0, and an ABM time budget of 20%, then what happens is most of your globalsteps are 0.1 (assuming no other lag sources) but if you have heavy ABMs, then you'll get one step of like 0.25 or 0.3 when ALL the ABMs fire. I'd much rather use up 20% of each globalstep for ABMs instead, if I can swing it. |
| 01:18 |
MTDiscord |
<Warr1024> Default ABM time budget is 20%, and default ABM timer interval is 1.0s, so that means that ABMs run one big 200ms chunk once every second. For some servers, that's quite a big lag spike. |
| 01:20 |
schwarzwald[m] |
Ah, so what happens is that all the ABMs run in 1 of every 10 globalsteps? |
| 01:20 |
MTDiscord |
<Warr1024> with default settings, basically, yes. |
| 01:21 |
schwarzwald[m] |
And your idea is to spread the ABMs out over all the globalsteps to avoid those big spikes? |
| 01:21 |
MTDiscord |
<Warr1024> On my server, I run a step of 0.05, so I get most of my steps at that size except one step in the 0.2 to 0.25 range each second, and for some machines you can really see the timing judder, and it's quite distracting, and makes some things harder to do, like debugging in-game circuits. |
| 01:22 |
MTDiscord |
<Warr1024> Right. |
| 01:22 |
schwarzwald[m] |
Sounds like a simple enough feature. "how hard can it be" |
| 01:22 |
MTDiscord |
<Warr1024> Right now, it runs something like 400 mapblocks in 0.2 seconds or something. If I could run like 50 mapblocks every 0.05 seconds, I'd be in good shape. |
| 01:22 |
MTDiscord |
<Warr1024> Well, I don't know how hard it can be, but I know at least some of how easy it can't be. |
| 01:23 |
MTDiscord |
<Warr1024> In theory I guess we could make it a global toggle, even, i.e. we don't need to allow modders to choose per-ABM whether to stagger or not, we could just allow a server owner to turn it on or off for all. Most server owners I know who muck about to try to fix ABM performance issues are making much more drastic changes already. |
| 01:24 |
MTDiscord |
<Warr1024> I've looked into some of the almost-alternatives for ABMs but they all have failure cases that only an ABM provides the full "eventually-reliable" firing necessary to recover form. |
| 01:25 |
schwarzwald[m] |
> 20% of each globalstep for ABMs instead |
| 01:25 |
schwarzwald[m] |
Doing literally this in the engine would probably be the simplest solution, right? But would break the behavior for people who want them to run intermittently? |
| 01:26 |
schwarzwald[m] |
So we have to keep track of which ABMs use the old behavior, and which ones use the new behavior? |
| 01:30 |
schwarzwald[m] |
Is that 20% default time budget already the time budget for ABMs in that particular globalstep run? Maybe this boils down to "do (if there's enough time budget) this ABM every x globalsteps" |
| 01:48 |
MTDiscord |
<Warr1024> Keeping track per-ABM would probably complicate the ABM system a lot. It might be enough to just make it a single global toggle. Then server owners can turn it on, try it out, and report to us what benefits or breakages they see. |
| 01:49 |
MTDiscord |
<Warr1024> It's possible that ABMs are written naively enough that they break ... but it's actualy likely that ABMs are generally written SO naively that they DON'T break because their authors never even tried to take the old behavior into account to rely on. |
| 01:49 |
MTDiscord |
<Warr1024> At least, a single global toggle might be the fastest way to start to get some field testing on it. |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:34 |
|
calcul0n_ joined #minetest-dev |
| 07:08 |
|
vampirefrog joined #minetest-dev |
| 08:22 |
|
Warr10248 joined #minetest-dev |
| 08:27 |
|
Fixer joined #minetest-dev |
| 08:32 |
|
Fixer joined #minetest-dev |
| 08:40 |
|
YuGiOhJCJ joined #minetest-dev |
| 08:41 |
|
ivanbu joined #minetest-dev |
| 08:41 |
|
ivanbu joined #minetest-dev |
| 09:03 |
|
Warr1024 joined #minetest-dev |
| 09:17 |
|
appguru joined #minetest-dev |
| 09:18 |
|
Fixer_ joined #minetest-dev |
| 10:06 |
|
Wuzzy joined #minetest-dev |
| 10:06 |
Wuzzy |
#11115 needs adoption. anyone interested? |
| 10:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/11115 -- Add support for single and dead-end raillike textures by Wuzzy2 |
| 10:22 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:30 |
Zughy[m] |
hmmmm: I do agree about the bazaar aspect and the educational funds (see kilbith, probably the one really earning money out of MT), but there is no common will. You ask sfan5 and Krock and they tell you they don't care about money. You ask c55 and you're lucky if they answer in the first place. You ask rubenwardy and he tells you that he'd like to, but that is complicated. You ask a few other core devs, and you realise they're not even |
| 10:30 |
Zughy[m] |
active. So in the end things "just go" |
| 10:38 |
Zughy[m] |
One positive thing is, at least now we have regular meetings every two weeks (next one is today) and PRs are going down. If we keep up the pace, this should allow the organisation to think about certain aspects within a reasonable future, as the ghost of PRs is a huge toll on development, I think (a ghost we've been exorcising) |
| 10:40 |
Zughy[m] |
Talking about that, there are 4 "two approvals" PRs waiting to be merged. That will bring us to 68 PRs, another brand new record :) |
| 11:40 |
pgimeno |
<MTDiscord> <Warr1024> We got multiple Lua threads now, so I guess it would be interesting if the "worker" lua states could ask for mapblock locks independently |
| 11:41 |
pgimeno |
last time I checked, Lua threads share a common environment and therefore are subject to a global interpreter lock |
| 11:46 |
|
jwmhjwmh joined #minetest-dev |
| 11:59 |
jwmhjwmh |
Lua "threads" share a common interpreter state, but Minetest runs its own async threads which have totally separate Lua states. |
| 11:59 |
jwmhjwmh |
Merge #12833, #12810, and #12771 in 5m. |
| 11:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/12833 -- DevTest: Explain purpose of most items in tooltips by Wuzzy2 |
| 11:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/12810 -- Improve documentation for `liquid_alternative_*` by Wuzzy2 |
| 11:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/12771 -- add an 'equals' method to ItemStack and compatibility w/ lua '==' by fluxionary |
| 12:01 |
pgimeno |
are these async threads with separate states a recent addition? |
| 12:02 |
jwmhjwmh |
Pretty recent, I think they were added in 5.6. |
| 12:03 |
pgimeno |
ok, I've been away for some months |
| 12:12 |
pgimeno |
it's not in the changelog >.< |
| 12:13 |
|
kilbith joined #minetest-dev |
| 12:23 |
MTDiscord |
<luatic> it is in the changelog: "Add Async environment for parallelized Lua code execution (sfan5) " (https://dev.minetest.net/Changelog#5.5.0_.E2.86.92_5.6.0) |
| 12:34 |
pgimeno |
oh right |
| 12:34 |
pgimeno |
thanks |
| 12:43 |
|
proller joined #minetest-dev |
| 13:26 |
|
proller joined #minetest-dev |
| 13:31 |
|
appguru joined #minetest-dev |
| 14:35 |
|
jwmhjwmh joined #minetest-dev |
| 14:41 |
|
kilbith joined #minetest-dev |
| 14:45 |
jwmhjwmh |
Merging #12797 in 5m. |
| 14:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/12797 -- Optimize lighting calculation by TurkeyMcMac |
| 14:57 |
Zughy[m] |
68 PRs open. Trivia: last time there were so few PRs was 8 years ago. More precisely, 2014-08-30. That's a big accomplishment, if you ask me |
| 15:11 |
sfan5 |
schwarzwald[m]: I don't see a reason to get rid of a reference couting in irrlicht and you also run into problems: in a scene graph that is not loop-free who owns what? |
| 15:14 |
sfan5 |
re mesh cache: the mesh cache can speed up meshgen times, amount of vertices uploaded to the GPU doesn't change |
| 15:16 |
sfan5 |
but it's also not enabled with smooth lighting so few people will have benefited in the last 5 years |
| 15:17 |
MTDiscord |
<savilli> So you're fine with removing it? |
| 15:24 |
sfan5 |
I guess it could be removed |
| 15:24 |
sfan5 |
is it broken? |
| 15:30 |
MTDiscord |
<savilli> Likely |
| 15:50 |
|
Desour joined #minetest-dev |
| 16:18 |
|
appguru joined #minetest-dev |
| 16:49 |
sfan5 |
ok wtf |
| 16:49 |
sfan5 |
can we please stop regressing graphics |
| 16:49 |
sfan5 |
the brightness is all bright |
| 16:50 |
sfan5 |
@x2048 |
| 16:50 |
sfan5 |
effectively smooth lighting is broken |
| 16:51 |
sfan5 |
nvm just had that turned off |
| 16:59 |
MTDiscord |
<x2048> Can you share a screenshot of what's broken? |
| 16:59 |
MTDiscord |
<x2048> Brightness... |
| 17:00 |
sfan5 |
https://a.uguu.se/WotOBUSY.png |
| 17:01 |
sfan5 |
probably this https://a.uguu.se/rWATBkMZ.png |
| 17:02 |
sfan5 |
(which ironically I approved) |
| 17:11 |
Krock |
yes, it's too bright but thought it's due to me messing with the shader files |
| 17:12 |
sfan5 |
pushing trivial fix |
| 17:13 |
sfan5 |
on another note I don't know who considers that over-bright tonemapping good |
| 17:13 |
|
Fixer joined #minetest-dev |
| 17:31 |
schwarzwald[m] |
Warr, to clarify, does "global" mean the setting would apply to the entire API? What I'm thinking is that if the reason for having a setting is that we need backwards compatibility, making the setting apply across all mods means that mods that require the old behavior are incompatible with mods that require the new behavior. |
| 17:34 |
Zughy[m] |
meeting time, amirite? |
| 17:35 |
Zughy[m] |
no I'm not, nevermind |
| 17:35 |
schwarzwald[m] |
What is the schedule for the dev meetings? I've observed that they're usually on Sunday. |
| 17:35 |
Zughy[m] |
in 25 minutes |
| 17:35 |
Zughy[m] |
every two weeks |
| 17:38 |
jwmhjwmh |
Merging #12813 in 5m. |
| 17:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/12813 -- [NO SQUASH] Remove unused MapBlock functionality, in particular dummy blocks by TurkeyMcMac |
| 17:49 |
|
Desour joined #minetest-dev |
| 17:49 |
Krock |
kind reminder that there's a meeting in 15 minutes. jwmhjwmh sfan5 @x2048 (pinging those who recently showed activity). the list is quite short today. |
| 17:53 |
sfan5 |
I guess I'm present, haven't looked at the meeting notes yet |
| 17:54 |
Krock |
me neither. concept discussion of 4 PRs |
| 17:56 |
MTDiscord |
<x2048> Can we also discuss ^ brightness? |
| 17:58 |
|
x2048 joined #minetest-dev |
| 18:00 |
Krock |
added |
| 18:03 |
jwmhjwmh |
Should we begin? |
| 18:03 |
Krock |
> #11432 |
| 18:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/11432 -- Add support for attached facedir/4dir nodes by Wuzzy2 |
| 18:03 |
Krock |
First meeting point. Concept discussion? |
| 18:04 |
jwmhjwmh |
See my comment there. I was wondering if there should be an attached_node variant based on the facedir axis. |
| 18:04 |
jwmhjwmh |
Rather than the facedir face. |
| 18:04 |
jwmhjwmh |
This could be useful for attached tree nodes and such. |
| 18:05 |
Krock |
why can't it have the same format as facedir? |
| 18:05 |
jwmhjwmh |
Then the log nodes would attach to nodes beside them. |
| 18:06 |
jwmhjwmh |
Instead of under them. |
| 18:06 |
Krock |
hmm |
| 18:06 |
jwmhjwmh |
I workaround in this case would be to change the orientation of the tree textures or to use "wallmounted" logs. |
| 18:07 |
jwmhjwmh |
But e.g. an attached chest would not work with wallmounted. |
| 18:08 |
Krock |
the most generic method I could imagine is to provide a bitfield that specifies where to attach into each axis using the rotated coordinate system |
| 18:08 |
sfan5 |
hm |
| 18:08 |
sfan5 |
not sure about the feature as a whole but if people think there's enough usecases then that's fine with me |
| 18:08 |
Desour |
you can express a rotated coordinate system using a facedir value |
| 18:09 |
Krock |
with a bitfield you could attach to multiple nodes |
| 18:10 |
Krock |
like a beam that's supported from both sides |
| 18:10 |
Krock |
it goes into the direction of what jwmhjwmh suggests, but taking it further to allow any combination |
| 18:11 |
jwmhjwmh |
A bit set could be represented in the attached_node group value, with one extra bit set to mark the format. |
| 18:11 |
Krock |
why do you need to mark the format? |
| 18:11 |
jwmhjwmh |
To distinguish it from other attached_node group settings. |
| 18:12 |
sfan5 |
minus the placement prediction games could actually implement all this on their own |
| 18:12 |
sfan5 |
so we should be wary of adding flexible but too complex formats |
| 18:12 |
sfan5 |
(right?) |
| 18:13 |
Krock |
it cannot get more complicated than that, I think. |
| 18:13 |
Krock |
also yes, it does not strictly need an implementation in Minetest |
| 18:14 |
Krock |
is this PR something that's wanted? |
| 18:15 |
jwmhjwmh |
The PR can be left as-is then. I wasn't going to use the feature myself. |
| 18:16 |
sfan5 |
I guess we should ask some mod authors to weigh in |
| 18:17 |
jwmhjwmh |
This use-case could be solved with the bit set approach, I think: https://github.com/minetest/minetest/pull/11432#issuecomment-876841336 |
| 18:18 |
Krock |
everything but altering attached modes could be implemented with bitfields |
| 18:20 |
Krock |
okay. I'll leave a link to the discussion there. modders are welcome to provide feedback there and proceed with the next topic |
| 18:20 |
Krock |
> #12739 |
| 18:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/12739 -- Add callback on_mapblocks_changed by TurkeyMcMac |
| 18:21 |
Desour |
(for full flexibility, you'd also have to support OR, i.e. by using multiple bitfields for cnf or dnf) |
| 18:21 |
Krock |
why do we need this? |
| 18:21 |
sfan5 |
to reliably track when nodes change |
| 18:22 |
Krock |
well yes, but mods trigger node changes themselves |
| 18:22 |
Krock |
and there's also on_placenode callbacks |
| 18:22 |
MTDiscord |
<GreenXenith> The linked issue gives you reasons |
| 18:22 |
jwmhjwmh |
The example mod mesecons_detector2 is a fast version of the mesecons node detector. It can detect changes from voxelmanips, liquid, etc. |
| 18:22 |
sfan5 |
well not for vmanips |
| 18:23 |
jwmhjwmh |
Desour proposed an alternative API along the lines of "minetest.watch_area(pos1, pos2, func)" |
| 18:23 |
jwmhjwmh |
This could also be used to implement mesecons_detector2 |
| 18:23 |
MTDiscord |
<GreenXenith> As someone that has made over 5 iterations of a replay mod for the last 4 or 5 years, I would greatly appreciate a more generic state watcher |
| 18:23 |
jwmhjwmh |
Areas could be stored in an AreaStore |
| 18:23 |
MTDiscord |
<GreenXenith> watch area is not generic enough |
| 18:24 |
jwmhjwmh |
Is it OK if the API raises false positives? |
| 18:24 |
MTDiscord |
<GreenXenith> The mapblock callback can let me watch any mapblock or I can limit it to an area myself. The inverse is not true for the watch area method |
| 18:25 |
sfan5 |
making it not raise false positives is infeasible |
| 18:25 |
Krock |
how would mods know what to watch for in these callbacks? |
| 18:25 |
Krock |
specific nodes, as an alternative to ABMs? |
| 18:26 |
jwmhjwmh |
The mod mesecons_detector2 uses the callback to trigger detector updates. It rechecks the detectors when the callback fires. |
| 18:26 |
Krock |
there is no way to figure out what used to be there before the callback is executed without tracking the entire map |
| 18:26 |
Desour |
> well not for vmanips are you sure sfan5? It'd make the callback unsuitable for node detectors |
| 18:26 |
Krock |
I see. yes, for detectors it could make sense |
| 18:26 |
sfan5 |
Desour: that was in response to "on_placenode" |
| 18:26 |
Krock |
vmanip marks blocks as dirty |
| 18:26 |
Krock |
ah I see |
| 18:27 |
Desour |
ahh |
| 18:27 |
MTDiscord |
<GreenXenith> Krock: ideally the callback would begin as soon as a block is slated to change. I would hope thats how it is implemented at least |
| 18:28 |
|
appguru joined #minetest-dev |
| 18:28 |
sfan5 |
the callback runs after the fact |
| 18:28 |
Krock |
no, mapblocks are already modified at that point |
| 18:28 |
Krock |
you cannot trigger something before they're marked dirty |
| 18:28 |
jwmhjwmh |
It would be hard to run the callback before modification. |
| 18:29 |
Krock |
and somewhat uneffitient on top of that |
| 18:29 |
MTDiscord |
<GreenXenith> Is the returned data only positions? |
| 18:29 |
sfan5 |
yes |
| 18:29 |
sfan5 |
the idea with the PR is that the engine already tracks this stuff so exposing it to Lua is free and has a great effect in terms of new possibilities |
| 18:29 |
MTDiscord |
<GreenXenith> Alright then I change my opinion to indifference. |
| 18:30 |
MTDiscord |
<GreenXenith> What exactly are the great new possibilities you speak of |
| 18:30 |
jwmhjwmh |
In the PR description you can download an example mod mesecons_detector2. |
| 18:31 |
Krock |
modders always found something to do with it |
| 18:31 |
Desour |
if the callback is only called once per server-step ("at most", I guess the only way for this to be less often is if nothing changed?), does this actually have to be a callback? you could make a function to retrieve all blocks that changed since last server-step. mods can then pull the list of changed blocks on_globalstep |
| 18:31 |
MTDiscord |
<GreenXenith> Is that mod not just a reimplementation of a thing we can already do? |
| 18:31 |
Desour |
(+ core.is_block_dirty(pos) -> bool) |
| 18:31 |
sfan5 |
it is |
| 18:31 |
sfan5 |
for the first time there would be a way to actually receive a callback when a vmanip modifies a block |
| 18:31 |
MTDiscord |
<GreenXenith> Krock: by that logic you should be merging every feature pr without a second thought |
| 18:32 |
pgimeno |
what's the API for register_on_mapblocks_changed? it would be nice to mention it in the comments without needing to read the code |
| 18:32 |
MTDiscord |
<GreenXenith> Alright, the vmanip point is a good one |
| 18:32 |
sfan5 |
* `minetest.register_on_mapblocks_changed(function(modified_blocks, modified_block_count))` |
| 18:33 |
sfan5 |
* `modified_blocks` is the set of modified mapblock position hashes. |
| 18:33 |
sfan5 |
* `modified_block_count` is the number of entries in the set. |
| 18:33 |
sfan5 |
now we should be on the same page |
| 18:33 |
pgimeno |
thanks |
| 18:34 |
jwmhjwmh |
Desour: core.is_block_dirty(pos) suggests the dirty marker is cleared at some meaningful point, when in fact it is just cleared on every server step. |
| 18:34 |
MTDiscord |
<x2048> Why do we need the count separately? |
| 18:34 |
sfan5 |
lua has no efficient means of counting the number of keys in a table |
| 18:34 |
Krock |
Desour: blocks are only dirty for a rather short time, so a normal function could result in missed updates when implementing a rate limit |
| 18:35 |
MTDiscord |
<GreenXenith> Is it not an array? |
| 18:35 |
jwmhjwmh |
It is a set of position hashes. |
| 18:35 |
rubenwardy |
{ [hash] = true } |
| 18:35 |
MTDiscord |
<GreenXenith> Why this over a list, out of curiosity |
| 18:35 |
rubenwardy |
I assume. Doc could be more specific |
| 18:35 |
sfan5 |
a bit unusual but more efficient |
| 18:36 |
jwmhjwmh |
It allows for fast checking of whether a mapblock has been modified. |
| 18:36 |
Krock |
faster lookups than integer-indiced tables |
| 18:36 |
MTDiscord |
<GreenXenith> Fair enough |
| 18:36 |
Krock |
and yet there's only node hash positions and yet it's used to hash a mapblock |
| 18:36 |
pgimeno |
mmm... does that mean it would be triggered for any change anywhere? that sounds busy |
| 18:37 |
jwmhjwmh |
All changes on a single server step are collected into one step. |
| 18:37 |
MTDiscord |
<GreenXenith> Thats the point |
| 18:37 |
Desour |
jwmhjwmh: then `core.was_block_modified_in_last_server_step(pos) -> bool` (and `core.get_blocks_modified_in_last_server_step() -> map, count`) |
| 18:37 |
Krock |
pgimeno: changes are bundled in batch for saving, and that's also where the callback should fire |
| 18:37 |
jwmhjwmh |
Into one step, I mean. |
| 18:37 |
sfan5 |
any change anywhere per mapblock (including changes that Lua couldn't even see) |
| 18:37 |
jwmhjwmh |
One set, I mean, lol. |
| 18:37 |
Krock |
(never mind actually it's at most once per server step) |
| 18:38 |
sfan5 |
Desour: this has almost no advantages other that being confusing in regards to when do you have to call it |
| 18:38 |
sfan5 |
when + how often |
| 18:38 |
pgimeno |
providing a range on register sounds more reasonable to me; filling in long hash tables can potentially incur a performance penalty |
| 18:38 |
MTDiscord |
<GreenXenith> Hmm, upon further thought, I realize I can manually track changes as long as I choose the area to watch. I have to save the initial mapblock state and then save the mablock state every time it changes. Could be expensive but it also could be worse |
| 18:39 |
jwmhjwmh |
Desour: You could use `local my_modified = {}; core.register_on_mapblocks_changed(function(m) my_modified = m end)`, then use `my_modified` in a globalstep. |
| 18:40 |
jwmhjwmh |
GreenXenith: maybe you could use mapblock_lib. |
| 18:40 |
Desour |
ok, right, the callback is probably simpler and better |
| 18:41 |
|
x2048 joined #minetest-dev |
| 18:41 |
MTDiscord |
<GreenXenith> Once again +1 to the design then from me. Its generic enough and easy enough to understand. |
| 18:41 |
sfan5 |
not being able to tell what changed or how the MB was before is indeed annoying |
| 18:42 |
sfan5 |
but at least with this you can choose to watch an area and bring your own manual tracking |
| 18:42 |
MTDiscord |
<GreenXenith> I fear tracking the changes themselves is beyond the scope of this feature, or at least the pr |
| 18:43 |
MTDiscord |
<x2048> it is, change tracking can be done in a few ways outside this API |
| 18:43 |
jwmhjwmh |
pgimeno: I doubt _that_ many mapblocks will be modified per globalstep, and making mapblock hashes should be fairly cheap. |
| 18:44 |
Krock |
hmm. on a busy server with 20 players you surely get at least 20 mapblocks per tick |
| 18:44 |
Krock |
be it just for ABMs |
| 18:44 |
Krock |
or other metadata updates |
| 18:44 |
sfan5 |
maybe ask pandorabox people how many written mapblocks to db they get |
| 18:44 |
Desour |
I wonder if it is more performant to build a lua hash table in C++ or to build an array and then make it to a hash table in lua |
| 18:44 |
sfan5 |
IIRC there's already stats for this |
| 18:44 |
pgimeno |
20 is reasonable; 500 could be troublesome |
| 18:44 |
sfan5 |
via prometheus I mean |
| 18:44 |
pgimeno |
on top of that, the table passed is engine-generated, so it generates garbage |
| 18:45 |
MTDiscord |
<Jonathon> @BuckarooBanzai |
| 18:45 |
sfan5 |
and all modified mapblocks get written (instantly?) so that figure should be accurate |
| 18:45 |
MTDiscord |
<GreenXenith> This is a callback you should expect to be called in excess, which is not a bad thing. Just needs to be efficient |
| 18:45 |
Krock |
pgimeno: depends on how much the ABMs do. oh right. liquid flow too. and mapblocks with technic nodes will pretty much fire every globalstep unless metadata changes are ignored |
| 18:46 |
jwmhjwmh |
Metadata changes are included. |
| 18:46 |
pgimeno |
there isn't an option for providing your own table to fill, like some functions (was it noise?) do |
| 18:46 |
Krock |
so yes, a hundred mapblocks per tick isn't too far off |
| 18:47 |
Desour |
Krock: technic runs on abm step, afaik |
| 18:47 |
Krock |
Desour: yes, it's the switching station that does it each second |
| 18:48 |
Desour |
(so, once per second by default, not once per server-step) |
| 18:48 |
rubenwardy |
builtin could have a table for reducing garbage |
| 18:48 |
Desour |
how do you clean the table? |
| 18:49 |
jwmhjwmh |
LuaJIT has table.clear() |
| 18:49 |
sfan5 |
since the hashtable is the table itself there shouldn't be any garbage except for the table object |
| 18:49 |
sfan5 |
would be very different with a list of vectors |
| 18:50 |
jwmhjwmh |
Yes, reusing the table might be micro-optimization. Minetest does a bunch of other allocation anyway. |
| 18:50 |
sfan5 |
i think we're getting a bit off-topic though |
| 18:51 |
Krock |
maybe let's keep this for now and go to the next topic? |
| 18:52 |
sfan5 |
sure |
| 18:52 |
Krock |
because I do not see any clear progress any more |
| 18:52 |
Krock |
> #12611 |
| 18:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/12611 -- Implement some VoxelManip functionality safely using LuaJIT's FFI library by TurkeyMcMac |
| 18:52 |
Krock |
> Decide whether the added complexity is worth it. |
| 18:53 |
jwmhjwmh |
I measured a speed up of almost 2x with this change to get_data etc. |
| 18:53 |
jwmhjwmh |
But it requires duplicating the implementations. |
| 18:53 |
sfan5 |
tending towards -1 from my side |
| 18:53 |
Krock |
well I'd say No. the API is supposed to work with LuaJIT and Lua the same way |
| 18:53 |
Krock |
also yes, code duplication and hence more maintenance efforts to keep it in sync and working well |
| 18:54 |
jwmhjwmh |
It does add pretty extensive unit tests for the API. |
| 18:54 |
sfan5 |
hm |
| 18:55 |
Krock |
I also implemented functions for FFI into Minetest as an experiment and it did indeed work pretty well |
| 18:55 |
Desour |
get_node can be made so fast that checking whether a node is near with get_node is almost as fast as get_nodes_near, last time I tried, btw. |
| 18:56 |
Desour |
it would be nice if we had a C api that we call from both C lua and luajit ffi, for consistency |
| 18:59 |
Krock |
rubenwardy: if you're around - do you have an opinion on this? |
| 18:59 |
rubenwardy |
didn't we try this years ago, and find no performance improvement? |
| 19:00 |
MTDiscord |
<x2048> Q: what is the biggest benefit from the faster voxelmanip? |
| 19:00 |
jwmhjwmh |
Mapgen, mesecons |
| 19:00 |
MTDiscord |
<Jonathon> probably worldedit as well? |
| 19:01 |
Krock |
schematic placement relies on it too |
| 19:01 |
sfan5 |
schematic placement is C++ |
| 19:01 |
Krock |
or was it only trees? well, I don't remember |
| 19:01 |
sfan5 |
this is only for voxelmanip interaction with lua, is it? |
| 19:01 |
Krock |
ah yes, internal vmanip. I got confused |
| 19:02 |
jwmhjwmh |
Their total speed probably would not increase enormously from this change, since get_data is only part of the cost. |
| 19:03 |
Krock |
#6863 |
| 19:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/6863 -- Add LuaJIT FFI-friendly memory-intensive functions |
| 19:03 |
Krock |
that was pgimeno's original PR |
| 19:03 |
Krock |
well great. the diff is gone |
| 19:03 |
pgimeno |
I also made this mod: https://notabug.org/pgimeno/ffi_accel |
| 19:04 |
pgimeno |
and the diff is available in notabug I believe |
| 19:04 |
pgimeno |
https://notabug.org/pgimeno/minetest/pulls/2 |
| 19:06 |
pgimeno |
I was told that ffi_accel greatly accelerated mapgen |
| 19:06 |
pgimeno |
even though it's very restricted due to security concerns |
| 19:07 |
jwmhjwmh |
My PR still requires copying to and from the VM buffer, since it is designed to be used transparently by untrusted mods. |
| 19:09 |
pgimeno |
the mod was about transparent replacement; 6863 was about a new faster way of doing things, but the mods using it would need to be trusted |
| 19:10 |
hmmmm |
wow :D |
| 19:11 |
hmmmm |
what is the security concern in question now? this seems like something new, i guess mods can be 'trusted' or 'untrusted'? what is the privilege trusted mods have exactly? |
| 19:11 |
Krock |
restrictions on "os" and "require" functions that could potentially execute harmful code |
| 19:11 |
hmmmm |
if it's about writing raw memory to a buffer in the process, it's not like that can't be handled with some bounds checks (but I suppose that defeats the purpose of this PR) |
| 19:12 |
hmmmm |
well it's not like the mods that are using this functionality also have privileges to "os" |
| 19:13 |
pgimeno |
in raw FFI (6863) there are no possible bounds checks, that's why it's fast |
| 19:13 |
hmmmm |
since they are executing in different modules that did not import |
| 19:13 |
hmmmm |
i am really glad somebody is making luavoxelmanip better |
| 19:14 |
Desour |
hmmmm: 12611 doesn't need trust, it implements part of the API using luajit's ffi lib. the implementation must not have bugs though |
| 19:14 |
Krock |
if there's FFI for normal Lua we could switch to the FFI variant althogether? |
| 19:15 |
hmmmm |
i support the concept, but id need to put in real work into reading up on the mechanisms being used here to do a code review |
| 19:15 |
hmmmm |
sorry i can't be more useful :p |
| 19:15 |
jwmhjwmh |
https://github.com/facebookarchive/luaffifb |
| 19:16 |
Desour |
Krock: there is, eg. https://github.com/q66/cffi-lua |
| 19:16 |
hmmmm |
<Krock> or was it only trees? well, I don't remember |
| 19:16 |
pgimeno |
Krock: technically there is, I believe Facebook implemented one, but it's not worth it - it's about speeding up access, and PUC Lua FFI performs poorly |
| 19:16 |
hmmmm |
i'm sure there are mods that use lua for trees that they want to make not using the l-system or schematics |
| 19:16 |
pgimeno |
in facebook's implementation there was an incompatibility with nil being the null pointer I believe |
| 19:16 |
hmmmm |
i just added those into the core because those seem like the most common use case |
| 19:18 |
pgimeno |
I don't have time to look into 12611 for now, maybe I can review it in future |
| 19:18 |
Krock |
well I don't know what to do with that PR |
| 19:18 |
Krock |
> #12449 one more? |
| 19:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/12449 -- [No Squash] Use .md extension for markdown files by rubenwardy |
| 19:18 |
hmmmm |
hmmmmmmmmmmmm.... tbh I think the requirement to remain secure should fall onto the mod writers who use FFI |
| 19:19 |
rubenwardy |
We have a mod sandbox, it's important not to just add holes in it |
| 19:19 |
hmmmm |
if you wanted to exploit minetest clients i'm pretty sure that's easy enough seeing as how you got ppl like nerzuhl running around making packet deserialize functions vuln as fuck |
| 19:20 |
hmmmm |
ahaha kidding |
| 19:20 |
hmmmm |
but MT seems like such a soft target |
| 19:20 |
hmmmm |
ye idk then ruben, but 2x speedup seems too appetizing |
| 19:20 |
MTDiscord |
<Warr1024> MT makes up for its weakness to attack by offering relatively little value to attackers. |
| 19:21 |
hmmmm |
true |
| 19:23 |
MTDiscord |
<x2048> It does not justify designing for vulnerability though. |
| 19:24 |
hmmmm |
do we actually know that there is a vulnerability or is the concern with the added surface area? |
| 19:25 |
rubenwardy |
This PR looks like it should be fine as it doesn't expose the ffi interface to mods, just upgrades the APIs to use it |
| 19:25 |
jwmhjwmh |
AFAIK my PR does not introduce a vulnerability. |
| 19:26 |
MTDiscord |
<x2048> I think the concern is with putting the basic security requirements on the mod authors. This PR does not do that. |
| 19:27 |
Desour |
the concern is mostly about attack surface. and minetest makes it hard to securely use the insec env, especially with mods having access to debug stuff, it's a bit less bad in builtin at least because no other mod loaded before |
| 19:28 |
hmmmm |
> #12449 good to merge |
| 19:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/12449 -- [No Squash] Use .md extension for markdown files by rubenwardy |
| 19:28 |
hmmmm |
i don't think increased attack surface alone is reason enough to block something substantial |
| 19:29 |
hmmmm |
if there is a vulnerability, it'd get patched, and then we move onward |
| 19:29 |
hmmmm |
you don't see people whining about support for emojis because it pulls in libjpeg |
| 19:30 |
Desour |
I wish we had something more searchable than txt or md. I hate those `See "Nodes"` comments. without case-sensitivity, there are about 181 matches for "nodes" |
| 19:31 |
MTDiscord |
<luatic> md should allow references |
| 19:31 |
hmmmm |
i feel like a lot of these concerns are a bit perfectionist |
| 19:31 |
hmmmm |
this is an upgrade from where we are now |
| 19:31 |
MTDiscord |
<luatic> I vaguely remember that [Nodes] might work (if there is an appropriate header); otherwise [Nodes](#nodes) can reasonably be expected to work |
| 19:32 |
hmmmm |
as long as you are not working backwards, it's ok if a PR doesn't include the kitchen sink too |
| 19:32 |
hmmmm |
maybe you can add the references |
| 19:32 |
MTDiscord |
<luatic> AsciiDoc is the format we went with for the docs project |
| 19:32 |
rubenwardy |
Desour: Using MD would allow linking to Nodes directly |
| 19:32 |
rubenwardy |
As others have said |
| 19:33 |
rubenwardy |
GitHub also lets you search the table of contents, and a lot of IDEs allow that as well (it's often called "structure") |
| 19:33 |
rubenwardy |
(or symbols) |
| 19:34 |
MTDiscord |
<luatic> BTW Desour, just grep for # Nodes; as long as the heading doesn't use setext-style you'll be fine |
| 19:34 |
rubenwardy |
Most of the doc is setext style lol |
| 19:34 |
MTDiscord |
<luatic> we should also switch all our headings to ATX-style (#) |
| 19:35 |
MTDiscord |
<luatic> rubenwardy: then it's probably poorly structured, because setext-style only works for levels 1 & 2 |
| 19:35 |
MTDiscord |
<luatic> that'd be plenty of top level headings |
| 19:35 |
Desour |
Nodes is also the text style https://github.com/minetest/minetest/blob/b3503e7853a52a8c16431f6b983e30c9d25951bc/doc/lua_api.txt#L1008 |
| 19:36 |
MTDiscord |
<luatic> argh |
| 19:36 |
Krock |
it does not matter. you can use [Nodes](#nodes) to link there |
| 19:36 |
Krock |
or at least that should work |
| 19:37 |
Desour |
I guess md is an improvement ¯\_(ツ)_/¯ after all, we are we are already writing it in markdown format |
| 19:38 |
Desour |
but in the long run, I would really like to see something nicer, like ldoc (I've made pretty good experiences with it <https://github.com/Desour/dslib#documentation>) |
| 19:38 |
hmmmm |
oh so you're volunteering eh |
| 19:39 |
Desour |
not now, but I'm trying to manipulate peoples' minds in the long run |
| 19:40 |
hmmmm |
i know that feeling lmao |
| 19:40 |
MTDiscord |
<luatic> ldoc is unfortunately about the only option unless you write your own |
| 19:40 |
Desour |
after all, it's not in the roadmap and making a contribution would only lead to wasted work |
| 19:40 |
hmmmm |
i was sort of hoping somebody else would make the active mapblock idea a reality |
| 19:40 |
MTDiscord |
<luatic> writing my own is on my TODO list tho hehe |
| 19:41 |
hmmmm |
that + fixing mapgen + breaking down maplock were the three big things i wanted to accomplish |
| 19:42 |
Desour |
luatic: or fork it to add more features and fix bugs |
| 19:42 |
MTDiscord |
<x2048> Looks like .md extension is accepted. One note though is that Discord bots (and any other bots) will need to be adjusted. |
| 19:42 |
MTDiscord |
<x2048> Do we move on? |
| 19:46 |
MTDiscord |
<luatic> Desour: I don't like the style of it; I want my doc comments to be at the appropriate places (e.g. param comments next to params, return comments next to return statements, function description next to function definitions) |
| 19:46 |
Krock |
@luatic: I think it would be best to state your concerns in the PR |
| 19:47 |
Krock |
if that's related to the .txt -> md transition |
| 19:47 |
Krock |
> final topic: Shader brightness issue |
| 19:47 |
MTDiscord |
<luatic> Krock: I am pro the txt -> md transition |
| 19:47 |
Krock |
@x2048 on recent Minetest versions, the terrain is somewhat bright with only shaders enabled |
| 19:48 |
Krock |
sfan5 did propose a patch earlier on. is the discussion about this, or am I mistaken? |
| 19:49 |
MTDiscord |
<x2048> > sfan5: on another note I don't know who considers that over-bright tonemapping good |
| 19:50 |
MTDiscord |
<x2048> This is what I want to discuss. |
| 19:50 |
Krock |
mhm. yes, it's indeed very bright. the texture colors are no longer reflected properly (at least at sunlight levels) |
| 19:51 |
MTDiscord |
<Warr1024> IIRC the tone mapping function is literally just a naive color curve applied statically to the rendered scene. When I heard about it, what I had hoped for was something more dynamic, e.g. taking average brightness into account and e.g. auto-adjusting for dim scenes and such. I am not sure what actual use the original shader actually served other than as e.g. a placeholder and proof of concept? |
| 19:52 |
MTDiscord |
<x2048> Bloom PR converts all PP into linear color space, assuming that 3D step rendered in sRGB |
| 19:52 |
rubenwardy |
It's probably worth making sure it's implemented correctly, in terms of how it works in other games |
| 19:53 |
MTDiscord |
<x2048> Adding bloom, godrays etc. on top will make some areas overbright, and this is where some tonemapping helps. |
| 19:53 |
rubenwardy |
Isn't tone mapping designed to implement fake HDR? Or am I thinking about something else |
| 19:53 |
MTDiscord |
<x2048> Not fake, |
| 19:53 |
rubenwardy |
"auto adjusting for dim scenes" sounds like fake HDR |
| 19:53 |
MTDiscord |
<Warr1024> Fake HDR is what it should have done but I don't think our implementation even attempts that. |
| 19:53 |
MTDiscord |
<x2048> tonemapping maps from HDR colors of rendering into sRGB of the display |
| 19:54 |
MTDiscord |
<Warr1024> It's "fake" in the sense that we don't actually have enough precision to do it properly |
| 19:54 |
rubenwardy |
Software HDR then, as contrasted to hardware/display HDR |
| 19:54 |
MTDiscord |
<x2048> Bloom adds exposure control via settings. You can so /set exposure_factor 0.5 in your single player |
| 19:54 |
MTDiscord |
<Warr1024> /set exposure_factor auto is what I'd want :-) |
| 19:55 |
MTDiscord |
<x2048> My point: the previous tonemapping code added 2.5 to the exposure, probably to make a fake HDR |
| 19:55 |
MTDiscord |
<Warr1024> like, sample overall brightness from the scene (possibly smooth it over time) and adjust the tone map to bring the dominant brightness closer to the middle. |
| 19:55 |
MTDiscord |
<x2048> I kept that factor here: https://github.com/minetest/minetest/blob/master/src/client/renderingengine.h#L51https://github.com/minetest/minetest/blob/master/src/client/renderingengine.h#L51 |
| 19:55 |
MTDiscord |
<x2048> But I'd like to remove it |
| 19:56 |
MTDiscord |
<x2048> It will make entire scene dimmer by default, i.e. change for the players. |
| 19:56 |
MTDiscord |
<x2048> But it will make my life, gamedev and TP designer life easier |
| 19:56 |
MTDiscord |
<Warr1024> I currently play with shaders off most of the time. If you had HDR support in screen-space (cheap enough) then that would probably be enough to get me to turn it on. |
| 19:58 |
MTDiscord |
<Warr1024> Consequently, I have my game tuned based on whatever the rendering looks like with shaders completely off (dunno if that's linear or not?) |
| 19:59 |
MTDiscord |
<Warr1024> If the game experience got overall darker, that'd force me to redo a bunch of art and make me quite unhappy. If we had HDR and it auto-adjusted for it and boosted stuff back into a good range, then I'd probably be cool with that :-) |
| 19:59 |
MTDiscord |
<x2048> Shaders off is sRGB and weird math around voxel lighting. |
| 20:00 |
MTDiscord |
<x2048> I don't think removing 2.5 factor will be darker than w/o shaders. |
| 20:00 |
MTDiscord |
<Warr1024> Though, "voxel lighting" would just mean "mulitply colors by some brightness <1" with the brightness function itself being that weird gamma curve thing that MT does, right? |
| 20:01 |
MTDiscord |
<Warr1024> What setting is that 2.5 thing tied to, just the "Shaders" base option, or tone mapping, or bloom? |
| 20:03 |
MTDiscord |
<Warr1024> Ideally, regardless of the shader options you pick, the default overall brightness of MT across all scenes shouldn't change compared to the no-shaders option, at least to me. |
| 20:03 |
MTDiscord |
<Warr1024> If they differ, regardless of which one you consider "correct", people will adjust their images for one way or the other, and it will look wrong to any players who play the other way. |
| 20:04 |
MTDiscord |
<Warr1024> At least, any settings that we put on the "Settings" panel in the main menu shouldn't so drastically alter the appearance of the game that it would be considered "breaking" for anyone who expects a reasonably faithful rendering of their visual art. |
| 20:05 |
MTDiscord |
<x2048> I'd like to share the screenshots. Can I just paste them in Discord? |
| 20:06 |
MTDiscord |
<Jonathon> they should just get a discord cdn link they can view |
| 20:06 |
MTDiscord |
<x2048> Thank you |
| 20:08 |
MTDiscord |
<x2048> @Warr1024 It's designed to affect bloom and tonemapping. |
| 20:09 |
MTDiscord |
<x2048> Fector 2.5 w/ tonemapping |
| 20:09 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1028761213884182568/Screenshot_20221009_220813.png |
| 20:12 |
MTDiscord |
<x2048> Without tonemapping |
| 20:12 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1028761781801328723/Screenshot_20221009_221119.png |
| 20:12 |
MTDiscord |
<x2048> Without shaders |
| 20:12 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1028761954396942447/Screenshot_20221009_221226.png |
| 20:14 |
MTDiscord |
<x2048> Factor 1.0 with tonemapping |
| 20:14 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1028762338775547914/Screenshot_20221009_221353.png |
| 20:14 |
MTDiscord |
<Andrey01> what about #12843 ? |
| 20:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/12843 -- Add modslist formspec for /mods command. by Andrey2470T |
| 20:16 |
MTDiscord |
<x2048> So the question of brightness is - do we change default tonemapping behavior from image 1 to image 4? Players can use exposure_factor setting to set the exposure correction they want. |
| 20:19 |
|
jwmhjwmh joined #minetest-dev |
| 20:27 |
MTDiscord |
<Warr1024> Hmm ... do you have a scene that shows contrast across the spectrum, e.g. a mix of dark and light areas? Tonemapping making things "brighter" is what I basically expected from an already-brighter-than-midtone scene to begin with... |
| 20:27 |
MTDiscord |
<Warr1024> but out of the ones you posted so far, image 1 does look the "most wrong" to me... |
| 20:45 |
schwarzwald[m] |
Has the meeting ended? It's been twenty minutes since the last comment. |
| 20:47 |
rubenwardy |
I guess so |
| 20:48 |
schwarzwald[m] |
Desour: I made the change across all of Irrlicht to handle mesh lifetimes using a shared_ptr, but it infected the public interface that Minetest uses, and Minetest doesn't build anymore after the change. |
| 20:49 |
schwarzwald[m] |
If anything like that is going to be done, it will not be limited in scope just to Irrlicht's internal implementation, unfortunately. |
| 20:52 |
MTDiscord |
<x2048> I would still appreciate opinions from coredevs on the default exposure for tonemapping, now that exposure control is a thing. |
| 20:52 |
sfan5 |
2.5 is just too much imo |
| 20:55 |
MTDiscord |
<x2048> I'd suggest going with 1.0 by default, as it matches the no-shader level, and it makes math easier. |
| 20:55 |
sfan5 |
wait are we discussing how it should look like with when the user chooses to enable tonemapping? |
| 20:55 |
sfan5 |
or new defaults? |
| 20:56 |
MTDiscord |
<x2048> We are discussing how it will look by default with tonemapping. Players can tune exposure_level to make it brighter or darker. |
| 20:57 |
sfan5 |
ok |
| 20:57 |
sfan5 |
my opinion probably doesn't count for that since I never enable tonemapping nor am I planning to |
| 20:57 |
MTDiscord |
<x2048> The image 1 is the current default, image 4 is the new proposed default for tonemapping. |
| 20:57 |
MTDiscord |
<x2048> 2 and 3 for reference without tonemapping / shaders. |
| 20:58 |
MTDiscord |
<x2048> Tonemapping is a must for bloom, dynamic light, godrays etc. |
| 21:02 |
MTDiscord |
<x2048> Another set of images: |
| 21:02 |
MTDiscord |
<x2048> No shaders: |
| 21:02 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1028774431029469194/Screenshot_20221009_230146.png |
| 21:02 |
MTDiscord |
<x2048> Tonemapping, Factor 1.0 |
| 21:02 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1028774521668386896/Screenshot_20221009_230113.png |
| 21:02 |
MTDiscord |
<x2048> Tonemapping, Factor 2.5 |
| 21:02 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1028774585451159572/Screenshot_20221009_230122.png |
| 21:03 |
sfan5 |
1.0 looks kinda dull, what about 1.5 or such? |
| 21:05 |
MTDiscord |
<x2048> What if the game can control the value? |
| 21:07 |
sfan5 |
the game should be able to anyway |
| 21:07 |
MTDiscord |
<x2048> Here is 1.5 |
| 21:07 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1028775669427097610/Screenshot_20221009_230522.png |
| 21:07 |
MTDiscord |
<x2048> I'd leave 1.5 to MTG then, as it will be different between the games. |
| 21:12 |
MTDiscord |
<x2048> BTW, having a factor of 1.5 is the same as saying that top 33% of all color values is overexposure. |
| 21:19 |
MTDiscord |
<x2048> Here is a different texture pack |
| 21:19 |
MTDiscord |
<x2048> No shaders |
| 21:19 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1028778849636450304/Screenshot_20221009_231044.png |
| 21:20 |
MTDiscord |
<x2048> Tonemapping, Exposure 1.0 |
| 21:20 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1028778946818478121/Screenshot_20221009_231503.png |
| 21:20 |
MTDiscord |
<x2048> Tonemapping, Exposure 1.5 |
| 21:20 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1028778992561569842/Screenshot_20221009_231740.png |
| 21:21 |
MTDiscord |
<x2048> Tonemapping will always tone-down colors from textures, because it reserves higher color values for 'HDR' part => tonemapping an SDR image will always make it 'dull' |
| 21:54 |
|
YuGiOhJCJ joined #minetest-dev |
| 22:12 |
|
jwmhjwmh joined #minetest-dev |
| 22:37 |
|
panwolfram joined #minetest-dev |
