| Time |
Nick |
Message |
| 00:22 |
|
Megaf joined #minetest-dev |
| 00:50 |
Megaf |
rubenwardy, Hi there, how you doing? |
| 00:50 |
Megaf |
Folks, so about the player list when pressing TAB |
| 00:50 |
Megaf |
can we have that? |
| 01:08 |
MTDiscord |
<exe_virus> You could probably code it up yourself. Or rebind a key to it and write a client mod for that |
| 01:09 |
Megaf |
It is done already |
| 01:10 |
Megaf |
the Github issue has been opened for years |
| 01:11 |
Megaf |
Here https://github.com/minetest/minetest/pull/958 |
| 01:11 |
Megaf |
> sfan5 commented on Oct 17, 2013 |
| 01:12 |
Megaf |
And here we have another implementation https://github.com/minetest/minetest/issues/4312 |
| 01:12 |
MTDiscord |
<exe_virus> Probably not then, though we may be getting better keyboard support with SDL backend, which may allow us to open up the exposed keys, buts that's just my musings |
| 01:31 |
pgimeno |
well you can type /status, not so comfortable but still effective |
| 01:33 |
Zughy[m]1 |
that's definitely not the same thing |
| 01:36 |
Megaf |
Almost every single mp game has a nice player list on the TAB key or elsewhere |
| 01:36 |
Megaf |
even flight simulators |
| 02:41 |
|
Megaf joined #minetest-dev |
| 03:31 |
|
I_am_Grid joined #minetest-dev |
| 04:32 |
|
ssieb joined #minetest-dev |
| 04:50 |
Megaf |
yay, after many years I'm adding another bug to our collection! https://github.com/minetest/minetest/issues/10945 |
| 04:50 |
Megaf |
#10945 |
| 04:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/10945 -- make install doesn't work. |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:54 |
|
Megaf joined #minetest-dev |
| 06:02 |
|
Megaf joined #minetest-dev |
| 07:44 |
|
ivanbu joined #minetest-dev |
| 07:44 |
|
ssieb joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:13 |
MTDiscord |
<Zander_200> Wait i can speak here now? pog |
| 09:07 |
MTDiscord |
<appguru> "WARNING: This storage backend is incaptable to save raw binary data due to restrictions of JSON." |
| 09:07 |
MTDiscord |
<appguru> How so? |
| 09:07 |
MTDiscord |
<appguru> JSON can store raw binary data in string form just fine |
| 09:19 |
sfan5 |
json only stores unicode |
| 09:19 |
sfan5 |
if you pretend that the first 255 unicode codepoints map to byte values, then yes it "can" store binary too |
| 10:58 |
|
calcul0n__ joined #minetest-dev |
| 10:59 |
celeron55 |
usually people base64 encode binary data before storing inside json |
| 11:13 |
|
proller joined #minetest-dev |
| 11:54 |
|
Fixer joined #minetest-dev |
| 12:44 |
Zughy[m]1 |
sorry for insisting, so can #10235 be added to the 5.4.0 milestone? |
| 12:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/10235 -- Send attachments instantly before set_pos by SmallJoker |
| 12:46 |
rubenwardy |
the change makes sense and looks good for me |
| 12:46 |
rubenwardy |
but I'm unsure how to test completely - but nothing will break, right? |
| 13:15 |
|
absurb joined #minetest-dev |
| 14:26 |
|
Wuzzy joined #minetest-dev |
| 14:52 |
Krock |
rubenwardy: sendOutdatedData() sends incremental data which is currently sent async to other actions, hence fixed sending for position updates would not break anything |
| 14:52 |
Krock |
worst that could happen is that attachments are sent twice after each other for rapid updates, rather than delaying them for a server step |
| 18:17 |
|
olliy joined #minetest-dev |
| 18:23 |
|
CodeAndFix joined #minetest-dev |
| 18:23 |
CodeAndFix |
hi |
| 18:32 |
|
calcul0n_ joined #minetest-dev |
| 19:00 |
|
ssieb joined #minetest-dev |
| 19:09 |
|
anon joined #minetest-dev |
| 19:10 |
|
Guest34648 left #minetest-dev |
| 19:22 |
sfan5 |
2021-02-12 20:19:43: WARNING[Server]: base_pos = (-1468.92,96,4001.12) attachment_pos = (0,11,0) parent_pos = (-1468.92,85,2015.12) |
| 19:22 |
sfan5 |
2021-02-12 20:19:43: ACTION[Server]: Server: singleplayer moved away from parent; diff=198.6 resetting position. |
| 19:22 |
sfan5 |
oh no |
| 19:22 |
sfan5 |
exactly 200 nodes offset, anyone want to guess what that means? |
| 19:23 |
Krock |
no idea at all. first time seeing this number |
| 19:24 |
sfan5 |
#10027 |
| 19:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/10027 -- CAOs vanish for one frame when shifting camera offset |
| 19:24 |
sfan5 |
the camera offset |
| 19:25 |
pgimeno |
I think Krock was being sarcastic :) |
| 19:25 |
Krock |
^ |
| 19:25 |
sfan5 |
oh |
| 19:25 |
sfan5 |
that went past me entirely |
| 19:26 |
Krock |
seen this sort of bug way too often and I thought I fixed that attachment issue like a year ago |
| 19:26 |
Krock |
seems like it's still not working properly |
| 19:26 |
sfan5 |
this is "just" a different aspect of the same issue |
| 19:26 |
Krock |
I wonder whether it's related to that one frame" hecks once mentioned where the player disappears |
| 19:27 |
sfan5 |
when the player is attached to something and the camera offset changes the client will send a position that's 200 nodes off once |
| 19:27 |
Krock |
err yes. you already linked that issue |
| 19:28 |
Krock |
the player position should not be related to the camera but for whatever reason this still happens |
| 19:28 |
pgimeno |
we really need to get rid of discrete camera offset completely. It needs to be continuously applied, but last time I looked into that, with Irrlicht scenes it's not possible. |
| 19:28 |
Krock |
yes "we need" but nobody has a plausible solution at the moment |
| 19:30 |
pgimeno |
I might give it a try after we get rid of stable Irrlicht, but I need to know if we're going to be using Irrlicht or get rid of it |
| 19:31 |
pgimeno |
with our own Irrlicht, it would be possible to modify rendering, to apply the offset to the scene as a whole, and possibly to change positions of scene nodes to double precision |
| 19:31 |
pgimeno |
with our own library, we can do whatever we want |
| 19:33 |
pgimeno |
is there an issue # for getting rid of the discrete camera offset? |
| 19:34 |
sfan5 |
don't think so |
| 19:34 |
Krock |
that was always a topic in related issues, but never opened as a standalone issue if you mean that |
| 19:34 |
pgimeno |
yes, that's what I meant |
| 19:37 |
pgimeno |
I don't think it's possible to develop a reasonable solution while we use stable Irrlicht |
| 19:44 |
Krock |
will merge #10235, game#2808 and game#2821 in 10 minutes |
| 19:44 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2808 -- Safe Compression Commit by ExeVirus |
| 19:44 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2821 -- Update German translation by Wuzzy2 |
| 19:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/10235 -- Send attachments instantly before set_pos by SmallJoker |
| 19:53 |
Krock |
merging |
| 19:55 |
Krock |
done |
| 19:58 |
pgimeno |
the problem with getting rid of discrete camera offset is that it will affect a lot of code, which means it will take forever to merge, which means there will be tons of conflicts when rebasing. The review process needs to be fast-tracked to prevent that, and I have a previous bad experience with the rotations PR. There's also the issue that I'm not in GitHub, so someone needs to adopt the PR like pauloue did with the rotations one. |
| 19:59 |
Krock |
much code? I thought it would only affect camera.cpp and localplayer.cpp perhaps |
| 19:59 |
Krock |
content_cao.cpp too |
| 19:59 |
pgimeno |
I thought camera offset was spread among a lot of files |
| 20:00 |
pgimeno |
I think particles need to take care of it too |
| 20:01 |
pgimeno |
I haven't checked recently, I'm talking from memory about something I looked into... well, maybe 5 years ago |
| 20:03 |
pgimeno |
doing it properly will affect how scene nodes are created, so it can potentially affect calls to scene node creation |
| 20:11 |
sfan5 |
Krock: I invented a different (worse, but simpler) solution for #10908 -> http://sprunge.us/Iyizlh?diff |
| 20:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/10908 -- Anticheat misbehaving by resetting players location and viewdirection when attached to entity with move_to(pos, true) being called |
| 20:11 |
sfan5 |
maybe that'd be preferable for 5.4 |
| 20:11 |
sfan5 |
and then solve the "client has authority over position" mess for 5.5 |
| 20:12 |
Krock |
does that even for for move_to? It still cannot compensate quick movements |
| 20:13 |
Krock |
*work for |
| 20:14 |
Krock |
but for normal interpolated movements that soft of lag pool would be a possible solution |
| 20:15 |
Krock |
(where interpolated is meant in terms of "predictable") |
| 20:16 |
sfan5 |
I specifically tested move_to |
| 20:19 |
Krock |
ah right. missed the part that one change was done in moveTo(...) |
| 20:20 |
Krock |
using the client-side interpolation time as "tolerance range" |
| 21:29 |
sfan5 |
so, worth creating a PR? |
| 21:32 |
Krock |
yes. I think it's worth a try |
| 23:05 |
sfan5 |
created. |
| 23:20 |
|
thodt joined #minetest-dev |
| 23:30 |
|
Megaf joined #minetest-dev |
| 23:38 |
Megaf |
sfan5, can you please elaborate how a broken make install that doesn't work it's not a bug? |
| 23:38 |
Megaf |
Context #10945 |
| 23:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/10945 -- make install doesn't work. |
| 23:39 |
Megaf |
I know make install is a new technology used on the UNIX world for only 40 years and may be too advanced for a little project with just a handful of users, but still. |
| 23:43 |
|
thodt left #minetest-dev |
| 23:44 |
Megaf |
I'm having a look in CMakeLists.txt, it seems to be done with the intention of running make install, as the definition are there, they are just not working |
| 23:45 |
Megaf |
where do the variables WIN32, UNIX and APPLE come from? |
| 23:47 |
Megaf |
Ok, that's a cmake thing, fair |
