Minetest logo

IRC log for #minetest-dev, 2014-08-31

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:07 Eater4 joined #minetest-dev
00:23 Guest31564 joined #minetest-dev
00:31 paramat left #minetest-dev
00:42 kahrl_ <hmmmm> it looks like a poor attempt to make a TreeView =/  <hmmmm> 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
00:52 werwerwer joined #minetest-dev
01:23 hmmmm [06:32 PM] <celeron55_> 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:22 paramat joined #minetest-dev
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
02:37 Miner_48er joined #minetest-dev
03:41 paramat left #minetest-dev
03:52 zat joined #minetest-dev
04:41 sol_invictus joined #minetest-dev
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:44 luizrpgluiz joined #minetest-dev
04:44 luizrpgluiz left #minetest-dev
04:47 hmmmm sol_invictus:  yes, if you have more useful information such as a stack backtrace
04:55 sol_invictus okay
05:13 Eater4 joined #minetest-dev
05:56 khonkhortisan joined #minetest-dev
06:04 nore joined #minetest-dev
06:12 Hunterz joined #minetest-dev
06:17 CraigyDavi` joined #minetest-dev
06:42 Krock joined #minetest-dev
06:46 blaise joined #minetest-dev
07:11 hmmmm ugh
07:11 hmmmm you know what a really hacky but efficient solution would be
07:11 blaise joined #minetest-dev
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:54 blaise joined #minetest-dev
07:57 Amaz joined #minetest-dev
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
08:14 proller joined #minetest-dev
08:16 book` joined #minetest-dev
08:28 crazyR joined #minetest-dev
08:43 PenguinDad joined #minetest-dev
09:15 iqualfragile joined #minetest-dev
09:41 deltib joined #minetest-dev
10:31 crazyR left #minetest-dev
10:55 kahrl joined #minetest-dev
11:31 darkrose joined #minetest-dev
11:40 ImQ009 joined #minetest-dev
11:59 Amaz joined #minetest-dev
12:31 PilzAdam joined #minetest-dev
12:33 iqualfragile joined #minetest-dev
12:35 casimir joined #minetest-dev
12:50 rubenwardy joined #minetest-dev
12:52 AnotherBrick joined #minetest-dev
12:57 PilzAdam joined #minetest-dev
12:57 gentoobro joined #minetest-dev
13:25 RentedMule joined #minetest-dev
13:34 mrtux joined #minetest-dev
13:36 hintss joined #minetest-dev
13:43 crazyR joined #minetest-dev
14:01 iqualfragile joined #minetest-dev
14:19 Calinou joined #minetest-dev
14:28 Eater4 joined #minetest-dev
14:37 VanessaE joined #minetest-dev
14:37 NakedFury joined #minetest-dev
14:37 proller joined #minetest-dev
15:14 hmmmm joined #minetest-dev
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:19 ^v joined #minetest-dev
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)
16:16 zat joined #minetest-dev
16:32 rubenwardy joined #minetest-dev
16:40 zat joined #minetest-dev
16:41 Calinou joined #minetest-dev
16:47 zat joined #minetest-dev
16:49 daswort joined #minetest-dev
16:52 Megaf joined #minetest-dev
16:55 iqualfragile joined #minetest-dev
16:58 EvergreenTree joined #minetest-dev
17:17 Miner_48er joined #minetest-dev
17:33 Calinou joined #minetest-dev
18:06 casimir joined #minetest-dev
18:28 PilzAdam joined #minetest-dev
18:45 khonkhortisan joined #minetest-dev
21:34 khonkhortisan joined #minetest-dev
21:47 Taoki joined #minetest-dev
22:02 paramat joined #minetest-dev
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:11 proller joined #minetest-dev
22:13 alexxss joined #minetest-dev
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/minet​est-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:52 RealBadAngel joined #minetest-dev
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 ;)

| Channels | #minetest-dev index | Today | | Google Search | Plaintext