| Time |
Nick |
Message |
| 00:56 |
|
olliy joined #minetest-dev |
| 01:45 |
|
celeron55 joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:12 |
|
diceLibrarian joined #minetest-dev |
| 04:28 |
|
sponji joined #minetest-dev |
| 05:06 |
|
hifi joined #minetest-dev |
| 06:17 |
|
izzyb joined #minetest-dev |
| 06:19 |
|
calcul0n joined #minetest-dev |
| 06:27 |
|
tekakutli joined #minetest-dev |
| 07:54 |
|
tekakutl` joined #minetest-dev |
| 08:22 |
|
Warr1024 joined #minetest-dev |
| 08:46 |
|
Warr1024 joined #minetest-dev |
| 09:17 |
|
appguru joined #minetest-dev |
| 09:56 |
|
calcul0n joined #minetest-dev |
| 13:58 |
|
tekakutli joined #minetest-dev |
| 14:01 |
|
tekakutli joined #minetest-dev |
| 14:09 |
|
tekakutli joined #minetest-dev |
| 14:12 |
|
panwolfram joined #minetest-dev |
| 14:18 |
|
Desour joined #minetest-dev |
| 14:52 |
|
appguru joined #minetest-dev |
| 15:08 |
|
tekakutli joined #minetest-dev |
| 15:08 |
|
tekakutli joined #minetest-dev |
| 16:17 |
|
tekakutli joined #minetest-dev |
| 16:19 |
|
tekakutli joined #minetest-dev |
| 16:36 |
|
bigfoot547 joined #minetest-dev |
| 17:29 |
Krock |
Apparently a meeting is planned for today, in 30 minutes |
| 17:30 |
rubenwardy |
!dev Meetings |
| 17:30 |
ShadowBot |
Meetings - Minetest Developer Wiki -- http://dev.minetest.net/Meetings |
| 17:35 |
rubenwardy |
merging #13550 in 10 |
| 17:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/13550 -- Improve UX when no game exists and drop `default_game` by rollerozxa |
| 17:36 |
erle |
> it will automatically pick the first non-devtest game |
| 17:36 |
erle |
like, alphabetically or so |
| 17:39 |
rubenwardy |
I believe alphabetically, although it may be an undefined order based on the filesystem |
| 17:40 |
rubenwardy |
it's alphabetically, there's a sort |
| 17:40 |
|
srifqi joined #minetest-dev |
| 17:40 |
rubenwardy |
remember that the selected game is persisted though |
| 17:42 |
erle |
yeah i think that's the only thing important |
| 17:42 |
erle |
and if there is only one game, it gets selected, so ”single-game-launchers” may still be possible (right?) |
| 17:43 |
rubenwardy |
yeah |
| 17:43 |
erle |
i think it's a very loud step towards ”minetest is an engine” |
| 17:43 |
erle |
so, congrats ROllerozxa |
| 17:49 |
MTDiscord |
<rollerozxa> oh nice, it got merged. I'll go ahead and open the 2nd MTG debundling PR real quick |
| 18:02 |
ROllerozxa |
erle: I'd assume it goes in alphabetical order, but the most important thing is that there is no `default_game` setting that is set to `minetest` by default but that it can adapt |
| 18:03 |
ROllerozxa |
so if someone bundles the engine with their own game, that is what it will pick and it won't go into a gameless void |
| 18:04 |
Krock |
Meeting time |
| 18:04 |
Krock |
> Feature freeze? |
| 18:05 |
Krock |
https://github.com/minetest/minetest/milestone/22 80% complete |
| 18:05 |
srifqi |
what was our target date for the next release? |
| 18:05 |
Krock |
there used to be the goal of 6 months release cycles, but better earlier than later |
| 18:06 |
Krock |
5.7.0 was in April, so the next would be due in October |
| 18:07 |
|
Desour joined #minetest-dev |
| 18:07 |
srifqi |
8 April to be exact, so it would be 8 October (in 20 days) |
| 18:07 |
Krock |
was minetest_game yet defined to be dropped in 5.8.0? if so, #13800 would need a milestone |
| 18:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/13800 -- Migration path once MTG is no longer preinstalled |
| 18:09 |
Krock |
adding the milestone just in case |
| 18:09 |
srifqi |
due to recent commmit, it should be included in the milestone |
| 18:09 |
Krock |
fortunately there's not too much waiting explicitly for 5.8.0 |
| 18:11 |
Krock |
unfortunately I was not very active in the Minetest Engine repository as of lately to judge whether there's PRs that should make it into 5.8.0 |
| 18:11 |
Krock |
so if you have some that are necessary, please add a milestone or let me know so that I would then add it |
| 18:11 |
Krock |
(you = anyone participating in this meeting) |
| 18:13 |
Krock |
There were a few new features which I could add to a first draft of the changelog to then judge whether a release would make sense |
| 18:13 |
Krock |
so that we could discuss that latest in 14 days |
| 18:15 |
MTDiscord |
<grorp> MTG isn't debundled yet. If we decide to debundle it for 5.8.0, #13818 should be added to the milestone as well. |
| 18:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/13818 -- Debundle Minetest Game by rollerozxa |
| 18:17 |
Krock |
I see. I will add it to the milestone since it's been mentioned a few times so that it's not entirely forgotten. However, the follow-up issue on the migration path should not be a blocker for the next release |
| 18:17 |
Krock |
so a solution for this new issue should be provided too before the debundling change makes it into the repo |
| 18:18 |
Krock |
changed the milestone to Oct 15 so that one meeting can be held before feature freeze |
| 18:20 |
Krock |
> #13642 |
| 18:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/13642 -- Import Irrlicht by numberZero |
| 18:20 |
Krock |
I assume that's a general request for review, @wsor4035 ? |
| 18:21 |
Desour |
I've recently wrote a comment there |
| 18:21 |
srifqi |
... which I agree with |
| 18:21 |
|
Warr1024 joined #minetest-dev |
| 18:21 |
Desour |
imo we need reproduction instructions, so we can review |
| 18:21 |
MTDiscord |
<grorp> @wsor |
| 18:22 |
Krock |
I am just afraid that pulling bugfixes from the upstream Irrlicht repo will become even harder than it already is |
| 18:22 |
Desour |
irrlicht dissolves anyway. rebasing upstream commits seems unrealistic |
| 18:23 |
Krock |
in either case, I would like to have the git history preserved which also allows easy reverts and bisecting |
| 18:23 |
Krock |
.. which seems to be basically impossible by what this PR intends to do |
| 18:23 |
Desour |
oh, I thought we wanted to throw away the commit history |
| 18:25 |
MTDiscord |
<wsor4035> krock: basically a decide one way or another to import vs submodule/etc since no real dev input had been had on it |
| 18:26 |
MTDiscord |
<grorp> How would you preserve the commit history? By putting a huge amount of Irrlicht commits on top of the Minetest commit history? |
| 18:26 |
Krock |
I wonder whether that is okay because the zlib/libpng license requires you to include copyright which is to my understanding also the committer's name and email? |
| 18:26 |
Desour |
iirc, a submodule would only be temporary if we did that |
| 18:26 |
Krock |
or am I misinformed about that? |
| 18:27 |
Krock |
@wsor4035 I would be very much in favour of the git submodule approach, although I also have seen arguments against that. e.g. doubled effort for PR creating |
| 18:28 |
MTDiscord |
<wsor4035> personally same |
| 18:30 |
MTDiscord |
<wsor4035> the other reason i asked zughy to put it on is the current situation is a bit of a mess, and confuses a lot of (mostly non technical) people for building minetest/getting version right |
| 18:31 |
erle |
well that's the issue of having a library that is not really a library, but some other component hat must be updated in lockstep |
| 18:31 |
Desour |
Krock: irrlicht/LICENSE doesn't say anything about commits. and a quick web search didn't reveal anything either |
| 18:32 |
srifqi |
Krock: a file containing a list of committers' name + email alongside the license text and a notice about its "acquisition" should be fine |
| 18:32 |
Desour |
anyway, we'll keep the irrlicht repo anyway, I assume. so we could just add a note that the old parts of the commit history exist there |
| 18:32 |
srifqi |
set it to public archive perhaps |
| 18:35 |
nrz_ |
It's also possible to have license and contributor file keeping it |
| 18:35 |
Krock |
srifqi: right, that should solve any such issue (if my concern is valid at all) |
| 18:36 |
sfan5 |
fwiw keeping commit history was absolutely not my plan |
| 18:36 |
sfan5 |
the irrlicht repo also only contains the last thousand or so revisions, there's a cutoff |
| 18:36 |
sfan5 |
so for full history we'd have to reference irrlicht's svm |
| 18:36 |
sfan5 |
svn* |
| 18:37 |
Krock |
oh, I did not realize that. so we're already half-way there to trash the history anyway. okay then |
| 18:37 |
|
Desour_ joined #minetest-dev |
| 18:40 |
Krock |
so copypasting IrrlichtMt into Minetest is the consensus? If not, would a poll for import vs copypaste be desired? |
| 18:41 |
Krock |
s/vs copypaste/vs submodule/ |
| 18:42 |
srifqi |
i support the import process after Desour's comment has been addressed |
| 18:43 |
Desour_ |
copy-paste > submodule from my side. (idk if there's a realistic good third way) |
| 18:43 |
erle |
subtree? |
| 18:43 |
erle |
Desour_, https://www.atlassian.com/git/tutorials/git-subtree |
| 18:43 |
Krock |
the nicer submodule? |
| 18:43 |
MTDiscord |
<wsor4035> its worse |
| 18:44 |
Desour_ |
I know that exists, but idk if it's good |
| 18:44 |
sfan5 |
submodule is just the current situation but nicer |
| 18:44 |
sfan5 |
copy-paste is the end goal, there isn't really a way around it |
| 18:44 |
erle |
true |
| 18:44 |
Desour_ |
but iirc you still have to mess with new commands, and can't just mix up the files between both parts |
| 18:45 |
erle |
subtree is copy-paste but nicer, not? |
| 18:46 |
erle |
i mean it's mainly a merge strategy to nest repositories |
| 18:46 |
Krock |
the issues that are to be addressed are: avoiding out-of-sync situations for the lockstep (copypaste and git submodule can do that) and less PR efforts (copypaste can do that). subtree does not appear to appear to solve that |
| 18:46 |
Desour_ |
somehow rebasing all irrlicht commits on minetest in some way could also be theoretically a way. but it might be ugly, and we don't have old irrlicht commits anyway, as mentioned above by someone |
| 18:47 |
Krock |
AFAIK you cannot rebase without a common git commit. copypaste is the only way |
| 18:47 |
erle |
you can synthesize a history for old irrlicht commits from svn and graft the new history on it ig |
| 18:47 |
erle |
like using git-svn clone |
| 18:49 |
Desour_ |
anyway, it wouldn't be worth the effort, imo |
| 18:49 |
erle |
i actually thought to do that for a possible custom irrlichtmt in case the threats of “we well drop support for your platform” become true, but i guess it is pointless to even think about that given that it will not stay separate for long now |
| 18:51 |
Desour_ |
*awkward silence* |
| 18:51 |
pgimeno |
I am still maintaining a copy of the full Irrlicht in git form |
| 18:53 |
Krock |
answered to the PR to clarify the status of it |
| 18:53 |
erle |
pgimeno do you have some kind of shim that manages to bridge the irrlicht-irrlichtmt gap maybe? |
| 18:54 |
Krock |
thanks for the inputs so let's continue |
| 18:54 |
Krock |
> #13700 |
| 18:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/13700 -- Android Java: Add some final by oong819 |
| 18:54 |
MTDiscord |
<grorp> The copy-paste approach seems like the best approach to me. |
| 18:54 |
nrz_ |
Copy paste i's definitively better, but you Can also import code in a subfolder with history |
| 18:55 |
Krock |
nrz_: If that's possible it would address one of Desour's comment points. Please give details about that in #13642. |
| 18:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/13642 -- Import Irrlicht by numberZero |
| 18:55 |
srifqi |
about that Java PR, my suggestion is to add simple code style guidelines for Java language (or languages in Android ecosystem) |
| 18:56 |
sfan5 |
if we want to bring out java code forward we should migrate it to kotlin |
| 18:56 |
srifqi |
Android Studio has a built-in code formatter that we can use |
| 18:56 |
sfan5 |
all in all it doesn't really matter however |
| 18:56 |
rubenwardy |
I love Kotlin but also we have so little Java code it doesn't really matter |
| 18:56 |
Krock |
can the C++ style rules not be applied roughly to Java? |
| 18:57 |
rubenwardy |
no, our C++ style rules are shit |
| 18:57 |
rubenwardy |
just use Android Studio's styler |
| 18:57 |
pgimeno |
erle: no I don't |
| 18:57 |
Krock |
now I see the PR. indeed, it needs a specific set |
| 18:57 |
Desour_ |
(Krock: to be clear, in that one comment point I suggested that you don't need to import the whole history and instead look at the irrlicht repo as soon as you reach the commit that imported irrlicht) |
| 18:57 |
pgimeno |
erle: but it should be possible to rebase it with some trickery |
| 18:57 |
rubenwardy |
(the best code styles are done by the IDE so you never need to think about it) |
| 18:57 |
srifqi |
while Java and C++ are in the same "family", it can be different in terms of style rules |
| 18:57 |
rubenwardy |
s/the IDE/a tool/ |
| 18:58 |
Krock |
( Desour_: well at the same time you want a solid reproduction step which would be the case if the trees merged. Both ways would be possible, I suppose ) |
| 18:59 |
MTDiscord |
<grorp> srifqi: Can you run the Android Studio formatter from the command line? |
| 18:59 |
rubenwardy |
yes |
| 18:59 |
Krock |
rubenwardy: so a simple "use Android Studio's styler" would already suffice as Java rules? |
| 18:59 |
|
grorp joined #minetest-dev |
| 18:59 |
Krock |
oh that's a cool thing. would be nice if the command line is documented in the wiki as well |
| 19:00 |
rubenwardy |
well, whatever code formatter we use should run as a gradle target as well |
| 19:00 |
MTDiscord |
<luatic> I don't think this is anything any styler currently does (deciding whether or whether not to use final) |
| 19:00 |
MTDiscord |
<luatic> because final communicates intent not to change a variable / override a function / extend a class, it's not "just style" |
| 19:01 |
grorp |
Hello, I'm a real IRC user now :) |
| 19:01 |
srifqi |
hello |
| 19:01 |
MTDiscord |
<luatic> you could slap final onto everything that is de facto not changed, but that would make it harder to change variables / override functions / extend classes |
| 19:01 |
MTDiscord |
<luatic> so I'm not too fond of the approach that PR took, though many of the variables there seem to have the intent of being final |
| 19:01 |
Desour_ |
the C++ code could also use some final btw. |
| 19:01 |
srifqi |
yes, that PR just inspired me about making a code style for Android code |
| 19:02 |
srifqi |
i don't support that PR |
| 19:03 |
Krock |
I don't see the point of using final when we're in full control of the source code anyway and that apps are generally isolated on Android devices, so I don't think that it's necessary at all |
| 19:03 |
srifqi |
grorp: Android Studio (or Intellij IDEA) has bin/format for that purpose |
| 19:04 |
Krock |
is anyone interested in providing a first draft of coding rules? |
| 19:04 |
MTDiscord |
<luatic> I agree that the motivation behind the PR was poor. The main reason to use final is, as said, to communicate intent such that a dev who later on swoops in knows that something is not supposed to be modified. |
| 19:06 |
Krock |
no replies, so I'll just note that volunteers are welcome to propose simple rules for the Java part |
| 19:07 |
srifqi |
currently, we only inherit Android classes (no inheritance from our own class). we might add that when we do inherit our own class) |
| 19:08 |
rubenwardy |
`final` isn't about security, you can override it using reflection. So being in full control or not doesn't make a different |
| 19:08 |
srifqi |
Krock: my draft would be "The coding style used for Java and other languages in Android app ecosystem is the same as coding style used by Android Studio." followed by steps to format code in IDE and using command line |
| 19:09 |
Krock |
so I'll note this down in https://dev.minetest.net/Java_code_style_guidelines as a starting point |
| 19:10 |
Krock |
or rather "Android_code_style_guidelines" in case Kotlin is used, perhaps? |
| 19:11 |
srifqi |
since we only use Java for Android purposes, Android code style guidelines is better |
| 19:12 |
srifqi |
that might include Java and Groove language |
| 19:12 |
srifqi |
... and XML, too |
| 19:14 |
srifqi |
s/Groove/Groovy |
| 19:15 |
srifqi |
oh, thank you for creating the page |
| 19:15 |
Krock |
-> https://dev.minetest.net/Android_code_style_guidelines |
| 19:15 |
Krock |
next up: #13583 |
| 19:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/13583 -- [discussion] Define a policy for raising our dependencies' versions |
| 19:16 |
Desour_ |
I've written a draft locally, but it's unfinished |
| 19:17 |
Krock |
okay, so I think it would be good to wait for that and then discuss the proposed points. The issue does provide reasonable suggestions |
| 19:17 |
erle |
Desour_ is that also relevant to *security* upgrades for old platform? |
| 19:17 |
srifqi |
Desour_: i thank you for that. i was wondering whether somebody is writing a draft |
| 19:17 |
Desour_ |
https://github.com/Desour/minetest/tree/dep_upgr_policy |
| 19:18 |
Desour_ |
erle: if you're referring to patch releases, it's not related to that at all |
| 19:18 |
Desour_ |
srifqi: sry for being silent about it. I wanted to finish it but haven't found motivation |
| 19:20 |
erle |
Desour_ i mean library version upgrades when a dependency has a security issue. no idea if ubuntu “support” actually means backporting all security fixes or not. |
| 19:20 |
srifqi |
no, it's okay. i can understand that |
| 19:20 |
Krock |
Desour_: in general I think that policies should be written neutral without any "you/we/whatever" mention. Furthermore, list your proposed Ubuntu LTS strategy. be clear where exactly we draw the line |
| 19:20 |
Krock |
we'll check the PR when you are ready |
| 19:21 |
erle |
Desour_ the ”prefer minimum” thing is good, unless there are security issues that are not addressed i think |
| 19:22 |
Desour_ |
ah, that's what you mean. if a distro ships an old version without security patches, we are not to blame just because that version happens to work |
| 19:24 |
Krock |
Desour_: would you like to have additional input or can you work with that? take your time. |
| 19:24 |
Desour_ |
I have enough input, thx :) |
| 19:25 |
Krock |
great! so let's continue with #11016. |
| 19:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/11016 -- Dual Wielding by LizzyFleckenstein03 |
| 19:25 |
Krock |
> I'd suggest to prioritise MTG removal and postpone this feature to 5.9, |
| 19:26 |
sfan5 |
PR probably needs a second look, I didn't have time/energy yet |
| 19:26 |
Krock |
well in the current state it is basically WIP, so it might be better to not only remove the milestone but also mark the PR as draft |
| 19:26 |
Krock |
the old issues aren't addressed to my knowledge |
| 19:27 |
erle |
were the old issues that this introduces an easy dupe or was that a different approach? |
| 19:27 |
Krock |
implementing this will made the API somewhat messy to preserve mod compatibility, which is rather unfortunate |
| 19:28 |
Krock |
erle: no, it's about mods not expecting the offhand while calling get_wielded_item() |
| 19:28 |
erle |
ah |
| 19:29 |
erle |
what i don't get – which part of dual wielding *needs* engine support? like why can't it be faked in a mod easily. |
| 19:29 |
Krock |
the visual aspect for one (left side wieldhand) |
| 19:29 |
erle |
and gameplay-wise? |
| 19:30 |
MTDiscord |
<luatic> there is no keybind for switching hands or stuff like that |
| 19:30 |
MTDiscord |
<luatic> and basically the only configurable keybind we have is aux1 |
| 19:30 |
Krock |
to place the so-called offhand node, but that could be implemented in mods, though. |
| 19:30 |
erle |
yeah, that's rather easy ig |
| 19:30 |
erle |
(don't quote me on this, i never done it, i may be totally wrong) |
| 19:31 |
Krock |
I might already have said that I would support a skimmed-down version of that PR which only introduces a new wieldhand visual which depends on the optional player slot |
| 19:32 |
Krock |
modders could then demand an aux2 hotkey or whatsoever to make better use of this visual feature |
| 19:32 |
erle |
indeed |
| 19:32 |
erle |
did you say that to lizzy in particular? |
| 19:32 |
Krock |
correction: that would need to specify the hand animation for placing |
| 19:32 |
erle |
Krock are you aware of any mod that tries faking it btw? i'd be interested how far ppl got |
| 19:33 |
erle |
also i think the proposal is sensible, new slot, new visual |
| 19:34 |
MTDiscord |
<luatic> I am aware of such a mod which uses the first person attachments, I think. IIRC it was by T. Affeldt (TestificateMods) |
| 19:34 |
MTDiscord |
<luatic> https://content.minetest.net/packages/TestificateMods/offhand/ |
| 19:34 |
Krock |
erle: I don't think any mod has implemented that yet reasonably because the HUD API does yet not support placing (wield)meshes onto the screen |
| 19:34 |
erle |
ah, so we only get stuff like shields then |
| 19:35 |
srifqi |
i agree about converting it to draft since the author clearly stated that there are some todos to be worked |
| 19:35 |
srifqi |
... and it's been 6 months, too |
| 19:35 |
Krock |
alright |
| 19:35 |
erle |
srifqi maybe ping the author too? i'll tell her when i see her on irc anyway |
| 19:36 |
erle |
Krock, also i think if you attach a fake node mesh to a player that you generate on the fly there is no way to make it so that *you* see it but other players do not, right? unless … fuckery with dynamic media? :D |
| 19:36 |
srifqi |
does converting to draft not ping the author? |
| 19:36 |
erle |
no idea, lots of stuff does not ping anyone (at least via email) |
| 19:36 |
Krock |
it should notify them |
| 19:37 |
srifqi |
the label already tells that actions are needed, too |
| 19:38 |
Krock |
alright |
| 19:38 |
Krock |
> #13764 |
| 19:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/13764 -- Refactored the liquid system, and added an optional feature for liquids to flow to the next slope. by cosin15 |
| 19:38 |
Krock |
concept approval question |
| 19:39 |
Krock |
it does look very unique |
| 19:40 |
srifqi |
i'm going to bed for now (02:40 am here) |
| 19:40 |
Krock |
gn srifqi |
| 19:40 |
Desour_ |
exactly mirroring the min-ec-raft's liquid physics would be hard probably. I've seen that video, it's super buggy |
| 19:40 |
Krock |
the filling up of flowing liquids when hitting a dead end does have a better appearance than what's currently implemented |
| 19:41 |
Krock |
regardless I believe the current code is somewhat optimized for speed throughout the years |
| 19:41 |
Krock |
s/throughout/over/ |
| 19:41 |
grorp |
I'm going to bed, too. Bye. |
| 19:41 |
|
grorp left #minetest-dev |
| 19:42 |
Krock |
good night. |
| 19:42 |
Desour_ |
gn u2 |
| 19:42 |
erle |
having poked a bit around the liquid system myself i want to say two things: first if that thing is really bug-for-bug-compatible, it's great and will not destroy any user worlds. second, the new mode looks nice. it needs to be opt-in though. third: writing unit tests for that kind of thing would be amazing! |
| 19:42 |
rubenwardy |
apparently MTDiscord too |
| 19:42 |
Krock |
MTDiscord went to sleep as well |
| 19:42 |
erle |
three things |
| 19:42 |
erle |
[spanish inquisition meme intensifies] |
| 19:42 |
sfan5 |
we could change the meeting time next time, since we no longer have anyone from the american continent attending (this was the reason IIRC) |
| 19:43 |
|
MTDiscord joined #minetest-dev |
| 19:43 |
MTDiscord |
<luatic> I think it would be fair to ask the author to ensure that this introduces no performance regression. |
| 19:43 |
Krock |
sfan5: sure. a few hours earlier would also be welcome from my side |
| 19:44 |
Krock |
srifqi might like to have it at least 4 hours earlier to attend |
| 19:45 |
Krock |
I'll ask them in the discussion of today's meeting |
| 19:47 |
|
MTDiscord joined #minetest-dev |
| 19:53 |
Krock |
no additional opinions on the PR? if you have some, please leave them there so that they're not working on a feature that might turn out to be undesired |
| 19:54 |
Krock |
> #13789 last one for today |
| 19:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/13789 -- Fix liquid falling if in "float" group, fixes #13782 by kromka-chleba |
| 19:54 |
rubenwardy |
<+Krock> > #13764 |
| 19:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/13764 -- Refactored the liquid system, and added an optional feature for liquids to flow to the next slope. by cosin15 |
| 19:54 |
rubenwardy |
the outcome here is either to replace "Roadmap: Needs approval" with "Supported by core dev", or close the PR |
| 19:54 |
rubenwardy |
same for the other one |
| 19:55 |
Krock |
oh right. totally forgot about the original purpose of the talking point |
| 19:56 |
Krock |
it does look interesting to me |
| 19:56 |
sfan5 |
my opinion: idk |
| 19:56 |
sfan5 |
if we're tending towards no maybe the author can PR the refactor first and try again then |
| 19:57 |
Krock |
is that roughly how water is propagated in Minecraft? |
| 19:59 |
Desour_ |
I haven't ever looked much into mt's liquid system. and I wouldn't want to open a can of worms that is a liquid system with new rules that can break in so many different ways, especially if those rules are not exactly specified. so no support from my side |
| 19:59 |
Krock |
master and this PR look a bit messy. not much gained code quality wise |
| 20:00 |
MTDiscord |
<luatic> I would agree with sfan5 here, the refactor should be cleanly separated from the new feature. IMO such a refactor also needs to have rigid testing to ensure that this introduces no regressions, including performance regressions. |
| 20:01 |
Krock |
so let's say refactor first, feature later? |
| 20:01 |
celeron55 |
i think it's fair to require any refactor+feature to be split into first a refactor, then a feature (understanding the caveat that often it can be too much to ask and it will be dropped) |
| 20:01 |
MTDiscord |
<luatic> (I don't have anything to say) but I would agree with refactor first, feature later. |
| 20:02 |
erle |
wasn't there something from the author along the lines of “if you promise you accept it, i'll make a test suite for the existing water” ? |
| 20:07 |
Krock |
updated the comment. shall I keep the PR open so that they can adapt or just close? |
| 20:07 |
Krock |
^ rubenwardy |
| 20:12 |
|
tekakutli joined #minetest-dev |
| 20:15 |
Krock |
by the way - any opinions on #13789 ? If there are no objections I'll remove the concept approval needed label |
| 20:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/13789 -- Fix liquid falling if in "float" group, fixes #13782 by kromka-chleba |
| 20:20 |
Krock |
alright. thank you for lasting this long. I added the meeting notes to the wiki. Meeting done. |
| 20:39 |
|
tekakutli joined #minetest-dev |
| 20:42 |
|
tekakutli joined #minetest-dev |
| 20:43 |
|
tekakutli joined #minetest-dev |
| 20:46 |
|
tekakutli joined #minetest-dev |
| 22:36 |
|
dv^_^ joined #minetest-dev |
