Time Nick Message 00:00 sapier VanessaE that's only true for mods not interacting with those nodes directly 00:00 VanessaE sapier: actually it's more akin to callbacks the way it's set up 00:00 VanessaE but your point stands. 00:00 VanessaE however, I think you're taking the idea to a logical extreme :) 00:01 VanessaE modeblocks:block? er... no. 00:01 sapier ppl use it to extreme 00:01 VanessaE however, 00:01 VanessaE think of this idea: 00:01 VanessaE moreblocks:slab_1 00:01 VanessaE in the future if we ever get meta_set_nodedef or something equivalent to it, that def could point to the 1/16 (one pixel) thick slab, and then some API call sets the material (== the texture) for it on place. 00:02 VanessaE instead of having 50 different slab_xxxxxxx_1 defs 00:02 RealBadAngel sapier, your main mistake is treating node with different textures as something another 00:02 VanessaE same for stairs, slabs (the regular ones), panels, you name it 00:02 sapier I just don't like the ide of hiding genuine nodedef properties within a single subtype value noone is able to interprete 00:02 RealBadAngel wrong, node will have all the same definition regardless tileset used 00:02 VanessaE this idea of RBA's is the same concept but on an extremely limited scope 00:02 sapier RealBadAngel: but exactly this is what vanessaE is gonna do for mesecons 00:03 RealBadAngel no subtypes (sub defs) possible 00:03 VanessaE sapier: document and they will interpret it. if they fail to interpret it, it's because the documentation sucks or the coder is stupid. 00:03 VanessaE I refuse to cater to the latter. 00:03 VanessaE but we can fix the former if needed. 00:03 sapier actually as of this thing merged no mod can rely on what node.name tells 00:03 VanessaE (and usually, it's the former) 00:03 RealBadAngel its rather def that has new abilities 00:03 RealBadAngel not it gains the sub ones 00:03 Inocudom RealBadAngel, I noticed that commit you made that made lighting solely a cpu matter. Night do look different now as a result of it. 00:04 sapier by now posibilities have been limited so actual abuse potential was minor, still it was possible, now I can do almost anything with it 00:04 sapier even the 1 nodedef moreblocks mod 00:04 RealBadAngel Inocudom, it was always done CPU side 00:04 RealBadAngel shaders never did the lighting 00:04 Inocudom What was it that you did then? 00:04 VanessaE sapier: are you saying we can't count on people to sun an abusive mod? 00:04 VanessaE shun* 00:04 RealBadAngel color blending was done cpu and gpu side 00:04 sapier exactly 00:05 RealBadAngel and both were different 00:05 VanessaE sapier: I'm afraid at some point you're gonna have to say "ok, we can at least trust you THIS far." 00:05 sapier ppl demand forcloading too even if it's a violation of our basic activity mechanism 00:05 VanessaE and expect people to abuse it, with the proviso that "well, your own damned fault. stop abusing the engine." 00:05 VanessaE sapier: we already have force-loading :P 00:06 RealBadAngel now color blending (vertex colors) is done only CPU side 00:06 sapier I know and I'm waiting for the first one to complain "my server is eating up all my ram" 00:06 Inocudom So, no conflict that way. 00:06 RealBadAngel so the effect is the same no matter shaders are on or off 00:06 sapier "fix the engine it's your fault as you provide forceload" 00:07 VanessaE sapier: the config sharply limits how many blocks can be force-loaded anyway, and force-loading a region is like having a player always on, so what's the real harm potential? 00:07 RealBadAngel that also got rid of RSOSD 00:07 VanessaE (ergo: the problem doesn't need "fixed") 00:07 RealBadAngel red screen of shaders death ;) 00:07 sapier it's a serverside config param, just changing a setting to 10000x value isn't something the engine shouldn't be able to handle 00:09 sapier as I said I wont veto against it I just wanted to make clear that this subtype has potential to actually create some sort of "shadow nodedef mechanism". 00:09 Inocudom I run Minetest and Freeminer on Linux Mint these days. I have no idea what a bad allocation error would look like on Linux Mint. I have seen it on Windows 7. 00:10 RealBadAngel sapier, there are possibly many other usages of the feature we havent event thought of yet 00:10 Inocudom However, I only got bad allocation errors in singleplayer on Windows 7. Never on servers. 00:10 RealBadAngel *even 00:11 sapier yes almost all of those usages will cause issues with other mods 00:11 sapier and to change a param2 you still have to send a block update to client 00:11 RealBadAngel not until mod will decide to use it on purpose 00:12 RealBadAngel without new code nothing gonna change 00:12 RealBadAngel old furnaces will work as usual for example 00:13 sapier As I said I don't see the actual benefit, reducing node number at cost of node size is at least doubtfull to me 00:13 RealBadAngel node size? 00:13 sapier node == nodedef 00:14 RealBadAngel you mean special_tiles table? 00:14 sapier which is part of nodedef 00:14 RealBadAngel sapier, it is present always 00:14 RealBadAngel you dont know what you are talkin about 00:15 sapier I do you increase special_tiles table in order to switch textures 00:15 sapier for what I remember you added 6 tiles ... or is it already variable? 00:15 RealBadAngel i added 4 00:16 Inocudom Bye. 00:16 RealBadAngel 2 were here 00:16 sapier ok so now a node can be actually 7 nodes instead of 3 before ... so a single nodedef for whole moreblocks will not work 00:16 RealBadAngel ? 00:17 RealBadAngel youre mixing the ideas completely 00:17 sapier no I'm just using the feature you provide ;-) 00:17 RealBadAngel you think its gonna replace set_metanode 00:17 RealBadAngel +f 00:17 sapier moreblocks:node1: base = dirt 00:17 RealBadAngel forget it 00:17 sapier moreblocks:node1 special tiles 1 = grass 00:17 RealBadAngel you got it completely wrong 00:18 sapier ok then please explain it to me 00:18 RealBadAngel there are no subtypes 00:18 RealBadAngel forget the word even 00:18 RealBadAngel theres only one nodedef 00:18 RealBadAngel and two possible sets of textures 00:18 RealBadAngel which are meant to represent on/off state 00:19 sapier containing 1 tiledef + 6 special tiledefs, switched by a param2 00:19 RealBadAngel yes 00:19 RealBadAngel and nothing more 00:19 sapier so param2 can make it look six different ways? 00:19 RealBadAngel ? 00:20 RealBadAngel who told you 6 ways? 00:20 sapier or just two different states? 00:20 RealBadAngel two 00:20 VanessaE only two states, sapier 00:20 VanessaE on and off. 00:20 VanessaE that's why we keep mentioning wires and pipes as examples 00:20 RealBadAngel furnace active / furnace inactive 00:20 sapier ok then I did missunderstand it ... well your video was quite missleading 00:20 VanessaE or furnaces, yes 00:21 VanessaE now mind you, yes, dirt/dirt with grass could in theory also be used for that, but that's stupid and dumb and you'd have to be an utter moron to misuse that feature for that 00:21 RealBadAngel http://pastebin.com/aFGVm4Ga 00:21 Zeno` I'd use it 00:21 RealBadAngel stone node with switching 00:21 Zeno` (just kidding!) 00:22 RealBadAngel (btw we need lua method to set param2 without swapping node) 00:22 sapier ok I admit for only two states abuse potential is still limited 00:22 VanessaE a better example would be the toaster in homedecor (jp added, haven't merged it yet). or any of those items I have where they need two nodes. I could use the "special" tiles to hold the second half of the node. 00:22 Taoki hmmm: I'm not sure if I asked this already, but just in case I haven't: Is there any hope of V7 supporting arrays of schematics? So we can create mine shafts or even complex roads as .mts files, and occasionally have the mapgen loop them underground or at surface level. Would be really cool! 00:22 Taoki * hmmmm 00:22 sapier what'd that function good for there's no way to update metadata without updating node 00:22 VanessaE second half of the *object* rather. 00:22 * Jordach hands VanessaE hyrbid nodes 00:23 sapier And I don't think updating metadata is significant faster then updating whole node (at network level) 00:23 Taoki Like create random labyrinths and the like 00:23 VanessaE Jordach: not hybrid nodes. think desks, beds, benches, warddrobes. things that need to be two nodes wide/tall 00:23 VanessaE -d 00:23 Jordach VanessaE, ah 00:23 RealBadAngel sapier, its updating single bit out of 4 bytes stored in map 00:23 RealBadAngel for a node 00:24 sapier I wonder when first one will complain about "two states aren't enough" ;-) 00:24 RealBadAngel nothing will be faster than that 00:24 VanessaE sapier: then we horsewhip that person ;) 00:24 RealBadAngel sapier, for those set_metanodef is made for 00:24 sapier RealBadAngel: maybe but I can't send a single bit packet to client ;-) 00:24 RealBadAngel slower but more powerful 00:24 sapier And sending 10 or 20 bytes doesn't make a difference on network level 00:24 RealBadAngel sapier, and btw you should check what set_metanodef is capable of 00:25 sapier not even 100 would matter 00:25 RealBadAngel darkrose has implemented dynamic nodeboxes already 00:25 sapier I usually don't need metanodedef ... and to be honest I don't even want to as those things started to evolve to some sort of parallelentitiy 00:26 Jordach RealBadAngel, our nodeboxes were dynamic already (constantly translated from table to irrlicht tables) 00:26 RealBadAngel Jordach, thats gonna change soon 00:26 sapier you make them more and more complex and in the end you'll have same pro and cons entities have now 00:26 sapier just completely different syntax 00:26 RealBadAngel sapier, theyre dumb and still experimental 00:27 Inocudom Yes, but I heard darkrose say that you must ask for her permission to use her code from Voxelands. That includes her achievements with nodeboxes. 00:27 sapier RealBadAngel: I don't say they are as powerfull as entities but they head that direction 00:28 RealBadAngel entities? you mean meshes propably 00:29 Inocudom I can't fathom how you could animate nodeboxes. 00:29 RealBadAngel nodeboxes are also meshes, just stored in our own format 00:29 RealBadAngel which sucks 00:29 cg72 jordach has a chest that opens ans closes so the animated thing is easy 00:29 RealBadAngel mesh 00:30 RealBadAngel not the entity 00:30 Taoki RealBadAngel: Sorry for being inactive lately. Any news on the new awesome shaders? 00:30 sapier entities are activeserverobjects 00:30 VanessaE cg72: that uses an entity 00:30 Inocudom Yes, it has it flaws. Take for example, the fact that all faces of all cubes that make up them show, even internal ones that aren't normally visible. 00:30 RealBadAngel entities are the thing that allow to directly load meshes 00:30 Inocudom Oh, how much VaneesaE's Creative Server would benefit if that were corrected. 00:30 RealBadAngel and then fuck them up badly 00:31 sapier yes but their main power is beeing single active parts in lua code 00:31 Inocudom Another benefit would be if nodeboxes followed the same rendering rules that normal nodes and chunks did. 00:32 RealBadAngel main benefit would be trashing nodeboxes at all, and replace them with meshes :P 00:32 Inocudom Welcome, Taoki. 00:32 RealBadAngel Taoki, liquids shaders are ready (water and lava) 00:32 Taoki hehe, thanks :P 00:32 Taoki RealBadAngel: Awesome. When will they be in master? 00:32 Inocudom But how would the nodeboxes be converted to meshes. What of all of the wonderful creations in homedecor? 00:32 VanessaE homedecor's stuff wouldn't change, Inocudom 00:33 RealBadAngel Taoki, https://www.youtube.com/watch?v=2x6w0wspmPo 00:33 sapier Inocudom: write your own converter ;-) 00:33 VanessaE and I have no plans to animate any of its nodes other than the desk fan, which is already animated 00:33 Taoki Nice! 00:33 Taoki That's not for the default texture pack though, right? 00:33 Taoki As in, if it's a 16 x 16 TP, the lava will still look 16 x 16 00:34 VanessaE RealBadAngel: don't trash nodeboxes, just fix how they're being handled. nothing says a new method can't be introduced that does a better job 00:34 VanessaE nodeboxes are perfectly fine for a lot of things 00:34 RealBadAngel that one is using default 16px lava texture actually 00:34 RealBadAngel https://www.youtube.com/watch?v=58lS8ptwNkU 00:35 RealBadAngel ofc you can use different textures to feed the shader with 00:35 Zeno` sapier: https://github.com/minetest/minetest/pull/1583 <-- Updated. I tested voxelmanip as an alternative and the call to get_data() was slower than the entire set/remove loop itself 00:35 Taoki nice 00:35 Taoki RealBadAngel: Are the node names no longer hardcoded though? IIRC that was a problem last time 00:36 sapier Zeno`: then we should fix the manip isntead of adding another mechanism to do same thing 00:36 Inocudom Very nice shaders RealBadAngel. 00:36 VanessaE sapier: no. a single call to do the job is better 00:36 VanessaE it's a cleaner way to do it. 00:36 sapier really? next time set_node_around 00:36 VanessaE even if you could mape vmanip as fast, a single API call wins every time 00:36 sapier and then set_node_pyramid 00:37 sapier and maybe set_node_if_water() 00:37 Zeno` sapier: is it possible to "fix" the manip? The "problem" (time-wise) seems to be the pushing of values onto the Lua stack. Additionally, even if it wasn't faster (or slower) then VanessaE's point is very compelling (to me) 00:37 VanessaE make* 00:37 Zeno` I think that setting cubic areas is enough 00:37 Zeno` I don't like pyramids 00:37 sapier VanessaE: most likely yes but a single call always means one veryveryvery specific usecase and not usefull for anything else 00:37 Zeno` setting cubic areas seems like something that would be used often 00:38 VanessaE sapier: aw come on, enough with the slipper slope/logical extreme stuff here 00:38 Zeno` pyramids... hardly ever 00:38 sapier e.g. your setnodearea could be done by adding support for "empty voxelmanip" 00:38 Zeno` It could be argued that adding *any* functionality is a slipper slope 00:38 VanessaE sapier: is not set_node() jus as specific? 00:39 Zeno` why is find_nodes_in_area() a function? 00:39 sapier yes it is ... it's a primitive operation 00:39 Zeno` I could do that with vmanip 00:39 VanessaE sapier: set_nodes_in_area(minp, maxp, "default:dirt") 00:39 sapier while set_nodes_in_area ain't a primitive operaition 00:39 VanessaE sapier: neither is find_nodes_in_area() 00:39 Zeno` seems a primitive operation to me. If I was writing a graphics library I'd have that as a primitive 00:40 VanessaE sapier: set_nodes_in_area is to set_node as find_nodes_in_area is to get_node 00:40 sapier and there won't be any chance to do transactional maps with a function like that wihout adding huge lag spikes 00:40 VanessaE if you can have the latter, you can have the former. 00:41 sapier no it ain't a primitive operation as you will have to lock map for full time of this operation which can be quite long 00:41 VanessaE if such an operation locks the map, C++ is doing it wrong 00:42 sapier it has to lock the map as we can't guarantee it's going to do this 00:42 VanessaE you can't lock, write 10 nodes, unlock, then repeat? 00:42 sapier at least if we introduce parallelity 00:42 VanessaE even if the map remains unlocked for like, a microsecond? 00:42 sapier set_nodes_in_area((1,1,1),(50,50,50)) 00:43 sapier I don't need to tell you how many nodes that will be 00:43 Zeno` I don't get it 00:44 sapier if we want to do this function in parallel we need to convert it internaly to voxelmanip later 00:44 VanessaE wait wait 00:44 VanessaE so how is that ANY different from doing the same thing with a Lua loop and vmanip? 00:44 VanessaE aside from being a single API call 00:44 VanessaE wouldn't you still have the same locking issue then? 00:44 VanessaE fill up a big vmanip object and blit it out to the map? 00:45 sapier there's no guarantee the node set 10 nodes ago is still set to this node if you set the current node 00:45 VanessaE that's exactly what you're proposing to do here 00:45 sapier but if you provide a set_nodes_in_area function anything different then guaranteeing that all nodes are set this way on returning is insane 00:45 VanessaE sapier: according to hmmmm, set_node() is immediate. 00:46 VanessaE or wait I see what you meant 00:46 VanessaE but you're missing the point here 00:46 sapier yes it is ... but think about some async thread doing things in parallel right now changing some nodes already changed by that loop wouldn't cause the async thread to stall 00:46 Zeno` I call set_node() (the c api version) so if set_node is immediate then isn't my code as well? 00:47 sapier if you do it that way we have to lock the map for full time of this operation no chance to break it into pieces 00:47 VanessaE for X/Y/Z = foo; do set_node(blah) end end end, versus [get a vmanip object] [fill it with a loop like <----- that one] [write vmanip object], versus set_nodes_in_area(minp, maxp, node) 00:47 VanessaE how is any of these any different from the other, aside from speed? 00:47 VanessaE do they not ALL lock the map? 00:48 sapier at the end of that loop you can't be sure that all nodes are still the way you set them 00:48 VanessaE what? 00:48 VanessaE of course you can 00:48 VanessaE lua isn't multithreaded 00:48 hmmmm set_node is only ever called from inside an envlock 00:48 sapier not in a parallel environment 00:48 VanessaE this isn't a parallel environment 00:48 hmmmm vanessae, would you prefer permanently killing any prospect of multithreaded lua? 00:49 sapier guess what I'm trying to direct minetest for about 2 years now 00:49 VanessaE hmmmm: of course not, but until we have it, what's the point of preventing the API from advancing? 00:49 VanessaE hmmmm: besides, I thought it was already agreed that that idea was totally dead? 00:49 hmmmm there's no real advancement here except some very fast operation is being made a little bit faster 00:49 VanessaE Zeno`: benchmarks? 00:49 sapier we wont have parallel minetest for some additional time but a function like that one will most likely be another stone in way towards it 00:49 hmmmm no, nobody ever said that. that's nonsense. 00:49 Zeno` the advancement is that it's more readable 00:50 hmmmm Zeno`, sounds like you want to write a wrapper function for this then 00:50 Zeno` VanessaE, the speed advantage for small areas is not a lot (~1.4 times faster) 00:50 VanessaE hmmmm: 10 lines of code --> 1, plus it's ^^^ 1.4 times faster? this is not a good enough advancement? 00:50 Zeno` hmmmm, it basically is a wrapper function, just in C++ 00:50 VanessaE hmmmm: not "want to". already did. 00:50 Zeno` for large areas 100x100x100 it's about 4x faster 00:51 Zeno` Anyway I didn't write this for speed issues 00:51 sapier VanessaE: It's an advancement we're gonna pay for once we try to do it in parallel ... and it will be expensive 00:51 hmmmm 4x faster than what 00:51 Zeno` Than the equivalent Lua loop 00:51 sapier what's base time? 00:51 sapier 1s to 0.250s? or 1000s to 250s? 00:52 Zeno` But I didn't write this for the speed advances 00:52 hmmmm voxelmanip should be faster than set_node at 100x100x100 areas 00:52 VanessaE hmmmm: but voxelmanip is way less readable by comparison. 00:52 Zeno` It's *more* for the readability 00:52 hmmmm vanessae: so then make a wrapper function for it. 00:52 VanessaE hmmmm: so...wait a second here... 00:52 hmmmm again. there is absolutely ZERO reason to add another api 00:52 VanessaE a wrapper in Lua is better than a wrapper in C++? 00:53 hmmmm that is correct 00:53 VanessaE O_o 00:53 hmmmm stop adding bullshit to the C++ api 00:53 hmmmm stop it. 00:53 VanessaE umn 00:53 sapier that wrapper doesn't even have to be in minetest api 00:53 Zeno` I don't agree that it's bullshit 00:53 VanessaE bullshit> 00:53 hmmmm indeed, that's what I was going for sapier 00:53 Taoki hmmmm: Hello. I'm not sure if I asked this already, but just in case I haven't: Is there any hope of V7 supporting arrays of schematics? So we can create mine shafts or even complex roads as .mts files, and occasionally have the mapgen loop them underground or at surface level. Would be really cool! 00:53 VanessaE the last thing I ever added to the API that i recall was that rotate and place function 00:53 VanessaE and now it's used all over the place 00:53 hmmmm maybe there could be some sort of mod that has a collection of these "convenience" things 00:53 Taoki (you were away when I first asked so I thought to ask again) 00:54 hmmmm Taoki: what? 00:54 sapier problem with this function is it's basicaly a subfunction of voxelmanip 00:54 VanessaE and that was many months ago 00:54 Zeno` so find_nodes_in_area() is deprecated? 00:54 Zeno` why not write a Lua wrapper function? 00:54 VanessaE so I take issue with your claim of adding "bullshit" to the API, especially the assertion that it's being done on an ongoing basis 00:54 hmmmm Zeno`: the point of find_nodes_in_area() is speed, not "readability" 00:54 sapier read access is way less critical in parallel environment 00:55 Taoki hmmmm: I was looking at natural mineshafts and nether corridors in Minecraft earlier (not that I want to copy MC). I was wondering if mgv7 will ever support creating corridors urgerground, by defining each segment as a schematic 00:55 Zeno` ffs, at this rate nothing will be in C++ and the entire codebase will be Lua 00:55 Taoki Basically to loop a schematic in a random maze-like pattern 00:55 hmmmm Taoki: do you understand that's an entirely new system? 00:55 hmmmm it's not like a feature that I can just slap in for shits and giggles 00:55 sapier Zeno`: still any reason not to use vmanip? 00:56 Taoki hmmmm: Wasn't sure if it could be added to V7. You would know best... if it's not possible that's fine 00:56 sapier assuming we can (almost completely) fix your speed penalty 00:56 Taoki I was hoping it is 00:56 Zeno` sapier: the call to get_data() takes longer than the set/remove loop itself 00:56 hmmmm Taoki: it's possible, but somebody else here would be the one to do it 00:56 VanessaE Zeno`: yeah, it's un-fucking-readable and now you're asking every damn mod that needs to clear more than three or four nodes in an area to write a wrapper. 00:56 VanessaE this is wasteful 00:56 Taoki ok. Good to know, thanks. Maybe someine will, once V7 is declared stable 00:56 sapier Zeno`: there's no reason not to support a nil voxelmanip not reading any data 00:57 VanessaE saper rather 00:57 VanessaE sapier* 00:57 * VanessaE is tired and getting a little crabby. 00:57 sapier actually I remember a quite similar meachanism within core 00:57 Taoki hmmmm: When you spend some time on mgv7 again however, please otherwise add distance limitations between decoration schematics... which I assume is an easier thing. So we can define decorational schematics that don't intersect with each other, like occasional houses 00:58 VanessaE you know what... 00:58 hmmmm Taoki, can you explain to me how I would implement that? 00:58 VanessaE this is gonna sound nasty but I'm gonna ask it anyway. 00:58 hmmmm VanessaE: perhaps you should fork minetest if you're so upset with the way things are going and do it better the right way. 00:58 VanessaE hmmmm: when was the last time you wrote a mod? 00:58 hmmmm VanessaE: never, but I enhanced a mod 00:58 VanessaE and I mean sat down and wrote one without having the benefit of being able to add to the API or tweak the C++ side? 00:58 VanessaE ok. never. 00:59 VanessaE so you purport to tell modders what's the best way? 00:59 hmmmm yes 00:59 VanessaE I'm sorry, but you're wrong. 00:59 hmmmm VanessaE: perhaps you should fork minetest if you're so upset with the way things are going and do it better the right way. 00:59 VanessaE and no, repeating yourself it not going to change the answer I was about to write. 00:59 hmmmm christ. all you do is whine but you never fix things. 00:59 VanessaE I am perfectly capable of reading, even if I can't type. 00:59 Taoki hmmmm: I was thinking of two approaches. One would be a "no intersection" flag, which guarantees that decorational schematics spawn at a minimal distance to not cut each other off. Second approach would be allowing to define a minimal distance per schematic... so basically no decoration spawns closer to another decoration once it's defined 01:00 hmmmm Taoki, yes, but how 01:00 Taoki eg: If a tree spawns at a position first, nothing 5 blocks around that tree can spawn 01:00 Taoki Ah... I was thinking it wouldn't be a problem 01:00 hmmmm articulate the mechanism by which this happens, not the interface 01:00 hmmmm that's a little harder, huh? 01:00 VanessaE I don't fork the engine because I can barely read C++ as it is. I have no chance at all of trying to code in that language - and that's after having spent a few years coding in other C-like languages as it is. I don't understand Minetest's codebase either, no one here truly does in its entirety. 01:00 sapier Zeno`: what do you need get_data for? 01:01 Taoki hmmmm: I was thinking that once a schematic has been applied, the mapgen knows the position at which it was spawned and can delete any potential schematics from that radius. 01:01 VanessaE but I can read and code in Lua, and that's a language I'm quite comfortable in, when I'm able to think clearly at all. 01:01 hmmmm sapier: this sort of situation is why I wanted to trust modders (to a point) with an envlock 01:01 Taoki Or, alternately, MGV7 would generate the decoration pattern in such a way to respect these values. But I don't know in depth how it's generated currently 01:02 Zeno` I meant set_data() 01:02 Taoki So when it tried to place a new decoration, it checks if it's in the radius of an existing decoration that has a minimal distance set 01:02 Zeno` anyway one last point 01:02 sapier hmmmm I'd give them a maplock at best not a full envlock 01:02 VanessaE oh and for the record, had you been paying the least bit of attention, you'd have noticed that I have been trying to keep an eye on things like multithreaded Lua being possible some day. plants_lib, for example, should be thread-safe after that git spate of rewrites. 01:02 sapier yet they'll fail to use it correct too 01:02 VanessaE so get down off your pedestal. 01:02 hmmmm that is totally true 01:03 sapier And we'll not have a way to find this out 01:03 hmmmm people can't use luavoxelmanip correctly even though it's been how long 01:03 hmmmm agh 01:03 Zeno` If in the future say there becomes a really fast way to do the operation. If it's all Lua-side then every mod will need to be updated. If a function was part of the API then only the C++ code would need updating and *all* mods using said function would immediately benefit without having to be updated. Surely that's something important. 01:04 Taoki hmmmm: How are decoration schematics currently generated? A random X and Z position within the new chunk per decoration, or are they placed using a perlin noise map (in which case the result is harder to predict and organize)? 01:04 hmmmm there should be a way to lump a set of operations together that must all be executed at the same time though 01:04 sapier if set_data is that slow we should improve it 01:04 VanessaE hmmmm: I said it before and I'll say it again: if the function works properly, then either the documentation sucks or the coders are stupid. which do you suppose is the case? 01:04 hmmmm this isn't necessarily about set_data being slow or whatevr 01:04 hmmmm whatever* 01:04 Inocudom I once made a post in the Minetest forums that said the following. Pride... Is the greatest enemy... Of open-source. 01:04 Inocudom It is a phrase that we can all learn from. 01:04 hmmmm what if somebody has a mod where they need to modify two things that are part of the environment but not both pieces of the map? 01:05 Zeno` To me, making the function "abstract" makes sense. The Lua programmer doesn't care (no should care) *how* the function does the bulk operation. 01:05 Zeno` nor* 01:05 sapier Zeno`: there's no way to optimize a set_nodes_in_area setting 85k nodes for example 01:05 sapier that one will cause lag 01:05 sapier it's a single operation and ppl will demand it to be atomic 01:06 Zeno` sapier, but changing how the C++ does it (let's say vmanip) is better than 1.3 million mods having their own variation 01:06 hmmmm Taoki: decorations are placed based on coming up with a random number of decorations per area, and then within that area, randomly selecting points to place it 01:06 sapier Zeno`: there's no way to change this, it's a design error 01:06 Zeno` atomic? Why? 01:06 hmmmm so for example you'd break an 80x80x80 chunk into 8x8 pieces 01:06 Zeno` I think you're misunderstanding what I'm saying 01:06 hmmmm and then each 8x8 piece would get a randomish amount assigned like... 3 01:07 hmmmm so then it'd randomly choose 3 positions from within that small chunk 01:07 Taoki hmmmm: ok. One way in that case would be to know the radius of each point (based on the settings of that decoration), and just avoid creating a point there or move the point away from that radius. 01:07 Taoki If a point already set itself there 01:07 Zeno` yeah, you're panellising it? 01:07 Zeno` I don't see what that has anything to do with the current discussion 01:07 hmmmm Taoki: that much is obvious. do you realize what that entails, though? 01:07 sapier the function you suggest is a single atomic operation or do you accept some additional comments "nodes withnin the set area may not be set to that node once the function is completed" 01:08 Taoki hmmmm: I'd normally think such a check would only be a few lines of code. But I didn't look at the mgv7 code personally 01:08 hmmmm taoki: schematics are not part of mapgen v7. 01:08 Zeno` Currently? I don't accept that it currently works like that 01:08 sapier paralellizing is almost completely about splitting things into small pieces what you do is adding another huge piece 01:08 hmmmm taoki: the check requires keeping the state of all such decorations previously placed 01:09 Taoki hmmmm: I know. Still, one could define a "personal space" radius as a single number, in the decoration definition. 01:09 hmmmm so tell me, how would you manage to do that? 01:09 Taoki True 01:09 Taoki Well, 01:10 Taoki hmmmm: For each point that is placed (decoration position), you also persist the position and that decoration's specified "personal space" radius, until all decorations are finished placing. Each new point accounts all previous ones and their specified minimal distance. 01:10 hmmmm taoki, that won't work. so I'm finished generating my 80x80 chunk of map and then another chunk gets generated later on 01:11 Taoki So: Chunk begins generating. New point is added. We persist that point as (x, y, z, radius). New points don't get closer to x / y / z than radius. Chunk finished generating, free all points 01:11 Taoki Ah 01:11 hmmmm yeah. :).. 01:11 sapier Zeno`: still a function like the one you want could be implemented within voxelmanip api, benefit would be we don't have to add map transactional code throughout minetest 01:11 Taoki Yeah, chunks could not account their neighbors as easily 01:11 hmmmm taoki: so not as simple as you thought, huh? 01:11 Taoki Since it'a s per-chunk operation, but the building might be larger than the chunk 01:11 Taoki hmmmm: Yeah, missed that one :) 01:12 sapier and something as big as this operation will require transactions in a parallel environment 01:12 hmmmm think of these kinds of things when you go request a schematic feature willy nilly 01:12 Taoki There might be a way around it... but I indeed need to think 01:12 Taoki Sounds like a permanent map of all decorations might have to be stored. Depending whether that would make the world file too big 01:13 hmmmm whenever you propose something like that, you lose 01:13 Zeno` sapier, yeah and wouldn't it be easier to maintain that if it was in C++? 01:13 Taoki Anyway, this is like the only thing that keeps decorations from being useable to generate villages (without roads of course). So I really hope someone can think of something here 01:14 Zeno` if the way the function should work needs to change you just change the implementation 01:14 Zeno` I don't get how that's not a benefit 01:15 Taoki hmmmm: There could be another way: Check if within the space the decoration would take up, there's anything but air blocks. Decorations could have a list of tolerated nodes, which they're allowed to overwrite. Obviously air being the first default... perhaps dirt and dirt_with_grass 01:15 Taoki This would of course require knowing the size of the schematic and exactly the area it takes up, and checking all the nodes in that area 01:15 Taoki So performance would depend on this not being abused by the mapgen designer who uses the Lua API 01:15 kahrl Zeno`: no it won't be easier to maintain 01:15 Taoki Still, it's a way :) 01:16 Zeno` kahrl: any "abstracted" function is easier to maintain 01:16 kahrl if each modder writes this simple function herself she can change things if there suddenly is a need for more features 01:16 Zeno` Because the "how" no longer matters 01:16 Taoki But yeah. A house decoration could for example be defined as allowed to override air, dirt, dirt_with_grass. But if there's another house already there, it would detect wood... so it would stop. 01:16 kahrl if we add it to the C++ API, everyone will come to us and ask for their favorite feature 01:17 kahrl which can't be satisfied all at once 01:17 Zeno` kahrl, that's what I was saying earlier. If this was a part of the Lua API then "behind the scenes" is none of the Lua programmers concern 01:17 Zeno` And if the implementation gets changed, all mods benefit without any changes to the mods at all 01:18 sapier Zeno`: no maintaining 100 different locations where to do transactions wont be more easy then just implement transactions around voxelmanip code ;-) 01:18 VanessaE so wait, now you don't add to the API because you don't want feature requests? O_o 01:19 Zeno` sapier, so in that case you change the implementation of set_nodes_in_area() to use voxelmanip 01:19 kahrl VanessaE: we don't all bullshit to the API because of that, yes 01:19 Zeno` No Lua-side changes necessary 01:19 kahrl s/all/add 01:20 sapier zeno I do understand this as "i want may quick and dirty version and dont care about how you guys get a really sane version" 01:20 Zeno` sapier, then you misunderstand me :) 01:20 sapier but that's what I see happening 01:20 VanessaE kahrl: one person's "bullshit" is another person's indispensable feature. 01:21 Zeno` Then you are seeing it incorrectly 01:21 sapier you wont transform the code to voxelmanip so we will have to do it once we really wanna implement parallelism 01:21 Zeno` Maybe I'm not explaining myself well. I dunno. 01:22 Zeno` Who said I wouldn't transform it to use voxelmanip? 01:22 sapier I agree you may not have intended this ... but result will be same 01:22 sapier if you did why not do it just now? 01:22 Zeno` Well, I see no point in doing it now if it's not going to be added to the API anyway 01:22 Zeno` I don't want to waste 10 minutes of my time :) 01:23 kahrl wait, didn't Zeno` already write a vmanip version 01:23 kahrl where the set_data call was slow 01:23 * kahrl is lost 01:23 VanessaE *headdesk* 01:23 Zeno` I wrote a vmanip version in Lua 01:23 sapier he did so why didn't he implement a faster variant of set_data 01:24 sapier adding a set_nodes_in_area to voxelmanip would be a api we can base uppon 01:25 Zeno` That's possible, but there are (currently) problems with voxelmanip (i.e. due to the lack of transactions you mentioned earlier) 01:25 sapier yes 1 create, 2 set nodes, 3 write back to map most likely is still slower then direct map access, but for us we'd only have to put transactional code at one location 01:26 Zeno` When it's fixed the l_set_nodes_in_area() simply calls voxelmanip 01:26 Zeno` And all mods will then be doing it the "proper" way 01:26 sapier that's same as with entities because someone doesn't fix the bugs we create new mechanisms doing same things 01:27 sapier no it ain't as you'd still have that deprecated function in api 01:27 Zeno` why would it be deprecated? 01:27 sapier and e.g. if you want to set 2 blocks within one transaction your deprecated api doesn't help at all 01:27 Zeno` become* 01:28 hmmmm well 01:28 sapier because voxelmanip is the way to do big changes to map 01:28 Zeno` It wouldn't become deprecated and that's the whole point of my argument 01:28 hmmmm sapier, do you agree there needs to be some sort of atomic operation batching? 01:28 Zeno` Yes, and the function would do that 01:28 sapier why create a parallel api ? 01:29 hmmmm especially now with multiple mods running at once 01:29 Zeno` I don't see it that way 01:29 sapier depends on what you understand by "atomic operation batching" ;-) 01:29 hmmmm not just a set of mapnodes being set at the same time 01:29 hmmmm what if a set of mapnodes need to be set as well as something being done with items 01:29 hmmmm idk 01:30 hmmmm basically I'm making a case for controlling envlock from within lua. the issue is that we can't freaking trust mods because they keep screwing things up 01:30 hmmmm mods have an excellent track record 01:30 Zeno` Well, give them the API function so they can't screw it up 01:30 sapier if you want to introduce a lock provided to lua api we need to create debugging tools first. see how long we needed to find the lag spikes caused by farming mod 01:30 hmmmm well see 01:30 hmmmm I wouldn't ever give them an indefinite lock 01:30 hmmmm maybe one that times out after a second 01:31 hmmmm that could be dangerous but it also might not be 01:31 sapier and what's gonna happen on timeout? 01:31 sapier data corruption? 01:31 hmmmm the lock gets released from underneath it 01:31 sapier assertion? 01:31 Inocudom What are these lag spikes caused by farming like? 01:31 VanessaE timeout of one second? that won't be enough for some mods like paramat's mapgens 01:31 sapier see 01:31 hmmmm so yeah, data corruption 01:31 hmmmm and a nice fat warning 01:31 Zeno` oh great... add another misuse of assert() heh 01:31 sapier you'll never find that issue 01:32 hmmmm "hey dickwad, your mod X is eating up waay too much time" 01:32 hmmmm "so we're just going to take your exclusive access away from you" 01:32 sapier "not happening on my big fat machine using luajit" 01:32 hmmmm huh 01:32 kahrl hmmmm: what if somebody SIGSTOPs the minetestserver process for a while 01:32 Inocudom How about TenPlus1's farming_redo mod? Is it more stable than what is currently in minetest_game? 01:32 kahrl while a mod has such a lock 01:32 sapier and you can't even be sure it's that mod some other application could have stalled that mode 01:32 sapier -e 01:33 hmmmm yeah, that's a problem. time would need to be based off of number of execution seconds and not wall time 01:33 hmmmm but come on 01:33 hmmmm is there any other imaginable way to accomplish the task we're talking about 01:34 sapier timed locks are inconsistent and cause more trouble then they're worth anything sane you can do on timeout is quit minetestserver immediatly 01:34 hmmmm short of defining an exhaustive list of "pending events that would need an envlock" 01:34 sapier why envlock? 01:34 hmmmm sorry, a lock in general 01:34 sapier envlock is like big fat kerlen lock 01:35 hmmmm kernel* 01:35 hmmmm it's worse than freebsd's giant lock in 7.x 01:35 hmmmm =/ 01:35 sapier imho we should get rid of it ... of course this can't be done at once 01:35 sapier at least we shouldn't add new big fat lock locations 01:35 hmmmm ah man sapier, you deserve way more credit than you get 01:36 hmmmm all these things require lots of time and with a job that's not so easy 01:36 * cg72 loves sapier 01:36 cg72 your the best lol 01:36 hmmmm yet you do it anyway 01:36 sapier thanks guys but that's not gonna remove the envlock till tomorrow too ;-) 01:36 hmmmm i wouldn't be able to even plan out a system like this if I had a week straight of nothing else to do 01:37 hmmmm but 01:37 hmmmm assuming the timed lock is a no-go, we'd have to do the other thing 01:37 cg72 hell that im not worried about lol im rewriting mapgen hehehehe 01:37 sapier well I don't have a complete plan yet too still a direction and I tend to try small steps towards it 01:37 sapier so if a step is wrong there's not that much of time lost 01:38 hmmmm we number each and every API and then build up an "execution plan" 01:38 hmmmm of what to call along with the parameters 01:38 sapier a message passing mechanism 01:38 hmmmm message passing yeah 01:39 hmmmm except getters would be a problem 01:39 hmmmm making decisions based off of something that needed a get 01:39 sapier message passing's problem is if you do it bad you do a lot of copying 01:40 sapier imho the voxelmanips are actually a quite good way to do it. e.g. current usecase 01:40 sapier right now you need to actually read the map to specify the location ... but ... why? 01:41 sapier mapgens for example usually don't care about map 01:41 sapier so why not just specify the extents? 01:41 cg72 if we dont read it or check couldnt it crash it lol 01:42 sapier once the extents are specified a mapgen can do whatever it wants, and then on save all data is saved back to map in one transaction 01:42 sapier now a different usecase 01:42 sapier manipulating an existing area 01:43 sapier reading reads full data but additionaly some sort of timestamp per block 01:43 sapier once user does want to save first thing to be done is checking the timestamps for modification, if this did happen the save is denied 01:45 sapier but I guess noone wants to add that transactional code to don't know how many functions 01:45 hmmmm sapier: ?? 01:45 hmmmm not sure what you mean by having to read the map to specify the location 01:46 hmmmm you certainly don't have to read map before writing map 01:46 sapier I haven't seen a different function in api ... but I haven't used voxelmanip a lot so I could've missed 01:46 hmmmm read_from_map(); get_data(); do stuff with data; set_data(); write_to_map(); is the normal pattern of use 01:47 sapier yes and what I'd suggest is skipping first two parts 01:47 hmmmm if you're just writing blockfulls of map though you don't need to read_from_map() or get_data() 01:47 hmmmm but if you're making some sort of shape, and you didn't read the map in first, you'll have content_ignore everywhere else 01:47 hmmmm aha 01:47 sapier but for what I remember write_to_map doesn't take minp and maxp parameters 01:47 hmmmm but that's okay because the way voxelmanip is right now it skips over blitting back content_ignore 01:48 sapier so how does voxelmanip know where to write? 01:48 hmmmm because of the area emerged..... 01:48 hmmmm hold on a moment, let me check something 01:49 hmmmm i think you're right actually 01:50 sapier well It's how I understood doc, so either doc is missleading, or I'm just interpreting it wrong ... wouldn't be first time 01:50 VanessaE and I believe I said THAT twice tonight. 01:50 sapier so two steps to get zenos function in a clean way 01:50 VanessaE (generally, not specific to vmanip) 01:50 sapier first make voxelmanip work without reading map 01:51 hmmmm oh god you're right 01:51 hmmmm this is bad 01:51 hmmmm sapier: i'll fix it 01:51 sapier second add a function to voxelmanip to set an area within the voxelmanip instead of set_data 01:51 hmmmm this was quite idiotic.. the minp/maxp should be specified in the constructor or the get_voxel_manip() call 01:52 sapier yes that's a even better solution 01:52 hmmmm that should fix everything 01:52 sapier maybe not 01:52 hmmmm why not 01:52 sapier he said set_data is to slow 01:52 hmmmm it's not.. 01:53 hmmmm you iterate through the table passed from lua and perform assignments 01:53 hmmmm like actual assignments, not operator overloaded nonsense 01:53 hmmmm no tricky things going behind the scene 01:53 hmmmm just copying memory 01:53 Zeno` no I didn't say that 01:54 Zeno` I don't care AT ALL about the speed 01:54 Zeno` I said that it's slower 01:54 sapier ok so set_data is not an issue, good 01:54 hmmmm i'll be the first to admit that voxelmanip is slower than set/get_data() for smaller areas... because of the enormous amount of overhead due to allocating large chunks of memory, copying tables to and from lua, etc. 01:55 sapier time to get some sleep :-) good moment now ;-) good night 01:55 Zeno` My real reason for not using voxelmanip in the C++ was because I don't quite trust it yet 01:55 Zeno` Not because of speed :) 01:57 Sokomine regarding mapgens and mods as such: one common problem is to find out which nodes are surface nodes. mods that want to put something on ground nodes have this problem. it isn't easy to find ground nodes universally 01:57 hmmmm taoki: the air idea is good, if not a little obvious, but highly inefficient 01:58 hmmmm taoki: and then there's the fact that it'd seriously mess up multi-threaded map generation 01:58 Zeno` The fact that the C++ version is faster is just a nice side-effect 01:58 VanessaE Sokomine: plants_lib does that by doing a find_nodes_in_area() call on the desired surface(s), searching through the returned table for everything that has air above it, and returning a new table with the results. 01:59 hmmmm arbitrarily-sized schematics placed on chunks of map at a time rather than the whole thing is a decivingly difficult problem 02:00 hmmmm instead of entertaining such nonsense, the problem ought to be simplified. but this requires pre-generating large areas of map beforehand. this could possibly work out okay if used with discression 02:05 Sokomine vanessae: sounds like a good solution for plantslib. sometimes, the height and not the actual node type is what is of intrest 02:06 VanessaE yes, exactly. the node type in the surface gets read and used later, but in the initial filter, all I care about is getting a list of positions of nodes that constitute "a surface with air above it" within the search region. 02:06 VanessaE that's another function that I would love to see added to the API, but I don't suppose it'll happen. 02:06 VanessaE (another "bullshit" idea, I'm sure) 02:06 Zeno` It'd be worth doing IMO 02:10 Sokomine it would be great if the api could be extended. that's the purpose of an api after all - to avoid that everyone has to re-invent the wheel 02:11 Sokomine for that matter, it does not matter to a modder if an api function is implemented in c++ or just part of builtin. the point is that it's there 02:11 VanessaE EXACTLY. 02:11 Zeno` Which is kind of what I've been saying all along lol 02:12 Zeno` Sokomine explained it better 02:31 Inocudom I heard it said that entities could use an api. 02:32 Inocudom I would like to see carts in the base game some day. Opening and closing chests too (very impressive thing Jordach did there.) 03:53 paramat hmmmm is quite right to resist pull #1583, voxelmanip is perfect for this 04:08 Zeno` paramat, the problem I have with voxelmanip is that it might set the node, or it might not 04:09 Zeno` voxelmanip would be fine if I could trust that the data is actually set (and I can't do that at this point in time) 04:09 Zeno` Either way functions for these are desirable so that when voxelmanip does become more predicatable the implementation of the function is simply updated 04:10 Zeno` Anyway I've removed the pull request for now 04:10 Zeno` And "voxelmanip is perfect for this" is not an argument for not having these as API functions 04:11 Zeno` Why should every mod have to write the same thing? Does C have fputs()? Surely it's trivial to implement via fputc() in a loop, so fputs() shouldn't be part of the C standard 04:12 Zeno` In fact all of string.h is trivial to implement. Every program should write their own versions of these functions! 04:12 * Zeno` wanders off 04:12 NakedFury get it all off your chest 04:16 Zeno` heh 04:16 Zeno` Well, while I'm at it I've got an issue with the use of assert() in the codebase 04:16 Zeno` Nah, I won't go there 04:28 hmmmm God dammit I am so stupid 04:28 hmmmm grrrrrrrrrrrr 04:28 hmmmm this weekend I promise I'm going to give schematics some love 04:28 VanessaE stupid? 04:29 hmmmm people use schematics so much 04:30 Zeno` Couldn't they be loaded with voxelmanip? 04:31 hmmmm the reason why schematics are part of the core is because they're technically a part of mapgen 04:32 Zeno` What about mapgens that clear or modify cubic areas? 04:32 hmmmm you create a schematic file, then you specify it in your mod as some structure placed randomly at generation time 04:32 hmmmm except 04:32 hmmmm goofballs decided it's a good idea to seriously abuse it and now it has to do like 50x as many things as it was originally intended 04:32 hmmmm "pllllllease add this one feature hmmm, please!" and so i listen 04:33 Zeno` interesting 04:33 hmmmm but, yes, it really could have been accomplished with voxelmanip. schematics predate luavoxelmanip by a little while 04:33 hmmmm the most elegant solution to voxelmanips, in their current usage, would be to implement it as a gigantic wrapper around luavoxelmanip. 04:34 hmmmm the most elegant solution to schematics* i mean to say 04:34 Zeno` I'm just a bit wary of voxelmanip at the moment :( 04:35 Zeno` It's fine if you only have one mapgen mod, but when you have some using set_node() and some using voxelmanip... well, you know the issues 04:35 hmmmm oh that 04:35 VanessaE yes, "that". 04:35 hmmmm I never actually saw that myself 04:36 Zeno` My glowworms mod was using voxelmanip but I had to change it so that plantlife would work 04:36 hmmmm schematics do use voxelmanip though, internally, so if you use minetest.place_schematic() at all in your mod... guess what.. 04:37 hmmmm man, schematics are completely foobar right now 04:37 hmmmm decorations are FUBAR too 04:37 hmmmm everything is fubar because it requires much more development than it's getting, because... that's coding 04:40 Zeno` Could start from scratch I suppose 04:40 Zeno` just keep the Lua stuff because that seems to be designed nicely 04:41 Zeno` But that might break things for a few years 04:41 Zeno` So maybe it's not an option 04:48 paramat hi, back 04:50 VanessaE wb 04:54 paramat Zeno` there's always 'for vi in area:iterp(minp, maxp) do ... (stuff) ... end', that iterates through all nodes in a cubic area fast, no triple lua loop needed 04:55 Zeno` Indeed there is 04:56 Zeno` It's still missing the point, though 04:56 blaise I just tried to compile git minetest again, after maybe a year or so? and this is what happened.. http://pastebin.com/TXuexVGG 04:57 blaise I know /usr/lib64/libGLESv2.so is for embedded devices.. 04:58 blaise and this is an amd64 machine with a radeon RS690M (X1200) 04:58 blaise so clearly that file shouldn't exist on my machine 04:59 blaise the configure script also properly detected what gl was available and what wasn't 04:59 blaise just wanted to toss that out there.. :) 04:59 paramat setting or removing nodes in a cubic volume ... personally, after writing 49 mods i can say such an API is almost completely useless =} 05:00 Zeno` paramat, all your mods use voxelmanip don't they? 05:00 paramat most do 05:01 Zeno` And do all your mods work alongside other mods that do mapgen stuff and don't use voxelmanip? 05:01 paramat ah i need to test that to see if i can replicate Vanessa's bug 05:02 Zeno` The point is, say there was a function called remove_nodes_in_area(). The implementation of that function could /change/ without having to update mods 05:03 Zeno` e.g. if that function had existed all along, no mods would *not* be using voxelmanip now (if the remove_nodes_in_area() was changed from setting nodes to using voxelmanip and all mods used this standard way of doing it) 05:03 Zeno` So I disagree that it's useless 05:04 Zeno` There are, of course, other reasons why reinventing the wheel for every mod is not desirable 05:06 Zeno` I'd like to use voxelmanip for everything as well, by the way 05:07 Zeno` But I've experienced the same bug as Vanessa 05:07 paramat ah 05:07 Zeno` in my own code 05:07 Zeno` So, it can't be that uncommon 05:07 paramat was either of the mods plantlife or snow? 05:08 Zeno` One mod was my own and the other mod was plantlife 05:08 Zeno` But I can replicate it without using plantlife 05:09 VanessaE paramat: current plantlife, mind you. two on_generated calls, nothing but set_node() operations and a few entities in one of the sub-mods. 05:09 paramat ah okay 05:09 Zeno` And I can't work out why (the C++ for that area of things is confusing... well I find it confusing) 05:09 paramat yeah i am bemused too 05:10 Zeno` The C++ (from memory) calls a "helper function" that's written in Lua that iterates through registered on_generated callbacks 05:10 Zeno` But, then when it comes back to C++ .... I dunno how it's happening 05:10 Zeno` i.e. comes back to C++ via the mapgen Lua 05:11 paramat i'm trying to suspend judgement until i can replicate with 2 of my own mods :) 05:11 Zeno` voxelmanip specifically... it seems to have the same data as /before/ any of the mapgen mods are called 05:11 Zeno` So perhaps while it's iterating the map needs to be unlocked between calls to the on_generated callback so that voxelmanip gets up-to-date data 05:12 Zeno` I *think* that's what's happening anyway 05:16 Zeno` Is hmmmm still here? 05:16 Zeno` I think hmmmm may have started looking into it, I'm not sure 05:26 Inocudom I must go now. Bye. 05:32 hmmmm hello 05:32 hmmmm i am not looking into it yet, i have stuff to look into for work 05:32 hmmmm ...my workday is all day because i work at home 05:33 VanessaE is *anyone* gonna look into it? it's been a problem since last February. 05:35 VanessaE https://forum.minetest.net/viewtopic.php?p=129941#p129941 <---- first report I recall seeing of this issue. 05:48 VanessaE nnl 05:48 VanessaE bbl* 06:21 jp !seen sapier: read the comments & fix that please : https://github.com/minetest/minetest/commit/7993696fc4b59354974059e1f8d6b3063d316411 19:00 Krock Badabooom and the silence is dead. 19:01 sfan5 what? 19:02 VanessaE you.... 19:02 VanessaE you broke it 19:02 VanessaE look at that, the silence is all over the floor now, shattered to pieces. 19:02 Krock >:D 19:02 Krock dejà vu.. 19:13 Calinou …sans mono 19:16 VanessaE ...bold 19:19 cg72 bold?? what i miss? 19:21 VanessaE everything :) 19:21 cg72 crap 19:21 VanessaE it's all HIS fault 19:21 * VanessaE points at Krock 19:22 cg72 Krock what did you do now? 19:23 * Krock points with cg72 at VanessaE 19:24 * cg72 points at cg72 22:11 RentedMule minetest 4.10 -- ppa stable version -- is crashing on startup with two of my worlds, at "Running TestSocket" -- it complains that address is already in use, but netstat shows nothing listening on that port 22:11 RentedMule what should I look at next? 23:44 paramat hmmmm, before you start your weekend of hot luuurve with schematics, i need to make a request that the 'forceplacement' bool will remain 23:45 paramat it's essential for my generative projects such as https://forum.minetest.net/viewtopic.php?f=11&t=9577