Time  Nick          Message
01:55 kahrl         http://paste.dy.fi/LYD second column is # of outgoing depends, third column # of incoming depends, fourth column the product of those
01:56 kahrl         the ones at the end should bring the most benefit when optimized
01:56 Tesseract     kahrl: Did you see my reply?
01:57 kahrl         Tesseract: no
01:57 Tesseract     <Tesseract> kahrl: There wasn't anything wrong with it, you just mentioned that you would like to have bind_address = 0.0.0.0, :: ... and not have ipv6_server. But that would take a lot mort time to implement.
01:57 kahrl         oh about #762
01:57 Tesseract     #862
01:58 kahrl         yeah, sorry :P
01:59 Tesseract     Also #856...
01:59 kahrl         Tesseract: you don't need to implement that
01:59 Tesseract     Hmmm?
01:59 kahrl         the multiple bind_address thing
01:59 Tesseract     Oh, yes.
01:59 Tesseract     So, is it good to merge?
01:59 kahrl         does #862 always work in singleplayer now?
01:59 Tesseract     Yes, it should. Although I can't test it.
02:01 kahrl         isn't this a memory leak? bind_addr.setAddress(new IPv6AddressBytes());
02:03 Tesseract     Hmmm, maybe.
02:04 kahrl         aren't there people who start a server through the menu who might want to set bind_address?
02:06 Tesseract     Without a lot more complexity only 0.0.0.0/:: and 127.0.0.1/::1 would work...
02:08 kahrl         I should really try to find the pipe-socket code I wrote once
02:09 kahrl         (it made it so that instead of using OS sockets to communicate in singleplayer / client+server mode, messages are passed through mutex-locked in process memory)
02:09 kahrl         that would eliminate all those problems
02:10 kahrl         if anyone wants to write it, feel free :P it's unlikely I'll find it again
02:11 Tesseract     Hmmm, where should I free/delete it?
02:12 kahrl         just make the if into a block and use a local IPv6AddressBytes
02:12 Tesseract     Ah, I think I see...
02:34 Tesseract     Gah, found a bug, but I have to wade through main.cpp to find out what is causing it...
03:26 Tesseract     \o/ singleplayer with IPv6 works finally.
03:28 Tesseract     kahrl: It should be all fixed now.
03:49 * VanessaE    peeks in
05:52 kahrl         is there any point in keeping farmesh?
06:06 celeron55     no
06:06 celeron55     it's been scheduled for deletion a long time ago
06:09 celeron55     >it's just not correct for a member of Map to deal with the environment, it's supposed to be separate from that
06:09 celeron55     yes, the whole thing should be in Server/ClientEnvironment
06:09 celeron55     the Map is just for the voxelly stuff
06:15 VanessaE      the point of farmesh was to give the impression of really-far-away stuff without necessarily having to render said stuff, right?
06:16 kahrl         VanessaE: kind of
06:16 kahrl         (it still rendered polygons, of course, and it was horribly inefficient at that)
06:17 VanessaE      right
06:17 kahrl         and architecturally it doesn't work in 0.4
06:17 VanessaE      actually, tried it once recently...
06:17 kahrl         because the client doesn't know what the mapgen on the server does
06:17 VanessaE      it sorta still worked
06:17 VanessaE      but it was utterly useless :)
06:22 celeron55     it should be removed even if someone redoes it sometime
06:22 celeron55     because it can't work using any of the principles it currently uses
06:23 celeron55     (search the logs for some more plans about it)
06:29 * kahrl       committed... something. https://github.com/kahrl/minetest/compare/omnicleanup
06:31 kahrl         seems to reduce the initial compile time on singlecores by roughly 5%: http://paste.dy.fi/LJ2
06:32 kahrl         it's hard to quantify but the savings later on should be bigger (not as many header dependencies, so fewer source files to recompile)
06:34 celeron55     oh by the way, wtf was this yesterday's #minetest license war
06:35 VanessaE      celeron55: no, I agree with you - remove it (farmesh) since it's guaranteed not to work properly anyway
06:35 celeron55     "< Peacock>  no matter what license mt uses, im pretty sure celeron is the copyright holder?"
06:35 celeron55     this is just plain retarded
06:35 celeron55     "and can relicense what he wrote at will"
06:35 VanessaE      oh G*d, don't start that in here :(
06:36 celeron55     oh i'll kick anyone who continues 8)
06:36 VanessaE      :)
06:43 celeron55     (to forum moderators: if somebody insist on releasing non-free mods, "Minetest-related projects" is the license-agnostic forum section)
09:26 troller       https://github.com/proller/minetest/commit/d378deefddd5fb27e85025b932f014cda91d4dbd
09:28 thexyz        why?
09:36 kahrl         for some reason the sqlite documentation about PRAGMA synchronous = FULL gets this wrong (at least fails to mention it)
09:36 kahrl         it's mentioned in http://www.sqlite.org/howtocorrupt.html
09:37 kahrl         even in FULL mode, a power outage can still break your database with most kinds of disks you're likely to encounter
09:37 kahrl         because most disks lie about fsync
09:41 celeron55     someone should benchmark how much faster OFF is
09:42 celeron55     in one project of mine i have to use OFF to get any kind of reasonable performance even while it uses transactions properly
09:43 celeron55     (haven't actually tried "normal" though)
09:45 celeron55     (also i don't think we want to enable SQL injections via minetest.conf)
09:45 Calinou       relevant: https://xkcd.com/1172/
09:53 thexyz        lol, who cares
10:36 nore_         I have an idea about a "shapechanging" nodebox type
10:37 nore_         the 8 first boxes of the nodebox could be toggled visible or not by the 8 bits in param2
10:38 PilzAdam      RBA had that idea a while ago
10:38 PilzAdam      but its not very effective
10:38 nore_         I could do it, but is it a good idea and would it be merged?
10:38 nore_         why?
10:38 nore_         stairplus could use only 1 node, as pipeworks, etc
10:39 nore_         technic cables too
10:39 PilzAdam      e.g. mesecons would need a node with about 20 nodeboxes to get all the wires in one node
10:39 nore_         no, mesecons need 9 boxes
10:39 nore_         so 2nodes
10:40 PilzAdam      AFAIK currently one pipeworks node has 20 nodeboxes
10:40 nore_         instead of 64 curently
10:40 PilzAdam      so it wouldnt be useable in this mod at all
10:41 nore_         pipeworks has only 6 boxes for tubes, I dont know for pipes
10:41 PilzAdam      8 boxes is just too restrictive, IMO
10:42 nore_         it is much better than nothing
10:42 nore_         but else it could be done in meta
10:42 nore_         and you can get 32 boxes
10:43 nore_         but I dont know if node meta is accessible to the client
10:43 PilzAdam      of course it is
10:44 nore_         then it can probably be done
10:44 PilzAdam      there was a branch about setting nodedef in meta somewhere
10:44 nore_         where is it? it is exactly what we need
10:45 nore_         it is even better
10:47 PilzAdam      https://github.com/celeron55/minetest/commits/meta_set_nodedef_2
10:47 PilzAdam      there are some problems with it, though
10:48 PilzAdam      and that BKVL stuff has to wait until 0.5.0 since it breaks compatibility
10:49 nore_         what are those problems?
10:57 nore_         but doing a shapechanging nodebo
10:58 nore_         x could be useful, or not? would it be merged?
11:08 celeron55     well, i can think of a way to make the original suggestion of nore_ work
11:08 PilzAdam      64 bit param2? ;-)
11:09 celeron55     it could be done so that in the node definition, there would be a list of lists of nodebox indices, and the used list would be selected directly via param2 value
11:09 celeron55     altough
11:09 celeron55     that doesn't give more than 8 bits of freedom
11:10 celeron55     it assumes that some of the 8 bit configurations would be useless
11:11 celeron55     (it allows more boxes though)
11:12 celeron55     i don't know if this is wanted though
11:12 celeron55     or more like accepted
11:13 celeron55     i mean, what about textures, for example?
11:14 celeron55     it would end up quite restrictive
11:42 nore_         perhaps some other param2 that would allow to choose textures in a list too?
12:08 PilzAdam      and what about <insert random field of nodedef>?
12:11 nore_         what field?
12:12 nore_         i dont think other fields could be needed
12:13 celeron55     you're very wrong
12:13 nore_         and about meta_set_nodedef, why does bkvl break compatibility?
12:13 nore_         celeron55, what field?
12:16 celeron55     even if they were nothing currently, we're highly likely to have something in the future
12:16 celeron55     or someone will want to have something either way
12:16 celeron55     there*
12:17 nore_         but in what way does bkvl break compatibility?
12:17 celeron55     what kind of a question is that
12:17 celeron55     it's a completely different serialization format
12:18 celeron55     more specifically it breaks backwards compatibility; but that's not an issue
12:18 celeron55     the issue is developing it to be mature enough for actual usage, which it is far from
12:19 nore_         but there could be no way to connect an old client to a new server if the server knows the version of the client?
12:19 celeron55     no
12:19 celeron55     there is no system and will never be any system to translate node metadata that way
12:19 celeron55     or, well, any kind of translation wouldn't be enough either
12:20 nore_         so metadata replaces nodedef completely?
12:20 celeron55     i mean
12:20 nore_         nodedef of normal nodes is not sent to clients?
12:20 celeron55     you can connect, but nodes that would use that thing will only be seen in their default look and behavior on old clients
12:21 celeron55     and at the same time the protocol compatibility might be reset so that it doesn't work anyway to get rid of convoluted compatibility code (there's plenty of that currently)
12:21 nore_         is that really a problem? because it is the same with leveled nodeboxes
12:22 celeron55     yes it is and i won't explain it any further; you can expect such clean-ups once in a while
12:22 celeron55     however i have no idea when it might happen; not in near future
12:23 celeron55     also there are some devs that do argue against the meta_set_nodedef style thing
12:23 nore_         it was said it will be with the release of 0.5.0, but that will be in a long time
12:23 nore_         who is against it?
12:24 celeron55     what do you do with that information
12:25 nore_         nothing, it is just being curious... ;)
12:25 celeron55     well, not telling it now anyway; it's pretty much offtopic currently
12:28 celeron55     (i try to spare people from useless feature wars so that they can get something done instead in their little time)
15:32 sapier        https://github.com/minetest/minetest/commit/0d60bc55e4373167141f0f08a10a2174cc7e029a sometimes ppl should fix issues instead of adding hacks
16:08 Exio4         PA was waiting for you sapier, but you didn't appear :P
16:10 PilzAdam      sapier, feel free to fix it in a proper way
16:10 PilzAdam      I am not familiar with the main menu code
16:11 PilzAdam      it was just too annyoing that Minetest takes over 10 seconds to start when you download something else
16:12 sapier        I'm wayting for vanessa to give feedback about my asyncronous server list prototype ... maybe she already gave it but I've been a little bit busy
16:12 sapier        -y+i
16:12 Exio4         lazy curl? ;P
16:12 PilzAdam      kahrl is working on a more generic implementation of that
16:13 sapier        exactly similar too the async lua system I once suggested
16:13 sapier        more generic?
16:13 PilzAdam      I think its this branch: https://github.com/kahrl/minetest/commits/httpfetch
16:14 sapier        and what is more generic about this?
16:14 PilzAdam      I was told it is
16:14 sapier        it's just another special case that is needed too
16:14 sapier        async file download
16:15 sapier        doesn't help for json files
16:15 sapier        unless you add a full json to luatable parser ;-)
16:16 sapier        but combining with this https://github.com/sapier/minetest/tree/asynchronous_events
16:16 sapier        will fix the issue
16:16 sapier        s
16:19 sapier        does anyone understand why this is so much code?
16:19 sapier        ahh ok he wants to replace the normal download too
16:20 PilzAdam      the internal API for that does not depend on cURL
16:20 sapier        if this is added it will
16:21 Exio4         he wants to abstract the whole "http" code ;P
16:21 sapier        unless he's removing the dependency until he finished it
16:21 PilzAdam      that is what I meant with "more generic"
16:21 sapier        imho it's not generic enough the async calls I tried to add aren't as specific as "download something"
16:21 PilzAdam      sapier, I mean outside of the httpfetch.* files
16:22 sapier        and the lua version I proposed some months ago would even have been usable directly from mods
16:22 sapier        does he know about the async events?
16:22 sapier        I posted this some days ago but not very loud
16:22 PilzAdam      he is aware of your code
16:23 PilzAdam      he said that his code would be a more generic solution
16:23 PilzAdam      IIRV
16:23 PilzAdam      *C
16:23 sapier        ok what is more generic that two unspecified callbacks?
16:23 sapier        :-)
16:23 PilzAdam      it adds the httpfetch interface for the whole core, not only for the main menu
16:24 sapier        yes but it's limited to http ;-)
16:25 sapier        ok I guess I need to talk with himself maybe some information is lost by retelling what he wants to do
16:28 PilzAdam      <sapier> imho it's not generic enough the async calls I tried to add aren't as specific as "download something" <- can you explain that further?
16:28 sapier        https://github.com/sapier/minetest/commit/c900051f68fa01cc8e58034f934eb009abbe2885 guiEngine.h
16:28 sapier        line 60
16:29 celeron55     sapier: kahrl has a huge branch where he has reworked much of the lua and main menu code
16:29 sapier        do you have a link celeron?
16:29 celeron55     for combining the APIs and for header optimizations
16:29 celeron55     and stuff
16:29 PilzAdam      the omnicleanup branch in his repo
16:29 sapier        great ... that's ironic
16:29 celeron55     you pretty much need to work with kahrl for whatever you do now to it
16:29 celeron55     (until it's merged in some form)
16:30 sapier        the apis have ben separated on purpose
16:31 sapier        ok I'll have a look at it firs
16:31 celeron55     (i don't actually know what the branch exactly does; kahrl hasn't yet written a summary about it (that he intends to))
16:32 celeron55     also, it's so huge you'll have tough time looking at it :P
16:35 PilzAdam      sapier, the httpfetch branch does a pretty similiar thing
16:38 VanessaE      sapier: I'm waiting for the httpfetch branch to go through, rather than test your patch
16:41 sapier        I wonder why ppl always think they don't need return values
16:43 VanessaE      bbl
16:50 sapier        I guess making main engine independet from componets was to ambitions to be preserverd for more than a month ... back to old style c programming
16:51 sapier        vanessae the http engine wont fix modstore nor big serverlists unless completely redone I don't see any of the similaritys pa is talking about
16:51 sapier        both use threads yes ... but that's not a similiarity
16:52 sapier        but I guess I should wait for more comments until tomorrow after seeing that after 2 weeks not beeing active everything I did was reclaimed
16:53 sapier        btw I'm still waiting for 774 640 and 418
16:54 sapier        and yes not adding them will push pa's simplemods
16:54 sapier        so if you want to make mobf die it's best to not add those
17:17 sapier1       not a single comment to 774 640 and 418? Guys I want a decision either add it or drop it I want to continue mobf development
17:18 PilzAdam      640 and 418 are good, I guess
17:19 sapier1       ok and what's the issue with 774? maybe it can be fixed?
17:19 PilzAdam      wasnt there a compatibility problem?
17:20 sapier1       not really
17:20 sapier1       it seemed to be but it isn't
17:22 PilzAdam      then its good
17:23 sapier1       ok if it's good plz add .. if you don't feel fine about the last one add the two others first
17:23 PilzAdam      the lua-api.txt part is messed up, though
17:24 sapier1       no it isn't I just can't document things I don't know what they're doing
17:24 sapier1       at least not exactly
17:24 PilzAdam      then why do you add lines with them?
17:25 sapier1       because someone (I don't know who was sleeping when adding it) has to fix this
17:25 PilzAdam      also you should explain that frame_speed is adjusted according to base_velocity and the objects velocity
17:26 sapier1       what about this sentence "if this is set animation framerate is adjusted  dependent on frame speed and this velocity"
17:27 sapier1       better "if this is set animation framerate is adjusted  dependent on frame speed, this velocity and objects xz velocity"
17:28 PilzAdam      hm, why only xz?
17:29 sapier1       because z velocity is rarely usefull for horizontal movement
17:29 sapier1       y of course
17:29 PilzAdam      think about e.g. birds
17:29 sapier1       if you really want to add this you need a completely different system
17:30 sapier1       e.g. not use a single velocity but multiple and to be more exact you need models supporting differend overlayd animations
17:32 sapier1       imho xz is a fair solution not beeing overcomplicated while providing much benefit
17:52 sapier1       https://github.com/minetest/minetest/pull/774 better?
18:42 sokomine      would it be possible to teach mt not to self-destruct if there's no more space on disk?
18:43 Tesseract     if (space_on_disk < MIN_SPACE) { throw std::exception("Not enough space on disk")}
18:44 sapier1       sokomine do you think something like disabling mapgen instead?
18:45 Tesseract     There is a read-only mode for the map. You would just have to trigger that.
18:46 sokomine      started it with no space left free, and instead of complaing, it just happily deleted favoriteservers.txt and minetest.conf. those ought to be restorable...there have been other occasions when it deleted world config files, player config files etc
18:46 sapier1       ok that's like that and even better yes
18:46 sapier1       what ? deleted those files?
18:46 sapier1       it never should delete those files unless a new one is already present
18:46 sokomine      yes, something like what tesseract wrote might be a good idea. no point in running a server if it can't be run anyway
18:47 sapier1       yes but that's not the issue you actually mentioned ;)
18:47 sokomine      not really deleted. set to zero bytes. as it loves to do when space is tight :-(
18:47 sapier1       those crucial config files never shall be deleted without having a backup
18:47 sapier1       that's same as deleting
18:48 sapier1       a sane solution would write the new file and rename it to minetest.conf for example
18:49 sokomine      luckily, i was puzzled by the strange font and didn't start a world. it would probably have been set to zero as well (at least the config files. and if those change the mapseed changes and the world starts looking ugly at best)
18:53 sokomine      and the first mapgen-bug that happened on redcrabs server was due to low disk space as well. detecting too low disk space may save a lot of buildings
19:01 celeron55     sapier1: it's the long running matter of minetest not writing to a temporary file and then moving into place
19:01 celeron55     nobody has wanted to ever fix it
19:02 celeron55     the problem and the fix has been always known; it's the coder what is missing
19:02 sapier1       I guess I should write some lines of code to trigger someone to write it himself ...
19:02 sapier1       sorry I'm a little bit ironic today
19:02 celeron55     8D
19:03 celeron55     it shouldn't be taken too personally if things happen to take multiple iterations
19:03 sokomine      perhaps each individual occourance of that bug is too annoying to one person only each time and only for a short time :-(
19:03 celeron55     the first ones always serve as inspiration and proposals
19:03 celeron55     and as initial testing
19:04 sapier1       if I did take this to personaly I'd have left some hours ago ... but I'm reasonable enough to realize if some changes really are in right direction (in most parts)
19:05 sapier1       no sokomine this bug just is to simple to be fixed ;-)
19:22 kahrl         10 print "Hello World!"; 20 goto 10
19:23 sapier1       hello kahrl ... the one I was looking for
19:23 sapier1       what's your intention about the http thing?
19:23 kahrl         oh okay, was going to ask about the lua thing first, but alright
19:24 kahrl         if it turns out to be needed we can add your async thing anyway
19:24 sapier1       that's mostly fine ... I guess the core modules independent design was to ambitions for minetests c style
19:24 kahrl         does loading favorite servers from a file really take any noticeably amount of time?
19:24 kahrl         s/bly/ble
19:25 sapier1       it's not the loading time but the parsing issue
19:25 kahrl         is jsoncpp that slow?
19:25 sapier1       sorry I think we're talking about different things
19:25 kahrl         I can't really believe that
19:26 kahrl         maybe; I haven't really looked at the serverlist loading code
19:26 sapier1       my aproach aimed towards a generic threading interface that could be used for different things not only http download
19:27 kahrl         I think SimpleThread is fine for that
19:27 sapier1       the favorites list was only a proof of concept ... it's slow when you don't have a online connection and need to wait for timeout
19:27 sapier1       no it isn't
19:27 kahrl         or do you mean coding threads in lua?
19:27 sapier1       you need a way to pass back the result
19:27 sapier1       starting a thread is only half of the job
19:28 sapier1       no not lua ... that's a thing I suggested months ago without success this is a interface to make asyncronous lua api calls only
19:29 sapier1       favourites list is one example
19:29 sapier1       e.g. you request the favorite list to be downloaded
19:29 sapier1       if it's completed you get an event
19:29 celeron55     my view on things is that it's generally best to actually code fast code and only do the things asynchronously that really need to be; it limits the variety of bugs that can happen
19:29 sapier1       if it never completes the gui is still responsive
19:29 sapier1       celeron you can't code your internet connection
19:30 kahrl         httpfetch solves that problem
19:30 celeron55     of course a network operation should be done asynchronously
19:30 sapier1       no it doesnÄ't
19:30 kahrl         sapier1: why not?
19:30 sapier1       what will the downloaded serverlist be good for?
19:30 sapier1       we don't have a json parser in lua
19:31 kahrl         you can make httpfetch_async calls in cpp too
19:31 sapier1       and how to pass back the result to lua?
19:31 kahrl         call a callback?
19:31 sapier1       not an option for mainmenu
19:31 celeron55     also why not download the server list in lua and just call a C++ function to parse it
19:32 kahrl         celeron55: or that
19:32 sapier1       is another way to do it but this way you need to rewrite everything
19:32 sapier1       we already had code to download as well as parse
19:32 kahrl         it's really strange to me that a file called convert_json.cpp contains HTTP fetching code right now
19:32 celeron55     everything?
19:32 celeron55     not likely
19:33 sapier1       names ...
19:33 sapier1       of course we have code that downloads a and parses in json
19:34 kahrl         I think it's unneeded coupling
19:34 kahrl         what if you want to download something that is not json?
19:34 sapier1       maybe but the way you suggest you need a generic json -> lua converter
19:34 sapier1       of course this is by far best solution
19:34 kahrl         doesn't sound hard
19:35 sapier1       no but in doing so you move error checking to lua too
19:35 kahrl         sure, why not?
19:35 sapier1       imho errors should be recognized as soon as possible
19:36 kahrl         then you'd have to write a json parser yourself and abort as soon as you see an unknown key ;)
19:36 celeron55     here's a pure lua json parser in 375 lines: http://hg.prosody.im/trunk/file/tip/util/json.lua
19:36 celeron55     8)
19:36 sapier1       first converting a maybe 1mb json table to lua just to realize it's a modstore list instead of a favourites list seems wrong to me
19:36 celeron55     (and encoder)
19:36 celeron55     (and a test for them)
19:36 kahrl         sapier1: unlikely to happen, so doesn't seem like a big problem
19:37 sapier1       sorry why do we still want to move code that obviously isn't fast if you don't have jit
19:37 sapier1       it's unlikely to happen to not have an internet connection too still it seems to be a problem for some ppl
19:37 celeron55     (anyway making C code for converting json to lua would probably be best)
19:38 PilzAdam      if you dont have one its not a problem, the problem is if its slow
19:38 celeron55     it's largely completely trivial
19:38 sapier1       it's a parser ... as long as no errors occur it's trivial catching all error cases isn't trivial
19:38 sapier1       and still the callback issue remains
19:39 kahrl         engine.async_handler?
19:39 sapier1       kahrl's http threads are just another threading system limited to download
19:40 sapier1       where to trigger?
19:40 sapier1       you can't trigger this from the executed thread
19:40 kahrl         check httpfetch_async_get in guiEngine's main loop
19:40 sapier1       add it
19:41 sapier1       and if you're already doing so plz add id's to issue multiple parallel downloads
19:41 kahrl         of course parallel downloads will be supported
19:42 sapier1       btw celeron55 fast code is worth nothing ... I just removed pathfinding from mobf because of even A* is way to slow
19:42 sapier1       the only way to use it would be asyncronous to not interfere with server main loop
19:43 kahrl         sapier1, use an incremental variant of A*?
19:44 sapier1       doesn't help A* may be used for 5 or 50 mobs in same server step no way to predict
19:44 Tesseract     IMO Lua should have access to JSON. Something like minetest.http_get("<serverlist url>", function(result) menu.serverlist = minetest.parse_json(result) end)
19:44 kahrl         A* is slow when no path exists, which can be the case very often
19:45 sapier1       exactly and risk of no path to exist increases drasticaly the more mobs try to find a path
19:46 sapier1       thus the only sane way to use A* would be use as much cpu power as not used by more important tasks
19:46 sapier1       but that can't be done right now
19:46 kahrl         perhaps maintain a list of connected components
19:47 kahrl         and immediately return that the path doesn't exist if the endpoints are in different components
19:47 sapier1       what do you mean with components?
19:47 kahrl         sets of connected nodes
19:47 sapier1       that compinent list needs to be updated on any map change
19:47 kahrl         of course
19:48 sapier1       so you add more ram usage and shift cpu power to building ;-)
19:48 kahrl         and updated on loading and unloading of mapblocks too
19:48 sapier1       possible ... maybe even a setup exists where this works ... but infrastructure for keeping that information is a lot of work
19:49 kahrl         of course it would need to optional, no need to calculate all that without some mobs
19:49 kahrl         to be*
19:49 sapier1       for now benefit of pathfinding movement to more simple movement isn't that big it'd be worth it
19:50 kahrl         yeah, makes sense to get the basic system working and performant first before working on this
19:50 sapier1       there are some cases where pathfindig results in more smart mobs but most time difference is hardly noticable
19:50 kahrl         e.g. the entity duplication issues
19:51 sapier1       one situation is e.g. if you dig  a U  and place a mob inside  ... without pathfinding it'll never realize to move back to get to the other side
19:52 kahrl         you could make A* limited so that it only tries a very limited amount of non-straight paths
19:52 kahrl         should have good performance while doing the pathfinding job in simple cases like the U
19:53 sapier1       not exactly
19:53 sapier1       A* is no wonderweapon it's only as good as your heuristic fits your situation
19:53 sapier1       if you optimize it for U it may terribly fail for L for example ;-)
19:54 sapier1       the current A* algorithm uses most common manhattan distance heuristic
19:56 sapier1       something different kahrl what do you think about  774 640 and 418?
19:57 kahrl         haven't thought about them
19:58 sapier1       plz think about them ;-) need them or something different for improving mobs
20:00 kahrl         well for #774 I don't know a bit about model animation
20:02 kahrl         wait why XZScalar and not hypot?
20:02 sapier1       ok but the other ones?
20:03 kahrl         what did you mean by "if you really want to add this you need a completely different system"?
20:04 sapier1       movement has 3 directions ... simplified this could be mapped to 2
20:05 sapier1       still if you'd specified 2 different orientations you'd need 2 animations beeing played at same time
20:05 sapier1       and y movement animations aren't used anywhere by now
20:06 sapier1       so 1) not used for anything and noone has any common usecase
20:06 sapier1       2) way more complex
20:06 sapier1       3) no support for multiple animations at a single model at same time
20:06 kahrl         can't you just take the norm of m_velocity in updateAnimationSpeed()?
20:07 sapier1       yes but what should this be usefull? a mob for example dropping straigt down will run like hekk
20:07 sapier1       -ll
20:07 kahrl         PA's example of a bird
20:08 sapier1       do you now of any bird moving up in a staight line?
20:08 PilzAdam      yes, Kolibri can AFAIK
20:08 PilzAdam      "hummingbird" in english
20:08 sapier1       ok pilzadam implement it in simplemobs and add the feature when needed ;-P
20:08 kahrl         well, we're also not trying to be 100% realistic
20:09 PilzAdam      just thinking about mobs here is too restrictive
20:09 sapier1       so what do you prefere using y too resulting in constant animation failures in most common drop case
20:09 kahrl         but I guess if the need arises support for using the norm of the whole vector can be added later
20:09 sapier1       or a small (most likely unnoticable error) for not even implemented kolibris
20:10 kahrl         well, of course it would just use X and Z unless Y is specifically enabled
20:10 PilzAdam      a new parameter
20:10 sapier1       if you want an additional parameter this can be added later thus is no reason to NOT add this one
20:11 kahrl         the most generic way would probably to define a matrix A and use sqrt(x' * A * x)
20:11 sapier1       there's always a thing to make even better I'm anoyed to be asked for features nobody uses just to have an excuse to not add my commits
20:12 kahrl         as I said I don't know about animations so I wouldn't be the one to OK your commit anyway
20:13 sapier1       I don't deny y movement would be fine too but it's of very limited use and at least for me it's not worth the effort ... it can be added afterwards if someone really needs it
20:18 PilzAdam      I dont like this "design by request"
20:18 kahrl         typo in 640: serachup
20:18 PilzAdam      we should think ahead
20:19 kahrl         and methods of ServerEnvironment should be called getSurface, not get_surface
20:19 kahrl         should it be a method of ServerEnvironment anyway?
20:19 kahrl         not ServerMap or Map?
20:22 kahrl         there are quite similar methods ServerEnvironment::line_of_sight, ClientMap::isOccluded, ServerEnvironment::get_surface, wonder if they can be merged into a single one
20:23 sapier1       no they're completely different
20:23 sapier1       line of sight just tells true/false get_surface tells position of surfacde
20:23 sapier1       isOccluded could be similar to line of sight yes
20:25 kahrl         line_of_sight and isOccluded could return the occlusion position as well
20:25 kahrl         if there is no such position -> not occluded
20:25 kahrl         of course they check different nodedef members than get_surface
20:26 sapier1       true you'd need to specify what to look for too
20:26 kahrl         perhaps a pointer-to-member of ContentFeatures
20:26 kahrl         that might get weird though
20:27 sapier1       don't know
20:30 kahrl         or simply a bool (*)(const ContentFeatures&)
20:32 kahrl         anyway, about the cleanup thing
20:32 kahrl         why did you want to completely separate the two lua APIs?
20:34 sapier1       primary intention was to not interfere with modapi and of course modapi was built in a way that reuse of core components wasn't possible
20:35 sapier1       but as you changed scriptapi back to close linkage to modding modules this issue is gone
20:36 kahrl         what do you mean by close linkage?
20:36 kahrl         the decision what modules go into each modding api is still in script/lua_api/
20:36 kahrl         script/lua_api/luaapi.cpp to be precise
20:37 sapier1       exactly original code wasn't intended to have a single code location that needs to now what to initialize
20:37 sapier1       the for loop you removed
20:38 sapier1       the way you do it it isn't even necessary to derive the classes they're derived right now
20:38 kahrl         yeah, but that makes it hard to define multiple different modding APIs
20:38 kahrl         e.g. what if you want to add a client side modding API
20:38 sapier1       yes that wasn't a design goal for scriptapi noone thought about making main menu lua that time
20:38 sapier1       client side modding api needs to be completely different
20:39 kahrl         not completely; it could easily reuse some parts from l_util.cpp
20:39 sapier1       it'd be absolutely insane to add a lua engine beeing that powerfull executing code sent by server
20:39 kahrl         (remove the settings part, maybe)
20:39 sapier1       no no no
20:39 sapier1       remove anything with file system access too
20:40 kahrl         I never said to leave those in...
20:40 sapier1       remove debug features process launching ...
20:40 sapier1       serialization needs to be redone too
20:41 sapier1       there's a lot of work to be done for clientside and I don't believe it's safe to start with an insecure engine trying to harden it
20:41 sapier1       at least I will not take that risk
20:42 sapier1       for mainmenu and modapi this seems more reasonable but you should rethink the deived things too I guess not everything is usefull if doing it this way
20:43 kahrl         yeah, I'm not happy about how ScriptApi is derived from everything
20:43 kahrl         what would you suggest?
20:43 sapier1       make it c again ... you already dropped the main intention so no need to keep the other relicts
20:44 kahrl         ummm
20:44 sapier1       main intention == hide what script language is behind it from minetest core
20:44 kahrl         I thought the main intention was to not have a huge single cpp with everything
20:44 sapier1       as mainmenu is integral part of core this isn't possible if you merge it by definition
20:44 kahrl         and you can't do that now? all the lua calls are in script/ now
20:45 kahrl         in fact it's more possible now than before, as the lua calls from guiEngine.cpp and guiLuaApi.cpp are in script/ now
20:45 sapier1       you can't hide it from scripts but engine doesn't know anything about lua
20:45 sapier1       no it isn't
20:46 sapier1       you could've replaced lua by e.g. python without touching mainmenu before
20:46 kahrl         but I think it's highly unlikely that we'll switch any time soon so that's an academic discussion
20:46 sapier1       now you need to replace both ... I know both isn't very likely
20:46 kahrl         (there's so much lua around by now)
20:46 sapier1       most discussions within minetest are academic ;-)
20:47 sapier1       remember y ... wich noone uses or intends to use
20:48 sapier1       as I said the way the classes are derived is based on the intention to separate modapi completely from core if this isn't possible anymore it should be redone too
20:48 sapier1       if not doing so you stop at half way to cleanup
20:49 kahrl         I still don't get what you mean by "separate modapi completely from core"
20:49 sapier1       but I'm not sure what code really is reused? error handlers? settings ? some init things ? thats all is there more?
20:50 kahrl         how are Register lines scattered throughout script/lua_api different from one luaapi_init_game function?
20:50 sapier1       my intention was to make moding a completely separated part with defined interface
20:50 sapier1       the luaapi_init_game needs to know what to initialize
20:51 sapier1       that wasn't necessary before
20:51 kahrl         tbh I find it cleaner than the macro hacks
20:51 sapier1       the macro things are only formal
20:52 sapier1       I added a shell around scriptapi to separate it and ease maintenance
20:52 kahrl         also the only thing that calls luaapi_init_game is ScriptApi
20:52 sapier1       of course it's benefits would've been visilble in some months/years not right niw
20:53 kahrl         are you saying someone might want to replace everything in script/lua_api but not make a small change in ScriptApi?
20:53 sapier1       I don't say your way of doing it is bad ... it's just completely opposit direction
20:54 sapier1       while I tried to encapsulate and isolate the scriptapi you reintegrated it to core
20:54 kahrl         I still don't understand what that means, but I think I never will
20:55 sapier1       ok have a look at one of our main problems in minetest,
20:55 sapier1       changeing one thing here may result in breakage there
20:55 kahrl         _no one_ except files in script/ even includes any header from script/lua_api
20:55 kahrl         and they already do so for other reasons, e.g. s_item.cpp includes l_item.h
20:56 sapier1       kahrl I don't say it's a big difference it's a rather small one but the effect in long term is completely different
20:57 sapier1       yes they do so for other imho wrong reasons ;-)
20:58 sapier1       mainmenu and modapi don't have much in common except of beeing both lua and using both settings
20:59 sapier1       maybe there'd even be a way to make scriptengine even more generic making mainmenu and scriptapi a derived object of that engine
20:59 kahrl         even with the old code you could make a small change, e.g. call fs::RecursiveDeleteContent("..") in l_debug() ;)
20:59 kahrl         just saying that almost no system has full isolation
21:00 sapier1       I never told any of the lua apis to be safe ... my security fixes have been rejected months ago
21:00 sapier1       I will not try to add any of them again as It's wasted time
21:01 kahrl         the reason I started doing this is that I wanted to add some utility functions to both APIs
21:01 sapier1       but I will stop using minetest for sure if client side lua is done that stuporous way (in tems of security) the modapi has been done
21:01 kahrl         urlencode and urldecode in this case
21:02 kahrl         and I saw that I had to repeat that code
21:02 sapier1       what's urlencode worth if cou can call "os.execute("rm /etc/*")
21:02 kahrl         and other things, e.g. for some reason the mainmenu has setting_setbool but the game API doesn't
21:02 kahrl         what does that have to do with anything
21:03 sapier1       as I said maybe the component design could be used to merge both code reuse as well as isolation
21:04 sfan5         what is so bad about mods not being totally isolated?
21:05 sapier1       less code coupling --> less sideeffects --> less effort to find bugs
21:05 sapier1       of course removing a single code coupling wont make it good at once
21:06 sapier1       but with one thing kahrl is right the scriptapi design is bad for component reuse in different engines
21:06 kahrl         I think I already removed some code coupling, master has 6305 total included files whereas omnicleanup has 5131 ;)
21:07 kahrl         counted by my trusted depgraph.py
21:07 sapier1       what did you remove?
21:07 kahrl         lots of includes from header files
21:07 kahrl         moved some stuff around, changed includes to forward declarations (if needed at all)
21:07 sapier1       good ... still Imho those init functions aren't the right direction
21:08 sapier1       but of course they're the most obvious way of doing it
21:08 kahrl         it's also easy to understand so anyone who wants to add a new module should be able to
21:09 kahrl         not that it was hard with your system, but the macros weren't really documented
21:09 sapier1       it doesn't feel right to have one class beeing a mainmenu or a modapi dependent on what you compile ;-)
21:09 kahrl         yeah, that thing I don't like too much
21:10 sapier1       I'm not very good in documentation yes
21:10 kahrl         says the only one who doxygens his headers :P
21:10 sapier1       and the macros have been there to reduce code size ;-P
21:11 sapier1       you told me not to doxygenify in mintest so I didn't even try to
21:11 sapier1       I'm very bad in deciding what is obvious and what needs explanation so either I document everything or wrong thing
21:11 kahrl         eh, it doesn't hurt to do it if you write whole new subsystems etc.
21:12 kahrl         but don't make a huge effort to add it to code that doesn't need it
21:12 sapier1       that's what I said I'm not good in deciding what needs it and what nor ;-P
21:13 sapier1       imho best way would be a base class engine that can be derived to mainmenu / modapi / clientapi
21:13 sapier1       sad thing is that class would even require lua lib features to be configurable to be usefull for clientapi
21:14 kahrl         sounds like a plan; what would ModApiBase::getScriptApi() return?
21:14 sapier1       I suggest this shall return a engine pointer
21:14 sapier1       but wait do we have dynamic casts available?
21:15 sapier1       if not the engine pointer can't be used
21:15 kahrl         as long as it's just used for our own classes, we do
21:15 kahrl         (it's not available for irrlicht classes, for example)
21:15 kahrl         what would be the performance impact of a dynamic_cast on every lua api call?
21:16 sapier1       of course but I don't think it'd be a major one
21:16 sapier1       lua calls aren't high frequency calls
21:16 kahrl         really?
21:16 sapier1       really
21:17 sapier1       high frequenc == x per ns
21:17 sapier1       I assume lua is in x per ms area ... but that's a guess
21:18 kahrl         maybe there should be classes above ModApiBase
21:18 kahrl         one for in-game APIs and one for mainmenu APIs
21:18 kahrl         they could return the specialized ScriptApi
21:18 sapier1       not sure
21:18 kahrl         s/classes above/subclasses of
21:19 sapier1       problem with current design is that a component is registred on constructor
21:19 kahrl         not with omnicleanup
21:19 sapier1       yes  but there you have close coupling between component and main class
21:20 sapier1       so either increase couling level as you do in omnicleanuo
21:20 sapier1       or replace by some component registry ... later one sounds like overkill at first glance
21:20 kahrl         it does
21:21 sapier1       hmm actually that registry does already exist
21:21 sapier1       if an id was added when a component registers
21:22 sapier1       initialization could be done by id
21:22 sapier1       reducing coupling from header to configuration coupling ... not  a big difference
21:25 sapier1       but discussion doesn't make any sense as I wont do it myself this time it's up to you to find a reasonable way to do it
21:25 kahrl         making each component know in which modding APIs it is used is also a kind of coupling
21:26 kahrl         (if I'm getting right what you're saying)
21:26 sapier1       not the component
21:27 sapier1       [new top class] --> derived from --> [current class components registred to]
21:27 sapier1       later one is extended by a call init_component(L,"someid")
21:28 sapier1       but as I said this is just a minor decoupling as the new class needs to know at least the ids
21:28 sapier1       another question why did you remove the return value from API_FCT?
21:28 kahrl         registerFunction never returns failure
21:29 sapier1       and why not fix that?
21:29 kahrl         it's not a problem to assert and abort the program if that fails
21:29 kahrl         imo
21:30 kahrl         or throw a LuaError or something if you want to be fancy and handle the error
21:30 sapier1       if someone extends registerFunction by duplicate check returning false in this case for exaple?
21:31 sapier1       that's the //TODO check presence first!
21:31 kahrl         ah, I wondered what that was about
21:32 sapier1       yea I intended to return false in that case
21:32 sapier1       obviously I forgot to add
21:32 kahrl         adding a duplicate there is really a programming error so an assert is fine
21:32 sapier1       it's not an hard error
21:33 kahrl         it is, somebody made a mistake that should be fixed immediately
21:33 sapier1       you can still continue most of time with a single api call missing
21:33 kahrl         well that's what it does currently
21:34 sapier1       imho assert is only legit if continuing most likely will cause damage to anything
21:34 sapier1       in this case most likely nothing bad will happen
21:35 kahrl         if you want to continue, what is the return value for?
21:35 kahrl         just log to e.g. errorstream
21:35 sapier1       registerFunction is a base function not knowing if this situation is a problem or not the caller knows
21:36 sapier1       maybe there's even a parameter missing overwrite
21:38 kahrl         I don't foresee such a situation coming up
21:38 sapier1       security
21:38 kahrl         ?
21:38 sapier1       overwrite builtin fct
21:39 kahrl         API_FCT isn't meant for such anyway
21:39 kahrl         stuff like that should be done by hand
21:39 sapier1       no it shouldn't
21:39 sapier1       you want to reuse code
21:40 sapier1       i will for sure not fetch 20 function names from lua set it push it back
21:40 sapier1       :-)
21:40 kahrl         adding full security would mean major changes anyway
21:40 sapier1       no it wouldn't
21:40 kahrl         it's not like registerFunction couldn't be changed
21:41 sapier1       no it wouldn't the design is already prepared for security ... main changes would be on mod side
21:41 kahrl         you said it was rejected
21:42 sapier1       yes it was but I don't add designs that are bad
21:42 kahrl         so what's the point?
21:42 sapier1       the features aren't included but they'd be easy to implement if for some reason ppl get sane
21:43 kahrl         that precondition will never be satisfied
21:43 sapier1       that's not the point ... you see at current api what happens if you design to current usecase
21:44 sapier1       it perfectly matched single lua case ... but was proofen wrong when mainmenu was switched to lua too
21:45 sapier1       hmm I hate the guy doing that ;-)
21:46 kahrl         you don't think you can refactor stuff if it doesn't satisfy the current use case anymore?
21:46 sapier1       you can refactor twice a week but noone is willing to relearn code structure that often
21:48 kahrl         I don't have a problem with doing that, maybe others do
21:48 sapier1       but I guess we wont get to a common point the difference between the two aproaches is just to small to give a clean result ... I prefere the decoupled way you the more c style way both have benenfits
21:49 kahrl         most of the time you don't even need to understand 100% of the (refactored) codebase to do something productive
21:49 sapier1       that's visible everywhere in minetest code .... /ironic
21:50 sapier1       that's why we're looking for the duplication glitch for months now
21:50 sapier1       noone really understands what happens
21:50 kahrl         but that code didn't even change once ;)
21:51 kahrl         maybe except for the 49 -> configurable limit
21:51 sapier1       I guess it will be gone once you remove my disappear fix ... replacing one performance killer bug by an annoying one ... still the real problem most likely isn't my fix but only triggered by it
22:06 kahrl         does anyone else have an opinion on these issues?
22:06 kahrl         e.g. about how to register modding API modules
22:49 iqualfragile_ pitriss|idle: thanks for telling us that you are now ideling, what a incredibly relevant information
23:12 Tesseract     pitriss|idle: http://kylej.name/irc-away-status.html
23:19 PilzAdam      ... another one