Time  Nick         Message
09:10 sfan5        i sometimes hate git
09:11 VanessaE     why now?
09:12 sfan5        i did "git add ." but i was in the build directory
09:12 VanessaE     oops
09:13 sfan5        it wants to commit total junk, using "git reset --hard HEAD^" i would lose my build dir, "git reset --soft HEAD^" just resets the commit, it keeps the ile in the commit quene
09:13 sfan5        *files
09:16 sfan5        does this look useful? https://github.com/sfan5/minetest/commit/72283d6f7493869a766c472bd9f666a54b76bf4b
10:24 kahrl        sfan5: that's the server's locale, in a mod you're probably more interested in the clients' locales
10:28 sfan5        oh, right didn't notice that one
10:35 sfan5        the client links, for the server it outputs a bunch of:
10:35 sfan5        CMakeFiles/minetestserver.dir/objects.a(main.cpp.obj):main.cpp:(.text+0x309f): undefined reference to `__imp__libintl_gettext'
10:37 sfan5        seems to be related to: https://github.com/celeron55/minetest/pull/458
13:10 thexyz       https://github.com/celeron55/minetest/pull/344
14:09 celeron55    there should be no way for a mod to get the locale of the server
14:09 celeron55    it's completely irrelevant
14:10 celeron55    localization of mods should work so that to strings that are sent to the client, a mod can, instead of a string, put a table like {en="foo", de="bar"}
14:11 celeron55    and then the engine will do things in some way that results in the right stuff showing up on clients
14:12 celeron55    either sends the full content of the table or knows the locale of each client
14:13 celeron55    that is the only way i can see actually working; anything else is likely just dumb
14:13 sfan5        ok, i closed the pull
14:14 celeron55    then if somebody wishes to create some kind of a gettext-like thing, it's easy to implement completely in lua (instead of the table, use something like thegettextything("english text")
14:15 sfan5        idea: mod can get locale of each client
14:15 celeron55    if somebody has a better overall idea, i'm ready to judge it 8)
14:16 sfan5        a gettext-thingy uses that to change the string accordingly
14:16 sfan5        </idea>
14:17 celeron55    won't work, because there are many situations when a mod must generate a text that will be sent to everyone
14:17 thexyz       sfan5: that won't work with initial node definition, for example
14:17 celeron55    and remaking those so that a mod controls what ends up to each client is likely not a good idea
14:17 sfan5        hook into minetest.send_chat_message, iterate over players and send in individual language
14:18 thexyz       inb4 c55 rage
14:18 celeron55    ...yeah, chat works, but how about all the 100000 other places?
14:18 sfan5        hook into minetest.register_node?
14:18 thexyz       too hacky
14:18 sfan5        but doable in lua
14:19 sfan5        *do-able
14:19 * celeron55  shakes his head and goes away
14:19 thexyz       it won't work anyway
14:19 thexyz       ok, fine
14:19 thexyz       I guess my freetype thing is ok them
15:16 PilzAdam     thexyz, https://github.com/celeron55/minetest/pull/470
15:18 thexyz       why've you altered treegen.h to include environment.h without changing anything else in treegen.h/cpp?
15:19 PilzAdam     because there were some errors while compiling
15:19 RealBadAngel i havent noticed any, what was those errors?
15:21 PilzAdam     it works if I include it in mapgen_flat.cpp, but I dont need it there
15:21 PilzAdam     RealBadAngel, basically ServerEnvironment not defined
15:22 RealBadAngel no such errors here
15:23 PilzAdam     it works if you include environment.h before treegen.h
15:23 PilzAdam     (wich is the case in the other mapgen files)
15:25 PilzAdam     I thought adding it to treegen.h makes more sence, so not every other file has to include environment.h when including treegen.h
15:27 RealBadAngel as far as i remember c55 said somethin about including long files and being careful bout it
15:27 RealBadAngel i may have it included before but decided not to
15:28 RealBadAngel at least im sure i removed some headers
15:29 celeron55    eh
15:29 celeron55    just put class Environment; in there
15:29 celeron55    or whatever it is
15:29 celeron55    including headers in headers shouldn't be done when not necessary
15:32 PilzAdam     fixed.
15:35 PilzAdam     hmmmm, https://github.com/celeron55/minetest/pull/470
15:36 hmmmm        hrmm i don't know if we actually want to do that
15:36 hmmmm        we can already get a map that's flat enough by setting both offset and height to 0 for v6 and disabling caves
15:37 hmmmm        (note that because steepness is bounded by 1.5 in the ground level code, that will never be 0)
15:38 PilzAdam     well, its easier to add mg_name = flat than doing all the other stuff in v6
15:38 hmmmm        not if it's well documented
15:38 PilzAdam     and also in flat mapgen there are no deserts etc,
15:38 hmmmm        my way would require 2 lines in minetest.conf and eliminate all code
15:38 hmmmm        that would needed to be added
15:39 PilzAdam     if we have GUI config its a lot easier to select flat
15:41 hmmmm        oh, i'm sorry
15:41 hmmmm        b is limited to 0.5 at the lowest
15:42 hmmmm        a = 0.5 + 0.5 * (-.2 + noise_height_select), we can't eliminate the variance in noise_height_select either
15:42 hmmmm        because the offset/scale is not applied
15:43 hmmmm        alright, PlizAdam, if you want to add flat mapgen the right way, here's what you do...
15:44 hmmmm        after noise_height_select->perlinMap2D(); in makeChunk, add noise_height_select->transformNoiseMap();
15:45 hmmmm        now on line 43, for some reason, i have 0.5 as the offset, but it didn't matter before because it was ignored.  change the first number in that definition from 0.5 to 0.0
15:45 hmmmm        and finally on line 358, change that call from NoisePerlin2DNoTxfmPosOffset to NoisePerlin2DPosOffset
15:46 RealBadAngel celeron55, that stuff showin me tabs and spaces is indeed quite usable. im cleanin now Technic mod out of lots invisible stuff...
15:46 hmmmm        one more thing actually, in defaultsettings.cpp now on line 183, change the 0.5 in the first field there to 0.0 too
15:47 hmmmm        sorry PlizAdam, I know you probably wanted to add in more code, but our goal is to minimize the amount of redundant stuff added
15:48 PilzAdam     it is Pilz not Pliz
15:48 PilzAdam     :-)
15:50 darkrose     it's p<tab>
16:02 PilzAdam     hmmmm, there is still one thing: my flat mapgen is a lot faster than the modified v6
16:03 hmmmm        in terms of amount of code executed, sure.  but it's not noticable
16:03 hmmmm        the majority of the cpu time is taken up by the lighting update
16:37 VanessaE     hmmmm:  maybe it isn't noticable, but remember that every cycle you save on something that can be optimized is a cycle you can put toward something else, perhaps that cannot be optimized further.
16:37 VanessaE     (not that a flat mapgen is in particularly high demand)
17:01 hmmmm        vanessa, about the whole emergethread freezing up thing, you do realize you're primarily having that problem because of the large amount of mods, right?
17:02 hmmmm        they are 1). poorly coded  2). extremely slow to execute thanks to lua  3). emergethread cannot run while the code in a mod is being run
17:02 VanessaE     I would have thought so, until I noticed it happening even in singleplayer with just one mod (moretrees) running.
17:03 VanessaE     (and as you know, that mod is *very* fast)
17:03 VanessaE     even worldedit is enough to kill the emergethread.
17:03 hmmmm        it's a problem that the majority of people don't have though
17:03 VanessaE     no other mods but that - just copy 100-200 thousand nodes from one place to another.  Emergethread will choke.
17:03 hmmmm        100-200 nodes being copied? well, duh
17:04 hmmmm        what did you honestly expect
17:04 VanessaE     wait wait..
17:04 VanessaE     I don't mean the Lua part - I mean the server 'catching up' after the copy is finished,.
17:04 hmmmm        yeah
17:04 hmmmm        that's normal
17:04 VanessaE     after 5 minutes?
17:04 hmmmm        what worldedit uses to accomplish its goal is extremely, EXTREMELY unsuitable
17:05 VanessaE     true, but I suppose that's the best that can be done at present
17:06 RealBadAngel there was engine patch that speeded up emerge thread partially
17:06 VanessaE     but point is, the more content the map has, the easier it is to make emergethread choke -- even with no mods installed at all.  even the unknown blocks leftover after removing moretrees on a well-populated map sometimes chokes it.
17:06 hmmmm        i'm gonna have to say, basically everything in minetest, especially before I started working on it, is as inefficient as possible
17:06 RealBadAngel but it was mentioned there theres lotsa more to do about it
17:06 hmmmm        it was coded so that it runs, but it runs like shit
17:07 hmmmm        things that used to make me cringe before i started looking at this code were ubquitous
17:08 hmmmm        it's like gore
17:08 hmmmm        worldedit was one of those things.
17:08 VanessaE     heh
17:08 VanessaE     well like I said, even without any mods loaded at all.
17:09 VanessaE     try this:
17:09 hmmmm        you know i used to wonder how it was possible, on modern processors, for things to be slow
17:09 hmmmm        now i know exactly what's needed
17:10 VanessaE     Delete all mods.  Install worldedit.  Make a fresh map.  Copy say 100x100x100 from anywhere to anywhere else.  Time how long it takes to get from the Enter key to "xxxxxx nodes copied".  Now time how long it takes from that moment until the map has redrawn to match the result of the copy.  Now shut down, remove worldedit, restart.  The map will still load slowly around the copied area.
17:11 VanessaE     it's the update step after worldedit has finished copying, and the subsequent reload of the map after a restart where the unexpectedly slow response is.
17:12 VanessaE     100k nodes should be nearly instantaneous to reload.  That's only, what, a meg or two of map data?
17:12 VanessaE     (well that 100^3 is a million, but you get the point)
17:13 hmmmm        but 'slowly' is subjective, and i personally expect things to be slow
17:13 hmmmm        100^3 nodes is a lot though for lua
17:13 VanessaE     nononono
17:13 VanessaE     you're missing my point.
17:14 hmmmm        after shutting down and letting it reload though
17:14 VanessaE     yeah
17:14 hmmmm        it has to reload everything else too
17:14 hmmmm        all the other blocks
17:14 hmmmm        there are a whole lot of them
17:14 VanessaE     fresh map....
17:14 hmmmm        doesn't matter
17:14 VanessaE     hrm
17:14 hmmmm        what you say is slow is actually perfectly normal
17:16 VanessaE     taking 5 minutes to reload less than a million nodes after a copy is *not* normal.....
17:16 RealBadAngel https://github.com/celeron55/minetest/pull/432
17:16 VanessaE     especially on a system with a good SSD and a hell of a fast video card
17:16 hmmmm        both irrelevant to block loading
17:16 RealBadAngel when it is normal, why this code speeds up emerge thread?
17:17 VanessaE     hmmmm: a fast disk from which to load the map is not relevant?  *confused*
17:18 hmmmm        it takes hardly any time at all to load the blocks from the disk
17:18 hmmmm        the problem is that all the other stuff is so CPU intensive
17:18 VanessaE     other stuff such as the lighting update?
17:18 hmmmm        you might be fooled into thinking that a good computer can play minetest well.. you'd be wrong
17:18 hmmmm        yes, for one
17:18 VanessaE     I see.
17:18 hmmmm        basically EVERYTHING takes at the very least 40ms to completely emerge a block
17:19 hmmmm        now multiply that by the number of blocks actually being loaded
17:19 VanessaE     that's horrible.
17:19 hmmmm        you can understand why things are slow now, can't you
17:19 VanessaE     mmhmm
17:19 hmmmm        man i want to nuke minetest sometimes and start all over from scratch and do everything right
17:19 VanessaE     I remember your commentary the other day about 40 vs 400 or something, emergethread just sitting there with its virtual thumb up its ass waiting :-)
17:20 hmmmm        but can't do that
17:22 VanessaE     well regarding efficiency in Lua, at least that can be taken care of with LuaJIT is put into use.
17:22 VanessaE     to a degree anyway
17:22 hmmmm        it's not a silver bullet
17:22 VanessaE     I know.
17:22 VanessaE     but executing CPU-specific machine code has to be faster than interpreting p-code ;)
17:23 VanessaE     (at least, it used to be in the old days)
17:23 hmmmm        there's still a lot of effort that should be put into making lua code fast
17:23 VanessaE     indeed
17:23 VanessaE     more API hooks to handle stuff that's always gonna be slow in Lua
17:23 hmmmm        you see, this really sucks.. if it were up to me, i'd leave lua completely out, because it opens the door wide for bottom-of-the-barrel scripters
17:23 VanessaE     (such as the aforementioned copy operation)
17:24 hmmmm        and they're going to write some really bad, slow code
17:24 hmmmm        in addition to an infrastructure that's already slow
17:24 hmmmm        and more slow code in the engine that has to wait for super-slow code in lua to finish
17:25 VanessaE     yeah
17:25 hmmmm        and here i am with an e3-1230v2, practically the king of CPUs, i can shred absolutely everything else, and here minetest is being completely choppy for no discernable reason
17:26 VanessaE     same here.
17:26 VanessaE     my Phenom 1055T may not be top of the line, but it isn't exactly a 6502 either.
17:27 hmmmm        but the worst part is that everything is so difficult to optimize because there's so much of it piled on top of eachother
17:27 hmmmm        so much more work
17:37 PilzAdam     thexyz, add src/cguittfont/* to .gitignore in ttf branch
17:48 thexyz       PilzAdam: why?
17:49 PilzAdam     because jthread, lua etc. are there too
17:49 thexyz       nope
17:51 PilzAdam     oh, well, then add the build files of it
17:54 PilzAdam     thexyz, also: the win build is broken; it compile correctly (with -DENABLE_FREETYPE=0), but when running the .exe it crashes
17:55 thexyz       hm..
17:55 PilzAdam     terminate called after throwing an instance of 'std::runtime_error'
17:55 PilzAdam     what():  locale::facet::_S_create_c_locale name not valid
18:01 thexyz       do you compile it with gettext enabled?
18:01 PilzAdam     yep
18:03 thexyz       does it reproduce with gettext disabled?
18:06 PilzAdam     yep
18:08 thexyz       ok, i'll look into it
18:08 thexyz       later
18:08 thexyz       some day
18:21 celeron55    hmm so i hear the block loading crap is because of mods using all of the main server thread time with the environment locked?
18:21 celeron55    sounds plausible
18:22 celeron55    a simple workaround to keep everyone a bit happier and more knowledgeable would be to automatically measure it and drop some env steps if needed, and track those somewhere where they can be observed
18:23 celeron55    so people can learn how usual a problem it is
18:24 celeron55    as hmmmm said, it's inevitable that random mods are going to eat all CPU because of inexperienced coders try to do much things in a slow language
18:24 celeron55    there isn't really any direct solution to it other than not having sucky mods 8)
18:25 celeron55    or not having so many of them
18:26 Exio         i still think having small functions like the generate ore and things are something what should be done in "raw C++" without lua
18:26 celeron55    of course
18:27 hmmmm        putting the ore generation back in C++ would shave 90ms off of block generation time (for me; probably more for other people)
18:27 celeron55    it's how one is supposed to use an embedded scripting language
18:27 Exio         hmmmm: in what cpu?
18:27 hmmmm        e3-1230v2
18:27 Exio         in this netbook (yes, i know) the ore generation takes... a bit
18:28 celeron55    there isn't really any reason why it is in Lua other than me now wanting to implement stuff in C++ because it seemed like the mapgen is going to get a lot of rework in the future
18:28 celeron55    but that ended up taking a full year before happening 8)
18:28 celeron55    s/now/not/g
18:28 celeron55    -g
18:29 hmmmm        on_generate is here to stay though.  the only plausible way to fix that is to add LuaJIT, and the VoxelManipulator interface
18:30 Exio         VoxelManipulator?
18:30 hmmmm        it would probably be nice if we did the envlock in l_set_node() and what not.
18:32 celeron55    it would be needed practically in every lua function whatsoever, (and also that will force the connection lock to be done so too)
18:32 PilzAdam     thexyz, the same error happens with ENABLE_FREETYPE=1
18:32 hmmmm        that's fine, look at the alternative
18:33 celeron55    i'm not saying it's not a good idea 8)
18:34 celeron55    there is an overhead in mutexes too though
18:35 celeron55    in one very early version of minetest, i tried locking the equivalent of some kind of an environment mutex on a basis of node accesses
18:35 celeron55    all i can say about that is nope
18:35 hmmmm        it'd probably be a lot more on a server with many clients, but i noticed that the locks get acquired immediately, in 30ms, or 400ms
18:36 hmmmm        my response to that is... with VoxelManipulator in place, when would you ever need to do a tight loop to set blocks within Lua
18:36 celeron55    sounds like how it probably goes (400ms being some on_generate delay and 30ms being an environment step)
18:38 celeron55    by the way, the lua voxelmanipulator thing probably needs to be implemented so that it can be used (in addition to some other way) so that you just flip it on, use the regular env:set_node stuff and then flip it off (or return from lua) and it blits the stuff and updates lighting
18:38 hmmmm        another option might be to expose a "begin block setting" and "end block setting" api in lua, and we fix up everybody's mod to use that and instruct developers of more obscure mods and new folks to add that
18:38 hmmmm        as for the other stuff...
18:38 hmmmm        if that's not called as often, then it'd suffice to put the locking right in there
18:39 hmmmm        oh yeah that is a good idea, i didn't think of that.
18:39 hmmmm        env:set_node will actually call some builtin lua function to do that
18:39 hmmmm        and that'll maintain the buffer, or we'll maintain the buffer in the core
18:40 celeron55    have you measured the general set_node overhead and what it consists of?
18:40 hmmmm        a lot
18:40 hmmmm        i haven't but i know it's a lot
18:40 hmmmm        too much
18:40 celeron55    have some kcallgrind graph to show or something?
18:40 celeron55    eh... kcachegrind
18:40 celeron55    whatever
18:41 hmmmm        btw what did you think about using RCU for mapblocks
18:42 celeron55    dunno
18:43 celeron55    i'll try to take a quick callgrind run of this and see what set_node looks like
18:44 celeron55    (ehm.... i mean, as quick as it gets)
18:47 celeron55    yeah... not even in game yet
18:48 celeron55    *imaginary whistling*
18:48 thexyz       PilzAdam: odd
18:49 celeron55    *rocks on chair*
18:49 PilzAdam     thexyz, I added the build to http://forum.minetest.net/viewtopic.php?id=4547 so that real windows users can test it
18:50 PilzAdam     but i doubt that its wine only
18:50 celeron55    ooh, the screen updated, to show that media is still at 0% in a local game...
18:51 Exio         valgrind + mt == between 0 to 0 FPS here :P
18:51 celeron55    it's like wait for a day, and then see a frame once a minute
18:52 celeron55    and this is --tool=callgrind, not the regular memory checker
18:52 celeron55    this is slower than anything ever
18:53 celeron55    yeah, then i spawn in a watery sand pit
18:53 celeron55    at 1 frame per 30s
19:23 celeron55    hell, this is just useless
19:23 celeron55    running only the server under callgrind might be a bit useful
19:24 celeron55    somebody else can spend the time for that... if they feel the need for some torture
19:24 celeron55    everybody needs some torture now and then, right?
19:25 hmmmm        no
19:55 PilzAdam     thexyz, the gettext win build works with export LC_ALL=C
19:55 PilzAdam     s/gettext/ttf