| Time |
Nick |
Message |
| 00:02 |
hmmmm |
see, shit like this epitomizes freeminer's main failings: https://github.com/freeminer/freeminer/commit/89dd1d8f4bd71847ce63b80d57d08a0516d2d86e |
| 00:02 |
hmmmm |
oh, there's a bug? fix the symptom, not the cause! |
| 00:03 |
sapier |
*g* |
| 00:03 |
sapier |
I learned all bugs you ignore strike back even more hard |
| 00:05 |
sapier |
btw what do you think about how to fix https://github.com/minetest/minetest/issues/1132 |
| 00:07 |
hmmmm |
the right thing to do here would be to bump the protocol version |
| 00:10 |
sapier |
and handle "older" clients special ... the sad thing about that way is the benefit is lost for all older clients which actually arent broken |
| 00:11 |
hmmmm |
oh hrm |
| 00:12 |
hmmmm |
this is a client issue, no...? what's wrong with always sending that packet regardless of the media transmission method? |
| 00:13 |
sapier |
that's what I fixed for recent clients, but 0.4.9 clients don't do it |
| 00:13 |
sapier |
they "forget" about it after downloading media |
| 00:13 |
hmmmm |
ugh |
| 00:14 |
sapier |
if there's nothing to download they're fine |
| 00:14 |
sapier |
there may be another bug in current dev forgetting about the packet in curl mode but I'm not exactly sure about it |
| 00:15 |
hmmmm |
what would sending the clients warning messages on an interval do to fix it |
| 00:15 |
hmmmm |
see this really sucks |
| 00:15 |
hmmmm |
once there's a bug we're stuck with it, because we can't make a patch or something |
| 00:15 |
hmmmm |
we just tell people to download the newest version |
| 00:15 |
sapier |
I added this but there's another issue spaming error messages in this situation |
| 00:16 |
sapier |
so the notification may not be seen ... murphys law |
| 00:16 |
hmmmm |
i don't know |
| 00:16 |
hmmmm |
this is so screwed |
| 00:18 |
hmmmm |
what's actually broken is the fact that we can't patch clients for big showstopping bugs like this |
| 00:18 |
sapier |
the other issue is caused by my changes. I delay client init to avoid showing players in world prior they are ready .. but client step is started in parallel so it's missing some init data that are still "on wire" |
| 00:19 |
sapier |
that situation isn't worth an error message now as missing hud info is now a temporary state only |
| 00:19 |
hmmmm |
when does it get resent |
| 00:19 |
sapier |
yes, we'd need a "autoupdate" at least telling users to update their client |
| 00:20 |
sapier |
it doesn't have to be resent, it's sent right after TOSERVER_RECEIVED_MEDIA is received by server |
| 00:20 |
hmmmm |
ohoh |
| 00:20 |
sapier |
exactly |
| 00:21 |
sapier |
if client doesn't send it it'll never finish it's join sequence |
| 00:21 |
sapier |
0.4.8 works fine |
| 00:21 |
sapier |
latest works (with some bogus error messages I already have a patch to remove) |
| 00:28 |
sapier |
but 0.4.9 will fail on first connect to a server |
| 00:28 |
hmmmm |
i think we should integrate some statistics collection into minetest to see how many people are actually using which versions |
| 00:29 |
|
loggingbot_ joined #minetest-dev |
| 00:29 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 00:29 |
hmmmm |
we should start |
| 00:29 |
sapier |
we'd need to add major minor patch + flag stable/dev |
| 00:30 |
sapier |
most simple way would be sending an additional packet TOSERVER_CLIENT_VERSION |
| 00:30 |
|
ShadowBot` joined #minetest-dev |
| 00:30 |
|
sfan5_ joined #minetest-dev |
| 00:31 |
hmmmm |
i don't want to make it seem too big brother tracking-ish but there should also be a uuid of each client so we don't duplicate entries when we aggregate the information |
| 00:31 |
|
Robby_ joined #minetest-dev |
| 00:32 |
sapier |
hmm I'm not sure about this. we have IP,player name and version shouldn't this be good enough for some reasonable statistics? |
| 00:32 |
sapier |
not perfect of course |
| 00:33 |
|
mrtux joined #minetest-dev |
| 00:33 |
hmmmm |
maybe a hash of the ip and player name |
| 00:33 |
hmmmm |
just no personally identifiable information |
| 00:34 |
hmmmm |
https://github.com/sapier/minetest/commit/56e23bed8faf47f5b1ec9064598b3669165072dc#diff-2543b17841165757ac531ffedd0b5fddR221 |
| 00:34 |
hmmmm |
eq |
| 00:34 |
hmmmm |
ew* |
| 00:35 |
sapier |
what did I do wrong there? |
| 00:35 |
hmmmm |
why not have like const char *client_state_strs[] = { "Invalid", "Disconnecting", ... } lua_pushstring(L, client_state_strs[state]); |
| 00:36 |
hmmmm |
also i dunno if it's intentional or not to have Disconnecting mapped to "Invalid" |
| 00:36 |
sapier |
hmmm ... that'd been too simple to even think about it :-) ... you're right. I'll do it that way ... no that's a copy n paste error |
| 00:36 |
sapier |
it's not ready for merge yet it's just been to show you how this could be done |
| 00:37 |
hmmmm |
oh |
| 00:37 |
sapier |
I'm working at a helper lua mod to administrate minetest from command line too but that's even less polished right now |
| 00:39 |
sapier |
actually I just need the rtt and jitter information for benchmarking but why not make it a really usefull tool |
| 00:40 |
|
rsiska joined #minetest-dev |
| 00:40 |
|
kahrl joined #minetest-dev |
| 00:40 |
|
salamanderrake joined #minetest-dev |
| 00:40 |
|
Taoki joined #minetest-dev |
| 00:43 |
|
deltib joined #minetest-dev |
| 00:43 |
|
bas080 joined #minetest-dev |
| 00:43 |
|
dzho joined #minetest-dev |
| 00:43 |
|
pitriss` joined #minetest-dev |
| 00:43 |
|
kahrl_ joined #minetest-dev |
| 00:45 |
|
17SAAEYAU joined #minetest-dev |
| 00:47 |
|
Anchakor_ joined #minetest-dev |
| 00:48 |
|
Gethiox joined #minetest-dev |
| 00:48 |
|
mrtux joined #minetest-dev |
| 00:52 |
|
yno_ joined #minetest-dev |
| 00:52 |
|
Neological joined #minetest-dev |
| 00:55 |
|
Taoki joined #minetest-dev |
| 00:55 |
|
17SAAEYOO joined #minetest-dev |
| 00:55 |
|
Yepoleb joined #minetest-dev |
| 00:55 |
|
darkrose joined #minetest-dev |
| 00:55 |
|
darkrose joined #minetest-dev |
| 00:58 |
|
rsiska joined #minetest-dev |
| 00:58 |
|
Kray joined #minetest-dev |
| 00:58 |
|
e1z0 joined #minetest-dev |
| 00:58 |
|
deltib joined #minetest-dev |
| 00:58 |
|
bas080 joined #minetest-dev |
| 00:58 |
|
dzho joined #minetest-dev |
| 01:01 |
|
Taoki joined #minetest-dev |
| 01:01 |
|
Neological joined #minetest-dev |
| 01:01 |
|
Anchakor_ joined #minetest-dev |
| 01:02 |
hmmmm |
to this day i still WTF at some things i find in mapgen_indev.cpp |
| 01:08 |
|
Kray joined #minetest-dev |
| 01:08 |
|
rsiska joined #minetest-dev |
| 01:12 |
|
lanxu joined #minetest-dev |
| 01:18 |
|
deltib joined #minetest-dev |
| 01:21 |
|
hmmmm joined #minetest-dev |
| 01:21 |
|
dzho joined #minetest-dev |
| 01:21 |
|
rsiska joined #minetest-dev |
| 01:21 |
|
VanessaE joined #minetest-dev |
| 01:21 |
|
Yepoleb joined #minetest-dev |
| 01:22 |
|
book` joined #minetest-dev |
| 01:23 |
|
lanxu joined #minetest-dev |
| 01:24 |
|
darkrose joined #minetest-dev |
| 01:24 |
|
darkrose joined #minetest-dev |
| 01:31 |
|
zat joined #minetest-dev |
| 01:31 |
|
mrtux joined #minetest-dev |
| 01:31 |
|
Ritchie joined #minetest-dev |
| 01:36 |
|
bas080 joined #minetest-dev |
| 01:36 |
|
specing joined #minetest-dev |
| 01:36 |
|
RealBadAngel joined #minetest-dev |
| 01:36 |
|
Kray joined #minetest-dev |
| 01:36 |
|
deltib joined #minetest-dev |
| 01:41 |
|
harrison joined #minetest-dev |
| 01:41 |
|
sfan5_ joined #minetest-dev |
| 01:57 |
|
loggingbot_ joined #minetest-dev |
| 01:57 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 02:17 |
|
loggingbot_ joined #minetest-dev |
| 02:17 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 02:29 |
|
Kray joined #minetest-dev |
| 02:38 |
|
loggingbot_ joined #minetest-dev |
| 03:08 |
|
salamanderrake joined #minetest-dev |
| 03:40 |
|
deltib joined #minetest-dev |
| 03:41 |
|
lanxu joined #minetest-dev |
| 03:53 |
|
loggingbot_ joined #minetest-dev |
| 04:00 |
|
loggingbot_ joined #minetest-dev |
| 04:00 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 04:08 |
|
loggingbot_ joined #minetest-dev |
| 04:14 |
|
loggingbot_ joined #minetest-dev |
| 04:14 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 04:17 |
|
Miner_48er joined #minetest-dev |
| 04:18 |
|
36DACCU2B joined #minetest-dev |
| 04:20 |
|
kahrl joined #minetest-dev |
| 04:21 |
|
ShadowNinja joined #minetest-dev |
| 04:21 |
|
ShadowNinja joined #minetest-dev |
| 04:22 |
|
ShadowNinja joined #minetest-dev |
| 04:22 |
|
Yepoleb joined #minetest-dev |
| 04:22 |
|
ShadowNinja joined #minetest-dev |
| 04:28 |
|
RealBadAngel joined #minetest-dev |
| 04:28 |
|
pitriss joined #minetest-dev |
| 04:28 |
|
deltib joined #minetest-dev |
| 04:28 |
|
CiaranG joined #minetest-dev |
| 04:28 |
|
xyz|imaginary joined #minetest-dev |
| 04:32 |
|
Miner_48er_ joined #minetest-dev |
| 04:35 |
|
Weedy joined #minetest-dev |
| 04:35 |
|
Weedy joined #minetest-dev |
| 04:36 |
|
Weedy joined #minetest-dev |
| 04:36 |
|
lanxu joined #minetest-dev |
| 04:36 |
|
kahrl joined #minetest-dev |
| 04:37 |
|
Weedy joined #minetest-dev |
| 04:38 |
|
Weedy joined #minetest-dev |
| 04:38 |
|
hmmmm joined #minetest-dev |
| 04:38 |
|
celeron55 joined #minetest-dev |
| 04:41 |
|
ShadowNinja joined #minetest-dev |
| 04:41 |
|
Weedy joined #minetest-dev |
| 04:41 |
|
ShadowNinja joined #minetest-dev |
| 04:42 |
|
CiaranG joined #minetest-dev |
| 04:43 |
|
Weedy joined #minetest-dev |
| 04:43 |
|
ShadowNinja joined #minetest-dev |
| 04:43 |
|
RealBadAngel joined #minetest-dev |
| 04:46 |
|
ShadowNinja joined #minetest-dev |
| 04:47 |
|
us_0gb joined #minetest-dev |
| 04:51 |
|
ShadowNinja joined #minetest-dev |
| 04:55 |
|
pitriss` joined #minetest-dev |
| 04:59 |
|
ShadowNinja joined #minetest-dev |
| 05:00 |
|
ShadowNinja joined #minetest-dev |
| 05:04 |
|
CiaranG joined #minetest-dev |
| 05:04 |
|
ShadowNinja joined #minetest-dev |
| 05:04 |
|
ShadowNinja joined #minetest-dev |
| 05:05 |
|
xyz|imaginary joined #minetest-dev |
| 05:09 |
|
pitriss joined #minetest-dev |
| 05:17 |
|
loggingbot_ joined #minetest-dev |
| 05:35 |
|
loggingbot_ joined #minetest-dev |
| 05:35 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 05:46 |
|
kahrl joined #minetest-dev |
| 06:02 |
|
deltib joined #minetest-dev |
| 06:02 |
|
Weedy joined #minetest-dev |
| 06:02 |
|
Guest69702 joined #minetest-dev |
| 06:02 |
|
sfan5_ joined #minetest-dev |
| 06:05 |
|
ShadowNinja joined #minetest-dev |
| 06:05 |
|
hmmmm joined #minetest-dev |
| 06:05 |
|
Yepoleb joined #minetest-dev |
| 06:05 |
|
celeron55 joined #minetest-dev |
| 06:05 |
|
RealBadAngel joined #minetest-dev |
| 06:05 |
|
Miner_48er joined #minetest-dev |
| 06:05 |
|
bas080 joined #minetest-dev |
| 06:09 |
|
kahrl joined #minetest-dev |
| 06:10 |
|
ShadowNinja joined #minetest-dev |
| 06:11 |
|
ShadowNinja joined #minetest-dev |
| 06:12 |
|
xyz|imaginary joined #minetest-dev |
| 06:17 |
|
ShadowNinja joined #minetest-dev |
| 06:24 |
|
xyz|imag1nary joined #minetest-dev |
| 06:56 |
|
loggingbot_ joined #minetest-dev |
| 07:03 |
|
lanxu joined #minetest-dev |
| 07:48 |
|
loggingbot_ joined #minetest-dev |
| 09:13 |
|
loggingbot_ joined #minetest-dev |
| 09:13 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 09:15 |
|
RealBadAngel joined #minetest-dev |
| 09:16 |
|
lanxu joined #minetest-dev |
| 09:25 |
|
OldCoder joined #minetest-dev |
| 09:26 |
|
deltib joined #minetest-dev |
| 09:26 |
|
Weedy joined #minetest-dev |
| 09:26 |
|
Guest69702 joined #minetest-dev |
| 09:26 |
|
sfan5 joined #minetest-dev |
| 09:27 |
|
Weedy joined #minetest-dev |
| 09:32 |
|
yno joined #minetest-dev |
| 09:42 |
|
Ritchie joined #minetest-dev |
| 09:56 |
|
Gethiox joined #minetest-dev |
| 09:57 |
|
lanxu joined #minetest-dev |
| 09:57 |
|
Robby joined #minetest-dev |
| 09:57 |
|
robmyers joined #minetest-dev |
| 10:00 |
|
robmyers joined #minetest-dev |
| 10:00 |
|
robmyers joined #minetest-dev |
| 10:00 |
|
lanxu joined #minetest-dev |
| 10:00 |
|
ShadowNinja joined #minetest-dev |
| 10:02 |
|
Taoki_1 joined #minetest-dev |
| 10:05 |
|
ShadowBot joined #minetest-dev |
| 10:11 |
|
ShadowNinja joined #minetest-dev |
| 10:19 |
|
45PABCV1W joined #minetest-dev |
| 10:22 |
|
Anchakor1 joined #minetest-dev |
| 10:35 |
|
DemonRaiser joined #minetest-dev |
| 10:35 |
|
AllegedlyDead joined #minetest-dev |
| 10:52 |
|
e1z0 joined #minetest-dev |
| 10:55 |
|
specing joined #minetest-dev |
| 11:04 |
|
ShadowNinja joined #minetest-dev |
| 11:21 |
|
ShadowNinja joined #minetest-dev |
| 11:22 |
|
ShadowNinja joined #minetest-dev |
| 11:25 |
|
ShadowNinja joined #minetest-dev |
| 11:34 |
|
Yepoleb joined #minetest-dev |
| 11:38 |
|
23LAA1OEF joined #minetest-dev |
| 11:38 |
|
ShadowNinja joined #minetest-dev |
| 12:18 |
|
Robby joined #minetest-dev |
| 12:26 |
|
23LAA1XHM joined #minetest-dev |
| 12:26 |
|
ShadowNinja joined #minetest-dev |
| 12:31 |
|
Yepoleb joined #minetest-dev |
| 12:40 |
|
ImQ009 joined #minetest-dev |
| 13:27 |
|
ImQ009_ joined #minetest-dev |
| 13:33 |
|
Taoki joined #minetest-dev |
| 13:34 |
|
werwerwer joined #minetest-dev |
| 13:34 |
|
Weedy_lappy joined #minetest-dev |
| 13:34 |
|
hmmmm joined #minetest-dev |
| 13:38 |
|
Weedy joined #minetest-dev |
| 13:39 |
|
Weedy_lappy joined #minetest-dev |
| 13:41 |
|
Weedy joined #minetest-dev |
| 13:47 |
|
Weedy_lappy joined #minetest-dev |
| 13:51 |
|
Weedy_lappy joined #minetest-dev |
| 13:52 |
|
Weedy_lappy joined #minetest-dev |
| 14:02 |
|
Weedy joined #minetest-dev |
| 14:02 |
|
hmmmm joined #minetest-dev |
| 14:02 |
|
Weedy joined #minetest-dev |
| 14:04 |
|
Weedy_la1py joined #minetest-dev |
| 14:05 |
|
ShadowNinja joined #minetest-dev |
| 14:05 |
|
werwerwer joined #minetest-dev |
| 14:09 |
|
Jordach joined #minetest-dev |
| 14:11 |
|
Taoki_1 joined #minetest-dev |
| 14:13 |
|
ShadowNinja joined #minetest-dev |
| 14:14 |
|
Weedy joined #minetest-dev |
| 14:20 |
|
Jordach joined #minetest-dev |
| 14:21 |
|
Tesseract joined #minetest-dev |
| 14:23 |
|
Weedy joined #minetest-dev |
| 14:33 |
|
Tesseract joined #minetest-dev |
| 14:34 |
|
Weedy joined #minetest-dev |
| 14:36 |
|
Weedy_lappy joined #minetest-dev |
| 14:49 |
|
Yepoleb_ joined #minetest-dev |
| 14:59 |
|
Weedy joined #minetest-dev |
| 15:11 |
|
werwerwer joined #minetest-dev |
| 15:21 |
|
SmugLeaf joined #minetest-dev |
| 15:21 |
|
Anchakor_ joined #minetest-dev |
| 15:22 |
|
hmmmm joined #minetest-dev |
| 15:29 |
|
Guest13789 joined #minetest-dev |
| 15:31 |
|
Weedy_lappy joined #minetest-dev |
| 15:40 |
|
SmugLeaf joined #minetest-dev |
| 15:40 |
|
NakedFury joined #minetest-dev |
| 15:41 |
|
werwerwer joined #minetest-dev |
| 15:46 |
|
zat joined #minetest-dev |
| 15:51 |
|
hmmmm joined #minetest-dev |
| 16:01 |
|
Calinou_ joined #minetest-dev |
| 16:03 |
|
Anchakor_ joined #minetest-dev |
| 16:04 |
|
OldCoder joined #minetest-dev |
| 16:11 |
|
deltib joined #minetest-dev |
| 16:11 |
|
sfan5 joined #minetest-dev |
| 16:13 |
|
harrison joined #minetest-dev |
| 16:22 |
|
Guest16696 joined #minetest-dev |
| 16:26 |
|
werwerwer_ joined #minetest-dev |
| 16:29 |
|
ImQ009 joined #minetest-dev |
| 16:40 |
|
Calinou_ joined #minetest-dev |
| 16:51 |
|
Exio4 joined #minetest-dev |
| 16:52 |
|
Zeitgeist_ joined #minetest-dev |
| 16:53 |
|
Zeitgeist_ joined #minetest-dev |
| 16:56 |
|
VanessaE joined #minetest-dev |
| 16:56 |
|
whirm joined #minetest-dev |
| 16:57 |
|
bas080 joined #minetest-dev |
| 16:57 |
|
whirm joined #minetest-dev |
| 17:00 |
|
SmugLeaf joined #minetest-dev |
| 17:00 |
|
zat joined #minetest-dev |
| 17:04 |
|
hmmmm joined #minetest-dev |
| 17:05 |
|
PilzAdam joined #minetest-dev |
| 17:07 |
|
e1z0 joined #minetest-dev |
| 17:09 |
|
Guest41192 joined #minetest-dev |
| 17:10 |
|
harrison_ joined #minetest-dev |
| 17:14 |
|
Anchakor_ joined #minetest-dev |
| 17:15 |
|
OldCoder joined #minetest-dev |
| 17:19 |
|
harrison_ joined #minetest-dev |
| 17:24 |
|
Weedy_lappy joined #minetest-dev |
| 17:24 |
|
Guest38052 joined #minetest-dev |
| 17:27 |
|
OldCoder joined #minetest-dev |
| 17:34 |
|
Megaf joined #minetest-dev |
| 17:34 |
Megaf |
Hi all |
| 17:43 |
|
Weedy_lappy joined #minetest-dev |
| 17:49 |
|
ImQ009 joined #minetest-dev |
| 17:54 |
|
Jordach joined #minetest-dev |
| 17:58 |
|
Megaf joined #minetest-dev |
| 17:59 |
|
pineappleclock joined #minetest-dev |
| 18:07 |
|
bas080 joined #minetest-dev |
| 18:18 |
|
Kray joined #minetest-dev |
| 18:28 |
|
sapier joined #minetest-dev |
| 18:32 |
|
Megaf joined #minetest-dev |
| 18:33 |
sapier |
https://github.com/minetest/minetest/issues/1132 this issue is still open. Could some of the core devs please comment ? |
| 18:34 |
sapier |
https://github.com/minetest/minetest/pull/1131 ShadowNinja I'm gonna merge this tonight if you don't have additional comments |
| 18:36 |
|
Jordach joined #minetest-dev |
| 18:38 |
|
NakedFury joined #minetest-dev |
| 18:41 |
PilzAdam |
sapier, I prefere 1), we have to bump the protocol before the next release anyway |
| 18:43 |
sapier |
1 has sideeffect that we can't fix the "uninit clients stand in world" issues for clients below 0.4.9 which aren't affected by the bug |
| 18:43 |
sapier |
well I should mention this in the issue |
| 18:45 |
VanessaE |
sure you can. |
| 18:46 |
VanessaE |
don't let the player "appear" in the world, from the server's perspective, until you receive the first movement packet of some kind |
| 18:46 |
VanessaE |
from the client's perspective, of course, just do whatever you normally would have done |
| 18:46 |
sapier |
what do you think about hmmmm's suggestion making clients tell server about their version? The problem is we don't really like version numbers but for situations like the current one it's be great |
| 18:47 |
VanessaE |
just don't send the announcement to everyone ELSE that the new client is there until the new client makes some kind of movement, or maybe responds to its first ping after the server thinks it has sent all of the media |
| 18:47 |
sapier |
no I can't vanessae player appears as soon as the playercao is created |
| 18:47 |
VanessaE |
why? |
| 18:48 |
sapier |
that's why I delayed some init messages because I need information about that player cao to send it |
| 18:48 |
VanessaE |
you're the server. Therefore, you are G*d. |
| 18:48 |
sapier |
playersao |
| 18:48 |
VanessaE |
you decide when you send the announcement to the *other* clients that are connected. |
| 18:48 |
sapier |
because a playersao is just an active object and it's data is sent to clients along with all other active objects |
| 18:48 |
VanessaE |
I'm not talking about what you send to the client that's just now connecting |
| 18:48 |
sapier |
I don't intend to do a special handling for any sao |
| 18:49 |
VanessaE |
you already know how to handle the connection handshake for the client that's just now connecting, regardless of the version of the client software |
| 18:50 |
sapier |
I'd have to filter active object list for players, check against client state, and do this at each step ... well we don't need to try to improve performance if we'd add crazy things like that on the other side |
| 18:50 |
|
Taoki_1 joined #minetest-dev |
| 18:50 |
VanessaE |
I'm talking about what to do about the announcement you send to everyone else who is already connected and actively playing. Why bother sending an announcement at all until the client can move? |
| 18:51 |
sapier |
the "announcement" as in chat isn't the problem |
| 18:51 |
VanessaE |
I don't mean that. |
| 18:51 |
sapier |
the problem is the player itself as this is a plain active object |
| 18:52 |
VanessaE |
if the server can show a player that is not able to actually *do* anything yet, the server's doing it wrong. |
| 18:52 |
sapier |
no it isn't |
| 18:52 |
VanessaE |
at least up until the point where the server knows for sure that the client can't, because it is e.g. still uploading media to the client. |
| 18:52 |
sapier |
once a active object is created as of environments view its operational |
| 18:53 |
sapier |
which is completely true there's nothing wrong about a standing still active object, all dropped items are same |
| 18:53 |
VanessaE |
well from a technical standpoint of course not |
| 18:53 |
VanessaE |
but these aren't just active objects. |
| 18:53 |
VanessaE |
these aren't mobs we're talking about |
| 18:53 |
VanessaE |
these are human beings. |
| 18:53 |
sapier |
technicaly there's no difference |
| 18:54 |
VanessaE |
well derp |
| 18:54 |
VanessaE |
in th software they're the same |
| 18:54 |
VanessaE |
but you can't treat them the same way from the users' standpoint |
| 18:54 |
sapier |
well one difference, a playersao does load map while a luaso doesn't |
| 18:54 |
VanessaE |
otherwise it just. plain. looks. wrong. |
| 18:54 |
|
EvergreenTree joined #minetest-dev |
| 18:54 |
sapier |
no I HAVE to treat them same way ... any other solution will cause useless overhead |
| 18:55 |
|
EvergreenTree_ joined #minetest-dev |
| 18:55 |
sapier |
that's why I delay playersao creation till client is initialized. having a player in env which isn't operational is useless |
| 18:55 |
VanessaE |
that's what I'm trying to say |
| 18:55 |
|
EvergreenTree joined #minetest-dev |
| 18:56 |
VanessaE |
delay the creation of that object until it can actually be used/moved |
| 18:56 |
sapier |
that's what I do ;-) ant that's what causes one of the issues |
| 18:56 |
VanessaE |
for an older client, delay it until the client answers its first ping or sends its first movement event or something else, idk what |
| 18:56 |
VanessaE |
for a newer cliebnt, well it's obvious |
| 18:56 |
sapier |
hmm |
| 18:57 |
|
EvergreenTree joined #minetest-dev |
| 18:57 |
VanessaE |
I'm trying to say that if you are the server, you already KNOW that the client did or did not answer some request or perform some action you told it to perform :) |
| 18:57 |
sapier |
abusing movement as replacement for missing init message ... not sure if it works .. but could be worth a try ... who's gonna tell users they need to move to join? |
| 18:57 |
VanessaE |
within the limits of the network's lag of course |
| 18:58 |
VanessaE |
why would you bother telling them? |
| 18:58 |
sapier |
because they won't complete join unless they move |
| 18:58 |
sapier |
well it's 0.4.9 only |
| 18:58 |
VanessaE |
ok so create the object when they move OR chat then |
| 18:59 |
VanessaE |
or anything else coming from the client that can't possibly be part of the media send/receive protocol |
| 18:59 |
VanessaE |
is there a way to send a "special" ping packet? |
| 18:59 |
VanessaE |
i.e. with some special tag? |
| 18:59 |
sapier |
you can send anything but you won't get an anwer from a 0.4.9 client |
| 18:59 |
|
EvergreenTree joined #minetest-dev |
| 18:59 |
VanessaE |
something that the client can respond to/echo back with the same value, that differs from the rest of the regular ping traffic I mean |
| 19:00 |
sapier |
no |
| 19:00 |
VanessaE |
damn. |
| 19:00 |
sapier |
for new clients we can do anything that's not an issue but we don't need something for new clients but only for 0.4.9 |
| 19:01 |
VanessaE |
right |
| 19:01 |
VanessaE |
that's what I'm trying to figure out |
| 19:01 |
VanessaE |
well wait |
| 19:01 |
VanessaE |
does the client answer pings AT ALL before media is finihsed sending? |
| 19:01 |
VanessaE |
finished* |
| 19:01 |
sapier |
yes ping is low level |
| 19:01 |
VanessaE |
damn |
| 19:01 |
VanessaE |
come on, work with me here :) |
| 19:02 |
VanessaE |
and I don't mean, btw, ICMP |
| 19:02 |
VanessaE |
I mean the server's own protocol |
| 19:02 |
sapier |
me too |
| 19:02 |
VanessaE |
ok, how about,. |
| 19:02 |
sapier |
old clients/servers don't have any protocol state |
| 19:02 |
VanessaE |
you know what order you're gonna send the media in |
| 19:02 |
sapier |
so you can't decide from their behaviour if they're done |
| 19:03 |
VanessaE |
just create the object right after the last file is sent, after you get the ack from that? |
| 19:03 |
VanessaE |
just assume the client is "ready" at that point. |
| 19:03 |
sapier |
no I don't know if a packet in send queue is a media packet or something else |
| 19:03 |
VanessaE |
shit. |
| 19:04 |
sapier |
that's how layering works, lower layers don't know about format of upper layers ;-) |
| 19:05 |
VanessaE |
well unless there's some low-level protocol flag no one's mentioned, there's only one thing left - rely on incoming data from the chat, movement packets, and whatever else you can glean from the client to determine it's readiness state |
| 19:05 |
sapier |
I'm gonna try about moving/chatting, but not sure if client will move a uninitialized player |
| 19:05 |
sapier |
I can't even tell the player to move as he most likely wont see this message due to spamed console |
| 19:06 |
VanessaE |
don't bother telling the player to mov |
| 19:06 |
VanessaE |
move* |
| 19:06 |
VanessaE |
the player will do that on his own anyway |
| 19:06 |
VanessaE |
I've watched them |
| 19:06 |
VanessaE |
the first damn thing EVERYONE does, if they don't say "hi" is they start looking around, trying to dig stuff, etc. |
| 19:06 |
VanessaE |
believe me, telling them to move will not be ncessary :) |
| 19:07 |
sapier |
try dig stuff without a visible map? |
| 19:07 |
VanessaE |
oh right, the map |
| 19:07 |
VanessaE |
shit |
| 19:07 |
VanessaE |
well they will still try :) |
| 19:07 |
sapier |
I don't know if this is gonna work but it's worth a try |
| 19:08 |
* VanessaE |
thinks.. |
| 19:08 |
VanessaE |
wait |
| 19:08 |
VanessaE |
the first thing you do is teleport the client to the static spawn point, right? |
| 19:08 |
VanessaE |
does not the client have to send back a packet that says "ok, I've moved to x,y,z" ? |
| 19:10 |
sapier |
I'm not exactly sure but position may be sent after player init |
| 19:10 |
|
kahrl joined #minetest-dev |
| 19:10 |
|
werwerwer joined #minetest-dev |
| 19:11 |
sapier |
yes it's first thing to be sent after init complete |
| 19:12 |
VanessaE |
meaning? |
| 19:12 |
sapier |
movement may not be sent to server prior init at all |
| 19:12 |
VanessaE |
ok, so we can at least use that to some degree |
| 19:12 |
VanessaE |
but does that apply to the static spawnpoint? |
| 19:13 |
|
ShadowBot joined #minetest-dev |
| 19:13 |
sapier |
yes spawn position isn't sent prior init complete |
| 19:13 |
VanessaE |
ok so we can use that |
| 19:14 |
VanessaE |
send two events there. |
| 19:14 |
VanessaE |
teleport the player to like 1,1,1 and then to the real spawn point. |
| 19:14 |
VanessaE |
that way they will always be sure to move at least once. |
| 19:14 |
sapier |
I can't telport "nothing" to somewhere |
| 19:14 |
VanessaE |
fuck |
| 19:14 |
VanessaE |
:D |
| 19:15 |
VanessaE |
right |
| 19:15 |
VanessaE |
but we have a hook now |
| 19:15 |
VanessaE |
you can see where I'm going with this |
| 19:15 |
sapier |
exactly the situation is completely messed up by now noone did really find a good option |
| 19:15 |
VanessaE |
you wait for the first movement event....which we now know will be the static spawn point transport. |
| 19:16 |
VanessaE |
wait, chicken and egg |
| 19:16 |
VanessaE |
shit |
| 19:16 |
sapier |
I'm quite sure I wont ever see a movement event but I'm gonna have a try |
| 19:16 |
sapier |
maybe client is as buggy as server and sends movement events without beeing initialized |
| 19:16 |
VanessaE |
maybe :() |
| 19:16 |
VanessaE |
:)] |
| 19:16 |
|
Guest38705 joined #minetest-dev |
| 19:17 |
VanessaE |
wait |
| 19:17 |
VanessaE |
hrm |
| 19:17 |
VanessaE |
this bugs me. I can see a way here, somehow. |
| 19:18 |
sapier |
well doing it this way any movement (on old and new clients) will cause the client to complete init |
| 19:19 |
sapier |
not sure if pressing a cursor in load screen will result in movement event :-) |
| 19:19 |
VanessaE |
heh |
| 19:19 |
VanessaE |
I doubt it |
| 19:19 |
sapier |
I'd not be too surprised |
| 19:22 |
|
Miner_48er joined #minetest-dev |
| 19:24 |
|
bas080 joined #minetest-dev |
| 19:24 |
VanessaE |
I guess then what' |
| 19:24 |
VanessaE |
I guess then what's needed is an extra flag attached to the player object that says whether it can be announced to the rest of the world. |
| 19:25 |
VanessaE |
create the object as late as you can reliably do so, then flip the flag and announce it when the client will let you (e.g. when it responds to the teleport-to-(1,1,1)-then-to-spawn commands or something) |
| 19:26 |
sapier |
no |
| 19:26 |
sapier |
that's change for all active objects we have to live with forever just to fix a single broken version |
| 19:26 |
VanessaE |
no? :) |
| 19:27 |
|
Ritchie joined #minetest-dev |
| 19:28 |
sapier |
no that's not a sane option. I don't have a problem to add a workaround function but adding flags to a generic datastructure used for hundreds and thousands of objects is something completely different |
| 19:28 |
VanessaE |
ok |
| 19:29 |
VanessaE |
well I was only thinking of one bit tucked away somewhere off in no-man's land :) |
| 19:29 |
VanessaE |
but I get your point |
| 19:29 |
VanessaE |
if my idea of using movement/chat activity to complete the join doesn't work, then we're kinda screwed though |
| 19:31 |
kahrl |
if I may ask, what are some of the cases where minetest would send TOSERVER_RECEIVED_MEDIA before httpfetch inclusion but wouldn't after? |
| 19:32 |
sapier |
yes kahrl it was always sent before and afterwards it's only sent if everything was present right from start |
| 19:33 |
sapier |
and it could still be broken for curl mode in current dev |
| 19:33 |
sapier |
I didn't have time to investigate a issue sokomine mentioned that points to this direction |
| 19:33 |
kahrl |
I don't remember it that way |
| 19:34 |
kahrl |
I thought, without remote_media, it would never send it, and with, it would send it immediately (even before having received everything) |
| 19:34 |
kahrl |
this seems correct, when looking at commit 0404bbf671 |
| 19:34 |
sapier |
well as far as I know it's been always sent after all media was received |
| 19:35 |
|
OWNSyouAll joined #minetest-dev |
| 19:35 |
kahrl |
sending it immediately was the reason for the bug with the .x files that VanessaE probably remembers |
| 19:36 |
sapier |
there may be multiple bugs in this area |
| 19:36 |
kahrl |
yeah |
| 19:36 |
VanessaE |
kahrl: yep |
| 19:36 |
|
EvergreenTree joined #minetest-dev |
| 19:36 |
|
EvergreenTree joined #minetest-dev |
| 19:36 |
sapier |
immediatly is as wrong as never send it ;-) |
| 19:36 |
|
xyz|imag1nary left #minetest-dev |
| 19:36 |
|
Taoki joined #minetest-dev |
| 19:37 |
|
EvergreenTree joined #minetest-dev |
| 19:37 |
kahrl |
well not sending it is not always a bug |
| 19:38 |
|
EvergreenTree joined #minetest-dev |
| 19:38 |
sapier |
VanessaE your idea could work, client is as buggy as client and sends position updates without knowing it's initial pos |
| 19:38 |
VanessaE |
sapier: ah good, so maybe we can rely on that, then |
| 19:38 |
sapier |
as of writing a simple protocol it is :-) |
| 19:38 |
VanessaE |
sapier: why do I feel as if we just reverse-engineered the protocol a bit? :D |
| 19:38 |
|
Zeitgeist_ joined #minetest-dev |
| 19:38 |
|
Zeitgeist_ joined #minetest-dev |
| 19:39 |
sapier |
of course you can always "guess" what state client is ... but it's way more easy to handle if you do correct handling |
| 19:39 |
kahrl |
because the way the protocol works (worked?) is: the server considers the client initialized if TOSERVER_RECEIVED_MEDIA has been received or TOCLIENT_MEDIA has been sent |
| 19:39 |
sapier |
yes but that was wrong |
| 19:39 |
kahrl |
no, it wasn't wrong |
| 19:39 |
sapier |
it is |
| 19:40 |
sapier |
TOCLIENT_MEDIA isn't a single packet to be sent but will take some (more) time to complete |
| 19:41 |
sapier |
therefore client isn't initialized completely |
| 19:41 |
sapier |
that doesn't matter if you have just a few kb of textures of course ... but if its some mb it does |
| 19:41 |
kahrl |
anything that requires the client to have all media is in reliable packets, isn't it? |
| 19:42 |
kahrl |
so it would be delivered after the media anyways |
| 19:42 |
sapier |
no it wont |
| 19:42 |
sapier |
as reliable has multiple channels |
| 19:42 |
kahrl |
are those actually used? |
| 19:42 |
sapier |
yes that's been one of the most important fixes to reduce lag |
| 19:44 |
kahrl |
I see |
| 19:44 |
kahrl |
so it's a bug now |
| 19:44 |
sapier |
no <= 0.4.8 seem to work fine |
| 19:44 |
sapier |
it's only 0.4.9 |
| 19:45 |
sapier |
we should've investigated why pre0.4.9 couldn't connect to redcrabs server, we'd have found the issue before |
| 19:45 |
kahrl |
there is no code in 0.4.8 to send TOSERVER_RECEIVED_MEDIA if remote_media is not used |
| 19:45 |
kahrl |
so I don't know what happens |
| 19:46 |
sapier |
you're talking about a texture pack? |
| 19:47 |
kahrl |
huh? |
| 19:47 |
sapier |
what do you mean with remote_media? |
| 19:48 |
sapier |
curl based fetching or in protocol handling? |
| 19:48 |
sapier |
or is there another option? |
| 19:48 |
kahrl |
the setting in (the server's) minetest.conf as well as the field in TOCLIENT_ANNOUNCE_MEDIA |
| 19:49 |
kahrl |
if that field is empty or the client is compiled without curl, TOSERVER_RECEIVED_MEDIA won't be sent |
| 19:49 |
sapier |
ok I guess I wasn't aware of that issue maybe we have another bug to fix |
| 19:50 |
sapier |
I'll check that server setting. |
| 19:53 |
|
iqualfragile joined #minetest-dev |
| 20:01 |
VanessaE |
sapier: and disable your damned proxy :P |
| 20:02 |
|
Ritchie joined #minetest-dev |
| 20:09 |
sapier |
no :-) I don't wanna have your workaround problems ;-P |
| 20:09 |
VanessaE |
hah! |
| 20:09 |
sapier |
I'm fine with plain old minetest texture downloading :-) |
| 20:09 |
sapier |
don't need curl to get my textures :-) |
| 20:11 |
VanessaE |
well you're also gonna miss some protocol stuff if you don't |
| 20:11 |
VanessaE |
you already know that...... |
| 20:12 |
sapier |
well there are others who can find those issues maintainer doesn't mean I'm the only one to find and fix bugs ;-P |
| 20:12 |
VanessaE |
true but if you're hunting a bug, you need a clean feed so you can see what the rest of us see :) |
| 20:12 |
|
Calinou joined #minetest-dev |
| 20:13 |
VanessaE |
kahrl: fwiw, I DID report the redcrab issue when it was first noticed; Sokomine brought it to my attention and I traced it back to your httpfetch commit :( |
| 20:13 |
sapier |
I'll never see what all of you see as there are way to many possible variants ... some thing we should get rid about but can't |
| 20:14 |
sapier |
well no need to blame anyone we all could've realized this to be a critical bug but didn't |
| 20:14 |
VanessaE |
oh no no no, no blame at all. |
| 20:14 |
VanessaE |
I just mean that no one chose to look into it (though it was acknowledged) |
| 20:23 |
|
harrison joined #minetest-dev |
| 20:25 |
sapier |
vanessaE sadly your idea doesn't work, position is sent right from the beginning |
| 20:25 |
VanessaE |
fuck. |
| 20:26 |
|
rsiska joined #minetest-dev |
| 20:28 |
VanessaE |
but wait |
| 20:28 |
VanessaE |
you got the position from the client |
| 20:28 |
VanessaE |
which means you have an active object already |
| 20:28 |
sapier |
client has an object |
| 20:28 |
VanessaE |
at that point, where do you stand? |
| 20:28 |
sapier |
but server doesn't |
| 20:28 |
VanessaE |
what does the server know about the client? |
| 20:29 |
sapier |
by that time only it's peer id |
| 20:29 |
VanessaE |
shit |
| 20:29 |
VanessaE |
you're not making this very easy, sapier :) |
| 20:29 |
sapier |
and protocol/serialization vesion but that won't help |
| 20:29 |
sapier |
well I can't fix bugs to the past ;-) |
| 20:29 |
VanessaE |
at this point, media has not been sent? |
| 20:34 |
|
Jordach joined #minetest-dev |
| 20:34 |
sapier |
no media hasn't been sent but client sends position |
| 20:34 |
VanessaE |
ok |
| 20:35 |
VanessaE |
not much to be done I guess |
| 20:35 |
sapier |
no we're quite out of options |
| 20:35 |
VanessaE |
give up and bump the protocol version. |
| 20:35 |
VanessaE |
new server version, new clients only I guess. |
| 20:36 |
VanessaE |
just make sure to fix the bugs that new clients get with old servers of course |
| 20:36 |
sapier |
no only new clients isn't an option |
| 20:36 |
sapier |
imho the only thing to decide is: |
| 20:37 |
sapier |
accept 0.4.9 clients to fail and mak older clients work fine or make al clients behave bad but not fail |
| 20:37 |
VanessaE |
you mena when connecting to old servers? |
| 20:37 |
VanessaE |
mean* |
| 20:37 |
sapier |
no old clients connecting to new server |
| 20:38 |
VanessaE |
I dunno |
| 20:38 |
VanessaE |
to my mind, if it can be fixed to behave the *right* way then it needs to be fixed. |
| 20:38 |
VanessaE |
anything less is just plain wrong |
| 20:39 |
VanessaE |
if that means older clients have to continue to behave wrongly (but with server workarounds to make sure they still work) then I guess that's what has to be done |
| 20:39 |
sapier |
that's option two |
| 20:40 |
VanessaE |
so current client on current server behaves perfectly right, current client on old server behaves as best as it can hope to, old client on current server behaves "wrongly" but still works, old client on old server just does what it's always done because we can't change the past. |
| 20:40 |
VanessaE |
sound okay? |
| 20:41 |
VanessaE |
(where "wrongly" means it appears in the world and just sits there until it can work, like it always used to) |
| 20:41 |
sapier |
yes ... but old in this case puts all old clients to same behaviour ... while all but 0.4.9 would work |
| 20:42 |
sapier |
unless we did increase protocol level for 0.4.9 |
| 20:42 |
VanessaE |
well do we really need to care if e.g. 0.4.8 works the same way as 0.4.9 does in this regard? |
| 20:42 |
VanessaE |
just as long as it *works* I mean? |
| 20:42 |
sapier |
all of your android clients are pre 0.4.9 |
| 20:42 |
VanessaE |
nope, some of those apparently are 0.4.9 |
| 20:43 |
VanessaE |
they have post-0.4.9 shaders e.g. waving leaves/water |
| 20:43 |
VanessaE |
(yeah, it surprised me, too) |
| 20:43 |
sapier |
hmm ok that changes situation |
| 20:43 |
VanessaE |
I have such a client on my tablet. |
| 20:44 |
sapier |
hmm we forgot to mention what changed in protocol version 22 |
| 20:44 |
VanessaE |
and when I last checked, those shaders required engine changes as well as the glsl code, so that puts them in 0.4.9-era code, no? |
| 20:47 |
|
sapier1 joined #minetest-dev |
| 20:47 |
sapier1 |
hmm 0.4.9 could be identifyable by protocol version |
| 20:47 |
VanessaE |
perhaps |
| 20:47 |
sapier1 |
yes ... that's the option we've been looking for ... protocol was bumped to 22 at november 23rd |
| 20:50 |
VanessaE |
November is rather a while back...... |
| 20:52 |
sapier1 |
yes but post 0.4.8 and pre 0.4.9 |
| 20:54 |
VanessaE |
hm |
| 20:54 |
VanessaE |
well |
| 20:54 |
VanessaE |
I guess you could use that as a filter I suppose |
| 21:01 |
|
salamanderrake joined #minetest-dev |
| 21:04 |
|
salamanderrake joined #minetest-dev |
| 21:13 |
ShadowNinja |
sapier: For your kick player pull you should use lua_tostring (as hmmm mentioned), add a comment after , and show the parameters and return value in the cumment above the declaration (// kick_player(name, [message]) -> success) Then you can push it. |
| 21:14 |
ShadowNinja |
comment* |
| 21:14 |
ShadowNinja |
(In header and source file, the ban functions have to be fixed, and maybe more, you can do that in a seperate commit) |
| 21:15 |
sapier |
no I wont do that at all ... I've got enougth work about fixing network server issues ... I'll only fix the kick related things once I have time to do so |
| 21:16 |
ShadowNinja |
sapier: As for bind_address: It shouldn't be in the menu as it's a very advanced feature. And it shouldn't be labeled "Address:", it should be labelled "Bind address:". |
| 21:16 |
ShadowNinja |
I'll do it then. |
| 21:16 |
sapier |
ok then I'm gonna drop that pull and rebase yours |
| 21:17 |
sapier |
meanin you have to rebase yours |
| 21:17 |
ShadowNinja |
What? |
| 21:18 |
sapier |
I wont write that multiple times just because you don't like it... if you're that picky about adding a new feature you'll have to provide a mergable pull request yourself ... sorry if this sounds rude but I can't allways do all the work I have other things to do too |
| 21:20 |
sapier |
It's a low prio enhancement while I tried to merge it but as it's not accepted I can live with it beeing out of master for some more times too |
| 21:21 |
|
SmugLeaf joined #minetest-dev |
| 21:24 |
ShadowNinja |
I just asked you to remove the main menu section, but I'll remove it myself if I must. Just leave the pull up for a bit longer. |
| 21:25 |
sapier |
I want that thing to be closed imho having a server option not available on gui is crap especialy if it's that easy to add. it's way more consistent |
| 21:26 |
sapier |
if you start server in dedicated mode it'll be bound to port start same thing with gui not ... that's inconsistent |
| 21:28 |
ShadowNinja |
I'll push your pull + http://ix.io/aiG and squashed in a few minutes. |
| 21:29 |
ShadowNinja |
sapier: I don't understand your second sentence. But the bind address is a advanced option that only a few people will use and will only serve to confuse most users. |
| 21:29 |
sapier |
seens to be fine |
| 21:30 |
sapier |
those users won't see it |
| 21:30 |
ShadowNinja |
And we don't want to bloat the GUI with options that most people won't use. |
| 21:30 |
sapier |
it's just hard to explain why a server will ignore a setting if run in gui |
| 21:30 |
sapier |
you didn't even try it did you? |
| 21:31 |
sapier |
only those users which already set that address will see it |
| 21:32 |
sapier |
noone else |
| 21:35 |
|
robmyers_ joined #minetest-dev |
| 21:38 |
|
yno_ joined #minetest-dev |
| 21:38 |
|
Tesseract joined #minetest-dev |
| 21:38 |
|
Weedy joined #minetest-dev |
| 21:41 |
|
realbadangel_ joined #minetest-dev |
| 21:41 |
|
darkrose_ joined #minetest-dev |
| 21:41 |
|
Robby_ joined #minetest-dev |
| 21:43 |
|
darkrose joined #minetest-dev |
| 21:47 |
|
ImQ009 joined #minetest-dev |
| 21:48 |
sapier |
VanessaE you could try this fix for 0.4.9 clients https://github.com/sapier/minetest/tree/silence_hud_errormessage |
| 21:49 |
Tesseract |
[16:33:51] <ShadowNinja> That's better, but it means that we won't be able to put anything else at that position. And the label needs to be changed either way. |
| 21:50 |
sapier |
what are you talking about? |
| 21:50 |
ShadowNinja |
<sapier> only those users which already set that address will see it noone else |
| 21:51 |
sapier |
well I used only room already used now so you'd have to change layout anyway if you want to place something else there |
| 21:52 |
ShadowNinja |
It overlaps with something? |
| 21:53 |
sapier |
no I just split the now oversized "Port" field to two fields |
| 21:53 |
sapier |
ok I increased it a little bit ... but that'd not be enough room to add anything else |
| 21:56 |
ShadowNinja |
Alright. |
| 21:56 |
sapier |
maybe we should ask for a third opinion |
| 21:56 |
|
Jordach joined #minetest-dev |
| 22:08 |
Calinou |
why not use : to separate address and port? |
| 22:08 |
Calinou |
if none, use default port |
| 22:08 |
Calinou |
(it is probably possible to detect IPv6 address) |
| 22:08 |
sapier |
it's not about port but about ip binding |
| 22:09 |
sapier |
e.g. if your server has a internet ip and a local ip |
| 22:16 |
ShadowNinja |
It seems fine if it's done that way, as long as it's labeled Bind address and the 0.0.0.0/:: check is removed. |
| 22:17 |
sapier |
well that check is there to reset the bind_addr setting |
| 22:17 |
sapier |
both are the most simple way to write a bind all addr |
| 22:18 |
sapier |
of course there are other ways to specify 0 addresses too |
| 22:18 |
ShadowNinja |
Just empty the field. |
| 22:18 |
sapier |
ok I'm fine with that solution too |
| 22:33 |
ShadowNinja |
I added a reason field to the kick command: http://pastebin.ubuntu.com/6869744/ |
| 22:33 |
ShadowNinja |
s/<reason>/[reason]/ |
| 22:34 |
sapier |
ok |
| 22:37 |
ShadowNinja |
sapier: This is a bit over-indented, can you fix that? https://github.com/minetest/minetest/blob/ea0def381da04d3704a51b8a31a78ddd0737a06a/src/pathfinder.cpp#L63 |
| 22:37 |
sapier |
not yet |
| 22:37 |
sapier |
it's fine for 4 space alingnment |
| 22:38 |
sapier |
it's aligned to function length |
| 22:39 |
ShadowNinja |
command_return_values updated... |
| 22:39 |
sapier |
all parameters should be moved to next line, but I don't do code style fixes only ... if I did do that there's no end |
| 22:40 |
ShadowNinja |
Yes, it shouldn't depend on tab width, it should be two tabs. |
| 22:40 |
sapier |
code style not depending on tab width is a nice wish but only true within some limits |
| 22:41 |
sapier |
but as I wont change anything now there's no need to discuss this again |
| 22:42 |
ShadowNinja |
It doesn't. Although these's one file(script/common/c_content.h?) that keeps everything aligned perfectly with spaces, but everything is so spread out... |
| 22:42 |
* ShadowNinja |
tries to fix #1111. |
| 22:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/1111 -- Allow custom types in minetest.register_craft |
| 22:42 |
sapier |
we need a full doc of code style, reference to some more or less fitting kernel style is useless |
| 22:43 |
sapier |
what's a custom type? |
| 22:45 |
ShadowNinja |
Eg, minetest.register_craft({type="alloy", input={...}, output="..."}) |
| 22:46 |
ShadowNinja |
Seems the types are built into the engine deeper than I thought though... |
| 22:47 |
sapier |
if I remember correctly that issue has been discussed to death about a month ago |
| 22:47 |
sapier |
resulting in "is possible but gives almost no benefit while breaking quite a lot" |
| 22:49 |
ShadowNinja |
It lets you easily define your own craft recipes. And it won't break anything if done right. |
| 22:50 |
sapier |
well try to find that discussin I believe it was on minetest. |
| 22:50 |
ShadowNinja |
It's definitely very difficult to fix though... |
| 22:52 |
sapier |
yes it's core functionality not lua |
| 22:52 |
|
book` joined #minetest-dev |
| 22:52 |
sapier |
the only way to fix it would be move it to lua ... with all consequences |
| 22:53 |
sapier |
maybe adding some dummy "custom craft" type would be possible too ... but that be as hacky as technic does it |
| 22:53 |
sapier |
it's quite useless to have it "look like" a core feature but actually do same |
| 22:55 |
ShadowNinja |
I fixed #1099 instead: http://ix.io/aiP |
| 22:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/1099 -- Texture packs with "[" in the name causes the Texture Packs menu to not draw. |
| 22:56 |
ShadowNinja |
sapier: Fine if I commit and push that? |
| 22:56 |
sapier |
yes but I still think [] as folder name is crap :-) |
| 22:57 |
ShadowNinja |
Maybe so, but no reason to let itbreak the menu. |
| 22:57 |
sapier |
it's my personal opinion only so fixing it will not harm anyone |
| 22:58 |
sapier |
especially as forbidding seems to be way more work then fixing |
| 23:14 |
ShadowNinja |
Error in on_globalstep crash fix: http://ix.io/aiQ |
| 23:16 |
|
robmyers joined #minetest-dev |
| 23:17 |
sapier |
maybe that's the one still bugging me |
| 23:29 |
VanessaE |
what's the word about the ${text} bug? |
| 23:30 |
* VanessaE |
pokes sapier |
| 23:30 |
VanessaE |
(I can't discuss the specifics here, logs) |
| 23:39 |
sapier |
nothing done by now |
| 23:39 |
sapier |
maybe shadow is interested in fixing? |
| 23:40 |
sapier |
I need to get some sleep ;-) |
| 23:40 |
ShadowNinja |
Hmmm, maybe... |
| 23:44 |
ShadowNinja |
It looks like it won't work in current master, but I don't see xyzz's temporary fixer commit. |
| 23:45 |
|
Zeitgeist_ joined #minetest-dev |
| 23:46 |
ShadowNinja |
Ah, sapier fixed it. |
| 23:51 |
|
us_0gb joined #minetest-dev |
| 23:53 |
|
grrk-bzzt joined #minetest-dev |
| 23:53 |
|
bas080 joined #minetest-dev |
| 23:55 |
ShadowNinja |
This should fix it: http://ix.io/aiT |
| 23:56 |
ShadowNinja |
I'd like to add proper in-string formating so that you can use "Locked chest (owned by ${owner})" and the like. |
| 23:58 |
VanessaE |
that seems useful for infotext, yes |
| 23:59 |
VanessaE |
ok |
