| Time |
Nick |
Message |
| 00:05 |
|
Mister_Q joined #minetest-dev |
| 00:06 |
|
Mister_Q joined #minetest-dev |
| 00:19 |
|
Mister_Q joined #minetest-dev |
| 00:22 |
|
Mister_Q joined #minetest-dev |
| 00:35 |
|
Mister_Q joined #minetest-dev |
| 02:10 |
|
Mister_Q joined #minetest-dev |
| 03:21 |
|
olliy joined #minetest-dev |
| 04:16 |
|
pengolod joined #minetest-dev |
| 04:49 |
|
pengolod left #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 07:59 |
|
ronoaldo joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 09:04 |
|
Lunatrius joined #minetest-dev |
| 09:06 |
|
zughy[m] joined #minetest-dev |
| 09:06 |
|
BakerPrime_ joined #minetest-dev |
| 09:19 |
|
calcul0n joined #minetest-dev |
| 09:35 |
|
LoneWolfHT joined #minetest-dev |
| 09:37 |
|
zughy[m] joined #minetest-dev |
| 09:43 |
|
Newbyte joined #minetest-dev |
| 09:46 |
|
kb1000 joined #minetest-dev |
| 09:46 |
|
freshreplicant[m joined #minetest-dev |
| 09:46 |
|
Zughy[m]1 joined #minetest-dev |
| 10:21 |
|
kb1000 joined #minetest-dev |
| 10:58 |
|
ronoaldo joined #minetest-dev |
| 11:03 |
|
giov4[m] joined #minetest-dev |
| 11:03 |
|
Zughy[m]1 joined #minetest-dev |
| 11:03 |
|
LoneWolfHT joined #minetest-dev |
| 11:03 |
|
Newbyte joined #minetest-dev |
| 11:03 |
|
zughy[m] joined #minetest-dev |
| 11:03 |
|
freshreplicant[m joined #minetest-dev |
| 11:03 |
|
_Zaizen_[m] joined #minetest-dev |
| 11:42 |
|
Fixer joined #minetest-dev |
| 12:01 |
|
proller joined #minetest-dev |
| 12:13 |
|
pmp-p joined #minetest-dev |
| 12:30 |
|
proller joined #minetest-dev |
| 14:09 |
|
olliy joined #minetest-dev |
| 14:46 |
|
Lunatrius joined #minetest-dev |
| 15:17 |
|
proller joined #minetest-dev |
| 15:18 |
|
calcul0n_ joined #minetest-dev |
| 16:29 |
|
Lunatrius` joined #minetest-dev |
| 16:44 |
|
Lunatrius joined #minetest-dev |
| 16:49 |
|
Lunatrius` joined #minetest-dev |
| 17:02 |
|
numzero joined #minetest-dev |
| 17:54 |
|
fluxflux_ joined #minetest-dev |
| 18:41 |
Krock |
Meeting in 20 minutes |
| 18:58 |
nerzhul_ |
oh a meeting, what are the topics Krock ? |
| 18:58 |
Zughy[m]1 |
https://dev.minetest.net/Meetings#2021-01-23 |
| 19:00 |
|
v-rob joined #minetest-dev |
| 19:01 |
Krock |
nerzhul_: mainly 5.4.0 release stuff |
| 19:02 |
nerzhul_ |
Krock: can i add a point about irrlicht and our future with it ? We are very hesitating on it, maybe we can thing about a 6.0 release with an embedded irrlicht with our fixes, overview. As a detached library first then we will see |
| 19:03 |
Krock |
no idea how many 5.x.0 releases there will be but yes sure |
| 19:04 |
nerzhul_ |
we may think about a 6.0 when this new library will be used as a replacement, or maybe when we start to use our own very close irrlicht if we decide it |
| 19:05 |
Krock |
though it will result in additional effort for package maintainers and users to build Minetest if an external repostiroy is required (non-bundled) |
| 19:05 |
Krock |
there's no way around I guess... |
| 19:05 |
v-rob |
Why would it require a 6.0? It only immediately affects the build process, no? |
| 19:05 |
sfan5 |
yes, it wouldn't require a 6.0 |
| 19:06 |
nerzhul_ |
it's a rupture in our dependency system, as you like in terms of naming, for me it's a major milestone in terms of project |
| 19:06 |
nerzhul_ |
anyway let's discuss that after release point, ok ? |
| 19:07 |
Krock |
now that we're already discussing the SDL/Irrlicht part we can just go ahead with this |
| 19:07 |
Krock |
it needs to be discussed sometime anyway |
| 19:08 |
Krock |
if possible, a dual system using the official Irrlicht branch and custom branch would be amazing. is that feasible or just unnecessary effort, nerzhul_ ? |
| 19:08 |
nerzhul_ |
it's a very huge effort, but possible, the problem is that you want SDL which requires a rupture in the irrlicht AND mt parts :p |
| 19:08 |
Krock |
so you'll probably need a separate branch for it |
| 19:09 |
sfan5 |
why separate branch? |
| 19:09 |
sfan5 |
so we can return to upstream irrlicht one day? |
| 19:09 |
nerzhul_ |
i'm not sure regarding the project lifetime it's an option haha |
| 19:09 |
nerzhul_ |
but a branch for the first developments is require |
| 19:09 |
Krock |
I'm not sure if SDL2 should become a dependency right now or whether all changes are applied at once |
| 19:10 |
Krock |
latter means a separate branch which then can be merged into master once it's ready |
| 19:10 |
nerzhul_ |
someone said SDL2 has huge overhead in terms of binary |
| 19:10 |
nerzhul_ |
at runtime |
| 19:11 |
sfan5 |
I think we should integrate sdl in a way that code is still theoretically compatible with normal Irrlicht |
| 19:11 |
Krock |
would be nice to know who said that, to judge what *huge* means in this context |
| 19:11 |
sfan5 |
so not just replace SEvent with SDL_Event, but translate SDL events into SEvent in Irrlicht's code |
| 19:11 |
Krock |
sfan5: but according to nerzhul_ that'll cause a lot more effort |
| 19:11 |
v-rob |
As far as I can tell, one of the biggest problems with SDL is text input. SDL2 uses real IME input while Irrlicht has a `Char` field in KeyInput. Instead of fixing this in Minetest, I would suggest making a polyfill from Irrlicht->SDL's events and not changing Minetest yet. |
| 19:12 |
sfan5 |
Krock: well that doesn't have to literally be a seperate branch, more of a thoeretical possibility |
| 19:12 |
sfan5 |
...if you get what I mean by that |
| 19:12 |
Krock |
I think I know what you mean, yes. |
| 19:12 |
sfan5 |
v-rob: yeah we could add a wchar_t* to SEvent for that |
| 19:13 |
sfan5 |
it will not be compatible with normal Irrlicht but it would not be far from it if there ever is need to use vanilla Irrlicht |
| 19:13 |
sfan5 |
this would also be advantageous if we do not want to port Android to SDL2 immediately |
| 19:13 |
nerzhul_ |
yep the keyboard handling in SDL2 is totally different |
| 19:13 |
nerzhul_ |
then we must require our GUI parts |
| 19:13 |
Krock |
is SDL2 a singular big blob, or can parts be imported individually, like the rendering/input part? |
| 19:14 |
v-rob |
Trying to make IME in EditBox, the chat, etc. is likely to have errors and IMO belongs to the formspec replacement |
| 19:14 |
nerzhul_ |
we should not use SDL2 rendering part except if you plan to replace GUI formspec with a SDL2 based other layout |
| 19:14 |
v-rob |
I see no need for SDL's rendering API, mainly events and windowing |
| 19:14 |
sfan5 |
agree ^ |
| 19:14 |
nerzhul_ |
we are close to that |
| 19:15 |
Krock |
right. think of it as an example then. we won't need networking either |
| 19:16 |
Krock |
maybe that's just be being too greedy |
| 19:17 |
Calinou |
SDL rendering is pretty oudated, it's not hardware accelerated |
| 19:17 |
Krock |
so initially, development on a separate Minetest branch, and merge once it's usable? Is that a plan, nerzhul_ ? |
| 19:17 |
pgimeno |
Calinou: I presume we are talking about SDL-GL |
| 19:17 |
v-rob |
Well, SDL_Surface is not hardware accllerated, but SDL_Texture is |
| 19:18 |
pgimeno |
so the idea would be to keep Irrlicht for the scene graph and rendering? I have issues with that |
| 19:18 |
Krock |
Irrlicht is an issue and the goal is to incrementally replace it |
| 19:18 |
pgimeno |
I think it should eventually be replaced, and SDL is not a bad choice |
| 19:18 |
nerzhul_ |
irrlicht jsut take the SDL_surface and does its opengl stuff on it, look at my branch |
| 19:18 |
Krock |
user input just happens to be the first use-case |
| 19:19 |
rubenwardy |
Calinou: we'd never be able to use SDL rendering, it's 2d |
| 19:19 |
rubenwardy |
We're talking about its ability as an input library and window manager |
| 19:19 |
Krock |
nerzhul_: so you added SDL2 as Irrlicht device which is then used for rendering, or am I seeing that wrong? |
| 19:19 |
v-rob |
The only way to use SDL with 3D is through OpenGL, Vulkan, or Direct3d |
| 19:20 |
nerzhul_ |
yes it's a thing like this |
| 19:20 |
nerzhul_ |
and sdl2 is used for text input but it's not clear yet on the MT side |
| 19:21 |
pgimeno |
if migrating allows dead keys (accents) to be typed, that would be awesome |
| 19:22 |
v-rob |
It would eventually, but likely not immediately. It would also allow things like Chinese and other such languages as well |
| 19:23 |
Krock |
okay. noted that. I'll update the entire Meeting wiki section after the other points are done |
| 19:23 |
Krock |
just to have a rough overview of what's going to happen next |
| 19:23 |
v-rob |
Along with improved joystick/game controller and touchscreen events |
| 19:25 |
Krock |
okay. Starting with the 5.4.0 release topic |
| 19:25 |
Krock |
=============================== |
| 19:25 |
Krock |
all issues and PRs which should go into 5.4.0 should be marked by now |
| 19:26 |
Krock |
according to rubenwardy (I believe), the desired freature freeze is today or in a week? |
| 19:26 |
rubenwardy |
I reckon so |
| 19:27 |
Krock |
other thoughts? I'd be okay with a freeze from today but in exchange the freeze might last longer for difficult issues |
| 19:28 |
Krock |
Alpha textures now have a fix. the ContentDB issue for Windows should be easy to fix, given that someone can test it |
| 19:29 |
Krock |
my concern is the get_player_information where no clear information about 5.4.0-dev is available |
| 19:30 |
Krock |
from what I understand the problem is that the callbacks are run even after the player is kicked |
| 19:31 |
sfan5 |
that's avoidable in mods |
| 19:31 |
Krock |
i.e. mod issue and does not need fixing? |
| 19:31 |
sfan5 |
the issue remains that the peer can disappear at any time before the player disappears |
| 19:31 |
sfan5 |
or at least that's what I guess, haven't looked into this deeply |
| 19:32 |
Krock |
so it's an async issue while unloading a player's data |
| 19:32 |
sfan5 |
I have no idea about #9352 yet |
| 19:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/9352 -- minetest.get_player_information sometimes return nil (running at mod load, in singleplayer) |
| 19:32 |
rubenwardy |
-> mod load |
| 19:32 |
rubenwardy |
the singleplayer doesn't join until after mods load, right? |
| 19:32 |
rubenwardy |
I should probably read more than the title |
| 19:33 |
Krock |
okay. It would be nice to somehow reproduce this error reliably |
| 19:33 |
sfan5 |
the title is wrong yea |
| 19:33 |
numzero |
I’m working on using SDL for input now |
| 19:33 |
numzero |
text input works |
| 19:33 |
Krock |
numzero: thanks for the input. will note that. |
| 19:34 |
numzero |
touch input almost works |
| 19:34 |
v-rob |
Wait, are there two people working on SDL at the same time? |
| 19:34 |
rubenwardy |
pun alert |
| 19:34 |
Krock |
rubenwardy: intended |
| 19:34 |
numzero |
I started my work off nerzhul’s branch |
| 19:35 |
nerzhul_ |
numzero you have PR on my branches ? can be nice |
| 19:36 |
numzero |
I have two branches now, one compatible with nerzhul’s (so he can pick commits from that) and one merged with ogl-es (Irrlicht 1.9) |
| 19:36 |
Krock |
I'll also have a look at the player information issue but recently my time is also kinda limited |
| 19:37 |
Krock |
let's see |
| 19:38 |
Krock |
#10636 |
| 19:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/10636 -- Improve touch event handling by numberZero |
| 19:38 |
numzero |
as using SDL with Irrlicht 1.8 is kinda pointless, it doesn’t support all our target platforms |
| 19:38 |
numzero |
so there will be need to use other Irrlicht version anyway |
| 19:38 |
Krock |
Q: how many people already tested this? |
| 19:38 |
Krock |
or rather, what's the state of the PR? mergeable? |
| 19:39 |
rubenwardy |
I was going to, but then my computer ran out of storage and I got distracted on house keeping |
| 19:39 |
rubenwardy |
also text wrapping |
| 19:39 |
numzero |
Krock: depends on #10808 |
| 19:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/10808 -- Improve irr_ptr by numberZero |
| 19:39 |
rubenwardy |
implementing working word wrapping took much much longer than expected |
| 19:39 |
numzero |
which has line length issues |
| 19:39 |
Krock |
numzero: yes I saw that. shouldn't be a major concern. |
| 19:39 |
Krock |
// clang-format off |
| 19:39 |
Krock |
// clang-format on |
| 19:40 |
Krock |
fixed |
| 19:40 |
numzero |
which is possible to “fix”, or agree to #10792 |
| 19:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/10792 -- Clang-format: increase column limit from 90 to 105 by Zughy |
| 19:40 |
Krock |
how about Gradle? is that fixed in master? |
| 19:41 |
Krock |
that's the other of the two failed builds/checks |
| 19:41 |
sfan5 |
yes |
| 19:41 |
Krock |
good. thanks. |
| 19:42 |
rubenwardy |
TIL operator== is not commutative |
| 19:43 |
Krock |
rubenwardy: but you'd have time in the next few weeks to test the input PR? |
| 19:43 |
rubenwardy |
yeah |
| 19:43 |
Krock |
thx |
| 19:44 |
Krock |
#/10819 |
| 19:44 |
Krock |
#10819 |
| 19:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/10819 -- [DONT SQUASH] Rework use_texture_alpha by sfan5 |
| 19:44 |
Krock |
I was going to test this like yesterday. Will give it a try again today by testing all registered nodes in a few games |
| 19:45 |
Krock |
also backwards compat needs testing, which is unlikely covered by Lone_Wolf's review |
| 19:46 |
Krock |
backwards compat from an old server -> new client and new server -> old client |
| 19:47 |
Krock |
#10555 |
| 19:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/10555 -- Mapgen settings in a game's minetest.conf get ignored |
| 19:48 |
Krock |
does this have to be fixed for 5.4.0? IMO the only proper solution would be to once and for all clean up the settings structure in 310661 |
| 19:49 |
Krock |
#10661 |
| 19:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/10661 -- [MANUAL SQUASH] Settings: Proper priority hierarchy by SmallJoker |
| 19:49 |
Krock |
whereas I tested many cases, it is still a deep change and would like to get some feedback there in case the issue has priority |
| 19:50 |
Krock |
also waiting for Casimir's answer to be sure |
| 19:50 |
sfan5 |
settings stuff should be fixed for 5.4 IMO |
| 19:52 |
Krock |
okay. I'll add the milestone to that PR because I don't think any other hacky method would work reliably due to overwriting issues |
| 19:53 |
Krock |
so when's the feature freeze starting? give it some more time to find a solution for get_player_information, or put on a bit of pressure by starting it today? |
| 19:53 |
Krock |
opinions? |
| 19:54 |
sfan5 |
are there any feature PRs ready enough to get in? |
| 19:54 |
sfan5 |
if not it doesn't really matter when the freeze starts |
| 19:54 |
rubenwardy |
v-rob has a PR with approval |
| 19:54 |
rubenwardy |
builtin translate is also close to being approved |
| 19:55 |
Krock |
https://github.com/minetest/minetest/pulls?q=is%3Apr+is%3Aopen+label%3AFeature+label%3A%22One+approval%22 |
| 19:55 |
Krock |
translated builtin would be indeed good to have |
| 19:55 |
|
Fleckenstein joined #minetest-dev |
| 19:55 |
Krock |
rubenwardy: are you talking about #10083 |
| 19:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/10083 -- FormSpec: Add list spacing, slot size, and noclip by v-rob |
| 19:56 |
rubenwardy |
yeah |
| 19:56 |
rubenwardy |
it has approval, v-rob can merge if he's still happy with it |
| 19:56 |
rubenwardy |
not important for 5.4.0 though, but well over due |
| 19:56 |
v-rob |
Yeah, I'm still happy with it. |
| 19:57 |
|
Mister_Q joined #minetest-dev |
| 19:57 |
Krock |
looks good from a quick glance |
| 19:57 |
v-rob |
PRs for it have been around for about three years now |
| 19:57 |
Krock |
so merge that and start feature freeze today? |
| 19:58 |
sfan5 |
I vote for starting it next week |
| 19:58 |
Krock |
I also feel safer that way |
| 19:58 |
rubenwardy |
fine by me |
| 20:00 |
|
kilbith joined #minetest-dev |
| 20:01 |
kilbith |
before you start to freeze, I remind you that I need that too: https://github.com/minetest/minetest/pull/10265 |
| 20:01 |
Krock |
!title |
| 20:01 |
ShadowBot |
FormSpec: 9-slice images, animated_images, and fgimg_middle by v-rob · Pull Request #10265 · minetest/minetest · GitHub |
| 20:01 |
rubenwardy |
I posted review comments for that, yet to be addressed |
| 20:01 |
v-rob |
I can fix those today |
| 20:01 |
kilbith |
thank you |
| 20:03 |
Krock |
game#2803 |
| 20:03 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2803 -- Lossless PNG Compression by ExeVirus |
| 20:04 |
Krock |
rubenwardy: what would you like to discuss? |
| 20:04 |
rubenwardy |
What the issue is that prevents from doing this optimisation |
| 20:04 |
Krock |
reading.... |
| 20:05 |
rubenwardy |
If it's just the leaves thing, then those have been whitelisted by the author to retain RGB when a=0 |
| 20:05 |
Krock |
I've seen that issue before |
| 20:05 |
Krock |
game#2801 |
| 20:05 |
sfan5 |
the mipmapping done by the engine code(?) doesn't ignore transparent pixels |
| 20:05 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2801 -- Foliage using allfaces_optional becomes too dark with distance (most leaf texture transparent pixels need improved colouring) |
| 20:06 |
rubenwardy |
oh interesting, so you either break mipmapping or you break opaque leaves |
| 20:07 |
Krock |
opaque leaves are a sin |
| 20:07 |
sfan5 |
hence the transparent pixels need to still have colors |
| 20:07 |
rubenwardy |
for Android I can seem them being worth it |
| 20:08 |
v-rob |
I can live with opaque leaves; it's opaque water that I can't stand |
| 20:09 |
Krock |
so either whitelist or compress the textures in a way without discarding the alpha colors |
| 20:10 |
Krock |
I think the opaque leaves issue is less important than bad mipmapping |
| 20:10 |
Krock |
IIRC that opaque mode is done using a certain color threshold |
| 20:11 |
sfan5 |
or fix the code |
| 20:11 |
Krock |
imageCleanTransparent imagefilters.cpp |
| 20:11 |
sfan5 |
but I don't know if the engine does the downscaling itself |
| 20:11 |
rubenwardy |
that PR already whitelists to preserve alpha colors |
| 20:13 |
Krock |
"The table of contents is too big for display. " thanks GitHub |
| 20:14 |
Krock |
fixing the opaque mode then seems the best solution to me, in combination with whitelisted textures |
| 20:15 |
Krock |
why whitelist? those textures that have alpha contents do show it most likely to the client |
| 20:15 |
Krock |
exceptions are overlay textures |
| 20:15 |
rubenwardy |
whitelist meaning that the optimiser doesn't remove the colors |
| 20:16 |
Krock |
it's a matter of a few bytes whether there's color in alpha=0 pixels. not optimizing any texture using that method would also be a solution |
| 20:17 |
rubenwardy |
exe_virus: thoughts? |
| 20:17 |
MTDiscord |
<rubenwardy> @exe_virus |
| 20:18 |
MTDiscord |
<exe_virus> I already whitelisted those textures |
| 20:18 |
MTDiscord |
<exe_virus> There won't be any issues |
| 20:18 |
MTDiscord |
<exe_virus> It totals an extra like 200 bytes or so |
| 20:19 |
MTDiscord |
<exe_virus> The PR contains those whitelists. Though I want to go over those 30 one more time before it's officially merged, since I did that for the rest of the textures in mtg |
| 20:20 |
MTDiscord |
<Flamore> You mean paramat game? |
| 20:20 |
rubenwardy |
exe: the suggestion is to not do it for all textures, to avoid the whitelist. Does that have a big effect? |
| 20:21 |
rubenwardy |
well, I suppose it's unlikely we'll be adding more leaves given MTG is in feature freeze |
| 20:21 |
MTDiscord |
<exe_virus> All textures? Yeah it has a larger effect when we don't use 8-bit indexed for all textures. |
| 20:21 |
MTDiscord |
<exe_virus> But this is only an issue for allfaces drawtypes |
| 20:22 |
MTDiscord |
<exe_virus> Hence the 30 that were reverted |
| 20:22 |
Krock |
no, also an issue for plantlike |
| 20:22 |
Calinou |
are opaque leaves worth supporting when we have simple (glasslike) leaves with denser textures? |
| 20:22 |
Krock |
also glasslike and nodeboxes (glass) |
| 20:23 |
Krock |
without alpha=0 colors those will also look bad from a distance |
| 20:23 |
|
Mister_Q joined #minetest-dev |
| 20:23 |
Krock |
but I doubt those have such colors already |
| 20:23 |
MTDiscord |
<exe_virus> No worries, the original PR in 2016 that originally reverted the textures is where I got the 30 files. I didn't question it but it's more than the 15 or so that should be allfaces. If you want I can go back and revert any drawtypes you want, just give me the list |
| 20:24 |
Krock |
it's just what came into my mind just now. I cannot reliably tell where exactly it's needed |
| 20:24 |
MTDiscord |
<exe_virus> So right now it's: Plantlike Allfaces+ Glasslike Glass-nodeboxes |
| 20:24 |
MTDiscord |
<exe_virus> Gotcha am I looking for anything with transparency? |
| 20:25 |
Krock |
textures where the transparency is shown to the client, and where the placed node looks bad from a distance |
| 20:25 |
Krock |
sorry, I cannot give a better explanation than this |
| 20:26 |
Krock |
(note: mipmapping must be enabled) |
| 20:26 |
MTDiscord |
<exe_virus> Yeah, and you can't have a nvidia gpu |
| 20:26 |
MTDiscord |
<exe_virus> Only amd or intel integrated with mipmapping has the issue |
| 20:27 |
Krock |
can reproduce it on a GTX 1050 |
| 20:28 |
Krock |
the meeting is over, I presume. |
| 20:28 |
Krock |
I don't have any additional points on the list and the wiki page is updated now |
| 20:30 |
MTDiscord |
<exe_virus> Okay, I'll research what happens if we don't use 8-bit indexed mode for the pngs |
| 20:31 |
kilbith |
Krock, well you forgot to mention inventory slot spacing but *sigh* |
| 20:32 |
Krock |
oh sorry. I thought we were talking about the badly scaled mipmap textures. 8-bit indexed shouldn't have an influence there |
| 20:32 |
Krock |
not sure though |
| 20:32 |
Krock |
kilbith: I need to move the section so I'll add that now. thanks for pointing out |
| 20:34 |
kilbith |
lhof<smth> would have talked about ZSTD in this meeting, too bad |
| 20:35 |
MTDiscord |
<exe_virus> We should have |
| 20:35 |
MTDiscord |
<exe_virus> I am clamoring for ZSTD |
| 20:35 |
MTDiscord |
<exe_virus> But I'm not a core dev haha |
| 20:41 |
v-rob |
Any problems with me merging #10083? |
| 20:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/10083 -- FormSpec: Add list spacing, slot size, and noclip by v-rob |
| 20:45 |
kilbith |
author being core-dev equals to a pre-approval |
| 20:45 |
v-rob |
Just making sure no one had any issues with it |
| 20:47 |
kilbith |
btw I noticed that hovering a hypertext[] with no scrollbar inside a scroll_container, blocks the container scrolling |
| 20:48 |
kilbith |
solution: disable the scrolling of hypertext without scrollbar |
| 20:48 |
v-rob |
Sounds like hypertext is eating the mouse event |
| 20:48 |
kilbith |
yes |
| 20:49 |
kilbith |
it should happen when there's actually a scrollbar when the content exceeds the limits |
| 20:56 |
ronoaldo |
Hey! I have tested the PR from drag and drop improvements on both desktop and mobile with no issues, looks good in terms of not adding side effects on my phone, and fixes the drag on mobile |
| 21:11 |
|
kilbith joined #minetest-dev |
| 21:13 |
|
Miner_48er joined #minetest-dev |
| 21:20 |
MTDiscord |
<exe_virus> Okay, @rubenwardy I closed the old mtg compression PR and opened a new one #2808. It only uses optipng.exe and does not change any bit depth settings, only strips metadata and attempts maximum zlib compression. Result still saves 93KB. Original PR only saved 11.2KB more, so not a big deal. Low hanging fruit first. |
| 21:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/2808 -- Add MoveSomewhere inventory action by est31 |
| 21:24 |
rubenwardy |
merging #10838 in 10 |
| 21:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/10838 -- Do not close game on escape in error windows by yamanq |
| 21:33 |
Zughy[m]1 |
#10792 comments addressed |
| 21:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/10792 -- Clang-format: increase column limit from 90 to 105 by Zughy |
| 21:37 |
sfan5 |
do we know if clang-format still runs with those settings |
| 21:40 |
rubenwardy |
yes it does |
| 21:41 |
|
Seirdy joined #minetest-dev |
| 21:41 |
sfan5 |
there's no CI run in the PR |
| 21:41 |
rubenwardy |
the workflow will be broken then |
| 21:42 |
|
kilbith joined #minetest-dev |
| 21:42 |
rubenwardy |
.clang-format needs to be added to both paths in .github/workflows/cpp_lint.yml |
| 21:43 |
v-rob |
Addressed issues in #10265 |
| 21:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/10265 -- FormSpec: 9-slice images, animated_images, and fgimg_middle by v-rob |
| 21:43 |
rubenwardy |
thanks, I'll take a look later |
| 21:46 |
kilbith |
v-rob, we can't set a spacing of 0 for slots of size < 1? |
| 21:48 |
kilbith |
v-rob, https://i.imgur.com/uAwCDQH.png |
| 21:49 |
kilbith |
size = 0.7; spacing = 0 |
| 21:52 |
v-rob |
Uhh, let me check that out |
| 21:57 |
v-rob |
Oh gee, you're right. I did some calculations with imgsize instead of slot_scale. I will fix that right away. |
| 22:17 |
|
Fixer_ joined #minetest-dev |
| 22:21 |
kilbith |
v-rob, so? |
| 22:22 |
v-rob |
Just compiled, making the PR now |
| 22:26 |
kilbith |
testing |
| 22:28 |
kilbith |
ok works as expected |
| 22:35 |
rubenwardy |
v-rob: FYI: you can merge trivial bug fixes by yourself, you just need to announce in this channel with notice |
| 22:37 |
v-rob |
ok |
| 22:38 |
rubenwardy |
it has to be trivial (=small and unlikely to cause a problem) and has to be a bug fix |
| 22:38 |
v-rob |
Right |
| 22:39 |
v-rob |
Then, merging #10860 and #10861 in 10 minutes |
| 22:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/10860 -- Make hypertext and textarea have proper scroll event propagation by v-rob |
| 22:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/10861 -- Fix formspec list spacing by v-rob |
| 22:42 |
|
kilbith joined #minetest-dev |
| 23:24 |
|
kilbith_ joined #minetest-dev |
| 23:49 |
kilbith_ |
okay there's another bug with list styling |
| 23:50 |
kilbith_ |
v-rob? |
| 23:56 |
|
kilbith joined #minetest-dev |
| 23:57 |
kilbith |
#10862 |
| 23:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/10862 -- Slot size of >1 ignores height size |
