Time Nick Message 02:05 MTDiscord You gie it to us, im sure we will find a use for it, its its no extra trouble 02:05 MTDiscord *give 02:05 MTDiscord *if 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 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 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:35 MTDiscord Well, so we're back to what MisterE suggested initially 10:36 MTDiscord 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: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 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:35 MTDiscord 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 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 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 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 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 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 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 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 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 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 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 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 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 And it sounds like the problem is that it doesn't have an API to provide that to us. 13:02 MTDiscord So my question is, can we get the keypresses from SDL, and then ask the OS for the character? 13:02 MTDiscord If the SDL API doesn't support the usecase we have to work around it, don't we? 13:03 [MTMatrix] the use case is supported in SDL 3 since a few weeks :) 13:03 [MTMatrix] 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 [MTMatrix] 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 And we can't do this behind SDL's back as sfan puts it? 13:10 MTDiscord 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 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 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 (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 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] 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] 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 SDL2 has functions to convert from a keycode to a scancode and vice versa. 13:50 MTDiscord 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 How does one officially add a bug/feature bounty? 14:05 MTDiscord 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] that's what I do, too 16:06 MTDiscord 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 those both arent on the 5.9 milestone? 16:08 MTDiscord 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 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 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 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 merged the compiler warning fixes 16:30 MTDiscord 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 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 I guess GLES Android implementation does interact with it 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] exactly. we need both kinds of bindings. 19:03 [MTMatrix] 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] 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] 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 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 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 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 Could we get the refactoring in separately? 19:27 MTDiscord Preferably not 19:28 MTDiscord 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: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 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 It's a limitation of the SDL API. 19:31 MTDiscord depends on what fix you're doing. the proper SDL3 fix doesn't involve changing MT code, yes. 19:32 MTDiscord 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 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 I think I didn't suggest the upstream thing, but it seems like a good suggestion 19:34 MTDiscord Ah, sorry, Desour suggested it. 19:34 Desour :) 19:34 MTDiscord Agree it's a good suggestion, but as sfan says it's probably not a reliable short term fix. 19:35 MTDiscord 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 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 Did I hear a suggestion to drop the default keybindings and have the user configure it upon upgrade to 5.9? 19:41 MTDiscord That crossed my mind as well. 19:41 Desour with tts, you might have heard it c: 19:42 MTDiscord 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 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 The open-source RTS Zero-K switched to scancodes I believe after previously using keycodes, and broke all my custom configuration. 19:47 MTDiscord 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 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 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 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 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] 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] 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 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 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 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 The modified keycode? 20:02 y5nw josiah: With the current SDL event: the (unshifted) keycode 20:03 MTDiscord 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 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 Ok, looking at this again, I think I need both the Irrlicht Key and Char to correspond to the modified keysym. 20:06 [MTMatrix] I think KeyInput.Key is supposed to be unmodified 20:07 [MTMatrix] I don't know the X11 terms you mentioned 20:07 v-rob It is unmodified, I was incorrect 20:07 MTDiscord Ah, ok, that makes that simpler. 20:07 MTDiscord Thanks. 20:07 Desour josiah_wi: apparently scancodes, but system independent. so it's like X11 keycodes, I *think* 20:07 MTDiscord That one is already correct, then. It's just the Char that's incorrect because the modifier isn't applied. 20:08 [MTMatrix] 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 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 option 3: workaround by manually turning shift + 7 specifically into / in our code? 20:15 MTDiscord 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 i agree with not option 1 20:15 MTDiscord 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 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 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] 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] are there any other common key combinations except shift+7 we'd have to consider for hacky hardcoding? 20:21 MTDiscord 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 I am in favor of going to scancodes. 20:29 MTDiscord But I'm also not a core dev. 20:29 MTDiscord 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] 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 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 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 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 "") 20:36 MTDiscord 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: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 sfan5: i have an idea where that's coming from 20:47 MTDiscord 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. 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 Grorp, I’d be relieved if you took this burden off me, but I’m not doing the hardcode hack thing. 22:00 MTDiscord I’m attempting a legitimate fix. It’s hacky but it should restore the old behavior correctly for all cases. 22:00 MTDiscord could someone add the bounty label: https://github.com/minetest/minetest/issues/11640 22:01 sfan5 ✅ 22:01 MTDiscord thanks sfan5