Time Nick Message 00:25 MTDiscord When I compile with ASAN (Address Sanitizer set to Yes (/fsanitize=address)): 00:25 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1270538173247918181/errors.txt?ex=66b41061&is=66b2bee1&hm=48843540194a87d9d22f26dd27a743bb4571d23920dbe11c43d2811ba4d12af4& 01:26 MTDiscord Huh, think I can reproduce this with MSVC? 01:26 MTDiscord I was running a Release build of latest master with MSVC only last Saturday. 01:27 MTDiscord I see the words MSVC and Visual Studio together a lot, I think they're the same? 01:28 MTDiscord MSVC is the Visual Studio Compiler. But my build setup may be different, I have custom scripts. 02:00 MTDiscord I thought about this for a while and came up with one idea: corrupted vtable. 02:02 MTDiscord Doesn't seem to happen with RUN_IN_PLACE release builds 02:02 MTDiscord Sweet, that's a good tip. 02:26 MTDiscord @landarvargan 02:26 MTDiscord cmake add_compile_options("/fsanitize=address") add_link_options("/fsanitize=address") 02:26 MTDiscord to compile with ASan. Working for me so far. 02:26 MTDiscord Stick it in the top of the root CMakeLists.txt sometime after project(). 02:32 Noisytoot asan is not ubsan 02:32 MTDiscord Linker flag is unrecognized, and failed with "LINK : fatal error LNK1104: cannot open file 'clang_rt.asan_dynamic_runtime_thunk-x86_64.lib'" 02:32 MTDiscord We are aware, but it still might show something. 02:32 Noisytoot ubsan is -fsanitize=undefined 02:32 MTDiscord Yes, MSVC doesn't have that. 03:12 MTDiscord @Lars esp. and others, it would be good to have "global" entities. Such entities always exist until manually removed by the remove method. The server will never put it to sleep. get_staticdata is ignored. All players (well, taking into account the limited observers) can see/know about this entity, regardless of their view range, since part of the entity may still be in view for large entities. This would really simplify the 03:12 MTDiscord battle royale implementation/workarounds I have to perform where I attempt to achieve the same thing. 03:21 MTDiscord if devs agree I can make an issue 03:23 MTDiscord I agree 03:25 MTDiscord https://tenor.com/view/milhouse-simpsons-frisbee-lonely-loneliness-gif-22891693 08:37 MTDiscord I could definitely use that 13:11 sfan5 it looks like we aren't any closer to a solution to the keybinding issue than before 14:20 MTDiscord We are, considering we're more OK than before with not fixing it C: 14:20 MTDiscord MisterE: Not yet sure whether this is the best way to go, but sure, open an issue for further discussion. Better than to have the discussion scattered here in chat. 15:04 rubenwardy is the issue #14545 ? 15:04 ShadowBot https://github.com/minetest/minetest/issues/14545 -- SDL: Some keybinds broken due to missing character lookup 15:08 rubenwardy this issue was opened over a year ago, that would have been plenty of time for a proper fix 15:09 rubenwardy naive suggestion, could we add support for bindings based on text value just for this case 15:10 rubenwardy or hard code something just for slash 15:10 rubenwardy or does SDL2 fully separate key press and text entry values 15:10 sfan5 bindings based on text value is literally what we (want to) have and what is causing this issue 15:11 sfan5 there's no way with sdl2 to get the character that a key event has produced 15:12 rubenwardy could the game mode listen for / text entry instead of slash keypress? 15:12 rubenwardy oh wait 15:12 rubenwardy I remember - listening for text entry disables IME stuff 15:12 rubenwardy or something 15:14 rubenwardy so there's four options: don't fix, short term hack, longer term fix, disable SDL2 for 5.9 15:15 sfan5 indeed 15:15 rubenwardy if a short term hack doesn't luck possible, we might have to disable SDL2 for 5.9.0 and work on a longer term fix for 5.10 15:15 rubenwardy *look 15:15 sfan5 though with 4 the question is: what about 5.9? it's not like it magically solve itself 15:15 sfan5 5.10* 15:16 rubenwardy do you know what the longer term fix would be? 15:16 rubenwardy I guess if you can't get text value, you can't bind to the text of `/`. But with modifier support users could bind to shift+7 15:17 sfan5 yeah 15:17 nrz What was the issue prΓ©sent on 5.8 ? Can we move back to this behavior ? 15:17 rubenwardy 5.8 didn't use SDL2 15:18 rubenwardy it's a hack, but could we hardcode a case for shift+7 to trigger / 15:19 rubenwardy ah https://github.com/minetest/minetest/pull/14894/files 15:19 sfan5 fyi + and - are the next two obvious problems and I don't know if the same workaround applies there 15:26 [MTMatrix] 5th option for /: remove it 15:39 MTDiscord Likely something like, manually map all the different IME scan codes... 15:40 MTDiscord Then if a user has a new scan code combo, then we record that in some sort of key mapping input system. 15:46 rubenwardy could it be worth posting on SDL forums / irc to ask what they recommend? 15:47 sfan5 i bet the answer is "sdl3" 15:47 rubenwardy probably one of the answers but hopefully there's others 15:47 rubenwardy the API says there's `unicode` on keydown only, could that be remembered for keyup? 15:48 rubenwardy or does that not take modifiers into account 15:50 rubenwardy great, pausing MT in a debugger causes my cursor to not be visible when in other windows 15:51 MTDiscord rubenwardy: SDL's key events no longer have a unicode field 15:51 rubenwardy ah great 15:51 rubenwardy I guess that's what the `unused` field is 15:54 rubenwardy The SDL docs says that textinput default to ON on desktop. What's the disadvantage of doing this and not calling SDL_StopTextInput on desktop? I guess it messes with IME software? 15:55 rubenwardy https://wiki.libsdl.org/SDL2/SDL_StartTextInput 15:56 y5nw Yes, it messed with IME 15:57 y5nw Also it seems like I get a constant 0x7026 for the unused field when the key is pressed down and 0x0 when the key is released 15:59 y5nw Nevermind, the value of the unused field seems to change when you run it again, but stays constant throughout the session 15:59 rubenwardy is there a way of working around the IME issue? For example, SDL_HINT_IME_SHOW_UI = false 16:00 y5nw I bet that is for when we handle preedit ourselves (and don't need the candidate window) 16:00 rubenwardy yeah I was thinking the same 16:01 rubenwardy Well, certainly a tricky one 16:02 rubenwardy it's kind of funny how it's the opposite to gamepads. With Irrlicht, we have no idea what gamepad button is what but with SDL we do 16:02 Noisytoot removing / is the worst possible option 16:03 Noisytoot I always use / (and .) when typing commands 16:03 rubenwardy Can we tell if IME is installed? 16:03 rubenwardy if so, could only SDL_StopTextInput then 16:04 y5nw You might be able to put in an IME check on X11 by checking the XMODIFIERS variable 16:06 rubenwardy sorry I'm just throwing ideas at the sink 16:08 rubenwardy So #14874 makes it possible to bind to shift+7. Could we ship with support for multiple layouts? Either by detecting the layout or including multiple bindings 16:08 ShadowBot https://github.com/minetest/minetest/issues/14874 -- Allow keybindings with modifiers by y5nw 16:08 rubenwardy Looks like + = shift+= and - = shift+6 on AZERTY 16:08 MTDiscord Yep that's an option, handle IME ourselves 16:08 rubenwardy https://gist.github.com/g2p/8597984 16:09 y5nw The problem with my PR is that it doesn't (and IMO: shouldn't) handle layouts, and I'm increasingly leaning toward using scancodes for keybindings 16:11 y5nw "doesn't" in that the behavior for keycodes remains the same in terms of letting the Irrlicht device handle keyboard layout switching. "Shouldn't" in the sense that this can get weird with IMEs 16:12 [MTMatrix] a problem to consider is that we'll probably break user keybinding configurations twice: one time in 5.9 by switching to SDL and another time in a later release by switching to scancodes 16:13 y5nw ("Shouldn't" less in terms of IMEs actually. More in terms of not adding unnecessary complexity IMO) 16:13 rubenwardy So with scancodes, you'd bind to the key that is / in a QWERTY keyboard but may be something else in other keyboards? 16:13 y5nw rubenwardy: exactly 16:14 [MTMatrix] but it's obviously more useful for WASD than for / 16:14 y5nw so the / key is then always the key left of the Right Shift key regardless of the keyboard layout 16:14 rubenwardy yeah 16:15 [MTMatrix] if we actually want to switch to scancodes (do we?), maybe it would make sense to bundle the breakage 16:17 rubenwardy does playing on other keyboard layouts already require rebinding the layout? I assume so as WASD would be broken 16:17 y5nw A thing to note for scancodes is that it will also be applied to modifier keys, so it breaks e.g. ctrl:swapcaps. I would assume that is easy/easier to work around though 16:33 rubenwardy ok so we're no closer after all that 16:34 y5nw It seems like you can work around that problem by using keycodes for modifier keys and scancodes for other keys (the .mod field is based on keycodes apparently) 16:35 rubenwardy sounds good 16:35 rubenwardy how much work is scancode support? 16:36 MTDiscord if they ask for SDL3, is this a big change for us ? what would be the blocker ? (appart we are in freeze, but we can imagine put efforts in it ?) 16:36 y5nw That's the hard part. We would still need keycodes for e.g. ^C and ^V so we would need to extend the KeyPress class to include both scancodes and keycodes (and the associated complications from that, e.g. comparison and matching) 16:37 rubenwardy @nrz0: SDL3 isn't even released yet 16:37 MTDiscord then they should not tell us to use it πŸ˜„ 16:37 MTDiscord isn't there is other games using SDL2 we can check code ? 16:37 [MTMatrix] The KeyPress class is a MT thing and not involved in GUI shortcuts at all afaik 16:38 y5nw Oops. I meant SKeyEvent from Irrlicht 16:38 MTDiscord There must be something, and I bet they rely on scancodes 16:39 y5nw (That would be easier though. KeyPress would then be fully based on scancodes with the exception of modifier keys using keycodes) 16:39 MTDiscord Wait, is there a problem at all? Haven't tested yet, but don't situations that could require ^C or ^V for copy/paste also enable text input which then sends it properly? 16:40 y5nw ^C and ^V are apparently sent by SDL even with text input enabled 16:40 MTDiscord Yeah, and? 16:41 MTDiscord They aren't when it is disabled, and should when it is enabled, right? 16:42 [MTMatrix] ^C and ^V do not depend on textinput. keycodes are enough for them. 16:43 [MTMatrix] I mean keycodes suffice to implement them 16:43 rubenwardy Next week, we will have been in feature freeze for 2 months. Which feels like a record 16:44 rubenwardy If there's no end in sight, my vote is for releasing 5.9 without SDL2 and working on scancodes/modifiers for 5.10 16:46 rubenwardy we could disable SDL2 on desktop platforms and keep it for Android 16:50 celeron55 that seems like an ok option to me as long as it seems there's a viable feature set that can be added that will make sdl2 keybinds acceptable for 5.10 16:53 celeron55 the things to add would probably be modifiers and trying to migrate the old default keys for multiple common keyboard layouts 16:53 rubenwardy It doesn't look like it's possible to use text entry here, so we'll have to switch to scancodes and always use the key next to the right shift 16:53 jonadab I expect it may always be possible for an IME to much things up for games, especially if it's the kind that's intended to require multiple keypresses for anything at all to happen (e.g, Anthy). 16:54 rubenwardy the user can always rebind it to their actual / key 16:56 celeron55 i'm doubtful of users appreciating just getting it to that point where it's possible to rebind / as modifier+scancode but not to automatically migrate old keybinds to that, but at least it's on the same path 16:56 rubenwardy well better to break bindings once than multiple releases in a row 16:57 celeron55 i definitely agree with that 16:57 rubenwardy we could add support for modifiers now and ask users to rebind / if needed 16:57 rubenwardy but then bindings would break again with scancodes 17:05 MTDiscord So scan codes only and force rebinds in 5.10? 17:07 Mantar What all does SDL get us on desktop that you'd need to break keybinds on 5.9.0 release instead of disable it until it's fixed? 17:08 celeron55 (unrelated: i invited cx384 to the core team on github now) 17:08 celeron55 maybe if better controller support also got into 5.10 (or whatever the "SDL2 release" ends up being), it would make people allow some keybinding hurdle 17:48 rubenwardy Too much to do, too little time 17:54 celeron55 that's life in a nutshell 17:57 MTDiscord rubenwardy the link on the announcement on the forum (https://dev.minetest.net/Changelog#5.8.0_.E2.86.92_5.9.0) doesn't load 17:58 rubenwardy Not sure why you're pinging me about celeron55's machine being slow πŸ˜‚ 17:59 rubenwardy It loads after a while for me 18:01 celeron55 it loaded fast previously 18:01 celeron55 let's see if it fixes itself 8) 18:02 celeron55 looks like the forum works fine-ish, but both wikis are essentially down 18:06 MTDiscord sorry ruben, it's because i read your announcement , but yeah it was for c55 πŸ˜„ 20:13 sfan5 sooo 20:13 sfan5 what will be the solution for 5.9.0? 20:16 Mantar Is there any reason not to just disable SDL on desktop and only enable it for Android? 20:17 celeron55 (that link does work now) 20:17 sfan5 Mantar: possible 20:18 celeron55 is the only practical downside that touchscreen input isn't available on desktop builds without SDL? 20:19 sfan5 we also lose native wayland support on linux 20:19 celeron55 touchscreen support on desktop is definitely something a few people have been asking, but it's a minority 20:19 sfan5 (but neither of those were in 5.8 so it's not actually a downgrade) 20:20 celeron55 the reasons for sdl will continue building up, but so far the list is not long 20:21 celeron55 the biggest risk is that not making releases with SDL will make people wary of making contributions using SDL, so the features will never build up like they could 20:21 celeron55 that's why it's not wise to hold on to irrlicht for long 20:21 Mantar Disabling it on desktop until 5.10 was rubenwardy's suggestion, and it seems like the sensible choice to me 20:22 Mantar anybody who wants to work on/test SDL stuff can enable it in their compile for the time being, and deal with any busted keys 20:23 sfan5 small note that with the "release train" methodology we're looking at "delay it until the next release" is not valid 20:23 sfan5 because we won't be wanting to delay 5.10 due to this 20:23 sfan5 it becomes more of a "delay it until ready" 20:23 celeron55 yes it's not wise to set it for 5.10. if it's not now, then it's just some unknown future release 20:23 rubenwardy yeah ofc 20:24 Mantar true, I was not suggesting putting it into a 5.10 milestone, just saying it sounds like people have ideas on how to fix it that will probably be ready by then 21:44 MTDiscord IMHO test in production and collect actual regressions and use cases 22:00 MTDiscord when minetest will be renamed into excavation experiment already?πŸ˜• 22:00 sfan5 soon 22:00 MTDiscord πŸ”₯ 22:01 MTDiscord digging trial is also good, but excavation experiment is more elaborate :> 22:02 Mantar call it gnu/minecraft 22:03 MTDiscord call it Antelope Excavation Tinkering 22:03 MTDiscord (the above but more elaborate) 23:29 pgimeno I don't know what the decision on workflow was, but if the one I proposed is adopted, I wanted to note that you have to think two versions ahead. With that workflow, the scancodes patch can't go into 5.10 unless it's ready by the time 5.9 is released, which seems extremely unlikely. It would be for 5.11. 23:31 pgimeno I'm mentioning it because rubenwardy put much emphasis on getting scancodes on 5.10, and because I'm in the dark about what the decision about workflow is. 23:54 Mantar way I see it, you can fast-track bugfixes in any workflow