| 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/viewtopic.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/commit/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/viewtopic.php?f=11&t=9577 |
