| Time |
Nick |
Message |
| 00:49 |
|
fluxionary joined #minetest-dev |
| 01:44 |
MTDiscord |
Command sent from Discord by herowl: |
| 01:44 |
MTDiscord |
!tell sfan5 The point is to get final review(s) from coredevs during the meeting and potentially get something merged, not to "technically not violate the rules". Just getting a review&merge during the meeting is slightly more probable than in the last hours before the meeting. |
| 01:44 |
ShadowBot |
MTDiscord: OK. |
| 02:05 |
|
\o` joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:08 |
\o` |
I'm not sure why framerate is so low for the client. IIRC I got it to never go below 60fps about 6 years ago. But, now, I've tried several servers and 20 fps is about average. Maybe it's Wayland I'm not sure |
| 04:08 |
\o` |
and that's with draw distance reduced |
| 04:18 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:53 |
|
hwpplayer1 joined #minetest-dev |
| 06:32 |
|
\o` joined #minetest-dev |
| 06:42 |
|
hwpplayer1 joined #minetest-dev |
| 08:03 |
sfan5 |
. |
| 08:13 |
sfan5 |
merging #15279 in 10m |
| 08:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/15279 -- [no squash] JSON fix and update our copy by sfan5 |
| 08:22 |
|
Warr1024 joined #minetest-dev |
| 08:47 |
|
Warr1024 joined #minetest-dev |
| 08:57 |
[MatrxMT] |
<Zughy> sfan5: how about #14726 at this point? It has two approvals |
| 08:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/14726 -- (Adoption) Gettext and plural support for client-side translations by y5nw |
| 08:57 |
sfan5 |
if coredevs consider it fine then they may merge it |
| 08:57 |
sfan5 |
(I have not looked at it) |
| 08:59 |
nore |
I'm good with it, yes |
| 09:17 |
nore |
rubenwardy: will merge in 2-3 hours except if you object, or if you want to do it first |
| 09:17 |
rubenwardy |
Feel free to go ahead |
| 09:20 |
nore |
Ok, doing that then |
| 09:21 |
nore |
I don't remember the specific situations for rebase vs squash though |
| 09:24 |
nore |
(after checking the git guidelines I don't see anything about it, but the commit history wouldn't pass the other conditions for commits so I'll squash) |
| 09:29 |
nore |
Merged! |
| 09:33 |
[MatrxMT] |
<Zughy> NICE! |
| 10:53 |
MTDiscord |
<luatic> \o`: obligatory "try setting transparency_sorting_distance = 0" |
| 10:58 |
\o` |
luatic, ok thanks. After 6 years I'm trying to find my feet again. I'll try that |
| 10:58 |
\o` |
I dunno if 6 years is right... I think my last commit was in 2018, not sure |
| 10:59 |
rubenwardy |
https://zirk.us/@dosch/113299457486670058 |
| 11:02 |
MTDiscord |
<herowl> rubenwardy: the link is broken for me |
| 11:03 |
rubenwardy |
It's a user complaining about bad performance on rpi400, since 5.9. Disabling sorting distance doesn't fix it |
| 11:05 |
\o` |
I dunno. 6 years ago I was getting a lot more than 20 fps after my optimisations |
| 11:11 |
sfan5 |
rubenwardy: isn't that literally https://github.com/minetest/minetest/issues/14993 |
| 11:11 |
rubenwardy |
Disabling doesn't fix it |
| 11:13 |
sfan5 |
https://github.com/minetest/minetest/pull/15115 maybe then |
| 11:13 |
sfan5 |
either way this is not actionable without more info |
| 11:15 |
rubenwardy |
I can ask them to open an issue or forward any questions you have |
| 11:16 |
sfan5 |
I don't want to spend any time on this now but the reproduction steps are basically the same as #14993 |
| 11:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/14993 -- Large FPS drop at certain locations on RPi 400, caused by transparency sorting |
| 11:17 |
sfan5 |
hw info, screenshot, profiler output, detailed info what worked better when/where/... |
| 12:15 |
|
hwpplayer1 joined #minetest-dev |
| 13:41 |
MTDiscord |
<luatic> pushing https://gist.github.com/appgurueu/662c1cd0b97e2c43f6ae3cd5c4a8be68 in 10m (fixes a regression i introduced which broke local anims) |
| 13:44 |
Krock |
LGTM |
| 13:44 |
Krock |
( https://github.com/minetest/minetest/commit/06907aa99b56ecd ) |
| 13:44 |
[MatrxMT] |
<grorp> should add the PR number or commit hash that introduced the regression to the commit message |
| 13:48 |
MTDiscord |
<luatic> sure, will do |
| 13:51 |
MTDiscord |
<luatic> done |
| 14:07 |
|
Wuzzy joined #minetest-dev |
| 14:25 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> @Lars you mentioned reviewing the scrollbar pr today? |
| 14:26 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> im at my pc for a couple hours, so any changes i can fix asap |
| 14:36 |
|
Desour joined #minetest-dev |
| 14:51 |
|
grorp joined #minetest-dev |
| 15:40 |
|
chmodsayshello joined #minetest-dev |
| 15:46 |
chmodsayshello |
It seems like that through the "screenshot-preview" feature in the minetest client a content-db server can place files (with the user only opening the formspec, and not installing anything) on the user's hard drive outside of the "cdb" directory through path traversal, yet still is limitied to minetest's cache. Is this considered a bug or would it |
| 15:46 |
chmodsayshello |
be a "won't fix" issue? |
| 15:51 |
|
cx384 joined #minetest-dev |
| 15:55 |
|
Desour joined #minetest-dev |
| 15:58 |
grorp |
imo we shouldn't try to get #14343 into 5.10.0. it's too late for the risky changes the PR makes to node lighting. |
| 15:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/14343 -- Ambient light and server control for it by Andrey2470T |
| 16:00 |
grorp |
the PR has only really been ready-for-review for a 7 days now (https://github.com/minetest/minetest/pull/14343#issuecomment-2395253950) and it's a complex PR, so it doesn't even make sense to expect it to be merged for 5.10.0 |
| 16:00 |
grorp |
s/for a/for/ |
| 16:00 |
MTDiscord |
<andrey2470t> It could be reverted if it continues to break the lighting |
| 16:01 |
MTDiscord |
<jordan4ibanez> I thought that's what was agreed on |
| 16:01 |
MTDiscord |
<andrey2470t> Yes, Lars suggested that and I and Herowl agreed on that |
| 16:02 |
MTDiscord |
<wsor4035> tbh just looking over the last few comments on the pr, it looks like your trying to show in a half finished project right before feature freeze |
| 16:03 |
MTDiscord |
<wsor4035> . s/show/shove |
| 16:04 |
MTDiscord |
<andrey2470t> @herowl I've merged your branch |
| 16:04 |
grorp |
jordan4ibanez: your "they want your PR to rot" complaint in https://irc.minetest.net/minetest-dev/2024-10-11#i_6207755 is unjustified imo. the PR has only been ready-for-review again for 7 days now and it has proven to be complex. |
| 16:05 |
MTDiscord |
<herowl> wsor: The project is quite finished, but unit tests are failing, and it's fault of the unit tests. I wrote correct code that worked properly, but didn't check unit tests on it. Andrey took my code and made changes to satisfy unit tests, and the changes broke rendering. |
| 16:06 |
MTDiscord |
<herowl> grorp: I don't see differences on the screenshots in your latest comment. Maybe I'm blind. |
| 16:06 |
MTDiscord |
<herowl> Anyway, if it is decided that the precision is not enough and we need the new vertex format etc., I'm fine with it. |
| 16:06 |
MTDiscord |
<jordan4ibanez> I literally read the entire thing in 5 minutes with a basic understanding of it |
| 16:07 |
MTDiscord |
<herowl> But those unit tests shouldn't be used as a justification to reject it. |
| 16:07 |
[MatrxMT] |
<Zughy> +1 with what wsor said |
| 16:07 |
MTDiscord |
<wsor4035> herowl: more so a combo of unresolved review comments, grorps screenshots, unit tests, etc |
| 16:07 |
MTDiscord |
<jordan4ibanez> I understand I has probably changed, but your deplatforming of my previous statement with the older version as the context is quite unfair |
| 16:07 |
MTDiscord |
<jordan4ibanez> It |
| 16:08 |
MTDiscord |
<herowl> Review comments are resolved. I don't see the differences in the grorp's screenshots, maybe something's wrong with me, but the way I see it, it's correct. Unit tests are broken themselves. |
| 16:09 |
MTDiscord |
<herowl> Tbh I have one more idea |
| 16:09 |
MTDiscord |
<wsor4035> anyways, my two bent pennies dont really matter, its more so up to the core devs. |
| 16:10 |
MTDiscord |
<herowl> To use the new packing only when ambient light is not black (i.e. unset). |
| 16:10 |
MTDiscord |
<herowl> In that case, it doesn't cause any sort of regressions when the new API is not used, and it may look off only when the new API is actually used. |
| 16:10 |
grorp |
jordan4ibanez: I responded to your statement because that one seemed unfair to me. I'm not sure what you mean. |
| 16:11 |
MTDiscord |
<jordan4ibanez> Because I've seen simpler prs than this sit for years. Do you think that's fair to the contributors? Why do you think we lose so many |
| 16:11 |
MTDiscord |
<andrey2470t> @grorp why did you add "Action/change needed" tag? Are the last commits not really changes? |
| 16:12 |
MTDiscord |
<herowl> jordan: +1 |
| 16:12 |
MTDiscord |
<herowl> It's caused by understaffing mostly, but yeah, there are other cases too. |
| 16:14 |
sfan5 |
chmodsayshello: that would be a bug |
| 16:15 |
sfan5 |
<+MTDiscord> <herowl> grorp: I don't see differences on the screenshots in your latest comment. Maybe I'm blind. |
| 16:15 |
sfan5 |
please them in side-by-side tabs and switch between them |
| 16:16 |
sfan5 |
alternative someone could post them to https://slow.pics/ |
| 16:16 |
MTDiscord |
<andrey2470t> I don't see the difference on the screenshots also at all |
| 16:18 |
MTDiscord |
<luatic> look at the shaded sand node sides |
| 16:19 |
grorp |
For the first two screenshots: Consider the right half of the picture. The top of the sand far away is brighter than on master. On master, the sand becomes brighter smoothly when getting closer to the light. With the PR, the sand becomes brighter in slight stripes. |
| 16:19 |
grorp |
but describing this is hard, better if you see it yourself |
| 16:22 |
MTDiscord |
<andrey2470t> I wrote in the PR the broken face shading that you showed on the first two screenshots was fixed by Herowl and I merged these fixes. These ones are already invalid. |
| 16:22 |
sfan5 |
there are noticable differences in how smooth light levels are |
| 16:22 |
grorp |
The screenshots in https://github.com/minetest/minetest/pull/14343#issuecomment-2409027834 were taken with https://github.com/Andrey2470T/minetest/pull/3 applied |
| 16:23 |
grorp |
so they're not "invalid" |
| 16:25 |
[MatrxMT] |
<Zughy> We're also wasting a lot of time debating about this thing. Can't it wait 3 more months? It's not like we're releasing every 8 months like we used to |
| 16:28 |
MTDiscord |
<herowl> Zughy: Well... in that case, we'll need to add the new format, migrate AO calculation, and adjust the unit tests. I.e. there's no point in "waiting". Either the current state is utterly unsatisfying and we need the new format or we don't. |
| 16:29 |
MTDiscord |
<herowl> What I'm afraid is that the new vertex format will cause performance issues or other crap. |
| 16:29 |
sfan5 |
the precision problem could potentially be worked around by moving decode_light to the shader |
| 16:30 |
[MatrxMT] |
<Zughy> It's one hour and a half to the feature freeze, with a meeting incoming, where EU core devs are also supposed to eat in the meanwhile |
| 16:30 |
grorp |
and we have something much more important to get done in the meeting |
| 16:30 |
MTDiscord |
<andrey2470t> @grorp how I would not struggle to differ these screenshots from each other I fail in that, don't see the any difference |
| 16:32 |
sfan5 |
<+sfan5> place them in side-by-side tabs and repeatedly switch between them |
| 16:32 |
sfan5 |
if you can't see the difference that way I don't know what else we can do |
| 16:32 |
sfan5 |
hopefully you have a monitor that was manufactured in the last 8 years and not totally messed up gamma/color reproduction? |
| 16:33 |
MTDiscord |
<jordan4ibanez> Color difference between layers in gimp |
| 16:33 |
cx384 |
merging #14318 in 5 min |
| 16:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/14318 -- Fix HUD inventory direction position by cx384 |
| 16:33 |
MTDiscord |
<herowl> sfan5: yeah, with smooth lighting off it is quite visible... |
| 16:34 |
MTDiscord |
<herowl> so screw my hack and we need the precision? |
| 16:35 |
sfan5 |
correct |
| 16:36 |
MTDiscord |
<andrey2470t> Zughy, my feature is hanging open during a half-year and see how many changes it endured... I even needed to squash all commits into the single one because their count did it difficult to solve the conflicts for me. Also, the comments count is about 200. And leaving it for still 3 months when it is about to be ready and needs only in solving the unittests problem is pretty dump as I think |
| 16:36 |
MTDiscord |
<herowl> Well, there is the precision loss, and AO issue. |
| 16:36 |
MTDiscord |
<herowl> I wouldn't care about those if it depended on me. |
| 16:36 |
MTDiscord |
<herowl> But I can see that others can care about it. |
| 16:36 |
sfan5 |
"I even needed to squash all commits into the single one" you can use git merge btw |
| 16:38 |
MTDiscord |
<herowl> Also I looked deep into the unittests, and I'm not sure why they are failing. |
| 16:38 |
MTDiscord |
<herowl> I personally don't see why those particular unittests are even there, but that's another issue. |
| 16:39 |
MTDiscord |
<herowl> Essentially, looks like we need to rewrite the underlying code. Not from the ground up, but we need to rewrite the meshgen a lot. |
| 16:40 |
MTDiscord |
<herowl> All that to allow the new vertex format, increase precision to what was before, and accommodate for AO. |
| 16:40 |
MTDiscord |
<herowl> Hopefully how to improve the unittests will get clearer along the way. |
| 16:41 |
MTDiscord |
<herowl> As it is now, I'm kind of giving up. I don't see a way to fix those unittests, and I don't see who does and wants to fix them. |
| 16:41 |
MTDiscord |
<herowl> I gather #14543 is also postponed? |
| 16:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/14543 -- Add gameid aliases by nauta-turbidus |
| 16:41 |
MTDiscord |
<herowl> And on that one there are not even visible issues. |
| 16:42 |
MTDiscord |
<herowl> ...anymore |
| 16:42 |
sfan5 |
freeze has not officially started but I don't see a chance |
| 16:43 |
MTDiscord |
<herowl> gl on the rename, will grab popcorn |
| 16:43 |
MTDiscord |
<luatic> I think we probably need something like a new format, but it should be thought out well |
| 16:44 |
MTDiscord |
<luatic> Another idea I had: In principle a single byte suffices for hardware coloring if we pass the palette to the shader |
| 16:45 |
MTDiscord |
<andrey2470t> @herowl I suppose all hacks that we made in the latest commits were a waste of time? The PR has postponed for 5.11. And for fixing other issues e.g. AO and shadows it will certainly need in a new format since there is no a more free space for encoding something more |
| 16:45 |
sfan5 |
<+sfan5> the precision problem could potentially be worked around by moving decode_light to the shader |
| 16:45 |
sfan5 |
^ |
| 16:45 |
sfan5 |
but idk about the issue with AO |
| 16:46 |
sfan5 |
either way a new vertex format is relatively easy to do |
| 16:46 |
sfan5 |
just please do it in a separate PR |
| 16:46 |
sfan5 |
and we will need to drop non-shader support |
| 16:46 |
sfan5 |
(probably) |
| 16:49 |
MTDiscord |
<herowl> Yes, I lost about 20h working on hacks that don't suffice. |
| 16:50 |
MTDiscord |
<herowl> What palette? There's no universal palette. |
| 16:50 |
MTDiscord |
<andrey2470t> It is still necessary to think on which structure the format will have. Adding only another color attribute? Probably it could be extendable. |
| 16:50 |
MTDiscord |
<herowl> Adding only one byte |
| 16:50 |
MTDiscord |
<luatic> The palette specified in the node def. I'm not claiming it is universal. Depending on how our meshgen works this might require creating more mesh buffers however, which might be a drawback. |
| 16:51 |
MTDiscord |
<herowl> I'm afraid it won't work like that. |
| 16:52 |
sfan5 |
i don't see why not. if we group buffers by texture right now it should work fine to include the palette |
| 16:52 |
sfan5 |
only problem is it needs multitexture support |
| 16:53 |
sfan5 |
or you'd have to pass it as shader uniform |
| 16:53 |
MTDiscord |
<herowl> hw color can be done without a palette though |
| 16:53 |
MTDiscord |
<herowl> palette is only for when you're using param2 coloring |
| 16:53 |
MTDiscord |
<andrey2470t> Tbh it is very distressing that I took it upon myself to solve the remainig problems in the ambient PR. I should focus on my closed vertex format... |
| 16:53 |
sfan5 |
arbitrary colors? in that case it won't work |
| 16:54 |
MTDiscord |
<herowl> sfan5: https://api.minetest.net/textures/#global-color |
| 16:55 |
sfan5 |
in any case I reiterate my suggestion to do iterative steps and not everything in one PR |
| 16:55 |
MTDiscord |
<herowl> andrey: it was me who made the hacks that don't require the new format |
| 16:55 |
sfan5 |
it's okay if we change the vertex format in preparation without any visible benefit |
| 16:55 |
sfan5 |
or refactor hw coloring or whatever |
| 16:56 |
MTDiscord |
<herowl> I guess we'll have to do it like that... |
| 16:57 |
MTDiscord |
<luatic> these aren't really arbitrary colors |
| 16:57 |
MTDiscord |
<luatic> the color thing is again per-def |
| 16:57 |
MTDiscord |
<andrey2470t> Actually me too, because I wasted much time on the awareness of the whole problem and I also suggested a few fixes that didn't work |
| 16:57 |
MTDiscord |
<luatic> the itemstack meta would be a bit trickier for itemstack objects but since we're currently doing one drawcall per entity a simple uniform would work there |
| 16:58 |
MTDiscord |
<herowl> luatic: Making entirely separate buffers for all nodes is the opposite of optimization. |
| 16:58 |
MTDiscord |
<luatic> this does not need entirely separate buffers for all nodes |
| 16:59 |
MTDiscord |
<herowl> This feels janky really |
| 17:00 |
MTDiscord |
<herowl> Hang on... |
| 17:00 |
MTDiscord |
<herowl> we could make an extra large palette |
| 17:00 |
MTDiscord |
<herowl> and use two bytes to index it |
| 17:01 |
MTDiscord |
<herowl> technically would work |
| 17:01 |
MTDiscord |
<herowl> but tbh |
| 17:01 |
MTDiscord |
<herowl> I think we should move towards smooth hw coloring, so you could interpolate the color on a range of nodes |
| 17:01 |
MTDiscord |
<herowl> and that requires arbitrary hw color |
| 17:01 |
MTDiscord |
<herowl> if we want colored lighting, we probably need a new color format anyway... |
| 17:09 |
MTDiscord |
<andrey2470t> I don't certainly think only one byte... imagine it would need to save something still, e.g. smooth color transitions like gradients no node tiles. Or a node could have a few UVs, e.g. for future lightmaps optimizing the lighting calculations. Or it could be something shader-specific when the custom shader pipeline gets implemented. So the format should be extendable. |
| 17:09 |
MTDiscord |
<herowl> Well, you can change the format later anyway |
| 17:09 |
MTDiscord |
<andrey2470t> If do a new vertex format, do it with a quality and taking into account for future changes |
| 17:10 |
MTDiscord |
<herowl> Do it in a way so it's less hardcoded and easier to change in the future, but for now support only what we have now. |
| 17:10 |
MTDiscord |
<herowl> It's all clientside, so you can just change it and it doesn't break any compatibility. |
| 17:11 |
MTDiscord |
<herowl> I'm only considering one byte vs color |
| 17:11 |
MTDiscord |
<herowl> the latter to allow colored lighting |
| 17:12 |
MTDiscord |
<herowl> which could happen very soon if we refactor the light calculations, which we need anyway to unhardcode AO |
| 17:12 |
MTDiscord |
<luatic> yep so far I see a need for 3x 1 byte RGB hw color, 1 byte light ratio, 1 byte light brightness |
| 17:12 |
MTDiscord |
<luatic> we currently have a 4x 1 byte RGBA vertex colors and abuse alpha for the light ratio |
| 17:12 |
MTDiscord |
<luatic> adding just one more byte should also be acceptable for performance |
| 17:13 |
MTDiscord |
<andrey2470t> Possible still a separate 3 x 1 byte color will be needed for the colored node lighting |
| 17:15 |
MTDiscord |
<andrey2470t> I think the new vertex formar could be a just byte buffer with a varyable length, so it could be differ from node to node. E.g. those nodes that doesn't need in the hw, just won't have that |
| 17:15 |
MTDiscord |
<herowl> buffer of buffers? uh oh |
| 17:16 |
MTDiscord |
<andrey2470t> For the optimisation |
| 17:16 |
MTDiscord |
<luatic> I think it essentially just needs to be a tagged union |
| 17:16 |
MTDiscord |
<luatic> which to an extent Irrlicht already tries to implement, just the options aren't quite what we're looking for |
| 17:16 |
MTDiscord |
<andrey2470t> Or better call it the byte array, not buffer |
| 17:16 |
MTDiscord |
<herowl> tagged union is size of its largest member though? |
| 17:17 |
MTDiscord |
<luatic> i should be more specific |
| 17:17 |
MTDiscord |
<luatic> a tagged union of buffers (pointers) basically |
| 17:17 |
MTDiscord |
<luatic> not a buffer of tagged unions or anything like that |
| 17:17 |
MTDiscord |
<herowl> I'm afraid that it either won't work on older hardware or won't be very efficient |
| 17:18 |
MTDiscord |
<luatic> I don't think we're striving to support OGL 1 indefinitely |
| 17:18 |
MTDiscord |
<herowl> lol |
| 17:18 |
MTDiscord |
<herowl> what about performance though? |
| 17:18 |
MTDiscord |
<luatic> I am optimistic but ultimately only benchmarks can tell |
| 17:18 |
MTDiscord |
<andrey2470t> It would certainly not work with the fixed function pipeline |
| 17:18 |
MTDiscord |
<andrey2470t> Which is in ogl1 now |
| 17:19 |
MTDiscord |
<andrey2470t> But since it is deprecated and is about to be removed, I think the varyable-sized vertex format could be considered |
| 17:20 |
MTDiscord |
<herowl> we're to support ogl3 and ogles2, right? |
| 17:20 |
MTDiscord |
<andrey2470t> I think only to support them now, yes |
| 17:32 |
|
chmodsayshello joined #minetest-dev |
| 17:33 |
Krock |
opengl3 requires SDL and we're yet not far enough to enable SDL by default for release |
| 17:33 |
Krock |
just throwing that in |
| 17:33 |
Krock |
also: meeting in 27 minutes |
| 17:38 |
[ |
Please do not drop support for OpenGL 2.1. Or if you do, at least make sure that OpenGL ES support is enabled by default and used if OpenGL 3 is unavailable |
| 17:38 |
[ |
Do dynamic shadows work on GLES2? |
| 17:38 |
MTDiscord |
<wsor4035> pretty sure the only support that might be dropped atm is opengl 1 |
| 17:38 |
sfan5 |
shadows only work on opengl, not ogles2 or opengl3 |
| 17:39 |
sfan5 |
not due to technical limitations, just nobody spent time to make it work |
| 17:41 |
sfan5 |
what is likely to be dropped is support opengl older than 2.0 (so w/o shaders) |
| 17:41 |
sfan5 |
dropping the opengl driver is more long-term and unclear |
| 17:42 |
sfan5 |
<+MTDiscord> <andrey2470t> But since it is deprecated and is about to be removed, I think the varyable-sized vertex format could be considered |
| 17:42 |
Krock |
at least dependency-wise it does not matter whether OpenGL 1 is used, or only 2.x |
| 17:43 |
sfan5 |
the complexity of choosing different vertex formats depending on what the nodes actually need just to save one or two bytes is likely not to be worth it |
| 17:46 |
sfan5 |
btw there's no reason opengl3 couldn't work without SDL. just nobody made it work |
| 17:52 |
Krock |
right. Makes sense. |
| 17:55 |
MTDiscord |
<andrey2470t> Currently Irrlicht implements only the dynamic setting the vertex attribute arrays based on the varyable VertexType as it happens in the OGL3 driver, but the problem is that the vertex types in meshes are not varyable, but fixed. There are only three accessible variants. |
| 17:55 |
MTDiscord |
<luatic> Yes, I think we need more variants there. |
| 17:56 |
MTDiscord |
<andrey2470t> Or better implement the vertex type as a varyable byte array without hardcoding the certain types |
| 17:58 |
MTDiscord |
<andrey2470t> Such way dropping video::S3DVertex, S3DVertex2TCoords and S3DVertexTangents |
| 17:58 |
MTDiscord |
<andrey2470t> If I don't mistake, the two last ones are not even used anywhere around the engine |
| 18:00 |
Krock |
Start of the meeting. pinging those who reacted to the announcement. sfan5 Desour grorp cx384 Zughy |
| 18:01 |
nore |
I'm there also! |
| 18:01 |
MTDiscord |
<luatic> me too :) |
| 18:01 |
Krock |
hello and welcome! that's great to see :) |
| 18:01 |
nore |
hello everyone :) |
| 18:01 |
grorp |
hi :) |
| 18:01 |
Desour |
I'm here. but I've not yet read the irc logs |
| 18:01 |
MTDiscord |
<sfence> I am on a train. Expect to leave it in 15 minutes. |
| 18:02 |
[MatrxMT] |
<Zughy> hi! |
| 18:02 |
cx384 |
I'm here but I doubt I will be of any use. |
| 18:04 |
Krock |
cx384: oh? I wouldn't think so. let's see what's to discuss. |
| 18:04 |
Krock |
> rename time! |
| 18:04 |
Krock |
this has been discussed internally already and is most likely a topic that should be continued there |
| 18:05 |
Krock |
I see that a few clarifications were made today regarding the organization renaming - so it must be still ongoing. |
| 18:06 |
[MatrxMT] |
<Zughy> we need to rename today, we need the new name before 5.10 |
| 18:06 |
Krock |
why exactly 5.10? |
| 18:06 |
[MatrxMT] |
<Zughy> we can't apply for FOSDEM with Minetest if we're gonna rename in the meanwhile |
| 18:07 |
[MatrxMT] |
<Zughy> 5.11 will happen in late January, that's way too late |
| 18:07 |
Krock |
then apply as Minetest and rename later because things take time and the FOSDEM happened so often in the past witohut issues |
| 18:07 |
|
chmodsayshello joined #minetest-dev |
| 18:07 |
[MatrxMT] |
<Zughy> I don't agree, also because everything seems ready? |
| 18:07 |
grorp |
why don't we do the rename today though? |
| 18:07 |
[ |
what's the point of renaming? |
| 18:07 |
Krock |
no need to rush things now |
| 18:08 |
MTDiscord |
<luatic> [_: that discussion has been long had |
| 18:08 |
nore |
even if we do the renaming, I'd say we can still apply for FOSDEM with Minetest, can't we? |
| 18:08 |
[MatrxMT] |
<Zughy> rush? It's been over a year, that doesn't seem like rushing |
| 18:08 |
rubenwardy |
I don't think we need to do all the renaming at once, just announce it soon and start doing it in the open |
| 18:08 |
grorp |
+1 |
| 18:08 |
MTDiscord |
<luatic> +1 |
| 18:08 |
[MatrxMT] |
<Zughy> I'm sorry but it's not you the ones who're gonna apply for FOSDEM. I don't want to do things twice |
| 18:08 |
grorp |
I think we're ready to publish the blog post now, though |
| 18:08 |
nore |
+1 |
| 18:08 |
[MatrxMT] |
<Zughy> +1 with rubenwardy |
| 18:09 |
[ |
what will the new name be? |
| 18:09 |
rubenwardy |
To be announced |
| 18:09 |
[MatrxMT] |
<Zughy> Broccoloni |
| 18:09 |
[MatrxMT] |
<Zughy> jk |
| 18:10 |
grorp |
I guess somebody needs to create a minetest/blog PR with the annoucement so it can be reviewed, which would reveal the name |
| 18:10 |
nore |
I think that as soon as the annoucement concerning the new name is made, we can start to use it in various places, such as the fosdem application |
| 18:10 |
[MatrxMT] |
<Zughy> Was GreenXenith being pinged in the end? |
| 18:10 |
[MatrxMT] |
<Zughy> grorp: also a forum post |
| 18:10 |
[MatrxMT] |
<Zughy> no need to review by the way, at least 4 of us went through the document |
| 18:11 |
Krock |
looking at the discussion on GitHub it seems that all major endpoints are reserved now |
| 18:11 |
grorp |
Zughy: I meant the technical aspects |
| 18:14 |
Krock |
so the next steps are to announce the change. rubenwardy would you be willing to coordinate this a bit, or is someone else taking the lead? |
| 18:14 |
[MatrxMT] |
<Zughy> I'm stressing people privately 🙃 |
| 18:14 |
Krock |
okay so Zughy it is. |
| 18:16 |
Krock |
any additional points to add here? something to clarify? |
| 18:17 |
MTDiscord |
<luatic> should we start working on some s/minetest/broccoloni PRs for some of the non-main repos already? |
| 18:17 |
MTDiscord |
<zmv7> Broccoloni?? |
| 18:18 |
Krock |
@zmv7 temporary name until disclosure |
| 18:18 |
Krock |
@luatic I suppose you could start to work on them without publishing. Problem here is that it would need coodination to not do the same thing twice |
| 18:19 |
[MatrxMT] |
<Zughy> Extra: I love Codeberg guys, trolled half of Mastodon https://social.anoxinon.de/@Codeberg/113296648740470783 |
| 18:19 |
Krock |
thus it might be easier to just await the publication and then work on the PR where nobody yet has begun |
| 18:20 |
Krock |
Zughy: I didn't know that Google Drive is going to be renamed |
| 18:20 |
Krock |
( /jk ) |
| 18:20 |
MTDiscord |
<zmv7> New name is "proprietary"? 😆 GNUn't |
| 18:21 |
Krock |
> feature freeze time |
| 18:21 |
Krock |
https://github.com/minetest/minetest/milestone/24 |
| 18:21 |
MTDiscord |
<andrey2470t> Btw, how about the texture atlas PR? Does anybody have a will of reviewing it? |
| 18:23 |
MTDiscord |
<andrey2470t> I did some late fixes in that and I got much better rendering performance than in the master, FPS is 2-3 higher at the middle and drawtime hesitates always from 1-2 ms |
| 18:24 |
Krock |
@andrey2470t you mention a reduction of drawcalls - what's the difference in percent (demo world) ? |
| 18:24 |
MTDiscord |
<zmv7> Will recently-merged #15279 and #15040 prs be in 5.10.0 tho? |
| 18:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/15279 -- [no squash] JSON fix and update our copy by sfan5 |
| 18:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/15040 -- Separate anticheat settings [#2] by zmv7 |
| 18:25 |
MTDiscord |
<luatic> zmv7: yes of course, why wouldn't they be? |
| 18:25 |
MTDiscord |
<andrey2470t> But there are still issues in the textures packing when there are many textures from the tile layers and also there's an issue with the crack animation since it tries to overlay the cracks atop the atlas |
| 18:25 |
Krock |
@zmv7 what's contained in master will be in the next release |
| 18:25 |
Krock |
that's why there'll be a feature freeze |
| 18:25 |
MTDiscord |
<zmv7> I just don't see them in the milestone |
| 18:25 |
Krock |
they didn't target 5.10.0 specifically, thus no milestone. they aren't necessary for that release. |
| 18:25 |
[ |
why doesn't minetest move to codeberg (or something other free github replacement)? |
| 18:25 |
MTDiscord |
<luatic> the milestone is just sort of a wishlist, not a collection of everything that's part of the release |
| 18:26 |
MTDiscord |
<zmv7> Got it |
| 18:26 |
Krock |
[: off-topic. please save that discussion for later. there's also an issue about this. |
| 18:27 |
|
chmodsayshello joined #minetest-dev |
| 18:27 |
sfan5 |
did I miss anything |
| 18:27 |
MTDiscord |
<zmv7> For some reason I thought that this works like with debian's system(unstable, testing, stable, ...) lol |
| 18:27 |
Krock |
sfan5: rename announcement soon. the broccoli is the temporary pseudonyme. then rename as the time goes on. |
| 18:28 |
MTDiscord |
<andrey2470t> I don't know in the percents, I can say only how higher the framerate is at the middle, with and without atlas |
| 18:28 |
sfan5 |
I see |
| 18:28 |
sfan5 |
so someone will work on publishing the blogpost? |
| 18:28 |
nore |
concerning the fixes in the milestone, I can review #15272 if needed |
| 18:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/15272 -- Show warning in the settings menu when shaders are disabled by grorp |
| 18:28 |
chmodsayshello |
Zughy: Could you please remove "Rebase needed" from #15104 again as I have resolved the merge conflict? |
| 18:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/15104 -- Add console-scrollbar by chmodsayshello |
| 18:29 |
MTDiscord |
<luatic> by "at the middle" you mean on average? so 2x - 3x the fps on average on your config? |
| 18:29 |
Krock |
@andrey2470t I always question whether it's worth the N lines of additional code (that needs maintenance) to e.g. boost the FPS from 60 to 62. That's why it would be important to have some repeatable performance measurements. |
| 18:29 |
Krock |
s/repeatable/reproducible/ |
| 18:29 |
MTDiscord |
<andrey2470t> On average in other words |
| 18:30 |
Krock |
nore: that would help. thanks. |
| 18:31 |
Krock |
sfan5: the blog post was mentioned previously by grorp, thus I assumed there's already something. This might be best discussed in the internal chat to do a peer review. |
| 18:31 |
sfan5 |
there's a draft linked in our internal discussions. I have looked at it |
| 18:31 |
sfan5 |
and others too |
| 18:31 |
grorp |
Zughy and I are working to publish it |
| 18:31 |
Krock |
great thanks, grorp . |
| 18:31 |
grorp |
or "and me"? English is complicated. |
| 18:32 |
MTDiscord |
<luatic> i vaguely feel like there might be a cleaner solution than atlases using modern opengl features but i haven't yet looked into it properly. hence why i'm not reviewing it just yet. |
| 18:32 |
Krock |
I don't know either when to use I or me, but it sounds correct and that's what counts ;) |
| 18:32 |
Desour |
Krock: the texture atlas PR fixes a performance bottleneck, so it's definitely worth it. (or something similar, i.e. based on array textures) |
| 18:32 |
MTDiscord |
<andrey2470t> No, if the master has 180-270 FPS with a simple scene, e.g. with plains without water, my PR will have the stable 400 and even higher. That's a result of my tests without shaders enabled, with viewing_range=190 |
| 18:32 |
MTDiscord |
<luatic> specifically: bindless textures, see https://www.khronos.org/opengl/wiki/Bindless_Texture |
| 18:32 |
|
Captain8771 joined #minetest-dev |
| 18:33 |
sfan5 |
have we formally declared feature freeze? |
| 18:33 |
Krock |
not yet |
| 18:34 |
sfan5 |
then let's do so |
| 18:34 |
Krock |
currently going through the milestone and it looks pretty good |
| 18:34 |
Krock |
I'll move my PR to 5.11 |
| 18:35 |
Krock |
because that code is quite brittle and I'd prefer to have it in an early dev version |
| 18:35 |
MTDiscord |
<andrey2470t> With the water scene with the atlas FPS sinks down before 350, but not before 50 how it happens now. That happens due to an improved material and buffer batching (almost all nodes has the same texture - atlas, so it is not needed in additional switches how it happens with the separate textures |
| 18:35 |
Krock |
("that code" = the entirety of inventory movement) |
| 18:36 |
nore |
we should probably move #13961 which is the associated issue as well in that case |
| 18:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/13961 -- Strange behavior when dragging&dropping from MTG creative inventory (since #13146) |
| 18:37 |
Krock |
any objections for doing the feature freeze now? |
| 18:37 |
Krock |
nore: moved. |
| 18:37 |
MTDiscord |
<luatic> freeze it 🧊 |
| 18:38 |
|
Topic for #minetest-dev is now FEATURE FREEZE IN EFFECT SINCE 2024-10-13. Minetest core development and maintenance. Chit chat goes to #minetest. https://dev.minetest.net/ https://irc.minetest.net/ https://github.com/minetest |
| 18:38 |
sfan5 |
i think we should review issues in the milestone now |
| 18:39 |
Krock |
> #14613 |
| 18:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/14613 -- The data structure problem with active objects |
| 18:39 |
sfan5 |
move to 5.11, next. |
| 18:39 |
Krock |
> #14817 |
| 18:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/14817 -- Animation blending no longer works |
| 18:39 |
Krock |
PR #15267 |
| 18:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/15267 -- Fix animation blending by appgurueu |
| 18:40 |
sfan5 |
can't say much about it but if we have a fix I guess we can keep it |
| 18:40 |
Krock |
@luatic Do you happen to have the time to get the PR ready during the feature freeze? |
| 18:41 |
Krock |
it might not be too important after all. not a blocker. |
| 18:41 |
Krock |
let's keep the issue in the milestone for now. we can still skip over it for 5.10. |
| 18:41 |
MTDiscord |
<luatic> I can't say. But don't wait on it. |
| 18:42 |
Krock |
alright. |
| 18:42 |
Krock |
> #14939 |
| 18:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/14939 -- Minetest builds for Mac don't have signature |
| 18:42 |
nore |
from the discussion, looks like we won't be able to get a signed version in the next too weeks |
| 18:42 |
grorp |
when I open the blog PR, may I include the real new name? |
| 18:42 |
grorp |
would be the first public use :o |
| 18:43 |
rubenwardy |
might be worth doing prelimarly code review without pushing publicly? |
| 18:43 |
MTDiscord |
<luatic> I think if possible the first public use should be in the announcement |
| 18:43 |
rubenwardy |
if you can build the blog, send a screenshot |
| 18:43 |
rubenwardy |
and send me the diff |
| 18:43 |
sfan5 |
I think sfence would have to address that issue, Krock |
| 18:43 |
sfan5 |
i think the UX of running unsigned apps is quite annoying but nothing we can (urgently) do |
| 18:43 |
sfan5 |
so I'd remove from milestone |
| 18:44 |
Krock |
sfan5: yes and he's currently in transit so probably no answer. I waited a bit for the blog discussion to finish |
| 18:44 |
Krock |
moved to 5.11 because we eventually need to fix it |
| 18:44 |
MTDiscord |
<luatic> Someone (say rubenwardy) could make a private repo or use their private fork of the blog repo, then review the PR on that, and once it's fine just manually push it and boom |
| 18:44 |
nore |
from the discussion, "it took GNOME almost 2 months to get a key/cert/thing and start to sign GIMP builds" anyway |
| 18:44 |
Krock |
> #14818 |
| 18:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/14818 -- Attachments lag behind bones under some circumstances |
| 18:45 |
rubenwardy |
rememebr to disable SDL2 at the start of freeze |
| 18:45 |
Krock |
yet no PR to fix it and not a blocker |
| 18:45 |
Krock |
rubenwardy: it's already in the milestone |
| 18:45 |
sfan5 |
yeah |
| 18:46 |
Krock |
removing the milestone assignment here because it's not as much of an every-day issue for end users. otherwise we'd keep pushing the same issues from one milestone to the next |
| 18:46 |
nore |
it looks like it is a long-standing bug, not a new one |
| 18:47 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> freeze happening now? |
| 18:47 |
MTDiscord |
<luatic> 14818 definitely is older than 5.9.x |
| 18:47 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> I'm hoping i can take sdl2 by 5.12 |
| 18:47 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> *11 |
| 18:47 |
sfan5 |
> #15027 |
| 18:47 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> for input that is |
| 18:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/15027 -- Bounciness issues with large dtime steps |
| 18:47 |
sfan5 |
fix pending, next. |
| 18:47 |
Krock |
send review needed |
| 18:47 |
Krock |
*second |
| 18:47 |
MTDiscord |
<luatic> i'll review the PR for that one |
| 18:48 |
sfan5 |
> #15005 |
| 18:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/15005 -- Touchscreen can be enabled when Irrlicht device doesn't support touchscreen (CIrrDeviceWin32, CIrrDeviceMacOSX) |
| 18:48 |
sfan5 |
waiting for answer to comment, next. |
| 18:48 |
Krock |
replied for clarification |
| 18:48 |
Krock |
> #15193 |
| 18:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/15193 -- Different globalstep compared to <5.9? |
| 18:48 |
sfan5 |
unclear. no reproducer, cause or fix. |
| 18:48 |
Krock |
is this another ghostbuster-like issue? |
| 18:48 |
sfan5 |
move to next |
| 18:48 |
Krock |
> #15264 rubenwardy here's your reminder |
| 18:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/15264 -- Revert SDL for 5.10, try again in 5.11 |
| 18:49 |
Krock |
> #15270 Â PR is pending here |
| 18:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/15270 -- Bad UX when upgrading to 5.10 with shaders disabled |
| 18:49 |
Krock |
at least the one about a notification in the settings. nore wanted to review it soon. |
| 18:49 |
nore |
yes, I'll review it tonight or tomorrow night |
| 18:49 |
Krock |
no worries. you've got more time than that. |
| 18:50 |
Krock |
and of list |
| 18:50 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> im gonna say no to 15005 and I'll elaborate later |
| 18:50 |
Krock |
* -- end of milestone -- |
| 18:50 |
nore |
(I know I have but I'll forget otherwise :) ) |
| 18:50 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> a user using a Chromebook complained about touch screens |
| 18:50 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> we shouldn't hide it |
| 18:51 |
Krock |
@cscscscscscscscscscscscscscscscs what OS are they using on the Chomebook? We might need a public support matrix for SDL vs Irrlicht because I keep running into the same uncertianinties |
| 18:51 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> i believe it's Android related |
| 18:52 |
Krock |
if it's Android then touch controls already work out of the box |
| 18:52 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> Yes they wanted to disable touchscreen |
| 18:52 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> Android removes it |
| 18:52 |
Krock |
let them test a master build after #14542 |
| 18:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/14542 -- [no squash] Auto-toggle TouchScreenGUI in-game when receiving touch/mouse input by grorp |
| 18:52 |
Krock |
then report back whether it worked well enough. |
| 18:53 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> I'm afraid they pregnant won't be able to test it |
| 18:53 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> *PROBABLY |
| 18:53 |
Krock |
Any other topics/PRs to discuss (in concept or review) ? |
| 18:54 |
MTDiscord |
<rollerozxa> for chromebook users it's probably better to run minetest in the crostini linux container |
| 18:54 |
MTDiscord |
<rollerozxa> worked well last time I tried it there at least |
| 18:54 |
sfan5 |
don't think so |
| 18:54 |
Krock |
general reminder that there's PR's waiting on a second approval |
| 18:55 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> I'm so sorry I'm using my phone swipe text |
| 18:55 |
Krock |
ofc feature ones are not too important in the next few weeks. |
| 18:55 |
[ |
there's also GNU/Linux phones |
| 18:55 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> it was for his students |
| 18:55 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> we shouldn't remove/hide the option |
| 18:56 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> you can still use touchscreen menus with it off |
| 18:57 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> Linux support on new Chromebook didn't exist |
| 18:57 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> *old |
| 18:57 |
Krock |
saving the meeting notes now. Thank you for participating. Other PRs can still be discussed here, just without the meeting schedule behind it. |
| 18:57 |
MTDiscord |
<rollerozxa> okay yeah I understand, easier to deploy android apps on chrome OS than crostini, which most managed domains block because of the risk of students having fun with it |
| 18:57 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> I'll reply to the issues late but I'm at work |
| 18:57 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> that too yeah |
| 18:59 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> I think his complaint was that his students in school used the older Chromebooks which don't support Christine |
| 18:59 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> crostini |
| 19:01 |
Krock |
the wiki died. 504 Gateway Time-out |
| 19:06 |
[MatrxMT] |
<Zughy> it's working again, at least the dev one |
| 19:19 |
sfan5 |
something I just noticed is that since clouds now use shaders and we have clouds in the main menu that means Minetest will just not launch if you don't have shader support |
| 19:19 |
sfan5 |
this should affect approximately nobody and can be fixed by adding 'enable_shaders = false' to minetest.conf |
| 19:20 |
sfan5 |
IMO we should just keep it like this and see if anyone ever complains |
| 19:20 |
Desour |
minetest is a test |
| 19:21 |
[MatrxMT] |
<Zughy> *Broccoloni is a test |
| 19:32 |
nore |
approved #15272, I think we can merge it since grorp is a core dev? |
| 19:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/15272 -- Show warning in the settings menu when shaders are disabled by grorp |
| 19:37 |
sfan5 |
sure |
| 19:59 |
nore |
ok, will merge tomorrow if no-one objects before then |
| 21:19 |
MTDiscord |
<andrey2470t> I think I will make the solution of #15287 later |
| 21:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/15287 -- Render the cracked node counterpart instead of the rebuilding the whole mapblock mesh |
| 21:21 |
|
GreenXenith joined #minetest-dev |
| 21:26 |
MTDiscord |
<andrey2470t> Except that, it seems when nodes are dug the same mapblock mesh gets rebuilt a tens of times instead of only three ones (at the begin, at the end of the crack animation and dire tly when the node gets dug |
| 21:50 |
sfan5 |
for completeness: https://blog.minetest.net/2024/10/13/Introducing-Our-New-Name/ |
| 21:51 |
[MatrxMT] |
<Zughy> Wait, it's not Broccoloni?! OH C'MON |
| 21:52 |
sfan5 |
Broccolibre |
| 21:52 |
sfan5 |
need a broccoli themed game |
| 21:53 |
[MatrxMT] |
<Zughy> fun fact: "brocco" is a way to say stupid in Italian, so "Broccolibre" sounded like "Free dumdum" |
| 21:56 |
ROllerozxa |
I have to say I am very happy with the new name, I used to be worried but now I am extremely excited |
| 21:56 |
MTDiscord |
<cscscscscscscscscscscscscscscscs> luatic is my favorite game to play with |
| 21:57 |
[ |
So will the IRC channels be renamed to #luanti and #luanti-dev? |
| 21:59 |
sfan5 |
dunno |
| 22:01 |
MTDiscord |
<herowl> Some insight: https://en.wiktionary.org/wiki/%CE%BB%CF%85%CF%8C%CE%BD%CF%84%CF%89%CE%BD |
| 22:01 |
MTDiscord |
<herowl> lyonton, means "let them set free" |
| 22:03 |
MTDiscord |
<andrey2470t> I've been overwhelmed with this news, but I don't think I will call the project by the new name after renaming, "Minetest" is for me a familiar and established name |
| 22:11 |
|
grorp left #minetest-dev |
| 22:13 |
|
\o` joined #minetest-dev |
| 22:15 |
sfan5 |
https://en.m.wiktionary.org/wiki/Luanci hmm |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 23:01 |
MTDiscord |
<exe_virus> Great work on the rename! I'm really actually quite impressed. You captured the core (Lua) and it's generic in terms of what is possible, yet distinct. I may not love it, but on first glance I don't hate it. Â Name went from a 2 -> 7 or 8. Thanks for the hard work! |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:19 |
|
hlqkj left #minetest-dev |
| 23:49 |
MTDiscord |
<exe_virus> So... Logo? It looks like everything else has been considered... |
| 23:50 |
[MatrxMT] |
<Zughy> Not touching it. Surely not for the foreseeable future |
| 23:51 |
MTDiscord |
<exe_virus> seems reasonable to me, jsut curious |
