Time  Nick         Message
03:50 hmmmm        hey what's up with this https://github.com/minetest/minetest/commit/22dbbf0a6fc9547f0dbdb7f6076337b8c6acd48b
03:51 hmmmm        that's one giant race condition
03:51 hmmmm        not that it'll crash anything or cause invalid data accesses, it's just that it'll work about a third of the time
03:51 hmmmm        who thought it was a good idea to commit this
03:52 * hmmmm      looks at ShadowNinja
05:04 VanessaE     thexyz, ShadowNinja: what's the status of that test with the parallax/bumpmap test that caused the shaders to turn black?  Seems like you guys found a work around?
05:04 VanessaE     -test
06:52 nore         this should fix the shaders: https://github.com/Novatux/minetest/tree/shaders
06:54 nore         is anyone here?
06:59 nore         there: https://github.com/minetest/minetest/pull/1041
06:59 nore         hmmmm, any thoughts on it?
07:14 hmmmm        shouldn't you be asking RealBadAngel that?
07:14 nore         he isn't there right now... but I mean, about code things, etc
07:15 hmmmm        it looks fine to me but I'm really not qualified to say whether or not it's a good fix
10:02 thexyz       VanessaE: I have no idea
10:03 nore         thexyz, https://github.com/minetest/minetest/pull/1041
10:03 nore         about the shaders thing
10:03 thexyz       alright
10:04 nore         could you tell me what you think of it?
10:06 thexyz       I don't know, I haven't worked with shaders at all
10:07 nore         nor did I before yesterday... but code-wise, is there anything to be changed?
10:08 thexyz       how would I know then? I guess it's ok if it works for you
10:08 nore         I guess I'll have to wait for RBA to join then...
11:35 specing      Is there a comprehensive guide to minetest.conf somewhere?
11:35 specing      I am specifically interested in the mapgen variables
11:37 specing      In the end, I would like larger caves that aren't connected between eachother, fewer cave entrances on the ground and more frequent ore
11:38 specing      As far as I can learn from its name, 'indev' is the most recent map generator (and likely most featurefull?)
11:45 specing      Could not open file of texture: character.png
11:45 specing      Loaded mesh: npc_character.b3d
11:45 specing      Segmentation fault
11:57 specing      ^ on git
12:10 specing      Is "Sky" proller's server?
12:10 specing      It looks really effed up
12:13 sapier       specing ignore the names
12:13 sapier       indev isn't latest, latest unstable is v7 (atm) indev is modified v6
12:43 specing      Ah okay
13:04 troller      specing, my
13:18 sapier       argh reading light information from vmanip data is a pain
13:23 sapier       and lua 5.1 doesn't support bitoperations...
14:16 specing      troller: how did you manage to generate such a weird map @ Sky?
14:16 specing      Also is there a normal part of that map?
14:16 troller      normal map at 0,0,0
14:17 troller      its only adjusted noiseparams
14:17 troller      find point zero teleport
14:21 specing      I have mese, can I make my own teleporter?
14:22 specing      or a helicopter
14:23 specing      Ah I see it has ufos
14:24 specing      not sure if I have enough obsidian to make it
14:25 specing      sqrt distance to 0,0,0 is 40000
14:41 hmmmm        sapier, what's painful?
14:41 hmmmm        local day = lightval % 16; local night = math.floor(lightval / 16)
14:42 hmmmm        or rather local night = (lightval - day) / 16
14:42 hmmmm        the other alternative is that I create a zillion tables for every call
15:56 nore         anyone ok for https://github.com/minetest/minetest_game/pull/227 ?
16:05 specing      boats are seriously uncontrollable
16:05 specing      I think troller 's server is full of lag
16:11 iqualfragile specing: nah, poats realy have some kind of controlability probem
16:13 hmmmm        hmmmm
16:29 sapier       hmmmm painful because lua doesn't support bitoperations
16:30 hmmmm        what's wrong with what I just wrote?
16:30 sapier       lightval day and lightval night are stored within a single byte ;-)
16:30 nore         sapier, either add bit32... or use a pure-Lua implementation of binary things...
16:31 hmmmm        yes, but what's wrong with what I just wrote..?
16:31 sapier       you don't have those values in vmanip ;-)
16:31 hmmmm        yes you do
16:31 sapier       where?
16:31 hmmmm        local lightvals = vmanip:get_light_data()
16:32 sapier       returns light and day as single value
16:32 hmmmm        local lightval = lightvals[area:index(x, y, z)]
16:32 sapier       still thats a byte value containing day and night ;-)
16:32 hmmmm        ....
16:32 hmmmm        did you not read what I wrote
16:32 hmmmm        [09:41 AM] <hmmmm> local day = lightval % 16; local night = math.floor(lightval / 16)
16:32 hmmmm        [09:42 AM] <hmmmm> or rather local night = (lightval - day) / 16
16:32 hmmmm        [09:42 AM] <hmmmm> the other alternative is that I create a zillion tables for every call
16:32 sapier       oh :-)
16:33 sapier       that's tooo simple hmmmm :-) can't be correct ;-)
16:33 hmmmm        do you not understand basic bit operations
16:34 sapier       I know it's correct ;-P yet it's still to simple ;-)
16:34 hmmmm        if you can come up with a better way to do that please notify me
16:35 sapier       next thing after day and night values is calculating timed values ... any suggestions to do core code more simple?
16:36 hmmmm        where's that algorithm I pointed out yesterday?
16:36 hmmmm        oh daynightratio.h
16:37 sapier       that one :-)
16:37 hmmmm        these kinds of things we don't need a separate API for since the transition between Lua and C and back again is probably way slower
16:37 sapier       I guess the time normalization is more complex than it's required to be
16:37 hmmmm        it is
16:37 hmmmm        each of those table values have a difference of 250
16:37 hmmmm        so I guess you can do
16:38 thexyz       has anyone actually benchmarked it? "the transition between Lua and C and back again is probably way slower"
16:38 hmmmm        local values = {150, 150, 250, 350, 500, ...}; so on
16:38 hmmmm        values[(time_of_day - 4375) / 250]
16:39 hmmmm        instead of a linear search like it does
16:39 sapier       thexyz no need to benchmark luajited operations against mountains of code to transfere data from luastack to c++ and back
16:41 thexyz       of course, no need, at all
16:41 hmmmm        I suppose that we'd have to do all the measurement from within the core in some callback without other crap messing up the results
16:42 sapier       on pure number crashing luajit is almost equal to c++ code
16:42 sapier       I verified that in pathfinder
16:42 sapier       -crashiing + crunching
16:43 hmmmm        are you able to coax it to use integer operations?
16:43 hmmmm        did you find a way to check what luajit actually compiles it down into?
16:43 hmmmm        that would be helpful
16:43 sapier       I don't think so luas numbers are always floating point
16:43 sapier       but we don't have much non fp values in minetest
16:43 hmmmm        that might not be true, there's a "lua_Integer" type
16:44 sapier       is there?
16:44 hmmmm        yes we do, all array indicies ever
16:44 sapier       positions are floa
16:44 sapier       t
16:45 sapier       mapnodes are integers of course
16:45 sapier       ok but my current task is reading light values from vmanip ... and reading light values directly from map is doubtless slow
16:46 sapier       at least if you have to read more then a single node
16:47 hmmmm        well
16:47 hmmmm        that's no longer a problem as of a couple weeks ago
16:48 hmmmm        i originally put the bulk light data functions in for paramat but they're really useful here too
16:48 sapier       sorry but what happend a couple of weeks ago?
16:48 hmmmm        I added get_light_data and set_light_data to vmanip
16:49 hmmmm        if you're having any *real* problems using them please let me know
16:49 sapier       oh ok that one actually adds the possibility to do what I try to do now
16:50 sapier       the only thing I'm not sure what to do is that light source code in ... but maybe that information is already available in lua too I didn't look for it by now
16:51 hmmmm        it isn't as far as I'm aware
16:51 hmmmm        it's really not that bad
16:51 hmmmm        just translate day_to_night_ratio into lua literally and then make optimizations where you can
16:51 hmmmm        time_to_daynight_ratio i mean
16:53 sapier       ok I guess I now understand what that strange time calculation on top of that function does
16:53 hmmmm        it translates what time of day it is to the amount of light there is in a non-linear fashion
16:54 ShadowNinja  hmmmm: Can you add get_param2_data()? That way WE wouldn't have to abuse schematics for saving things with facedir and the like.
16:54 hmmmm        ShadowNinja, did you see what I was saying before about that pull request you merged a few days ago
16:54 sapier       no that calculation on top shifts daytime to be able to use a single mapping table
16:54 ShadowNinja  hmmmm: And where's the race condition in that?
16:55 hmmmm        the block isn't generated on time before the player spawns
16:55 hmmmm        it just so happens that a cave spawns right underneath the player and he falls
16:55 hmmmm        or maybe a tree gets spawned there from the border of a neighboring chunk
16:55 ShadowNinja  Ah.
16:55 hmmmm        basically what i'm saying is that guy's attempts to get around this are all futile
16:56 ShadowNinja  How whould you recommend fixing it?
16:56 hmmmm        if it were simple, spawning would've been fixed a LONG time ago
16:57 hmmmm        if you actually wanted to FIX it you'd have to add infrastructure
16:57 hmmmm        i.e. a way to prioritize chunk generation and a way to block on it
16:57 hmmmm        if you want to freeze up ServerThread to wait for map generation to finish, though, it's your call...
16:58 hmmmm        that could be a really long time
16:58 hmmmm        then you'd have people happily building away on a server and some shmuck joins and he ends up spawning somewhere that isn't generated and all of a sudden the entire server comes to a screeching halt and everybody says
16:59 hmmmm        "welp, it seems like someone's trying to join the server, we've gotta stop building until he's done"
16:59 ShadowNinja  That's obviously non-optimal. The current one seems to work pretty well, those spawning issues should be very rare...
16:59 ShadowNinja  But did the other method not have these issues?
17:00 hmmmm        the other method assumed that CONTENT_IGNORE was a solid block and so it'd count against the number of air nodes
17:00 hmmmm        so if the block wasn't generated yet it'd go look around for other places that do have it generated
17:02 specing      boats give my screen a knockback effect
17:02 ShadowNinja  Well accepting only air made me spawn about 20 nodes above a ocean far from spawn...
17:08 nore         can someone check that please? https://github.com/minetest/minetest_game/pull/227
17:11 ShadowNinja  nore: Mods shouldn't depend on hacky_swap_node, and swap_node should be local.
17:11 hmmmm        the method you just merged doesn't really help anything at all
17:11 nore         it was not local before... but I can change that too
17:12 hmmmm        it might seem like it does but findSpawnPos already does an emergeBlock() on the place it's querying which makes the emergeBlock calls in Map::findGroundLevel completely redundant
17:12 hmmmm        EFFECTIVELY the only thing that patch does is
17:12 hmmmm        1). increase the maximum spawn height by a lot
17:12 nore         ShadowNinja, changed
17:13 hmmmm        2). revert back to the old way of finding the ground level
17:13 hmmmm        #2 is bad because again, if that piece of the map doesn't exist yet, you're not going to find the ground level by probing!
17:14 hmmmm        so you need to rely on the map generator's findGroundLevel
17:14 nore         ShadowNinja, do you know a bit about shaders?
17:14 hmmmm        and no, it help you spawn outside of trees or caves, that's just the reality of it
17:14 hmmmm        I say we revert it
17:14 ShadowNinja  nore: No. Your patch looks OK to me, but better check with RBA.
17:15 nore         and can I merge the minetest_game thing?
17:15 celeron55    there should probably be some queue of players that need a spawn position when the map isn't loaded yet, and the server would reposition them once it gets to loading or generating a suitable position
17:15 hmmmm        it won't help you*
17:16 nore         ShadowNinja, ^
17:18 ShadowNinja  nore: That looks good.
17:18 hmmmm        so here's the deal
17:19 hmmmm        revert 22dbbf0a6fc9547f0dbdb7f6076337b8c6acd48b and I'll modify Map::getGroundLevel to use a mixture of the old probe method and use the new query-mapgen method if the former fails because it's not generated
17:20 hmmmm        and eventually I'll put in an async emergeBlock callback which we can trigger the remainder of the spawning process on
17:22 ShadowNinja  That seems good.
17:29 sapier       does read_from_map read node as well as light data?
17:29 hmmmm        it loads the map contents into the voxel manipulator
17:30 hmmmm        the various get_*data functions just put the stuff into table format so lua can do something with it
17:30 sapier       ok thanks that's the answer I was looking for
17:32 sapier       light works partly now ... obviously light sources are missing ... and there seems to be another effect where voxellight is more then core light data ... not sure what this is
17:33 sapier       could be missing sunlight_propagates check
18:09 sapier       any idea how to match vmanip and real world data?
18:10 hmmmm        ??
18:11 sapier       local voxel_light_data = voxeldata:get_light_data()
18:11 sapier       local node_data = voxeldata:get_data()
18:11 sapier       local voxelhelper = VoxelArea:new(minp,maxp)
18:11 hmmmm        noo noo noo.  minp and maxp is the generated area
18:11 hmmmm        you want the area that was emerged into the voxelmanip
18:11 sapier       wait
18:11 hmmmm        (the two positions you get from read_from_map)
18:11 sapier       local voxeldata = minetest.get_voxel_manip()
18:11 sapier       voxeldata:read_from_map(minp,maxp)
18:12 sapier       missed those lines I have them before the others
18:12 hmmmm        read_from_map returns two parameters
18:12 sapier       now doing  local raw_node_data = node_data[helper:indexp(pos)]
18:12 sapier       ok I guess i need to check those?
18:12 hmmmm        yup, ya sure do
18:13 hmmmm        check out some voxelmanip reference code
18:14 sapier       not sure if I like that interface ... it passes all that data even as it may be useless for me
18:14 hmmmm        i didn't come up with it
18:14 sapier       but for some situations it may be usefull to have at least some of the data you actually wanted to get
18:15 hmmmm        if you want to get a 2x2x2 sized area of block data from voxelmanip
18:15 hmmmm        that's fine, it'll get that
18:15 hmmmm        but it needs to get all of the containing chunks
18:15 hmmmm        this is why voxelarea exists
18:15 hmmmm        to simplify that
18:16 hmmmm        eminp, emaxp = voxeldata:read_from_map(minp, maxp)
18:16 hmmmm        voxelphelper = VoxelArea:new(eminp, emaxp)
18:17 sapier       I try
18:17 sapier       nope still doesn't match
18:18 sapier       seem to be less errors
18:18 sapier       RAW: 0 NodeVM: default:dirt NodeDirect: air VL: 0 ND:2 Pos: (25,4,-358)
18:19 sapier       of course light is calculated to 0 by vmanip data as it's dirt
18:19 hmmmm        you're simply doing something wrong
18:19 hmmmm        voxelmanip at this point has all the bugs worked out
18:20 sapier       I don't think anyone would recognize a shift
18:20 hmmmm        why don't you copy and paste your source code you're working with to pastebin
18:20 sapier       especialy as ppl usualy use it to modify things and not to just read data
18:21 sapier       https://gist.github.com/sapier/7861582
18:23 sapier       the pos calculation is exactly what core does on convertin float vector to int vector
18:24 hmmmm        oh you're rounding things
18:24 hmmmm        if you floored all of that, what happens then?
18:25 sapier       let me try again with those vmanip return values
18:26 hmmmm        well in this case it may be that VoxelArea is bugged
18:26 sapier       ok first try (not rounding anything --> no change
18:26 hmmmm        it treats everything as if they were integers
18:27 sapier       doing floor without 0.5 doesn't help either
18:27 sapier       ok maybe I should round minp and maxp first too
18:27 hmmmm        yes
18:28 hmmmm        please round things before passing them on to voxelmanip or voxelarea
18:30 sapier       no change
18:31 hmmmm        I hope you realize that origpos is bound to pos
18:31 hmmmm        they're references, not actual v3fs
18:32 sapier       ok that wasn't intended
18:34 sapier       ok that may have done the trick ... any chance to get the rounding to indexp and index?
18:34 sapier       stop
18:34 hmmmm        that would compromise speed for everybody who uses them as integers
18:34 sapier       got the error again
18:34 ShadowNinja  vector.new() and vector.round() may help...
18:36 hmmmm        hmm
18:36 hmmmm        well the code looks fine
18:36 hmmmm        it's not like your particular use case is unique any way
18:37 RealBadAngel hi all
18:38 ShadowNinja  hmmmm: So, what about get_param2_data()?
18:38 sapier       unique? I want to verify environment information within lua without having to callback to c++ for each single node ... I intend to us this for mob environment check too ... but It's only usefull if I can match get_node() values to vmanip node values
18:38 sapier       +e
18:39 hmmmm        ShadowNinja, I'll think about it
18:39 sapier       and as long as vmanip keeps telling me there is stone where get_node tells air ... I've got a problem ;-)
18:39 hmmmm        well it's not magic
18:39 hmmmm        VoxelManip is really simple
18:40 sapier       seems to be that simple that it's hard to understand it's issues
18:41 sapier       most time information seems to match but there are rare cases where they don't as noone is moving around in this world there can't ne any mapgen artifacts in there
18:41 ShadowNinja  sapier: assert((minetest.get_node(pos).name == "air") == (data[area:index(pos.x, pos.y, pos.z)] == c_air))
18:42 sapier       assert doesn't work in minetest ... and I get those missmatches when I try to calculate light
18:43 ShadowNinja  sapier: How doesn't it work?
18:43 ShadowNinja  (assert that is)
18:43 ShadowNinja  The backtrace issue is fixed, if that's what you are refering to.
18:43 sapier       if you do an assert it's pure chance you really see correct error (at least if there are more at once)
18:44 sapier       at least until yesterdays core ... didn't update today
18:48 ShadowNinja  Um, it isn't any worse than doing something like error("Assertation failed").  What you were talking about yesterday are programer errors that the interpreter can not warn you about until they actually result in a crash.
18:48 sapier       no it isn't but I don't need an error to see the missmatch ;-)
18:50 sapier       ok as I don't know that code in vmanip I'm not gonna fix it now ... as long as there ain't anyone telling me what I'm doing wrong I'll consinder vmanip as broken ... it's usefull for spawning but useless for speeding up environment checks
18:53 ShadowNinja  sapier: Update your gist.
18:54 sapier       updated
18:55 sapier       one last try ... traditional position rounding instead of core conversion format
18:55 ShadowNinja  sapier: What does the light_around tabe contain?
18:56 sapier       light_around definitions as of specified for adv_spawning ... not relevant to vmanip issues
18:57 sapier       no traditional rounding doesn't seem to work too
18:58 ShadowNinja  sapier: You are passing i to get_node_light().
19:00 ShadowNinja  sapier: Oh, two i's. You should change that to i and j or similar. And get_node_light takes a foating point number from 0 to 1.
19:00 sapier       oops another issue yes
19:00 sapier       thanks .. but still not the vmanip issue
19:01 sapier       I pinpointed a occasion where vmanip tells default:water_source while direct tells papyrus ... direct is right of course
19:01 sapier       and next default water is 2 nodes below and one to left or front
19:02 sapier       so it can't even be a off by one issue
19:04 sapier       ok lets try writing a simple test mod ... :-/
19:04 ShadowNinja  Well, your rounding is odd...
19:04 sapier       that's what core does
19:04 ShadowNinja  -10 -> -9
19:05 sapier       but it doesn't work for any other variant of rounding
19:05 ShadowNinja  Er, -11.
19:06 sapier       yes seems to be wrong but as I told math.floor(x+0.5) doesn't work either
19:06 ShadowNinja  sapier: origpos is never restored from what I see. Use vector.round, it copies it too.
19:07 ShadowNinja  That turns 20 lines into one...
19:08 sapier       I'll try too but I don't expect it to change anything
19:08 nore         RealBadAngel, so, can I merge #1041?
19:09 ShadowNinja  sapier: > =round(round(round(round(-10)))) --> -14 Does that seem right?
19:09 sapier       as expected no change
19:09 ShadowNinja  sapier: Update the gist.
19:09 sapier       that's only been an attempt to use lua code as close to core as possible
19:10 RealBadAngel nore, yes, the code is fine, i will use that idea to further configure the shaders
19:10 ShadowNinja  If the core does that then is's wrong. But it seems more likely that your mis-reading something.
19:10 nore         ok, merging it now except if anyone is against it...
19:10 sapier       updated
19:11 sapier       I guess what core does works due to int/float mechanics of c
19:11 hmmmm        mm oh you do realize that C rounds to -inf right?
19:11 hmmmm        not to 0
19:11 nore         ok, I'm going to merge the shader thing
19:13 ShadowNinja  sapier: The rounding  should be above the contains check.
19:14 sapier       what are you talking about hmmmm?
19:16 ShadowNinja  sapier: You try to convert a 0-24000 time range to a 0-24000 time range as if it were a 0-1 range.
19:16 ShadowNinja  (170 & 171)
19:17 thexyz       nore: uh, you shouldn't create pull requests from master branch if you plan to change it
19:17 thexyz       nore: https://github.com/minetest/minetest/pull/606 https://github.com/minetest/minetest/pull/1041
19:21 hmmmm        sapier:  err, I mean toward zero, but you round toward -inf
19:21 hmmmm        if you check the actual code in the core, after it does the +- 0.5 adjustment, it rounds toward zero
19:22 hmmmm        because it implicitly converts float to int
19:23 hmmmm        can you try doing math.ceil for the less-than-0 case?
19:27 ShadowNinja  local function round_to_zero(x) if x > 0 then return math.floor(x) else return math.ceil(x) end end <-- Something like that should make it a lot shorter.
19:28 sapier       trying ceil rounding ... shadow even if time was wrong the node still should be same ;-P
19:30 sapier       the rounding result seems to be more correct with ceil but vmanip <-> real world matching aint better
19:30 sapier       I try to create a simple mod only checking consistency
19:51 sapier       ok guess I found the main issue
19:51 sapier       why does it alway break once I said this
19:56 hmmmm        well what was the main issue?  is it valid or did you just think you found an issue?
19:56 hmmmm        because it could be that there are multiple unrelated problems
19:56 sapier       VoxelHelper:new doesn't complain about invalid parameters
19:56 hmmmm        of course not
19:56 hmmmm        and you mean VoxelArea btw
19:57 sapier       I do but having nil as a parameter that is required is an error to me ;-)
19:57 hmmmm        the entire voxelcrap was made with speed in mind, not ease of use
19:58 sapier       ok for my simple testmod vector.round() seems to be valid
19:59 sapier       sorry speed in mind is not a excuse for skipping error check in a function called ONCE ;-)
20:00 nore         thexyz, ?
20:00 nore         <thexyz> nore: uh, you shouldn't create pull requests from master branch if you plan to change it <-- about that
20:00 hmmmm        well I was opposed to error checking in general for that reason
20:01 sapier       especialy if parameters are passed in a non intuitive way as VoxelArea:new({MinEdge=got_minp,MaxEdge=got_maxp})
20:01 sapier       btw () is missing in lua_api.txt
20:01 hmmmm        you can skip that
20:01 hmmmm        VoxelArea:new{} is valid
20:02 sapier       realy with {}?
20:02 hmmmm        shockingly yes
20:02 hmmmm        must be some oddity of lua syntax that I accidentally discovered
20:02 sapier       where's that syntax from?
20:03 hmmmm        shrug
20:03 sapier       never seen anything like that
20:03 hmmmm        try it
20:03 sapier       and how to passt the edges?
20:03 nore         thexyz, if that was about my force loading pull request, it is because I made that pull request when I didn't even know how to use git...
20:04 nore         and IIRC I haven't been able to change the branch without creating another pull
20:05 celeron55    sapier: yes, you can leave out () from a function call that has a single table argument
20:05 sapier       that one should be forbidden ;-)
20:07 kaeza        works for strings too
20:08 sapier       I'm working with lua for 2 years now and I'm still astonished what strange constructs are possible
20:08 kaeza        it's some wonky way to support "extensions" to the syntax, like require "foo"
20:08 hmmmm        scripting languages in general
20:08 hmmmm        I've grown to strongly hate scripting languages
20:08 sapier       but still Imho new should not pass without error if MinEdge and MaxEdge are missing
20:09 hmmmm        at work I have a side project that I have to do JS and python for and it's horrid
20:09 sapier       ok seems now I don't get node missmatches any longer ... *crossing fingers*
20:11 celeron55    that particular lua shortcut is probably due to how they based lua on some older projects and wanted the old file format to be loadable as a lua script
20:12 celeron55    here's a very old text about lua in which they describe it in an... interesting way: http://www.lua.org/semish94.html
20:13 celeron55    it's about the first ever version i guess 8)
20:13 sapier       do we really want to encourage users to use that old syntax?
20:16 celeron55    (of course it also for what kaeza said; fancier syntax; eg. if you implement a class system in lua, it's very useful)
20:16 celeron55    sapier: probably not
20:17 kaeza        someone on #lua posted the other day a C++-like syntax, like class "Foo" : extends { ... }
20:17 kaeza        with some clever constructs :P
20:17 sapier       I'd not be surprised if others would assume that to be an error too ... at least you wonder what is meant by it
20:18 sapier       I missinterpreted it to be pseudocode
20:18 kaeza        err Java-like rather
20:18 celeron55    sapier: and it's of course completely out of question to actually learn the language one is using?
20:18 celeron55    one can read the "programming in lua" book in one afternoon and it's super useful
20:18 sapier       I assume you know any special construct and meaning of c? :-)
20:19 hmmmm        when you hate the language you're working with you don't necessarily want to read a book on it
20:19 celeron55    you can know practically everything about lua
20:19 sapier       there are very less languages where you have only one possible way to do something ... most ppl don't memorize any single possible way if there are hundreds ;-)
20:20 celeron55    hmmmm: it helps because then you are able to avoid the pitfalls and that way be more happy
20:20 sapier       I don't deny this would be usefull ... yet it's like backups ... everyone knows you should do them ;-)
20:21 lanxu        Wait? reading "programming in lua" in one afternoon... And understand everything? :)
20:21 sapier       and memorize everything
20:22 PilzAdam     hmmmm, how can you "hate" a programming language?
20:22 celeron55    lanxu: well at least you'll immediately recall single argument functions from the book when seeing them elsewhere
20:22 sapier       celeron page 10 line 5 word 2? :-)
20:22 hmmmm        PilzAdam, easily
20:22 celeron55    sapier: if that's how you read books, then i understand you hate it
20:22 celeron55    you probably also make backups by copying files by hand
20:23 celeron55    anyway!
20:23 sapier       I didn't say I hate it thats hmmmms saying... I've seen worse languages ;-)
20:23 sapier       scheme for example
20:23 kaeza        I don't see anything wrong with implementing foo{...} as convenience for foo({...})
20:23 celeron55    just change the docs to not suggest the parenthesis-less syntax
20:23 kaeza        fun fact: foo:bar() is the same as foo.bar(foo), except 'foo' is only evaluated once
20:23 jin_xi       lets rely on things like that
20:24 sapier       I knew that kaeza ... that feature is particulary usefull :-)
20:24 celeron55    kaeza: so can we detect the evaluation count and screw people up?
20:25 kaeza        no I mean, if you do foo[bleh].bar:baz(), it does less lookups than foo[bleh].bar.baz(foo[bleh].bar)
20:26 celeron55    i know you mean that
20:26 kaeza        oookay, moving on...
20:26 kaeza        :P
20:26 sapier       yea I thought about fixing mobf to use that syntax ... but was to lazy to do by now :-)
20:30 sapier       ok I may have succeeded in fetching light values from vmanip
20:30 sapier       ... light values are floored uppon return to lua
20:42 sapier       https://gist.github.com/sapier/7863517 that code might be usefull for others ... what do you think about adding it to builtin?
20:43 hmmmm        possibly
20:43 hmmmm        if I were you I'd compare it against computing in the core and see what's better
20:44 sapier       good Idea as I have identical code here I may even get a valid result
21:20 sapier       ok ... answer to is it worth using voxel is a absolute exact and non missinterpretable "maybe" :-/
21:21 sapier       if you only want to read a single(up to some value) light value core is way faster ... but as of some threshold voxelmanip starts to become faster
21:28 sapier       wow ... guess there's a situation where core lighting really looses "Comparing core to voxel : 1805.3405761719 <--> 0.0048828125"
21:33 sapier       forget about it ... benchmark error :-)
21:56 sapier       ok without luajit voxelmanip light isn't at all a competitior ... with luajit you need to check very high numbers of nodes to gain some benefit ... but there's way more spread then expected
21:57 sapier       very high numbers == >10k nodes
22:41 hmmmm        by "core lighting" you mean get_node_light()?
22:42 hmmmm        also you're taking into account the C->lua switching, right?  you need to benchmark in the core to figure that one out
22:56 sapier       yes I do
22:57 sapier       why do I need to benchmark in core? I'm interested in how much time to get that information to lua mod
22:58 sapier       if whole spawning is done withing core that'll be way faster of course
23:01 emptty       ShadowNinja: you said a while ago that the furnace should use minetest.swap_node. Could you please be more specific? That bug of blinking furnaces is driving me crazy
23:01 emptty       (but I'm a complete noob with the minetest codebase)
23:07 hmmmm        sapier, well you also need to consider that an 80*80*80 chunk is 512000 nodes, which is way more than 10k
23:09 sapier       yes I tried 21*21*21 (distance 10)
23:09 hmmmm        is this the number of checks that need to be done for a single spawn?
23:09 sapier       but if you don't have luajit that value ise more 1 milion then 10k
23:10 sapier       no I increased the number till I found the point where core and voxel have been equal
23:10 hmmmm        to be fair, VoxelManip was designed for way bigger jobs than 21x21x21
23:11 hmmmm        and not for get_node_light() which is pretty lightweight compared to setNode()
23:11 sapier       worst thing I have right now is 7*7*7
23:12 sapier       true
23:12 sapier       wrong tool for this job
23:12 hmmmm        see, the thing about VoxelManip is that you're able to check multiple things about that node at once
23:12 hmmmm        like the content as well
23:13 hmmmm        so you can have one voxelmanip object on that area, find the surface, spawn on a specific node, with a specific number of nodes around it, and then check the light values, etc.
23:13 sapier       doing all of those things requires way less then 10k nodes
23:14 sapier       counting of nodes can be done completely in core no need to transfere all data up (most time)
23:14 sapier       more relevant is you can't check for objects more then 32 nodes away
23:15 sapier       e.g. if you want mobs to be rare
23:16 sapier       if you do on a single spawn you can use spawn chance ... but if you do continous spawning it's just a matter of time till that mob will be everywhere
23:18 hmmmm        so it's just based on the proximity to other mobs
23:18 hmmmm        Minecraft has a "mobcap" that deals more with the number of mob objects in the loaded area
23:18 sapier       yes but that does only work for distances below activity range ... need to find some way to work that one around
23:19 hmmmm        see, we could do that instead if it weren't for the current crappy block loading scheme
23:19 sapier       current adv_spawning can already do mobcap
23:20 sapier       one possibility is to store unloaded mob locations within a separate metadata file
23:20 sapier       do you know how fast lua's hashtable implementation is? does it do linear search?
23:21 hmmmm        hahaha
23:21 hmmmm        lua's hashtable implementation called a "table"
23:21 sapier       ok so linear search :-)
23:21 hmmmm        if lua really did linear searching for table lookups the result would be an unusable toy language
23:21 sapier       no linear search?
23:22 sapier       if not it might be an option
23:22 hmmmm        I'm saying there's no way that Lua could possibly be using linear search without the performance being even MORE dogshit than it is currently
23:22 sapier       ok ok :-)
23:23 sapier       guess we really need a real on_deactivate callback for entities
23:25 hmmmm        ugh, I need to add a vector to the Mapgen class but I really don't like the idea of adding yet another non-POD datatype...
23:25 hmmmm        or no, it is POD right now.
23:28 ShadowNinja  emptty: swap_node doesn't reset the formspec. It's added in master now.
23:30 emptty       ShadowNinja: so, there is no workaround for 0.4.8?
23:31 ShadowNinja  emptty: Well, you could manually apply the patches to the core and game. But not without modifying it.
23:36 emptty       ShadowNinja: will this one be enough? https://github.com/minetest/minetest/commit/d879a539cd19ddd1ee34afec2512fb2238de2822
23:37 Exio4        you need the patch for minetest_game too
23:37 ShadowNinja  emptty: You'll also want the doc fix, and the..^
23:37 emptty       I don't really want the doc fix for now ;)
23:38 emptty       That one? https://github.com/minetest/minetest_game/commit/47a49eccf4bd59427fa7486fd413e6eade1db896
23:40 Exio4        yeah
23:52 emptty       let me try it :)
23:53 emptty       But that's quite a huge bug, by the way. It kinda ruins the gameplay.
23:54 emptty       don't you think that it could justify a 0.4.8.1 or something?