| Time |
Nick |
Message |
| 01:44 |
|
wsor4035 joined #minetest-dev |
| 04:39 |
|
indiana joined #minetest-dev |
| 07:22 |
|
MTDiscord joined #minetest-dev |
| 07:51 |
|
calcul0n joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 09:08 |
|
proller joined #minetest-dev |
| 10:15 |
|
Fixer joined #minetest-dev |
| 10:29 |
|
proller joined #minetest-dev |
| 11:49 |
|
Fixer_ joined #minetest-dev |
| 12:05 |
|
proller joined #minetest-dev |
| 12:48 |
|
Fleckenstein joined #minetest-dev |
| 12:50 |
|
Sharpik joined #minetest-dev |
| 12:57 |
Sharpik |
rubenwardy: Hello Rubenwardy, I'd like to ask If You are going to release 5.4.x android test build at https://github.com/rubenwardy/minetest/releases/ in near few days. Thanks for response and Your work |
| 13:12 |
|
turtleman joined #minetest-dev |
| 13:29 |
rubenwardy |
I had no plans to do so |
| 13:29 |
rubenwardy |
5.4 won't be released until December |
| 13:34 |
Sharpik |
Ok, thanks for response |
| 13:47 |
|
proller joined #minetest-dev |
| 14:14 |
|
Sharpik joined #minetest-dev |
| 14:24 |
|
proller joined #minetest-dev |
| 14:45 |
|
EliasFleckenstei joined #minetest-dev |
| 14:52 |
|
absurb joined #minetest-dev |
| 16:13 |
|
lhofhansl joined #minetest-dev |
| 16:14 |
lhofhansl |
hi all, I updated #10426 to only handle worldmods (world specific mods) and no longer handles an optional "game" folder insight the world, since that is too controversial. |
| 16:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/10426 -- Handle world mods in the config dialog. by lhofhansl |
| 16:41 |
|
aldum joined #minetest-dev |
| 16:57 |
sfan5 |
<rubenwardy> There's a backport branch for 5.3.1 with some anticheat fixes |
| 16:57 |
sfan5 |
in your repo? |
| 16:58 |
rubenwardy |
In minetest |
| 16:58 |
rubenwardy |
Unless I didn't push it |
| 16:58 |
sfan5 |
https://github.com/minetest/minetest/tree/backport-5 oh |
| 17:04 |
sfan5 |
I wonder if any server owners are running the attached freemove fix yet |
| 17:04 |
sfan5 |
it could use some testing |
| 17:28 |
|
homthack joined #minetest-dev |
| 18:55 |
|
Sharpik joined #minetest-dev |
| 19:04 |
Krock |
ok guys I fixed the chat inputs |
| 19:09 |
|
TC01 joined #minetest-dev |
| 19:12 |
rubenwardy |
Yay |
| 19:18 |
Krock |
#10456 |
| 19:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/10456 -- Fix key input issues by SmallJoker |
| 19:20 |
Krock |
I can now enter {}][ and ! which were not possible previously. perhaps there's also improvement for other layouts |
| 19:20 |
Krock |
using stock irrlicht |
| 19:20 |
rubenwardy |
as key bindings or in text input? |
| 19:21 |
MTDiscord |
<Lone_Wolf> I'll add to my client and see how it goes |
| 19:24 |
sfan5 |
.git/rebase-apply/patch:113: trailing whitespace. |
| 19:24 |
sfan5 |
switch (key_code) { |
| 19:26 |
Krock |
rubenwardy: latter. I believe former already worked |
| 19:30 |
sfan5 |
there's also an unit test failure |
| 19:30 |
Krock |
>:( |
| 19:30 |
Krock |
0 / 37 failed modules (0 / 198 failed individual tests). |
| 19:33 |
Krock |
I don't understand why clang fails for that one. though the test is also kinda stupid |
| 19:34 |
MTDiscord |
<Techy5> Would there be any interest in changing the color for the minimap radar to something other than pure green? |
| 19:34 |
MTDiscord |
<Techy5> At the moment, it feels more like a debug tool than an actual gameplay element |
| 19:34 |
Krock |
radars are commonly green, though. |
| 19:35 |
MTDiscord |
<Techy5> true, but it could be toned down a bit (currently it's pure #00FF00 green) |
| 19:37 |
sfan5 |
unlike operator== the std::hash<KeyPress> implementation prefers keycode over char |
| 19:37 |
sfan5 |
could that be it? |
| 19:37 |
Krock |
https://github.com/minetest/minetest/blob/master/src/client/minimap.cpp#L339-L341 |
| 19:39 |
Krock |
no, the hash function has to be like that |
| 19:40 |
Krock |
also it would either use hash or equality signs |
| 19:40 |
Krock |
also the hash function is only relevant to the input handler - not to KeyPress itself |
| 19:41 |
sfan5 |
4. For two parameters k1 and k2 that are equal, std::hash<Key>()(k1) == std::hash<Key>()(k2). |
| 19:42 |
sfan5 |
I don't see the function guaranteeing this |
| 19:46 |
sfan5 |
and because the comparison can work on either keycode or char I can't come up with a hash function that does |
| 19:46 |
Krock |
"Key" is bit-shifted to mostly ensure that the values don't overlap |
| 19:47 |
Krock |
though it's a pity that wchar_t is the size of size_t |
| 19:49 |
sfan5 |
the issue is that {KEY_KEY_G, '.'} hashes to (KEY_KEY_G << 24) and {<missing>, '.'} hashes to '.' but operator== would compare the two equal |
| 19:50 |
Krock |
I see |
| 19:52 |
sfan5 |
and in fact this was added before your PR but I didn't notice |
| 19:53 |
sfan5 |
(maybe that's what caused the issues?) |
| 19:55 |
|
fluxflux joined #minetest-dev |
| 19:57 |
|
Taoki joined #minetest-dev |
| 19:57 |
sfan5 |
if you don't mind, check if reverting https://github.com/minetest/minetest/commit/787561b29afdbc78769f68c2f5c4f2cff1b32340 fixes key input |
| 19:58 |
|
Hijiri_ joined #minetest-dev |
| 19:59 |
Krock |
it does |
| 20:02 |
|
Taoki joined #minetest-dev |
| 20:03 |
Krock |
okay. let's see whether this attempt works. == and hash will now produce the same outputs for the same KeyPress |
| 20:05 |
sfan5 |
shouldn't that be if (valid_kcode(Key) || valid_kcode(o.Key)) ? |
| 20:05 |
sfan5 |
otherwise it might happen that k1 == k2 but !(k2 == k1) |
| 20:06 |
Krock |
right! |
| 20:07 |
Krock |
ah shit. Sneak move broke |
| 20:11 |
sfan5 |
:/ |
| 20:13 |
Krock |
KEY_KEY_W must be taken for upper and lowercase W, whereas / is always in combination with shift |
| 20:13 |
Krock |
I believe the reason why it worked previously is a matter of priority |
| 20:14 |
sfan5 |
yeah probably |
| 20:23 |
Krock |
fsck this. will probably just split the chat fixes into a new PR and revert the other one. |
| 21:10 |
|
Taoki joined #minetest-dev |
| 21:47 |
|
lhofhansl joined #minetest-dev |
| 23:28 |
|
homthack joined #minetest-dev |
