| Time |
Nick |
Message |
| 00:39 |
rubenwardy |
sfan5: what should be the behaviour when connecting to a localhost server? #12284 |
| 00:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/12284 -- [No Squash] Show dep errors in Select Mods modal by rubenwardy |
| 00:39 |
rubenwardy |
Oops |
| 00:39 |
rubenwardy |
#12185 |
| 00:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/12185 -- Add login/register dialog to separate register and login by rubenwardy |
| 00:41 |
rubenwardy |
Options: |
| 00:41 |
rubenwardy |
* hide register button, register from login |
| 00:41 |
rubenwardy |
* keep register button, but allow register from login |
| 00:41 |
rubenwardy |
* No change |
| 00:52 |
rubenwardy |
I'm worried that users will think the button disappearing means you can't register |
| 00:52 |
rubenwardy |
But also then it makes the feature undiscoverable |
| 01:19 |
|
fluxionary joined #minetest-dev |
| 02:24 |
MTDiscord |
<exe_virus> Client knows who they've registered/visited before, correct? Have the button change to match that fact on a per server basis? |
| 02:25 |
rubenwardy |
they don't know for certain - the user may have connected on a different client, they may change their username, or the server may have deleted their account |
| 02:33 |
MTDiscord |
<exe_virus> Fair, well then no change |
| 02:36 |
rubenwardy |
can always go with no change and see if it's annoying |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 08:04 |
|
Fixer joined #minetest-dev |
| 08:22 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:22 |
sfan5 |
rubenwardy: no idea, I didn't look at that PR at all yet |
| 11:13 |
|
HuguesRoss joined #minetest-dev |
| 11:41 |
sfan5 |
rubenwardy: localhost should be consistent with any other server, power users can use the setting |
| 11:46 |
erle |
which setting? |
| 11:49 |
sfan5 |
Zughy[m]: you seem to have puts lots of issues that don't fit in any other category into "@ Startup / Config / Util", I don't think that fits |
| 11:50 |
erle |
rubenwardy, i thought a bit about the interface and i wonder: UX-wise, if you only get to know during a login process if you need to register an account, what is the motivation to have a system with an impedance mismatch? |
| 11:51 |
rubenwardy |
What does that even mean? |
| 11:51 |
erle |
rubenwardy like, the way the process works “on the wire” is currently mirroring the interface. why would anyone, ever, want to introduce something that has transformational overhead? |
| 11:51 |
erle |
oh wait, i can explain |
| 11:51 |
rubenwardy |
sfan5: yeah I noticed that too, I've been relabelling it |
| 11:51 |
rubenwardy |
erle: user experience |
| 11:51 |
rubenwardy |
It's much better than the current confirmation dialog, and will match user experience better |
| 11:52 |
rubenwardy |
UX expectations* |
| 11:52 |
rubenwardy |
It's rare for sites to have login to register, that feels like a 90s chatroom thing |
| 11:53 |
erle |
rubenwardy in computing systems, you can encounter situations where some process or some data does not match the interface you are using to access it. this can be a GUI issue or a library API issue. this is called an “impedance mismatch” (borrowed from the electrical engineering term). |
| 11:54 |
erle |
rubenwardy you might be familiar with bugs or confusion arising from that if you ever accessed a relational database using an object-relational mapper (ORM). the term is “object-relational impedance mismatch”. |
| 11:54 |
rubenwardy |
The protocol does distinguish between login and register |
| 11:54 |
rubenwardy |
That's the reason why this is possible |
| 11:55 |
erle |
it can happen in UX too, when the UI does not match the process. by far the most common way i have seen this happen is if some system has an established way to do it and then years later someone decides or suspects that users “want” or “expect” it differently. you can pretty easily distinguish the ones who actually care what users think from those who have only a rough idea by asking if they have made user studi |
| 11:55 |
erle |
es. the nielsen group for example, does this. |
| 11:56 |
erle |
yes, i know how the protocol looks |
| 11:57 |
erle |
however, the impedance mismatch here is not between the ”protocol” as in “network protocol”, but as in “protocol” like “the entire sequence of user actions”. |
| 11:57 |
erle |
(this is the “turing complete user” POV that olia lialina wrote about) |
| 11:58 |
erle |
so in this case, the mismatch occurs not on the network, but exactly where you already spotted it |
| 11:58 |
erle |
<rubenwardy> they don't know for certain - the user may have connected on a different client, they may change their username, or the server may have deleted their account |
| 11:59 |
erle |
but i already figured it out, from your other statement |
| 11:59 |
rubenwardy |
That's already the case with existing websites |
| 11:59 |
erle |
websites? |
| 11:59 |
erle |
<rubenwardy> It's rare for sites to have login to register, that feels like a 90s chatroom thing |
| 11:59 |
rubenwardy |
With an existing website, it shows both login and register. It doesn't assume you have an account or not |
| 11:59 |
rubenwardy |
I have done user studies, although that was targeted towards a menu redesign |
| 12:00 |
rubenwardy |
"how do I create an account on a server" and not having a password are two common complaints as well |
| 12:00 |
erle |
that statement – correct me if i am wrong – seems to me as if “UX expectations” you worry about are about *new* users, not about existing users. |
| 12:00 |
rubenwardy |
Yes |
| 12:01 |
erle |
yeah, that eplains it then |
| 12:01 |
erle |
for me |
| 12:01 |
rubenwardy |
A big part of user experience is onboarding |
| 12:01 |
rubenwardy |
By which I mean making clear what something does without the user doing it |
| 12:01 |
erle |
true. it is also very common for old systems to not match whatever is expected by some rando with no experiences. |
| 12:01 |
erle |
(no experiences with that specific system) |
| 12:02 |
freshreplicant[m |
I suppose for registration, you'd generally worry about new users, rather then old users who are probably registered already, no? |
| 12:03 |
erle |
not necessarily. new servers pop up all the time. |
| 12:03 |
erle |
so even if you played minetest for years you might register at one today. |
| 12:03 |
erle |
accounts are not global (for good measure, lol) |
| 12:04 |
erle |
freshreplicant[m the tension here is between making the interface as appealing as possible to newcomers without upsetting existing users (i.e. they think the option went away or so) |
| 12:04 |
erle |
at least that is my interpretation of it after reading what rubenwardy wrote |
| 12:05 |
rubenwardy |
Exactly that |
| 12:05 |
erle |
curiously, a lot of software works just fine without optimizing onboarding. it is often neglected, because devs and power users know all the idiosyncrasies. |
| 12:05 |
rubenwardy |
Which is why the login dialog is still on that tab, and there's a setting to remove separate register |
| 12:06 |
erle |
in fact, you can see this in minetest mods and games very often. with the exception of crafting – where the inventory may help, a lot of mechanics remain unexplained. |
| 12:07 |
erle |
i have been struggling with this realization for a while tbh |
| 12:07 |
erle |
like, how would anyone, without reading the documentation, know that you have to punch a tree? it's not a thing you'd accidentally do. |
| 12:08 |
erle |
this is, of course, not the fault of the minetest engine. it's a game design thing. |
| 12:08 |
sfan5 |
you wouldn't accidentally punch a tree? |
| 12:08 |
erle |
and games can overcome it. achievements, for example, hint at what is possible and create a riddle for the player. |
| 12:08 |
erle |
sfan5 it does not drop immediately. i think nodecore is a typical example for minetest players how random game mechanics can feel. |
| 12:09 |
sfan5 |
true |
| 12:09 |
sfan5 |
I do find nodecore confusing and hard to discover how things are supposed to work |
| 12:10 |
erle |
same, i gave up playing it. but imagine you had a friend who would tell you! |
| 12:10 |
erle |
like some nodecore expert |
| 12:10 |
erle |
i think minetest game (and many other things) basically works because everyone who recommends it can also say “punch a tree and also the pickaxe recipe is this and that” |
| 12:11 |
erle |
i haven't had a good solution for this, but i'm planning to add a bunch of hints every time someone complains |
| 12:12 |
erle |
like, you know, player gets into a minecart and you get a “punch the minecart to accelerate” |
| 12:12 |
erle |
i would love to be able to solve it in a more general way, but i doubt that is easily possible within the engine |
| 12:12 |
erle |
or rather, every engine feature that would make it possible is kind of spoileriffic |
| 12:13 |
erle |
though i think the weapon cooldown should have some visual indicator. hmm, is it an engine feature even? |
| 12:18 |
erle |
it seems not https://github.com/minetest/minetest/issues/5823 |
| 12:19 |
erle |
i think i meant full_punch_interval |
| 12:20 |
erle |
is there any way to have an indicator for that? |
| 12:20 |
MTDiscord |
<luatic> Currently? |
| 12:20 |
erle |
yes |
| 12:20 |
MTDiscord |
<luatic> Yes. Server-controlled and thus laggy though. |
| 12:21 |
erle |
sounds bad, but pls give me a link |
| 12:21 |
MTDiscord |
<luatic> Options include abusing tool wear our registering your own HUD elements. |
| 12:21 |
MTDiscord |
<luatic> or* |
| 12:21 |
MTDiscord |
<Warr1024> NodeCore's onboarding experience is actually one of the things that most of the design energy goes into. |
| 12:21 |
erle |
“you do not do much more damage if you click super fast” is hard to explain |
| 12:21 |
MTDiscord |
<luatic> ah that's another issue, but tool bars can convey this |
| 12:22 |
MTDiscord |
<luatic> also I believe the swinging anim kinda conveys it? |
| 12:22 |
MTDiscord |
<Warr1024> I'm not 100% satisfied with it, but keeping its target audience just 1 or 2 steps shy of rage quitting is not easy. |
| 12:22 |
erle |
Warr1024 it's not that nodecore is bad. it just suffers from not having 10 years of history and being entirely unlike most other games. exile for example, is a lot different than other games, but still similar enough. or repixture. |
| 12:23 |
MTDiscord |
<Warr1024> Yeah, people complain that it's "not intuitive" but then of course they haven't invested the time in building an intuition for it like they have for other games... |
| 12:23 |
erle |
luatic you would think that, right? yet, look at #4714 |
| 12:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/4714 -- Visual weapon swing time doesn't correspond with full punch interval |
| 12:23 |
MTDiscord |
<Warr1024> Having game devs able to control the speed of some animations would be nice, yeah. |
| 12:24 |
|
Taoki joined #minetest-dev |
| 12:26 |
erle |
i just realized that “keeping its target audience just 1 or 2 steps shy of rage quitting” might be the fundamental design principle behind nodecore and now i feel enlightened! |
| 12:30 |
MTDiscord |
<Warr1024> I sort of ended up optimizing it for hardcore puzzle players who are tired of being spoonfed by other games. |
| 12:30 |
erle |
that's legit |
| 12:30 |
erle |
i mean, if i want a puzzle on rails i'll go play “inside the box” |
| 12:31 |
MTDiscord |
<Warr1024> It does also seem to feel like it appeals to other types of gamers too, though some of that may be an accident to some extent. |
| 12:31 |
rubenwardy |
I prefer puzzles where the rules aren't so opaque. Games like Portal and Inside the box are good at introducing things gradually |
| 12:32 |
MTDiscord |
<Warr1024> ITB I found didn't really have much of a creative angle to the solving though. The solutions too often were "in the box" in the original sense. |
| 12:33 |
MTDiscord |
<Warr1024> Portal has the level of flexibility necessary to allow for creative solutions, but it was too skill-dependent. I wanted a puzzle game that was more purely about solving puzzles and not so much about executing solutions. |
| 12:34 |
erle |
rubenwardy i bet you like the original half-life and half-life 2. bothe are great at introducing mechanics gradually. also they have some pretty interesting game design ideas: like aliens in half life making a sound before they teleport in or attack. or you being able to hear the radio of the combine soldiers in half life 2 (they act tactical and you can basically listen to that and deduce who spotted the player). |
| 12:34 |
erle |
rubenwardy, am i right? :) |
| 12:34 |
rubenwardy |
Yeah I do like those |
| 12:35 |
MTDiscord |
<Warr1024> Besides, for me to instruct players I would need to know in advance everything about the game, and if it weren't for players discovering things about NodeCore all the time that I hadn't anticipated, I might have just lost interest in developing it long ago. |
| 12:36 |
erle |
oh yeah, players discovering random stuff is great. i try to preserve useful glitches because of that. |
| 12:36 |
MTDiscord |
<Warr1024> I liked the original half-life games too, up until they ran out of new content and then depended on mods, most of which were pretty blah. |
| 12:37 |
Zughy[m] |
sfan5: I couldn't fit some issues on any "@ <whatever>" and I thought to put it in "util", I was kinda desperate |
| 12:37 |
MTDiscord |
<Warr1024> Trying to make a game that lasts a long time and doesn't suddenly run out of replay value is super hard. |
| 12:39 |
erle |
Warr1024 you can definitely sabotage any effort to take the simple way out though. for example, “dungeon crawl: stone soup” has both an “autoexplore” and an “autofight” key, to go to unexplored parts of a level and to punch/shoot the nearest enemy. turns out if you mash both of those, you get reliably nowhere, because the game was made deliberately to avoid players having success with grinding. |
| 12:39 |
erle |
given that i mentioned that |
| 12:41 |
erle |
rubenwardy sfan5 how much resistance would be there to make digging a toggle-able thing, like going forward? i have read the reviews of repixture and i must say, clicking a lot does indeed put strain on hands. also autodig alone is no cheat (can't even dig a tunnel with it, because the player is 2 high). |
| 12:41 |
rubenwardy |
Zughy[m]: you don't have to label everything with @, and that could be a sign that an @ is missing |
| 12:41 |
rubenwardy |
erle: that makes sense for accessibility |
| 12:42 |
rubenwardy |
most game accessibility guides recommend having alternatives for things that require holding a button or spamming a button |
| 12:42 |
rubenwardy |
how would you distinguish between punch and dig? |
| 12:43 |
erle |
input-wise, there is no difference. so why does that matter? |
| 12:43 |
rubenwardy |
it's useful to be able to dig stuff |
| 12:43 |
erle |
spamclicking punches does not give you an advantage because of the punch interval |
| 12:43 |
rubenwardy |
*punch |
| 12:43 |
rubenwardy |
Punching a mesecons button will flip it, digging will dig it |
| 12:44 |
erle |
oh, you mean dig vs use |
| 12:44 |
rubenwardy |
so if you make it togglable or autodig, you'd need a key rather than just clicking the button |
| 12:44 |
rubenwardy |
use is on the item you're holding, if the item has no use callback it punches what you're focusing on |
| 12:44 |
rubenwardy |
as an oversimplification |
| 12:45 |
erle |
but i was not saying autouse |
| 12:45 |
MTDiscord |
<Warr1024> I've actually had some accessibility challenges due to input controls. I needed an extra form of interaction, so developed the "pummel" from repeated punching. I originally designed it to be time-based rather than spam-clicky due to mobile (it's better to develop a slow rhythm) but even that was a lot for some players with repetitive strain injuries. Luckily things like input macros and alternative control devices seemed to help. |
| 12:45 |
rubenwardy |
you still need to be able to use though - you can't just toggle with the mouse button. So you'd need a key for it |
| 12:46 |
MTDiscord |
<Warr1024> I couldn't use punch alone because (1) I wanted it not to be fast, and (2) I wanted it to be possible to dig without triggering the action, and you can't dig without punching first. |
| 12:46 |
erle |
there is only one use case i have seen for autouse so far and it is autoeat. and the intervals are far too big for any toggle switch to be of use, except for the case of “falling through the void from the end onto the nether roof”. as the story goes, someone™ managed to do this with chugging a lot of healing potions, surviving 1000 nodes of void damage or so. |
| 12:46 |
erle |
the autoeat mod is btw how i spot cheaters. they eat in perfect intervals. ;) |
| 12:47 |
MTDiscord |
<Warr1024> Theoretically, on desktop you have a lot of "bucky" options, like you can dig, sneak-dig, aux-dig, sneak-aux-dig, and in some cases do wild things like walk left and right at the same time while sneak-aux-digging, so there's already a lot of flexibility to the controls ... it's just not very obvious and some of those are a huge pain. |
| 12:47 |
erle |
R.I.P. going left-right while autoforward :/ |
| 12:48 |
erle |
(it was useful for boats and mountable animals, holding down forward hurts for me) |
| 12:50 |
erle |
rubenwardy i would think that autodig would have a similar “just hold down the button” feeling as autoforward |
| 12:50 |
erle |
i.e. have a key to toggle it on and off |
| 12:50 |
erle |
then players could have it on and move around |
| 12:50 |
erle |
and stop complaining about long digging times |
| 12:52 |
erle |
Zughy[m] any interest in confirming this one? https://github.com/minetest/minetest/issues/11749 |
| 13:01 |
MTDiscord |
<Warr1024> "Holding forward hurts for me" is a WASDism ? When mouselook started to become a thing in the early 90's, rather than just defaulting to WASD, I did a little thinking and came up with my own ergonomic key scheme. "Forward" ended up on the spacebar, which is actually pretty easy to hold. One rather curious consequence is that it's trivial for me to hold all 4 directions at the same time... |
| 13:02 |
rubenwardy |
Pushing trivial bug fix in 5 minutes: https://github.com/rubenwardy/minetest/commit/9824a451bb8d6f632aa80abc186f440f8d5a745a |
| 13:02 |
rubenwardy |
!title |
| 13:02 |
ShadowBot |
Fix mods not being recursively enabled · rubenwardy/minetest 9824a45 · GitHub |
| 13:02 |
rubenwardy |
So many bugs found just by testing the darned thing |
| 13:05 |
sfan5 |
unittests when |
| 13:05 |
rubenwardy |
soon :tm: |
| 13:05 |
rubenwardy |
I plan it as part of the src/content refactor |
| 13:06 |
rubenwardy |
one implementation, unit tested |
| 13:06 |
erle |
Warr1024 bold of you to think i use WASD (i use neo2) |
| 13:09 |
MTDiscord |
<Warr1024> Everyone uses WASD and I don't understand it ? |
| 13:09 |
MTDiscord |
<Warr1024> What is neo2? |
| 13:13 |
erle |
Warr1024 https://en.wikipedia.org/wiki/Neo_(keyboard_layout) |
| 13:13 |
rubenwardy |
sfan5: would you be happy for #12253 to be merged as trivial? |
| 13:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/12253 -- Fix enabling of dependencies with identical names by TurkeyMcMac |
| 13:13 |
erle |
Warr1024 it's a useful layout for german/english, math/science and programming characters. puts less strain on hands too. |
| 13:14 |
sfan5 |
merge it if you think it's good |
| 13:14 |
erle |
rubenwardy sfan5 does #12253 always prefer the already enabled mod? |
| 13:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/12253 -- Fix enabling of dependencies with identical names by TurkeyMcMac |
| 13:14 |
erle |
it looks like it |
| 13:42 |
rubenwardy |
another trivial one #12202 |
| 13:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/12202 -- Enable dependencies when enabling modpacks by TurkeyMcMac |
| 13:45 |
erle |
rubenwardy wouldn't it make sense to have unit tests for exactly these kinds of changes? |
| 13:45 |
erle |
to ensure nothing goes wrong |
| 13:45 |
rubenwardy |
<+rubenwardy> I plan it as part of the src/content refactor |
| 13:46 |
rubenwardy |
I'm making a list of test cases |
| 13:46 |
erle |
well, at least i wouldn't have much faith in that this simple action does not mess up anything without having at least some tests for that. |
| 13:46 |
rubenwardy |
I currently have 7 mods folders with different test cases |
| 13:46 |
erle |
neat |
| 13:46 |
erle |
show? |
| 13:47 |
erle |
(i want to confirm the dep issues i found are in there) |
| 13:47 |
rubenwardy |
they're all attached in PRs |
| 13:51 |
rubenwardy |
I could make integration tests for the pkgmgr code already, those could end up being quite portable. Having to commit the mods into the repo is annoying though. Could make a function to make them temporarily |
| 13:54 |
|
appguru joined #minetest-dev |
| 14:08 |
rubenwardy |
Hmm, Minetest does show a chat error for unsatisfied mods already, so maybe we can get away with making it a hard error now |
| 14:08 |
rubenwardy |
RE: #12217 |
| 14:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/12217 -- Prevent loading a world with unresolved dependencies |
| 14:10 |
rubenwardy |
#12284 will make it much easier to resolve as well |
| 14:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/12284 -- [No Squash] Show dep errors in Select Mods modal by rubenwardy |
| 14:31 |
erle |
rubenwardy i think you can not get away with making it a hard error unless the “optional dependencies turned into hard dependencies” bugs are all fixed. are they? |
| 14:32 |
rubenwardy |
not a bug |
| 14:32 |
rubenwardy |
it's intended behaviour, optional dependencies are only optional at Select Mods time |
| 14:33 |
rubenwardy |
so the solution to this is to throw an error, and make users disable those mods if they don't want to use them |
| 14:33 |
rubenwardy |
Please read that issue for more context |
| 14:33 |
rubenwardy |
and that PR has a screenshot in a comment showing what happens when you have "optional dependencies turned into hard dependencies" |
| 14:42 |
|
Baytuch joined #minetest-dev |
| 14:57 |
erle |
rubenwardy does your mod unit test thing have a test that equals the “can you still break stuff in mineclone2” test? |
| 14:58 |
rubenwardy |
that's way too vagu |
| 14:58 |
rubenwardy |
do you mean an optional dependency in a game causing a game mod to break? |
| 14:58 |
erle |
right |
| 14:58 |
erle |
i explain |
| 14:59 |
rubenwardy |
that's something I have tested manually for the modconfig PR, added to the list now |
| 14:59 |
rubenwardy |
#12295 |
| 14:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/12295 -- Content/pkgmgr test plan |
| 15:04 |
rubenwardy |
here's what happens if a game mod opt-depends on a mod with errors: https://user-images.githubusercontent.com/2122943/167278461-2a79f660-2f70-43d6-8791-3965e281ade5.png |
| 15:04 |
rubenwardy |
well, in that screenshot butterflies -> flowers -> uses_notinstalled -XX-> notinstalled |
| 15:06 |
erle |
rubenwardy, about the breaking stuff in mineclone2: in the absence of dependency constraints, minetest loads mods reverse alphabetical order. people have been relying on that to be able to load mods as late as possible. the best example is _mcl_autogroup, which wants to be loaded after all tools and nodes are loaded to set dig groups so that the dig times closely match minecraft. |
| 15:06 |
rubenwardy |
ah |
| 15:06 |
erle |
so, uh, multiple attempts at removing or refactoring this awful hack have resulted in people unable to dig stuff |
| 15:06 |
rubenwardy |
well, that's not actually guaranteed by the mod dependency system |
| 15:07 |
rubenwardy |
there's an issue for loads first mods |
| 15:07 |
rubenwardy |
mcl2 should probably have all its mods depend on _mcl_autogroup |
| 15:07 |
erle |
no |
| 15:07 |
erle |
you misunderstand |
| 15:07 |
erle |
no mod is allowed to depend on _mcl_autogroup |
| 15:07 |
erle |
it must load AFTER everything else |
| 15:07 |
rubenwardy |
ah |
| 15:08 |
rubenwardy |
why not use register_on_mods_loaded? |
| 15:08 |
erle |
some reason that escapes me. you are not the first to suggest it. |
| 15:08 |
erle |
in fact, there exists mcl_autogroups and _mcl_autogroups, with only the code that can not reasonably be stuffed into the first put into the latter, if i am not mistaken. |
| 15:10 |
erle |
even if it is not officially guaranteed, the “in the absence of anything else, load reverse alphabetical” seems to be really simple to do once you have a topological sort of the dpendencies (which i assume you want before loading them) |
| 15:11 |
MTDiscord |
<ROllerozxa> _mcl_autogroup needs to be able to change item definitions right? so it would be too late in register_on_mods_loaded, because I remember seeing someone trying to do a similar thing on minetest discord using that callback to edit definitions after all mods have been loaded and failing |
| 15:11 |
erle |
and yes, the most common suggestions were register_on_mods_loaded(), minetest.after(0, […]) and “make it depend on everything else”, which all seemed to not work (the last one is most obvious, it will not work with third party mods ever). |
| 15:11 |
erle |
oh yeah that could it be |
| 15:11 |
erle |
it certainly has not stayed that way for lack of trying |
| 15:12 |
sfan5 |
rubenwardy: you can merge #12202 too if you consider it alright |
| 15:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/12202 -- Enable dependencies when enabling modpacks by TurkeyMcMac |
| 15:12 |
erle |
not sure though, i suggest to ask Elias Åström <ryvnfriseup.net> |
| 15:13 |
rubenwardy |
I was testing but then got distracted by more testing |
| 15:13 |
erle |
i think that should be made the official slogan of minetest |
| 15:14 |
MTDiscord |
<ROllerozxa> I thought the official slogan of minetest was "Build with blocks, then get bored, then spend the rest of your week programming in Lua." 8) |
| 15:14 |
erle |
rubenwardy anyways, as long as there is no alternative to handle the “my mod needs to load as late as possible, given the stated dependency graph” case, changing the mod load order in ways that _mcl_autogroups is loaded before any mod that starts with an ASCII letter will make many people very unhappy. |
| 15:15 |
erle |
given that it's easy and cheap to have the reverse alphabetic constraint since it does not interfere with anything else, i suggest to simply document it and add it to the unit tests. |
| 15:16 |
erle |
(it does not interfere bcause it can always be applied after everything else is calculated, just by sorting the sublists of the dep tree) |
| 15:18 |
erle |
and yes, it's a silly constraint for a dependency resolution system. as i have said, this hack is there because nothing else seemed to work. |
| 15:18 |
rubenwardy |
It would be nice to know why they can't use on mods loaded |
| 15:27 |
erle |
https://git.minetest.land/MineClone2/MineClone2/pulls/1961 |
| 15:29 |
erle |
https://irc.minetest.net/minetest-dev/2022-01-22#i_5925812 |
| 15:29 |
erle |
> the reason for the _mcl_autogroups naming hack is that, to work correctly, the code in _mcl_autogroups needs to be run after all other mods have loaded, but before all on_mods_loaded callbacks defined by other mods |
| 15:30 |
erle |
rubenwardy that clear enough? |
| 15:30 |
rubenwardy |
You can inject to the start of that callback using table.insert |
| 15:31 |
erle |
(in the old irc discussion you also see the misunderstanding “make a mod depend on autogroups” vs the reality “autogroups has to depend on every mod inexistence for it to continue to work without the underscore hack”) |
| 15:31 |
erle |
inexistence → in existence |
| 15:33 |
erle |
rubenwardy do you have an example of that a) working well b) being guaranteed to not also change some time? |
| 15:34 |
erle |
well, the code to workaround any sorting order changes is likely orders of magnitude more than a simple sort operation. anyways, i just wanted to make you aware of this so that you can keep it in mind. |
| 15:38 |
MTDiscord |
<ROllerozxa> hm, I just tried enclosing the overwrite function call in _mcl_autogroup a register_on_mods_loaded function and it... did not blow up, it still works? or block breaking still worked at least |
| 15:39 |
erle |
ROllerozxa now you hae to verify that this also works for all digtimes with all enchantments and if any other mod does something funny on_mods_loaded |
| 15:40 |
erle |
in particular enchantments are quite funny. as in, horrible. |
| 15:40 |
erle |
for the sake of not relying on awful hacks, i'd welcome a solution here. |
| 15:41 |
sfan5 |
you were given suggestions but it seems to me that you expect other people to do all the work for you and deliver a finished package to your doorstep |
| 15:51 |
erle |
sfan5 more like “everyone who i have seen actually trying to solve this has failed so far, so i am not likely to believe anyone who comes up with a new suggestion” |
| 15:52 |
erle |
i have wasted hours on this myself |
| 15:52 |
MTDiscord |
<luatic> It is indeed a tricky issue: How do you make a mod that does hacky (but necessary) API overrides load before all other mods? |
| 15:53 |
MTDiscord |
<luatic> The only way currently is to use naming hacks (or to use even worse hacks to make all other mods depend on that mod) |
| 15:53 |
MTDiscord |
<luatic> TBF the cleanest solution I can imagine is some mcl_default mod depending on mcl_autogroup and all MCL mods depending on mcl_default. |
| 15:54 |
erle |
this just seems like the kind of problem to me where every obvious approach is subtly wrong. i know a bunch of other problems like that, but the most common I know is “how to implement dependency resolution in the context of a build system” (which is similar to, but not the same as mod loading order). |
| 15:55 |
sfan5 |
erle: you have both my suggestion(s) from January and what rubenwardy said now, if nobody actually tests these out I have to assume that MCL* devs are not actually interested in a fix |
| 15:58 |
rubenwardy |
Would be interesting to shuffle mods before resolving dependencies as a mod Dev tool, would allow finding missing deps |
| 15:59 |
erle |
sfan5 i am under the impression that none of your suggestions work for the general case (which includes third-party mods), except for “1) modifying all tools thus far and 2) redefining register_tools for all tools to come”, which I have not tried and i am not aware anyone did. |
| 15:59 |
erle |
i can assure you, it's not out of lazyness, it's that any replacement has to be as good as the underscore hack |
| 16:03 |
erle |
rubenwardy i strongly support having a shuffle as a debugging option. however, if it is activated, it should probably also output the load order it came up with, to aid debugging. |
| 16:04 |
|
Fleckenstein joined #minetest-dev |
| 16:38 |
|
YuGiOhJCJ joined #minetest-dev |
| 16:43 |
sfan5 |
merging #12288, #12283, #12277 in 10-20mm |
| 16:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/12288 -- strict.lua: remove unused variable WARN_INIT by Zughy |
| 16:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/12283 -- Fix mapblock geometry optimisation not working by rollerozxa |
| 16:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/12277 -- [no squash] Random performance improvements by sfan5 |
| 16:43 |
sfan5 |
s/mm/m/ |
| 16:46 |
rubenwardy |
Nice |
| 16:46 |
rubenwardy |
Milliminutes |
| 16:46 |
rubenwardy |
0.06s |
| 16:46 |
rubenwardy |
Well, x10-20 |
| 16:47 |
rubenwardy |
So 0.6s-1.2s. You're late |
| 16:47 |
MTDiscord |
<luatic> Millimetres xD |
| 17:35 |
sfan5 |
when's the meeting again |
| 17:35 |
rubenwardy |
7pm UTC? When did the clocks go back, I don't remember it being this late |
| 17:36 |
rubenwardy |
27 march in the UK, a while ago |
| 17:37 |
rubenwardy |
Make sure to update the agenda if you have anything |
| 17:37 |
rubenwardy |
!dev Meetings |
| 17:38 |
ShadowBot |
Meetings - Minetest Developer Wiki -- http://dev.minetest.net/Meetings |
| 17:38 |
Cosmosis[m] |
Is this channel the same as the IRC one? |
| 17:40 |
sfan5 |
this is #minetest-dev on irc.libera.chat |
| 17:40 |
Cosmosis[m] |
Is anyone allowed to participate in the meetings? |
| 17:40 |
rubenwardy |
Yes, but you should only discuss the current meeting point |
| 17:41 |
Cosmosis[m] |
Ok, will do |
| 17:41 |
rubenwardy |
The top of the meetings page has some info |
| 17:44 |
Cosmosis[m] |
So the meeting is 4PM EDT? |
| 17:45 |
sfan5 |
if that's in 1h15m, then yes |
| 17:45 |
rubenwardy |
Haha |
| 17:45 |
Cosmosis[m] |
wait, is it 7pm UTC? |
| 17:45 |
rubenwardy |
We should use that time is link to handle all these time conversions |
| 17:47 |
Cosmosis[m] |
nvm it's 3PM EDT |
| 17:47 |
Cosmosis[m] |
time is hard |
| 17:49 |
rubenwardy |
https://time.is/1900_8_May_2022_in_UTC?Minetest_core_dev_meeting |
| 17:50 |
rubenwardy |
wish it would show the local time more prominently |
| 17:50 |
Cosmosis[m] |
neat |
| 17:50 |
rubenwardy |
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Minetest+core+dev+meeting&iso=20220508T19&p1=1440&ah=1 |
| 18:30 |
Krock |
in 30 minutes. that's not timezone dependent. |
| 18:37 |
rubenwardy |
for me, it shows the UTC time in medium size, local time in small size, and countdown in large size |
| 18:38 |
rubenwardy |
imo it should be small/med/large rather than med/small/large |
| 18:38 |
rubenwardy |
I suppose for actual events you may be interested in the time at the event location |
| 18:38 |
rubenwardy |
actual -> irl |
| 18:39 |
sfan5 |
if someone volunteers to pay for accomodation and travel we can do irl meetings too |
| 18:39 |
rubenwardy |
haha |
| 18:40 |
Krock |
guys I just found a new purpose for the donation button /s |
| 18:40 |
rubenwardy |
Mese Con confirmed |
| 18:53 |
Pexin |
"mese con" took me a minute but I got there |
| 19:01 |
Krock |
> Minetest core dev meeting - Event in progress |
| 19:03 |
rubenwardy |
hello |
| 19:03 |
HuguesRoss |
hey |
| 19:03 |
erle |
ih |
| 19:03 |
erle |
hi |
| 19:03 |
Krock |
there's not much in today's meeting |
| 19:03 |
erle |
a mese con would obviuosly need to happen in minetest itself |
| 19:03 |
sfan5 |
I'll go for a bathroom break bu perhaps yall can think about 5.5.1 in your mind already |
| 19:04 |
sfan5 |
+t |
| 19:04 |
Krock |
https://github.com/minetest/minetest/commits/backport-5 |
| 19:04 |
erle |
given that there is already the backport-5 branch (which shows a need) what arguments except “doing a release is work” are there? |
| 19:05 |
erle |
also, is that branch suitable as a 5.5.1? |
| 19:06 |
erle |
btw, i bet distro packagers appreciate not having to figure out which patches to backport |
| 19:06 |
Pexin |
where is the roadmap list for 5.6? |
| 19:06 |
Krock |
https://github.com/minetest/minetest/milestones according to this, we're 76% done |
| 19:07 |
paradust |
(side note: the discord/irc bridge is broken) |
| 19:07 |
HuguesRoss |
From a quick look at that backport branch, I'm not 100% on if #12000 would fit in a X.X.1 or would be better left to 5.6 |
| 19:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/12000 -- Fix builtin statbar backgrounds by appgurueu |
| 19:08 |
HuguesRoss |
That one's a bugfix, but I believe it's a fairly long-standing bug and it's a minor change in behavior |
| 19:08 |
HuguesRoss |
I wouldn't go as far as to call it a feature though |
| 19:08 |
* sfan5 |
back |
| 19:09 |
Krock |
so the question is whether to priorize 5.6.0 or delay for a 5.5.1 release |
| 19:09 |
sfan5 |
we can do both |
| 19:09 |
Krock |
if it doesn't cause too much work |
| 19:10 |
HuguesRoss |
I'd like to avoid any big delays to 5.6 since it has some stuff that was pushed back from 5.5 |
| 19:10 |
HuguesRoss |
But as long as 5.5.1 doesn't take too long it could be nice to have |
| 19:10 |
rubenwardy |
release early, release often is preferable - this applies to patches too though |
| 19:10 |
Krock |
I don't think there's another disadvantage from releasing a 5.5.1 version |
| 19:11 |
Krock |
so #12000 could be included as well as a less important fix |
| 19:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/12000 -- Fix builtin statbar backgrounds by appgurueu |
| 19:11 |
sfan5 |
last time my concerns with 5.5.1 were 1) doing a release is work and 2) someone might come around with a new critical bug soon (given that public servers are currently under an involuntary stress test) |
| 19:11 |
sfan5 |
this is not to say that I'm against it |
| 19:12 |
Krock |
critical bugs can always appear and it's been like that forever |
| 19:12 |
HuguesRoss |
Yeah, as long as people are fine with it we can leave it in, it's already in backport-5. I wanted to mention it just so folks were aware of the change, but it's not a big deal either way |
| 19:12 |
erle |
IMO “someone might find a new critical bug soon” is no good argument against doing a release that fixes a critical bug (wasn't there something about 5.4 clients being crashed by 5.5 servers?) |
| 19:12 |
Krock |
HuguesRoss: it's just that compiling is rather inconvenient |
| 19:13 |
Krock |
so a proper release would do them a favour |
| 19:13 |
sfan5 |
we can discuss individial commits in the backports branch later, I just whipped that up since someone asked for it |
| 19:13 |
erle |
also a proper release would make sure that they are all on the same page |
| 19:13 |
erle |
instead of cherry-picking this and that |
| 19:13 |
HuguesRoss |
yeah, I meant we can leave it in for the release. May not have worded that well |
| 19:14 |
Krock |
erle: patch releases are only cherry-pick based |
| 19:14 |
Krock |
what you're talking about is a full release |
| 19:14 |
Krock |
s/full/normal/ |
| 19:14 |
sfan5 |
ok so in short do I count three people in favor, one neutral for 5.5.1? |
| 19:15 |
Krock |
yes, I presume. |
| 19:15 |
rubenwardy |
I'm in favour |
| 19:16 |
Krock |
Shall I open a list to keep track of the commits to push to backport-5 ? |
| 19:16 |
erle |
Krock what i meant is distribution packagers and server maintainers have no need to cherry-pick if there is an official branch |
| 19:16 |
rubenwardy |
don't we do that with a pr from backport-5 to stable-5? |
| 19:16 |
sfan5 |
I can do that, I already created that branch after all |
| 19:17 |
Krock |
rubenwardy: that happened with the 0.4 backport which became stable later on |
| 19:17 |
Krock |
currently it looks like backport-5 is a rolling patch release until there's a proper tag |
| 19:17 |
rubenwardy |
backport-5 is a dev branch that is merged into stable-5 when a patch release is made |
| 19:18 |
sfan5 |
^ that, yes |
| 19:18 |
Krock |
oh, I see. so the commit integrity is not necessary in that case |
| 19:19 |
Krock |
i.e. allowed force pushes |
| 19:19 |
rubenwardy |
merge commits mean you don't need to force push stable-5 |
| 19:19 |
Krock |
yes |
| 19:20 |
sfan5 |
sounds like that is settled, next point (which I just added): Prioritize things for 5.6? |
| 19:20 |
sfan5 |
do we want to do that now? |
| 19:20 |
sfan5 |
or maybe: when is the planned release anyway? |
| 19:21 |
rubenwardy |
I'd like it sooner than the last one - 11 months |
| 19:21 |
rubenwardy |
plenty of time to beat that |
| 19:21 |
sfan5 |
July? |
| 19:21 |
rubenwardy |
sure |
| 19:21 |
Krock |
last release was in january, plus 6 months = July |
| 19:22 |
Krock |
seems reasonable |
| 19:22 |
sfan5 |
we can always do it earlier if we think all stuff is finished |
| 19:22 |
rubenwardy |
for me, the only one I really need in 5.6 is #12217 I would like a few of my other content changes too |
| 19:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/12217 -- Prevent loading a world with unresolved dependencies |
| 19:22 |
Krock |
updating milestone to first Sunday in July |
| 19:24 |
Krock |
tyes, the dependency issues are a long-standing issue and I'm glad you're working on it |
| 19:24 |
Krock |
the suggestion is good - deprecate the current behaviour |
| 19:24 |
sfan5 |
quickly gathered list: #7629 maybe, #11545 definitely, #10265 probably, #11016 users probably want this, #11465 about time too |
| 19:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/7629 -- Run Minetest update checker on startup by SmallJoker |
| 19:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/11545 -- Animated particlespawners by velartrill |
| 19:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/10265 -- FormSpec: 9-slice images, animated_images, and fgimg_middle by v-rob |
| 19:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/11016 -- Dual Wielding by EliasFleckenstein03 |
| 19:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/11465 -- New physics overrides by Wuzzy2 |
| 19:25 |
sfan5 |
also #12131 in the "users probably want this" category |
| 19:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/12131 -- Add `minetest.settings` to CSM API and allow CSMs to provide `settingtypes.txt` by AFCMS |
| 19:25 |
sfan5 |
the issue mentioned by rubenwardy sounds good to me |
| 19:26 |
sfan5 |
if I have your opinion on mine then I can add some of them to the milestone too |
| 19:26 |
rubenwardy |
all sound good. |
| 19:26 |
HuguesRoss |
#10625 is waiting on changes, I've updated the labels accordingly |
| 19:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/10625 -- Game minimap textures are ignored by Minetest |
| 19:26 |
HuguesRoss |
They're very small though |
| 19:26 |
HuguesRoss |
err |
| 19:26 |
HuguesRoss |
#10265 |
| 19:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/10265 -- FormSpec: 9-slice images, animated_images, and fgimg_middle by v-rob |
| 19:27 |
sfan5 |
sounds likely that we can get to it then |
| 19:27 |
sfan5 |
+in time |
| 19:27 |
erle |
sfan5 is #11852 in backports-5? given it's a regression from 5.4.1 |
| 19:27 |
HuguesRoss |
Well, I hope so... it's been sitting in that state for close to a month |
| 19:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/11852 -- Parts of slime entity model are not rendered anymore when shaders are turned on (regression from 5.4.1) |
| 19:27 |
rubenwardy |
we probably need two categories here - need and want |
| 19:28 |
sfan5 |
erle: not now please |
| 19:28 |
rubenwardy |
where need is for bug fixes and critical path changes, where missing it will delay development |
| 19:28 |
rubenwardy |
well maybe not so strict of a definition |
| 19:28 |
Krock |
we could either group them by milestone or tags |
| 19:29 |
rubenwardy |
I mean I suppose we could put both in the milestone, and use High Priority / blocker for the need category |
| 19:29 |
Krock |
right. that seems reasonable |
| 19:29 |
sfan5 |
#7629 probably we need to discuss it again, not sure why it's stalled; but that's for some time later |
| 19:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/7629 -- Run Minetest update checker on startup by SmallJoker |
| 19:29 |
Krock |
I just had a look at the update checker, and it seems to be ready for review? |
| 19:29 |
HuguesRoss |
#7629 seems like a very good one to get in, while it's not a blocker it'd be good to have update notifications in |
| 19:29 |
rubenwardy |
I think that's awaiting review? |
| 19:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/7629 -- Run Minetest update checker on startup by SmallJoker |
| 19:30 |
rubenwardy |
oh looks like I was having android issues |
| 19:30 |
rubenwardy |
classic |
| 19:31 |
sfan5 |
HuguesRoss: do you have any other PRs in mind for 5.6? |
| 19:31 |
Krock |
#11545 I believe this is re-inventing the wheel by writing an interpreter which should not be needed in first place |
| 19:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/11545 -- Animated particlespawners by velartrill |
| 19:31 |
Krock |
hence I wonder whether to add to 5.6.0 |
| 19:31 |
sfan5 |
you mean CSM could do it? |
| 19:31 |
HuguesRoss |
sfan5: None that we haven't discussed |
| 19:32 |
Krock |
yes, optimally CSM would execute this in a "sandbox" |
| 19:32 |
HuguesRoss |
I'd like to see the formspec events get in, but I wouldn't block a release for it and it'll probably take too long |
| 19:32 |
Krock |
to animate the particles from there. that's more generic and allows easy extensions in the future |
| 19:32 |
sfan5 |
I agree |
| 19:32 |
sfan5 |
but CSM is far away |
| 19:32 |
sfan5 |
(unfortunately) |
| 19:32 |
Krock |
whereas it completely disregards the PR and is currently not feasible with CSM |
| 19:33 |
Krock |
exposing particles should not be too complicated though .. hmm |
| 19:33 |
erle |
well, CSM does not have to mean SSCSM though. minetest could have a CSM that has a modchannel (or how it is called) that does it and just come with it builtin. |
| 19:33 |
erle |
just like waspsaliva comes with a bunch of CSMs builtin |
| 19:34 |
Zughy[m] |
velartrill will probably be pissed off, after all the waiting, if her (?) PR gets delayed |
| 19:34 |
Krock |
this does not require entire SSCSM |
| 19:34 |
erle |
then use that for particles |
| 19:34 |
sfan5 |
Krock: I think it's reasonable to have the feature now rather than later and when CSM is eventually here probably a lot of stuff will be replaced with it |
| 19:35 |
Krock |
sfan5: I'd be fine with it, as long the feature is marked as possibly replaced in the future |
| 19:35 |
erle |
sfan5 on the other hand, you can never easily get rid of a feature you introduced |
| 19:35 |
Krock |
otherwise we'll never be able to replace it fully |
| 19:35 |
sfan5 |
well that'd be for 6.0 anyway |
| 19:35 |
sfan5 |
wouldn't it? |
| 19:35 |
Krock |
right |
| 19:35 |
erle |
Krock do you have a particle CSM? |
| 19:35 |
Krock |
erle: the functions for that do not yet exist |
| 19:35 |
HuguesRoss |
I do also think there's an argument for end-user simplicity sometimes. Having an API to define basic animations in particles will always be less of a hassle than users having to write particles_redo |
| 19:36 |
HuguesRoss |
Even if the former exists, it doesn't preclude CSM-based solutions for more advanced users either |
| 19:36 |
erle |
Krock in minetest proper, yes. but i remember that for debugging coordinate leaks waspsaliva has at least some particle spawner CSM functions. might not be rendering-related though, i forgot. |
| 19:37 |
Krock |
HuguesRoss: it would however cause feature duplication and hence bloated code |
| 19:37 |
sfan5 |
I think the argument here is that the functions provided by the PR are already pretty advanced |
| 19:37 |
erle |
Zughy[m] if “$person would be pissed if it took longer” was a good argument, a lot more merges would happen haha |
| 19:37 |
Pexin |
regarding including a "default" csm in the standard release: this would require enabling csm itself by default, unless multiple csm categories are created ("official" csm vs user-provided) |
| 19:38 |
erle |
Pexin what's wrong with enabling it by default, as long as it can only do stuff like show particles etc.? |
| 19:38 |
erle |
it would still be restricted |
| 19:38 |
erle |
by server flags |
| 19:38 |
Pexin |
csm currently is not globally enabled by default I presume for a reason |
| 19:38 |
Zughy[m] |
erle: yeah but it's been open almost a year ago and she was very responsive in applying changes, like... c'mon |
| 19:38 |
Krock |
Pexin: loading the CSM environment and loading mods within it can be treated separately |
| 19:39 |
sfan5 |
I think we're drifting off the topic |
| 19:39 |
erle |
but i want the bikeshed color decided in a CSM! |
| 19:40 |
Krock |
good, now there's some 5.6.0 goals |
| 19:40 |
sfan5 |
next point: https://github.com/minetest/minetest/issues/12251#issuecomment-1115477945 backwards compat hinders refactors, drop compat for old irrmt revisions this time? |
| 19:41 |
Krock |
how about the std::vector implementation? isn't the impact reduced now? |
| 19:42 |
Krock |
https://github.com/minetest/irrlicht/pull/101 |
| 19:42 |
HuguesRoss |
Is irrmt packaged separately? Because if not it doesn't seem like a major issue to drop backwards-compat |
| 19:42 |
sfan5 |
it is, sort of; this makes development painful when you need to change both in lockstep |
| 19:42 |
sfan5 |
Krock: what do you mean? |
| 19:43 |
sfan5 |
keeping compatibility with earlier versions is currently a "nice to have" (IMO) feature to simplify development and stuff for users |
| 19:43 |
erle |
having talked to debian ppl: irrmt is intended to be packaged by twrightsman within the minetest package |
| 19:44 |
erle |
anecdotally speaking, everyone i know already expects them to be updated in lockstep and obv that's never ideal |
| 19:44 |
erle |
(for separate components) |
| 19:45 |
Krock |
sfan5: does the switch to std::vector (internally only) have an impact on compatibility? if not, is the performance improvement in doing so too negligible ? |
| 19:46 |
sfan5 |
there's a small number of incompatible changes required https://github.com/minetest/minetest/pull/12263 |
| 19:46 |
sfan5 |
I don't know about the performance difference but getting rid of irrlicht's own containers is on the (informal) irrlichtmt roadmap anyway |
| 19:47 |
sfan5 |
to make it clear: it's not impossible to #ifdef the stuff so that it stays compatible both ways, just inconvenient |
| 19:47 |
erle |
having worked as a software developer, usually having incompat changes at both ends is dealt with by making sure you have proper mocks and unit tests that cover everything imaginable. |
| 19:48 |
Krock |
I believe modifying too much of the interface would make backporting work even harder |
| 19:48 |
Krock |
so keeping the changes minimal like in the proposed PR seems fine to me, even though it breaks compatibility |
| 19:49 |
sfan5 |
so that's a yes for "break compat this time for sake of the (almost) refactor", right? |
| 19:49 |
HuguesRoss |
It's a yes on my end |
| 19:50 |
erle |
can someone remind me why “make irrlichtmt a git submodule so you always get the right revision” was discarded when proposed? |
| 19:50 |
Krock |
yes from my side. It would be even better if there was a good way to detect incompatible versions using macros or whatsoever |
| 19:50 |
erle |
after all this lockstep stuff is not that new and the next change will come sooner or later |
| 19:50 |
erle |
next incompat change i mean |
| 19:50 |
sfan5 |
it's possible to detect it, just a #if IRRLICHT_VERSION_MT_REVISION < 5 #error (blame the user) #endif |
| 19:51 |
sfan5 |
s/5/6/ whatever |
| 19:51 |
sfan5 |
rubenwardy: opinion? |
| 19:51 |
Krock |
so a generic check in a main header would be great to have if that does not already exist |
| 19:51 |
rubenwardy |
I'm tied, it'll make things like bisecting annoying |
| 19:51 |
rubenwardy |
using a submodule would allow you to pin the irr version better |
| 19:51 |
rubenwardy |
but eh |
| 19:52 |
rubenwardy |
probably worth getting to a state where irrlicht can be merged sooner than later |
| 19:52 |
Krock |
framework changes are a bad situation in general |
| 19:52 |
sfan5 |
yes |
| 19:53 |
sfan5 |
i'll note down that we're in favor then |
| 19:53 |
Krock |
rubenwardy: merged with what? to directly integrate it into the Minetest repo, or as submodule? |
| 19:53 |
rubenwardy |
directly into the Minetest repo |
| 19:53 |
rubenwardy |
wasn't that the long term goal? |
| 19:53 |
sfan5 |
I think so |
| 19:54 |
HuguesRoss |
Is there any reason we couldn't do the latter sooner and the former later? |
| 19:55 |
sfan5 |
I don't think so |
| 19:55 |
sfan5 |
I just don't really want to deal with submodules |
| 19:55 |
erle |
a submodule is the easy integration. a subtree would pull the entire irrlicht thing into the main repo via a subtree merge. from my POV you prooooobably don't want a subtree for reasons. |
| 19:56 |
Krock |
the irrlichtmt build system is quite different to Minetest's so properly integrating that might take some work |
| 19:56 |
rubenwardy |
another option is CMake fetch content |
| 19:56 |
erle |
rubenwardy what's that |
| 19:56 |
sfan5 |
you let cmake download the repo and build it |
| 19:56 |
rubenwardy |
yeah. With caching |
| 19:56 |
erle |
distro packagers will hate you for it |
| 19:56 |
rubenwardy |
cmake would manage the git clone in lib/ |
| 19:56 |
erle |
nothing is allowed to download stuff during a build process |
| 19:57 |
rubenwardy |
it can be made so you could also just provide it with the library pre-cloned |
| 19:57 |
erle |
or is there a local fallback possible? |
| 19:57 |
erle |
ah ok |
| 19:58 |
rubenwardy |
This might be just as annoying for dev though, if it updates the irrlicht repo based on version - and isn't backwards compat |
| 19:58 |
rubenwardy |
actually, with the current situation you could probably make a bash script which gets the correct irrlicht version |
| 19:58 |
rubenwardy |
for dev use whilst bisecting |
| 19:58 |
erle |
uh, in what way would that bash script be better than using git submoduleo? |
| 19:58 |
Krock |
that sounds like a workaround rather than a proper solution |
| 19:58 |
rubenwardy |
it's not, but people don't like submodules |
| 19:59 |
rubenwardy |
submodule or merging is the proper solution for keeping stuff in sync |
| 20:01 |
rubenwardy |
if Irrlicht was merged into the repo now, it would be 40% of the code. Which is actually less than I expected |
| 20:03 |
rubenwardy |
anyway. I think the conclusion is that breaking it is fine, with some concerns over ease-of-use during dev |
| 20:03 |
erle |
but those concerns existed before anyway |
| 20:03 |
rubenwardy |
yeah |
| 20:03 |
Krock |
except that old Irrlicht never changed |
| 20:04 |
erle |
you mean they only exist since irrlichtmt and the in-lockstep thing, because irrlicht is a *bit* more careful about breaking compat? |
| 20:05 |
Krock |
https://github.com/zaki/irrlicht there was no activity since 2019, so which compat issues could you possibly mean? |
| 20:06 |
sfan5 |
irrlicht 1.8 has not changed since ~2013, minus a few bug fix releases |
| 20:06 |
sfan5 |
no substantial change = no breaks |
| 20:06 |
erle |
oh and i thought it was just some rando on github does not updating their mirror |
| 20:07 |
sfan5 |
the mirror is indeed outdated but your point still makes no sense |
| 20:08 |
rubenwardy |
https://github.com/minetest/irrlicht/tree/svn-trunk updated upstream mirror |
| 20:08 |
erle |
because minetest never used irrlicht trunk but the years old releases? |
| 20:08 |
rubenwardy |
will, recently updated |
| 20:08 |
sfan5 |
next on the list: "One Approval" PRs and decide on whether to merge, request changes or close. |
| 20:08 |
sfan5 |
https://github.com/minetest/minetest/pulls?q=is%3Aopen+is%3Apr+label%3A%22One+approval%22 link here |
| 20:08 |
rubenwardy |
Did I add this point? Is core review really a meeting thing, other than prompting people to do it? |
| 20:09 |
sfan5 |
oh it's just a reminder |
| 20:09 |
sfan5 |
is there any PR on that list we want to discuss then? |
| 20:10 |
erle |
oh, i can say something about the PNG gamma thing here! if gamma correction will never be supported, then minetest should either not load such images or at the very least log a warning so modders are aware of it. |
| 20:10 |
erle |
i was under the impression that eventually (e.g. when the rendering is revamped) correct rendering of such textures could be a goal |
| 20:10 |
rubenwardy |
is there an issue for gamma correction? |
| 20:11 |
rubenwardy |
https://github.com/minetest/minetest/pull/12089#issuecomment-1107927711 |
| 20:11 |
rubenwardy |
HuguesRoss ^ |
| 20:11 |
HuguesRoss |
Yeah probably that |
| 20:11 |
erle |
not sure, i just contributed these test nodes because i realized they render wrong. hilariously, gimp gets them even more wrong. |
| 20:12 |
rubenwardy |
I'm all for TDD, but adding broken test nodes to devtest for a feature we don't plan to support soon(?) doesn't seem right |
| 20:12 |
rubenwardy |
should probably be a .zip in an issue asking for gamma correction |
| 20:12 |
erle |
the other alternative is just winging it and accepting that the blending will be wrong and applying the correction on decoding. arguably that's cursed and wrong but it might make the gradient there render correctly? no idea. |
| 20:14 |
erle |
anyways if gamma correction is not happening and devs like the “warn on unsupported PNG features” approach, i can start identifying other textures that also render wrong or not at all that need a warning. |
| 20:14 |
erle |
(prob just a blacklist of chunks) |
| 20:15 |
sfan5 |
I vote for doing nothing |
| 20:16 |
Krock |
I don't see the need for any action right now |
| 20:16 |
rubenwardy |
wouldn't the action be closing the PR? |
| 20:16 |
erle |
yeah, but like, with a comment. |
| 20:16 |
Krock |
except that, yes ^ |
| 20:16 |
HuguesRoss |
That seems like the next step |
| 20:16 |
sfan5 |
well yes: closing and then doing nothing |
| 20:17 |
erle |
i think it's a bit weird to have something unsuported and not warn about it, but well, it's not like anyone has complained before me, right? :P |
| 20:17 |
Krock |
if textures are not supported, it's an issue for irrlichtmt |
| 20:17 |
erle |
sfan5 at least closing with a “gamma is not happening” so future generations know why it was scrapped would be nice |
| 20:17 |
erle |
Krock oh i see |
| 20:18 |
HuguesRoss |
I think it's a case of: is this edge case actually in use in the wild? If a number of applications outside of MT also don't handle them properly, most likely it's a corner of the spec that no-one actually cares about outside of a couple niche cases |
| 20:18 |
HuguesRoss |
I value having easy confirmation of what works and doesn't, but I concur that actually checking or fixing beyond that is not really a good use of dev-time |
| 20:19 |
Krock |
I might have a look at the "One approval" PRs upcoming week. Will see. Until next time. |
| 20:19 |
rubenwardy |
I've added myself to 2 |
| 20:20 |
erle |
HuguesRoss yeah, “here is a demo that this thing does not work” was one of my motivations too. i am the type that does TDD but like, leaves failing test cases in for “you might have wondered if this works, it does not”. |
| 20:24 |
rubenwardy |
ok next |
| 20:25 |
sfan5 |
whats next tho |
| 20:25 |
rubenwardy |
roadmap stuff |
| 20:25 |
rubenwardy |
well, it's more concept approval for older PRs |
| 20:25 |
rubenwardy |
it's probably worth being a bit more lenient than usual |
| 20:25 |
rubenwardy |
https://github.com/minetest/minetest/pulls?q=is%3Aopen+is%3Apr+label%3A%22Roadmap%3A+Needs+approval%22 |
| 20:26 |
rubenwardy |
eg: #11424 looks useful, but are we keeping support for both GL ES 1 and 2? |
| 20:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/11424 -- Allow Selecting Which GLES Version To Link With by TheBrokenRail |
| 20:27 |
sfan5 |
in the long run probably not |
| 20:28 |
sfan5 |
I think the PR is superseded now because Irrlicht is |
| 20:28 |
sfan5 |
... |
| 20:28 |
sfan5 |
actually I think the PR is superseded now because Irrlicht is now responsible for linking to OpenGL libraries |
| 20:28 |
sfan5 |
and it already links to the right ones as selected in IrrCompileConfig.h |
| 20:28 |
sfan5 |
so this is not even an issue anymore? |
| 20:29 |
erle |
how to confirm that? |
| 20:29 |
sfan5 |
confirm what |
| 20:29 |
erle |
that the submitter can get the right GLES version (1) that way |
| 20:30 |
erle |
like, which build command would do it |
| 20:31 |
sfan5 |
would do what |
| 20:31 |
erle |
link with GLES1 |
| 20:32 |
sfan5 |
irrlichtmt does that if you select it in IrrCompileConfig.h as I just said |
| 20:32 |
Zughy[m] |
as a triager, please let me bring your attention to these "possible close" issues, that have been labelled as such for a long time: https://forum.minetest.net/viewtopic.php?f=7&t=28060 Oldest is from sfan5, 2014. 3 of them have already been closed in these days |
| 20:32 |
erle |
ah okay, that's the only option, i see |
| 20:33 |
erle |
about #11829 obviously the client should check the input before processing it and error instead of randomly hanging |
| 20:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/11829 -- Client hangs on startup if too many texture modifiers are used in a game or mod |
| 20:34 |
sfan5 |
Zughy[m]: maybe later, IMO it can be put into the notes for he next meeting |
| 20:34 |
erle |
like, just don't try to parse this mess with the shotgun parser if there are too many levels |
| 20:34 |
sfan5 |
rubenwardy: which next? |
| 20:34 |
erle |
a simple regex or so could replace that hang with a nice uniformly colored “texture missing here” |
| 20:35 |
rubenwardy |
#11316 should be an easy concept one |
| 20:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/11316 -- make item count background work by Kezii |
| 20:35 |
sfan5 |
"should" |
| 20:35 |
rubenwardy |
ok borderline controversial |
| 20:36 |
sfan5 |
technically making it configurable (from the formspec src) is the right way |
| 20:36 |
rubenwardy |
not an accessability setting kind of thing? |
| 20:37 |
rubenwardy |
although, the contrast doesn't seem as bad as chat or nametags |
| 20:37 |
erle |
how stuff like #11742 can be “unconfirmed” and “possible close” if it is a) easily reproducible b) a server crash … that remains a riddle for me |
| 20:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/11742 -- Creating float vector with x outside of -2.14748e+06 < x < 2.14748e+06 crashes server |
| 20:37 |
HuguesRoss |
Accessibility setting seems better to me, since formspec solution wouldn't affect the hotbar and would require at least an SSM with a formspec prepend |
| 20:38 |
|
erle was kicked by sfan5: erle |
| 20:39 |
sfan5 |
well I'm fine with either |
| 20:40 |
|
erle joined #minetest-dev |
| 20:40 |
sfan5 |
HuguesRoss: actually, it could be both, like with entity nametags |
| 20:41 |
HuguesRoss |
true |
| 20:41 |
HuguesRoss |
But in the case of nametags I think that was for gameplay purposes |
| 20:42 |
sfan5 |
well doesn't look like a simple decision can fix the PR |
| 20:43 |
HuguesRoss |
Personally I don't like the rectangle at all, but I see the value for certain games or users with vision disabilities--it seems to me like the easiest way to get it in is as an accessibility setting, then expose more to modders if anyone actually requests it later |
| 20:43 |
HuguesRoss |
My *suspicion* is that people asking for the ability for games to configure it actually just want the option not to have it |
| 20:43 |
sfan5 |
probably |
| 20:44 |
sfan5 |
resolving the PR that way is fine by me |
| 20:46 |
sfan5 |
rubenwardy, Krock? |
| 20:46 |
rubenwardy |
<+HuguesRoss> Personally I don't like the rectangle at all, but I see the value for certain games or users with vision disabilities--it seems to me like the easiest way to get it in is as an accessibility setting, then expose more to modders if anyone actually requests it later |
| 20:46 |
rubenwardy |
+1 to this |
| 20:46 |
rubenwardy |
I'm not sure how useful it is as an accessibility thing though |
| 20:47 |
rubenwardy |
has this been requested, or just someone seeing a bug to fix |
| 20:47 |
rubenwardy |
I suppose constrast can be low in certain situations |
| 20:49 |
Zughy[m] |
As an artist, it's an ugly hack |
| 20:50 |
Zughy[m] |
increasing the font size should be nicer to see and also more readable |
| 20:50 |
Zughy[m] |
https://github.com/minetest/minetest/pull/11316#issuecomment-855253502 |
| 20:51 |
sfan5 |
but should these be choices the engine makes? |
| 20:51 |
rubenwardy |
that actually makes sense |
| 20:51 |
HuguesRoss |
Oh it's 100% an ugly hack. But I also think font size increase won't always give the same clarity as a straight-up bg color will, so we probably still want this |
| 20:52 |
erle |
i have a slight contrast vision problem and it is very hard to see such numbers for me, even if larger, with some items. while wool for example. |
| 20:53 |
Zughy[m] |
outline? |
| 20:53 |
erle |
yes, you can hack it a bit less intrusive by applying a dark outline with a light filling or the other way around. |
| 20:53 |
erle |
that way you always have a recognizable glyph |
| 20:54 |
HuguesRoss |
For now I've labelled with supported and changes needed. I don't see anyone saying we don't need a way to clarify the text, and this seems like a good starting point to me. If others disagree, feel free to remove them |
| 20:54 |
HuguesRoss |
*the labels, not the people |
| 20:55 |
erle |
Zughy[m], btw, the super-lazy way to get a text outline is to apply 4 text shadows in different diagonal directions |
| 20:55 |
Zughy[m] |
fast mock-up before/after: https://imgur.com/a/pDrUhc8 |
| 20:56 |
rubenwardy |
I'm getting bored, I suggest not doing all of these PRs now |
| 20:57 |
Zughy[m] |
I know the guy who made the PR, he's probably not interested in continuing the work |
| 20:57 |
Pexin |
hasnt it been 2 hours? |
| 20:58 |
HuguesRoss |
It has been, yes |
| 20:58 |
sfan5 |
in my experience meeting effectiveness drops sharply after about one hour |
| 20:58 |
Zughy[m] |
..oh c'mon here it goes again with "let's make X optional" |
| 20:59 |
sfan5 |
maybe we can quickly some quick opinions on #10705 |
| 20:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/10705 -- unset_bone_position by theviper121 |
| 20:59 |
sfan5 |
since someone just opened an issue requesting this |
| 20:59 |
rubenwardy |
makes sense to me |
| 20:59 |
sfan5 |
mine: I'm in favor, the PR just needs a bit of work |
| 20:59 |
rubenwardy |
not sure I'll review it, but the feature makes sense |
| 21:00 |
sfan5 |
s/quickly some quick/quickly get some/ |
| 21:00 |
rubenwardy |
sounds supported then |
| 21:00 |
HuguesRoss |
> ..oh c'mon here it goes again with "let's make X optional" |
| 21:00 |
HuguesRoss |
This is an actual valid use-case for that though, this is exactly what accessibility settings are for |
| 21:00 |
Pexin |
release_bone_position ? |
| 21:01 |
sfan5 |
okay that sounds like it for the meeting |
| 21:01 |
|
behalebabo joined #minetest-dev |
| 21:01 |
HuguesRoss |
yeah |
| 21:01 |
sfan5 |
unless anyone else has something quick |
| 21:02 |
rubenwardy |
nothing from me |
| 21:02 |
sfan5 |
by the way we should be ready to release 5.5.1 next weekend probably |
| 21:03 |
rubenwardy |
makes sense |
| 21:08 |
Zughy[m] |
well, this is quick #12152 |
| 21:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/12152 -- Add doc to list breaking changes for the next major release by Zughy |
| 21:08 |
rubenwardy |
Zughy: look at this |
| 21:08 |
rubenwardy |
the room: *crickets* *tumbleweed blows past* |
| 21:11 |
HuguesRoss |
I think it would be nice to have, since not everyone will browse the release notes |
| 21:12 |
HuguesRoss |
I am also too lazy to spend the necessary time to validate that everything is there... but the sooner we add something to this effect the sooner we can ask PRs to update it before merging |
| 21:32 |
Zughy[m] |
(put an approval :D) |
| 21:39 |
sfan5 |
rubenwardy: topic for next months blog post: MT repo will have passed 10k commits |
| 21:39 |
rubenwardy |
good idea |
| 21:39 |
rubenwardy |
we need cake |
| 21:42 |
Pexin |
cake made of voxels naturally |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 23:08 |
|
AliasStillTaken joined #minetest-dev |
