Time  Nick         Message
01:53 hmmmm        ah, i see you've already dealt with this problem to an extent before... hence BlockGenerationStatus
02:58 thexyz       http://irc.minetest.ru/minetest/2013-02-16#i_2876764 + http://irc.minetest.ru/minetest/2013-02-17#i_2876870
02:58 thexyz       crap!
03:24 hmmmm        is it just me, or does a lot of map.cpp seem to just repeat itself over and over and over and over
03:24 hmmmm        500 functions that do the same thing
03:31 hmmmm        anyway i came up with a clean, decent idea. in MapVoxelManipulator::emerge and ManualMapVoxelManipulator::initialEmerge, I have it set a flag if 1). the block data exists and 2). the first node of the data is CONTENT_IGNORE.  i'll call this flag VMANIP_BLOCK_CONTAINS_CIGNORE or something, and i'll make block_data_inexistant into VMANIP_BLOCK_DATA_INEXIST.  so m_loaded_blocks will have a u8 or something as the value instead of a bool.
03:31 hmmmm        i don't have to change *too* much around for this
03:32 hmmmm        then, in initBlockMake, after vmanip's initialEmerge(), I go through blockpos_min and blockpos_max and manually reset the VMANIP_BLOCK_CONTAINS_CIGNORE flag, leaving the border blocks the only ones that can possibly have it set
03:32 hmmmm        then in the vmanip blitBack and blitBackAll, I skip over blitting the block back if VMANIP_BLOCK_CONTAINS_CIGNORE is set
03:33 hmmmm        actually, i can't see a reason why anybody would need to know this aside from celeron..
06:48 hmmmm        https://github.com/kwolekr/minetest/commit/98f9d8128462808c3d65fd656bb15ede6d50b394
07:41 RealBadAngel damn, solved problem flipping textures on X :)
07:42 RealBadAngel its good to take a nap and come back to the problem next morning hehe
07:49 RealBadAngel hmmmm, you have to define how many threads will be used?
07:49 hmmmm        clearly not.. see line 59 of emerge.cpp
07:51 RealBadAngel so whats that for? settings->setDefault("num_emerge_threads", "");
07:51 hmmmm        all settings need to be set to a default, if you don't it'll throw an exception and crash when you try to access it and it's not in minetest.conf
07:52 hmmmm        that field is blank instead of a number so that i can see if it was set or not with .empty()
07:53 RealBadAngel so, nr of threads depends of how many cpus you have
07:53 hmmmm        unless you explicitly set it otherwise
07:54 RealBadAngel if i do have dual core and set it to 4?
07:54 RealBadAngel it gonna explode? ;)
07:55 hmmmm        actually with the other default settings, no, you won't notice a difference at all.  you need to increase emergequeue_limit_generate and emergequeue_limit_diskonly to actually take advantage of it
07:55 hmmmm        i'll do that in a bit
07:56 hmmmm        i need to dynamically set those values based on how many threads there are too
08:43 RealBadAngel https://github.com/RealBadAngel/minetest/commit/43496b0d90180742ffa38d52ec0ffedb09d14074
08:43 RealBadAngel 6d facedir for meshes is ready
08:43 RealBadAngel now need to rotate just nodeboxes
10:27 RealBadAngel http://forum.minetest.net/viewtopic.php?pid=70867
10:28 RealBadAngel some info and tools to test 6d facedir
12:57 RealBadAngel ive updated my git with 6d facedir rotations for nodeboxes also
12:57 RealBadAngel need to fix the old bug with need for coords to be sorted
12:59 RealBadAngel also screwdriver is updated, pick the face, first use will bring there top of the node, next uses will rotate node
13:00 RealBadAngel extremely easy now to place pistons or rotate stairs+ nodes
16:28 hmmmm        how intensive is MeshGenerationThread?
16:29 hmmmm        i'll ask the real question... if you can choose two non-emerge threads in particular to tie down to a specific core, which would they be?  for the client?  for the server only?
16:34 VanessaE     depends.  what's the benefit of locking a thread to a specific core?
16:34 VanessaE     aside from core-to-core migration latency
16:34 hmmmm        cache coherency
16:34 VanessaE     hm
16:36 VanessaE     dunno, I can't really think of anything that would have a net benefit
16:37 VanessaE     I mean, the rendering code certainly, but then if you go multithreaded with that, then fat lotta good that does
16:37 hmmmm        woah, i did not go that far.
16:37 VanessaE     heh
16:38 VanessaE     "if you go" = "if some day months-to-years down the line, you go..."
16:38 VanessaE     etc.
16:39 VanessaE     two non-emerge threads..
16:39 VanessaE     well networking and sound don't really need much, what about those?
16:40 hmmmm        those would be examples of things that i wouldn't bind
16:41 VanessaE     no idea then
18:08 hmmmm        hmm
18:09 hmmmm        on windows systems, if minetest is being run in single player mode, i want the emergethreads to have PROCESS_MODE_BACKGROUND_BEGIN priority
18:10 hmmmm        or should i just have it BELOW_NORMAL_PRIORITY_CLASS
18:10 hmmmm        when in doubt leave it up to the user, with a sane default :)?
18:11 hmmmm        indeed, it shouldn't have a background priority since that would cause a priority inversion thanks to the envlocks
18:12 hmmmm        unless i were to set it in between the makeChunk calls
20:24 thexyz       any thoughts on this https://github.com/xyzz/minetest-stress/blob/master/examples/simple/init.lua ?
20:24 thexyz       jquery-like syntax for minetest modding api
20:30 troller      https://github.com/celeron55/minetest/pull/492 - ready for merge!
20:30 troller      http://servers.minetest.net/ up
23:32 sapier       https://github.com/sapier/minetest/commit/03d3af485eb36e75ca316e89a6969481efa692aa
23:32 VanessaE     hmmmm: in singleplayer, anything that directly faces the user should have absolute priority over that which does not - so the rendering thread(s) could be pushed up along with the code that communicates regarding your look direction and position back and forth to the server.  Then the rest of the server can be basically back-burnered.
23:32 sapier       this is security hardening patch preserving full API compatibility to builtin io and os functions
23:32 hmmmm        that's a little too complicated vanessa
23:32 VanessaE     that should do a lot to stop the occasional hangs and lags in the client side that happen when the singleplayer server gets slow
23:32 sapier       at least for those functions not considered harmfull and disabled
23:33 VanessaE     well I guess it would be, but that's just how I'd do it if I were writing this from scratch
23:34 sapier       isn't everything within players view already priorized above other nodes/blocks?
23:41 hmmmm        yes, it's sorted in terms of distance from the player
23:42 hmmmm        if the block isn't within the player's sight, it doesn't get selected for sending at all