Time Nick Message 06:38 nore is anyone here? I have 2 suggestions 06:50 VanessaE make your suggestions anyway, if only for the log. 06:52 nore those are already in #minetest... 06:54 VanessaE some folks are in here that aren't in #minetest 07:02 nore so those suggestions are minetest.swap_node (instead of using haky_swap_nodes, which causes formspec problems on the client) 07:02 nore and minetest.get_loaded_blocks, minetest.register_on_block_load, minetest.register_on_block_unload 07:03 sfan5 get_loaded_blocks returns something like {{x=-2, y=1, z=2}, {x=-1, y=1, z=1}} ? 07:04 nore yes, that could be good 07:05 nore on perhaps minp,maxp 07:05 sfan5 minetest.register_on_block(un)?load is called with (blockpos) ? 07:05 sfan5 s/(blockpos)/func/(blockpos)/ 07:05 sfan5 woops 07:05 sfan5 s/(blockpos)/func(blockpos)/ 07:06 sfan5 we don't need minp or maxp 07:06 nore yes, it should be ok 07:08 sfan5 it would just be "minp = vector.new(blockpos) * 16; maxp = minp + 16" for minp and maxp 07:10 sfan5 hm 07:11 sfan5 minp, maxp would actually be better for both functions 07:11 sfan5 mods shouldn't depends on BLOCK_SIZE being 16 07:13 nore yes, that's why I thought minp, maxp would be better 07:14 nore about what about a minetest.swap_node that would avoid hacky_swap_node, which is, as its name says, hacky 07:17 celeron55 we don't expose blocks to mods 07:17 celeron55 so it would be get_loaded_positions() that returns a list of {minp, maxp} pairs or something 07:19 celeron55 i think swap_node could exist, but someone needs to see if there are problems in such 08:13 nore and another suggestion: one more parameter to ABM that would be "time_since_last_executed" 08:44 proller nore, updated 08:44 nore thanks 09:50 sfan5 I've got a table way of representing formspecs now that works and supports all features of the current formspecs: http://sfan5.duckdns.org/minetest-formspec-luatable.txt 10:32 proller sfan5, cool 10:37 proller sfan5, then make searialize in json, and using json struct in c++ -> much less code 10:37 sfan5 no 10:38 VanessaE proller: please don't go lamefun on us :P 10:40 sfan5 it is intended to be a lua side things 10:40 sfan5 -s 10:41 sfan5 because its confusing which field in dropdown[1,2;3,5;abc;def;foo,bar,foo;2] is which 10:46 proller its must be key-value 10:47 proller idea here - http://dev.minetest.net/Formspec_json 12:09 thexyz objections? https://gist.github.com/xyzz/2bf7e9144b2f76599996 12:10 sfan5 I don't think you need to ask to commit that :P 12:11 PilzAdam thexyz, seems good 12:12 thexyz sfan5: PA could get angry 18:05 celeron55 >I don't think you need to ask to commit that 18:05 celeron55 one doesn't need to ask, but notifying a reasonable time before pushing is always right 18:07 nore I have something that is more-or-less a bug report 18:08 sfan5 any new opinions on using lua tables for formspecs but keeping the string format internally? 18:08 nore if I am correct, inv:remove_item called with stack count>stack max will only remove stack_max items, even if there are enough items 18:09 nore when I say more-or-less bug report, it is because it is perhaps normal 18:09 PilzAdam sfan5, just add minetest.table_to_formspec({...}) 18:09 celeron55 nore: sounds like a bug 18:10 celeron55 nore: altough... yes, it's kind of arguable, because it'd need to return an itemstack that is too large 8) 18:11 nore that causes a bug with pipeworks :( 18:11 celeron55 but my opinion is that changing it would make it less clumsy as an interface which is how interfaces should work 18:12 nore because I use it to remove a number of items from an inventory, but I don't care about the returned stack 18:19 proller https://github.com/minetest/minetest/pull/895 https://github.com/minetest/minetest/pull/892 https://github.com/minetest/minetest/pull/883 18:19 proller https://github.com/minetest/minetest/pull/882 18:20 proller celeron55, btw, 2 weeks of asking agree - reasonable time ? 18:24 celeron55 well what can i say? it doesn't matter 8) 18:28 celeron55 if nobody is interested, there are exactly three options: 1) talk enough to get them interested (posting links is not talking); 2) give up; 3) code more to have a more impressive bunch of stuff 18:29 nore celeron55, I use the first option with my pulls... 18:30 celeron55 i recommend the first option :P 18:31 nore btw, what do you thinkof #688? 18:31 nore It adds a tool callback instead of wearing the tool out 18:32 nore if the callback is defined for that tool 18:57 celeron55 nore: i guess it's good 18:57 celeron55 i wonder though what the action should be if it returns nil 18:57 celeron55 an another one that would make sense would be to normally wear the tool in that case 18:57 nore it does not wear the tool if it returns nil 18:58 celeron55 so that if someone wants to eg. add a particle effect or something else like that not related to the wear, he doesn't need to take care about wear 18:58 celeron55 or is there some reasoning against this 18:59 nore the digparams is given to the callback, and PilzAdam said that to be compatible to the other api calls, we should not change the stack if return is nil 19:00 kahrl nore: doc/lua_api.txt:1953 -- shouldn't this line have 'if not minetest.setting_getbool("creative_mode")' around it? 19:00 celeron55 nore: well that isn't really related to whether to wear it or not in case of nil? 19:00 nore idk 19:01 celeron55 PilzAdam: ^ 19:02 nore but if you want, I can change it, it is a 30-second change 19:03 nore kahrl, yes, you're right, the pull was before that... 19:04 celeron55 nore: i want PilzAdam to consider it 19:04 PilzAdam its a matter of documentation 19:04 celeron55 PilzAdam: it's also a matter of having sane defaults 19:04 PilzAdam currently there is "should wear out tool", so it shouldnt wear it out if its nil 19:05 celeron55 defaults should never surprise even if documentation isn't read properly 19:05 PilzAdam I wonder if we should rather use minetest.after_place() and set that as default in the nodedef 19:05 sfan5 PilzAdam: thats not how it should be, tables should be used as replacement for text formspec 19:06 nore so, do you want me to change that, or not? 19:06 PilzAdam this "if not minetest.setting_getbool("creative_mode") then" seems a bit wrong to me, it should be done by the game, not the engine 19:07 PilzAdam the engine doesnt change anything else if creative_mode is on 19:07 nore yes it does: minetest.item_place 19:08 PilzAdam nore, I dont see anything else than the wearing out of the tool being different in creative_mode 19:08 PilzAdam if we would add minetest.after_use(), then creative could override it to handle the creative_mode 19:09 nore aren't the infinite items in builtin? 19:09 PilzAdam nope 19:09 kahrl btw, should it be called after_dig? 19:09 kahrl otherwise I'd think it has to do with on_use 19:10 nore so, a per-tool callback, + a global callback? 19:11 nore kahrl: it has, since it is same as on_use, but after the node has been dug 19:11 kahrl but if you define on_use the item can't dig at all 19:12 nore yes, and that's why I added this callback... 19:13 proller ok.. https://github.com/minetest/minetest/pull/883/files - small change, fixes unreal temps, want to commit 19:14 kahrl proller, why hardcode these noiseparams values? 19:16 proller they in m_emerge->biomedef->np_heat in ugly 50 +-50 format now, better to change it and get ftom them 19:16 proller but hmmmm doesnt allow to touch 19:17 proller in this function not noiseparams, its just normalize to reasonable values 19:20 kahrl what about mods that use minetest.get_heat/minetest.get_humidity? (are there any?) 19:20 kahrl would they have to change? 19:21 hmmmm no, it's the biome definitions 19:21 hmmmm i know pilztest uses them at least 19:21 sapier heat/humidity haven't been in any stable version by now (as far as I know) 19:21 proller no, values was good, but sometimes can increase to like 90c 19:21 hmmmm they *have*, but, they really weren't doing anything much except selecting biomes for essentially what is an experimental mapgen 19:22 hmmmm alright 19:22 hmmmm i promise i'm going to fix that up tonight 19:23 hmmmm proller, i'll give the values you normalized the heat/humidity to some consideration, but i'm looking for some properties in particular with the heat/humidity gradients 19:24 hmmmm like for one i'm probably going to add more octaves to them and increase the scale 19:25 proller i can commit my patch now, and fix after your 19:26 proller and want make HELL in last 1000: 19:26 proller if (p.Y < -30000) heat += 6000 * (1-((float)(p.Y - -31000)/1000)); //hot core 19:26 hmmmm lol 19:26 hmmmm yeah see.... there's no way i'd agree to hardcoding that 19:26 hmmmm remember i was talking about the realm idea 19:27 proller i can make configurable 19:27 hmmmm there would be a nether 'realm type' and a sky 'realm type' and whatever 19:27 hmmmm no, don't 19:27 hmmmm for now that's fine, it doesn't really matter 19:27 nore proller, you can make a lua function that will modify minetest.get_heat 19:27 hmmmm it's just that i'm gonna have to modify that at some point 19:27 hmmmm proller, give me a little while to look over your commits first 19:28 proller nore, no, cant, it used by core 19:28 nore then allow modifications ;) 19:28 nore the core should re-call lua 19:29 proller i think about it, like storing u16 heat_add in block, and allow modify it from lua 19:29 kahrl lua shouldn't know about mapblocks 19:30 hmmmm yes^ 19:30 hmmmm stop it with the block idea 19:30 proller it can access by x,y,z coord, like get_heat now 19:30 proller but store per block 19:31 hmmmm er, well whatever 19:31 hmmmm i see what you mean 19:31 hmmmm if you're going to do that, please name it heat_offset or something instead 19:32 proller ok 19:40 proller idea "hot core" was for making unreachable -31000 with melting stone 19:41 proller like anything melting and burning and you cant dig deeper 20:22 proller still want to commit https://github.com/minetest/minetest/pull/883/files before peoples start it using 20:23 proller tested 1/5 weeks on server 20:23 proller 1.5 20:33 hmmmm that one's fine 20:37 proller ok, commiting 20:37 proller other much harder