Time  Nick         Message
07:29 nore         I've got a suggestion: minetest.register_on_craft
07:30 nore         this should be called when a player crafts something, and should return an itemstack
07:30 nore         that will replace the crafted itemstack
07:31 nore         i.e.: minetest.register_on_craft(function(player, crafted_item)
07:31 nore         ...
07:31 nore         return new_crafted_item end)
07:31 nore         what do you think of it?
09:28 nore         https://github.com/minetest/minetest/pull/966
09:28 nore         what do you think of that?
09:28 nore         it is what I spoke o about 2 hours ago
09:28 nore         +f
10:00 nore         PilzAdam, what do you think of https://github.com/minetest/minetest/pull/966
10:00 nore         ?
10:02 PilzAdam     doc missing
10:04 nore         yes, I was going to add it
10:04 nore         but else, it is ok?
10:07 nore         PilzAdam, doc added
10:08 PilzAdam     "to do nothing." does that mean that the craftresult is nothing, or that the original craftresult is used?
10:09 nore         the original craftresult is used
10:09 PilzAdam     then write that
10:09 nore         changed
10:10 PilzAdam     also it might be useful to get the crafting grid list passed to the function
10:10 nore         the crafting grid list is the player inventory, no?
10:10 PilzAdam     its the 3x3 grid
10:10 PilzAdam     are the items still there when the function is called?
10:11 nore         no, they have been already removed
10:11 PilzAdam     so the mod doesnt know how the item was crafted
10:11 nore         no
10:12 nore         so you want something like the original crafting grid too
10:12 PilzAdam     yes
10:13 nore         is there a function to copy an inventory list?
10:15 PilzAdam     in Lua an inventory list is just an array of itemstacks
10:15 nore         and in C?
10:16 PilzAdam     inventory.h:171
10:17 PilzAdam     you can use = to copy it
10:17 nore         or, perfect
10:18 nore         s/or/ok
10:18 nore         and how do you transform a C inventory list to a Lua one?
10:19 PilzAdam     script/common/c_content.cpp:706
10:20 PilzAdam     you could either copy the code, or add push_inventory_list(lia_State, InventoryList)
10:21 nore         and what should be the order of arguments? itemstack, old_list, player?
10:24 PilzAdam     call it "recipe" instead of old_list, or so
10:24 nore         old_craft_grid, perhaps?
10:24 nore         I reckon it is the best
10:24 PilzAdam     why the "old"?
10:24 nore         because it is not like that anymore
10:26 PilzAdam     but do the modder need to know about that?
10:26 nore         about what?
10:27 nore         the callback is called after the craft grid has been changed, so the modder can modify it if he wants, etc
10:27 * VanessaE   thinks of wearing tools down when they're used to craft something, e.g. moretrees coconuts
10:27 nore         for example, one can make a tool that you craft with some other thing, and the tool is worn out
10:27 nore         VanessaE, you read in my mind
10:27 VanessaE     ninja'd :)
10:28 PilzAdam     it should be added as a comment in lua-api.txt
10:28 nore         yes, I will do that
10:28 PilzAdam     I still dont see a reason to call the list "old", just "recipe" is fine
10:28 VanessaE     it would make it possible to craft the four million kinds of stairsplus shapes without using the circular saw, as in MC, and have the tools wear out
10:37 nore         PilzAdam, I get that:  error: base operand of ‘->’ has non-pointer type ‘InventoryList’
10:37 nore         what does this mean?
10:37 PilzAdam     do you try to use -> without having a pointer?
10:37 nore         I have that:
10:38 nore         InventoryList &old_craft_grid
10:38 nore         in the arguments
10:38 nore         and I try to do that: old_craft_grid->getSize()
10:38 nore         what should I do instead?
10:38 deltib       that's a reference, not a pointer
10:38 PilzAdam     try .
10:38 nore         . instead of ->?
10:38 PilzAdam     yes
10:39 nore         error: conversion from ‘InventoryList*’ to non-scalar type ‘InventoryList’ requested
10:39 PilzAdam     what do you pass to the function?
10:41 nore         InventoryList saved_craft_list = list_craft;
10:41 nore         I pass saved_craft_list
10:42 PilzAdam     is that a pointer?
10:43 nore         InventoryList *list_craft = inv_craft->getList("craft");
10:43 nore         ok, I've been able to do it this time
10:44 nore         should work, I've replaced a few & by *
11:01 thexyz       eeeh, that's not how you do C(++)
11:07 sapier       grrr the longer I try to get gettext working with vs2012 the more I think we should drop gettext completely ... and replace it by something more sane ... did anyone else succeed
11:07 sapier       ?
11:10 sapier       btw localization seems to have changed from winxp to vista too so maybe we handle those different too
11:25 nore         PilzAdam, how do you copy an inventory list in C?
11:26 nore         it does not work, when the old one is modified, the new one is modified too with what you said
11:28 nore         could it be done by serializing it and then deserializing it again?
11:28 nore         how is that done?
11:28 sapier       of course but that's lua not c style
11:28 nore         :(
11:28 nore         so, how do you copy it?
11:28 sapier       is list a class or a struct?
11:29 nore         class
11:29 sapier       add a copy constuctor
11:29 sapier       then you can do list a = listb
11:30 sapier       the constructor is required to copy all content of the list
11:30 nore         no, lista = listb already exists
11:30 sapier       e.g. if there are pointers in there the CONTENT needs to be copied not the pointer
11:30 nore         but it is only shallow
11:30 nore         m_items = other.m_items;
11:31 sapier       let me have a look I guess m_items is a pointer not a member
11:31 nore         where items is a std::vector<ItemStack> m_items;
11:32 thexyz       sapier: is there anything else than gettext?
11:32 sapier       I'm already looking for a lgpl replacement no success by now
11:32 thexyz       so all alternatives are gpl-only?
11:33 thexyz       that's uncool
11:33 sapier       no I didn't find a suitable replacement at all by now ;-)
11:33 sapier       gpl is reason why vs2010+ arent supported too
11:33 sapier       nore you're right there already is a copy constructor
11:34 nore         but it does not deepcopy
11:34 sapier       and as of inventorylist point of view this should be fine
11:34 nore         what if I want a deepcopy?
11:34 sapier       "deepcopy"?
11:34 nore         i.e., it does:
11:34 nore         m_items = other.m_items;
11:35 sapier       deepcopy isn't a concept used in c++ ;-)
11:35 nore         std::vector<ItemStack> m_items;
11:35 nore         but there is that ^
11:35 sapier       ItemStack isn't a pointer so it's content is copied too
11:35 nore         but is the vector copied?
11:36 sapier       yes and copying a vector results in a copy of it's content
11:36 sapier       that's why copying a vector can be very dangerous
11:36 sapier       as of performance point of view ;-)
11:36 nore         so doing that: InventoryList *saved_craft_list = list_craft; will copy the inventory list, right?
11:37 sapier       no of course not
11:37 sapier       you don't do a copy there
11:37 nore         well, what should I do if I want a copy, then?
11:37 sapier       you just save a pointer to that list
11:37 sapier       InventoryList saved_craft_list = *list_craft;
11:38 sapier       but as I said thats a very very very costly operation
11:38 nore         now I get errors while compiling :(
11:39 sapier       you neet to replace any location where you used saved_craft_list by &saved_craft_list
11:39 sapier       and of course you can't use that list after you returned from the function doing InventoryList saved_craft_list = *list_craft;
11:39 nore         ok, it works, thanks!
11:40 sapier       if you want to add that code to minetest you most likely won't succeed ;-)
11:40 sapier       operations like that are only valid in very rare cases
11:41 nore         well, that's what PA told me to do...
11:41 sapier       &saved_craft_list is very risky on stack variables is quite problematic expect crashes if you don't know exactly what you're doing
11:41 nore         I use it only once after that, and the list is not used after function exit
11:42 sapier       and no offence nore but I have some doubts  you really know what you're doing in this special case ;-)
11:43 nore         perhaps...
11:43 sapier       ok let's see your code after you finished it but don't be to upset if it's not accepted
11:43 nore         you can look at the code there:
11:43 nore         https://github.com/minetest/minetest/pull/966
11:43 nore         (it's pushed now)
11:45 sapier       ok seems to be right as of pointer scope view
11:45 nore         I tested it, it works correctly
11:45 nore         I was able to see the old craft list from Lua
11:46 sapier       you can't tell something works correct by testing ;-)
11:46 sapier       there's happening to much you don't see in this special case
11:46 nore         yes, but you can tell it doesn't crash every time...
11:46 nore         ofc
11:46 sapier       I don't know how big those inventory lists are, if they're some bytes only this way of doing it is perfectly fine
11:46 nore         anyway, are you ok with this pull?
11:47 sapier       if they get large this code might cause a stack overflow ... no idea if this is a real risk in this case
11:48 sapier       no forget about my comment
11:48 sapier       vectory copy constructor is used so stack is not involved
11:48 nore         so you mean, the vector is not on the stack
11:49 sapier       asuming noone tries to do hundreds of crafting operations per second this code should be fine
11:49 nore         should I delete the inventory list after that then?
11:49 sapier       a std::vector stores it's contents at heap
11:49 nore         to free the memory space used by the vector?
11:50 sapier       no it's automaticaly deleted once the function is left
11:50 nore         good then...
11:50 nore         so you're ok with the pull?
11:50 sapier       this is why &saved_craft_list is dangerous if it's saved somewhere it's gonna become invalid after that function is left
11:51 sapier       but in this case it should be fine
11:51 nore         yeah, of course
11:51 nore         anyway, it's not used after the function is left, so...
11:51 sapier       I don't see any obvious errors in there. but you need to get ok from core devs
11:52 nore         RBA is ok with it (see comment), and PA too (he said me to add the old crafting grid)
11:52 nore         http://irc.minetest.ru/minetest-dev/2013-10-26#i_3393247
11:52 nore         there ^
11:54 sapier       yes but re-show them your new changes ;-) ppl from different countrys not talking in their own language tend to missinterpret each other
11:54 nore         PilzAdam, RealBadAngel, are you still there?
12:01 nore         sapier, do you remember your remove_craft function?
12:01 nore         it can be done with that, now
12:01 nore         -> change the craft to craft a "nothing" item
12:02 nore         and register_on_craft, so that "nothing" will be removed, and the old craft grid restored
12:02 sapier       hmm so you're gonna make craft recieps mod useless by your pull request? ;-)
12:03 nore         what do you mean?
12:03 PilzAdam     nore, I havent said that Im ok with it
12:03 nore         I thought you were
12:03 nore         anyway, are you ok with it now?
12:04 sapier       if you modify recieps on the fly noone can rely on what craft recieps are registred
12:04 nore         yes, we need that remove_craft function
12:04 nore         dunno why it is not merged
12:05 nore         my way of removing a craft is more or less a hack...
12:05 sapier       actually if your changes are added we don't need it any longer nor do we need those functions that get craft recieps ... as they aren't relyable any longer
12:05 nore         well, they are
12:06 sapier       why do you think they are?
12:06 nore         that change is mainly for crafts that would like to add metadata to items
12:06 nore         or for crafts that would want to wear tools, etc
12:07 nore         the objective is not to make those functions useless
12:07 sapier       yes but you just told me you could modify input and output items too. Did I understand wrong?
12:07 nore         you can modify the output item
12:07 nore         and the input items, after the craft has been done
12:09 nore         for example, you can make a craft recipe that will create an item with some metatdata in it, etc.
12:09 sapier       ok so you need to do some tricks ... to do completely different things as defined in reciep ... I guess there's no way to avoid that option if you have a on craft callback
12:10 nore         nope, since someone can always take the player inventory and modify it within the callback
12:10 nore         no way to avoid that
12:10 nore         the objective isn't to hack into craft recipes like that
12:11 nore         and finally, you need a craft recipe with it to use it
12:11 sapier       no matter if it's meant to do so modders tend to use things in ways not designet to be used ;-)
12:11 sapier       e.g. nodeboxes for mobs ;-)
12:12 nore         i.e., something that has no craft recipe will not trigger the callback
12:12 sapier       imho it's as goof as it can be
12:12 sapier       good
12:12 nore         btw, sapier, about removing hacks, have you looked at the new #874?
12:13 sapier       no I'm still busy trying to find out how to make visual studio use gettext correctly
12:13 nore         when I mean new, I just fixed one of the issues you said
12:14 sapier       sorry don't remember what 874 was can you give me a keyword?
12:14 sapier       keyword isn't english right?
12:14 nore         send an "on_receive_fields" event when a formspec is closed
12:16 sapier       yeah that callback was missing for some time
12:16 sapier       but i have to leave now
12:24 nore         so, PilzAdam, are you ok with #966?
12:53 nore         kahrl, what do you think of #966?
12:55 nore         https://github.com/minetest/minetest/pull/966
12:56 kahrl        I think it's a bit narrowminded
12:56 nore         why?
12:57 kahrl        how does it e.g. interact with crafting table mods
12:57 nore         the crafting table mods need to call minetest.on_craft
12:57 nore         hadn't thought of those, though
12:58 kahrl        but most callbacks registered with on_craft will probably assume old_craft_grid is 3x3
12:58 nore         so, pass craft_inventory + old_craft_grid?
12:59 kahrl        perhaps, yes
13:01 kahrl        do all crafting table mods stick to the convention that the inventory list is called "craft"? if so the inv:get_width("craft") can be used from the callback
13:02 nore         kahrl, I reckon yes
13:02 nore         however, I have a question
13:02 nore         how do you push an inventory to Lua?
13:02 kahrl        InvRef
13:03 nore         InvRef::create(L, inv)?
13:05 kahrl        right, see the examples in s_inventory.cpp
13:05 nore         where is it defined?
13:06 kahrl        l_inventory.cpp
13:07 kahrl        for the InventoryLocation use setPlayer(name)
13:08 nore         ?
13:09 kahrl        nevermind, craft_inv is already an InventoryLocation
13:09 nore         nope, it is Inventory*
13:09 nore         and I get errors
13:09 kahrl        inv_craft is an Inventory*
13:09 kahrl        craft_inv is an InventoryLocation
13:11 nore         must I still use setPlayer?
13:11 kahrl        nope
13:11 nore         where is InventoryLocation defined?
13:12 kahrl        inventorymanager.h I guess
13:12 kahrl        yeah
13:13 nore         it looks like it compiles now...
13:16 nore         ok, it works
13:16 nore         only need to modify lua_api.txt now
13:20 nore         kahrl, can you look at it now please?
13:20 nore         and tell me if it is ok
13:23 nore         and sapier said he was ok with it, so if it is ok for you, could you merge it?
13:23 nore         http://irc.minetest.ru/minetest-dev/2013-10-26#i_3393598 <-- there
14:08 nore         hmmmm, what do you think of https://github.com/minetest/minetest/pulls/966 ?
14:09 Exio4        did you make a script for saying it everytime a core dev joins? ;P
14:09 hmmmm        the concept seems good
14:09 nore         no, I didn't
14:10 nore         hmmmm: and the code?
14:10 hmmmm        what's craft_inv..?
14:11 nore         look at lua_api.txt
14:11 nore         it's explained better
14:12 hmmmm        i ctrl+f in lua_api.txt, find 'craft inv', nothing
14:12 nore         look for on_craft
14:12 nore         it's explained there
14:12 hmmmm        that's the thing you just added
14:12 nore         yes
14:13 hmmmm        you didn't explain it
14:13 hmmmm        you said
14:13 hmmmm        "craft_inv is the crafting inventory"
14:13 nore         well, I said it is normally player:get_inventory()
14:13 hmmmm        but what is it now...............?
14:14 nore         it is always that, except that a mod could call on_craft with a different craft_inv, for example for crafting table mods
14:14 hmmmm        so what are you saying
14:14 hmmmm        mods would modify what it seems to have in the inventory?
14:14 nore         no, not exactly
14:14 hmmmm        so now you have a fake crafting inventory that's sometimes different from the normal inventory?
14:14 hmmmm        come on, try harder
14:15 nore         well, more or less that
14:15 hmmmm        I really have no idea what the point of it is
14:15 nore         when a workbench mod wants to craft something, it should call minetest.on_craft
14:15 nore         with craft_inv = his own inventory
14:16 nore         the point of it is there: http://irc.minetest.ru/minetest-dev/2013-10-26#i_3393643
14:16 hmmmm        I don't understand it, so therefore I can't approve it or not
14:16 hmmmm        man, nore, look you got me at the perfect time
14:16 nore         why?
14:16 hmmmm        can I at least take a piss and have a coffee before I do minetest stuff
14:17 hmmmm        later. ok?
14:17 nore         yeah, of course ;)
16:22 hmmmm        to be honest I don't know much about the whole inventory business
16:24 hmmmm        ah, so craft_inv is an InventoryLocation?
16:26 hmmmm        why do I feel like the inventory was over-OO-engineered?
16:26 nore         ?
16:26 nore         'ah, object oriented
16:26 nore         well, I don't know
16:26 hmmmm        I'm talking about on the C++ side of things
16:27 hmmmm        something that's so simple has needless abstractions
16:27 hmmmm        so the craft_inv is an InventoryLocation that contains what, exactly?
16:27 nore         but anyway, what do you think of the pull?
16:27 hmmmm        I'm trying to ascertain that
16:27 hmmmm        I need to ask you questions about it first to form an opinion
16:29 nore         what are those questions?
16:29 hmmmm        the one i just asked 3 lines ago
16:30 nore         craft_inv contains the craft recipe items
16:31 hmmmm        how can it do that?  from what I'm reading, it can only contain the type of inventory, player name, and a v3s16
16:31 nore         well, it contains the player inventory
16:31 nore         in which are the craft recipe items, in the list "craft"
16:32 nore         on the other hand, in the Lua callback, it should be used only for that
16:32 nore         so other inventories can be passed like for a workbench mod
16:32 nore         i.e. a workbench mod would do:
16:33 nore         output = minetest.on_craft(output, player, old_craft_grid, workbench_inv)
16:34 hmmmm        and if on_craft isn't called, workbench_inv is always the regular inventory
16:34 hmmmm        you use craft_inv to get an inv_craft
16:35 hmmmm        that's a pretty bad name, whoever came up with this convention should feel ashamed
16:35 nore         workbench_inv would be minetest.get_meta(workbench_pos):get_inventory()
16:35 nore         and about craft_inv and inv_craft, dunno, it was already there
16:35 hmmmm        workbench_inv would be that?
16:35 nore         for a workbench mod
16:35 hmmmm        so you get the metadata of that node's inventory
16:35 hmmmm        that gives you an inv_workbench, no?
16:36 hmmmm        does get_inventory return an Inventory object, or an InventoryLocation?
16:36 nore         well, lua inventories are inventory locations, I reckon
16:36 nore         ehh, no, not inventory locations
16:36 hmmmm        I'm looking for the definition of the get_inventory() api
16:36 nore         InvRef, which is a different one
16:37 nore         look in l_inventory.cpp perhaps
16:37 hmmmm        hmm
16:37 nore         anyway, there is only one Lua inventory
16:37 hmmmm        it's actually in l_nodemeta.cpp
16:38 nore         so the idea is that that inventory is passed as an argument to on_craft
16:38 hmmmm        from my partial understanding of the code, it's actually an InventoryLocation, not an InvRef
16:38 nore         so if the inventory is not player:get_inventory(), for example in workbench
16:39 nore         hmmmm, it is transformed in an InvRef when put on the Lua stack
16:39 nore         the code still works
16:41 hmmmm        oh, I see it, yeah
16:41 hmmmm        it uses an InventoryLocation internally
16:41 hmmmm        alright, fine then
16:41 hmmmm        if it works it works, I can't exactly test it
16:41 nore         yes
16:41 nore         it works fine in my tests, so...
16:42 nore         will you merge it, since sapier is ok with it too?
16:43 nore         there: http://irc.minetest.ru/minetest-dev/2013-10-26#i_3393598
17:12 Sokomine     nore: regarding your suggested pull request: would it be possible to support multiple outputs for the same craft receipe as well? there are sometimes conflicts in crafting receipes which either force the modders to search for diffrent receipes or server operators to change the mods
17:12 Sokomine     of course that would be an additional feature
17:12 nore         what do you mean, multiple outputs?
17:13 nore         I do not change the crafting code, only add a callback at the end of it
17:13 Sokomine     your on_craft function might also be pretty intresting for all those achievement systems ("first time crafted xyz")
17:13 Sokomine     there are sometimes identical receipes for diffrent outputs due to modders not knowing about each others mods
17:14 Sokomine     the ideal solution is to change one of the receipes. but perhaps it might be practical to have the option to offer diffrent possible results for the same receipe as well
17:16 nore         the last one is a problem, because one wants sometimes to override old recipes
17:25 Sokomine     ok. it was just an idea. perhaps diffrent crafting results for the same craft would be too impractical in the long run
17:27 Sokomine     regarding inventory - there's still https://github.com/minetest/minetest/issues/944 which is at least a problem for my table saw and most likely for all metadata inventories that do not expect input
17:31 Sokomine     that requires changes to inventorymanager.cpp. as no dev has shown intrest, guess i'll have to see how i can fix it myshelf
17:31 nore         good luck for that
17:32 Sokomine     thanks :-)
19:04 Sokomine     hmmmm: just got reminded of the 4seasons mod. that was a very nice one. it got dropped from the kingarthur server because it caused too much load. the mod changes the season all 20-30 minutes and replaces the dirt_with_grass blocks and the leaves of trees with season-specific ones (spring,summer=normal,autum,winter)
19:04 Sokomine     with luavoxelmanip, it might be possible to do it fast enough
19:04 hmmmm        mmm
19:04 hmmmm        i am not so sure about that sokomine
19:04 hmmmm        that sounds like a bad approach
19:04 Sokomine     why? can you explain?
19:05 hmmmm        see, if the node color tinting idea ever makes it into code then that could be used
19:05 Sokomine     another drawtype that occasionally gets the swtich-to-other-texture command from the server would be even nicer
19:05 hmmmm        the color LUT could just be changed so that it's pointing at a different season's color
19:05 hmmmm        so you'd get the same leaves, for instance, but then it'd be red colored instead
19:05 hmmmm        or something along those lines
19:06 Sokomine     hmm
19:07 Sokomine     for the dirt_with_grass, such an approach mgiht suffice. the leaves where diffrent iirc - just changing color composition may not be enough (or may it?)
19:07 hmmmm        in order to do that, we'd have to make leaves have the "colorlike" attribute that I was talking about
19:07 hmmmm        dirt with grass too
19:07 hmmmm        since neither of them have any other drawtypes they'd be able to use the entire 8 bit range for colors
19:08 hmmmm        so you can have a complete range from green to yellow to red for your leaves, 256 shades, and they'd be able to gradually change over time
19:08 VanessaE     not to belittle your work, but imho there should be less focus on that and more on things like client crashes and general slowness.
19:09 hmmmm        i think it's pretty fast the way it is
19:10 Sokomine     oh, sorry. was just reminded of that mod. and i did like it a lot. would love to see it again
19:11 VanessaE     hmmmm: to some degree it is, and certainly the server has gotten faster, but I'm seeing people complaining about low FPS even on the simplest games now
19:11 hmmmm        that VBO patch never made it in i guess
19:11 VanessaE     nope.]
19:11 VanessaE     I use it, and it helps to some degree, but there are claims of huge memory leaks
19:11 VanessaE     plus it doesn't unload old data often enough
19:11 hmmmm        that should help things along for certain...... also people seem to confuse the wanted FPS with a low fps
19:12 VanessaE     hmmmm: 3fps is "low".
19:12 hmmmm        they think, "oh hey I have a really fast card and I can get 200 fps in minecraft but here I only get 30"
19:12 hmmmm        i'm sorry, but 3 fps is under some specific situation which requires a lot of context
19:12 VanessaE     (note I said "3", not "30")
19:12 hmmmm        it might be reasonable.
19:13 hmmmm        and it probably isn't fixable either.
19:13 VanessaE     hmmmm: a low-end 1.6 GHz netbook with 2GB RAM should still be able to pull off 20-30 fps on a game as simple as mt_nostalgia or vanilla minetest_game
19:13 VanessaE     for example.
19:13 hmmmm        well, I'd be inclined to believe that the graphics chipset is what matters the most there
19:13 VanessaE     indeed so
19:14 hmmmm        then why didn't you mention that instead of the ram and processor?
19:14 VanessaE     but regardless, even a good software renderer is faster than that, which tells me MT has some strange bottleneck no one's thought to look into
19:14 VanessaE     because I don't remember which GPU the example machine had.
19:15 hmmmm        don't forget that Minetest is unique in that it dynamically generates the meshes
19:15 Sokomine     there are situations when the graphics chipset does not matter at all anymore. when some bugs come into play, it plain simply doesn't matter if it's the gpu found inside a celeron g1620 (no extra graphics card) or that rather high-end card vanessa has. same result. may take slightly longer with the better card to give up, but eventually it ends at those 3 fps for both
19:15 hmmmm        regular 3d applications upload the mesh to the gpu *once*
19:15 Sokomine     it did help a lot that the particle spawners of the bees mod got removed
19:16 VanessaE     hmmmm: I could see a continue stream of mesh uploads causing a bottleneck, but it's not like there's anything in the world that sits there burning through 60 changes/second, you know?
19:17 VanessaE     a single, quick upload every so often should not have an appreciable effect on the rendering speed.
19:17 VanessaE     continuous stream*
19:17 VanessaE     I mean,
19:17 hmmmm        well, it'd be nice if you were able to find the problem
19:18 VanessaE     if mesh uploads are such a bottleneck, why haven't the been split into smaller pieces?
19:18 VanessaE     so that you have to only update that one node off in the corner of the block, etc.
19:18 Sokomine     don't know about that. i have no idea about the functionning of modern graphics hardware. i can only say that with the bees mod, fps went down to unplayable 3 fps
19:19 VanessaE     the more nodes a world has defined, whether any significant fraction of them are visible or not, the slower the fps also
19:19 VanessaE     as if the rendering engine is sitting there counting through the entire node database for every frame or something.
19:19 Sokomine     it's ok that fps drop on my hardware when i turn far view on and have huge areas loaded. when the bee particle spawners where on, even standing in the desert staring at a desert stone block eventually led to fps drops below playable
19:20 Sokomine     hmmm: yes, that would be great :-) perhaps the problem can be found when talking about it and seeing it from diffrent angels
19:20 VanessaE     the client is doing something truly wasteful and no one can seem to find out why because everyone's obsessed with new features.
19:20 VanessaE     fixing bugs is boring, ergo no one wants to fix them
19:21 Sokomine     trouble is: without any idea what may cause those bugs, there's no way to fix them
19:23 VanessaE     it's like that huge fps drop some folks see when digging.  that started back in early 2012.  for low-rez users it isn't too bad, but for high-rez users it causes the client to hang for a split second in the worse cases, which leads to over-digging.  how much longer is it gonna take before that get fixed?
19:23 VanessaE     (and I've been seeing some comments that low-rez users are now similarly affected)
19:39 sapier1      the one responsible for adding gettext as call to core and return translation get to the next corner and be ashamed ;-P
19:41 VanessaE     also, can we PLEASE be given an option to not prevent others from looking into a locked chest?
19:41 VanessaE     some of find that feature irritating as hell
19:41 VanessaE     (and if I supported it before, I changed my mind :P )
19:45 sapier1      wait it's possible to have a look into another persons locked chest?
19:46 VanessaE     it used to be.
19:47 Sokomine     no, it's not. locked chests show their content only to their owner. trouble is: they have to ask the server for that. and that's sloooooooooooowwwwww
19:47 Sokomine     there can be a special locked secret chest for players who care about that. those can have the slow performance if they want to
19:48 Sokomine     for chests, this call-the-server-first is a very bad idea. there are other situationes where the show formspec is a very fine feature and very desirable (in mobs for example, or in special machines)
19:49 Sokomine     i try to avoid normal locked chests now and use either technic chests or locked homedecor kitchen furniture - both are way faster than the inbuild locked chest
19:49 Sokomine     it annoys me a lot. technic chests are more expensive, and the homedecor kitchen cabinet has a smaller inv
19:50 PilzAdam     Sokomine, if your problem is the speed than removing that feature is the wrong way
19:50 PilzAdam     s/than/then/
19:50 Sokomine     why?
19:50 PilzAdam     we should rather fix that it takes so long
19:51 VanessaE     my personal problem is that, as the admin of my server, maybe I need to look in players' chests.
19:51 PilzAdam     VanessaE, thats perfectly possible, just change the is_owner() function
19:51 Sokomine     my main problem is the speed, yes. don't think mt's network code is suddenly going to evolve to super-fast so that the problem could be solved
19:51 PilzAdam     Sokomine, client-side Lua could solve it
19:51 VanessaE     PilzAdam: implied:  without having to modify the code.
19:52 VanessaE     i,.e. I prefer to keep the base game as vanilla as possible.  bug reports are much easier and more reliable then.
19:52 Sokomine     another point is that i don't care that my chests are secret. it would even be more desirable if everybody can look inside - so people can tell me if they need something or have to offer anything in return for trade
19:52 PilzAdam     VanessaE, then install a mod that adds a priv that allows looking in locked chests, open locked doors etc.
19:52 VanessaE     "Oh, you changed that function? No clue then. sucks to be you."
19:52 Sokomine     it's also good to give people an overview of what might be worth keeping. peeking into other peoples chests may improve knowledge of what's available for newer players
19:53 Sokomine     pilzadam: client-side? sure?
19:53 VanessaE     client-side *anything to do with locked anything* is a bad idea.
19:54 Sokomine     how can i override that function clientside?
19:54 PilzAdam     VanessaE, client-side Lua is for prediction only
19:54 Sokomine     i mean - i could ask vanessa to change it on her server, yes. won't help on all the other ones out there
19:54 VanessaE     prediction for opening a chest? O.o
19:55 sapier1      you can't predict opening a chest ;-P
19:55 Sokomine     yes. in this case, i want prediction
19:55 PilzAdam     what do you think why opening a normal chest is faster?
19:55 VanessaE     since when did we need prediction to display a damn inventory??
19:55 Sokomine     in most cases, showing me the content of my chests as it was last time is perfectly ok - helps enough to find the desired chest and initiate the move of my inventory :-)
19:55 sapier1      prediction is only usefull for world manipulation e.g. digging, doors ... things like that
19:56 VanessaE     prediction when it comes to moving stuff around is reasonable
19:56 VanessaE     but to just show the chest inv?  no.
19:56 VanessaE     that's just overki;;
19:56 sapier1      a chest is like shrödingers cat until you asked server you can't know whats in there
19:56 VanessaE     overkill*
19:57 PilzAdam     VanessaE, you can see the results of not having prediction for opening chests in the current locked chests
19:57 sapier1      there's no way to "predict" content of a chest ... either you you know whats in or you don't
19:57 Sokomine     thought the information what's in the chest is stored in metadata?
19:57 VanessaE     PilzAdam: did you miss the part where Sokomine said that locked kitchen cabinetry in homedecor (== locked chests) are faster than the default locked chests?
19:57 PilzAdam     sapier1, all clients know all the content
19:58 sapier1      so you don't need to predict
19:58 sapier1      you already KNOW
19:58 PilzAdam     VanessaE, homedecors locked chests have prediction, though
19:58 VanessaE     since when?
19:58 PilzAdam     sapier1, no, predict wether you are allowed to show it or not
19:58 VanessaE     kaeza: *poke*
19:58 PilzAdam     VanessaE, since forever, its builtin in the engine
19:58 kaeza        hm?
19:59 VanessaE     if it's built-in, then why doesn't the default locked chest benefit from it?
19:59 sapier1      imho thats a protocol/engine lack of feature
19:59 Sokomine     ah. there we are. i don't *want* the code to bother about weather it's allowed to show me the content or not. i want it to show it anyway. weather accessing the chest is allowed or not plays only a rule when actually acessing the inventory
19:59 PilzAdam     VanessaE, because for default locked chests there is a Lua function that decides wether to show it; that means the server has to send the result to the client
20:00 VanessaE     ah
20:00 Sokomine     that very question (am i allowed to or not?) leads to a terrible delay
20:00 VanessaE     and therein lies the rub.
20:00 kaeza        VanessaE, because PilzAdam thinks that making chests locked is not enough, hence, he wants them to be private too
20:00 sapier1      btw why does client know content of all chests?
20:00 Sokomine     pilzadam: exactly. that's what i'm angry about and what i want changed
20:00 PilzAdam     so we need a copy of the Lua function in the client so the client knows it faster
20:00 kaeza        which is... silly
20:00 PilzAdam     (i.e. the client predicts what the server will say)
20:01 sapier1      this function does only work if it has all information to decide
20:01 VanessaE     no, we need the client to just open the damn chests, or consult a flag that the server had set at the start.
20:01 Sokomine     client knows content of all chests because content is stored in metadata. and that's sent with the mapdata to my knowledge
20:01 VanessaE     there's no reason for client-side Lua for that.
20:01 VanessaE     that's overkill
20:01 sapier1      so either information is passed along with content of chest
20:01 PilzAdam     sapier1, that is playername and "owner" field in meta currently
20:01 sapier1      or we need to implement a way to transfer data to client too
20:02 sapier1      so for current way of doing this might work ... but I assume we need a way to transfere data anyway
20:02 VanessaE     KISS
20:02 sapier1      still ... overkill for chest peaking ;-)
20:03 PilzAdam     VanessaE, KISS does not refer to features, it refers to code
20:03 kaeza        sapier1, is all metadata passed on to client?
20:03 VanessaE     just give the client a one-bit flag when you sign in, true/1 == "locked chests on this server can be viewed".  let the client consult that flag instead of running a bunch if Lua code!
20:03 Sokomine     the problem can be solved by removing that "show content only to owner" functionality. if that gets removed, it's fast again. normal chests cause no trouble
20:03 VanessaE     PilzAdam: it refers to both.
20:03 kaeza        or just formspec and infotext?
20:04 sapier1      I don't know exactly kaeza but I'd expect metadata to be part of map information sent to client
20:04 VanessaE     if you wanna do client-side Lua for something, that's great.  But for this, no.  That's just stupid.
20:04 PilzAdam     kaeza, I think its the whole meta
20:04 Sokomine     you can even implement extra secret chests if you want. those could be crafted with locked chest + steel ingot above (plus a diffrent texture...). it would then be immediately obvious that those chests arn't accessible to non-onwners - and for the owners of them, it'll be their own fault for using the slow but secret variant
20:04 PilzAdam     so better you dont store passwords in it
20:05 kaeza        what I mean is, "owner" is already used by default mod (locked chests) and several mods like protection blocks, etc
20:05 Sokomine     instead of a function, normal locked chests ought to have just their formspec
20:05 sapier1      imho implementing locked chest as node metadata is wrong
20:06 kaeza        so it would be easy for the client to check that locally
20:06 Sokomine     in the long run, improving mts network code may help as well. there'll still be delay - sometimes servers are on the other side of the ocean. that may - depending on situation - lead to some small lag
20:06 sapier1      a locked chest could store it's data in a separate data file not mixing it to map information ... yes that'd be not as fast as current one
20:07 PilzAdam     sapier1, now that is overkill
20:07 kaeza        ^
20:07 sapier1      no it isn't it's way more easy than adding prediction synchronization .... to get really locked chests
20:08 Sokomine     hm, no, we don't need prediction information
20:08 sapier1      but I'm gonna concentrate on fixing gettext for msvc it's a pain in the ass
20:09 Sokomine     all i say is that the "my chests ought to be secret!" idea is one i do not share at all and that costs me time whenever i want to access my own locked chest. i don't want that. i don't care about special privacy there - the content of my chests is not *that* private
20:09 PilzAdam     someone could make a glass-chest mod that would allow everyone to watch the items but only the owner to take them out
20:09 * VanessaE   restrains sapier1 from killing Sokomine  ;)
20:10 VanessaE     PilzAdam: damn it come on.  just get rid of the feature.
20:10 Sokomine     what people build are the normal locked chests. that receipe is known. and then we get the horrible performance. why not make your ultra-secret-chest a special one?
20:10 PilzAdam     its just not very realistic if you can watch into a locked wooden chest
20:10 VanessaE     s/feature/misfeature/
20:10 * Sokomine   runs away and hides :)
20:11 * Sokomine   folds up a couple of cobble stacks and throws them happily at pilzadam and watches how that would turn out in the real world :-)
20:11 sapier1      imho looking into a locked chest is a bug. no matter if this might be a interesting feature ... having a look into other ppls bedroom might be interesting too (for some ppl) but it's still wrong ;-)
20:11 VanessaE     she's right, since when was realism a concern in this game?
20:11 PilzAdam     Im talking about in-game logic, maybe realism the wrong word
20:11 VanessaE     every time someone *else* brings it up, the idea of realism to any degree is shot down
20:12 VanessaE     ok then, in the real world even a locked chest has gaps between the boards, through which you can see the contents.
20:13 Sokomine     oh, i do love to look into bedrooms in minetest :-) they're part of the buildings. i don't actually expect people to sleep there or have anything private :-) it's just like walking through a house that's for sale or taking a tour on a castle where you can see how it's furnished
20:13 kaeza        meh, as with finite lava, it's no use to argue
20:14 PilzAdam     I just got reminded why I dont touch minetest_game anymore
20:14 Sokomine     :-(
20:14 VanessaE     ...
20:14 kaeza        so better actually do a mod to override default chests to remove this wonderfully useful feature
20:14 VanessaE     you know, maybe I *should* have taken up that offer to join as a dev for minetest_game....
20:15 VanessaE     (but I've got too much on my plate as it is)
20:17 VanessaE     the reason, PilzAdam, is because you want minetest_game to be specific to your preferences.  You're not all that willing to defer to others, even when it's like 5 against 1.
20:17 VanessaE     yes, you used to run stuff by me, but I'm still only one person and not the most reliable bellwether for the community\
20:17 VanessaE     (as I have my own preferences also)
20:18 PilzAdam     well, everyone has their personal preferences
20:19 PilzAdam     we need to pick someone to design the game
20:20 VanessaE     that would have the same problem we have now - one person at the helm.
20:20 PilzAdam     and we cant decide on each feature with a poll, since that would make a rather inconsistent game overall
20:20 PilzAdam     what we could do is get people write down their goals, and then vote on that
20:21 PilzAdam     but then we need to keep in mind that we still have to work with minetest_game, and cant come up with a completly new game
20:22 VanessaE     well at this point we're getting down to individual features and tweaks now.  It's not like anyone's proposing to rewrite the game or start over
20:22 Sokomine     yes, right now it's just that feature. it really annoys me a lot
20:23 VanessaE     add nore's crafting table and my 6d lib, get rid of the privatized locked chests, etc.
20:23 VanessaE     no one's saying to replace dirt, stone, cobble etc with other stuff or to get rid of the core gameplay
20:23 Sokomine     there is a workaround usually - skip the locked chests and take alternatives like technic or homedecor which do have the old behaviour and are not a test for patience every time you want to check where to put items
20:23 PilzAdam     a lot of single features make up a game, though; and just merging them randomly creates that incosistent game that I was talking about
20:24 VanessaE     define "inconsistent".
20:24 Sokomine     it's true that there can be very diffrent opinions about many points...
20:24 VanessaE     I mean, inconsistent with *what* exactly?
20:24 PilzAdam     a game without a goal, just random features glued together
20:24 VanessaE     0.4.x is already highly inconsistent if you compare it to, say, 0.3.x
20:24 PilzAdam     kinda like minetest_game is currently
20:25 VanessaE     as in, the current game bears only passing resemblance to the old one..  so "consistent" needs to also define a base.
20:25 sapier1      imho engine shouldn't provide features as of locked chest but provide generic mechanisms to implement it in game
20:25 Sokomine     for me, minetest_game defines the basics all servers are based upon - the common ground. to make it really enjoyable, a lot of features (=mostly blocks to build with) are added by the diffrent mods
20:26 VanessaE     PilzAdam: what you want to say is that the game has no direction, not that it's "inconsistent".
20:26 PilzAdam     yes
20:27 VanessaE     perhaps it hasn't, but that should not stop us from working on the little stuff.  a direction might even emerge from doing just that.
20:27 VanessaE     at the same time, G*d forbid we should ever end up with "the end" or anything even remotely similar, as MC has.
20:27 VanessaE     that would take the concept of "direction" way too far.
20:28 VanessaE     so maybe the direction should be "where your imagination will take you"\
20:28 VanessaE     by that I mean, what's wrong with the game just being open-ended to begin with?
20:29 VanessaE     it's like LEGO.  when it first became popular, the majority of sets had no specific plan.
20:29 PilzAdam     that is one possible direction for minetest_game
20:29 VanessaE     it was "here are your bricks, here are a couple of examples of what can be done.  have fun!"
20:29 PilzAdam     others would go into a survival direction; or have the focus on the dungeons (as c55's original idea)
20:30 PilzAdam     the problem is that we need to decide on one direction; and base every merge on that decision
20:31 VanessaE     for the longest while, the company has this obsession with themed sets and specific plans..  every set came with instructions to build one or two particular things, but nothing that really helped the customer just...play.  Now the old "do anything you want to" sets are making a resurgence.
20:31 VanessaE     had*
20:31 VanessaE     PilzAdam: if we base every merge on that one decision, what happens when we decide that this was the wrong direction?
20:32 VanessaE     a change of "direction" after that much effort will lead to the same situation you complain of now
20:32 PilzAdam     how so?
20:33 VanessaE     because suddenly you go from, let's say, a dungeon themed game to a space theme.
20:33 VanessaE     what are you gonna do with an iron maiden or a rack, on a space station?
20:33 VanessaE     it'll begin to look like "a random collection of stuff" (paraphrasing) again
20:33 PilzAdam     huh? I was talking about making a decision about a direction once, and never change that again
20:33 VanessaE     exactly
20:33 VanessaE     you can't do that.
20:34 PilzAdam     if we want another direction, we create a new game
20:34 VanessaE     that's a sure recipe for failure.
20:34 VanessaE     and then you end up with a repeat of the common/build/survival fiasco.
20:34 PilzAdam     that didnt work because the games were too similiar
20:35 VanessaE     if you want a game with actual direction, better to leave minetest-game as the random collection of stuff that it exists as now and start something entirely new.
20:35 VanessaE     e.g. what you did with Pilztest (sp) is a good plan
20:35 Sokomine     hmmm. game is always...such a big term. minetest - to me - is the game, even though diffrent sets of mods may almost - but not quite - feel like a diffrent game. in the language prefered here, minetest would always be the engine, and diffrent modsets be considered diffrent games
20:35 VanessaE     it didn't work because people couldn't reliably write mods anymore - shit kept breaking.
20:36 VanessaE     "oh this needs X, but X is in that other game and I need this to run in this first game", etc.
20:36 PilzAdam     if the games werent so similiar then people would start writing mods for one game only
20:37 VanessaE     people won't do that.  that's the thing.
20:37 Sokomine     why? one of the great advantages is that most mods don't have too many dependencies
20:37 PilzAdam     e.g. someone could write a mod for OCD, but wouldnt intend to run it on pilztest
20:38 Sokomine     and i think most users prefer mods with few dependencies as they're easier to install
20:38 Sokomine     that's not the way it is. mod xyz may work very well with pilztest - and utterly break a functionality you liked very much and consider basic for pilztest but that the modder just didn't wish to be that way
20:38 VanessaE     minetest_game needs to remain a base game, it needs no real direction imho, other than "have fun"
20:40 PilzAdam     others would like to see a real direction for minetest_game
20:41 Sokomine     that desired direction may vastly differ
20:41 Sokomine     think of it like a lib
20:41 VanessaE     but we can't let this call for "direction" turn minetest_game into something others won't want to base their games and/or servers in
20:41 VanessaE     on*
20:41 PilzAdam     of course a decision on a direction will piss some people off
20:41 PilzAdam     thats good, then they will make their own games
20:42 VanessaE     some?  It has the potential to piss off *everone*
20:42 Sokomine     from the point of view of the mod collections and the modders, minetest_game is the basic library, while from the point of the minetest engine, minetest_game might be the application
20:42 VanessaE     *everyone**
20:42 PilzAdam     VanessaE, depends on the mechanism we use to choose the direction
20:42 Sokomine     "base their games/servers on" - that's what i think minetest_game is for
20:42 Sokomine     you can also run it without mods if you want to have it plain
20:43 VanessaE     have you looked at how vastly different all the various games are now?
20:43 PilzAdam     they are not very different, because most of them base on minetest_game
20:44 VanessaE     on the one end, there's minetest_classic and mt_nostalgia.  In the middle somewhere is my game.  beyond that, technic game.  On the far end might be pilztest.
20:44 VanessaE     and that's just one axis of the graph.
20:45 celeron55    my opinion is that minetest_game should be completely halted and work in game content should be continued in a few non-centralized teams
20:45 VanessaE     well I guess minetest classic is a continuation of 0.3.x rather than a game for 0.4.x but you get the point
20:45 VanessaE     celeron55: you mean the multiple-games-but-pick-better-names discussion from before?
20:46 celeron55    VanessaE: along those lines, yes
20:46 RealBadAngel hi all
20:47 VanessaE     celeron55: perhaps so, but there are still a few things the base "game", or let's call it a library at this point, needs.
20:47 VanessaE     hi RBA
20:47 celeron55    and what are those things?
20:48 celeron55    the non-centralized teams can of course discuss with each other what they want to consider the common base
20:48 VanessaE     celeron55: oh stuff like darkrose's workbench (but with nore's retuned code), that 6d library I contributed, maybe a couple more random block types, that sort of thing.  Nothing big, per se.
20:48 celeron55    but that base shouldn't be what end users generally stumble upon when they first try minetest
20:49 PilzAdam     people seem to be comfortable in the current situtation, that minetest_game is just a base for mods; people dont want the system to change were games are actual games
20:49 PilzAdam     ("people" being VanessaE and Sokomine)
20:50 VanessaE     the biggest contention I see from modders is that they just don't want to depend on other, third-party mods.  a bigger crafting table, for example, is immediately useful to all mods out there, should their authors choose to use the expanded feature.
20:51 VanessaE     but no one uses it because "it isn't included with the game" or similar.
20:51 celeron55    i already hate minecraft-like crafting so much that i can't think about adding more of it without stuff coming up my throat 8)
20:51 VanessaE     celeron55: nonono
20:51 VanessaE     the workbench I refer to adds larger-than-3x3 crafting grids
20:52 celeron55    ...and?
20:52 celeron55    it's more of the same thing
20:52 VanessaE     oh wait, I misread that :D
20:52 Sokomine     hm, i just don't see the diffrent mod collections as entirely diffrent games. i want people to be able to choose the mods that conform to their gameplay. for people starting (and doing those youtube let's plays), a broader set of mods may help
20:52 VanessaE     I read that as "I hate the MC way of 2x2 grids and a 3x3 table" :)
20:53 proller      most peoples nothing know about mods and just wants good game
20:54 VanessaE     celeron55: I suppose one could make a cauldron mod, where you just throw random ingredients in (including various forms of magic potions and powders) and out comes pre-formed blocks and tools ;)
20:54 RealBadAngel celeron55, you may find this interesting: http://www.youtube.com/watch?v=3jV7Oxw-IJo
20:55 celeron55    VanessaE, Sokomine: nothing stops you from providing the build-your-own-game subgame as one of the independent-ish subgames
20:56 VanessaE     celeron55: actually that's what my game aims to be.  it probably fails a bit at it, but yeah
20:56 Sokomine     crafting in mt is much better than in mc, yes. those alternate crafting tables are most likely for more complex receipes. coming up with a good, memorable receipe idea gets dificult, and we get conflicting receipes sometimes
20:57 VanessaE     RBA:  ramp the sun up towards white a lot faster than you do now, but that's pretty good
20:57 Sokomine     my personal preference is to have specialized machines to craft what is desired (i.e. table saw). to some degree those are crafting tables as well
20:57 VanessaE     (by the time the sky is fully brightened, the sun should be nearly white)
20:57 RealBadAngel tinting is defined by tonemap, it can be easily adjusted
20:58 VanessaE     RealBadAngel: as a test, try it with Taoki's tinted fog pull
20:58 VanessaE     I suspect the two will work well together
20:59 RealBadAngel btw, tinting a tetxure is quite easy, easier than i thought
21:00 RealBadAngel first, lighting have to be turned on for a material, put tintin color as emissive light for this material, original texture shall be grayscale
21:00 RealBadAngel and thats all
21:02 RealBadAngel this way we can tint any node like grass or water depending on biome for example
21:03 NakedFury    finally greyscale?
22:28 RealBadAngel i made pull with sun/moon code, https://github.com/minetest/minetest/pull/967
22:28 RealBadAngel if some1 wanna try and comment it out
22:29 RealBadAngel ive made textures that look like old default sun and moon, but they can be replaced with anything
22:37 Taoki        RealBadAngel: When will the new shaders be in?
22:38 RealBadAngel i got still lotsa things to code
22:38 Taoki        ;( ok
22:39 RealBadAngel i need reflection and refraction textures atm
22:39 RealBadAngel just made a short break and made sun/moon thingy with tinting
22:40 Taoki        Yes, looks very good... +1
22:40 Taoki        Hope that can be added without much delay too
22:41 RealBadAngel c55 should take a look on it and merge it with #960 propably
22:41 RealBadAngel it could be more complete together with skybox
22:42 Taoki        #960 will probably break my colored fog. And, it will likely be merged before it and do so. Just as I expected when I made that code.
22:42 RealBadAngel i dont think so
22:42 RealBadAngel i mean just take a look on it
22:43 RealBadAngel tinting popped to be just trivial to achieve
22:44 RealBadAngel i would like to use that method to tint grass depending on biomes
22:44 RealBadAngel maybe leaves too?
22:45 RealBadAngel so jungles could be juicy green, swamplands almost brown for example
22:46 NakedFury    Minecraft style
22:46 RealBadAngel not only minecraft
22:46 NakedFury    grass closer to deserts can start losing color too
22:47 RealBadAngel it could vary on humidity
22:47 Taoki        RealBadAngel: I meant the Lua command to customize sky colors. Would that ont conflict?
22:48 Taoki        If not that's good then
22:48 RealBadAngel youre talkin now bout c55's pull, not mine
22:49 Taoki        ah
22:49 Taoki        Yeah... either way my code is probably skrewed as I expected.
22:49 RealBadAngel i commented that pull already, imho using lua to set skybox is wrong way
22:49 Taoki        My colored fog will prolly be lost before it's merged.
22:50 RealBadAngel engine shall check for skybox files, and if provided use them
22:50 RealBadAngel lua way makes it impossible to change skyboxes with texture packs
23:24 sapier1      ok after 3 days of investigation I'm almost sure I know what's happening in our visual studio localization issue:
23:24 sapier1      1) gettext is working correct returning e.g. russian characters
23:25 sapier1      2) setlocale(LC_ALL,"") sets System default locale
23:25 sapier1      3) setlocale(LC_NUMERIC,"C") sets more than only numeric locale
23:26 sapier1      so if you set system default locale settings correct everything is fine (you need to set numeric locales to match english)
23:27 sapier1      using LANG/LANGUAGE only switches gettext
23:27 sapier1      in mingw setlocale works as expected
23:28 sapier1      so my conclusion vs2012 maybe even 2010 is terribly broken and is tricky to fix ... I haven't found a way to do so so suggestions are welcome
23:30 sapier1      AND the locale setting was most likely broken before to it just didn't matter ... it does matter now because someone was as smart as sending text from lua -> core -> lua converting at any transition from wchar to char and back
23:59 Exio4        what do you think about moving "flat" to its own mapgen?\