| Time |
Nick |
Message |
| 00:16 |
MTDiscord |
<Jonathon> yeah, and? |
| 00:16 |
MTDiscord |
<Jonathon> 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 |
<Jonathon> or one fixed the docs, and the other added support for css level 4 |
| 00:38 |
MTDiscord |
<Jonathon> ya know, reading the titles |
| 01:24 |
|
steveamr joined #minetest-dev |
| 01:25 |
steveamr |
Hi |
| 01:25 |
steveamr |
How in minetest can my name is irc |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 07:02 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:26 |
|
calcul0n joined #minetest-dev |
| 07:55 |
MTDiscord |
<GoodClover> wsor: why would you merge one to fix the docs and then one to un-fix them to their previous state |
| 07:56 |
MTDiscord |
<GoodClover> oh, the support one also modifies the docs |
| 07:56 |
MTDiscord |
<GoodClover> so it's just redundant |
| 07:56 |
MTDiscord |
<GoodClover> no worries then :p |
| 08:32 |
MTDiscord |
<luatic> erle: merging the level 4 PR would have made the level 3 PR obsolete |
| 08:33 |
MTDiscord |
<luatic> 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:10 |
|
HuguesRoss joined #minetest-dev |
| 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 |
<Jonathon> 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:46 |
|
Fixer joined #minetest-dev |
| 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:05 |
|
YuGiOhJCJ joined #minetest-dev |
| 12:09 |
MTDiscord |
<ROllerozxa> 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 |
<ROllerozxa> 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 |
| 13:13 |
|
Toothless joined #minetest-dev |
| 13:18 |
|
proller joined #minetest-dev |
| 13:36 |
|
proller joined #minetest-dev |
| 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 |
<luatic> I'm considering making a couple 2D arcade games using this |
| 15:29 |
MTDiscord |
<luatic> like Snake |
| 15:30 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> But rather "class of problems" |
| 15:31 |
erle |
class as in class of problem |
| 15:31 |
erle |
yeah what luatic saysn |
| 15:31 |
MTDiscord |
<luatic> erle: your intensive testing sacrifices the holy agility |
| 15:32 |
MTDiscord |
<luatic> :P |
| 15:32 |
MTDiscord |
<Jordach> just test in production |
| 15:32 |
MTDiscord |
<Jordach> nothing can go wrong™️ |
| 15:32 |
MTDiscord |
<luatic> bruh moment |
| 15:32 |
MTDiscord |
<luatic> 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 |
<luatic> :P |
| 15:35 |
MTDiscord |
<luatic> Now how do you want to test this? |
| 15:35 |
MTDiscord |
<luatic> Rotate the scrollwheel by 1cm? |
| 15:35 |
erle |
there is no scrollwheel on a trackball hehe |
| 15:35 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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:23 |
|
YuGiOhJCJ joined #minetest-dev |
| 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:49 |
|
Toothless joined #minetest-dev |
| 18:57 |
MTDiscord |
<luatic> 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 |
<luatic> anyways sfan5, would you take another look |
| 19:00 |
MTDiscord |
<luatic> I've now created a single default object |
| 19:01 |
MTDiscord |
<luatic> to void any and all performance concerns (not that they could've been justified in the first place) ;) |
| 19:18 |
|
v-rob joined #minetest-dev |
| 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:20 |
|
qur joined #minetest-dev |
| 19:21 |
erle |
<v-rob> 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 |
<Jordach> 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 |
<Jordach> 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 |
<Jordach> oh no |
| 19:35 |
MTDiscord |
<Jordach> 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* |
| 19:42 |
|
qur joined #minetest-dev |
| 20:07 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Jordach> 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 |
<Jonathon> 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 |
<ROllerozxa> I don't think most server owners use server binaries provided by their distro repository |
| 20:13 |
MTDiscord |
<Warr1024> I don't think binaries are the biggest issue, I think it's having a specific commit/tag |
| 20:14 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> Though I guess fixing the [combine thing would be nice to include in 5.5.1 too |
| 20:16 |
MTDiscord |
<Jordach> 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 |
<luatic> is there some kind of list for the next dev meeting where I can put PRs on? |
| 20:32 |
MTDiscord |
<luatic> 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 |
<Jonathon> dev wiki is a list, not sure who is supposed to add to it |
| 20:33 |
MTDiscord |
<luatic> wsor: which page? |
| 20:34 |
MTDiscord |
<Jonathon> 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 |
<Warr1024> 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 |
<luatic> 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 |
<luatic> trivial PRs only need a single approval, right? |
| 20:35 |
rubenwardy |
that only applies to bug fixes |
| 20:35 |
MTDiscord |
<luatic> 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 |
<Warr1024> 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 |
<Warr1024> 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:56 |
|
v-rob joined #minetest-dev |
| 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 |
<Jonathon> 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:20 |
|
proller joined #minetest-dev |
| 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 |
<luatic> 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 |
<Jonathon> 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 |
<Warr1024> 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 |
<Warr1024> "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 |
<Warr1024> 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 |
<Warr1024> 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 |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 22:39 |
|
v-rob joined #minetest-dev |
| 22:42 |
|
v-rob[m] left #minetest-dev |
| 23:20 |
|
Alias joined #minetest-dev |
| 23:41 |
|
YuGiOhJCJ joined #minetest-dev |
| 23:59 |
|
Noisytoot joined #minetest-dev |
