Minetest logo

IRC log for #minetest-dev, 2013-06-22

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

All times shown according to UTC.

Time Nick Message
00:40 sapier left #minetest-dev
00:53 kaeza joined #minetest-dev
01:27 EduardeCalibal joined #minetest-dev
01:29 kaeza joined #minetest-dev
01:38 diemartin joined #minetest-dev
01:39 ch98 left #minetest-dev
01:42 dexter0 joined #minetest-dev
01:43 ssieb joined #minetest-dev
01:44 BackupCoder joined #minetest-dev
01:45 Deivan joined #minetest-dev
01:54 EduardeCalibal joined #minetest-dev
02:09 Mallot1 joined #minetest-dev
02:09 Mallot1 hey, where should i learn Lua?
03:07 dzho <.<
03:10 Mallot1 what/
03:10 Mallot1 ?
03:20 hmmmm muwahaha
03:20 hmmmm mapgen v7 is now playable
03:20 hmmmm though i wouldn't recommend using it.
03:28 hmmmm http://oi41.tinypic.com/2nthcvk.jpg
03:30 ShadowNinja What is the name of a 80x80 mapgen chunk? Chunk?
03:30 ShadowNinja hmmmm: ^
03:31 hmmmm 80x80x80 you mean... it's just called "default-sized chunk"
03:32 ShadowNinja Er, yes.
03:33 Mallot1 joined #minetest-dev
03:36 D-Man joined #minetest-dev
04:04 kaeza joined #minetest-dev
04:08 kahrl hmmmm: awesome!
04:08 hmmmm yeah
04:09 hmmmm just writing up the lua api docs right now
04:09 hmmmm i'm going to commit soon
04:30 hmmmm https://github.com/kwolekr/minetest/commit/6d1c9d61d74336a479750c9a9746d1a33148e1ab
04:44 kahrl https://github.com/kwolekr/minetest/commit/6d1c9d61d74336a479750c9a9746d1a33148e1ab#L1R675
04:44 kahrl ^ shouldn't there be another "For each node in schematic:" below this line?
04:44 hmmmm nope
04:44 hmmmm i pair the params together.  they're both almost always 0 and compress well that way
04:45 kahrl I thought serializeBulk always separated them
04:45 hmmmm oh shoot
04:46 hmmmm you're right, i forgot to change that when i decided to use serializeBulk instead of my own
04:59 kahrl couldn't SWAP be replaced with std::swap?
04:59 hmmmm ah std::swap
04:59 hmmmm i'm glad i didn't use that, i recall std::swap giving problems with MS VC++
04:59 kahrl haha
05:00 kahrl why does anyone call that a C++ compiler :P
05:00 hmmmm you know what i'm talking about, right?  can't remember exactly what it was, but it broke compilation if they didn't add something extra
05:00 hmmmm something about namespaces
05:01 hmmmm ah here we are http://connect.microsoft.com/VisualStudio/feedback/details/499152/valid-c-program-using-std-swap-fails-to-compile-in-vc10
05:01 hmmmm err it was http://connect.microsoft.com/VisualStudio/feedback/details/387055/using-declaration-using-std-swap-should-not-disable-argument-dependent-lookup
05:02 hmmmm actually it seems like there are a whole bunch of different problems with std::swap with MSVC++
05:03 kahrl the reason I'm asking is because the way SWAP is written it might lead to weird things
05:03 hmmmm hmm?  like what
05:03 kahrl for example, you can't add an else in sortBoxVerticies
05:03 kahrl at least I'm pretty sure you can't
05:04 hmmmm don't get what you mean... i can change it to do {} while (0) if you'd like
05:04 kahrl yeah that would be a solution
05:04 hmmmm although i technically shouldn't need to do that
05:04 hmmmm i don't think other macros do either
05:05 hmmmm ahh
05:05 hmmmm i see what you mean haha
05:06 kahrl oh yeah CHECKKEY and QUICKTUNE have the same problem
05:07 kahrl and there are some others
05:07 hmmmm anyway i fixed that here
05:07 mrtux_ joined #minetest-dev
05:11 hmmmm fixed two things in lua docs.  looks good now
05:13 hmmmm now i need to add rotations :/
05:14 kahrl when placing, Would it be a good idea to skip the CONTENT_AIR/CONTENT_IGNORE check when param1 is != 0?
05:14 hmmmm the L-system decoration type is still sort of up in the air.  i'm not entirely sure what to do, because the system currently in place is really only for trees.  iirc jin_xi has a more complete, generalized version, but it requires lua callbacks to carry out the rules.
05:15 kahrl so that if someone really wants to place air in a schematic, just set param1 to 255
05:15 hmmmm maybe
05:15 hmmmm keep in mind they can forcibly place air in a schematic if they manually place it
05:16 hmmmm i'm not sure what sort of use case setting air can have as a decoration though..
05:16 hmmmm we'll see how much they want to be placing air
05:16 kahrl oh wait param1 = 255 would still be less than 100%
05:17 kahrl hmmmm, placing rooms underground
05:17 hmmmm how would that work?  these are placed on ground level
05:18 kahrl not with decorations I guess... but place_schematic
05:18 hmmmm again, with place_schematic, it doesn't check for air/content ignore
05:18 kahrl I'd like to close the "set multiple nodes at once" feature request when place_schematic is merged
05:18 kahrl oh, I thought they were the same
05:19 hmmmm nope... see placeSchematic vs. generate
05:19 kahrl kind of confusing but it works
05:28 hmmmm can i make a pull request on github without forking the repository?
05:28 hmmmm i think you do something with the patches
05:28 kahrl pretty sure a pull request requires a branch
05:30 kahrl the branch could be in the upstream repository so technically a fork isn't needed
06:11 emptty joined #minetest-dev
06:37 hmmmm https://images.4chan.org/g/src/1371882632988.jpg
06:37 hmmmm crazy - wonder if that was generated, probably not though
06:38 hmmmm in noiseparams, the spread factor is always the same for the three components but it doesn't need to be like this
06:39 hmmmm increase the y component of np_ridge in mgv7 and you should be able to get nice vertical gloops in terrain, sort of like that
06:39 hmmmm certainly not anything that cool
06:46 Calinou joined #minetest-dev
06:53 emptty joined #minetest-dev
07:12 neko259 joined #minetest-dev
07:39 darkrose joined #minetest-dev
08:04 Anchakor_ joined #minetest-dev
08:05 Zeg9 joined #minetest-dev
08:25 emptty joined #minetest-dev
08:46 ffoxin joined #minetest-dev
08:47 ffoxin joined #minetest-dev
09:15 ffoxin left #minetest-dev
09:32 Calinou joined #minetest-dev
09:41 Jordach joined #minetest-dev
10:59 Calinou joined #minetest-dev
11:00 neko259 joined #minetest-dev
11:06 emptty joined #minetest-dev
11:06 rubenwardy joined #minetest-dev
11:06 rubenwardy joined #minetest-dev
11:11 PilzAdam joined #minetest-dev
11:22 dexter0 joined #minetest-dev
11:23 rubenwardy joined #minetest-dev
11:25 PilzAdam hmmm, you have reverted the changes of two commits in lua-api.txt
11:26 PilzAdam +m
11:43 Taoki joined #minetest-dev
11:43 emptty joined #minetest-dev
12:05 tango_ joined #minetest-dev
12:09 ImQ009 joined #minetest-dev
12:33 Nekofire joined #minetest-dev
12:35 Nekofire Hello anyone active in here at the moment
12:41 * sfan5
12:52 PilzAdam joined #minetest-dev
12:53 iqualfragile joined #minetest-dev
13:04 Wuzzy joined #minetest-dev
14:03 PilzAdam joined #minetest-dev
14:05 Anchakor_ joined #minetest-dev
14:06 ImQ009 joined #minetest-dev
14:18 ecube joined #minetest-dev
14:50 proller try#6 everyone ready for ipv6?
15:05 Anchakor_ joined #minetest-dev
15:05 Anchakor_ joined #minetest-dev
15:21 Taoki joined #minetest-dev
15:26 Calinou joined #minetest-dev
15:29 iqualfragile joined #minetest-dev
15:38 Zeg9 joined #minetest-dev
15:42 PilzAdam joined #minetest-dev
16:09 emptty1 joined #minetest-dev
16:10 Zeg9 joined #minetest-dev
16:16 emptty joined #minetest-dev
16:39 hmmmm joined #minetest-dev
16:59 Nekofire Hello
16:59 sapier joined #minetest-dev
17:02 sapier https://github.com/sapier/minetest/tree/async_lua_functions hmmmm what do you think about this proof of concept for asynchronous lua function calls?
17:03 * hmmmm blinks
17:03 hmmmm wait you're making a new thread for this?
17:04 sapier it's only 202 line change so quite small for me
17:04 hmmmm don't half of the api that don't need locks return a result?
17:04 hmmmm doesn't half*
17:05 hmmmm also you and your friend claasses
17:05 hmmmm nobody here uses that :/
17:05 sapier but it works and encapsulation is done quite well
17:06 sapier I don't need to publish full api up to main.cpp
17:06 sapier but in this special case adding a job dispatcher may even result in removing it
17:06 hmmmm alright i only read through half of the source
17:06 hmmmm but it seems to be sort of like this would only work for new api
17:07 hmmmm get job results?
17:07 sapier what do you mean with new api?
17:07 sapier if you issue a job request you get back an id
17:07 hmmmm how is the lua caller supposed to get the result
17:07 sapier once the job is finished a callback is called passing id and result
17:07 hmmmm through that api?
17:08 hmmmm see?  exactly, like i said, this would only work for new api
17:08 hmmmm unless you want to make a new set of asynchronous versions
17:08 sapier yes it's a new feature asynchronous tasks
17:08 hmmmm which you'd have to basically force people to adopt
17:08 sapier it was never meant to replace current api but just provide a interface for long run functions
17:09 hmmmm because why on earth would somebody use local jobid = minetest.foo_async(blahblahblah)        ... minetest.get_job_results(jobid) -- can this block?
17:09 sapier no it can't
17:09 hmmmm what happens if it's not ready...
17:09 sapier if what isn't ready? if there's another job running the new one is queued
17:10 hmmmm no i mean what if the lua caller tries to get the result of a job that hasn't completed yet
17:10 sapier there's no way to activly fetch a result by now
17:11 hmmmm maybe i'm misreading something
17:11 sapier waiting for a asynchronous result is somehow useless you wouldn't have to do it asynchrounous if you're waiting for it
17:11 hmmmm what is the point of get_job_result then
17:11 hmmmm who calls it
17:12 sapier it's internal job/result queuing
17:12 sapier in environmental on_step there's checked if results are ready
17:12 hmmmm ah
17:12 sapier if this is case the result callbacks are called
17:12 hmmmm are you sure that's a good idea
17:13 hmmmm because now every asynchronous call's results have a maximum latency of an entire server step
17:13 hmmmm that could be 100ms for all you know
17:13 hmmmm which it is by default
17:13 hmmmm see what i would've done here is have the caller register a callback function
17:13 sapier it's meant for long run tasks so imho 100ms isn't a problem
17:14 hmmmm i sort of wonder what kind of long run tasks we're talking about...
17:14 sapier someone needs to call the callback
17:14 sapier I'm not sure if it'd be a good idea to call it from another thread ... but yes that'd be a possibility
17:14 hmmmm i would do it from the async task thraed
17:15 hmmmm er wait
17:15 hmmmm no that's bad, lua can only have one thing running at a time
17:15 hmmmm wow, lua is really dumb
17:15 hmmmm who came up with this crap
17:15 hmmmm alright your way is good then
17:15 sapier yes ... i realized this when trying to get luathreads working ;-)
17:17 Mallot1 joined #minetest-dev
17:17 hmmmm what's with async_yield
17:17 PilzAdam hmmmm, have you read the logs yet?
17:17 hmmmm 1 ms?? isn't that kind of arbitrary
17:17 hmmmm what's wrong with pthread_yield()?
17:17 sapier some quick solution to stop the worker thread from consuming full cpu power
17:18 Mallot1 we should add a computer into the game
17:18 Mallot1 a programmable computer
17:18 sapier hmmm nothing but phtread_yield isn't available on windows ;-)
17:18 Mallot1 like computercraft :D that you can program with Lua and you can program the mesecons and stuff :D
17:18 hmmmm sapier, you can do Sleep(0) on windows
17:19 PilzAdam Mallot1, mesecons already has a Luacontroller
17:19 Mallot1 sapier i edited your mod pack
17:19 hmmmm <PilzAdam> hmmm, you have reverted the changes of two commits in lua-api.txt
17:19 sapier good idea I'll fix it
17:19 Mallot1 they do?
17:19 hmmmm saw that
17:19 sapier thx Mallot1 I already pushed your fix
17:19 hmmmm i was going to fix it back along with some other things in a separate fix random crap commit
17:20 sapier the big question about the async feature is "does it really fix problems?" ;-)
17:20 hmmmm i suppose what happened was that i rebased on current master, and i had lua_api.txt open in a plain text editor, which didn't reload the file when it was modified by an external source (like git)
17:20 hmmmm sapier, it doesn't, it might make something more comfortable in the future however
17:21 hmmmm if we do have something that could use that
17:21 PilzAdam hmmmm, then get a proper text editor :-p
17:21 D-Man joined #minetest-dev
17:21 hmmmm asynchronous calls would probably too hard for most lua coders to understand, i fear
17:21 sapier I guess there won't ever be access to a lot of things from a async call
17:21 hmmmm for some reason, async baffles novices
17:21 sapier basicaly almost every data needs to be passed by argument or available per minetest api
17:22 D-Man :/
17:24 sapier but it could be used for jejias curl feature as well as worldedit(once propper map locking is established)
17:24 sapier maybe even for custom on_generated
17:24 hmmmm i wonder if worldedit would ever need this
17:25 hmmmm the only things that'd take a lot of time *in the core* would be blitting to and from the map
17:25 hmmmm not only is that a lot faster than you're giving it credit for, but it also requires that envlock
17:25 hmmmm which makes it useless
17:27 hmmmm anyway now i have to take a break from mapgen v7 and do the mapvoxelmanipulator really fast, or else people will get the wrong idea and start abusing schematics
17:27 PilzAdam people already do that...
17:28 Mallot1 humminah humminah
17:28 sapier pathfinder lua version had a mode wher it first fetched data then calculated path ... using a similar design would gain benefit ... but I'm not sure if there are lots of task that can be done this way
17:28 Mallot1 print("Hello" .. "World");
17:29 hmmmm Mallot1, probably a good idea to keep it in #minetest
17:29 Mallot1 lol
17:29 Mallot1 ooops wrong chat i have both open
17:29 Mallot1 *mallot1 is noobin
17:29 Mallot1 bye
17:31 hmmmm hm, pilzadam, http://forum.minetest.net/viewtopic.php?id=6225  sounds like many of his data files are being corrupted by some sort of malware or virus
17:31 hmmmm like one of those things where it'd infect .exes by appending a hook into the entry point
17:34 hmmmm or what if he has bad ram
17:35 kaeza joined #minetest-dev
17:36 Exio if he had bad ram windows would throw a BSOD, i guess?
17:37 hmmmm would it really?  the boot process is quite predictable because it's the first thing that happens
17:37 hmmmm it's totally possible for kernel mode things to be unaffected simply because they're never in the physical address range where the corruption occurs
17:37 sapier exio no badram may result in random application crashes only
17:38 Exio the last time i had a bad ram + windows, it randomly crashed and threw a BSOD
17:38 hmmmm he might want to try out my BadRAM for Windows(tm)
17:38 hmmmm :D
17:38 hmmmm just kidding, i wouldn't ever recommend people to use that
17:38 Exio haha
17:38 sapier I'm on a pc with some bad ram took me half a year to realize source of random crashes was a memory error ... I appreciate linux bad ram avoidance feature :-)
17:39 Exio linux crashes less with that
17:42 D-Man joined #minetest-dev
17:56 neko259 joined #minetest-dev
18:00 diemartin joined #minetest-dev
18:05 Nekofire is any body active in themod chats
18:11 kaeza Nekofire, if it's not engine related, it's best to post it in #minetest
18:53 kahrl one of my machines developed bad ram recently, it first manifested in grsec detecting a stack smashing attack in python
18:54 kahrl then random application crashes and system freezes
18:54 sapier the more ram you have the less the problems you experience
18:55 kahrl it appears it wasn't really the ram that was faulty but something on the bus or chipset
18:55 kahrl because it happened with either of the two ram sticks
18:55 sapier wow a very rare error
18:58 sapier oops :-) I just realized I've forgotten to add the most important files to the async branch :-)
19:01 ffoxin joined #minetest-dev
19:31 kaeza sapier, would that bring any performance benefits when using it instead of e.g. Lua coroutines?
19:32 sapier yes coroutines do not run parallel while async calls run i own thread
19:32 kaeza ah ok
19:32 sapier ok "yes" is only true for multicore processors
19:32 sapier but it's bought by quite limited data exchange
19:33 kaeza does that create a new lua_State? IIRC Lua is not friends with multithreading
19:34 sapier so if you have really long run tasks , e.g. downloads, complex calculations, map modifications this might help
19:34 sapier exactly the new lua_State is cause for limited data exchange
19:34 kaeza a gotcha
19:34 kaeza ah*
19:35 kahrl map modifications? how are locks handled? (might have missed it)
19:35 PilzAdam sapier, see #minetest, people dont like falling nodes colliding with objects
19:36 sapier I have said what I wanted to say to this It's your turn to decide what you do PilzAdam
19:37 sapier kahrl that's a todo for this changes it's only prototype atm ... but map modifications is one of main use cases
19:37 celeron55 i say don't add asynchronous modification of maps
19:38 celeron55 i don't know the details of what you have though, is there a description somewhere?
19:38 sapier no it's very early prototyping
19:38 hmmmm just read the channel logs from this morning, it'll explain everything you need to know
19:39 celeron55 ---- description follows (sapier writes it now) ----
19:39 sapier basicaly (one or multiple) separate lua thread running in parallel
19:39 sapier celeron55 I've never seen description beeing implemented ;-)
19:39 celeron55 what can the threads access and by what means?
19:40 sapier any data not beeing part of main luaengine basicaly minetest api only
19:40 sapier or data explicitly passed to it
19:40 celeron55 any of minetest api?
19:41 celeron55 so how does it handle two threads reading and modifying the same nodes at the same time?
19:41 sapier not exactly there are minetest api calls using lua stack too those wont work too
19:42 celeron55 that isn't valid english
19:42 sapier some minetest api calls access lua stack from within c code
19:42 sapier e.g. auth functions
19:43 sapier accessing those would result in readding impicit synchronisation to main thread
19:43 hmmmm [03:41 PM] <celeron55> so how does it handle two threads reading and modifying the same nodes at the same time?     <-- the idea of these async calls is to carry out complex computations that don't involve env/conlock
19:44 celeron55 so they have a limited api?
19:44 sapier yes extremely limited
19:44 celeron55 i mean, VERY limited
19:44 hmmmm the async call framework is only for new api
19:44 celeron55 where's it listed and who is going to make sure nobody starts messing with it?
19:45 sapier it's not even decided if this is a suitable way celeron55 it's just for discussion atm
19:46 hmmmm sapier, did you profile the API with the three locking schemes, like it is now/unlock when not needed/lock only when needed ?
19:46 celeron55 what problem does it solve? was this answered already?
19:46 sapier atm it only solves curl api
19:47 sapier without further changes no other problems are fixed
19:48 sapier hmmmm it's difficult to profile as I don't have a suiteable testcase
19:48 hmmmm typical mods
19:49 hmmmm grab the top 10 most popular mods and try them all with each
19:49 kahrl locking only on each api call that needs it is not enough
19:49 celeron55 do you guys know you could just use lua coroutines and add api functions that will automatically yield() when they are waiting for i/o?
19:49 sapier no it doesn celeron
19:49 hmmmm ??? kahrl, why?
19:49 kahrl you need to be able to lock groups of calls
19:49 celeron55 i think that is possible, but i'm not exactly sure
19:49 celeron55 sapier: why?
19:49 sapier lua coroutines don't have any concurrency
19:50 celeron55 you don't need actual concurrency
19:50 kahrl sapier: minetest.get_node(pos) --> decision in lua depending on result of that ---> minetest.set_node(pos, newnode)
19:50 celeron55 it just needs to look like that from lua side
19:50 sapier it's manual preemption you can't even yield on io
19:50 kahrl if it unlocks between get_node and set_node the decision might rely on data that is now invalid
19:50 hmmmm oh, that's true, good point..
19:50 celeron55 sapier: the coroutines would be put in a table where the engine would resume them periodically
19:51 sapier kahrl that's not a problem
19:51 kahrl sapier: why not?
19:51 hmmmm celeron said he tried that already
19:51 hmmmm (that is, lock only when needed)
19:51 hmmmm didn't think of the case of a get and set node right after
19:51 sapier you can't avoid it either
19:52 sapier celeron55 but what problem would this fix?
19:52 celeron55 sapier: the same thing: you could do asynchronous curl operations in lua
19:52 celeron55 (with code that isn't all spread around)
19:52 sapier celeron55 only if the curl operations are non blocking
19:53 celeron55 the curl C interface has a good non-blocking API if that's needed
19:53 celeron55 it's not a reasoning for anything
19:54 sapier ok so curl is no usecase
19:54 celeron55 hmmmm: what i have said is that one of the early versions of MT had a lock that locked on each node access
19:54 sapier so only longrun lua calculations are left
19:54 hmmmm celeron, yeah, and kahrl said that wouldn't work anyway
19:54 hmmmm you mentioned that you didn't stick with that because of performance reasons
19:55 celeron55 really there's no good reason to even do any coroutine stuff for curl, becasue there could be just some start_curl(callback) thing that would use the asynchronous api in the background
19:55 celeron55 but whatever
19:55 hmmmm how is curl used in lua right now?
19:55 celeron55 hmmmm: mutexes are too slow for that
19:55 sapier hmmmm it's an open pull request
19:55 hmmmm oh.  i thought it invoked an external utility.
19:56 sapier I don't know I expected it to use curl lib as it's already linked
19:56 hmmmm lots of people do dumb things which is why i didn't leave out the possibility
19:56 hmmmm and since the asynchronous api isn't being used, that's the only rational explanation i would have why
19:57 hmmmm the only remaining possibility is that the person who added the curl api in the lua api using the lib directly didn't know how or didn't care to use the async functions
19:57 sapier hmmmm sorry didn't get it explanation for what?
19:58 celeron55 hmmmm: minetest has some internal utilities for starting threads that operate curl in a blocking way
19:58 celeron55 it's probably based on that (haven't looked)
19:58 hmmmm that's pretty stupid
19:58 hmmmm ugh
19:58 hmmmm i wish people knew how to properly use the tools they're working with
19:58 celeron55 well it really doesn't matter for what's in currently
19:58 celeron55 but for the lua thing it does
19:59 celeron55 ...or actually not even for that
19:59 Mallot1 was minetest made in voxel3d?
19:59 hmmmm sapier, why the curl api in the pull request isn't asynchronous at present
19:59 celeron55 where is the pull request in the first place? 8)
20:00 kaeza Mallot1, minetest was made with MegaZeux
20:00 sapier It's from jeija and about 6 months old
20:02 sapier ok so async api isn't way to go unless someone wants to add lots of calculations in lua
20:02 hmmmm anyway
20:03 kahrl hmmmm: small bug in the schematic doc in lua_api.txt: in line 1953 the node tables should using name, param1, param2 keys instead of 1,2,3
20:03 hmmmm the main reason why we brought up the entire thing about locking in lua is because of people needing to do heavy computations in lua
20:04 sapier that can be done with async ... but seems to be the only thing it's suitable
20:04 hmmmm oh whoops
20:04 hmmmm i'll fix it up with the random fix patch
20:06 hmmmm anyway i'll be sure to take more care with lua_api.txt when rebasing my branch
20:06 kahrl huh, I placed a 50x1x50 structure with minetest.place_structure and one corner mapblock didn't get updated
20:06 hmmmm didn't get updated, or didn't get written to?
20:07 hmmmm did you try logging out and logging back in
20:07 kahrl didn't get written to (it still isn't there after restarting)
20:07 hmmmm </indian tech support voice>
20:07 hmmmm i guess you were up against a boundary, and i did something wrong with what i had to emerge?
20:08 hmmmm +  v3s16 bp2 = getNodeBlockPos(p + size - v3s16(1,1,1));
20:08 sapier1 joined #minetest-dev
20:09 hmmmm if size was 1,1,1, i'd need to emerge an area from p1 = p2 inclusively
20:09 hmmmm so that subtraction is correct
20:10 kahrl can't see anything useful in debug.txt even with debug_log_level = 4
20:10 hmmmm vm->just one block is missing?
20:12 kahrl the block from (48,16,2064) to (63,31,2079) wasn't written to
20:12 hmmmm initialEmerge uses inclusive coordinates too so that's not the problem
20:13 hmmmm and it's the z coordinate
20:13 hmmmm you placed this using placeDecoration, just to make sure, right?
20:13 hmmmm placeStructure rather
20:13 kahrl the structure was placed at 2028,21,48
20:14 kahrl well minetest.place_schematic
20:14 hmmmm that yeah
20:15 kahrl http://paste.dy.fi/anM <-- that's the code
20:16 kahrl 22:04:34: ACTION[ServerThread]: singleplayer uses sandjoy:sandjoy, pointing at [node under=2053,21,73 above=2053,22,73]
20:16 hmmmm stumped
20:17 hmmmm er.. do you get that problem if you remove the - v3s16(1,1,1) from mapgen.cpp:583?
20:17 sapier1 why don't we have a jsemaphore?
20:18 kahrl hmmmm: let me first see if I can reproduce the problem
20:19 tango_ joined #minetest-dev
20:22 sapier1 hmmmm if you want to do numbercrunching the current (and atm final version) supports multiple parallel lua async calls
20:23 kahrl doesn't seem like it wants to happen again (didn't change mapgen.cpp yet)
20:24 hmmmm hmmm odd... if it happens again, i bet what i pointed out was the problem
20:24 hmmmm if anything is, that's what the problem would be
20:24 kahrl I tried the exact same spot though
20:25 hmmmm hahaha, what if the rand() had a hiccup and it just so happened that all those nodes in that spot didn't show up
20:25 hmmmm that would be funny
20:25 kahrl hehe
20:26 kahrl <killjoy>anything but the outer edge is param1=0 though</killjoy> :P
20:26 hmmmm i'm pretty sure that the correct coordinate of the blockpos to emerge is p + size - v3s16(1,1,1) .... it only makes sense.  it made sense to me while i was writing it and it makes sense now
20:26 hmmmm but it doesn't hurt to over-emerge either
20:26 hmmmm so i might remove that bit
20:28 kahrl maybe something (mapgen?) was still working on that block and replaced it after the place_schematic was done?
20:28 hmmmm ahh
20:28 kahrl (I think the formula in mapgen.cpp:583 is correct)
20:28 hmmmm it's possible and it would make sense
20:31 kahrl I was able to reproduce it by running into a new area
20:31 mrtux joined #minetest-dev
20:31 kahrl if it's the mapgen it's hard to reproduce because mapgen is so fast ;)
20:31 hmmmm ehehe
20:31 hmmmm that's being called on_generate?
20:32 kahrl this time it didn't happen at the edge: http://imgur.com/6pKCqFM
20:32 kahrl *corner
20:32 kahrl it happened at the edge but not the corner
20:32 hmmmm i'm sure i'll figure it out eventually
20:33 kahrl called in on_use, my updated code: http://paste.dy.fi/aO0
20:39 kahrl oh hold on
20:39 kahrl this time is was actually written but not sent to the client
20:39 kahrl it*
20:44 hmmmm the block update code should be solid
20:53 mrtux joined #minetest-dev
20:55 diemartin joined #minetest-dev
20:57 kahrl is there a way to set some nodes placed with place_schematic to probability zero?
20:59 kahrl since it doesn't skip air and ignore like the version called during mapgen does
21:00 kahrl wait a sec... if (c != CONTENT_AIR && c != CONTENT_IGNORE) continue;  <-- does that mean the mapgen version only placed air and ignore?
21:00 kahrl places*
21:01 kahrl or am I just dumb now
21:01 kahrl oh wait, that's not the schematic but the map data
21:02 hmmmm right
21:02 hmmmm don't want to replace things that were already placed
21:02 kahrl makes sense
21:02 hmmmm <kahrl> is there a way to set some nodes placed with place_schematic to probability zero?   <---- well, nope, but that's probably a good idea
21:03 hmmmm i'll add that in a later commit
21:03 kahrl perhaps: if (schematic[i] == CONTENT_IGNORE) continue;
21:03 hmmmm mmm =/  how is content ignore going to get into the schematic
21:03 hmmmm it's a better idea to just have a zero probability
21:04 kahrl yeah probably
21:05 hmmmm i guess, what i could do is set aside an additional probabilility value like -1, and that would mean "node is never written to"
21:05 kahrl just change myrand_range(1, 256) to myrand_range(2, 256)
21:05 hmmmm in applyProbabilities i'd set the content to CONTENT_IGNORE
21:06 hmmmm that would avoid reducing the range of possible probabilities, and avoid changing the meaning of "0 probability"
21:06 kahrl how would you set param1 to -1?
21:06 hmmmm i don't ever do that
21:07 hmmmm i check for -1 in applyProbabilities, never actually set param1 to that
21:07 hmmmm and if it's set raw, then i can just have them add in content ignore as the actual content
21:07 kahrl oh you mean when you generate a schematic with minetest.create_schematic
21:07 hmmmm yeah
21:07 kahrl that makes sense
21:07 hmmmm that's probably the best way to do this
21:09 sapier1 is there any chance to get chunk/block granular map locking?
21:09 hmmmm yep, by making the map container sectors are held in atomic
21:09 hmmmm err
21:10 hmmmm misread
21:10 hmmmm let's have a set that contains blocks that are in use
21:10 hmmmm reading/writing to this set needs a lock of course
21:10 sapier1 maybe my sentence wasn't cler enough is map datastructure designe suited for locks at that level?
21:11 hmmmm that would be a really lot of locks if you do it that way
21:11 hmmmm it's just not plausible
21:12 kahrl it could certainly be done but the performance would likely be abysmal
21:12 sapier1 I thought more in direction of metainformation "in_use" with access to that information is locked
21:12 hmmmm so we have our own mapblockref function that checks to see if the block you want to grab is in use; it locks the mapblock set lock, checks to see, unlocks that, if it is in use, then it should wait until there's a mapblock free event somewhere and then check again (??)
21:12 kahrl if it's just a flag then a lockfree algorithm could be used I guess
21:13 hmmmm lol
21:13 hmmmm i checked out how big a bitmap of all possible blocks would be
21:13 hmmmm that's not plausible, we'd need to use a data structure
21:13 sapier1 not node granular of course
21:13 hmmmm it's probably best to roll our own then
21:14 kahrl do unloaded blocks need to be locked? otherwise you could just add a flag or lock in class MapBlock
21:15 hmmmm the flag would need to be atomic
21:15 hmmmm and what happens if it's already in use?  it'd have to wait
21:15 hmmmm which is basically..... the definition of a lock
21:15 kahrl yeah
21:16 sapier1 the flag would be just to avoid thousands of locks
21:16 hmmmm and having a lock for every single mapblock like i said, that's probably not going to work.  i mean, it seems like an obvious solution, but i have my doubts
21:16 sapier1 another completely different aproach what about transactions?
21:16 kahrl then with that many locks without any strategy to sort them there's a real danger of deadlocks
21:16 hmmmm transactions?
21:17 hmmmm you mean like, just atomic writes to mapblocks for everything?
21:17 sapier1 changes not beeing executed at once but only on commit if someone else changed anything that is required for that transaction it's not going to be executed and has to be done again
21:17 sapier1 in common case no conflicts will occur
21:18 sapier1 of course in conflict case overhead is big
21:18 kahrl guess that's something that needs to be done if RCU for mapblocks is added
21:18 hmmmm yeah, but wouldn't that make it not updated as soon as it's modified?
21:18 hmmmm right, RCU is basically the next step
21:18 hmmmm i considered all these things a while back and that's basically what i decided
21:19 sapier1 yes but rcu wouldn't fix changes depending on some map state
21:19 sapier1 e.g. if mapnode == ? then set some other node
21:19 kahrl how would you implement transactions without rcu?
21:20 sapier1 with transactions you could call start transaction mark all nodes you checked as relevant and if anythin is wrong restart
21:20 sapier1 capture set_node calls storing in transaction data
21:20 sapier1 add a counter to map that is updated at each real modification to speedup changes, if counter hasn't changed since start_transaction no check is required at all
21:22 sapier1 but I don't know map structure well ... so my thoughts might be completely wrong
21:22 kahrl the counter will become useless once you have installed enough mods that do async map updates in transactions
21:23 kahrl if lets say something in on_generate is done that way
21:23 sapier1 why? mods don't run in paralell regularly
21:23 kahrl they don't run in parallel at all now :P
21:23 sapier1 they never will
21:24 sapier1 lua is just not capable of running parallel tasks
21:24 kahrl hmm? I thought that was the entire purpose of this along with the async calls
21:24 sapier1 it won't runn the whole mod in parallel
21:25 sapier1 and yes with async it can happen without it the counter isn't even usefull at all
21:25 sapier1 I thought async api is burried due to lack of real usecases?
21:25 sapier1 at least for the moment
21:28 hmmmm https://github.com/minetest/minetest/commit/4d77781ce7cba571701e731b1f442af691933720
21:31 hmmmm not sure how RCU wouldn't cover that problem
21:31 hmmmm it's used almost exactly like a regular lock
21:32 hmmmm once you 'lock' the block, you'll be reading from the version of the mapblock you locked it the whole while until you unlock it
21:32 sapier what would be benefits of rcu in that case?
21:32 hmmmm it's after you 'unlock' it, that it'll delete the version of the mapblock you were using
21:33 hmmmm multiple readers and writers doing things at the same time without screwing stuff up
21:33 sapier ok so on lock a copy is created?
21:33 hmmmm well
21:33 sapier more precise on second lock
21:34 hmmmm right
21:34 sapier third ...
21:34 sapier but that'd require transactions per definition
21:34 sapier e.g. if second unlocks changes need to be commited
21:35 hmmmm yeah, the whole thing each reader and writer gets their own version to screw around with, and a transaction is done where all the changes are comitted once that lock is given up
21:35 hmmmm yeah
21:35 sapier so to sumarize
21:36 sapier start_transaction does only create an administration structure
21:36 hmmmm iirc, to preserve the order, it'd save the second copy for changes until the first lock is done
21:36 hmmmm commits the first set of changes, then commits the second changes
21:36 sapier on first access from within a transaction (read or write) the block is locked
21:36 sapier on transaction_commit the changes are saved
21:37 sapier if someone commits while other transactions are running changes need to be merged ore commit fails
21:37 PilzAdam anyone objects: https://github.com/PilzAdam/minetest/commit/b23d20e8ba799c60a132a7a40908fecc596f74b9 ?
21:37 hmmmm pilzadam, seems good
21:37 sapier pilzadam me too
21:37 hmmmm sapier, yeah, that commit is saved until older locks are finished
21:38 sapier within a transaction any read or write of a block marks this block as relevant for merge
21:38 proller why player ip not in logs on connect?
21:38 sapier no hmmmm that's wrong if you do it that way the changes of this commit may be based on invalid mapdata
21:38 PilzAdam proller, the IP is in the logs AFAIK
21:39 PilzAdam infostream IIRC
21:39 hmmmm how so?  everybody would get their own version of how the mapblock looked *at that time*
21:40 proller PilzAdam, 00:32:36: ACTION[ServerThread]: Guest4456 joins game. List of players: Guest4456
21:40 hmmmm that's infostream
21:40 sapier hmmmm yes and that's exactly the problem
21:40 PilzAdam proller, look at the infostream output arround this
21:40 hmmmm that's not infostream*
21:40 sapier if e.g. second one checked node(1,1,1) for water
21:40 PilzAdam proller, you need debug_log_level >= 3 for this
21:40 hmmmm oh that's true
21:40 proller 8(
21:40 sapier to do something to block 1,1,2
21:40 hmmmm right right, i get it
21:41 hmmmm rcu must do something different from what i thought
21:41 proller PilzAdam, i think it must be in like:   Guest4456 [ip.here] joins game.
21:41 PilzAdam proller, yea, could be useful
21:42 iqualfragile_ joined #minetest-dev
21:42 proller enabling verbose log could be late
21:43 sapier hmmmm the transactions would fix it but of course anyone using it has to expect a transaction to fail and handle that case
21:43 PilzAdam proller, I agree on changing it
21:43 hmmmm right
21:44 hmmmm but there aren't too many people using this
21:44 hmmmm only the primitive mapblock access functions in map.cpp
21:44 sapier true
21:45 PilzAdam it was announced that common mod support will be dropped after 0.4.7 -> https://github.com/PilzAdam/minetest/commit/c4d22d6e666c89658434b9636519560e956473e8
21:46 ShadowNinja proller: With my function you can write mod to do that.
21:47 proller ShadowNinja, its must be in core by default
21:47 PilzAdam proller, minetest.get_player_ip(name) is in 0.4.7
21:49 ShadowNinja IMO player names should be case-insensitive. But case should be preserved, like IRC.
21:51 proller +1
21:51 proller and maybe more agressive preserve like 0 -> O  1->l , ....
22:04 PilzAdam any comments on the common drop?
22:28 Anchakor left #minetest-dev
22:28 Anchakor joined #minetest-dev
23:08 sapier left #minetest-dev
23:20 Mallot1 what common drop?
23:20 Mallot1 i was sleeping
23:21 kahrl PilzAdam: I thought GetDirListing already excluded files starting with ".", but apparently that is only the case on POSIX
23:22 PilzAdam kahrl, a windows user requested this
23:22 PilzAdam there is a similiar workaround for something else (mods?)
23:22 kahrl imho GetDirListing should behave the same everywhere
23:22 kahrl I might have made a bad assumption somewhere in the path code I wrote that sapier included in next_gen_main_menu
23:23 kahrl because of that
23:23 VanessaE joined #minetest-dev
23:23 PilzAdam mods.cpp:103
23:23 VanessaE I asked if anyone plans to fix the 4096-node limig.  Pilzadam suggested:  <PilzAdam> VanessaE, src/mapnoge.h:38 increase MAX_CONTENT and see what happens
23:24 VanessaE I changed it to fffd and deployed to my server.
23:24 VanessaE it works fine.
23:24 PilzAdam *mapnode.h
23:24 VanessaE er yeah.
23:24 VanessaE anyway, if someone else could test that or comment, and push that one-character change to master, I'd appreciate it, as old clients can't connect to a server that's been so-modified
23:25 VanessaE (push, unless it presents a problem)
23:25 PilzAdam *only if it has more items registered than the former limit
23:25 VanessaE right.
23:29 kaeza joined #minetest-dev
23:32 Mallot1 i think the game needs asoundtrack
23:42 hmmmm woah woah whoa
23:42 hmmmm you're changing MAX_CONTENT?
23:42 hmmmm hold on a minute there
23:42 hmmmm first of all in order to do that we'd need to change it from a statically sized array to a vector
23:42 hmmmm and then you also need to fix node id mapping serialization
23:43 hmmmm it's not a one liner fix
23:49 Taoki joined #minetest-dev
23:57 Tesseract joined #minetest-dev

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