Time Nick Message 00:26 ssieb Fixer: After the inventory mesh change, my inventory pages are really fast. It used be slow like that. 00:30 Fixer ShadowNinja, "jumping at node edge", what kind of bug was that? i don't remember 00:31 ShadowNinja Fixer: Go up to the edge of a node (on an edge that drops off) and try to jump, the input is ignored. 00:31 Fixer interesting 00:31 ShadowNinja You have to get right up on the edge though. 00:33 Fixer ShadowNinja, made 1 flying block, can jump right on the edge, stable 0.4.13 00:34 Fixer oh wait 00:34 Fixer i see, ok 00:34 Fixer reproduced 05:11 Hijiri ShadowNinja: if you spam sneak button you can also get the walk sound to play over and over 05:11 Hijiri when you are on the unjumpable edge 09:12 est31 I'll push this patch in one hour: https://github.com/minetest/minetest/issues/3863#issuecomment-197133987 12:10 celeron55 client_mapblock_limit is dumb as hell 12:10 celeron55 what is the server supposed to do when the client keeps deleting the blocks that it sends to it? 12:11 celeron55 currently it just sends then again and again and the whole system just works 100% of the time against itself 12:12 celeron55 them* 12:12 celeron55 i now made it so that the client tells the server that value, and now i can't walk anywhere because the server refuses to send blocks to the client because it knows they would go over the limit 12:13 celeron55 this is wasteful as fuck 12:17 celeron55 well i know what i will do 12:17 est31 celeron55, before it was a memory leak 12:17 celeron55 but this is dumb anyway 12:18 est31 you explored the map fast enough, you hit the memory limit of your CPU 12:18 celeron55 i'm going to float up the value told to the server based on a new heuristic value collected by the mapblock draw list generation 12:19 est31 you mean meshgen? 12:19 celeron55 nope 12:19 celeron55 soon nobody can understand how this works 8)) 12:19 est31 xD 12:20 celeron55 mapblock draw list generation is a thing that exist that is needed but which nobody knows nothing about except me 12:20 celeron55 exists* 12:20 est31 its part of farmap? 12:20 celeron55 no 12:20 est31 secret part of minetest lol 12:21 celeron55 i'm improving it otherwise too now though 12:22 est31 fine 12:22 est31 i gotta go again 12:23 est31 will push that change later this day 12:23 est31 https://github.com/minetest/minetest/issues/3863#issuecomment-197133987 13:25 dfelinto_vnc does anyone know how complicated would it be to have camera roll support in minetest? 13:25 dfelinto_vnc it seems that part of the problem is that irrlicht itself is only using camera pitch and yaw (if I got it right) 14:02 celeron55 so, the next problem is that 5000 is good enough for only a draw range of like 160 14:02 celeron55 5000 is the current default and there's no user-friendly way to change it, and no automation to change it 14:03 VanessaE how much RAM would it cost if you, say, bumped it up to 25K/ 14:03 VanessaE ? 14:03 celeron55 i don't think a static value like this makes any sense 14:03 VanessaE hm 14:04 VanessaE well remember the reason it had a static measure is OOM crashes before, as I recall 14:04 VanessaE (I'm not opposed to just using however much it needs, though) 14:04 celeron55 i think it chould be calculated from the user's draw range 14:04 celeron55 and there could possibly be a setting to increase it beyond that 14:05 celeron55 i guess it could be this exact setting 14:05 celeron55 it should be just be automatically overridden to a higher value if that is needed for rendering how much the thing is set to render 14:06 VanessaE problem is, you have to account for the user gallivanting around the map, so view range alone won't do, I think. 14:06 VanessaE but I agree in principle. 14:06 celeron55 of course it will do 14:07 celeron55 what does that word even mean 14:07 VanessaE ? 14:07 celeron55 if you mean like teleporting, then maybe a value of 2x what works for hanging around at a single-location 14:08 VanessaE oh, nono. I mean running around like crazy, going all over the place (not even teleporting). pretty common in multiplayer servers 14:08 dfelinto_vnc are you talking about culling? 14:08 celeron55 that's the issue i am solving 14:08 celeron55 not something i am breaking 14:08 VanessaE ok. 14:08 VanessaE I'll just leave it to you then 14:09 dfelinto_vnc is there a quick place I can hack to bump it to 10x? 14:09 * dfelinto_vnc wants to understand this part of the code better 14:11 VanessaE client_mapblock_limit = xxxx 14:11 VanessaE (if that still works; my engine is outdated) 14:11 dfelinto_vnc thanks 16:05 nore sofar: btw, for the beds, I was able to put an attached node there using a mesecons piston 16:05 nore but I would like to be able to attach nodes to the sides of the beds (like signs for example) 16:05 * nore is still wondering on how to do it 16:20 sofar nore: just like doors it's pretty much impossible unless we make some sort of API for it 16:20 nore yeah :/ 16:21 nore either we would need something like multinode support 16:21 nore or horrible hacks 16:33 VanessaE secondary_nodes_sides = {xp=true, yn=nil, zn=true, ...} 16:33 VanessaE seems reasonable to me anyway 16:34 VanessaE (xp = x positive, yn = y negative, etc) 16:35 VanessaE seems to me that if a node is placed with one of those flags, there ought to be callbacks attached to those nodes, e.g. is_secondary = func(pos,dir) or some such 16:36 VanessaE that way they're still distinct nodes. problem is you'd need the secondaries to have some sort of back-link to their "root" nodes for easier destruct 16:37 VanessaE that last part would not work though for mods that have a common "placeholder" airlike node used to fill the space taken by the "root" node 16:40 VanessaE the only other way would be for the engine to treat collision box data (or the model itself) as an indicator that a node space is already filled 16:40 VanessaE and that could be...complicated. 16:45 sofar I wouldn't necessarily implement it that way 16:46 VanessaE it's just the first thing that came to mind 16:46 sofar I was thinking of looking into something like an on_place_onto() callback that would return a modified pointed_thing 16:47 VanessaE on place ONTO? 16:47 sofar on_place_pointing() 16:48 sofar that could then be called by builtin or core to receive a different pointed_thing.under and pointed_thing.above 16:48 sofar and then the normal core code can resume 16:49 sofar it would be a very minimal method. the callback would have to do some math though to properly determine where the player is looking 16:54 nore sofar: that looks like a good idea 16:54 sofar nore: and doable, too 16:54 nore maybe the callback could pass the intersection of the player view with the collision box 16:54 VanessaE for placing a node I guess that works 16:54 nore that would avoid a lot of math 16:54 VanessaE but what about destroying a node? 16:55 VanessaE you can't even begin to rely on player yaw then 16:56 sofar core.on_dig_node wouldn't call it 16:56 sofar it wouldn't need to, anyway 16:57 VanessaE well I'm talking about the case for beds when, for example, a piston or nodebreaker or even just a growing tree somehow destroys half. the engine should detect that and destroy (or drop) the other piece(s). 16:59 sofar that part ... making the secondary node an "attached" node that drops nothing would already fix that 16:59 sofar can't believe I've not thought of that before, either 16:59 VanessaE how would that work? "attached" nodes only matter if they are hanging from the wall 17:00 sofar hang bed tops off bed bottoms? 17:00 VanessaE but they'd still be sitting on the ground 17:00 sofar anyway, that issue I've fixed 17:00 VanessaE I get where you're going though 17:00 sofar PR pending, don't think it's merged tho 17:04 sofar I don't think that PR will miss the release, it's too trivial 17:04 sofar actually, that part is already in 18:30 Fixer https://github.com/minetest/minetest_game/issues/940 confirmed by other person 18:34 everamzah #game941 18:35 everamzah game#914 ? 18:35 ShadowBot https://github.com/minetest/minetest_game/issues/914 -- Option to disable bone drops by tenplus1 18:35 everamzah heya! 18:35 everamzah https://github.com/minetest/minetest_game/pull/941 *takes a walk* 18:50 sofar thanks 18:56 Fixer sofar, remember your "Allow digging of protected doors with "protection_bypass"" ? now i wonder if steel trapdoors are affected by this too, will test it later. 18:56 sofar I checked the code, it's not 18:56 sofar but, please test 18:56 Fixer ok 18:56 * sofar puts QA hat on Fixer 19:33 Fixer wooden sign is not diggable by mese axe? o_0 19:36 sofar it no longer is dig_immediate 19:36 sofar try digging longer 19:39 Fixer nope, it is a buuug 19:40 Fixer damned, another two issues :/ 19:40 Fixer steel one is fine though 19:52 Fixer sofar, wooden one is only diggable by axes 19:53 sofar so it needs to become oddly_diggable_by_hand = 1 19:53 sofar can you try that? 19:53 sofar I gotta run afk a bit 19:53 Fixer don't work 19:54 sofar oddly_breakable_by_hand = 1 in groups, sorry 19:55 Fixer another bug about the bad :S 19:56 Fixer sofar, steel trapdoors are ok btw 21:01 nore < VanessaE> well I'm talking about the case for beds when, for example, a piston or nodebreaker or even just a growing tree somehow destroys half. the engine should detect that and destroy (or drop) the other piece(s). <-- according to me, tree growing should call nodeupdate 21:01 nore so that falling nodes fall and attached nodes are dropped, if needed 21:25 Fixer i see that obsidian is distractable by tnt now, is this correct behaviour? 21:28 est31 using only a viewing range based check is dumb 21:28 est31 you go to a place, you come back 21:28 est31 but the server has to re-send the area because it got deleted because it was outside of the viewing range 21:29 celeron55 how i did it now was that the setting which defaults to 5000 is used unless it's too low for the viewing range 21:30 est31 it should be something like if (inside viewing range) { don't delete } else if (count limit exceeded) { delete } 21:30 celeron55 so assuming 5000 was somehow chosen wisely, then it all is wise now 21:30 est31 paramat chose it i think 21:31 est31 how do you calculate the number of the blocks inside the viewing range? 21:31 celeron55 basically just double it and cube it up 21:31 celeron55 works fine 21:31 est31 ah okay 21:31 est31 yeah thats the maximum then 21:32 Fixer celeron55, i do have memory problems with new farmap, if you talking about it 21:32 celeron55 this isn't about farmap 21:32 Fixer ok 21:32 est31 celeron55, your key privs are needed: https://github.com/minetest/minetest/pull/3865 21:44 sofar celeron55: since I can't transfer to you directly, I've transferred it to your personal account, you can then transfer it to the minetest org 21:44 sofar since I can't transfer to *minetest* directly... 21:48 celeron55 i wonder when and where is it going to tell me about it 21:50 sofar e-mail 21:50 sofar and then you have to click the link 21:57 paramat celeron55 we jointly chose 5000 because that would use 2GB of memory 22:01 Fixer cpu usage is quite high with farmap, up to 80%, in default mt it is closer to 30-40%. 22:10 est31 okay last chance to say no, will merge this fix in 10 mins: https://github.com/est31/minetest/commit/3132bcb3732df51c08c8b2f34781e463cd94fe7f 22:10 paramat 2GB seems a lot for 5000 blocks though, and 5000 is not much world 22:10 est31 i have been announcing this for the whole day now :) 22:10 paramat looks 22:11 celeron55 whether 5000 blocks takes 2GB largely depends on what they contain 22:11 est31 yeah 22:11 celeron55 could be more like 100MB or less in another case 22:13 paramat it was chosen for average mgv7 with it's massive forests 22:13 est31 the limiting is not perfect, i originally wanted to use the real memory demands for each block 22:13 Fixer massive forests are no go for 32 bit builds 22:14 est31 but i didn't find a way to measure it 22:14 celeron55 sofar: done 22:14 paramat i noticed that limit wasn't acting on farmap, luckily. will farmeshes be limited or are they super-compact? i didn't notice much memory use even with a huge view 22:15 Fixer paramat, try recent farmap, it just eats memory like crazy 22:15 est31 the problem about farmap is the big texture cache. no? 22:16 est31 well not problem 22:16 paramat yes i'll be testing again 22:16 est31 s/problem/memory demanding part/ 22:16 est31 so store each texture in each brightness 4 times 22:16 celeron55 est31: it actually really doesn't eat a lot of memory 22:17 celeron55 back then it used much higher resolutions by default 22:17 sofar celeron55: cool, thanks. 22:18 celeron55 farmap's memory consumption mostly consists of the meshes on the client side 22:18 est31 do the core devs have write permissions for the repo ? https://github.com/orgs/minetest/teams/team-minetest/repositories 22:19 celeron55 just like mapblock memory consumption, in fact 22:20 celeron55 est31: now they do 22:20 est31 fine 22:22 celeron55 i guess farmap needs some kind of thresholds for unloading stuff up to completely unloading stuff 22:23 celeron55 it's not my priority now because i'm finding so many other issues in the PR after i started beating more speed out of it 22:45 paramat ShadowNinja some simple reviews for you game#932 game#935 game#941 game#931 22:45 ShadowBot https://github.com/minetest/minetest_game/issues/932 -- Allow digging of protected doors with "protection_bypass" by sofar 22:45 ShadowBot https://github.com/minetest/minetest_game/issues/935 -- Walls: Don't connect to group:cracky by sofar 22:45 ShadowBot https://github.com/minetest/minetest_game/issues/941 -- Rename argument to priv check by everamzah 22:45 ShadowBot https://github.com/minetest/minetest_game/issues/931 -- Re-export character.b3d without texture linkage. by sofar 23:04 paramat any approval for #3862 ? simple review 23:04 ShadowBot https://github.com/minetest/minetest/issues/3862 -- Mgv7: Limit pseudorandom caves to surface mapchunk or below by paramat 23:39 Fixer paramat, "In stable 0.4.13 it was breakable by hands, wooden tools/swords (and stronger), except of hoes" 23:39 paramat wooden sign? 23:39 Fixer paramat, yes, wooden sign 23:40 Fixer checked it few minutes ago in stable one