| Time |
Nick |
Message |
| 02:05 |
MTDiscord |
<mistere_123> You gie it to us, im sure we will find a use for it, its its no extra trouble |
| 02:05 |
MTDiscord |
<mistere_123> *give |
| 02:05 |
MTDiscord |
<mistere_123> *if |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:59 |
SingleDigitIq |
wen efficient minetest engine development? :> |
| 05:03 |
SingleDigitIq |
while a committee tries to agree upon like anything, every interesting pr inevitably goes stale, and how many times it happened when a part of core team agreed on something, and waited for the other part of the team and as a result pr was closed? |
| 05:03 |
SingleDigitIq |
decentralized governance is only good in very conservative systems, like finance. it does not work in space as rapidly advancing as gamedev, and even more than that, it does not work in software that is not mission critical. |
| 05:04 |
SingleDigitIq |
the best pr right now for this old code is a complete overhaul, how a committee will ever agree to merge a complete overhaul, how many man hours will that take? |
| 05:05 |
SingleDigitIq |
the size of core dev team dilutes incentives, nobody truly owns the code. the best path forward for minetest would be either celeron starts being the most active maintainer again, or gives away minetest to sfan completely |
| 05:08 |
SingleDigitIq |
a committee always struggles to make a decision. here is an idea a. but hey it comes with b side effect and c downside. oh okay, lets do nothing. of course every decision has a downside, there is a downside in sleeping too, does not mean its not required. centralized governance would advance this project much more rapidly, not all decisions would be perfect, but there will be decisions, prs will actually start to get merged |
| 05:08 |
SingleDigitIq |
also another thing about highest quality open source is to discourage prs as much as possible |
| 05:08 |
SingleDigitIq |
you guys just waste time reviewing random nonsense |
| 05:13 |
SingleDigitIq |
every. single. time. when anything high quality came out of open source it was one dev doing everything, not bothering with a committee opinion. minetest is not postgres, it's not mission critical, waiting for big tech employees to start contributing might never work |
| 05:29 |
Mantar |
fork it if you wanna, but more talking is not a solution to anything |
| 05:30 |
SingleDigitIq |
i am not just talking though |
| 05:31 |
SingleDigitIq |
just picturing it as is, a fresh perspective if you will |
| 06:09 |
MTDiscord |
<greenxenith> Yes, i'll have "Nonsense Takes" for 500, Alex. |
| 06:16 |
SingleDigitIq |
why are you laffin is it because i am dum? :< |
| 06:17 |
SingleDigitIq |
another way could be more hierarchy' clarity maybe? no centralized decision making = years of stagnation |
| 06:59 |
|
grorp joined #minetest-dev |
| 07:00 |
grorp |
due to unexpected events, I have Internet access again earlier than expected |
| 07:03 |
grorp |
Krock: re changelog: "punch with single tap" should be "punch with short tap", I got that wrong in the commit message |
| 07:08 |
grorp |
in the highlights section, you wrote about keyboard support on Android as a future improvement. that's actually been supported for a long time. the new thing is mouse support on Android. |
| 07:08 |
Krock |
that highlight section is from ruben but I'll adjust it too |
| 07:08 |
Krock |
thanks |
| 09:30 |
celeron55 |
SingleDigitIq: anyone in the core team can pick up the main lead, as long as they are appreciated by the community to do that. most people don't really want such a high workload and high stakes hobby, it's nicer to take a laid back approach |
| 09:33 |
celeron55 |
the governance is not decentralized because i want to force it to be. it's decentralized because it's so draining for anyone to try to act as an active dictator for a long stretch of time |
| 09:36 |
celeron55 |
anyway... |
| 09:37 |
celeron55 |
i like the idea of being able to create a texture with a static name and a dynamic content. conceptually just a simple layer of indirection (alias) from a freeform name to a dynamic name |
| 09:38 |
celeron55 |
and the reason for having that would be due to the simplification in memory management |
| 09:38 |
celeron55 |
no need to catch unused textures |
| 09:40 |
celeron55 |
by creating the alias, you allocate the texture, and from there on it's updated onto the same texture |
| 10:30 |
|
vampirefrog joined #minetest-dev |
| 10:35 |
MTDiscord |
<herowl> Well, so we're back to what MisterE suggested initially |
| 10:36 |
MTDiscord |
<herowl> Also another problem was mentioned, and I'll reiterate it: if you use any complex texture modifiers, especially [combine, any texture packs that change the resolution fall apart... or at least can't touch the stuff that is touched by those modifiers. |
| 11:33 |
celeron55 |
it could be fixed with new texture modifiers that are resolution independent, i.e. coordinates would be scaled to 0.0...1.0 or something |
| 11:33 |
celeron55 |
(and crucially coordinates would always be included in the modifier and not taken from the image) |
| 11:35 |
celeron55 |
overall the modifiers are a good idea with a wide range of uses. it's like a mini text based image editor, insanely powerful. but it's quite rough |
| 11:36 |
celeron55 |
mini text based parametric image editor, to be exact |
| 11:36 |
|
grorp joined #minetest-dev |
| 11:38 |
grorp |
could it be that we're closer to releasing than a month ago because issues/PRs have been removed from the milestone, not because any have been fixed/merged? |
| 11:38 |
grorp |
if so, why didn't we remove them a month ago? |
| 11:40 |
grorp |
also, why is the Android SDK version thing necessary for 5.9? shouldn't we be fine as long as we publish 5.9 before Aug 31? |
| 11:43 |
Krock |
some less important issues and PRs were either moved or removed from the milestone. |
| 11:45 |
Krock |
oh right. If we publish before that date, we should be fine. removing blocker. |
| 11:45 |
|
cranez joined #minetest-dev |
| 11:45 |
grorp |
yes, I'm just wondering why we didn't do this a month ago |
| 11:45 |
Krock |
thus it seems that the only remaining issue that needs fixing is #14886 |
| 11:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/14886 -- Attached sounds don't resume playing when objects come back into range |
| 11:46 |
Krock |
things kept popping up and were added to the milestone in those two months (I'm also partially responsible for that) |
| 11:46 |
Krock |
except that cleanups were slower than stuff getting re-added |
| 11:46 |
grorp |
me too |
| 11:47 |
grorp |
#14545 is a wontfix for 5.9, right? |
| 11:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/14545 -- SDL: Some keybinds broken due to missing character lookup |
| 11:48 |
Krock |
luckily there's still the regular devices(linux/win32) if SDL turns out to be stable enough |
| 11:48 |
Krock |
there's yet no approved PR so I don't think we can fix this without dragging the release even further |
| 11:49 |
grorp |
#14874 also doesn't really fix the issue at all, it just allows you to work around it |
| 11:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/14874 -- Allow keybindings with modifiers by y5nw |
| 11:49 |
grorp |
as far as I understand it |
| 11:50 |
grorp |
the question is: do we ship with the bug or do we revert to non-SDL by default? |
| 11:57 |
mtvisitor |
#14865 |
| 11:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/14865 -- Remove mod_translation_updater.py and move it to minetest/modtools by Zughy |
| 11:59 |
Krock |
grorp: unfortunately I don't know how well SDL works in general because I've always used the Irrlicht Linux device |
| 12:00 |
Krock |
for affected platforms, default=false would be an option, but we might be trading one issue for others |
| 12:04 |
|
Desour joined #minetest-dev |
| 12:34 |
|
grorp joined #minetest-dev |
| 12:35 |
MTDiscord |
<josiah_wi> Isn't switching the keymap to be position-based a feature change? That's not a bugfix. |
| 12:35 |
grorp |
the SDL device has no known bugs remaining except that one, I've used it for months now |
| 12:36 |
grorp |
josiah_wi: you're talking about #14874? |
| 12:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/14874 -- Allow keybindings with modifiers by y5nw |
| 12:37 |
MTDiscord |
<josiah_wi> No, I'm talking about the issue thread. What has to be done to get the correct key? Can we re-use that part of the Linux driver? |
| 12:38 |
MTDiscord |
<josiah_wi> Perhaps that PR is already the correct fix for the issue. It's hard to tell from reading the issue thread and the PR description whether it's a fix for the bug or not. |
| 12:38 |
grorp |
it isn't |
| 12:39 |
MTDiscord |
<josiah_wi> The issue made it sound like we aren't doing a key lookup but are instead using the position of the key to decide which key it is. |
| 12:40 |
grorp |
no, we're not using the position of the key. that would mean SDL scancode. |
| 12:40 |
MTDiscord |
<josiah_wi> I can confirm the expected behavior, which should be preserved in a bug fix, is to look up the key in the keymap. I use a Dvorak keyboard layout and I always have to remap my keys because WASD aren't in the same place. |
| 12:40 |
sfan5 |
13:50 <+grorp> the question is: do we ship with the bug or do we revert to non-SDL by default? |
| 12:40 |
sfan5 |
ship with the bug IMO |
| 12:41 |
grorp |
we're using the SDL keycode, which is the actual key but *without* modifiers applied. |
| 12:41 |
MTDiscord |
<josiah_wi> Ok, how is allowing keybindings with modifiers not a fix then? |
| 12:41 |
grorp |
the old Irrlicht devices do apply modifiers, the SDL device doesn't and that's the bug. |
| 12:42 |
grorp |
"This only provides a partial workaround for #14545 by allowing (also: requiring) users to use e.g. Shift-7 instead of / for keybindings." |
| 12:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/14545 -- SDL: Some keybinds broken due to missing character lookup |
| 12:43 |
Krock |
what we need is the printed character like in tex tinputs |
| 12:43 |
grorp |
which is the SDL keycode with modifiers applied, which will be possible to get with SDL3 |
| 12:43 |
Krock |
as for Shift+7 and '/': one should be equivalent to the other |
| 12:44 |
Krock |
(assuming the user's locale stays the same while using Minetest with their configuration) |
| 12:44 |
Krock |
how come text input does work properly, then? |
| 12:44 |
sfan5 |
i think the most likely fix is to hardcode mapping from shift+7 to '/' |
| 12:44 |
MTDiscord |
<josiah_wi> Part of the confusion for me must be that I can't type a / character by pressing shift-7 on my keyboard. |
| 12:45 |
sfan5 |
assuming we can somehow apply that to only the relevant layouts |
| 12:45 |
Krock |
@josiah_wi setxkbmap de |
| 12:45 |
grorp |
depends on keyboard layout of course. I posted this snippet as a response to josiah_wi's question. the PR doesn't fix the bug because the user has to bind the key combination manually, it doesn't work out of the box. |
| 12:47 |
grorp |
hmm, yeah, hardcoding the key combination could work as a temporary workaround for at least some common keyboard layouts. |
| 12:47 |
MTDiscord |
<josiah_wi> So what we'd like to do is to have the keybinding set to /, and for the user to be able to activate it by pressing shift+7 on a keyboard layout where that is the mapping for the '/' character? |
| 12:48 |
sfan5 |
yes |
| 12:48 |
grorp |
and that's also how it used to work |
| 12:48 |
sfan5 |
this doesn't affect people who can enter / with a single key press, it still works there |
| 12:48 |
grorp |
Krock: text input works correctly because it has a separate interface in SDL |
| 12:49 |
grorp |
poor erlehmann with his Neo2 keyboard, all of his keybindings will be broken by 5.9 |
| 12:51 |
MTDiscord |
<josiah_wi> I can think of two approaches to fix it. The first is to lookup the keypresses from the character, and store that internally as the keybinding (similar to the existing PR with an additional step), and the second is to convert the keypresses to a character and look that up in the keybinding map. |
| 12:51 |
MTDiscord |
<josiah_wi> Am I overlooking anything? |
| 12:52 |
Krock |
grorp: could we somehow abuse that, or is it limited to GUI elements? |
| 12:54 |
sfan5 |
we can't abuse text input for key input |
| 12:55 |
Krock |
:( |
| 12:55 |
grorp |
it's possible, but it's super ugly doesn't work very well. the SDL 1.2 compat implementation on top of SDL 2 does it for implementing the old "unicode" key event field. |
| 12:55 |
grorp |
+and |
| 12:57 |
grorp |
josiah_wi: I don't see how your suggestions would resolve the issue? from where do you get the modified keycode that depends on keyboard layout? |
| 12:58 |
MTDiscord |
<josiah_wi> An exhaustive search of the layout bindings. My first thoughts are that going from the keypresses to the character is much easier, since that's the way it normally works. |
| 12:59 |
MTDiscord |
<josiah_wi> SDL must do something like this for the text input that you said works like we want already, right? |
| 13:00 |
sfan5 |
not really? |
| 13:00 |
sfan5 |
sdl knows the character that a key press has produced, it just doesn't give this information to us |
| 13:01 |
MTDiscord |
<josiah_wi> Right, but it does some kind of lookup to determine which character that is. |
| 13:01 |
sfan5 |
the OS exposes that information |
| 13:01 |
MTDiscord |
<josiah_wi> And it sounds like the problem is that it doesn't have an API to provide that to us. |
| 13:02 |
MTDiscord |
<josiah_wi> So my question is, can we get the keypresses from SDL, and then ask the OS for the character? |
| 13:02 |
MTDiscord |
<josiah_wi> If the SDL API doesn't support the usecase we have to work around it, don't we? |
| 13:03 |
[MTMatrix] |
<grorp> the use case is supported in SDL 3 since a few weeks :) |
| 13:03 |
[MTMatrix] |
<grorp> actually, I wonder why they didn't notice the SDL 2 API was too limited when they wrote the SDL 1.2 compat layer and had to do such a huge hack |
| 13:03 |
sfan5 |
I don't think so |
| 13:03 |
sfan5 |
here's e.g. what win32 does https://github.com/minetest/minetest/blob/7625f88a0cafa846a0ea3cd7f9364a9dd7b1faa2/irr/src/CIrrDeviceWin32.cpp#L655-L659 |
| 13:03 |
sfan5 |
this isn't something you can just do behind SDL's back |
| 13:04 |
|
Desour joined #minetest-dev |
| 13:04 |
[MTMatrix] |
<grorp> not mentioning that not having to do platform-specific stuff like this is why we want to use SDL |
| 13:06 |
grorp |
*not to mention |
| 13:06 |
Desour |
and here's what our X11 backend does: https://github.com/minetest/minetest/blob/7625f88a0cafa846a0ea3cd7f9364a9dd7b1faa2/irr/src/CIrrDeviceLinux.cpp#L894 |
| 13:07 |
MTDiscord |
<josiah_wi> And we can't do this behind SDL's back as sfan puts it? |
| 13:10 |
MTDiscord |
<josiah_wi> Do we know of any correct way to fix it at all? I'm starting to see why it may be a lot of work. |
| 13:10 |
sfan5 |
the only correct fix is to use sdl3 |
| 13:11 |
grorp |
I have a working implementation of that |
| 13:11 |
MTDiscord |
<josiah_wi> I doubt we can require SDL3 though.. |
| 13:11 |
grorp |
yes, we'll have to wait. it's not even released yet. |
| 13:13 |
sfan5 |
https://discourse.libsdl.org/t/how-soon-will-the-first-stable-version-of-sdl3-be-released/46024/3 it will be a while... |
| 13:13 |
sfan5 |
in conclusion: |
| 13:13 |
sfan5 |
short term fix -> some hackery to map the right chars depending on layout/locale |
| 13:13 |
sfan5 |
medium term fix -> support both sdl2 and sdl3. encourage packagers to use sdl3 |
| 13:13 |
sfan5 |
long term fix -> require sdl3 |
| 13:16 |
Desour |
does SDL3 even allow doing what we do in X11? I didn't come to read up what things exactly they did to fix the issue. but it looks like they still just provide an enum keycode value. so how would we even recognize, if for example someone bound jumping to '€' on a default german layout? |
| 13:16 |
sfan5 |
I thought sdl3 simply started providing the character generated by a key press |
| 13:18 |
MTDiscord |
<josiah_wi> I am available all day to test on Windows if that's helpful. I'm also willing to try my hand at writing the code, but I have never used SDL/2 so I don't know the APIs. |
| 13:18 |
grorp |
basically you can now decide whether your keycodes should be affected by modifiers or not, or call a function to get them from scancodes manually if you want both. |
| 13:18 |
MTDiscord |
<josiah_wi> (I can test on Linux to, but I presume devs are more likely to be working on Linux.) |
| 13:18 |
grorp |
the SDL keycodes are not an enum, but can be any character |
| 13:19 |
MTDiscord |
<josiah_wi> too* |
| 13:19 |
grorp |
or special values corresponding to non-printable scancodes |
| 13:19 |
Desour |
ahh |
| 13:22 |
grorp |
> you can now decide whether your keycodes should be affected by modifiers or not |
| 13:23 |
grorp |
actually they removed that part again, just mentioning it for correctness |
| 13:23 |
Desour |
do you know by chance, if they accounted for non-default modifiers? |
| 13:25 |
[MTMatrix] |
<grorp> wdym? |
| 13:27 |
Desour |
for example, if someone uses a non-default scancode for shift. or if one adds a modifier, and other shenanigans |
| 13:29 |
[MTMatrix] |
<grorp> no idea. how would you do that? is that somehow possible in some operating system's settings? |
| 13:32 |
Desour |
I'm using xkbcomp with a custom .xkb file for my keyboard layout. IIRC, this article describes it well: https://wiki.archlinux.org/title/X_keyboard_extension?useskin=vector |
| 13:48 |
MTDiscord |
<josiah_wi> SDL2 has functions to convert from a keycode to a scancode and vice versa. |
| 13:50 |
MTDiscord |
<josiah_wi> I suppose the issue with these is that they don't take modifiers into account. |
| 13:50 |
Desour |
josiah_wi: yes, but in SDL3 they added the modifier argument |
| 13:57 |
Desour |
it looks like they have a hashmap for modifiers+scancode to keycode (aka char). looking at X11_UpdateKeymap in SDL, it seems like they populate this hashmap by looking up all scancodes for a fixed set of modifier combinations |
| 14:03 |
MTDiscord |
<mistere_123> How does one officially add a bug/feature bounty? |
| 14:05 |
MTDiscord |
<rollerozxa> announce it and tell someone to add the bounty label to the issue, I assume |
| 15:24 |
rubenwardy |
would be nice if android could compile faster |
| 15:48 |
rubenwardy |
how do you clear deps again |
| 15:48 |
rubenwardy |
I wish this was done automatically |
| 15:49 |
Krock |
figure it out and write a script |
| 15:51 |
sfan5 |
they're somewhere in the "native" folder |
| 15:52 |
rubenwardy |
I guess `rm -r native/deps native/build/deps.zip` |
| 15:53 |
[MTMatrix] |
<grorp> that's what I do, too |
| 16:06 |
MTDiscord |
<luatic> would like to push https://gist.github.com/appgurueu/55be8f09f26df31a8dc5722bceb4dc8f and merge #14872 and #14877 in 10m. |
| 16:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/14872 -- Clean up MSVC warnings in CIrrDeviceSDL.{h,cc} by JosiahWI |
| 16:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/14877 -- Improve fs::PathStartsWith to handle empty strings by asrelo |
| 16:07 |
MTDiscord |
<wsor4035> those both arent on the 5.9 milestone? |
| 16:08 |
MTDiscord |
<luatic> they are both relatively minor refactoring. is that considered not fine to merge during feature freeze? |
| 16:08 |
rubenwardy |
no, feature freeze includes unnecessary refactors |
| 16:08 |
MTDiscord |
<luatic> and the diff i want to push is to document the api that was used in game#3142 |
| 16:08 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/3142 -- Replace deprecated `get_metadata()` calls by Niklp09 |
| 16:08 |
rubenwardy |
it's fine if it's a bug fix though |
| 16:08 |
MTDiscord |
<luatic> rubenwardy: okay, will only push the doc thing then, if you consider that fine. |
| 16:09 |
rubenwardy |
fixing compiler warnings is argubly a bugfix |
| 16:14 |
MTDiscord |
<luatic> rubenwardy: alright, i'd push https://gist.github.com/appgurueu/55be8f09f26df31a8dc5722bceb4dc8f and merge #14872, is that fine by you? |
| 16:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/14872 -- Clean up MSVC warnings in CIrrDeviceSDL.{h,cc} by JosiahWI |
| 16:17 |
rubenwardy |
\o/ |
| 16:17 |
rubenwardy |
ok, cleared deps and I still see this https://rwdy.uk/276iR.jpg |
| 16:18 |
rubenwardy |
I could maybe try clean building again, but those two builds have already taken my battery down to 13% |
| 16:29 |
MTDiscord |
<luatic> merged the compiler warning fixes |
| 16:30 |
MTDiscord |
<luatic> pushed the doc fix |
| 16:33 |
Krock |
rubenwardy: do the buildbot binaries suffer from the same issue? |
| 16:37 |
sfan5 |
you mean the error text? |
| 16:37 |
sfan5 |
that looks just like the driver deciding to warn of performance issue at the highest log level |
| 16:38 |
sfan5 |
should disappear in release builds |
| 16:56 |
MTDiscord |
<josiah_wi> I would like to take on the keybinding issue. I'll see whether we can bundle SDL3's implementation, and if not I'll try making the appropriate system-dependent call. |
| 17:03 |
Desour |
josiah_wi: gl! maybe try to backport it to SDL2 (and ask the SDL ppl if they want that of course) |
| 17:04 |
Krock |
yes, I meant the error text. I assumed it was related to malfunctioning shaders |
| 17:05 |
Krock |
or deeper: unsupported pixel formats passed to OpenGL. but it does mention Performance, thus might not be too important |
| 17:36 |
sfan5 |
afbc is this btw https://www.arm.com/technologies/graphics-technologies/arm-frame-buffer-compression |
| 17:36 |
sfan5 |
never seen this being interacted with directly from GL |
| 17:58 |
MTDiscord |
<herowl> I guess GLES Android implementation does interact with it |
| 18:53 |
|
v-rob joined #minetest-dev |
| 18:55 |
v-rob |
I don't understand. Why _are_ we using SDL_Keycode? WASD is only WASD on QWERTY, but will be at some random set of positions on DVORAK or AZERTY or whatever. I thought the existence of scancodes was one of the major benefits of switching to SDL... |
| 18:57 |
Krock |
some are position-dependent, others have literal meanings, such as + and - |
| 18:57 |
Krock |
in the best case we'd have a system to accept both ways |
| 19:02 |
[MTMatrix] |
<grorp> exactly. we need both kinds of bindings. |
| 19:03 |
[MTMatrix] |
<grorp> but for now, reimplementing the old behavior is the most sane option. redoing the keybinding system on top of SDL only makes sense after we drop everything else. |
| 19:04 |
v-rob |
Most of them, like I, could be placed in a position near WASD (Tab, Q, or something) rather than I for Inventory. The main problems seem to be + - . / |
| 19:05 |
v-rob |
I don't know of any games that allow the user to choose either a keycode or a scancode. |
| 19:05 |
v-rob |
Unless the keycodes are hardcoded and scancodes are customizable, I guess. |
| 19:06 |
[MTMatrix] |
<grorp> we don't have to allow the user to choose between keycode and scancode, but we have to be able to choose for the default bindings. |
| 19:06 |
[MTMatrix] |
<grorp> if we want to switch to scancodes |
| 19:08 |
Desour |
>I don't know of any games that allow the user to choose either a keycode or a scancode. |
| 19:08 |
Desour |
we want to be better than other games |
| 19:09 |
rubenwardy |
I don't think it actually matters to the user, they can just press a key and the game shows that |
| 19:09 |
rubenwardy |
it matters more when shipping premade bindings to a large variety of user agents with different keyboard layouts |
| 19:10 |
rubenwardy |
keycode or scancode is technical information that the user doesn't care about. In a binding GUI, they just want to be able to press a key and use that |
| 19:15 |
v-rob |
I suppose that makes reasonable sense |
| 19:15 |
v-rob |
So you could have a scancode in minetest.conf, but in the GUI, that'd be translated to the corresponding keycode of the user's keyboard layout. |
| 19:20 |
rubenwardy |
yeah exactly, the user would see the label they see on their physical keyboard |
| 19:20 |
v-rob |
Although, we can't make any of the named keys, like I, be keycodes. Otherwise we could end up with conflicts, say if I appeared in the WASD area on some layout. |
| 19:20 |
v-rob |
Only keys with symbols would be safe enough to be keycodes |
| 19:24 |
MTDiscord |
<y5nw> v-rob: IMO that should be left to the user. You still can have keybinding conflicts when the user switches to a different layout after changing the controls |
| 19:25 |
MTDiscord |
<josiah_wi> f5nw, if you want to work on the keybinding issue, you are more than welcome to, since I know you have already done some work related to it and put up a pull request. |
| 19:26 |
v-rob |
I mean the default bindings. If I is a keycode by default and WASD are scancodes, then W and I would conflict in a hypothetical QIERTY layout |
| 19:26 |
MTDiscord |
<y5nw> Josiah: I would prefer first getting #14874 merged since that one also includes some minor refactoring that I don't want to duplicate across PRs |
| 19:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/14874 -- Allow keybindings with modifiers by y5nw |
| 19:27 |
sfan5 |
how does minecraft solve this? |
| 19:27 |
MTDiscord |
<josiah_wi> Could we get the refactoring in separately? |
| 19:27 |
MTDiscord |
<y5nw> Preferably not |
| 19:28 |
MTDiscord |
<josiah_wi> I understood that we are in feature freeze and only merging fixes. Your PR looks useful beyond mitigating the bug, but it is not a bugfix. |
| 19:28 |
|
y5nw joined #minetest-dev |
| 19:29 |
y5nw |
Right. Which is why I explicitly said that this is only a partial workaround for an issue. The bugfix label is added by Zughy |
| 19:29 |
v-rob |
Easy solution: Check if the keyboard is QWERTY, crash otherwise |
| 19:30 |
MTDiscord |
<josiah_wi> I expected that the fix would be done entirely on the Irrlicht side, is that not the case? |
| 19:30 |
y5nw |
This is mainly a SDL issue from what I read |
| 19:30 |
MTDiscord |
<josiah_wi> It's a limitation of the SDL API. |
| 19:31 |
MTDiscord |
<grorp> depends on what fix you're doing. the proper SDL3 fix doesn't involve changing MT code, yes. |
| 19:32 |
MTDiscord |
<josiah_wi> The API we need exists in SDL3 and my game plan is to first try to patch that into SDL2 (and can consider backporting to upstream SDL2 as grorp suggested). |
| 19:32 |
sfan5 |
uh |
| 19:32 |
sfan5 |
we can't "patch" sdl2. it's external to us |
| 19:32 |
MTDiscord |
<josiah_wi> Yeah, but we can do hacky stuff. |
| 19:32 |
Desour |
anyone can make a PR there though |
| 19:33 |
sfan5 |
even in the hypothetical scenario that SDL2 accepts this as a backport like 80% of users won't have the correct SDL version and never will |
| 19:33 |
sfan5 |
okay maybe a bit generous given we control the windows version |
| 19:33 |
MTDiscord |
<grorp> I think I didn't suggest the upstream thing, but it seems like a good suggestion |
| 19:34 |
MTDiscord |
<josiah_wi> Ah, sorry, Desour suggested it. |
| 19:34 |
Desour |
:) |
| 19:34 |
MTDiscord |
<josiah_wi> Agree it's a good suggestion, but as sfan says it's probably not a reliable short term fix. |
| 19:35 |
MTDiscord |
<grorp> sfan5: re MC: what specifically? |
| 19:35 |
Desour |
y5nw: 14874 only works with shift, ctrl and similar modifiers, right? it would be cool to be able to use arbitrary keys as modifiers |
| 19:35 |
y5nw |
Anyway, I would suggest labeling #14874 as a feature to reflect what it is. Whether/When this will be merged is something I do not want to interfere in too much (ideally not at all) |
| 19:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/14874 -- Allow keybindings with modifiers by y5nw |
| 19:35 |
Desour |
e.g. f toggles fly, shift+f toggles noclip |
| 19:35 |
y5nw |
Desour: yes |
| 19:36 |
y5nw |
Desour: well, it does not allow Alt- as a modifier either, but this is partly also an Irrlicht thing I have not yet looked into |
| 19:37 |
v-rob |
Oh wait: this keycode/scancode things still makes no sense. On a QWERTY, E is run, but on Dvorak, it's . That means run and CSM command conflict. |
| 19:37 |
Desour |
iirc, we have some getButtonPressed (or whatever it's called) API in minetest. you should be able use this to check arbitrary modifiers |
| 19:37 |
v-rob |
I don't think mixing keycodes and scancodes is a good solution |
| 19:38 |
MTDiscord |
<grorp> what else would you do? |
| 19:38 |
v-rob |
Scancodes only |
| 19:39 |
y5nw |
The thing about using specifically Shift/Ctrl as modifier is that it is a relatively low-hanging fruit in terms of keypress events, since you have these fields in SKeyInput |
| 19:39 |
Desour |
we could consider dropping the keysym binding feature, and just let players configure it instead |
| 19:39 |
v-rob |
Make + - and company be position-based, and let users remap those specifically. |
| 19:40 |
v-rob |
Also, what if Shift is sneak, and / is command on a layout where you have to use Shift? Then you have to sneak to use a command, which is a pain if you're flying. |
| 19:40 |
v-rob |
Character-based keycodes don't make much sense for in-game controls. Formspec controls, yes. In-game, no. |
| 19:40 |
y5nw |
Isn't that already the case pre-SDL though? |
| 19:40 |
v-rob |
But we can make it better post-SDL |
| 19:41 |
MTDiscord |
<josiah_wi> Did I hear a suggestion to drop the default keybindings and have the user configure it upon upgrade to 5.9? |
| 19:41 |
MTDiscord |
<josiah_wi> That crossed my mind as well. |
| 19:41 |
Desour |
with tts, you might have heard it c: |
| 19:42 |
MTDiscord |
<josiah_wi> Or with telepathy. |
| 19:42 |
Desour |
we could also make a pop up at the first minetest startup, to choose a common keyboard layout |
| 19:43 |
Desour |
so, the user choose AZERTY, for example, and then the mainmenu builtin binds the scancodes accordingly |
| 19:43 |
v-rob |
With a bit of research, Minecraft seems to either use scancodes, or detects the keyboard layout and converts scancodes to keycodes. |
| 19:43 |
y5nw |
I think SDL allows converting between scancodes and keycodes |
| 19:44 |
sfan5 |
is it usual that games totally mess up if you ever switch your keyboard layout, then? |
| 19:44 |
v-rob |
You would never have that with scancodes. You're guaranteed to have it happen with keycodes. |
| 19:44 |
v-rob |
What "most games" do is irrelevant if "most games" do it badly |
| 19:45 |
v-rob |
I don't think we should follow the crowd if the crowd uses keycodes |
| 19:45 |
Desour |
hm right, you could plug in a different input device. I guess we need key bindings per keyboard |
| 19:45 |
v-rob |
No please no. We could never maintain that |
| 19:46 |
MTDiscord |
<josiah_wi> My typical experience as a Dvorak user is that games don't handle keyboard layout switching well. I typically configure all my bindings by hand on any new game. |
| 19:46 |
sfan5 |
I mean this is not something we should support |
| 19:46 |
sfan5 |
just wondering |
| 19:46 |
Desour |
bind "A button held on keyboard 1337" + "B button pressed on keyboard 42" -> jump |
| 19:46 |
MTDiscord |
<josiah_wi> The open-source RTS Zero-K switched to scancodes I believe after previously using keycodes, and broke all my custom configuration. |
| 19:47 |
MTDiscord |
<josiah_wi> It was extremely annoying and I didn't bother to relearn everything. |
| 19:49 |
v-rob |
If we explicitly support each individual keyboard layout, we'd have plenty of "Issue #NNNNN: Default keybindings don't work on random keyboard layout used by 0.05% of the world" |
| 19:50 |
sfan5 |
what key would / on the us layout be on qwertz acutally? |
| 19:50 |
sfan5 |
- maybe? |
| 19:50 |
MTDiscord |
<josiah_wi> Hmm, we get the keyboard events from the PollEvent API, and they have both a keycode and a scancode. |
| 19:50 |
sfan5 |
then where do + and - go? |
| 19:50 |
celeron55 |
i would support Desour's plan of just giving a few options of default scancode mappings to initially for the user to set |
| 19:50 |
MTDiscord |
<josiah_wi> Is the keycode from the event wrong? |
| 19:51 |
celeron55 |
if the user is using something unusual, they know it and will be happy that they can just do it custom themselves |
| 19:51 |
celeron55 |
to map multiple keyboards differently... well, that sounds like mission impossible |
| 19:51 |
Desour |
josiah_wi: so, ask the user to let their cat run on the keyboard, so we can guess the layout :D |
| 19:52 |
MTDiscord |
<josiah_wi> Writing a new GUI sounds like a lot of work compared to this if this works. |
| 19:52 |
sfan5 |
if we include an USB driver in Minetest the OS won't be able to interfere anymore |
| 19:52 |
MTDiscord |
<josiah_wi> It sounds like a great idea, but maybe not for 5.9? |
| 19:53 |
celeron55 |
i definitely think mappings should be scancodes if at all possible. it's all too common to be let down by the key mapping functions of a game by not being able to map certain keys individually, or at all |
| 19:53 |
celeron55 |
or not being able to map certain combinations |
| 19:54 |
Desour |
for 5.9, how hard would it actually be to just ship the release with SDL and non-SDL (X11/win32/whatever) backend both compiled in, and add a setting? |
| 19:55 |
[MTMatrix] |
<grorp> let's not forget that the whole scancode thing is not relevant for 5.9 |
| 19:55 |
v-rob |
It's definitely true that we can't move to scancodes immediately. Irrlicht's KeyEvent still needs to include keycodes for the sake of formspecs. We would need to work like SDL, with both keycode and scancode available in each event. |
| 19:56 |
[MTMatrix] |
<grorp> josiah_wi: the keycode is not wrong, it's just "unmodified". |
| 19:56 |
Desour |
v-rob: what keycodes do formspec require, besides 'i'? |
| 19:57 |
v-rob |
Ctrl+X, Ctrl+C, Ctrl+V off the top of my head |
| 19:57 |
v-rob |
Those shouldn't be scancodes |
| 19:57 |
Desour |
ahh, I totally forgot those |
| 19:57 |
MTDiscord |
<luatic> idea for 5.10: keycodes as defaults, with the ability to override via scancodes? |
| 19:58 |
v-rob |
I think scancodes are better defaults. The most important thing is for WASD to be correct. If users have to remap / to something more sane, that's better than if WASD is scattered around the keyboard by default. |
| 19:58 |
celeron55 |
it's not horrible UX to press a button that doesn't normally produce /, to open up the chat with / pre-typed in it |
| 19:58 |
celeron55 |
it could even be preferable to some |
| 19:58 |
v-rob |
Once we transfer to SDL entirely, I suggest that we add an `SDL_Event SdlEvent` to `irr::SEvent`. That way we can slowly phase out Irrlicht's existing event system. |
| 19:59 |
|
dv^_^ joined #minetest-dev |
| 19:59 |
celeron55 |
it just isn't how MT has historically done it |
| 19:59 |
Desour |
v-rob: Ctrl+X / C / V should also be made rebindable, btw.. text editors also allow changing them, after all |
| 19:59 |
v-rob |
I'm already doing this in my in-progress UI API, at least for now. |
| 20:00 |
v-rob |
That is, using SDL_Event directly |
| 20:01 |
Desour |
v-rob: if it's an api for mods, don't let it mess around with the clipboard, as that can contain sensitive information |
| 20:01 |
v-rob |
Desour: Perhaps, but mods may add custom keybindings to formspecs if we ever get the equivalent of #8679 (which, incidentally, is stalled because of the lack of SDL keycodes and scancodes). |
| 20:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/8679 -- Add FormSpec key and mouse events by v-rob |
| 20:01 |
MTDiscord |
<josiah_wi> Does the EKEY_CODE irrlichtKey have to correspond to the modified key or the physical key? |
| 20:01 |
v-rob |
Keycode for compatibility with formspecs |
| 20:02 |
MTDiscord |
<josiah_wi> The modified keycode? |
| 20:02 |
y5nw |
josiah: With the current SDL event: the (unshifted) keycode |
| 20:03 |
MTDiscord |
<josiah_wi> Ok, I will leave it unmodified, and modify just the character. |
| 20:03 |
v-rob |
In the Win32 backend at least, pretty sure it corresponds to the shifted keycode, e.g. you can bind to & on QWERTY |
| 20:04 |
Desour |
for better terminology, I suggest using keysym instead of keycode. SDL keycodes are like unicode chars, but X11 keycodes are like scancodes |
| 20:04 |
v-rob |
But there may be some other shenanigans in Minetest's key handling somewhere that make this behavior possible. |
| 20:05 |
MTDiscord |
<josiah_wi> Thanks. So, to clarify, does the Irrlicht keycode correspond to the X11-type keycode or the keysym? |
| 20:05 |
v-rob |
Ah, yup, it's Minetest that gives that support, not Irrlicht: https://github.com/minetest/minetest/blob/master/src/client/keycode.cpp#L219 |
| 20:05 |
v-rob |
If we use scancodes, keycode.h/cpp can just die completely. |
| 20:06 |
MTDiscord |
<josiah_wi> Ok, looking at this again, I think I need both the Irrlicht Key and Char to correspond to the modified keysym. |
| 20:06 |
[MTMatrix] |
<grorp> I think KeyInput.Key is supposed to be unmodified |
| 20:07 |
[MTMatrix] |
<grorp> I don't know the X11 terms you mentioned |
| 20:07 |
v-rob |
It is unmodified, I was incorrect |
| 20:07 |
MTDiscord |
<josiah_wi> Ah, ok, that makes that simpler. |
| 20:07 |
MTDiscord |
<josiah_wi> Thanks. |
| 20:07 |
Desour |
josiah_wi: apparently scancodes, but system independent. so it's like X11 keycodes, I *think* |
| 20:07 |
MTDiscord |
<josiah_wi> That one is already correct, then. It's just the Char that's incorrect because the modifier isn't applied. |
| 20:08 |
[MTMatrix] |
<grorp> indeed |
| 20:10 |
v-rob |
Can I get a list of opinions? I know that myself and celeron55 are both in favor of scancodes only for in-game bindings. |
| 20:11 |
MTDiscord |
<josiah_wi> I'm too busy trying to fix this bug before the 5.9 release to say my opinion. (/s) |
| 20:11 |
v-rob |
(Note: We can't do scancodes for 5.9 in any case) |
| 20:13 |
Desour |
option 0: ignore the issue, and ship the bug. |
| 20:13 |
Desour |
option 1: release with USE_SDL2=0 |
| 20:14 |
Desour |
option 2: ship with SDL and X11, and let users choose via option (idk how feasible this is) |
| 20:14 |
Desour |
anything else that is realistic for 5.9.0? |
| 20:15 |
MTDiscord |
<luatic> option 3: workaround by manually turning shift + 7 specifically into / in our code? |
| 20:15 |
MTDiscord |
<wsor4035> seems like one of the goals of 5.9 was to use sdl2 on all platforms, so option 1 really seems not great tbh |
| 20:15 |
y5nw |
luatic: And how? |
| 20:15 |
v-rob |
Not option 1 |
| 20:15 |
Mantar |
shipping with a bug is also not great |
| 20:15 |
MTDiscord |
<luatic> i agree with not option 1 |
| 20:15 |
MTDiscord |
<luatic> imo 1 < 0 even |
| 20:15 |
Krock |
option 4: delay 5.9.0 for another month to perhaps find a PR that works |
| 20:16 |
Desour |
luatic: wouldn't this break QWERTY layouts? x) |
| 20:16 |
sfan5 |
https://github.com/minetest/minetest/issues/14171 I swear this is the worst ui issue with the mainmenu |
| 20:16 |
sfan5 |
spent three minutes searching for something that isn't there again |
| 20:16 |
Desour |
Krock: year* |
| 20:16 |
MTDiscord |
<luatic> Desour: wouldn't it be just a hidden feature, since / keeps working for them ;) |
| 20:17 |
Desour |
luatic: ah now I get what you suggested xD |
| 20:17 |
Desour |
yeah, nice hack |
| 20:17 |
v-rob |
Option 3 is feasible, since we know whether Shift is pressed via SEvent::KeyEvent |
| 20:18 |
MTDiscord |
<wsor4035> there is pr https://github.com/minetest/minetest/pull/14874 btw which is related |
| 20:18 |
v-rob |
Anyhow, I still would like to know opinions about scancodes/keysyms for in-game bindings in 5.10.0 or beyond |
| 20:19 |
Desour |
#14874 adds new syntax for the keybind settings. not a good idea in feature freeze |
| 20:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/14874 -- Allow keybindings with modifiers by y5nw |
| 20:19 |
Krock |
sfan5: (about the settings) showing up all dependencies recursively shouldn't be too difficult to implement |
| 20:19 |
[MTMatrix] |
<grorp> the hack approach seems insane but like the most feasible |
| 20:20 |
Krock |
I could have a look at that later on |
| 20:20 |
y5nw |
wsor: That was brought up already; but if the intention is to go for option 3 like luatic said and switch to scancodes then that largely makes said PR irrelevant |
| 20:21 |
[MTMatrix] |
<grorp> are there any other common key combinations except shift+7 we'd have to consider for hacky hardcoding? |
| 20:21 |
MTDiscord |
<luatic> relevant: #14681 |
| 20:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/14681 -- Fix shift for sdl by andriyndev |
| 20:21 |
y5nw |
(In fact, if 5.9.0 gets released soon then I would be more than happy to close that in favor of focusing more on my localization PRs) |
| 20:23 |
y5nw |
luatic: If the goal is to unconditionally convert Shift-7 to / then you can implement that quite trivially by adding an if clause to the KeyPress(SKeyInput) constructor |
| 20:28 |
v-rob |
Oh well. Seems nobody cares to give their opinion. |
| 20:29 |
MTDiscord |
<josiah_wi> I am in favor of going to scancodes. |
| 20:29 |
MTDiscord |
<josiah_wi> But I'm also not a core dev. |
| 20:29 |
MTDiscord |
<luatic> v-rob: i don't think i could contribute a well-informed opinion. but your proposal doesn't sound bad to me. |
| 20:29 |
[MTMatrix] |
<grorp> I'll think about it more before giving an opinion |
| 20:30 |
v-rob |
I mean, none of these opinions are final. Just wanted to know what the general opinion was. But thanks. |
| 20:31 |
v-rob |
Sorry, gotta go though |
| 20:31 |
pgimeno |
<v-rob> Also, what if Shift is sneak, and / is command on a layout where you have to use Shift? Then you have to sneak to use a command, which is a pain if you're flying. <--- Has happened to me all the time with all versions of Minetest. That's why I got used to use the keypad / even if it's uncomfortable. |
| 20:32 |
pgimeno |
<celeron55> it's not horrible UX to press a button that doesn't normally produce /, to open up the chat with / pre-typed in it |
| 20:32 |
pgimeno |
<celeron55> it could even be preferable to some |
| 20:32 |
pgimeno |
count me in on that one |
| 20:32 |
Desour |
v-rob: support for scancodes: of course; still being able to use keysyms: idk. would be an effort to maintain; other things: I want complex key-combination to action bindings (where actions include things like walking forward, copying text, and also loading config files). keysyms are no longer required from user perspective then anyways, so a layout based defaults chooser like suggest earlier would suffice imo |
| 20:32 |
sfan5 |
fresh bug #14893 |
| 20:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/14893 -- Settings: enabling flags does not work |
| 20:33 |
pgimeno |
my vote would be scancodes for keeping internal controls, and converting them to keysyms for UI display |
| 20:34 |
Desour |
for ui display there are scancode names |
| 20:34 |
Desour |
https://wiki.libsdl.org/SDL2/SDL_GetScancodeName |
| 20:34 |
y5nw |
These don't appear to be translated though |
| 20:34 |
pgimeno |
I mean something like this: https://love2d.org/wiki/love.keyboard.getKeyFromScancode |
| 20:35 |
pgimeno |
(love2d exposes both scancodes and keysyms as strings for its Lua API) |
| 20:36 |
Desour |
(but also displaying a keysym would of course be good. something like "ö" is more readable than "<AE08>") |
| 20:36 |
MTDiscord |
<josiah_wi> Going to take a break to make rhubarb muffins, but I have started working on an implementation. |
| 20:39 |
pgimeno |
the key to the right of . is / in an American keyboard, and - in a Spanish keyboard. The key to the right of 0 is - in an American keyboard, and ' in a Spanish keyboard. The key to the right of that one is = (+ if shifted) in an American keyboard, and ¡ in a Spanish keyboard. Yet I'd be very comfortable if the US "/" (Spanish "-") is defined to open chat and insert a "/", and US "-" and "=" (Spanish "'" and "¡") are defined as doing what - and |
| 20:39 |
pgimeno |
+ are supposed to do. |
| 20:40 |
|
grorp joined #minetest-dev |
| 20:41 |
pgimeno |
And if people don't like that, they can be redefined. The point is that they are defined as scancodes. |
| 20:41 |
grorp |
this would be the hack solution: https://github.com/grorp/minetest/commit/d139528dd6623c82b80047ce4747be151a445836 |
| 20:44 |
MTDiscord |
<luatic> sfan5: i have an idea where that's coming from |
| 20:47 |
MTDiscord |
<luatic> i might have a fix |
| 20:48 |
sfan5 |
that would be nice |
| 20:49 |
sfan5 |
free bug: the documentation doesn't say that games can contain a screenshot.png |
| 20:52 |
y5nw |
sfan5: Also: it might make sense to rename core.register_async_metatable to core.register_portable_metatable since this wasn't changed in #14369 |
| 20:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/14369 -- Try to preserve metatable when exchanging data with the async env by y5nw |
| 20:53 |
sfan5 |
I agree |
| 20:53 |
sfan5 |
do you want to make a PR to rename it and deprecate the old name? :) |
| 20:54 |
y5nw |
I'm not sure |
| 20:56 |
grorp |
josiah_wi: I'm sorry for stealing the thing you wanted to do, btw. I didn't think about that. |
| 20:58 |
|
v-rob joined #minetest-dev |
| 21:05 |
rubenwardy |
#14892 ready for review |
| 21:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/14892 -- Android SDK 34 by rubenwardy |
| 21:59 |
MTDiscord |
<josiah_wi> Grorp, I’d be relieved if you took this burden off me, but I’m not doing the hardcode hack thing. |
| 22:00 |
MTDiscord |
<josiah_wi> I’m attempting a legitimate fix. It’s hacky but it should restore the old behavior correctly for all cases. |
| 22:00 |
MTDiscord |
<mistere_123> could someone add the bounty label: https://github.com/minetest/minetest/issues/11640 |
| 22:01 |
sfan5 |
✅ |
| 22:01 |
MTDiscord |
<mistere_123> thanks sfan5 |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
