Time  Nick      Message
16:54 paramat   well tested and ready #8473
16:54 ShadowBot https://github.com/minetest/minetest/issues/8473 -- Dungeons: Settable density noise, move number calculation to mapgens by paramat
20:12 Krock     paramat: why do you make it a pointer in https://github.com/minetest/minetest/pull/8473/files#diff-a36a0ee19e510b3bdb49d816a1198c3dR286 but in https://github.com/minetest/minetest/pull/8473/files#diff-4e367915b1e5eb6f277dea42041d9416R111 ?
20:16 paramat   i guess you mean '... but not in ...'. erm, because it works this way =) i'm not good with pointers
20:18 paramat   i can't remember why actually, it might be wrong
20:21 paramat   oh, it might be because mgv6 doesn't use class 'mapgenbasic'
20:21 paramat   'mapgenbasic' is something shared between all the other mapgens
20:23 paramat   as far as i can remember, i changed what i needed to change to avoid compilation errors, and this is how it turned out. but yes it could be wrong as i don't fully understand the use of pointers
20:24 * Krock   checks out
20:26 Krock     pointers aren't that complicated. they just point to the memory where the actual data is
20:31 Krock     I now see how this worked with pointers. The noise parameters originate from the map settings which are read once, and kept in memory until the server is shut down
20:32 Krock     ServerMap::settings_mgr
20:34 Krock     paramat: May I push a commit onto your branch to adjust the dungeon noise parameter member type to the ones from cave1/cave2?
21:27 paramat   sorry, was away. can i view your change first?
21:30 paramat   i don't understand what you mean by 'adjust member type'. is this to correct a mistake?
21:31 paramat   afk for 30 mins
21:52 paramat   thanks for the offer but i prefer to make the change myself, to keep this PR simple. please could you paste your patch diff in a comment?
21:52 paramat   oh they're gone heh
23:25 VanessaE  Minetest needs a shorter disconnect timeout, I've got players who report having been disconnected (nevermind the reason) still being able to play for several minutes before the client goes "HEY, it broke!".
23:25 VanessaE  if there's some kind of keepalive that keeps running even when the server is lagging (i.e. some separate thread), then 30s seems more reasonable.
23:26 p_gimeno  I've had lags of more than 1 minute
23:26 VanessaE  yeah but I mean if the actual network connection is still alive.
23:27 VanessaE  nevermind if the server's being bogged down by Lua.
23:27 VanessaE  even 1 minute is a LONG time when you're actively building.
23:27 VanessaE  the client maybe ought to display a warning somewhere, too, if the connection goes down for more than, say, 10s.  Just some icon in a corner of the window that suggests a broken network connection
23:28 VanessaE  (i.e. something totally passive, that goes away on its own, without interrupting the player)
23:28 p_gimeno  I may be wrong, but I think that if the server is bogged down by Lua for long enough, you get a timeout because nothing keeps the connection alive
23:29 VanessaE  well that needs to be corrected imho.  my reasoning is simple:  if it's engine/Lua lag, then everything the player has done during the lag should theoretically be applied when the server catches up, but if the underlying network dies, the player needs to know that his/her actions are about to be discarded.
23:31 VanessaE  hence that icon I suggested.
23:32 p_gimeno  ok, if I understand it correctly, you propose adding a keepalive thread that informs the client that the server keeps the connection open
23:33 VanessaE  actually, I was assuming such a thread already existed, and should used to improve UX.
23:33 VanessaE  I mean, isn't there *already* a periodic keepalive packet?>
23:33 VanessaE  like every 10s or something?
23:34 p_gimeno  I'm not into how the networking works, I guess there's something, but I don't think there's a thread dedicated to it
23:35 VanessaE  yeah, looking at F5, looks like there's a periodic keepalive, every 2-4 seconds.
23:36 p_gimeno  AFAIK the threads are 1 server, 1 client and N emerge
23:37 p_gimeno  (where the server thread deals with Lua, network and everything else)
23:37 VanessaE  huh.  I thought there were moree.
23:37 VanessaE  -e
23:37 VanessaE  well that needs corrected for sure.  this ain't 1990, processors aren't limited to just one core anymore :P
23:38 VanessaE  having a user sit there actively building only to find they have been disconnected for the last 5 mins is bad UX.
23:39 VanessaE  think of it like a website.  how long does a browser give the site to respond before timing out?
23:40 VanessaE  about 1 minute isn't it?  even that's way too long; the user won't give a site more than 5-10 seconds before they move on, so says some studies I've read about (6s being the average)
23:41 p_gimeno  yeah but as everything, you have to find someone to bell that cat, and threaded code is very delicate and prone to bugs that are very hard to find and trace
23:41 VanessaE  I Know.
23:42 VanessaE  mod coding is like that.  it may all be single-threaded, but in a complex mod that also happens to be very fast, you get a lot of the behavior of a multi-threaded environment.
23:48 VanessaE  still, I hope you agree with the basic premise that letting the player build when they're not even online is generally a bad idea :)
23:49 p_gimeno  yeah I agree, I just see the effort to implement that a bit unbalanced with the benefit
23:50 VanessaE  I dunno..
23:51 VanessaE  servers crash.  a lot.
23:51 VanessaE  often without closing the connection properly.
23:52 VanessaE  the "5 minute" thing refers to one that happened today, due to an ordinary mod bug
23:52 VanessaE  somehow, the server went down just hard enough that some clients didn't get a proper disconnect
23:53 VanessaE  yesterday, I did a routine reboot (killall -INT minetestserver) to bring in some mod updates, and one of my players (different person) reported having been disconnected for a solid 2 minutes before the client threw an error.