Time Nick Message 01:44 ShadowNinja You can't delete a void* because delete doesn't know what destructor to call. Delete is essentially a destructor call followed by a free(). (although technically new has to be paired with delete and malloc/calloc/realloc has to be paired with free since they could be completely different allocators) If whatever the void* actually points to allocates any of it's own memory then you'll still have a memory leak. 01:50 schwarzwald[m] Right, I understand the problem, but I don't know the right solution. It looks like this is managed by the emerge thread, but allocated in a different thread. Maybe I'm overcomplicating it, but it seems very nontrivial to fix. e.g. it might require architecture changes. 01:50 schwarzwald[m] * architecture changes (to do well). 07:17 Zughy[m] I invite core devs again to schedule #12429 for the next milestone: it can break any game genre, imho way more important than code optimisation 07:17 ShadowBot https://github.com/minetest/minetest/issues/12429 -- Seeing through blocks glitch 07:33 sfan5 schwarzwald[m]: the callback argument is managed by whoever enqueues the emerge 07:34 sfan5 IIRC it was this code https://github.com/minetest/minetest/blob/46e7b5135292ae7aa233577d1cc364d60fc932f8/src/script/lua_api/l_env.cpp#L1208 07:35 sfan5 and coverity assumes num_block to be zero, which would mean state is allocated and never has a chance to be freed 07:35 sfan5 the solution here is simply to turn the assert into an if that returns early (or throws an error) 09:04 MTDiscord Zughy: #12429 is (1) ancient and (2) nontrivial to fix, see my comment. It definitely shouldn't be put on the milestone IMO. All that can be done about is are basically hacks, which should be left up to mods to choose & use. 09:04 ShadowBot https://github.com/minetest/minetest/issues/12429 -- Seeing through blocks glitch 09:04 MTDiscord about it* 10:59 Zughy[m] I don't agree, that's a HUGE problem. It means free x-ray for everyone, how is that acceptable? I honestly don't care if it requires a lot of time to be fixed, because it's a way to break every possible game 11:24 celeron55 i don't think that can be that much work, altough i'm not sure what's happening 11:24 celeron55 do you move the player outside of the blocks, but leave the camera near plane inside the blocks? 11:25 celeron55 if that's the case, then the post effect color simply has to be switched on according to the camera near plane's position, not the player's 11:25 celeron55 of course that's a plane, not a point, so it takes some extra calculating 11:26 sfan5 well do you want the entire screen to turn black when some 20% (at an angle!) is inside a node? 11:34 celeron55 probably just that part. so, even more calculating, but not impossible 11:34 celeron55 that would feel super polished 12:42 MTDiscord alternatively, you could add a bunch of geometry to the scene, like adding baffles inside a node if it's close enough to the camera, to achieve the blacking-out, and let the 3d hocus pocus handle mathing it into place. 12:43 MTDiscord if you could handle it as a single surface per node that could be pretty nice, but it could be a lot more complex than basically doing what we do with wieldmeshes and allowing there to be some extra "just in case" surfaces. 17:03 schwarzwald[m] "the solution here is simply to..." <- Do we have a convention for how error logs should be formatted? 17:04 schwarzwald[m] * be formatted? (I don't think I saw one on the dev wiki) 17:08 schwarzwald[m] We should also change the Action field in the coverity report to "Fix submitted" at some point, so people looking at the report in the future don't think it's still an outstanding issue. 17:10 Pexin well youre not supposed to BE halfway in a node. if it's computationally cheaper to black the whole screen based on the nearplane, that's probably fine 17:14 sfan5 I think just silently returning would be more correct here, otherwise it'd be throw LuaError("Area to emerge is empty"); 17:16 schwarzwald[m] Silently returning does make sense. Why is there an assert? 17:30 schwarzwald[m] Pushed, #12466 ready for review. 17:30 ShadowBot https://github.com/minetest/minetest/issues/12466 -- Fix two memleak reports from Coverity by JosiahWI 18:12 celeron55 Pexin: but the nearplane isn't you, it's just a rendering necessity 19:26 Pexin celeron55: my impressio was the nearplane is closer than the player collisionmesh though? 19:27 celeron55 yes but the player's collision mesh isn't used for that either, if i'm not mistaken 19:27 celeron55 it's just the camera position that's used 19:28 Pexin but the distance from the wall "should" be farther than the nearplane? 19:28 celeron55 it's probably easy to make it better but difficult to make it perfect 19:28 celeron55 yes, that's true 19:28 MTDiscord Pexin: It works as long as you're not colliding with blocks if that's what you're asking 19:29 celeron55 altough i don't know the exact dimensions, maybe with some FOV, screen aspect ratio or view distance it might not be so 19:29 MTDiscord Obviously blocks you may be inside (e.g. liquids) get tricky; you can sometimes see the water plane being clipped when you slowly sink 19:29 MTDiscord where you may be inside* 19:29 celeron55 that's not an issue though 19:29 MTDiscord in this case it isn't 19:29 MTDiscord the issue here is that somebody is inside a block and moves the camera slightly outside of the block 19:30 MTDiscord which means the engine doesn't black out the screen, but it's close enough for the block face to be clipped 19:30 celeron55 or, well, i mean, it doesn't look that good either, but it's generally not game breaking 19:30 MTDiscord celeron55: it has become a (dirty) part of PvP gameplay 19:31 celeron55 for solid nodes it's game breaking 19:31 MTDiscord together with #8952 it basically makes hiding impossible 19:31 ShadowBot https://github.com/minetest/minetest/issues/8952 -- Entities visible in mapblocks before terrain. 19:31 MTDiscord the problem is that unless both issues are fixed fixing one is insufficient 19:31 Pexin so can the "blackout effect" be made to swap whether it is decided by playerpos vs camerapos? 19:32 celeron55 it's certainly worth trying to make the blackout effect activate based on something more resembling the camera near plane than the current implementation 19:35 Pexin personally, my concern would be computational efficiency, and adding geometry based on proximity seems like it could be bad, but maybe I'm wrong 19:36 Pexin though I'm sure ot would visually work great 19:36 MTDiscord mathematically it would probably correct to extrude each of the node's faces for the blackout effect; programmatically this is too much work though so you'd just extrude all boxes by the clipping distance and check whether the camera is inside that; technically this will unneedingly black out the player camera for the literal edges of the block, but that's irrelevant as the player will (1) still be very much inside the node there 19:36 MTDiscord (2) it's a very slim area (near plane is very small); note also that mods can fix this already (to some extent), as they can (1) obtain node boxes and (2) calculate camera pos - however they don't know the clients clipping plane 19:36 MTDiscord probably be correct* 19:40 MTDiscord it seems only GLES users can change the near clipping plane "to prevent abuse" 19:40 celeron55 of course one should ask, how is the size of the near plane chosen, and the answer is, it should be as big as possible to gain accuracy in depth comparisons 19:41 MTDiscord celeron55: it is 0.1 in blocksize 19:41 MTDiscord so 1cm 19:41 celeron55 could be bigger, but it seems to be large enough given there aren't obvious depth fighting problems or inaccuracy 19:43 celeron55 (basically once you get Z fighting between planes that are already intentionally using different positions to try to avoid z fighting, that's one thing you need to start looking at) 21:55 MTDiscord sfan5, celeron55: here's my proposed fix, could you take a look? #12469 21:55 ShadowBot https://github.com/minetest/minetest/issues/12469 -- Always make everything black if camera is within node by appgurueu 23:47 kilbith a mod could do it just fine