Minetest logo

IRC log for #minetest-dev, 2013-10-26

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

All times shown according to UTC.

Time Nick Message
00:46 salamanderrake joined #minetest-dev
01:23 jojoa1997 joined #minetest-dev
01:30 jojoa1997 joined #minetest-dev
02:22 ecube joined #minetest-dev
02:30 Miner_48er joined #minetest-dev
03:31 psedlak joined #minetest-dev
04:41 OWNSyouAll_DESKT joined #minetest-dev
05:24 werwerwer_ joined #minetest-dev
06:15 deltib joined #minetest-dev
06:23 nore joined #minetest-dev
07:27 Calinou joined #minetest-dev
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?
07:51 Gethiox joined #minetest-dev
08:13 darkrose joined #minetest-dev
08:13 darkrose joined #minetest-dev
09:11 ImQ009 joined #minetest-dev
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
09:32 Jordach joined #minetest-dev
09:39 Taoki joined #minetest-dev
09:59 PilzAdam joined #minetest-dev
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:14 Ritchie_ joined #minetest-dev
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 *
10:58 sapier joined #minetest-dev
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 SpeedProg joined #minetest-dev
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 psedlak joined #minetest-dev
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 Zeitgeist_ joined #minetest-dev
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:16 sapier left #minetest-dev
12:24 nore so, PilzAdam, are you ok with #966?
12:24 ImQ009 joined #minetest-dev
12:47 Gethiox2 joined #minetest-dev
12:52 kahrl joined #minetest-dev
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:05 hmmmm joined #minetest-dev
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 ;)
14:29 IceCraft joined #minetest-dev
14:32 IceCraft joined #minetest-dev
14:33 IceCraft joined #minetest-dev
14:33 IceCraft joined #minetest-dev
15:06 zat joined #minetest-dev
15:27 mrtux joined #minetest-dev
15:31 smoke_fumus joined #minetest-dev
15:36 mrtux_ joined #minetest-dev
15:42 mrtux_ joined #minetest-dev
15:48 Calinou joined #minetest-dev
15:52 mrtux joined #minetest-dev
15:53 mrtux joined #minetest-dev
16:05 NakedFury joined #minetest-dev
16:22 OWNSyouAll_DESKT joined #minetest-dev
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 OWNSyouAll_DESKT joined #minetest-dev
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 rubenwardy joined #minetest-dev
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 :-)
17:40 mrtux joined #minetest-dev
17:40 mrtux joined #minetest-dev
17:41 mrtux joined #minetest-dev
17:58 mrtux joined #minetest-dev
18:09 mrtux joined #minetest-dev
18:42 ImQ009 joined #minetest-dev
18:54 OWNSyouAll joined #minetest-dev
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 psedlak joined #minetest-dev
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:36 sapier1 joined #minetest-dev
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 RealBadAngel joined #minetest-dev
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:05 Miner_48er joined #minetest-dev
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?\

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