Time Nick Message
09:50 IhrFussel Why is the forum so slow lately?
09:51 IhrFussel It can take up to 10 secs to load one page
09:51 IhrFussel Really not pleasant to browse like this
09:52 Krock *shrug*
10:12 Krock > Also it's hardly possible to play MT with "200ms RTT and high packet loss"...
10:12 Krock lolwhat
10:13 Krock a server step of 0.2 is quite common
10:13 Krock combining both results in almost half a second of delay, still good enough for gameplay
10:17 IhrFussel Most servers with many heavyweight mods generally have a lag higher than the actual server step
10:17 IhrFussel I'm quite happy with my 0.2-0.4 max lag mostly
10:20 IhrFussel My server step is set to 0.15 but realistically the server cannot keep it at that as soon as 3 people joined
12:50 IhrFussel To fight the map stalling issues that occur whenever too many certain app users with random names connect I now implemented a command that blocks these users for 15 minutes ... that should help with random flooding
13:38 rdococ can luacontrollers store functions?
13:50 BuckarooBanzai IhrFussel: how about migrating to 5.x? :D
13:51 IhrFussel Since the devs don't even know (yet) what exactly causes those issues I'm fairly certain that the exact same apps will be able to stall 5.X servers as well should they ever update to that engine version
13:53 IhrFussel The most likely cause is a 'full map sending queue' somehow ... cause when it happens only nodes on the map and meta info are blocked (inventories don't work either, not sure if that only applies to storage nodes)
13:54 IhrFussel Setting max block sends per client to 20 doesn't fix it
13:54 Krock sad but true
13:55 IhrFussel Oh writing on signs doesn't work either when it happens...so yes definitely something is blocking map nodes and meta
13:57 IhrFussel Moving into unloaded map areas while attached to an entity makes the screen stutter a lot
13:58 IhrFussel But it looks like the client still knows about stairs/slabs etc
13:59 IhrFussel Cause in my test case the car suddenly went up a little in the void...exactly where stairs should be
14:03 IhrFussel Here you can clearly see that the client DOES know about the snow levels and also the extreme stutter https://ihrfussels-server.de/cardemo.mp4
14:05 IhrFussel The protections at the bottom also update correctly depending on the position in the void
14:06 IhrFussel To me it feels like the client gets the necessary terrain data from the server but something blocks it from loading it and making it walkable
14:08 IhrFussel With noclip I can fly into the void and all entities will load correctly so all that works
14:11 BuckarooBanzai IhrFussel: nice video, but AFAIK the car gets the coords from the server, and the blocks are still loaded/recognized on there...
14:12 IhrFussel Yes but it is kinda weird that the client still knows where the car needs to step up/go down with no visible nodes
14:13 Krock interesting. this again confirms that there's a stall in the block sending code
14:13 Krock the client does not know where the car will drive
14:13 Krock or can you walk on the nodes without the car? probably not
14:13 BuckarooBanzai it would all be "ignore" nodes on the client...
14:14 IhrFussel Without being attached to an entity you cannot move at all unless you use noclip
14:14 * BuckarooBanzai pulls out wireshark...
14:14 BuckarooBanzai :P
14:15 IhrFussel So you mean the server stells the car that there is some obstacle and then it steps up?
14:15 Krock yes
14:15 IhrFussel tells*
14:15 Krock it rather sends the car position very frequently
14:15 Krock you should see that in the F5 profiler
14:17 IhrFussel Yeah whenever the screen does a 'hiccup' the position slightly changes in F5
14:20 IhrFussel But wait maybe I was wrong that meta cannot be send during that stall... cause the signs I use are from signs_lib ... and those take the meta from the sign node and generate an entity with the value from local text = meta:get_string("text")
14:20 IhrFussel And the text itself actually displays in the void
14:21 BuckarooBanzai I believe: mapdata != entity-data (on the client at least)
14:22 IhrFussel I know but node meta seems to work...reading at least
14:22 BuckarooBanzai On the server-side: sure, looks like it...
14:25 IhrFussel So could the screen stutter actually be server steps?
14:27 BuckarooBanzai IhrFussel: how good is your C++ knowledge? Maybe a first step would be to profile the mapsending code (which ip / how much mapblocks/data is sent to what client)
14:31 IhrFussel I have about zero knowledge regarding c++ =/ Here is another video that shows that the monster can't even see me in the void it seems https://ihrfussels-server.de/stalldemo.mp4
14:36 IhrFussel Ignore the last video, I was inside a wall
14:49 IhrFussel Okay yeah I can confirm that the position in F5 only updates every step (0.15 secs in my case) when entering the void attached to an entity
14:50 IhrFussel And that is also when the stuttering happens ... so basically the client suddenly doesn't know what's there anymore but the server tells the client to update the visuals anyways
14:55 * BuckarooBanzai looks at https://github.com/minetest/minetest/blob/master/src/server.cpp and runs away from the 3700 LOC in there... :X
15:04 IhrFussel Krock, when you say 'queue' do you mean a certain setting that can be changed? Like disk queue? Or is that something entirely internal
15:05 Krock well yes, there's a total limit https://github.com/minetest/minetest/blob/master/src/server.cpp#L2287
15:05 Krock for 0.4.x that also means increasing the per_server setting to some high value
15:07 IhrFussel So you mean setting max_simultaneous_block_sends_per_client to something very high should help with it?
15:09 IhrFussel I don't even know how those apps can request so many more blocks at once...do they fake their positions and jump around? There is a max distance setting for block sending
15:09 IhrFussel On my server it is 5 so max a radius of 5 blocks around the player
15:15 IhrFussel WAIT
15:15 IhrFussel 0.4 doesn't even use per_client??
15:15 IhrFussel I only find max_simultaneous_block_sends_server_total
15:25 Krock it uses both
15:26 Krock players can't jump around without the server's permission. that would trigger anticheat
15:30 IhrFussel But if the per_client would only be full wouldn't the server simply skip the user and go to the next one?
15:31 IhrFussel I think the total server queue somehow gets full ... I will try setting it to 300 and see if there are any improvements
15:32 Krock yes, that should be the case
15:33 IhrFussel I didn't define max sends total cause someone told me that it's not used anymore... so in 0.4 you need to set it still
15:34 Krock however, if the client keeps discarding the mapblock where they're in, then it tries to re-send the very same mapblock each step
15:34 Krock since it's priority-sorted, based on the distance
15:35 IhrFussel Should that be measurable via network monitoring CLI?
15:36 Krock dunno
15:36 Krock although the packet would always be the same
15:37 IhrFussel Why would the client's app discard all those blocks though ... usually those apps don't touch any code that's not relevant to ads/inapp stuff
15:38 Krock packet loss? mobile connection before timing out? dunno
15:39 IhrFussel If that is the cause there is not much we can do about it right?
15:39 IhrFussel I mean how would we fix that server side...
15:41 rdococ for my digilines scripting language, maybe I could implement futures or promises
15:41 IhrFussel Maybe limiting sending attempts and if all fail they have to wait a moment before they get blocks again
15:42 Krock well, the block could be delayed by n of sending retries
15:55 BuckarooBanzai IhrFussel: i may have the same problem as yours but it presents itself differently: every few weeks the "min-lag" is going from about 10 ms to above 100 ms and the server gets unresposive, but the server log still show activity in the forceloaded zones. In the image: https://i.imgur.com/dhqvTS3.png the lower right is the elevated min-lag. I've writ
15:55 BuckarooBanzai ten a watchdog mod (https://git.rudin.io/minetest/watchdog) exactly for that but haven't found the root cause yet...
16:07 IhrFussel My server had a similar problem in the past ... sometimes it would not react to any connections anymore and CPU% would stay at 100 all the time until I manually killed the process ... it fixed itself after I updated the MT version though
17:28 rdococ what programming paradigm should I use for a digilines language?
17:46 Krock digicode
17:47 rdococ I was thinking of calling the language digilang
17:57 Krock call it AIDS: Advances Instructions for Digiline Setups
17:58 Krock confusion=100%
18:08 rdococ hmm... imperative is the closest to Lua, but would that be best for something that's meant to connect to a digilines network?
18:08 rdococ I guess the network is reminiscent of object-oriented programming
18:14 xerox123 o/
18:18 rdococ hi
21:02 sfan5 once again, it is time for statistics: https://kitsunemimi.pw/tmp/serverlist_stats_2019-05-19.txt
21:03 rubenwardy hahha
21:03 rubenwardy so many still on 5.0
21:04 rubenwardy also, it's 5.0.1 not 5.1.0
21:04 rubenwardy wait
21:04 sfan5 yes
21:05 rubenwardy is it protocol ver or user agent?
21:05 rubenwardy user agent
21:05 rdococ gUnknown?
21:05 sfan5 by 5.1 I mean the current dev, not 5.0.1
21:05 sfan5 5.0.1 is counted under 5.0
21:06 rdococ 4.16 is more popular than 4.17, interesting
21:06 rubenwardy why such a mismatch between server list requests and players?
21:07 rubenwardy ie: 87% on 5.0 according to serverlist, yet ~50% on 5.0 according to number of players online
21:08 rdococ lol, 1 guy probably still using Windows 2000
21:08 sfan5 might be this one app that appears (?) to be 5.0 but can't join any 5.0 server because it's an incompatible dev version
21:08 sfan5 ¯\_(ツ)_/¯
21:09 rdococ weren't there dev versions that called themselves 0.5.0-dev before the 0. was dropped?
21:10 sfan5 I didn't count those, so they appear under "unknown"
21:11 rdococ I'm sad there are no time travellers using 6.0