| 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/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: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 ;) |
