Time Nick Message 00:16 OldCoder iqualfragile VanessaE they improve performance if turned up? 00:16 OldCoder Faster at tradeoff for memory? 00:17 VanessaE depends on your pipe really 00:17 VanessaE I stopped at 500, I am not sure if going higher will be any better 00:17 VanessaE but up to THAT point, it was. 00:17 VanessaE as sapier explained it, it's the number of blocks that can be "on the wire" at any one time. 00:18 OldCoder kkty 00:44 celeron55 those are all about network performance 00:45 celeron55 if your connection gets congested, that's the lag the players will get 00:45 celeron55 (if blocks are being transferred) 00:46 celeron55 so, setting it to 1 will keep lag always at the minimum, but will decrease maximum speed 00:46 celeron55 in a very natural way 00:46 hmmmm whatever happened to that guy with the client sendblocks 00:46 celeron55 oh also 00:46 hmmmm client request blocks rather 00:46 celeron55 that also includes the mesh generation queue on the client 00:46 celeron55 so it will have a different effect on fast and slow machines 00:47 celeron55 hmmmm: i forked and developed it and never got it working properly; keep in mind that this was before the upstream network work by sapier, i.e. very old 00:48 celeron55 the current implementation is way better at managing network resources than that one 00:48 celeron55 but the biggest issue was that it just hanged occasionally 00:49 hmmmm i take it that you never solved the hang issue 00:49 hmmmm erm, i mean figured out what causes the hang issue 00:49 celeron55 there's a probability that it was fixed by sapier 00:50 celeron55 but really you first need to define what you're expecting to gain from using that branch 00:50 hmmmm i need to seriously un-fuck EmergeThread's block queueing before this gets solved :( 00:50 VanessaE hmmmm: client request blocks was itself blocked anyway as I recall 00:50 hmmmm celeron, better design 00:51 VanessaE it was decided that this should not be possible. 00:51 celeron55 VanessaE: afaik you are making this up 00:51 VanessaE nope.avi 00:51 celeron55 or has this been decided lately? 00:51 hmmmm i want the client to keep a d-radiused cube of mapblocks 00:52 celeron55 i don't recall this from the time that i was working on it 00:52 hmmmm like minecraft 00:52 VanessaE last time this was discussed, someone here decided quite firmly "no" 00:52 VanessaE and specifically that the server would somehow be better at deciding what the client should get than the client would. 00:52 hmmmm the exact opposite was said 00:52 hmmmm client knows best.. 00:52 hmmmm esp. with the server assuming FOV 00:52 hmmmm horrible 00:52 VanessaE hmmmm: I would have thought so, but no. that was not the consensus. 00:52 hmmmm well 00:53 hmmmm i don't know where you're getting this but it's plain technically incorrect 00:53 hmmmm client request blocks would not be blocked by anybody 00:53 * VanessaE sighs 00:53 hmmmm erase from your mind whatever you currently are thinking 00:56 VanessaE http://irc.minetest.ru/minetest-dev/2013-05-17#i_3093163 00:56 VanessaE I'm pretty sure sapier's word counts as a legit "veto" here. 00:57 hmmmm shit you're right, let's just completely drop the discussion now because some log from 1.5 years ago has sapier bringing up a concern. 00:58 VanessaE no one's saying drop it. but I'd be quite appreciative if folks would discard the "you are making this up" and the like. 00:59 hmmmm here: 01:00 VanessaE http://irc.minetest.ru/minetest-dev/2014-04-18#i_3655854 01:00 VanessaE there, a little more recent then. 01:00 hmmmm 1). client doesn't need to guess what blocks have been invalidated. the server can still send those 01:00 hmmmm 2). throttling individual clients is quite trivial 01:00 hmmmm 3). this would eliminate the need for the server to guess or have to spend time calculating the client's FOV 01:01 hmmmm 4). this is better design to begin with 01:01 VanessaE agreed on all points. 01:01 hmmmm 5). the client can prioritize which blocks 01:07 celeron55 i can see various issues in this though, it might not be so simple to get it work in a way that doesn't work worse in practice 01:09 celeron55 for example, the current block selection thing also sends updated blocks to the client, and even prioritizes those too 01:12 hmmmm the server assumes which blocks the client has though 01:12 hmmmm are blocks sent as reliable? (i forget) 01:12 celeron55 of course they are 01:13 celeron55 how would you expect it to work otherwise 01:13 celeron55 they generally span multiple UDP packets 01:13 celeron55 or, well, vary between being a fraction of a UDP packet, and a UDP packet being a fraction of a block 01:17 celeron55 (the first case is handled by, like any short packet, by sending a shorter udp packet, which is inefficient bandwidth-wise (but efficient lag-wise (which can be inappropriate in this case))) 01:20 hmmmm how much space do you estimate is consumed by block metadata? 01:20 celeron55 what is block metadata? 01:21 hmmmm node metadata 01:21 celeron55 hopefully generally zero 01:22 celeron55 sleep -> 03:13 Sokomine regarding block send: someone asked about local caching of mapblocks from a server (as a second usage of the save to localmap branch). that might also be very intresting 05:22 Zeno` 1000 fps barrier broken 09:19 Fritigern Zeno`: Remember how yesterday doubletap_jump was not changed in minetest.conf? Well, today i noticed that my server is not in the serverlist whilst it is supposed to be, my minetest.conf checks out so it must be related to the dev version that i use. (latest git) 09:19 Zeno` I'm not sure it's related 09:19 Zeno` VanessaE's servers are also not there 09:20 Fritigern Weird 09:20 VanessaE it is not related. 09:20 VanessaE I'm not using zeno's latest patches or even a particularly recent build 09:21 kahrl is it related to the latest commits in https://github.com/minetest/master-server? 09:21 Zeno` I didn't touch server-related files at any rate :) 09:21 Fritigern Well, you can not blame me for thinking that it was, seeing as it too is a minetest.conf setting not being honored :-) 09:21 kahrl s/commits/commit 09:22 VanessaE I'm about 2 weeks behind, commit 737cce5f plus a patch sapier wanted me to try out (dbf97af0) 09:23 VanessaE kahrl: it may be; my servers were first reported as missing from the list just yesterday evening. 09:23 VanessaE (but that one tiny commit, I haven't the foggiest idea what it would do) 09:24 Fritigern My server has been quiet all day, but since mine is a minor server, i didn;t think much of it until i checked the list about 30 minutes ago 09:36 VanessaE bbl 09:54 sfan5 kahrl: possibly, I did a git pull of that commit yesterday and restarted uwsgi 10:51 RealBadAngel Zeno`, 1k fps? 10:51 RealBadAngel have you put your hands on nasa's mainframe or what? 10:51 Zeno` RBA, 1400 10:52 Zeno` anyway, can you test #1804 10:52 ShadowBot https://github.com/minetest/minetest/issues/1804 -- Fix regression and make minor improvements in the_game by Zeno- 10:52 RealBadAngel on it 10:52 Zeno` lol, nah it's not on a mainframe 10:53 RealBadAngel just their laptop? ;) 10:53 Zeno` and that PR won't get the speed ups (I need that PR to make the cache keys PR though) 10:53 Zeno` yeah I stole their laptop 10:53 Zeno` I can only get 1400fps if I look at the ground (heh) 10:56 RealBadAngel what are your system specs anyway? 11:38 Zeno` RBA: any issues with #1804 ? 11:38 ShadowBot https://github.com/minetest/minetest/issues/1804 -- Fix regression and make minor improvements in the_game by Zeno- 12:03 RealBadAngel Zeno`, not yet 12:04 RealBadAngel i will just play with it for a while 15:13 Zeno` what's it take to get a bug fix merged? :p #1804 15:13 ShadowBot https://github.com/minetest/minetest/issues/1804 -- Fix regression and make minor improvements in the_game by Zeno- 22:26 paramat hmmmm, i have 2 mapgen-related pull requests here, what do you think? https://github.com/minetest/minetest_game/pull/339 https://github.com/minetest/minetest_game/pull/336 22:46 paramat for 336 the mapgen issue is the defaultifying of pine trees, which means creating default schematics. we could perhaps have multiple pinetree schematics in different sizes