Time Nick Message 00:42 kahrl_ it looks like a poor attempt to make a TreeView =/ the irrlicht toolkit is wholy unsuitable for a gui 00:42 kahrl_ not really, we have GUITable 00:42 kahrl_ but nobody bothered to use it on the configure screen yet 01:23 hmmmm [06:32 PM] are you intending on locking the mutex every time any operation is done on the VM? 01:24 hmmmm no. the lock would be done inside of Map::setNode when it scans through the list to see if it's invalidating any VMs, and also inside of VoxelManipulator::blitBackAll() to check if its emerged area intersects with any other active VoxelManipulators, and if so, set the dirty flag for those guys 01:26 hmmmm that's to set the dirty flag.. the dirty check would be inside of LuaVoxelManip::l_get_data() that takes an optional boolean to "reload if data invalidated" 01:26 hmmmm I really don't want to do it this way 01:33 Sokomine perhaps adding a second callback for on_generated might help? one which is reserved for voxelmanip operations only? and which would get called before the normal on_generated? 02:01 hmmmm that doesn't help whatsoever 02:27 paramat random experiment: recently i tried using the non-mapgen object vm in an on-generated lua mapgen, thinking it would be faster because it doesn't load in a shell of mapblocks around a chunk ... it was actually 4 times slower =) 02:32 hmmmm well that's because the mapgen object vm doesn't load any map 02:33 hmmmm it already has it loaded in there from the map generation 02:33 hmmmm the whole idea behind the mapgen object vm is that it takes the results straight from the mapgen so you can sort of "hook" onto the mapgen, extending it, without duplicating effort 02:35 paramat i see 04:41 sol_invictus Should I report this bug? 04:42 sol_invictus >connection.cpp:2088: virtual void* con::ConnectionReceiveThread::Thread(): Assertion '0' failed 04:47 hmmmm sol_invictus: yes, if you have more useful information such as a stack backtrace 04:55 sol_invictus okay 07:11 hmmmm ugh 07:11 hmmmm you know what a really hacky but efficient solution would be 07:12 hmmmm what if I added a little shim in ServerMap::setNode() that checks to see if it's from a mapgen thread, and if so, check the area for that particular voxelmanip, and if it's contained in there, set the dirty flag 07:13 hmmmm this makes the solution pretty specific but it removes any need for synchronization 07:20 hmmmm I guess if I'm going to make the solution that specific, i might as well just manually update the VM too 07:21 hmmmm then the flag will say "oh btw, some node got set on the part of map this vmanip has loaded" 07:22 hmmmm and then some moron is going to start calling minetest.set_node() intertwined with the luavoxelmanip operations and then complain that his table isn't getting updated 07:22 hmmmm "BUT IT'S CLEARLY NOT THE MODDER'S FAULT! THE CORE MUST ACCOUNT FOR EVERY SINGLE EDGE CASE IMAGINABLE AND COVER UP ALL OF THE SLIGHTLY COMPLICATED ISSUES OF REALITY!" 07:41 sol_invictus hmmmm: were you addressing my issue now? 07:59 celeron55_ hmmmm: i kind of suggested that 07:59 celeron55_ if we can get the documentation right, it could possibly work 08:00 celeron55_ there still is the issue with parallel VMs though; i wonder when we will stumble upon that 15:18 hmmmm oh god. celeron55_: the issue with parallel VMs is one that I had already had the displeasure of dealing with. see: multi-threaded mapgen 15:19 hmmmm luckily, there it wasn't such a problem because practically the only nodes that got set cross-chunk were air nodes and then the rest would be cignore, so i could 'merge' them together with a tiny bit of logic in blitBack() 15:21 hmmmm i think the policy should just be that the most recent blitback overwrites the old, document that, and let the modders whine all they want that we're not able to do magic tricks 15:21 hmmmm as for reading... that's also a caveat emptor 15:23 hmmmm to my knowledge, because of the lua-table-copy issue, there is legitimately no way to solve that. if it comes to that, where you have multiple lua threads running multiple on_generated callbacks, the time between the beginning of execution and the time the mod calls get_data() is quite short 15:24 hmmmm the mod would spend the vast majority of its time playing around with the map content in Lua table form 15:25 hmmmm i lied, we could have the mod specify a "listen for updates on this table i'm returning" boolean that'll add the table to some global and then scan through if it needs to update that 15:25 hmmmm but now you have classic race conditions in lua - we made that possible! 15:26 hmmmm can you just think? what if lua modders demand that we add locking capabilities to lock specific sub-regions of map loaded in a VM 15:28 hmmmm this is sort of ridiculous.. well-funded browsers don't have multithreaded javascript enginges, does dumb lil' minetest really need one? 15:28 hmmmm the inherent complications threading would bring makes scripting difficult and therefore not fun to the non-experienced coder 15:37 celeron55_ i'm thinking there should be a more clever merge of map data in blitBack() instead of overwriting everything 15:38 celeron55_ it would allow proper multithreaeding and all the pain would just come at the merge 15:39 hmmmm one obvious thing that comes to mind is a node-defined "importance" value 15:40 hmmmm so if default:stone is competing with, say, koolmod123:neatthing, the latter would be actually written 15:40 celeron55_ some kind of merge would allow set_node and VM to coexist without any feedback to the VM until at the merge 15:40 celeron55_ as long as they didn't change the same positions, it would work 15:40 celeron55_ which is probably enough for almost everything 15:41 celeron55_ and only in that case some data would be lost due to the nature of the thing 15:42 hmmmm the node priority value has its own set of problems too 15:42 hmmmm it's likely that mods are going to think of themselves as important and set their nodes to the maximum] 15:43 celeron55_ well, we can provide recommendations and blame the modders if they don't follow them 15:45 celeron55_ which will likely work in important cases 15:45 hmmmm this might solve the problem of mods setting some kind of "kool nodes" in some area without stale vmanip data from the mapgen overwriting it 15:46 hmmmm but i can already imagine 15:46 hmmmm some modder is going to say, "well I'd like to avoid this mod's buildings but I can't do that because I can't see the buildings until after I blit back" 15:47 hmmmm well, they don't say "blit back", they say "write to map" 15:47 celeron55_ well actually our modding community provides a lot of incentive to interacting properly with other mods; if you don't, chances are people will find who is to blame; as long as the API *can* be used right in some way 15:48 hmmmm that's the thing though 15:48 hmmmm they're going to want some way to know if there's going to be some other mod's structure in the way, and if so, place their thing out of the way 15:48 hmmmm if it's all pseudorandom you're not going to be able to know beforehand. 15:49 hmmmm could you imagine, if every mod had to know every other mod's PseudoRandom seed values, and calculate where their structures are going to be written so they are avoided? 15:49 celeron55_ it will always be the price to pay from multithreading 15:49 hmmmm and likewise with perlin noise 15:50 hmmmm well 15:50 hmmmm the node priority value would just be an expansion of "is_ground_content" to a number rather than boolean 15:50 celeron55_ i think we should be able to somehow leave a way to do it slowly but accurately if people want to though... 15:50 celeron55_ i wonder if that's impossible 15:50 celeron55_ without having this mutex stuff in there for every case 15:51 hmmmm ??? 15:51 hmmmm are you implying we keep it single threaded but have each thread's actions spread across multiple callbacks? 15:52 celeron55_ hmm, there are probably other parallel VM cases than what i was thinking about 15:52 hmmmm there are many mods that do some rudimentary form of cooperative multitasking (by giving itself up before the job is complete so ServerThread can run) 15:52 celeron55_ maybe just forget what i said 15:53 celeron55_ but, my point was, someone at some point is probably going to say that he really wants to make sure a thing his mod places in the world is placed there exactly as he wants to, and so that everything coming after it immediately knows it's there 15:53 celeron55_ and we will have to say "no, that will forever be impossible" 15:53 hmmmm that would certainly be interesting though, what if we kept all the mods in a single thread and did some sort of apartment threading model 15:55 celeron55_ anyway i'm fine with a priority merge like that 15:56 hmmmm it's deceptively simple 15:56 celeron55_ it's simple and everyone can understand it and likely works -> perfect for MT 15:56 hmmmm it creates many more problems though 15:57 celeron55_ and also it possibly fixes multiple design issues 15:57 hmmmm this is crazy 15:57 hmmmm but if we do it right then it'd be quite an engineering feat 15:58 hmmmm (by that i mean multithreaded mods) 22:10 paramat VanessaE, hmmmm, during the night in a half-asleep moment i realised a hacky fix for snow plus plantlife, it's simple and it works no dependancies needed: i changed the snow mod's voxelmanip to the non-mapgen object voxelmanip which actually reads the map as the previous mod's on-gen leaves it. i'll release my version soon 22:11 VanessaE paramat: see -dev logs from earlier 22:11 VanessaE ending about 6 hours ago 22:32 hmmmm paramat, hacky solutions are highly discouraged 22:32 paramat yes read that, my idea came thanks to this http://irc.minetest.ru/minetest-dev/2014-08-31#i_3893437 22:32 paramat lol 22:32 hmmmm it'd be best to just wait a little while and I'm going to implement the non-synchronized solution 22:33 paramat yes cool, it's just a hacky fix until then 22:34 paramat using the non-mapgen object voexlmanip slows down snow mod, but i am going to clean up the messy code and add perlinmaps to speed it up 22:34 hmmmm excellent 22:35 paramat hmmmm, if no dependancies are set, what order are multiple on-gen functions registered? 22:36 hmmmm the ones that appear earlier in execution... 22:36 hmmmm those minetest.on_generated( things are actually function calls 22:39 paramat oh so include a 'loaded' message in each mod and watch terminal? so you mean random order? 22:40 hmmmm i'm really not sure what order mods are loaded in 22:40 hmmmm when you said multiple on-gen functions i thought you meant multiple in one mod 22:41 kahrl paramat: you can run with --verbose and grep debug.txt for "Loading and running script from" 22:42 kahrl er I mean debug_log_level = 4 22:42 kahrl but --verbose works too, whatever floats your boat 22:43 kahrl the only guarantee about the order is that it's a topological sorting of the mods based on their dependencies 22:44 kahrl so if mod a depends on mod b, mod b will be loaded before mod a 22:45 paramat okay thanks 22:45 * paramat 's boat flies up into the sky 23:35 crazyR hey guys anyone know why copy/paste works in windows versions of minetest but not in unix/linux versions? 23:38 pitriss crazyR: just try any other clipboard.. there are AFAIK 3 different clipboards 23:39 pitriss crazyR: btw paste is not possible in console and for me needs double ctrl+v 23:40 crazyR paste works for me everywhere outside of minetest. but inside is a diffrent storey. and im not the only unix user to have this issue. 23:40 crazyR *story 23:47 pitriss for me in Kde 3.5/Trinity is enough to mark that copied text, and in game press T and then twice ctrl+v and it just work 23:54 RealBadAngel @paramat, downloading time is terminology of the times past 23:54 RealBadAngel in age of gigabit net argument of file size 5mb sounds like a bad joke 23:55 RealBadAngel popular net games have client downloads like 1,5gb 23:55 RealBadAngel and its nothin special 23:56 RealBadAngel takes half an hour 23:59 proller and takes months on minetest (c) speed ;)