Time Nick Message 00:00 Exio4 hmmmm: ^ 00:44 hmmmm Exio4, that's what I was thinking, but I'd still need to maintain reverse compatibility somehow 00:46 sapier1 ok I guess I found a solution ... but it's quite ugly 00:46 Exio4 what i thought was "hardcoding" for some time the flat option = flat mapgen, and say that option is deprecated and remove that "compat" in two releases or so, adding a notice about how-to change the mapgen in a world, like when creative/survival games got removed 00:47 Exio4 when parsing options 00:47 Exio4 but i don't know how that could be done, didn't check that code 01:37 hmmmm Exio4, unlike sapier I'm not very big on those "WARNING WARNING DEPRECATED!" messages 01:40 sapier1 :-) yea I'm the only one that's why deprecated code stays in codebase forever ;-P 01:40 Exio4 i don't like useless code just for supporting old stuff 01:41 hmmmm I mean what I could do is hard code in some check for MG_FLAT and set the mapgen to flat 01:41 hmmmm but would that be encouraging people to do it either way? 01:41 sapier1 yes but you can't avoid that code for some time ... with those ugly warnings you force ppl to switch to new mechanism ... not very polite ... true 01:44 hmmmm the code that would need to be added for the 'kludge' is hardly anything 01:44 hmmmm like 3 lines.. which is why I think I should forego the warning and just offer another more intuitive way to do the same thing 01:45 sapier1 if you don't declare it deprecated you don't need a warning anyway ;-) 01:46 hmmmm right, but before talking about doing more stuff, i ought to finish up what I started working on 3 months ago 01:46 hmmmm ugh 01:46 Exio4 hehe 01:46 Exio4 irl stuff? :P 01:46 hmmmm no, mapgen menu parameter configuration 01:47 hmmmm I think I need to pause, more carefully determine what I am trying to accomplish with this, and *then* continue on rather than just coding some shit up and committing it 01:48 hmmmm also, I don't like to admit it, but that prestowhatever guy was on the right track in the sense that some higher quality noise should be added 01:49 hmmmm you notice it more with 3d I'd say 01:49 hmmmm prestidigitator 01:52 sapier1 does anyone have a problem with compilerswitches to make minetest compatible to different compilers? :-) 01:52 hmmmm sure, as long as it doesn't involve slipping in a change to -O0 for debug like I caught that one time 01:53 sapier1 so disabling unit tests won't be accepted too? ;-) 01:53 sapier1 quite useless to have those things in a DEBUG build ... 01:53 sapier1 crashes instantly 01:53 sapier1 maybe we should add something like Real_Debug 01:54 sapier1 you guys can't use a debugger for sure if you are fine with -O1 and unittests :-) 01:56 hmmmm what's wrong with unit tests 01:56 sapier1 they fail 01:57 hmmmm they do? 01:57 hmmmm i thought it was just that network related one that was fixed by increasing the delay 01:58 sapier1 doesn't seem to help if you run within debugger 01:58 hmmmm shrug 02:56 VanessaE https://github.com/minetest/minetest/pull/967 makes THIS possible --> http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_4157666916.png ~~ http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_4157907066.png ~~ http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_4157692488.png 02:56 VanessaE very straightforward to texture for - sun/moon need to be grayscale or close to it, and are tinted in realtime with a tone map, very similar to how MC does some of its in-world textures. 02:57 VanessaE (those screenshots show actual in-game imagery from HDX) 02:58 VanessaE \by default, the sun and moon are made to look about the same as they were before, most users probably won't notice the difference. 02:59 VanessaE Taoki: can you try that pull alongside your tinted fog patch? I'm curious how that'll look 02:59 VanessaE (it has been revised since your initial comment) 03:07 NakedFury this can hopefuly lead to using it with grass, leaves, water. 03:08 VanessaE possibly 03:08 VanessaE there was some talk about that yes 03:13 pitriss this new sun and moon should be more cubic:) 03:13 VanessaE they are by defult. 03:13 VanessaE default*( 03:14 VanessaE they look about the same as before. 03:14 VanessaE those ^^ screenshots just show what it looks like with a texture pack. 03:17 VanessaE that patch is purely client-side btw 03:18 sapier1 https://github.com/sapier/minetest/tree/fix_windows_i18n schould fix the localization issues added due to gettext usage from lua 07:36 nore what do you think of https://github.com/minetest/minetest/pull/966 ? 07:40 nore I have a suggestion for inventories too, that could fix many things 07:41 nore instead of storing the stack that is being moved in the inventory, store it somewhere 07:42 nore and when a player takes an item, store it there, when he puts it a chest, move the stack from there to the chest, etc. 07:43 kaeza nore, that would mean that e.g. if several on_craft are registered, each successive one is passed the "new" itemstack (in case one of them returns the itemstack) 07:43 kaeza is this intended? 07:43 nore yes, of course 07:44 nore so you can have a mod that checks for a player crafting something (e.g. achievements, etc) 07:44 nore and a craft that will give some random item 07:44 nore if they are registered in the correct order, the random item will trigger the craft thing 07:45 nore however, the objective for most callbacks is either a little modification of the crafted item 07:45 nore (i.e., add metadata) 07:45 nore or a modification of a carft grid (wear a tool, for example) 07:46 VanessaE moretrees coconuts + axe == coconut pieces + slightly worn axe 07:46 VanessaE (+ milk) 07:47 nore ^ that way, you can also make multiple-output recipes 07:48 kaeza hmm... not sure about it, but could be usable 07:48 kaeza let's see what modders come up with :P 07:49 nore I need another core dev to clearly agree... sapier it ok with it 08:20 nore about that: https://github.com/minetest/minetest/issues/944 08:20 nore bug causing item loss with inventories 08:20 nore I have a suggestion: 08:21 nore when the player selects an item, store it somewhere else instead of leaving it where it is 08:21 nore i.e.: the selected item should be an item stored in only one place, instead of having that "selected item" behaviour 08:57 nore RealBadAngel, do you agree with the new version of https://github.com/minetest/minetest/pull/966 ? 09:04 nore sapier, are you still ok for #966? 09:06 PilzAdam nore, do you really need to include inventory.h and inventorymanager.h in s_item.h? 09:06 nore yes, I need inventorylist and inventorylocation 09:07 PilzAdam clas InventoryList; class InventoryLocation; should work too 09:08 sapier nore you only need pointers to them not the content (that's what pilzadam says) 09:08 nore just writing that should work? 09:08 PilzAdam yea, and include the headers in s_item.cpp then 09:09 sapier if you do it the way pilzadam suggests cpp files including inventorymanager.h don't need to be rebuilt if inventory.h is changed 09:09 sapier what pa suggests is called forward declaration it works as long as you don't need to access any "subelement" of a pointer 09:09 nore wait, it uses inventorylist->getSize 09:10 nore and ->getItem 09:10 sapier ok then it wont work 09:10 PilzAdam yea, but not in th s_item.h 09:10 nore so, include the headers in the cpp 09:10 PilzAdam you only need to include it for s_item.cpp 09:10 sapier :-) I guess I should look at that file 09:10 nore and define dummy classes in the header 09:10 PilzAdam that would save us some compile time 09:11 sapier exactly nore if you don't actually need the members in the header do only use forward declarations in there and include the real headers in cpp files where you can't avoid using it 09:13 nore ok, done, it looks like it compiles correctly 09:14 sapier hmm does anyone have an idea why gettext initialization is done as inline function? 09:14 PilzAdam nore, "is should normally be the same as" 09:15 sapier I understand why the char conversion functions are inline but for init it seems like someone didn't want to add a cpp file 09:15 PilzAdam nore, the lua-api.txt part seems rather long, can you shorten it a bit? 09:17 nore PilzAdam, done 09:22 nore so, now is it ok for merging? 09:22 PilzAdam https://gist.github.com/PilzAdam/7179556 09:23 nore Should I change lua_api.txt with that? 09:23 nore (perhaps add a warning: do not assume that the crafting width is 3 too) 09:24 PilzAdam modified it a bit, reload 09:25 PilzAdam hm.. dunno if that warning is needed; it could go into the devwiki 09:26 nore pushed, with the warning (after all, it costs nothing to put it here) 09:28 PilzAdam I dont like to bloat lua-api.txt like this 09:30 nore are 6 lines bloating? 09:31 sapier due to size of lua-api.txt each additional line that isn't absolutely necessary has to be considered bloating ;-) 09:31 nore so, I remove those last 2 lines? 09:32 sapier just to throw this idea in again what about splitting lua-api.txt pa? ;-) 09:32 PilzAdam sapier, you would break my way of using it by this 09:32 sapier e.g. map related, object/entity related, generic 09:32 PilzAdam because Ctrl+F wouldnt work anymore 09:33 sapier I know but it does only work if you already know what your looking for either 09:33 nore PA: removed those lines 09:34 sapier and it'd be easy to concatenate thos splitted files withing build so a lua-api.txt full file is built for those actling like you ;-) 09:34 nore PilzAdam, no need for Ctrl+F, grep -R works well 09:50 nore so, will it be merged? 09:53 sapier Mingw32 Build: http://a.pomf.se/f20eh.7z 09:53 sapier MSVC Build: http://a.pomf.se/cf2ds.7z 09:53 sapier hope I didn' forget a dll this time ;-) 09:59 RealBadAngel anybody has an opinion on https://github.com/minetest/minetest/pull/967 ? 10:01 nore RealBadAngel, it looks good, but I'd like a Lua function that can change the textures for a player only 10:02 RealBadAngel this is meant for texture packs 10:02 nore or perhaps even best: add more objects for a player (i.e. 2 suns, etc) 10:02 nore yes, I know 10:03 nore perhaps as a separate pull request, then 10:03 nore RBA, do you still agree on #966? 10:03 RealBadAngel such thing could as you suggesting could be made with api c55 is coding 10:04 nore not yet (IIRC, the sky doesn't move, does it?) 10:04 RealBadAngel but core of my change will remain intact, with api you could just change texture names or add another instances 10:05 sapier what api celeron is coding are you talking about rba? 10:05 RealBadAngel #960 10:06 sapier ahh :-) 10:06 nore sapier, RBA, can #966 be merged? 10:07 nore (if you both agree, that makes 2 core devs, doesn't it?) 10:07 sapier I'm not the one to ask nore ;-) 10:07 nore why? 10:07 nore what do you mean? 10:07 sapier I'm not a core dev ;) 10:08 nore I thought you were... :( 10:08 nore so I will have to ask someone else 10:08 sapier rba and pa are as far as I know ;) 10:08 nore PilzAdam, are you ok with it? 10:09 RealBadAngel i havent checked the code, so i cant say if its rdy to merge. but i agree on that it is needed for many cases 10:09 PilzAdam someone still needs to test it 10:10 RealBadAngel if some1 will check codestyle i can write a mod to test it 10:10 RealBadAngel i have in mind a few ideas 10:11 PilzAdam its ok to merge if it works 10:11 RealBadAngel so i will write simple mod with a tool wearing out after crafting 10:11 RealBadAngel saw to cut block into slabs 10:12 nore PilzAdam, https://gist.github.com/Novatux/7179966 10:12 nore to test 10:12 nore (very basic) 10:12 nore what it checks is that all parameters are really what they should be 10:13 nore and that the itemstack returned is correctly changed 10:15 sapier It's not really important but shouldn't it be "// do the callback" instead of "// make the callback" .. any natives in here? ;-) 10:15 nore not be 10:15 nore s/be/me 10:16 nore and anyway, anyone can understand that 10:16 sapier if you need to do other changes too I suggest removing that comment completely 10:16 RealBadAngel is the callback registered for just itemstack? 10:16 nore what do you mean, for just itemstack? 10:16 PilzAdam there is a bug 10:16 nore PilzAdam, what? 10:17 RealBadAngel i mean what about multiple recipes to craft an item 10:17 nore RealBadAngel, the callback is global 10:17 RealBadAngel will the callback be called in every case? 10:17 PilzAdam return ItemStack("default:wood"); <- this is not stackable, that means it doesnt matter how often you click, you only get one wood in your "hand" 10:17 nore PilzAdam, that is normal 10:17 PilzAdam so you basically lose the recipe 10:17 PilzAdam I consider this a bug 10:18 nore because you try to pick an item in the "craftresult" that is not the same as the one you're holding 10:18 nore however, if you're crafting wood, you will see that you should be able to craft 10:18 PilzAdam but both items are default:wood, I expect them to stack 10:19 nore nope, in craftpreview, there is something else than default:wood 10:19 nore so when you click on it while holding default:wood, crafting is not triggered 10:20 nore and so the callback is not run, and the engine can't know that it will magically turn into default:wood 10:20 RealBadAngel nore, if the callback is called for each and every recipe resulting with itemstack, maybe callbacks shall be given unique ID's 10:20 PilzAdam the engine could know it by running the Lua function 10:21 RealBadAngel for different recipes 10:21 nore PilzAdam, but what about what the function will do? 10:21 nore RealBadAngel, what I mean is that all registered callbacks are run when a craft in done 10:22 RealBadAngel otherwise you cannot have two different callbacks for 2 recipes resulting in same crafted item 10:22 nore so if you want something to trigger on wood or stone, you do 10:22 nore if itemstack:get_name() == "default:wood" or itemstack;get_name()=="default:stone" then 10:22 nore -- do what you want 10:22 nore end 10:23 nore and you can check the old_craft_grid to know what recipe was done 10:23 RealBadAngel wouldnt it be better to register a callback for the recipe, not resulting item? 10:24 nore what do you mean, for the recipe? 10:24 nore if you want something specific to a recipe, you can check the old_craft_grid 10:24 RealBadAngel if recipe is used and got crafting result then trigger it 10:24 nore to see if that was the recipe 10:24 nore and if so, run your callback 10:25 nore the advantage of that is that it is much more powerful 10:25 RealBadAngel this way we will have to check for crafting grid if something is there 10:25 nore so you can make a global callback that will collect statistics, for example 10:25 RealBadAngel to distinct which recipe was used to get the result 10:26 RealBadAngel on the other hand, when you will trigger it on recipe usage, you will know for sure which case it is 10:26 RealBadAngel lemme give you an example: we have saws. iron, mese, diamond ones 10:26 nore well, with a recipe-specific callback, how do you make a mod that collects statistics to know how many times you've crafted each thing? 10:27 RealBadAngel and resulting 2 stone slabs on use 10:27 nore and? 10:27 RealBadAngel your way callback will be called whenever saws were used, it was crafted or whatever 10:28 RealBadAngel you will have to find out who the f... trigerred that 10:28 RealBadAngel callback on recipe usage will bring you straightforward to your code 10:28 nore well, for that you could check the craft grid to see if there is a saw in it 10:29 nore yes, but what about my previous question? 10:29 nore well, with a recipe-specific callback, how do you make a mod that collects statistics to know how many times you've crafted each thing? 10:30 nore PilzAdam, about the fact that is does not stack: 10:30 nore most mods will not change the output, or only add metadata to it 10:30 nore so there will be no problem with that 10:30 RealBadAngel nore, simply, increase +1 table with result item 10:31 RealBadAngel or with quantity of it 10:31 RealBadAngel on every callback 10:31 nore yes, but you need a callback for every craft recipe... 10:31 nore what do you do with other mod's craft recipes, then? 10:32 RealBadAngel have default callback to handle the statistics and eventually call user defined one 10:32 nore PilzAdam, what about if the function has side effects too? (such as doing statistics) 10:33 PilzAdam thats the problem 10:33 nore yes, but you still need a callback for every craft recipe 10:33 nore PilzAdam, most mods will not change the output 10:33 nore and among those that will do, it will mostly be to set some metadata in a tool or somthing like that 10:34 PilzAdam you dont know what mods will do 10:34 nore so it will be possible to stack 10:34 nore PilzAdam, of course I don't 10:34 nore but really, what mod will make a craft recipe give something, and *always* change it with something else. 10:34 nore ? 10:35 nore that's not coherent! 10:35 nore and if they do that, it is their problem 10:35 nore i.e.: if I want to do a craft recipe that gives a random amount of something 10:36 RealBadAngel btw, i can see another side effect. if i do register callbacks for cutting, with different tools, will have too old crafting ones it means that all the callbacks will be run 10:36 RealBadAngel instead of just one 10:36 RealBadAngel for the correct case 10:36 nore RealBadAngel, you still have only one callback to register if you do it correctly 10:37 RealBadAngel one can have many ways to get one item. provided by many mods 10:37 nore I would set the output to that something, and then randomly change the itemstack count 10:37 RealBadAngel that means multiple callbacks 10:37 nore RealBadAngel, not with the current way 10:37 RealBadAngel not? 10:37 nore you only need to check that the output is your item in the single callback 10:38 nore if itemstack:get_name() == "myitem" then 10:38 nore --do what you need to do 10:38 nore end 10:38 PilzAdam nore, imagine a mod that modifies craft results based on player classes 10:38 RealBadAngel im talkin about case that multiple recipes defined by different mods leads to the very same item 10:38 nore so I should add a predict_craft_result function? 10:39 nore RealBadAngel, that's exactly what my code detects 10:39 nore if the output is that item, then do something 10:39 RealBadAngel what if two mods calls for the very same item 10:40 nore then the two callbacks are run 10:40 RealBadAngel what if there are lets say 20 ways to get stone slab 10:40 nore PilzAdam, so perhaps some minetest.register_craft_prediction? 10:40 RealBadAngel we do have 20 callbacks then 10:40 nore all 20 ways would trigger the same callback 10:41 RealBadAngel hold on, the same? 10:41 RealBadAngel i defined two callbacks 10:41 nore say, if I do: 10:41 RealBadAngel will they override each other? 10:42 nore no, of course! 10:42 nore the first registered will be run, then the second registered will be run too 10:43 RealBadAngel huh, it may work, but coding all the cases will be time consuming 10:43 nore PilzAdam, what about what I said? 10:43 PilzAdam nore, the problem with that is that it runs on the server, so it would be quite laggy 10:43 nore craft already runs on the server 10:44 nore my pull request does not change that 10:44 RealBadAngel identyfing the recipe will be time consuming 10:45 nore RealBadAngel, perhaps some function can be written in builtin for that 10:45 nore recipe_matches_craft_grid, or somthing like that 10:46 RealBadAngel register craft could return recipe id, callback should provide it 10:46 RealBadAngel maybe something like that 10:47 RealBadAngel but this would require extra code 10:47 RealBadAngel imho callback on recipe is easier and way faster 10:47 nore no, it is not easier to code 10:47 nore and it is less powerful 10:48 RealBadAngel why less powerful? 10:48 nore for the very reason I said above 10:54 RealBadAngel you will have your callback for the itemstack, it could be default one 10:54 RealBadAngel but the user defined could be taken from recipe 10:55 RealBadAngel so call your one as by now, take user's from recipe if provided and call it 10:56 nore so you mean, one global callback that checks for recipes callbacks 10:56 RealBadAngel huh, wait 10:57 RealBadAngel one global with possible global user defined (for the statistics or whatever) 10:57 RealBadAngel and then recipe dependent if provided 10:57 RealBadAngel that would be perfect 10:57 nore could do that later 10:58 nore for now, I'm working on PilzAdam's thing 11:00 RealBadAngel that will combine yours and mine way and minimalize code needed to identify recipes used 11:01 RealBadAngel so for example i could get directly to diamond saw code, you will still have global callbacks for another stuff 11:07 nore how do you get an inventorylocation from a player? 11:07 nore I have a player, and I want its inventory location 11:07 nore how do I do that? 11:21 RealBadAngel hold on 11:22 RealBadAngel in engine? 11:23 nore nvm, I found it 11:29 nore PilzAdam, could you look at the latest commit and tell me what you think of it? 11:32 nore PilzAdam, are you still there? 11:48 nore PilzAdam, example use: https://gist.github.com/Novatux/7179966 12:17 sapier https://github.com/minetest/minetest/pull/968 use mingw zlib on mingw builds 12:20 nore sapier, have you seen the last version of #966? 12:22 sapier overriding predicion too ... :-) guess now we need an additional function to fetch dynamic recieps too ;-) 12:22 nore https://gist.github.com/Novatux/7179966 <--look at that 12:23 nore this makes steel blocks with a single stack of steel ingots 12:24 sapier do we actually need recieps any longer? 12:26 nore way easier than that 12:26 nore and what you can do too is: 12:26 nore minetest.register_craft{output = "placeholder"... 12:27 nore and then check if itemstack is placeholder to do your things 12:27 sapier I'm not convinced this is right way to do it as it seems to me we now have two almost unrelated ways of specifying recieps 12:27 sapier maybe whole reciep mechanics should be reworked 12:28 nore the objective is to be able to do things that were not possible, e.g., make a block with metadata, depending on which items your craft it with 12:28 nore etc. 12:28 sapier don't get me wrong imho your additions are far more advanced than the old ones ... maybe your version should replace the old way of doing it ... but I'm not sure if it's already capable of replacing it completely 12:28 nore recipes are for normal things 12:29 sapier that doesn't matter "normal" is just a special case of complex ;-) 12:29 nore I reckon it is, by adding a Lua function able to detect if something is a craft recipe 12:30 nore and then adding the first callback to check for those registered craft recipes 12:30 nore however, I don't think it should be changed now, since minetest.get_craft_result would become *slow* 12:31 nore and crafting too 12:32 sapier ok so at least entry point needs to stay as is .. but you should have a look at those functions returning craft reciep list. In best case find way to make them show the changes added by those lua callbacks 12:33 sapier or if not possible add some special marker so a mod can recognize a reciep may not be valid the way it's listed 13:12 nore hmmmm, what do you think now of #966? 13:12 nore with that https://gist.github.com/Novatux/7179966 to test it 14:49 nore is anyone here ok for #966? 15:00 nore I had a question about perlins: how costly are they? 15:43 dysoco Can I import minetest into an IDE? What do you use? 15:43 dysoco I guess I could just use Emacs + ctags but 15:48 ShadowNinja zat: Any progress on SQLite rollback? 15:49 nore ShadowNinja, did you add entities to #856? 15:49 nore cause I reckon that is why it is not merged yet 15:50 nore btw, have you seen what it is possible to do with #966? 15:50 nore https://gist.github.com/Novatux/7179966 15:51 ShadowNinja nore: I updated the docs to mention the fact that someone might use the functions with entities. But they always worked, as long as you rounded the position of course. 15:52 nore I reckon they wished it for taking builtin_item, IIRC 15:52 nore perhaps dropping too 15:54 ShadowNinja nore: Neat. 15:54 zat ShadowNinja: not so far but I want to finish it soon 15:54 zat I am going to make it more storage optimizing 15:54 ShadowNinja Ok, sounds good. 15:55 zat And I hope not to be complained much for my code... 15:57 dysoco Does Minetest have any kind of automated tests to see if the build is OK? 15:58 nore there are unit tests, but not everything can be tested automatically 15:59 dysoco Well I'll search for the unit tests 15:59 nore I have heard that some of them fail, so... 16:01 ShadowNinja dysoco: We have automatic travis builds. See https://travis-ci.org/minetest/minetest 16:02 nore well, I reckon what he asked was to check if the build worked correctly, not if if built correctly 16:04 dysoco Yeah, I mean, the code builds, but how do I know I haven't broke anything 16:04 dysoco that's what I mean 16:47 ShadowNinja Just compile it and run the executable. If it works it works. There are some unit tests in test.cpp that run unless ou use --disable-unittests 16:54 dysoco Alright, thanks. 17:47 dysoco Is there a coding standard? Can't find one, and the code is written in different ways all arround 17:47 dysoco style guide* 17:48 ShadowNinja dysoco: http://dev.minetest.net/Code_style_guidelines 17:48 rubenwardy This is open source, there is no style! [/jokes] I think there might be an article on dev.minetest.net 17:49 dysoco ShadowNinja: thanks! 17:52 dysoco Looks a bit too broad though, like doesn't specify wether to use Allman or BSD style. 17:52 Calinou try to follow the most guidelines you can :) 17:52 Calinou no idea what's the difference between these 17:53 dysoco opening brace goes either in the same line as declaration of the function (or if statement, or whatever) or in a new line 17:53 dysoco but I'm just too perfectionist, everything must be perfect and the same :P 17:55 celeron55 well those guidelines partly conflict with what is actually used because they've been written by hmmmm 17:56 nore celeron55, what do you think of https://github.com/minetest/minetest/pull/966 ? 17:57 hmmmm indeed 17:57 hmmmm that's the style I follow, but it's somewhat acceptable if you follow the code style of what's already prevalent in that source file 17:57 celeron55 they should be adjusted a bit; for example that thing about switches at the start hasn't been and isn't followed at all 17:57 hmmmm yeah, that's true, I've been meaning to fix that actually 17:59 nore what do you think of #966? 17:59 nore (craft callback) 18:02 celeron55 wait wtf https://github.com/prestidigitator/minetest/blob/objnoise/src/noise.h 18:02 celeron55 i hadn't looked at this file before 18:03 nore what is the problem with that file? 18:03 nore (except that it is perhaps a bit too much OO) 18:04 celeron55 ...it's so utterly ridiculously verbose that it's not even funny anymore 18:04 dysoco that identation 18:04 dysoco appropiate file name: noise.h :P 18:04 nore yeah, some of the comments are useless 18:07 nore that should be called noise.comments 18:07 nore that would be a correct file name 18:08 nore so, any thought on #966? 18:09 celeron55 i don't know, i need to focus on something else 18:28 PilzAdam lol "@param x \n The point's x coordinate." <- why we dont like doxygen 18:29 thexyz why? 18:31 PilzAdam what why? 18:33 thexyz why don't we like doxygen? 18:35 thexyz having too much documentation is better than having no docs at all, isn't it? 18:35 dysoco You can use doxygen without having stupid comments 18:42 thexyz and since we're talking about noise.h anyway why do this? https://github.com/minetest/minetest/blob/master/src/noise.h#L48 18:44 ShadowNinja VanessaE is having a issue where the assert() statements in vector.lua don't generate a backtrace. I haven't reproduced it. Does anyone know why this might happen? 19:29 celeron55 thexyz: it's basically not implemented 19:29 celeron55 feel free to implement 20:17 VanessaE celeron55: did you see RBA's latest pull? 20:18 VanessaE https://github.com/minetest/minetest/pull/967 -- with that plus HDX, you get --> https://forum.minetest.net/viewtopic.php?pid=115811#p115811 20:23 VanessaE (he figured out how to do what you said you weren't sure could be easily done ;) ) 20:52 celeron55 VanessaE: uhm 20:52 celeron55 VanessaE: so what have i said is easily done that is in there? 20:52 celeron55 +not 20:53 VanessaE celeron55: some time back we discussed doing this, and you mentioned that it would be either cumbersome, or would not look right. Just syaing. 20:53 VanessaE saying* 20:55 celeron55 yeah and you left out what is "it" 20:56 VanessaE oh, the idea of tinting a texture 20:56 VanessaE you were rather convinced that there was no easy way to do it. 20:57 VanessaE anyways, it works well. 20:57 VanessaE or more specifically, the idea of tinting it in realtime to match the general color progression of a sunrise 20:58 celeron55 i don't recall anything about this so whatever 20:58 VanessaE no matter :P 23:37 Sokomine i want to return diffrent types of drops depending on which tool is used. any recommended way of doing so? else i'll probably set drops to nothing and handle out the drops in after_dig_node manually 23:38 Sokomine perhaps there's a better way i'm currently not seeing