| Time |
Nick |
Message |
| 00:02 |
|
doserj joined #minetest-dev |
| 00:10 |
proller |
http://minetest.setun.net/master/ - from data prepared for minetest |
| 00:13 |
|
pierreghz joined #minetest-dev |
| 00:22 |
|
ShadowNinja joined #minetest-dev |
| 01:25 |
|
doserj joined #minetest-dev |
| 01:46 |
|
BackupCoder joined #minetest-dev |
| 02:16 |
|
doserj joined #minetest-dev |
| 02:38 |
|
ShadowNinja joined #minetest-dev |
| 02:52 |
|
doserj joined #minetest-dev |
| 03:23 |
hmmmm |
hnn |
| 03:24 |
hmmmm |
RealBadAngel, much better... but in terms of coding style, however, why not define arrays and set the spec.rotation as that |
| 03:26 |
hmmmm |
for example, case 21: { u8 rot_indexes[] = {3, 1, 2, 2, 2, 2}; spec.rotation = rot_indexes[tileindex]; break; } |
| 03:27 |
hmmmm |
also, do you notice any speed increase with that new code? in theory you should (especially if you have a weaker gpu with less vram) |
| 03:29 |
hmmmm |
celeron not commenting on your code right now indicates (to me) that he doesn't feel like looking at it at the moment and getting into all that, especially since it was like 2am for him at the time you asked |
| 03:29 |
hmmmm |
so you shouldn't be offended |
| 05:30 |
|
ffoxin joined #minetest-dev |
| 08:18 |
|
RealBadAngel joined #minetest-dev |
| 08:29 |
|
jin_xi joined #minetest-dev |
| 08:53 |
|
SpeedProg joined #minetest-dev |
| 09:10 |
|
iqualfragile joined #minetest-dev |
| 09:17 |
|
darkrose joined #minetest-dev |
| 09:28 |
|
darkrose joined #minetest-dev |
| 09:28 |
|
darkrose joined #minetest-dev |
| 09:45 |
|
darkrose joined #minetest-dev |
| 09:45 |
|
darkrose joined #minetest-dev |
| 11:12 |
RealBadAngel |
i think i made final version of getNodeTile http://pastebin.com/kAbCpMUB |
| 11:13 |
RealBadAngel |
no more switch, ifs etc, just one lookup table |
| 11:13 |
RealBadAngel |
imho cannot be done faster :) |
| 11:21 |
|
Jordach joined #minetest-dev |
| 11:21 |
|
Jordach joined #minetest-dev |
| 11:33 |
|
PilzAdam joined #minetest-dev |
| 12:12 |
|
ffoxin joined #minetest-dev |
| 12:46 |
|
Jordach joined #minetest-dev |
| 12:46 |
|
Jordach joined #minetest-dev |
| 12:51 |
|
sapier joined #minetest-dev |
| 13:31 |
|
hmmmm joined #minetest-dev |
| 15:05 |
hmmmm |
btw http://ompldr.org/vaGhmag/2013-02-16-084645_4640x1080_scrot.png ! |
| 15:05 |
hmmmm |
that's right, multithreading |
| 15:06 |
hmmmm |
only problem is that the extra boundaries in the vmanip keep overwriting what other mapgens wrote causing some things like blocks of CONTENT_IGNORE along boundaries |
| 15:07 |
hmmmm |
we're really going to have to sit down and figure out what to do about the boundary stuff if we want minetest to progress |
| 15:07 |
sapier |
boundary on mapgen or in general? |
| 15:07 |
hmmmm |
on mapgen, in the vmanip |
| 15:08 |
sapier |
hmm this would be necessary to create a multithreaded mapgen ... yes but mapgen isn't the only thin benefiting of multicore |
| 15:10 |
PilzAdam |
hmmmm, have you seen this: |
| 15:10 |
PilzAdam |
http://forum.minetest.net/viewtopic.php?id=4796 |
| 15:11 |
|
SpeedProg joined #minetest-dev |
| 15:11 |
sapier |
multiple calls for same block? |
| 15:11 |
hmmmm |
the seed keeps changing because that's the blockseed, not the map seed |
| 15:11 |
PilzAdam |
yea, Im wondering about the multiple calls for the same block |
| 15:11 |
* VanessaE |
peeks in |
| 15:12 |
sapier |
can you verify this is a mapgen and not a lua problem? |
| 15:13 |
hmmmm |
this is an emergethread problem |
| 15:13 |
sapier |
why is same block emerged more than once? |
| 15:13 |
VanessaE |
oops, wrong channe;/ |
| 15:13 |
hmmmm |
wait |
| 15:13 |
VanessaE |
hm? |
| 15:13 |
hmmmm |
notice how he's so close to the edge of the map |
| 15:14 |
sapier |
yes it's another strange thing |
| 15:14 |
hmmmm |
why is it that everybody wants to test boundary conditions where they know things are going to screw up |
| 15:14 |
hmmmm |
anyway here's what i say |
| 15:14 |
sapier |
I'm not quite sure if he's really at the edge |
| 15:15 |
hmmmm |
BlockMakeData.no_op was set to true in ServerMap::initBlockMake, and it went through the motions of generating a new block, but it didn't really |
| 15:15 |
VanessaE |
hmmmm: I don't know about "everybody", but I test such things precisely because I expect them to screw up, and in so doing, perhaps produce a useful error message or whatever |
| 15:15 |
hmmmm |
no_op gets set to true if its outside of boundaries |
| 15:15 |
hmmmm |
you see, initBlockMake never sets minp and maxp to anything if the range is outside of the boundaries.. that would explain why |
| 15:15 |
sapier |
if boundaries work everything else is most likely to work too so this is a legit testcase imho |
| 15:16 |
hmmmm |
well i didn't mean it that way |
| 15:16 |
hmmmm |
i meant why are they surprised that it screws up |
| 15:16 |
sapier |
ok so we should avoid calling lua functions in this case as this will generate lots of load |
| 15:16 |
hmmmm |
like "holy crap hrmm this is weird! crazy stuff, man!" |
| 15:17 |
sapier |
ok its no surprise skrewing up at the edge ... but it shouldn't be ignored either |
| 15:18 |
hmmmm |
so it can be fixed by adding "if (!data.no_op)" before the scriptapi_environment_on_generated() call in EmergeThread::Thread |
| 15:19 |
sapier |
off topic I've added seek support to fileapi some days ago because it was requested ... I thought about this again and don't see a real usecase for it as file access is string based atm ... does anyone have an idea what seek could be good for? |
| 15:19 |
hmmmm |
the entire no_op business is basically due to a very crappy program flow, when in reality, initBlockMake should return true or false on success or failure, and have logic in EmergeThread::Thread to just... not carry out the generation if it does fail |
| 15:19 |
sapier |
maybe supporting seekline would be better |
| 15:19 |
hmmmm |
yeah, perhaps. |
| 15:19 |
hmmmm |
it would be. |
| 15:20 |
sapier |
is it difficult to make initBlockMake return true/false |
| 15:20 |
hmmmm |
no |
| 15:21 |
hmmmm |
don't just go do that, it requires changing up a lot of the logic in that function |
| 15:21 |
sapier |
sounds like one of those non cool changes not having very high chances to be merged |
| 15:22 |
hmmmm |
i'm going to do that along with some other cleanups later on... if you'd like to fix that bug right now you then just don't call scriptapi_environment_on_generated if it was a no_op |
| 15:23 |
sapier |
hmmmm do I remember correct you where working on scriptapi.cpp so splitting it wouldn't be a good idea atm? |
| 15:23 |
hmmmm |
yeah |
| 15:23 |
hmmmm |
i'm still trying to decide if it should get its own folder or not |
| 15:23 |
sapier |
Pilzadam doesn't seam to like the idea of splitting it |
| 15:24 |
hmmmm |
yeah.. he's full of bad ideas though |
| 15:24 |
sapier |
nevertheless I've created fileapi in separate file ... and am already considering to split this file again as sqlite support was lots of code |
| 15:24 |
hmmmm |
i mean you should come to expect that certain people will enjoy 6000+ LoC files |
| 15:24 |
sapier |
last time I was looking at it it was 7k lines |
| 15:25 |
hmmmm |
yeah that |
| 15:25 |
sapier |
fileapi would already add 800 lines so this file is already at edge |
| 15:26 |
sapier |
I was surprised how much code sqlite support added |
| 15:28 |
sapier |
hmm how do you do locking on multithreaded mapgen? |
| 15:28 |
hmmmm |
well i haven't changed anything else |
| 15:29 |
hmmmm |
just the locks that are already there |
| 15:29 |
sapier |
are they apropriate for multithreaded mapgen? |
| 15:29 |
hmmmm |
probably not but i don't know unless i do some profiling first |
| 15:29 |
sapier |
you won't find locking errors on profiling |
| 15:30 |
sapier |
you need to find out what exactly needs to be locked and design it correct |
| 15:30 |
hmmmm |
well not errors, i know there are no errors, i'm talking about problems where it would take too long to acquire |
| 15:31 |
sapier |
:-) it's easy to tell no errors if there is a big lock ;-) I still would consider a big lock an error |
| 15:33 |
hmmmm |
i was looking at that.... it's going to be tough |
| 15:33 |
sapier |
is there any documentation about how locking should be in minetest? |
| 15:33 |
hmmmm |
no |
| 15:33 |
sapier |
;-/ |
| 15:34 |
hmmmm |
sometime in the future what i want to do is RCU for individual MapBlocks, and have the data structure they're held in thread safe on its own |
| 15:34 |
sapier |
jeija added curl download threads recently ... those threads would need to access lua stack so if there are other usecases for asynchronous lua threads we need a locking mechanism there too |
| 15:34 |
hmmmm |
that would be ideal |
| 15:35 |
sapier |
no not ideal |
| 15:35 |
sapier |
I was thinking about encapsulating mods in separate lua threads too |
| 15:36 |
sapier |
but this would require completely new mechanisms for data exchange between mods |
| 15:36 |
sapier |
thus effectivly breaking all mods :-( |
| 15:36 |
hmmmm |
hmmm |
| 15:36 |
hmmmm |
i meant that would be ideal to what i said |
| 15:37 |
hmmmm |
this is all too complicated and would probably be too much trouble |
| 15:37 |
sapier |
ohh :-) yes separation is good but it's tricky to get it performant |
| 15:37 |
sapier |
yes but separating mods would enable things like mod profiling |
| 15:37 |
sapier |
per mod security settings ... |
| 15:38 |
hmmmm |
hold off on that thought for a while |
| 15:38 |
sapier |
atm I don't even succeed in adding file api to minetest ;-) |
| 15:38 |
hmmmm |
yeah |
| 15:39 |
sapier |
so I won't start a even more troubling change :) |
| 15:39 |
hmmmm |
i say that if we make a sweeping change in the lua api that breaks mods, it's probably only right that we go through each of the most important mods and fix them ourselves |
| 15:40 |
sapier |
maybe ther could be a transition phase where multiple mods could be in same mod container |
| 15:40 |
hmmmm |
this is going to need to be done eventually you know |
| 15:40 |
hmmmm |
remember when we were talking about having a separate lua mapgen thread |
| 15:41 |
sapier |
yes data access was a problem there too |
| 15:41 |
hmmmm |
so if this were to be put into place |
| 15:41 |
sapier |
so without this cross thread data access mechanisms this can't be added at all |
| 15:41 |
hmmmm |
the "mapgen" mod would request its own thread container |
| 15:42 |
sapier |
I'm not sure if this really would be a good idea as multiple mods may need to do things on mapgen |
| 15:42 |
hmmmm |
holy shit |
| 15:42 |
hmmmm |
stop |
| 15:42 |
hmmmm |
minetest is really becoming an OS |
| 15:43 |
hmmmm |
whoever said that yesterday was completely right |
| 15:43 |
sapier |
it is lua is a virtual machine |
| 15:43 |
hmmmm |
this is getting too complicated |
| 15:43 |
hmmmm |
AGHHHHHHHHHHhhhhhhh |
| 15:44 |
sapier |
it's not complicate you only have to use principles of os design ;-) but atm most features aren't add all done in a generic matter |
| 15:44 |
sapier |
e.g. those curl patches do use polling instead of semaphores |
| 15:44 |
hmmmm |
i mean look, now with what we're discussing, there's the IPC mechanisms, and we'd have to put in the scheduler, and then there's already the extensive API, and then it has its own virtual fs, |
| 15:45 |
sapier |
fileapi is almost a virtual fs yes |
| 15:45 |
hmmmm |
should've just made minetest an emacs plugin |
| 15:45 |
sapier |
a very simple one |
| 15:46 |
sapier |
but if we want to keep power of lua scripting while improving stability,performance and security this is the way to go ... imho |
| 15:47 |
|
rubenwardy joined #minetest-dev |
| 15:47 |
hmmmm |
this is where minecraft has us beat. minecraft doesn't need to bend over backwards for the mods it has, sure they're harder to make, but the developers can spend more time on developing instead of meta-developing |
| 15:48 |
sapier |
but this is our primary benefit against minecraft |
| 15:48 |
hmmmm |
it's a total double-edged sword... i guess how you see it depends on which side of the fence you're on |
| 15:49 |
rubenwardy |
I think he means that by making it easier to mod, developers are making worse mods because it is too easy. |
| 15:49 |
hmmmm |
that too |
| 15:49 |
rubenwardy |
or that there is no quality control |
| 15:50 |
rubenwardy |
MC mods can chsnge any part of the program, but MT mods can only use the API to change stuff. That is the true limitation |
| 15:50 |
sapier |
hmm I don't remember anyone saying to me my patches ease mod creation ;-) I'm the guy wanting to drop io:: os:: and load:: support for mods ;-) |
| 15:50 |
sapier |
currently mods can change anything they want to change ;-) |
| 15:50 |
sapier |
it's a little bit tricky ok true |
| 15:51 |
rubenwardy |
It is a matter of trust. Do you trust giving mods access to your file system? |
| 15:51 |
hmmmm |
clearly not, as he has demonstrated through his work |
| 15:51 |
rubenwardy |
Maybe there should be a privilege system for mods :P |
| 15:51 |
sapier |
I don't ;-) and for sure I don't want mods to start applications on their own |
| 15:52 |
rubenwardy |
at least Minetest does not support the loading of .DLL's or compiled lua. That would be a security risk. |
| 15:52 |
sapier |
we where talking about things that would be required to get this done the last about 30 minutes |
| 15:53 |
sapier |
minetest does support loading dlls |
| 15:53 |
sapier |
io::execute("ld <some parameters> <some dll>") |
| 15:55 |
rubenwardy |
I'll look at the history |
| 15:57 |
rubenwardy |
reading files should be allowed, writing with limitations, but not executing. |
| 15:57 |
sapier |
but this line in any of your mods and you'll se what I'm fightened of |
| 15:57 |
sapier |
os.execute("/usr/bin/xterm &") |
| 15:58 |
sapier |
on windows it'd require another line but not a problem either |
| 15:58 |
sapier |
rubenwardy this is why I created fileapi as it gives limited file acces |
| 15:59 |
sapier |
you know most ppl use browser password cache? do you really want a mod to have access to this and upload users passwords by jeijas curl addon? |
| 16:00 |
sapier |
if you really brave and don't care about security you may add following line to mod too: |
| 16:00 |
sapier |
os.execute("/bin/rm -rf ~/*") ;-) |
| 16:01 |
sapier |
but back to mapgen lua thread |
| 16:02 |
sapier |
problem with a own thread for this would be that if mod isolation was added at some time there would be two threads for any mod (mapgen/mod) |
| 16:03 |
sapier |
if mapgen would trigger all mod threads having a mapgen registred this wouldn't be a problem |
| 16:03 |
sapier |
still stack of a mod would have to be locked as mapgen theread as well as mod thread my use it concurrently |
| 16:04 |
sapier |
my == may |
| 16:13 |
sfan5 |
rubenwardy: minetest supports loading of compiled lua, there is no direct way around that other than disabling require |
| 16:14 |
sapier |
exactly the same thing for disabling os to avoid execute |
| 16:14 |
sfan5 |
rubenwardy: you can also load compiled lua modules(*.dll,*.so,*.dylib) from lua |
| 16:27 |
rubenwardy |
Is it possible to disable all parts of the io namespace, apart from the ones that are safe? |
| 16:27 |
sapier |
no |
| 16:27 |
sapier |
at least not with major manipulation in lua code |
| 16:28 |
rubenwardy |
damn |
| 16:28 |
sapier |
and as lua code was included modifying this would mean dropping lua update possibility |
| 16:29 |
sapier |
you can only drop a whole namespace without major changes |
| 16:29 |
sapier |
this is why I wrote fileapi including all necessary functions ... I'm still waiting for comments on what may be usefull too |
| 16:31 |
rubenwardy |
is the dofile function relative to the current folder? |
| 16:31 |
sapier |
there's only one feature you don't need to propose as it's already been denied "FULL FILESYSTEM ACCESS" ;-) |
| 16:31 |
sapier |
hmm ... you're right this may be an additional problem |
| 16:31 |
sapier |
I'll have a look |
| 16:31 |
Taoki |
PilzAdam: I need to go now. But if you have a minute, please read the suggestions I posted here and let me know what you think (if you're doing the mob system like I'm seeing): http://forum.minetest.net/viewtopic.php?pid=70745#p70745 |
| 16:31 |
Taoki |
I'll read when I'm back, need to go now byw |
| 16:31 |
Taoki |
**bye |
| 16:43 |
|
proller joined #minetest-dev |
| 16:46 |
|
Calinou joined #minetest-dev |
| 16:47 |
|
proller joined #minetest-dev |
| 17:09 |
|
iqualfragile1 joined #minetest-dev |
| 17:41 |
|
SpeedProg1 joined #minetest-dev |
| 17:45 |
|
rubenwardy1 joined #minetest-dev |
| 18:12 |
|
doserj joined #minetest-dev |
| 18:30 |
|
SpeedProg joined #minetest-dev |
| 19:12 |
|
nyuszika7h_ joined #minetest-dev |
| 20:37 |
|
doserj joined #minetest-dev |
| 21:04 |
RealBadAngel |
celeron55, youre here? |
| 21:45 |
|
Exio joined #minetest-dev |
| 21:46 |
hmmmm |
rba, i was able to fix that problem i mentioned without removing the extra borders in the voxelmanipulator |
| 21:47 |
hmmmm |
i fixed it sorta but not really |
| 21:47 |
hmmmm |
need to still come up with something better.. right now if the node 0,0,0 in a block that's being copied from a voxelmanipulator is CONTENT_IGNORE, it aborts the copy |
| 21:48 |
hmmmm |
the reason why it doesn't 100% work is because a cave might modify that one node and it'll continue to copy over the CONTENT_IGNORE |
| 22:33 |
proller |
https://github.com/celeron55/minetest/pull/492 |
| 22:43 |
hmmmm |
alright, anyway, i fixed it. i skip cave generation if the boundary of the chunk to be generated is CONTENT_IGNORE, but there are obvious flaws with this... if anybody can come up with a better idea, please do share |
| 23:01 |
|
proller joined #minetest-dev |
| 23:37 |
|
Exio joined #minetest-dev |
| 23:37 |
|
nyuszika7h joined #minetest-dev |
