Time Nick Message 00:16 MTDiscord yeah, and? 00:16 MTDiscord read the titles 00:32 erle Jonathon each PR references the other one as alternative. so i suspect one of them was merged by mistake, i just do not know which one. 00:38 MTDiscord or one fixed the docs, and the other added support for css level 4 00:38 MTDiscord ya know, reading the titles 01:25 steveamr Hi 01:25 steveamr How in minetest can my name is irc 07:55 MTDiscord wsor: why would you merge one to fix the docs and then one to un-fix them to their previous state 07:56 MTDiscord oh, the support one also modifies the docs 07:56 MTDiscord so it's just redundant 07:56 MTDiscord no worries then :p 08:32 MTDiscord erle: merging the level 4 PR would have made the level 3 PR obsolete 08:33 MTDiscord other way around is not quite the case though: merging the level 3 PR just turned the level 4 PR from a bugfix PR into a feature PR 09:17 sfan5 I represent the opinion that rebeccapurple is not an essential color for use within Minetest and this PR should not have been merged 10:24 rubenwardy the feature isn't rebeccapurple, the feature is supporting CSS color module level 4 11:12 erle i agree with sfan5 here. the only practical thing this is achieving will be that rebeccapurple-using mods do not work in older versions. then again, it will be a while before anyone uses it ig. 11:15 MTDiscord By that logic we should never add any new features ever 11:43 rubenwardy If someone made a PR to add rebbecapurple, I wouldn't have accepted it either - however, supporting the latest version of a standard is the feature here 11:44 erle the only change in there is adding rebeccapurple though 11:44 rubenwardy means that it's an easy change 11:45 erle well, what has done has been done. i just wanted to make sure it was not a communications fuckup. 11:45 erle because it sure looked like one at first glance. 11:51 HuguesRoss If I were in charge of the project from day one, I wouldn't try to support a CSS standard in a game engine. But it has claimed support since 2014 (813c088c1c66df45731c9015248b22d55e694c76), so the least we can do is keep that support up-to-date 11:58 HuguesRoss Re #8679, given the scope I generally agree that a test package would be useful to help modders test the new functionality. I don't have the necessary setup to do that on my end though, is there any established process for releasing dev-builds to be tested? I know sfan5 does this occasionally 11:58 ShadowBot https://github.com/minetest/minetest/issues/8679 -- Add FormSpec key and mouse events by v-rob 12:09 MTDiscord well back when the scoped android storage in 5.4.2 was being developed ruben put prebuilt android packages in the related PR and pointed people to it in order for it to be tested on a wide range of devices 12:10 rubenwardy GitHub and GitLab both make Windows builds 12:10 rubenwardy the official builds are built by sfan5 though 12:19 erle i can test on thinkpad t60, thinkpad x390, reform1 and reform2. but i need something that is largely automated and a checklist for testing. i won't do a thing if the testing instructions are “just play around”. 12:22 MTDiscord I guess an example mod could be necessary for the testing as well 12:29 HuguesRoss erle: that's the issue here--it's a fairly major addition to the API, and one that directly interacts with both the network and player input so *the only viable way to test* is via modding and manual testing. It's not something you can meaningfully checklist 12:29 HuguesRoss That's part of why figuring out how to test the feature has taken me so long 14:14 paradust Can I get a sanity check on... https://github.com/minetest/minetest/issues/12242 14:14 paradust I haven't written any code yet, but I'm curious if this would be pullable as is, or if I should consider doing something else 14:35 sfan5 did you try to measure the performance impact of the current way? 14:42 paradust only via profiling. I see ClientEnvironment:addActiveObject spends about 40% of its time in the logging code 14:43 paradust Most of that is in strftime. Which could be an emscripten-specific deficit, to be fair. 14:45 celeron55 i think that definitely does make sense 14:46 celeron55 not sure about the implementation, but the problem does exist 14:48 celeron55 it's not good to encourage people to leave out useful logging just because it causes a performance impact when disabled 14:49 celeron55 and it will be always so that at least mutexes can have very different performance impacts on different systems, even if everything else can be optimized 14:49 sfan5 paradust: I imagine time() and localtime() have very different performance characteristics on emscripten 14:54 paradust yes, quite a bit slower than a native syscall, since it has to go through the browser 14:55 paradust I also noticed there's still a race in StringBuffer::overflow. In the rare case that multiple threads are both outputting to the same stream, it could overrun the buffer by a byte or two 14:56 paradust Making the stream (and thus the buffer) thread-local would fix that incidentally 15:20 erle HuguesRoss, especially huge things need a checklist. you can look at mineclonia PRs to see how I do it – often I make a test mod or test code and integrate that into the checklist. 15:22 erle paradust how did you measure the 40%? 15:23 erle as i said before, i only use cachegrind and that turns it slooooooow 15:23 HuguesRoss erle: Do you have an example of relevant complexity and scope? I'm not really keen on digging through PRs I don't know to try and locate one 15:25 paradust erle: Chrome/Firefox both have built-in tools to profile js/wasm. It collects samples and aggregates them. 15:25 erle HuguesRoss this is the kind of testing strictness i mean – all possible interactions we could come up with were listed and verified. it contains no testing mod though. https://git.minetest.land/Mineclonia/Mineclonia/pulls/285 15:27 erle HuguesRoss i bet v-rob[m] can come up with this kind of list. if so, i'd try to work through it on every platform. after making sure i can't come up with more steps. 15:28 HuguesRoss Well, I can only wish him good luck 15:28 erle HuguesRoss i must admit, given what i sent you i do not understand why you think checklists may not be useful here. 15:29 erle here, as in, for #8679 15:29 ShadowBot https://github.com/minetest/minetest/issues/8679 -- Add FormSpec key and mouse events by v-rob 15:29 HuguesRoss Because the number of potential interactions is large enough that listing them all--let alone testing them all--is unrealistic 15:29 MTDiscord I'm considering making a couple 2D arcade games using this 15:29 MTDiscord like Snake 15:30 MTDiscord For testing purposes, just displaying the events would presumably be a decent start 15:30 erle HuguesRoss you don't need to list them all. you only need to test one instance of each class. 15:30 HuguesRoss "you only need to test one instance of each class." This tells me that you either have not read the code, or do not know as much about testing as you think 15:30 erle HuguesRoss for example, we did not test all ways to spawn a snow golem in the pumpkin patch PR. we tested one way, to ensure it still works. 15:31 erle well, i am usually a fan of “test everything”. but almost everyone else is not. so i am willing to compromise :P 15:31 MTDiscord HuguessRoss: Class is not meant as in code I believe 15:31 erle regardless, even an incomplete list is usefull 15:31 HuguesRoss hm 15:31 MTDiscord But rather "class of problems" 15:31 erle class as in class of problem 15:31 erle yeah what luatic saysn 15:31 MTDiscord erle: your intensive testing sacrifices the holy agility 15:32 MTDiscord :P 15:32 MTDiscord just test in production 15:32 MTDiscord nothing can go wrong™️ 15:32 MTDiscord bruh moment 15:32 MTDiscord everything will go wrong 15:33 erle luatic people keep saying that, but in the end testing is RARELY more effort than writing the code. it's just that a lot of people rather tinker 4 hours with the code than spend 20 minutes on coming up with a test plan and 40 minutes on executing it. 15:33 erle i have learned that even an incomplete list of manual (i.e. not possible to automate) test cases is invaluable to find bugs. just don't pretend you'll find them all as long as your list is incomplete. 15:33 HuguesRoss My concern here is still that there's a lot of potential classes of problem that will be difficult to test. For instance--does scroll event behavior vary by hardware? 15:34 erle yes, that's a thing you can and should test. 15:34 HuguesRoss Well, I can't 15:34 erle you don't need to specify the outcome of the test 15:34 HuguesRoss I have one mouse 15:34 HuguesRoss Maybe the community can! But there's no guarantee they will, or that they have all relevant options 15:34 erle i have no mouse, but 2 computers with trackballs and 2 with touchpads. seems we are well equipped together to figure it out. 15:35 erle as i said, even an incomplete list helps. 15:35 MTDiscord :P 15:35 MTDiscord Now how do you want to test this? 15:35 MTDiscord Rotate the scrollwheel by 1cm? 15:35 erle there is no scrollwheel on a trackball hehe 15:35 MTDiscord Also you'd first have to normalize sensitivity settings 15:37 HuguesRoss Oh yeah also--how does the rate at which mice report movement events affect this? Because I know some programs that can lag out depending on the mouse being used 15:38 HuguesRoss Then there's probably a bevy of potential interesting situations that can occur on the network. How reliable does this need to be? Do we guarantee event order? 15:38 HuguesRoss etc 16:21 erle minetest actually does already have mouse lag in formspecs 16:21 erle i am not sure if anyone is aware of that 16:21 erle but it is possible to click the mouse, then move it and have the movement happen before the click 16:21 erle if you do it in inventory formspec, you pick up the wrong item 16:21 erle which is infuriating 16:23 Pexin erle: is THAT what's been happening 16:23 Pexin I thought I just had cold stiff fingers 16:36 Krock will merge #12228 #12230 #12232 #12221 in 15 minutes 16:36 ShadowBot https://github.com/minetest/minetest/issues/12228 -- DevTest: Fix armorball sprite by Wuzzy2 16:36 ShadowBot https://github.com/minetest/minetest/issues/12230 -- Show unknown node in debug screen by Wuzzy2 16:36 ShadowBot https://github.com/minetest/minetest/issues/12232 -- Remove HW_buffer_counter after irrlichmt fix to remove HWBufferMap by paradust7 16:36 ShadowBot https://github.com/minetest/minetest/issues/12221 -- Refactor local time retrieval by Oblomov 16:41 MTDiscord Krock: did you forget to add the "two approvals" tag on #12228 ? 16:41 ShadowBot https://github.com/minetest/minetest/issues/12228 -- DevTest: Fix armorball sprite by Wuzzy2 16:50 Krock @luatic I added trivial instead 16:50 Krock whatever I could approve it if you insist 16:51 MTDiscord Krock: then please mark #12239 as trivial too :) 16:51 ShadowBot https://github.com/minetest/minetest/issues/12239 -- Docs: Recommend entity.name by appgurueu 16:54 Krock question is whether .name is supposed to be a reliable indicator 16:54 Krock i.e. one that's supposed to work forever 17:04 erle Krock, since you merged #12221 you can close #12080 with a message that it is unnecessary? 17:04 ShadowBot https://github.com/minetest/minetest/issues/12221 -- Refactor local time retrieval by Oblomov 17:04 ShadowBot https://github.com/minetest/minetest/issues/12080 -- WIP: Do not stat /etc/localtime all the time by erlehmann 17:05 erle oblomov has improved my solution after all 17:05 erle i.e. my thing is not needed 17:05 erle hmm, i can close it myself i think 17:34 sfan5 you can indeed close your own PRs 17:34 sfan5 HuguesRoss: if you want a windows build for the formspec thingy just ping me 17:36 HuguesRoss sfan5: Yeah I think we should make one and try to get more active modders to try the feature. Whatever testing we do on our end, having more real uses to look at would be helpful 17:38 HuguesRoss I think at this point we know we want this, it's roadmap-tagged... so the question is more one of whether or not the implementation needs work 17:43 sfan5 it'd be nice if someone else could give irr#99 a test run 17:43 ShadowBot https://github.com/minetest/irrlicht/issues/99 -- Replace HWBufferMap with a list and back pointers by paradust7 17:43 sfan5 merging #12234 in 10m 17:43 ShadowBot https://github.com/minetest/minetest/issues/12234 -- [NO SQUASH] Auth-related fixes by sfan5 17:52 sfan5 HuguesRoss: https://kitsunemimi.pw/tmp/minetest-5.6.0-dd788a8-pr8679-win64.zip 17:53 HuguesRoss Thanks 18:03 sfan5 I browsed through the just pushed commit and found a bug 18:03 sfan5 damnit 18:05 sfan5 force pushing master.... 18:06 rubenwardy great, GitHub still resets PR last_updated when you force push to master 18:07 sfan5 you're welcome 18:07 rubenwardy :D 18:09 sfan5 guess I'm making a PR to enable additional warning flags next 18:16 sfan5 my local build is somehow devoid of any warning flags 18:16 sfan5 wat 18:22 erle > I browsed through the just pushed commit and found a bug 18:23 erle which one? 18:23 erle (and what is the bug? i'm curious) 18:25 sfan5 during refactoring I merged two functions into one and added an extra argument, the argument was unused instead of doing what it used to 18:37 sfan5 the compiler could have warned me about it with -Wunused-parameter but we have lots of trivial stubs that would then throw a warning, unfortunate 18:43 erle well, ig apart from the missing warning it was unfortunate. you did have a review after all. 18:43 erle is it possible to annotate the stubs so that -Wunused-parameter does not nag? 18:44 erle ah, found it https://github.com/minetest/minetest/commit/ef19219992223a629ec1d2b8ef196039867059bb vs https://github.com/minetest/minetest/commit/a65f6f07f3a5601207b790edcc8cc945133112f7 right? 18:57 MTDiscord sfan5: I take your comment as https://github.com/minetest/minetest/pull/12241#discussion_r861167203 I should remove the client Lua code? 18:58 sfan5 it's a mere suggestion, maybe someone else has a different opinion 18:58 sfan5 erle: it is possible to annotate stubs but that misses the point 18:58 sfan5 a warning flag would be useful if it only warned for methods that contain "real" content 19:00 MTDiscord anyways sfan5, would you take another look 19:00 MTDiscord I've now created a single default object 19:01 MTDiscord to void any and all performance concerns (not that they could've been justified in the first place) ;) 19:18 v-rob In terms of #8679, I don't think mice are terribly important to test thoroughly--after all, if one mouse reports faster mousewheel events than another, it's not too bad, since the users of those mice are probably used to it. The mousepad on my laptop, for instance, reports floating point values, giving very fine-grained scrolling, and if you swipe really fast and let go, it continues scrolling in a decelerative manner. The wheel on my mouse, on the 19:18 v-rob other hand, only scrolls in increments of three, and the mouse itself only moves two pixels at a time, never one. Modders just have to be prepared for slight differences. 19:18 ShadowBot https://github.com/minetest/minetest/issues/8679 -- Add FormSpec key and mouse events by v-rob 19:18 v-rob Mainly, the mouse testing should focus on whether mice work rather than whether they give consistent results. 19:18 v-rob Keyboards are a bigger issue, since it's very important that keyboard results are consistent. Mainly, I'm concerned about the OEM keys and whether they're consistent across platforms. 19:19 v-rob I suspect that SDL may have code to make OEM keys consistent across keyboard, since it has no generic "OEM" enum values, whereas Irrlicht does. 19:19 v-rob Since I'm an English speaker on a QWERTY keyboard, it all works fine for me. However, it needs to be tested by other people, ideally with diverse languages. 19:19 v-rob I don't know of any better way to test that than to print the keycode to the screen and say "hey, does this match the key on your keyboard?" 19:21 erle Mainly, the mouse testing should focus on whether mice work rather than whether they give consistent results. 19:21 v-rob The easy alternative is to only send keys like a-z, 0-9, shift, control, etc. that we _know_ are safe to send, and avoid quote marks, semicolons, and whatever. But that still doesn't solve the problem of testing to make sure my refactor of KeyPress didn't break anything. 19:21 erle v-rob this is why i want to test scrolling with touchpads and trackpads 19:23 sfan5 free PR idea: colorize the warning printed by devtest at startup (in orange) 19:23 erle v-rob, i am not sure about a-z. the j key on my keyboard is located where the - key is located on a qwertz keyboard. 19:24 v-rob OK, we'll only send the spacebar then, nothing else :) 19:24 erle and the d key on my keyboard is located where qwertz has ö 19:24 erle i'll test that 19:24 v-rob I don't even know what ö _should_ return in terms of keycodes :/ 19:24 erle but the thing is i don't believe there is a safe *character* set. i believe there may be safe keycodes. or maybe i am misunderstanding something about that. 19:25 erle i'll check quickly 19:25 v-rob I think shift, alt, control, spacebar, enter, arrow keys, and the like all ought to be safe 19:25 sfan5 I don't remember what I wrote on that PR but I believe I said that going by keycodes is totally flawed 19:25 erle it probably is 19:25 v-rob What ought it to go by? 19:25 erle the reform has several spacebars hehe 19:26 v-rob "Character" is far too ambiguous to be used 19:26 erle no idea, i'll test the ö thing now in 5.4.1 19:26 sfan5 the characters produced 19:26 erle the problem is that keyboards are fucky. usb keyboards basically speak ps2 scancodes over usb, for example. 19:26 erle so you have to have the conversion handling on the software side, because keyboards won't send you a “character” 19:27 sfan5 though if you're designing an input scheme it'd be good to have it use WASD regardless of what the keyboard layout produces 19:27 erle i3 does it well 19:27 sfan5 so the question with the formspec keyboard feature is, is it meant to be control-y or text input-y? 19:27 erle i think it saves key configuration by character, but the initial mapping is by keycode, i.e. layout 19:28 erle so the initial mapping will always be independent of keyboard mapping 19:28 erle in terms of which physical keys are pressed 19:28 v-rob I think the problem with characters is that they change depending on the shift key: if I have shift down, and I press 7, I'll get &. 19:28 v-rob So, you have no idea if the user pressed "shift+7" or their keyboard-specific & key 19:28 sfan5 true 19:29 v-rob What a mess 19:29 erle is that *actually* true? 19:29 v-rob If you go by character, yes 19:29 erle oh, i see 19:29 v-rob Minetest's _keybindings_ currently do this 19:29 v-rob Try going to the key change menu, and when you set a key, press shift and 7 at the exact same time. You will sometimes get an & as your keybinding. 19:30 v-rob It's wacky, and the PR gets rid of that 19:31 sfan5 is that because it rewrites the key menu or because it also changes some input stuff (not directly related to formspecs)? 19:31 erle so for me right now, üöä produce OEM 1 / OEM 3 / OEM 7. what shuold it produce with your PR? 19:31 erle and why – if it is meant to go by character – doesn't it produce ü or ö or ä? 19:32 v-rob It isn't meant to go by character, it's meant to go by keycode 19:32 rubenwardy I've seen libraries go with keypress and text entered events 19:33 rubenwardy which makes sense, as you may type multiple keys to enter text 19:33 v-rob The PR gets rid of it because it removes that "feature" from KeyPress. KeyPress is nothing but a light wrapper around Irrlicht's keycode now 19:33 erle shift + 7 is € on my keyboard. but i found a bug in minetest – alt + 7 is ¤, but it is erroneously detected as a number block key. 19:33 rubenwardy so the keypress would use whatever the keycode is, and text entered would be üöä 19:33 sfan5 is that properly separated into commits? 19:33 v-rob I want to steer away from text input for now since it'll encourage badly-written custom input fields 19:34 sfan5 I don't want that pr squashed and then end up with a behaviour change plus a new feature in a single commit 19:34 MTDiscord that's upto a mod/game author to decidec 19:34 erle i agree with sfan5, it's good to separate concerns 19:34 MTDiscord because sometimes default formspec elems are not worth it 19:34 erle v-rob so if a mod now has WASD controls, will it have VUIA controls on my keyboard, because it goes by keycode? 19:34 sfan5 custom text input will be a nightmare with latency 19:35 erle v-rob also what happens with android virtual keyboards? 19:35 rubenwardy no support 19:35 sfan5 thinking about implementing one is not feasible without CSM 19:35 sfan5 erle: doesn't work 19:35 rubenwardy Android won't support this feature 19:35 MTDiscord oh no 19:35 MTDiscord anyway 19:35 erle oh no 19:35 rubenwardy unless they have a bluetooth keyboard 19:35 paradust v-rob: SDL keymap in irrlicht is very broken. I had to do quite a bit to fix it for web build. 19:36 sfan5 rubenwardy: don't think those work either 19:36 sfan5 (unsupported by irrlicht) 19:36 rubenwardy lol. Well, maybe a pipedream for the future 19:36 erle wait, keyboard never worked on android? 19:36 rubenwardy paradust: sounds like something we'd like to see 19:36 erle not that i play android 19:36 sfan5 it would not be hard to fix this but I am not motivated to do it 19:36 erle paradust i suggest to show v-rob at the earliest possible time 19:36 sfan5 erle: nobody is or has been using SDL with irrlicht 19:37 rubenwardy Anyway, we've made the decision that whilst we'd like feature parity on Android, we won't let it block desktop from getting features. Arguably, this is great as you support the platform better 19:37 sfan5 this has not changed 19:37 sfan5 nor does it relate tot he PR 19:37 sfan5 to the* 19:37 rubenwardy err we have made that decision right 19:37 v-rob I don't think they are separated into different commits, no. It may be possible to do so, but if the things are too interlinked, it may have to be split with the KeyPress one merged first. 19:37 sfan5 v-rob: sure that'd be good 19:37 v-rob In theory, we can add touch events for Android. 19:37 sfan5 (touch support is not exclusive to android) 19:38 v-rob I know that, I have a touchscreen laptop 19:38 v-rob It's just Irrlicht doesn't support computer touch events (I think) 19:38 sfan5 I'm saying that touch works on Linux in the right conditions 19:38 sfan5 someone contributed this 19:38 paradust rubenwardy: https://github.com/paradust7/irrlicht/commit/385d05a72d8a913995649da0f6b810adeb2db0d7 19:39 rubenwardy yay hardware support 19:39 rubenwardy caveats on caveats 19:41 v-rob Now, if we were using SDL, we likely wouldn't have any of these problems *wink wink* 20:07 MTDiscord It sounds like we don't have plans to release a 5.5.1 currently ... in light of the MakeWorld Attacks (even my server seems to have been hit a little, and I'm way low on the radar) I think it might make sense. In particular, at least it would be good to have a specific commit/build (perhaps tagged even) that server owners can run with these auth attack mitigations in place... 20:08 MTDiscord Some server owners have been cherry-picking specific commits, but the more different sets of patches people are running, the harder it is to properly support a bunch of different versions that nobody else has. 20:09 MTDiscord i have some ideas on fixing the other issues 20:11 erle the easiest thing to do is make another advisory 20:11 erle then distribution people backport the stuff themselves 20:12 MTDiscord even if 5.5.1 is released, it still wont have the multitude of patches server owners run on top due to various reasons, not limited to core dev politics 20:12 MTDiscord I don't think most server owners use server binaries provided by their distro repository 20:13 MTDiscord I don't think binaries are the biggest issue, I think it's having a specific commit/tag 20:14 MTDiscord I build my own binaries, but the only "patching" I do is a couple of debug logging settings, and some cmake options like enabling postgres 20:15 MTDiscord Because of this auth thing I'm basically running 5.6.0-dev now, even though it was my intention to stay on 5.5.* until 5.6 was released... 20:15 MTDiscord Though I guess fixing the [combine thing would be nice to include in 5.5.1 too 20:16 MTDiscord or solve the problem by releasing more frequently instead of complaining about wack version usage? 20:24 v-rob > so for me right now, üöä produce OEM 1 / OEM 3 / OEM 7 -- Ah carp. Yeah, OEM keys definitely don't work. I just checked my PR--it'll report ;`' for those OEM keys, respectively 20:25 v-rob That makes OEM keys a definite "no" 20:32 MTDiscord is there some kind of list for the next dev meeting where I can put PRs on? 20:32 MTDiscord anyways, #11846 could use a look 20:32 ShadowBot https://github.com/minetest/minetest/issues/11846 -- No damage effects on hp_max change by appgurueu 20:32 MTDiscord dev wiki is a list, not sure who is supposed to add to it 20:33 MTDiscord wsor: which page? 20:34 MTDiscord the meeting page? 20:34 sfan5 dev minetest net Meetings 20:34 sfan5 or such 20:34 rubenwardy !dev Meetings 20:34 ShadowBot Meetings - Minetest Developer Wiki -- http://dev.minetest.net/Meetings 20:34 sfan5 I don't think binaries are the biggest issue, I think it's having a specific commit/tag 20:34 sfan5 we could cherry-pick backports to the stable-5 branch without actually releasing, that'd give server owners something they can use without risk 20:34 rubenwardy luatic: meetings aren't really for code review, and that PR's concept looks fine 20:34 sfan5 (or another branch) 20:35 MTDiscord rubenwardy: if you could quickly fix the formatting issue #11876 has, you might be able to get another PR off the list with minimum effort 20:35 ShadowBot https://github.com/minetest/minetest/issues/11876 -- Update mods_here.txt to mention installing mods via CDB by qwerty123a2 20:35 MTDiscord trivial PRs only need a single approval, right? 20:35 rubenwardy that only applies to bug fixes 20:35 MTDiscord hmmkay 20:36 sfan5 trivial PRs need zero approvals 20:36 sfan5 though technically the coredev who merged it implicitly approves it 20:36 sfan5 so approval count can never be zero 20:38 rubenwardy oh you're right 20:39 rubenwardy > If you have a small patch, fixing some compiler error or other trivial mistake, notify about fixing it on #minetest-dev, wait for 5...15 minutes and push it. [..] https://dev.minetest.net/Git_Guidelines 20:42 erle v-rob what layout do you have? 20:43 erle v-rob for me the üöä keys are where zxc are on qwerty, but it could be that your üöä keys are somewhere else. physically. 20:43 erle like for me they are in the row above the space key, on the left. i bet yours are on the right. 20:44 erle and one or two rows higher 20:48 sfan5 by the way here's another reason not to rush out 5.5.1: probably in a bunch of days someone will come with another engine bug that we'll have to fix, if we release asap we'll end up on version 5.5.9 sooner or later 20:49 MTDiscord you can do a 5.5.10, you don't run out of numbers :-J 20:51 erle yeah than do that 20:51 erle like what's the problem with minor releases 20:53 MTDiscord In this case it's not so much "there's a bug in the engine" as it is "somebody is actively using these exploits in the wild to attack servers". If someone can find 9 other bugs like that, then I'd say we'd have earned a 5.5.10. 20:54 erle what Warr1024 says 20:58 v-rob erle: I don't have üöä keys, I was quoting you 20:59 v-rob For me, ;`' are the keys for those OEM keycodes 21:00 sfan5 each release incurs a certain amount of work, that's why 21:01 erle v-rob oh 21:04 erle sfan5 in your opinion, is it possible to clearly backport the thing? if so, if you tell me the commits, i'll make the debian bug report – there is already someone packaging 5.5 there I remember. 21:04 erle clearly → cleanly 21:05 sfan5 to 5.4? I have no idea 21:05 erle and to 5.5? 21:05 sfan5 debian does not package 5.5 21:05 sfan5 and even if they did and backported it the fix would only go the unstable/testing 21:06 erle ah sponsor is needed here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006832 21:07 erle last update, yesterday 21:09 MTDiscord lol, Debian is going to try to build against regular irrlicht 21:10 v-rob[m] In terms of #8679, I don't think mice are terribly important to test thoroughly--after all, if one mouse reports faster mousewheel events than another, it's not too bad, since the users of those mice are probably used to it. The mousepad on my laptop, for instance, reports floating point values, giving very fine-grained scrolling, and if you swipe really fast and let go, it continues scrolling in a decelerative manner. The wheel on 21:10 v-rob[m] my mouse, on the other hand, only scrolls in increments of three, and the mouse itself only moves two pixels at a time, never one. Modders just have to be prepared for slight differences. 21:10 ShadowBot https://github.com/minetest/minetest/issues/8679 -- Add FormSpec key and mouse events by v-rob 21:10 v-rob[m] Mainly, the mouse testing should focus on whether mice work rather than whether they give consistent results. 21:10 v-rob[m] Keyboards are a bigger issue, since it's very important that keyboard results are consistent. Mainly, I'm concerned about the OEM keys and whether they're consistent across platforms. 21:11 v-rob Ack, stupid matrix 21:11 v-rob[m] I suspect that SDL may have code to make OEM keys consistent across keyboard, since it has no generic "OEM" enum values, whereas Irrlicht does. 21:12 v-rob Now it connects and sends all the messages it refused to send earlier... 21:12 v-rob[m] Since I'm an English speaker on a QWERTY keyboard, it all works fine for me. However, it needs to be tested by other people, ideally with diverse languages. 21:13 v-rob[m] I don't know of any better way to test that than to print the keycode to the screen and say "hey, does this match the key on your keyboard?" 21:14 v-rob[m] test 21:17 sfan5 in addition before a minor release I'd like if someone at least attempts to solve the issues we've had with android 21:17 v-rob Well, I've been looking through the USB specifications (https://www.usb.org/sites/default/files/hut1_21_0.pdf, see section 10, 0x07), which gives a full listing of keycodes, which SDL appears to follow to the letter. However, judging by the comment at the top of the table, the fact that everything gives inconsistent results is actually... standard behaviour. 21:19 v-rob However, the table does give a handy list of keycodes with lots of footnotes noting which ones are usually inconsistent. So, we can easily pick and choose the best keycodes to include, and if we decide to include others, they can be documented as being inconsistent across platforms. 21:22 v-rob I think basing it off this table is the way to go 21:22 v-rob In fact, referencing this table might be a good idea. 21:23 rubenwardy by keycodes, do you mean numbers or names? 21:23 rubenwardy Names are much better for the API 21:23 v-rob It gives the standard name for each standardized number 21:24 v-rob So we could use the standard names in our API (removing the "Keyboard " prefix, perhaps) 21:26 v-rob It's pretty bad, though. A good number of letters (for instance, "a", "c", "m", etc) are listed as "Typically remapped for other languages in the host system." 21:26 v-rob There's no way modders can rely on keypresses to be consistent 21:30 MTDiscord will the arrow keys work at least? 21:35 v-rob Yeah, arrow keys, shift, control, alt, spacebar, escape, enter, and other such special keys should always be safe no matter what. 21:36 v-rob Anything not affected by language, essentially. Letters and punctuation are all language-affected 21:36 v-rob Numbers are probably fine 21:37 v-rob So, there's enough to make formspec-based games with. It's no good for keyboard shortcuts, though, since letters may be wacky on some keyboards 21:38 MTDiscord i should rewrite some of the existing ones like tetris to use this pr for testing 21:40 erle > arrow keys, shift, control, alt, spacebar, escape, enter 21:40 erle i am very curious if this holds 21:40 v-rob If it doesn't, the whole PR needs to be scrapped 21:41 v-rob Still, any keyboard that doesn't give consistent results for those is _probably_ not adhering to the standard 21:41 erle v-rob there is a way around this though. make minetest have an internal mapping that is adjustable. “now press the key for a” and so on. 21:42 v-rob It's possible. Gross, but possible 21:42 erle it means you need to press each key once 21:42 erle i am very curious if both spacebars on the reform2 give the same keycode 21:43 erle v-rob can i figure something out using xev or do i need to start the full minetest and go into the keyboard dialog? 21:43 erle or is there some sdl application i can misuse for this 21:43 v-rob No idea what xev is. 21:44 v-rob Minetest will probably give you "Unknown" or something like that if the keycodes are different 21:44 erle it shows X events. i press a key and it outputs something. or i move the mouse. etc. pp. 21:44 erle wait 21:45 erle for example, i press return and one part of the output is: keycode 36 (keysym 0xff0d, Return) 21:45 v-rob So, do the spacebars have different codes? 21:45 erle when i press the enter key on the keypad it gives me: keycode 104 (keysym 0xff8d, KP_Enter) 21:46 erle no idea, i have to start the computer and it uses wayland, so it is more than i am willing to think about it rn. i am very sleepy. 21:46 erle i'll have time during the weekend figuring this out 21:47 erle (i do not know if wayland and xev work as i think they should work) 21:47 v-rob Wait, what's a keysym? 21:47 v-rob That doesn't look like either a keycode or a scancode 21:49 sfan5 https://www.cl.cam.ac.uk/~mgk25/ucs/keysymdef.h 21:50 v-rob Wait, that sounds exactly like what we want 21:50 erle v-rob more weird stuff: minetest 5.4.1 thinks my left alt key is “left menu” and my right alt key is “keypad .” which is funny, because i have a keypad with a key that is detected as that (even though it is labeled with a comme probably due to being a dutch keyboard). is this something your PR fixes? 21:51 erle comme → comma 21:51 v-rob Probably not 21:51 sfan5 5.5 brought a lot of changes, comparing anything current to 5.4 is a waste of time 21:51 erle ok 21:52 sfan5 anything input, client, windowing, OS-related that is 21:53 erle just for amusement, caps lock (on the left of the keyboard) is detected here as “right menu” lol. and the key left of the 1 key (^) is detected as 1. haha. 21:53 erle i'll compare to 5.5 then 21:53 v-rob Gotcha, keysyms are X11 only. Shoot 21:54 v-rob Windows, of course, has its own standard 21:54 paradust SDL has its own virtual keysyms/scancodes 21:55 v-rob Do SDL keycodes really function the same as X11 keysyms? 21:55 v-rob Or are they light wrappers around USB keycodes? 21:55 paradust https://wiki.libsdl.org/SDL_Keycode 21:55 erle haha, on 5.5.0 windows (in wine) the üöä keys are OEM 5 / 6 / 7. 21:56 paradust Not sure what you're asking. Each platform SDL supports is supposed to map onto this in some sensible way 21:56 v-rob Right, so they are keysyms. So, SDL _would_ actually fix this problem. 21:56 v-rob Actually, I think Irrlicht uses Windows virtual keys, so this whole keycode mess might actually only be a problem on Linux 21:58 erle v-rob on windows, is your left caps lock key OEM 8? 21:58 erle in minetest 5.5.0 21:59 v-rob One moment, please 21:59 erle also my fn key is f16 lol 21:59 sfan5 irrlicht isn't really much different from sdl in that regard, not sure why you think this would only affect one platform 22:00 sfan5 EKEY_CODE ~= SDL_SCANCODE_* and the Char ~= SDLK_* 22:00 v-rob If it's using virtual keys and keysyms, that would imply that EKEY_CODE ~= SDLK_* 22:01 v-rob (I assum ~= meaning "approximately equivalent") 22:01 sfan5 it means that and no 22:01 sfan5 you have stuff like SDL_SCANCODE_INTERNATIONAL4 because key locations do not portably map to characters 22:02 sfan5 and then you have stuff like SDLK_COLON because no consistent location maps to this character 22:02 erle in fact, i know no letter or special symbol that can portably map. do numbers? 22:02 erle arabic numbers, in case some smartass is reading lol 22:02 sfan5 and in irrlicht you have the equivalents: KEY_OEM_1 and Char == L':' 22:02 v-rob Well, if you press Z on QWERTY, you get a Z in the keybindings menu. Pressing Z on AZERTY will give Z still. That's a keysym. If we were using scancodes, you'd get W when you press the Z in AZERTY 22:03 sfan5 that's something different 22:03 sfan5 what irrlicht exposes is pretty much like SDL 22:04 sfan5 minetest mangles this using KeyPress to get a roughly "what matters is the character that comes out" (because I thought it was the right thing at the time) 22:05 v-rob Well, if SDL has the same pitfalls, I don't know how we can have a consistent interface for modders. Perhaps characters are the best compromise after all 22:05 sfan5 yes, input is hard 22:05 erle and still, minetest 5.5.0 will tell me that the minus key and the escape key are the same in the keypress menu on a thinkpad x390. hilarious, since the minus key is actually mapped and the escape key should never be mapped. 22:05 erle mapped → mappable 22:06 v-rob Well, characters will allow us to do keyboard shortcuts 22:06 sfan5 I think if someone wrote a simple test application that let you press a key and printed the Char and Key it maps to, that'd provide some clarity 22:06 erle v-rob characters are only a good compromise if you can prevent WASD or HJKL type of interfaces. because they won't work on anything that is not QWERTY or derived 22:06 sfan5 (for irrlicht, but you can do this for sdl too) 22:07 erle yes, i'd run that app a lot 22:07 v-rob erle: that's what scancodes would be useful for 22:07 v-rob Positional 22:07 erle v-rob then from my POV you need two interfaces, as sfan5 said, one scancody, one character-style. this is a mess indeed. 22:08 erle (sfan5 did not say you need 2 interfaces, but distinguished the two types of interfaces) 22:08 erle (just to be clear) 22:08 paradust is this as wrong as it looks: https://github.com/minetest/minetest/blob/master/src/network/connectionthreads.cpp#L35 22:08 MTDiscord makes a weird kind of sense to me 22:09 erle paradust what's wrong 22:09 paradust if debugging is off, I would expect LOG(a) to be a no-op 22:09 MTDiscord "if non-debug build, still execute the thing inside a log statement for its side effects, but don't actually pass the value it returns to the logging stuff" 22:10 erle paradust, if debugging is off, logging is a no-op, what is done to be logged is not 22:10 sfan5 both wrong 22:10 sfan5 debug build = logging happens and it's behind a mutex for consistent ordering, release build = logging happens but yolo ordering 22:11 sfan5 also log statements with side effects are bad, I hope there are none 22:11 MTDiscord I would hope there are none too, but I could see why one would guard against them. 22:11 erle sfan5, wait, is the mutex that expensive? 22:12 sfan5 no idea 22:12 MTDiscord Also, having a debug statement affect the choice of mutex use or not ... sounds kinda wrong too... 22:12 sfan5 if it's inside networking code, possibly 22:12 erle oof 22:15 erle sorry for being wrong, i should have read the code