Minetest logo

IRC log for #minetest-dev, 2014-08-29

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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 Zeno` joined #minetest-dev
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 Inocudom left #minetest-dev
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 Inocudom joined #minetest-dev
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:21 VargaD joined #minetest-dev
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 cg72 joined #minetest-dev
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 CraigyDavi joined #minetest-dev
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 CraigyDavi` joined #minetest-dev
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 CraigyDavi`` joined #minetest-dev
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:44 Miner_48er joined #minetest-dev
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:55 sapier left #minetest-dev
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:44 Hunterz joined #minetest-dev
03:51 paramat joined #minetest-dev
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:19 zat joined #minetest-dev
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 NakedFury joined #minetest-dev
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:26 paramat left #minetest-dev
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/vi​ewtopic.php?p=129941#p129941   <----  first report I recall seeing of this issue.
05:46 Hunterz joined #minetest-dev
05:48 VanessaE nnl
05:48 VanessaE bbl*
06:21 jp joined #minetest-dev
06:21 jp !seen sapier: read the comments & fix that please : https://github.com/minetest/minetest/commi​t/7993696fc4b59354974059e1f8d6b3063d316411
06:25 jp joined #minetest-dev
06:38 Garmine joined #minetest-dev
06:47 jp left #minetest-dev
07:00 NakedFury joined #minetest-dev
07:02 OldCoder joined #minetest-dev
07:36 Calinou joined #minetest-dev
07:51 AnotherBrick joined #minetest-dev
07:58 RealBadAngel joined #minetest-dev
09:06 Amaz joined #minetest-dev
09:17 Amaz joined #minetest-dev
09:17 HLuaBot joined #minetest-dev
09:17 Taoki joined #minetest-dev
09:17 deltib joined #minetest-dev
09:40 CraigyDavi` joined #minetest-dev
09:50 RentedMu1e joined #minetest-dev
09:50 w00tc0d3 joined #minetest-dev
09:51 Anchakor1 joined #minetest-dev
09:52 Weedy joined #minetest-dev
09:55 gentoobr1 joined #minetest-dev
09:57 Tesseract joined #minetest-dev
10:02 ImQ009 joined #minetest-dev
10:10 Gethiox-v2 joined #minetest-dev
10:11 book` joined #minetest-dev
10:25 gentoobro joined #minetest-dev
10:30 Ritchie_ joined #minetest-dev
10:32 Amaz joined #minetest-dev
10:33 VargaD_ joined #minetest-dev
10:38 sfan5 joined #minetest-dev
10:52 celeron55_ joined #minetest-dev
10:53 proller joined #minetest-dev
10:55 blais3 joined #minetest-dev
10:55 Amaz joined #minetest-dev
10:58 Gethiox-v2 joined #minetest-dev
11:02 hax404 joined #minetest-dev
11:04 ImQ009_ joined #minetest-dev
11:04 CraigyDavi`` joined #minetest-dev
11:04 OldCoder joined #minetest-dev
11:11 Evolykane joined #minetest-dev
11:18 ImQ009_ joined #minetest-dev
11:19 CraigyDavi` joined #minetest-dev
11:23 lanxu joined #minetest-dev
11:30 kahrl_ joined #minetest-dev
11:45 RentedMule joined #minetest-dev
11:47 Amaz joined #minetest-dev
12:04 Jordach joined #minetest-dev
12:15 kahrl joined #minetest-dev
12:16 Taoki joined #minetest-dev
12:36 blaise joined #minetest-dev
12:41 Krock joined #minetest-dev
13:40 NakedFury joined #minetest-dev
13:52 hmmmm joined #minetest-dev
13:58 NakedFury joined #minetest-dev
14:22 VanessaE joined #minetest-dev
14:35 Evolykane joined #minetest-dev
14:43 PenguinDad joined #minetest-dev
15:11 Calinou joined #minetest-dev
15:37 Amaz joined #minetest-dev
15:40 zat joined #minetest-dev
16:24 Hunterz joined #minetest-dev
16:49 kaeza joined #minetest-dev
18:01 Weedy joined #minetest-dev
18:01 Weedy joined #minetest-dev
18:27 khonkhortisan joined #minetest-dev
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:14 Amaz joined #minetest-dev
19:15 cg72 joined #minetest-dev
19:16 VanessaE ...bold
19:18 kaeza joined #minetest-dev
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
19:24 CaIinou joined #minetest-dev
19:35 Miner_48er joined #minetest-dev
19:56 ShadowNinja joined #minetest-dev
20:13 proller joined #minetest-dev
20:29 NakedFury joined #minetest-dev
20:29 proller joined #minetest-dev
21:21 proller joined #minetest-dev
21:25 proller joined #minetest-dev
21:29 SmugLeaf joined #minetest-dev
21:29 SmugLeaf joined #minetest-dev
21:43 Weedy joined #minetest-dev
21:43 Weedy joined #minetest-dev
21:43 CraigyDavi` joined #minetest-dev
21:45 Jordach_ joined #minetest-dev
21:47 Weedy joined #minetest-dev
21:52 SmugLeaf joined #minetest-dev
21:52 SmugLeaf joined #minetest-dev
22:01 Taoki joined #minetest-dev
22:03 VanessaE joined #minetest-dev
22:07 SmugLeaf joined #minetest-dev
22:07 SmugLeaf joined #minetest-dev
22:11 Miner_48er joined #minetest-dev
22:11 Jordach joined #minetest-dev
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:35 paramat joined #minetest-dev
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/v​iewtopic.php?f=11&amp;t=9577

| Channels | #minetest-dev index | Today | | Google Search | Plaintext