Time  Nick           Message
00:14 luizrpgluiz    have any target date for the release of version 0.5.0?
00:15 est31          ~topic
00:15 ShadowBot      est31: Minetest core development and maintenance. 0.4.13 release scheduled for August 10 2015. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/
00:15 hmmmm          est31:  the problem is that the entire protocol has to change just for one small thing
00:15 luizrpgluiz    I'm looking forward to the news of the new version if it does not change the api also
00:15 hmmmm          wtf who scheduled 0.4.13
00:15 est31          hmmmm, me
00:15 hmmmm          come on you're killing me guys
00:16 hmmmm          we need to have a critical mass of people able to help with the releases around too
00:16 est31          hmmmm, thats no hard date, if we have bugs not solved by that date, we just wait :)
00:16 hmmmm          crecca just left
00:16 hmmmm          meh..
00:16 hmmmm          crecca:  yes
00:22 RealBadAngel   hmmmm, are you ok with the pr now?
00:22 hmmmm          hold on
00:23 hmmmm          I thought you said there was a difference between the >= 1.999 and the > 2.0?
00:23 hmmmm          in fact now one of them is >= 2.0 and the other is > 2.0!
00:24 luizrpgluiz    lol
00:25 RealBadAngel   ouch, havent pushed updated one
00:27 RealBadAngel   just forgot about last update waitin, now its consistent
00:28 hmmmm          did you remember to make the corresponding PR for mtgame?
00:29 luizrpgluiz    I apologize that I did not understand anything, but I think the minetest should have more efficient updates or at least try to experience a new graphical engine.
00:29 hmmmm          btw you don't have to change anything, just so you know, the id parameter for getTexture is optional
00:29 hmmmm          so if you don't intend to use the id for anything just write texture = getTexture(tname);
00:29 est31          RealBadAngel, you dont have to fix the mesh thread lag, also not have to add the right shift IMO
00:30 est31          because we already dont accept right shift as sneak key
00:30 hmmmm          luizrpgluiz:  we are looking into separating irrlicht into an abstraction layer
00:30 est31          are we?
00:30 hmmmm          yeah
00:30 hmmmm          obviously not soon
00:30 hmmmm          but it's in the plans
00:30 est31          well thats good
00:30 hmmmm          then someday maybe we can move to something modern like OpenSceneGraph
00:31 VanessaE       hmmmm: when he last said it, Zeno was ~40% done with that.
00:31 VanessaE       and this was weeks ago
00:31 hmmmm          really!?!?
00:31 hmmmm          sweety
00:31 VanessaE       yes
00:31 hmmmm          sweet*
00:31 est31          wow
00:31 hmmmm          no wonder why zeno is staying away
00:31 est31          with the openscenegraph, or the abstraction
00:31 hmmmm          probably the abstraction
00:31 VanessaE       the abstraction.  if I understood him correctly anyways
00:31 hmmmm          abstraction is needed first
00:31 est31          yea
00:32 RealBadAngel   offtopic. who else can see glitched wield hand?
00:34 RealBadAngel   https://imgrush.com/sjYy4sd6jCKV.png
00:35 hmmmm          which settings do I need to have enabled to see it?
00:37 RealBadAngel   atm i can see that glitch no matter the settings
00:39 luizrpgluiz    hmmmm: why not do a test with another graphical engine and is easier to use and has more things to use in minetest and that offers graphic and clear support and open source ?
00:39 hmmmm          because it's not as easy as just switching a library
00:39 hmmmm          you need to re-code just about everything
00:41 est31          ~ping
00:41 ShadowBot      pong
00:45 luizrpgluiz    Yes, I understand you have to reprogram all the same game that moves to another scripting language also, and of course some engines may offer better things for the development be more effective.
00:45 paramat        will push #2909 soon
00:45 ShadowBot      https://github.com/minetest/minetest/issues/2909 -- Minimal: Remove recently added unnecessary nodes by paramat
00:47 paramat        RealBadAngel, i only see that wield glitch when using fsaa
00:49 luizrpgluiz    someone already used the OGRE3D in some developing games before?
00:50 VanessaE       paramat: in UjE's screenshot, fsaa was not disabled (says his config file anyway)
00:52 RealBadAngel   for me turning off fsaa helped
00:53 est31          why, luizrpgluiz we can stick with lua
00:53 est31          the engine has nothing to do with us using lua
00:55 paramat        the wield glitch in UjE's screenshots is a different wield glitch (i think)
00:55 VanessaE       paramat: well the glitch I refer to is the pattern on the left-facing side of the hand.
00:57 RealBadAngel   hmmmm, flags_texture = getTexture(tname); that simply doesnt compile
00:57 hmmmm          what is the error?
00:58 RealBadAngel   http://pastie.org/10291064
00:59 RealBadAngel   pretty funny because i can see such call in wieldmesh.cpp and there it works
00:59 luizrpgluiz    est31: it was an example, if you want to use another graphics engine in the game, I have nothing against LUA, I think even easier to develop mods and even programs, but it would be good to use a graphical engine that has at least support the scripting language
00:59 hmmmm          i see why
01:00 RealBadAngel   yes?
01:00 est31          luizrpgluiz, even if, most mods are written in lua, and i dont think we should give the full api to untrusted mods
01:00 hmmmm          RealBadAngel: on tile.cpp:333, add =NULL to id
01:01 est31          we snouldn't use engine shipped scripting languages imo
01:01 hmmmm          the function prototype is correctly defined in the publically exposed ITextureSource interfaces, that is, with id as an optional parameter
01:02 hmmmm          it just so happens that they have matching function prototypes so it links correctly
01:02 hmmmm          only that id is not defined as an optional parameter in the private implementation, TextureSource
01:03 RealBadAngel   i see
01:03 RealBadAngel   now it compiles
01:05 luizrpgluiz    est31: Yes, in a way I agree with you, what I meant was it would be great to use another graphics engine that has more good things and that it is aid to better develop minetest the game or any future projects :)
01:10 RealBadAngel   hmmmm, i will make commit for mt game as soon as this gets merged
01:35 RealBadAngel   hmmmm, better? https://github.com/RealBadAngel/minetest/commit/e9e07e637340e108b75618c507e1df5f9868363d#diff-8b1361a90a460ea33ecf3db026997f8aR2062
01:36 est31          RealBadAngel, dont update the protocol version yet
01:37 est31          if I add utf-8 chat, it would need additional update
01:37 est31          if we can do it together, its better
01:37 est31          in one protocol bump
01:37 RealBadAngel   i can wait, no problem
01:38 RealBadAngel   do you have that pr ready?
01:38 est31          yea
01:38 est31          only needs reviews
01:38 paramat        now pushing 2909
01:39 est31          paramat, do you have any reviews for that
01:39 est31          hmmmm is all crazy about 3 reviews for people
01:40 est31          i dont say blocking is good, but if, it should be fair
01:40 est31          for everybody
01:40 est31          dont you think
01:41 paramat        hmmmm #2909 if you want to check
01:41 ShadowBot      https://github.com/minetest/minetest/issues/2909 -- Minimal: Remove recently added unnecessary nodes by paramat
01:44 paramat        i announced the PR twice earlier, but didn't highlight hmmmmm
01:44 RealBadAngel   paramat its ok with me (i will just have to rebase mine)
01:45 RealBadAngel   btw, after VanessaE and cheapie crying that stone is horrible, i made new normalmap
01:45 RealBadAngel   https://imgrush.com/4GAPi-hoeF4F.png
01:45 est31          I admit that paramat's code has very high quality
01:45 RealBadAngel   what do you think about this one?
01:46 cheapie        RealBadAngel: A little bit on the bumpy side, but I *love* the sharpness.
01:46 est31          I cant recall a change of him that doesnt have regressions
01:46 cheapie        Much, much better than the old one.
01:46 paramat        yeah better
01:46 VanessaE       way better.
01:46 est31          I cant recall a change of him that has regressions Ü
01:46 est31          *
01:46 est31          sorry
01:47 est31          too much negations here :)
01:53 est31          paramat, 2909 looks good
01:54 est31          as you know what you are doing, i guess you can push it with only one +1
01:56 paramat        well it's usually a good idea to have hmmmmm check my PRs, but if he's busy sometimes i go ahead anyway, being a sortof 'deputy mapgen maintainer'
01:57 paramat        i'll wait a little longer
02:03 hmmmm          paramat:  yes, looks good
02:03 hmmmm          realbadangel: yes, looks good
02:04 paramat        thanks, you first RBA, there's no conflicts it seems
02:05 RealBadAngel   hmmmm, btw https://imgrush.com/SwA4emRCW2Jy.png
02:05 RealBadAngel   look at the normal map to the left
02:05 VanessaE       you mean to the right :P
02:05 exio4          when in doubt, go with the center
02:06 RealBadAngel   you can see that gradients on the top and bottom edge are connecting
02:06 paramat        ah this is less bumpy? i prefer this
02:06 VanessaE       yeah I see it, RBA
02:06 RealBadAngel   thats why i had to clamp non seamsless texture
02:06 RealBadAngel   and to the right ofc ;)
02:08 est31          <Routh> RealBadAngel: How difficult would it be to add code that adds a logical serial number to trees with spawn_tree()? The thought is to increase mod interoperability for situations like the one outlined here: https://github.com/HybridDog/treecapitator/issues/2
02:08 est31          <est31> I think this is more a question for paramat or hmmmm
02:09 RealBadAngel   i think hes talkin bout l-system ones
02:09 VanessaE       he is.
02:09 paramat        oh crumbs
02:09 VanessaE       spawn_tree() would need to take an extra param in addition to pos and deg, to let the code set some metadata to each node placed, to achieve what he wants.
02:09 VanessaE       def*
02:10 RealBadAngel   theres a seed already used
02:10 VanessaE       no, this would need to be something that could be unique to each individual tree
02:11 VanessaE       so that two trees that intermingle won't get mixed up by, say, technic chainsaw or treecapitator mod
02:11 RealBadAngel   like what? naming it like "my lovely tree #219" ? ;)
02:11 ShadowBot      https://github.com/minetest/minetest/issues/219 -- Use shift as the descent control on ladders and when flying
02:11 RealBadAngel   oops ;)
02:11 VanessaE       RealBadAngel: well yeah roughly that but simpler.  :P
02:11 Routh          Or just an incremental multiplier of 42.
02:11 VanessaE       42? heh
02:12 Routh          It is the answer.
02:12 VanessaE       it doesn't much matter WHAT gets stored, as long as it's the same for all nodes that are placed for a given tree, and unique to each individual tree.
02:13 RealBadAngel   a seed stored in meta?
02:13 VanessaE       not the seed.
02:13 VanessaE       a serial number.
02:13 VanessaE       something that can be provided by a mod, on a call-by-call basis
02:13 est31          it fits into param2 or 1 too i guess
02:14 RealBadAngel   i will think about it
02:14 VanessaE       est31: that might work too, param2 to be specific
02:14 est31          you can even take the originating position, feed that to a pseudorandom, and then fill param2
02:14 VanessaE       it's not like the value needs much of a range
02:14 est31          yea
02:15 est31          so even a bool option would suffice for this usecase
02:15 est31          or multiple types
02:15 est31          if bool and true, then store it in param2
02:15 est31          if string, store it in meta
02:17 est31          hrmm, how should a value like this be called?
02:17 est31          in the treedef
02:20 VanessaE       enable_unique_ids  ?
02:20 est31          is param1 or param2 a better option?
02:20 VanessaE       param2
02:20 VanessaE       param1 is used for lighting, but in an lsystems tree, param2 is useless otherwise
02:21 VanessaE       (you can't set unique facedirs in the trees' nodes anyway)
02:21 paramat        i don't think it's worth doing all this just for a problem with treecapitator
02:22 VanessaE       paramat: think of technic's chainsaw.  it can take down several trees at once, including houses near them built with the same wood.  Definitely undesirable.
02:22 paramat        l-system maybe, but only because it's not used in mapgen =)
02:23 est31          stacks dont have param 1 or 2?
02:23 RealBadAngel   imho only using meta can solve this
02:23 paramat        still not worth it
02:23 est31          so if you dig a node and place it, it defaults to 0
02:23 est31          ?
02:23 VanessaE       est31: that's a good question.
02:24 est31          meta is bad because its inefficient
02:25 RealBadAngel   so idk atm
02:26 paramat        better that chainsaw and treecapitator are rewritten to avoid the problems, instead of slowing treegen
02:26 est31          there is no other way i think
02:27 est31          how can you distinguish generated structures from hand built ones?
02:27 est31          and if you connect two trees with trunk blocks, it fails too
02:28 est31          paramat, #2909 has now 2 +1 one from me, one from kwolekr
02:28 ShadowBot      https://github.com/minetest/minetest/issues/2909 -- Minimal: Remove recently added unnecessary nodes by paramat
02:28 est31          you can push
02:28 paramat        okay i'll go first then
02:29 paramat        now pushing
02:29 hmmmm          grr
02:30 VanessaE       est31: I'd say just use param2, and paramtype2 = "identifier" or something.  keep it simple. :)
02:30 VanessaE       (for once, I'm NOT suggesting overkill :) )
02:31 est31          what would be overkill in your opinion
02:31 Routh          I'm also curious how two trees that intermixed during gen would be differentiated by any mod if they are of the same type, even if the coder is a genious..
02:31 VanessaE       strings in metadata :)
02:32 est31          ok I fix a crash with areastore, then i code the treedef extension
02:38 hmmmm          jeez
02:38 hmmmm          okay
02:38 hmmmm          est31:  I fixed the dependency on the previous commit
02:38 paramat        complete
02:38 est31          ?
02:38 hmmmm          had to squash, reset, amend
02:38 est31          ah
02:39 est31          that commit
02:39 est31          ok then
02:39 hmmmm          i did things in the wrong order in the first place
02:41 hmmmm          hmm
02:45 hmmmm          i can replicate the FSAA bug
02:48 est31          is pcgrandom a good pseudorandom if want to get a unique param2 from a v3s16 position? are there more lightweight pseudorandom functions for that?
03:04 hmmmm          est31:  I don't get what you mean
03:04 hmmmm          are you saying you want a lightweight hashing function?
03:05 est31          hmmmm, yes
03:05 est31          pcgrandom is already lightweight
03:05 hmmmm          random functions are not meant for that
03:05 hmmmm          in theory, due to the properties of pcgrandom, you should be able to, but i wouldn't trust it
03:05 est31          we cant store the full position in the param2 can we
03:06 hmmmm          no we can't
03:06 hmmmm          why don't you implement CRC-8?
03:06 est31          ?
03:06 est31          CRC is a checksum
03:06 est31          ah i see, it does the same as a pseudorandom does
03:07 est31          so why can pcgrando not be trusted
03:08 hmmmm          I don't know really
03:08 hmmmm          CRC is purpose made for this, however
03:31 hmmmm          where did RBA go
03:31 hmmmm          I thought he was going to push his commit
03:32 hmmmm          https://github.com/kwolekr/minetest/commit/5006ce82609b2260f191b132f2dabcfdb06d6e20
03:32 hmmmm          PTAL
03:35 est31          if he pushes he should not increase the protocol version just yet
03:35 est31          I want to get the utf8 chat in together with it
03:35 hmmmm          fair enough
03:36 est31          he can push, just not increase the #define PROTOCOL_VERSION_MAX
03:37 hmmmm          how close is the utf-8 pr to being finished??
03:37 est31          its ready for review
03:37 hmmmm          ok
03:37 est31          only needs review and testing
03:40 est31          and rebase
03:40 est31          but there are no real large changes to rebasearound
03:43 hmmmm          re-review my commit?
03:43 hmmmm          I did it a slightly different way
03:48 est31          i havent reviewed 5006ce82609 yet
03:50 hmmmm          ugh
03:50 hmmmm          am I the only one who hates the Buffer class
03:50 hmmmm          why do people use it
03:51 hmmmm          really, i can't wait until C++11 so we can get move constructors
03:51 est31          https://github.com/minetest/minetest/blob/990a96578f20244626b6b9f67f8e79a7e2e614ea/src/util/numeric.h#L62
03:51 est31          what do we do here
03:51 est31          why not simply return p / d
03:51 hmmmm          it's confusing, isn't it? :(
03:51 est31          why that check
03:51 hmmmm          that's for rounding down
03:52 hmmmm          integer division in C and C++ rounds toward zero
03:54 est31          so to get the edges of the mapblock a coord is inside, I do val mblock = getContainerPos();
03:54 hmmmm          39 / 20 = 19, -39 / 20 = -19, but what we actually want is -39 / 20 = -20, because the container "0" contains points 0..d, and -d..1 is contained in "-1"
03:54 est31          then val pos1 = mblock.X * r , mblock.Y * r, mblock.Z * r
03:54 hmmmm          yeah
03:54 est31          and valpos2 = pos1 + (r,r,r)
03:55 hmmmm          - (1,1,1)
03:55 hmmmm          remember coordinates are inclusive
03:55 est31          ?
03:56 hmmmm          p1 = v3s16(blockpos.X * MAP_BLOCKSIZE, blockpos.Y * MAP_BLOCKSIZE, blockpos.Z * MAP_BLOCKSIZE);
03:56 hmmmm          p2 = p1 + v3s16(1,1,1) * MAP_BLOCKSIZE - v3s16(1,1,1);
03:56 hmmmm          also, check out getNodeBlockPos() in mapblock.h
03:57 est31          ah
03:57 est31          yea
05:11 est31          wow
05:11 est31          do we really copy the TreeDef twice BY VALUE?
05:15 kahrl_         technically, C++ (before C++11, IIRC) does not guarantee that integer division rounds towards 0, it could round towards -inf for example
05:16 kahrl_         but I'm very confident that all of the compilers we target round towards zero
05:19 johnnyjoy      disorder
05:20 johnnyjoy      Sorry, wrong window.
05:24 VanessaE       [off] since he won't come over here, kahrl_ and hmmmm could you poke into #minetest and give this guy a good thrashing? Soni that is.
05:54 est31          ok #2910
05:54 ShadowBot      https://github.com/minetest/minetest/issues/2910 -- Treegen: Add enable_unique_ids option by est31
05:56 VanessaE       est31:
05:57 VanessaE       oops,.
05:57 VanessaE       it looks like you missed the secondary leaves and the fruit
05:57 VanessaE       er you got the secondary leaves
06:00 est31          its untested though
06:04 VanessaE       est31: don't forget the fruit?
06:04 est31          added
06:05 est31          ah forgot git push
06:05 est31          pushed
06:08 VanessaE       looks like it should work.
06:10 VanessaE       needs rebased
06:11 est31          ?
06:12 VanessaE       it generates a merge commit when I pull against HEAD.
06:13 est31          dont use pull then
06:13 VanessaE       heh
06:16 VanessaE       what the...?
06:16 VanessaE       2015-07-14 02:16:08: ERROR[main]: A serialization error occurred:
06:16 VanessaE       2015-07-14 02:16:08: ERROR[main]: deSerializeLongString: string too long
06:16 VanessaE       2015-07-14 02:16:08: ERROR[main]: The server is probably  running a different version of Minetest.
06:17 est31          hmmmm, ^
06:17 est31          his fault
06:18 est31          well this is trial and error
06:18 est31          seems we have to raise the limit
06:18 VanessaE       lemme back it off by one commit and see how that fairs.
06:19 VanessaE       (fares?)
06:20 hmmmm          ohh
06:20 hmmmm          VanessaE, what were you doing
06:20 kahrl_         why not add the problematic string length to the error message?
06:20 VanessaE       yep, it works at HEAD~1
06:20 hmmmm          kahrl, will do
06:20 hmmmm          but seriously, 8 MB strings?
06:20 hmmmm          really??
06:20 hmmmm          what is doing this?
06:21 kahrl_         signs?
06:21 hmmmm          sounds like a case of poor design
06:21 VanessaE       hmmmm: I deleted and started my usual plantlife test map.
06:21 VanessaE       that's all.
06:21 hmmmm          signs take up a few kb
06:21 VanessaE       no signs.
06:21 VanessaE       virgin world.
06:21 hmmmm          alright lemme try this
06:21 hmmmm          i thought 8mb would be a decent compromise
06:22 VanessaE       somehow I doubt that it's receiving an 8MB string?
06:22 hmmmm          oh.. it is.
06:23 hmmmm          so instead of just increasing the limit to accomodate whatever it is, i'd like to fix the design of the long string that's larger than 8mb
06:23 hmmmm          i'm sorry that's freaking ridiculous
06:23 hmmmm          if it's really necessary and valid, that's an easy opening for an attacker to DoS a server or a client
06:24 est31          VanessaE, how large are your 512 textures
06:24 VanessaE       est31: I'm not using them here, but the biggest files there are perhaps 300 kB
06:24 VanessaE       most full-size ones are half that
06:25 VanessaE       aw crap
06:25 VanessaE       there's an issue with using param2
06:25 VanessaE       your code works fine, but param2 can't be used here because the trunks have to be able to rotate on place (e.g. horizontal)
06:26 est31          hrmm, param1 then?
06:27 VanessaE       can param1 even be used here?
06:27 est31          and only for the trunks?
06:27 VanessaE       I thought that was for light?
06:27 hmmmm          just tried plantlife + biomesdev, cannot reproduce
06:27 VanessaE       hmmmm: you may need moretrees to trigger that crash?
06:28 hmmmm          ewwww.
06:28 est31          perhaps we should make it crash when the server sends, and then look at the stacktrace
06:29 hmmmm          solid leaves + waving leaves shader = gross
06:29 est31          VanessaE, https://github.com/minetest/minetest/blob/990a96578f20244626b6b9f67f8e79a7e2e614ea/src/mapnode.h#L126
06:29 est31          so we will have to leave out leaves
06:32 VanessaE       est31: no good
06:33 VanessaE       leaves form like 90% of a tree
06:33 hmmmm          what are you two babbling about
06:33 est31          #2910
06:33 ShadowBot      https://github.com/minetest/minetest/issues/2910 -- Treegen: Add enable_unique_ids option by est31
06:33 VanessaE       hmmmm: adding number value to each node placed by a given spawn_tree() call so that mods can identify one tree from another right next to it
06:33 est31          e.g. for chainsaws
06:33 hmmmm          lol, that's not happening
06:33 kahrl_         the serialization error reminded me that I wanted to do this: https://gist.github.com/kahrl/87cb5c55bcb9e67ff494
06:34 VanessaE       hmmmm: it's *optional*
06:34 hmmmm          whatever's left in param2 is whatever you have to work with
06:34 hmmmm          there simply is not enough space
06:34 VanessaE       there are I believe two bits free in param2
06:34 hmmmm          the "correct" way to do this is to create an entity at the same location as the tree
06:34 VanessaE       (at least in this particular context)
06:35 VanessaE       wat
06:35 VanessaE       with the way the engine handles entities???
06:35 est31          our entity support is incredibly buggy
06:35 VanessaE       and besides, the mod (in this case a treecapitator sort of thing) needs to be able to identify a tree no matter which node you hit
06:35 kahrl_         hmmmm: what about using the areastore to store this information
06:35 VanessaE       (and these things can stand 30 nodes tall)
06:36 hmmmm          maybe, shrug.  est, what do you say about that?
06:36 hmmmm          don't know how it works just yet
06:36 est31          areastore for trees?
06:38 hmmmm          vanessae:  try this: http://pastebin.ubuntu.com/11876138/
06:38 VanessaE       est31: I think the only sane way right now is metadata; I don't think that a two-bit value in param2 (bits 6 and 7) will be enough "resolution".
06:39 VanessaE       well 3 bits actually isn't it?
06:40 VanessaE       if so, that would be just enough I think.
06:40 est31          you can have different nodes for tree and tree mined
06:40 VanessaE       ew.
06:40 est31          then when you place tree mined, you can screwdriver it
06:41 est31          also, who runs with a screwdriver in the forest, and is abled to scredriver *parts* of trees
06:41 kahrl_         couldn't the treecapacitator mod simply use a better algorithm?
06:41 VanessaE       est31: if using more than one node per trunk/leaves/etc that wouldn't be necessary.  one can simply "drop" the rotatable node
06:41 est31          e.g. adjusting their graph search to not search "down"
06:42 kahrl_         yeah
06:42 kahrl_         I'm thinking of something like how Frozen Bubble determines which bubbles are floating and to be removed
06:42 VanessaE       kahrl_: the problem is when you have two or three trees intermingling
06:42 VanessaE       you don't want to cut down that willow next to the oak you just dug
06:43 VanessaE       or rather, you don't want to cut down the OTHER oak next to the one you just dug./
06:43 kahrl_         do moretrees have branches that extend downward from the trunk?
06:43 VanessaE       yes.
06:43 kahrl_         ok, then it's not a simple as not searching downward
06:43 VanessaE       willows, apple trees, and oaks all do that
06:43 est31          we have l system trees
06:44 est31          quite sophisticated
06:44 VanessaE       est31: can you try restricting your writes to param2 to just the upper 3 bits?
06:44 VanessaE       if I remember right, only the lower 5 are used for rotation in a regular node like a trunk
06:45 est31          VanessaE, yes i can, but in one of 64 cases we have a problem
06:45 VanessaE       ID collision?
06:45 est31          yup
06:45 VanessaE       that's what I figured.
06:45 est31          3 bits means 8 possible ids
06:46 est31          which means 64 possible combinations
06:46 est31          and 8 of them are harmful
06:46 est31          oh
06:46 est31          then its 8 out of 64 not 1
06:47 VanessaE       well, in practice, the trees never get closer than a few nodes apart, so it's not really possible to overlap more than about four trees
06:47 kahrl_         so how about this
06:47 VanessaE       so 8 IDs would probably still be enough
06:47 kahrl_         define the "current tree space" to be the infinite pyramid pointing downward whose tip is at the node that was cut by the player
06:47 est31          dunno how the 4 color theorem scales to 3d
06:48 kahrl_         any tree node that is connected to the cut node, but not to a tree node outside the current tree space will be removed
06:48 VanessaE       hmmmm: your patch doesn't apply.  looks like whitespace errors and wrong EOL. can you put it on a gist instead?
06:49 VanessaE       kahrl_: the problem there is that a tree doesn't really have its own "space".
06:49 est31          ok next idea
06:49 est31          what about storing "growing directions"
06:49 VanessaE       imagine planting say three oaks side by side, say 5m apart.  their trunks and leaves will all intermingle.
06:49 est31          this means, every trunk stores a "lower" trunk
06:49 est31          either directly below
06:50 est31          or in the case of branches another direction
06:50 est31          if we cut the tree, we walk these directions backwards
06:50 VanessaE       est31: right, but how do you differentiate between two trees where trunks are up against one another?
06:50 est31          only problem is we need 3*3*3 - 1, 8 is not sufficient
06:51 est31          VanessaE, well their directions will point in opposite directions
06:51 est31          more or less
06:51 VanessaE       not if you have two trunks, and one of them sends out a branch straight through the other
06:52 kahrl_         I would consider those to be merged into a single tree
06:52 hmmmm          VanessaE:  https://gist.github.com/kwolekr/b6ad270dec917622cfb3 ??
06:52 VanessaE       kahrl_: well branches of branches then.
06:52 VanessaE       these ain't default trees we're dealing with :)
06:54 VanessaE       hmmmm: nope.  your EOLs are good now but all your tabs are being converted to spaces.
06:54 hmmmm          grag
06:54 est31          just make a commit and push it to your github
06:54 kahrl_         perhaps the solution is to train a neural network, whose input is the node types surrounding a given tree node and whose output is whether to follow that tree node in the search ;)
06:54 VanessaE       kahrl_: haha
06:55 hmmmm          i give up
06:55 hmmmm          how do you create and share patches with people
06:56 hmmmm          gist keeps freaking converting tabs to spaces
06:56 VanessaE       ACE Editor, Indent Mode -> tabs
06:57 VanessaE       when you create a gist
06:57 kahrl_         try raw mode?
06:58 kahrl_         I created my latest gist without messing with editor settings and it still has tabs in the raw view
06:58 VanessaE       weird.  they came out as spaces here.  maybe it's what he's copying from then?
07:02 VanessaE       est31: anyway, ultimately 3 bits may not be a lot of uniqueness, but it's all we have left.  either that or store meta for each affected node.
07:03 VanessaE       in practice, that's gonna be a hell of a lot of nodes, but I don't see any other option that's also modder-friendly
07:03 VanessaE       (not that it matters to me how "friendly" it is, as such... I ain't the one who has to check these ID codes anyway :D )
07:06 VanessaE       actually, I have another idea.
07:07 VanessaE       like a sign, a tree trunk only has roughly 6 possible orientations you can rotate it to that the average person would be able to point out.  Suppose another paramtype2 is added where only the lower three bits store that rotation info.
07:07 VanessaE       that would leave 5 bits at the top that can be used for the ID code then
07:08 hmmmm          alright i got it https://gist.github.com/kwolekr/93eae7716ba528eeeb83
07:08 VanessaE       hmmmm: that works.
07:08 * VanessaE     compiles...
07:09 est31          one in 32
07:09 est31          so whats bad with param1
07:09 VanessaE       param1 is used for light data
07:09 est31          leaves can use the param2, no?
07:09 VanessaE       leaves don't use param2 at all.
07:10 est31          we use param1 only if light propagates through, no?
07:10 est31          like for leaves
07:10 est31          but not for trunks
07:10 kahrl_         leaves could be removed if and only if the leaf decay code would end up removing them
07:10 kahrl_         no params needed
07:11 VanessaE       hmmmm: nope.  still getting a serialization error.
07:11 VanessaE       2015-07-14 03:10:42: ERROR[main]: >>> deserializing nodedefmanager
07:11 VanessaE       2015-07-14 03:10:42: ERROR[main]: A serialization error occurred:
07:11 VanessaE       there, specifically.
07:11 hmmmm          the point of that patch was to find out where the serialization error happened, and how big the string ws...
07:11 est31          VanessaE, that was only debugging code
07:11 hmmmm          care to paste the second line of the log message?
07:11 VanessaE       2015-07-14 03:10:42: ERROR[main]: deSerializeLongString: string too long: 10074436 bytes
07:11 est31          so what was the length
07:12 hmmmm          so around 10 mb
07:12 est31          too much nodedefs
07:12 hmmmm          this is vanessae we're talking about though.
07:12 VanessaE       haha
07:12 hmmmm          5000000 mods
07:12 est31          lets discuss about nodedef compression
07:12 hmmmm          don't bother
07:12 VanessaE       well be fair, the engine is supposed to handle 32766 nodes.
07:12 VanessaE       and I use only half of that
07:12 hmmmm          we're eventually getting whole network compression, right?
07:12 est31          i dont think we will get that
07:12 VanessaE       hmmmm: I hope not.  the CPU usage would be insane.
07:13 hmmmm          nah... zlib is really fast!
07:13 est31          that wouldnt be the problem
07:13 hmmmm          you'd be surprised
07:13 est31          more the lag problem
07:13 VanessaE       > zlib is really fast...
07:13 VanessaE       > server has 50 players
07:13 kahrl_         uh... nodedef is already sent compressed
07:13 hmmmm          ah
07:13 hmmmm          good point
07:14 est31          you cant just let a chat message sit there and wait until some other content comes in, until a buffer is filled so that oyu can send it
07:14 hmmmm          toochay
07:14 hmmmm          so how about 32 MB
07:14 VanessaE       32MB sounds good
07:14 hmmmm          yeah 32 mb is fine.
07:14 hmmmm          64 for safe measure.
07:14 est31          how do we compress nodedefs kahrl_?
07:15 hmmmm          i don't think you'd be able to bring down a server by forcing it to allocate 64 mb
07:15 VanessaE       if 10 would be enough for half, 32 should be way more than enough for the whole thing
07:15 hmmmm          i foresaw something like this happening, heh
07:15 est31          well 64 mb is a multiplier
07:15 est31          50 players times 64 mb is...
07:15 VanessaE       well if you're allocating 64MB you may as well open up the nodedef limit to the full 65534 ;)
07:15 * VanessaE     hides
07:15 hmmmm          VanessaE: go into util/serialize.h and change LONG_STRING_MAX to 32 mb
07:16 hmmmm          just so we don't waste time heh
07:16 kahrl_         est31: all of them are serialized, concatenated and then the whole thing is handed to compressZlib
07:16 VanessaE       ok
07:16 est31          kahrl_, ok
07:16 VanessaE       compiling.
07:18 * VanessaE     runs it.
07:19 VanessaE       works.
07:19 hmmmm          o ok
07:19 VanessaE       it prints those initial three "deserializing" messages to error stream but meh
07:22 VanessaE       est31: now anyways, yes param2 is for light propagation
07:22 VanessaE       just looked.
07:22 est31          param1 you mean
07:22 VanessaE       er yeah
07:22 VanessaE       sorry typo
07:22 VanessaE       https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L505
07:22 est31          well yes
07:23 est31          but read the comment
07:23 est31          https://github.com/minetest/minetest/blob/990a96578f20244626b6b9f67f8e79a7e2e614ea/src/mapnode.h#L126
07:23 hmmmm          https://github.com/kwolekr/minetest/commit/515e7028ac5121bc6a5205b12aae731eed630b05
07:23 hmmmm          ?
07:23 est31          "Uhh... well, most blocks have light or nothing in here."
07:24 VanessaE       yeah but for leaves, surely there would be a light value
07:24 est31          wasnt it 640 k ?
07:24 hmmmm          yeah it was
07:24 hmmmm          but this is 64 MB
07:24 est31          +1
07:25 hmmmm          btw what about https://github.com/kwolekr/minetest/commit/5006ce82609b2260f191b132f2dabcfdb06d6e20
07:25 VanessaE       lol
07:25 hmmmm          yes? no?
07:25 VanessaE       hmmmm: I'd say a yes to that but I have not tested it yet
07:25 est31          the commit title is promising thats a yes, but i have to read through witespace
07:28 kahrl_         lol
07:28 kahrl_         did handleCommand_ActiveObjectMessages seriously read the string from the stream byte by byte
07:28 est31          perhaps it should print the message somewhere else
07:28 VanessaE       (note:  that patch has to be applied before the 64MB patch)
07:28 est31          eg into actionstream
07:28 est31          or at least info
07:28 hmmmm          kahrl_ most of the deserialization code is just as bad if not worse
07:29 hmmmm          it's absolutely amazing, how there can be so many security problems with code that uses istringstream
07:29 hmmmm          est31:  but why?  it's pretty useless information
07:29 est31          meh, lets remove it
07:30 est31          what about the PacketError
07:30 hmmmm          why print the corrupted packet for some specific packet and not all the others?
07:30 est31          good point
07:30 hmmmm          it's one of nerzhul's sloppy copy/paste jobs
07:31 hmmmm          he didn't even bother checking to see if anything can produce a packeterror in that block
07:31 VanessaE       well the two patches seem to work fine
07:31 hmmmm          hint: the answer is no
07:31 est31          +1 then
07:31 VanessaE       but I'm not getting any serialization errors as readily as usual
07:31 VanessaE       so I'm not sure if that's enough for a +1
07:31 VanessaE       but it doesn't crash :)
07:32 VanessaE       the server I'm testing on is really laggy though
07:32 kahrl_         I agree, the only use for printing the data I can imagine is for some debugathon (like you were doing) where you manually compare message data
07:33 kahrl_         in which case you can make it log it before you start
07:33 VanessaE       ah, got one
07:33 VanessaE       2015-07-14 03:32:52: ERROR[main]: Client::handleCommand_ActiveObjectMessages: caught SerializationError: deSerializeString: couldn't read all chars
07:33 hmmmm          right, somehow the serialization layer (*cough* nerzhul) is producing garbage data for the AOM commands
07:34 VanessaE       seems good, hmmmm.
07:34 hmmmm          we looked at this together
07:34 hmmmm          the garbage doesn't come from the environment's AOM queue itself
07:34 hmmmm          something somehow magically happens to the data as it's being sent to the client
07:35 hmmmm          hmmm.
07:35 asl97          issue #2841 just got close
07:35 ShadowBot      https://github.com/minetest/minetest/issues/2841 -- on_rightclick for item (or tool)
07:36 est31          asl97, becausei guess he realized it exists
07:36 asl97          it does?
07:37 est31          on_place??
07:37 asl97          quote: `on_place function without pointed`
07:37 asl97          iirc, on_place is only called when it is pointed to something
07:38 est31          ah then it makes sense
07:41 est31          hmmmm, why do you have dislike against using param1
07:41 hmmmm          param1 is light, no?
07:42 VanessaE       light propagation
07:42 hmmmm          and what is this for?
07:42 est31          only if the nodedef has light_propagates = true
07:42 hmmmm          you're going to mess up the way the node looks if you try to store other data in param1
07:42 est31          at least according to https://github.com/minetest/minetest/blob/990a96578f20244626b6b9f67f8e79a7e2e614ea/src/mapnode.h#L126
07:42 VanessaE       est31: which would be both leaves nodes and the fruit node.
07:43 hmmmm          ah
07:43 hmmmm          I guess not
07:43 est31          VanessaE, those can be handled by leaf decay as kahrl_ said, no?
07:43 hmmmm          well go ahead then, use param1
07:43 VanessaE       est31: no, because the whole point is for the chainsaw/treecapitator/whatever to take down the entire tree.  and leaf decay is purposely slow in moretrees, to keep CPU usage at a minimum
07:44 est31          hrmmm...
07:44 VanessaE       wait wtf?
07:44 VanessaE       leaves are NOT set to sunlight_propagates.
07:44 VanessaE       (however paramtype = "light", despite)
07:45 VanessaE       the fruit however, is.
07:45 VanessaE       I can change that, though
07:45 est31          also question what the difference between light_propagates and sunlight_propagates is
07:45 est31          well i guess i will make my code check for light_propagates
07:46 VanessaE       so I could free up all uses of param1 here if you're right about how param1 is being used
07:46 est31          or sunlight_propagates or whatever
07:46 hmmmm          well, sunlight_propogates implies light_propogates
07:46 kahrl_         using param1 for tree nodes would probably be fine for now, but I'm not sure how future proof that is
07:46 hmmmm          sunlight_propogates iirc is only used when spreading light
07:46 kahrl_         I can imagine some artistic christmas-y mod making trees out of glass nodes or something
07:46 VanessaE       kahrl_: in the future, you just KNOW we're gonna need to add a param3.
07:47 VanessaE       (yes I know it would make the map bigger, but I think the day will come when there's no other choice)
07:47 est31          well if we have good compression algs, we only store the entropy
07:48 est31          which is quite low for param3 = 0 everywhere
07:48 VanessaE       this is true
07:48 kahrl_         est31: btw, light_propagates = true is just legacy notation for paramtype = "light"
07:49 VanessaE       For the record, RealBadAngel has been vying for a param3 + param4 to be added at some point.
07:49 VanessaE       as for compression, leveldb already does.
07:50 kahrl_         wait, not sure
07:51 kahrl_         ah yeah, script/common/c_content.cpp:437
07:51 VanessaE       kahrl_: well it used to be, at least, that if you didn't set paramtype = "light", your node would be all black in the world.
07:51 kahrl_         (not exactly what I was saying but close enough)
07:53 kahrl_         see also the warn_if_field_exists in line 424
07:54 est31          VanessaE, what about "immediate" leaf decay
07:54 VanessaE       est31: that would cause a lag spike.
07:55 VanessaE       (as if removing the tree doesn't already)
07:55 est31          VanessaE, not if you use a smart algorithm
07:55 VanessaE       no matter how smart, it's still 2000+ nodes
07:55 kahrl_         so, to answer the question about the difference, light_propagates is checked when (un)spreading light from any source, while sunlight_propagates is only checked when (un)spreading sunlight
07:56 est31          of course, if you iterate over the block, then if its a leaf node, iterate over all the nodes "close" to it whether they are trunks
07:56 est31          its gonna be horribly slow
07:56 est31          but you can make that smarter
07:57 est31          e.g. make 4x4x4 blocks
07:57 est31          store a bool for each of them
07:57 est31          then iterate *once* over the whole area
07:57 est31          storing the bool, whether a trunk is in there
07:58 est31          now you only have to check the 4x4x4 blocks nearby when you iterate a second time for the leaves
07:58 est31          most of them will be false, unless there is another tree
07:59 est31          if the 4x4x4 block you are currenty in is true, you can leave the leaf be
08:00 est31          if the 4x4x4 block you are currently in is false, and a neighbouring one is true, you will have to fall back to "manually" determine the position (and distance) of the trunk node
08:00 est31          if all neighbours are false you have nothing to check :)
08:01 VanessaE       well, how such a tool is implemented I leave as an exercise to the guy who wanted this feature anyway :)
08:01 asl97          it should be possible to make it faster, mc can handle it quite well, there are mods over there with HUGE tree,  think over 10 times BIGGER, maybe even 100 times
08:02 est31          asl97, have you seen moretree trees?
08:04 asl97          yea, have you seen the Sacred rubber sapling from MFR?
08:04 VanessaE       est31: ok, I just confirmed, all the nodes in a tree look fine if I strip out all references to param and paramtype
08:05 est31          asl97, does that have leaf decay?
08:05 asl97          the leaves from the default rubber tree sapling seem to have it,  i not quite sure about those from the Sacred rubber sapling
08:06 VanessaE       so param(1) is available, if the engine will allow you to actually USE it anyway
08:06 asl97          it's too huge to cut it down
08:06 asl97          maybe it's over 1000 times
08:06 est31          VanessaE, le engine cest us
08:07 VanessaE       eh?
08:07 est31          https://en.wikiquote.org/wiki/Louis_XIV_of_France
08:07 VanessaE       heh ok
08:08 VanessaE       all right, so I guess try passing the ID value through param1
08:08 est31          can you change it to 1 everywhere and check whether it works?
08:09 asl97          i will check if it has decay by cutting out a small part of the tree, a image of the tree from the internet: http://postimg.org/image/briol21nt/
08:09 est31          except for leaves or other light code maybe
08:09 VanessaE       well it returns nil when it's not set. just checked.
08:09 VanessaE       but lemme see what your patch does
08:10 VanessaE       is it param1, or just param?
08:11 est31          its param1
08:11 VanessaE       ok, lemme see what it does.
08:11 RealBadAngel   hi guys
08:12 VanessaE       mornin', RBA.
08:12 RealBadAngel   just wanted to make sure you realize that a tree grows exactly the same at given pos and the same seed?
08:12 VanessaE       RealBadAngel: some trees don't.  coded randomness in the mod
08:13 est31          well thats stupii
08:13 est31          d
08:13 est31          what do you have a seed for
08:13 RealBadAngel   that was  request, made by PA iirc, for worlds being the same
08:13 VanessaE       est31: the extra randomness is for differing models of trees
08:14 VanessaE       for example in moretrees, when the damn thing works at all, there are 3 slightly different models of jungle trees, and two of fir
08:14 est31          you sure you want to saay when, not if?
08:14 est31          :p
08:14 VanessaE       the models being built procedurally (well, a primitive form)
08:15 VanessaE       I say when because the trees grow fine from a sapling, but some glitch in my biome defs keeps them from spawning at mapgen time :)
08:15 VanessaE       a glitch I never bothered to fix since default jungletrees exist
08:16 VanessaE       hm
08:16 VanessaE       param1 does not work as expected.
08:16 VanessaE       "moretrees:sequoia_leaves": param1=9
08:16 VanessaE       "moretrees:sequoia_trunk": param1=192
08:16 VanessaE       "moretrees:sequoia_leaves": param1=14
08:16 VanessaE       (just a little debug statement I added to moretrees, punching in a few different places on the same tree)
08:20 VanessaE       I guess those spread-light functions are altering the value being stored.
08:21 VanessaE       hm, no.  looks like I missed a paramtype setting.
08:22 est31          somehow i dont see these checks at all
08:22 VanessaE       aw fuck
08:22 VanessaE       leaves HAVE to have paramtype = "light" or they come out black.
08:23 VanessaE       maybe because of their drawtype
08:23 VanessaE       the ID is, however, being stored in param1 correctly.
08:24 est31          thats good then
08:24 RealBadAngel   i just figured the way we can get some spare bits in params :)
08:24 RealBadAngel   lets code irrlicht lighting :)
08:24 VanessaE       est31: so the question now is, can lighting be forced into the leaves without using param1
08:24 VanessaE       (and without fucking with irrlicht lighting just yet :P )
08:24 RealBadAngel   ;)
08:25 est31          VanessaE, or we just dont set it for the leaves
08:25 VanessaE       ...
08:28 RealBadAngel   est31, what about your pr im waiting for?
08:28 est31          lol seems that minecraft has to fight with shadow bugs too : http://postimg.org/image/briol21nt/
08:28 est31          RealBadAngel, ?
08:29 VanessaE       est31:  https://gist.github.com/VanessaE/6a31cc55d1a2c263bdd0
08:30 VanessaE       get current moretrees and apply this
08:30 VanessaE       punch a moretrees trunk or leaves to get the param1 value from that node.
08:30 VanessaE       (point is so that you can see what I'm doing in the code, anyway)
08:30 RealBadAngel   est31, that one with chat
08:32 est31          ok, so whats the problem again
08:32 VanessaE       me?
08:33 est31          yes
08:33 VanessaE       with that ^^^ patch, leaves end up black.
08:33 asl97          est31: it does decay, plenty of lag spike in area without wood but it was ok when there is wood, oh well, i guess the test world is doom to lag now...
08:34 asl97          most likely due to node being remove or something
08:34 VanessaE       est31: "That's a big tree."  :)
08:34 VanessaE       (meh, blew the line)
08:35 est31          so their leaf decay is laggy too
08:36 asl97          but the huge tree rocks
08:37 kahrl_         yeah, mc leaf decay has always been laggy. Source: played Canopy Carnage years ago
08:39 VanessaE       in any case, it's impossible to code an algorithm that will successfully remove an entire tree but not any neighbors, if all parts of the tree are not identified as belonging together.
08:39 VanessaE       so in the end, I see three options:  A. use the upper three bits of param2.  B. make a new facedir mode that only uses the lower three bits of param2, and use the upper 5 for the ID.  C. use metadata.  D. add a param3 or equivalent.
08:39 VanessaE       er four options.
08:40 est31          E. use param1 for trunks, use param2 for leaves
08:40 VanessaE       hm.  that may be possible.
08:40 est31          F. use param1 for trunks think of smarter leafdecay
08:40 VanessaE       F is right out.  chainsaw a tree, leave a cloud of leaves... "this mod sucks! BuG RePorT!!!" etc.
08:41 VanessaE       plus,
08:41 VanessaE       leaf decay drops saplings.
08:41 est31          seen the "think of smarter leafdecay" part?
08:41 VanessaE       the user likely won't hang around long enough to collect them.
08:41 est31          also we can do leaf_decay(chainsaw=true) call
08:41 est31          which immediately "checks" all leaves around removed blocks
08:42 asl97          tinker axe leave the leaves too so it isn't really a big problem,  call it by design
08:43 asl97          it would drain the chainsaw lesser too and make it possible to chainsaw the largest tree in moretree and leave the leaves to decay
08:43 VanessaE       I guess removing all the corresponding leaves within a 2 or 3 meter radius of a removed trunk would work
08:44 VanessaE       wouldn't work on palm trees though
08:44 VanessaE       (the canopy is around 7 meters radius)
08:44 RealBadAngel   #2885
08:44 ShadowBot      https://github.com/minetest/minetest/issues/2885 -- Utf8 based chat by est31
08:44 RealBadAngel   est31, , i meant this pr
08:45 est31          RealBadAngel, yes what about it
08:45 RealBadAngel   when you will be rdy with it
08:45 est31          i am ready with it
08:45 asl97          a check once algorithm could work,  leaves: abm: if not meta and find_wood then set_meta end, trunk: on_dig: for all_node_in_area do leaves:set_meta(nil) end
08:45 est31          only needs testers to test it
08:45 RealBadAngel   i cant merge my without raising protocol ver
08:46 est31          also reviewers to review it
08:46 est31          why, you can merge it without raising the version
08:46 est31          then it simply isnt activated
08:46 RealBadAngel   https://github.com/minetest/minetest/pull/2897/files#diff-70868aa6d6b96c0c1623c761500d23c4R123
08:47 RealBadAngel   that way, the patch will just not work
08:47 est31          well yea, sort of
08:48 VanessaE       est31: ok, I'm gonna test the patch with param1 for trunks, param2 for leaves and fruit
08:51 VanessaE       est31: ok that seems to work properly
08:53 VanessaE       https://gist.github.com/VanessaE/7e3d3e3df640e1d5cc8a
08:53 VanessaE       your patch as modified, plus moretrees modified to use it
08:53 est31          great
08:54 est31          then ill modify my patch to check for the paramtype so that it knows where to write in
08:54 VanessaE       ok.
09:00 VanessaE       est31: oh, that patch for the areastore, where did we stand on that?  I forgot :)
09:00 est31          VanessaE, its good enough to run it on a server
09:00 VanessaE       ok
09:00 est31          "i dont know of any bugs"
09:00 VanessaE       famous last words? :D
09:00 est31          yepo
09:01 VanessaE       hehe
09:04 VanessaE       hm, I just realized another conflict.  paramtype2 = "waving"
09:04 VanessaE       however moretrees doesn't use this.
09:04 est31          "waving"?
09:04 VanessaE       yeah, for the waving leaves shader
09:05 VanessaE       hm, must be deprecated.
09:05 VanessaE       I don't see it in lua_api
09:06 est31          well, i know how to code it, and if somebody wants to use paramtype2 = waving they have to think of a better leaf decay alg than abm
09:06 VanessaE       RealBadAngel: what's the story on that?
09:07 VanessaE       in fact "waving" doesn't appear in the api at all.
09:08 RealBadAngel   lemme check
09:10 RealBadAngel   i cant see anything related to param2 being "waving"
09:10 RealBadAngel   its contentFeatures property, not param2
09:10 VanessaE       yeah, looks like it's just a node def item now
09:10 VanessaE       the param2 thing must be leftover from my testing from when you first wrote the shaders then
09:11 VanessaE       (I did find a couple refs in moretrees, on closer inspection)
09:11 VanessaE       est31: ok, no conflict.
09:11 RealBadAngel   propapbly yes
09:14 VanessaE       yep, works fine with just waving=1 where needed
09:14 VanessaE       you should probably document that feature in the API
09:14 RealBadAngel   https://github.com/minetest/minetest_game/pull/567
09:14 VanessaE       lgtm, RealBadAngel
09:15 est31          cheapie?
09:15 VanessaE       you need to do the others too, also desert stone and desert cobble should match regular stone and cobble I think.
09:15 est31          why is it "sharpened"
09:16 est31          if then its less sharp
09:17 RealBadAngel   previous one was too blurry
09:18 VanessaE       RealBadAngel: I think he means the edges of the big pixels
09:18 est31          ^
09:18 VanessaE       in fact the new one is fuzzier than the old one, but with those diagonal shadows gone, it looks better
09:19 RealBadAngel   https://imgrush.com/Rjqu4J_CDKxG
09:19 VanessaE       that's the old one
09:19 RealBadAngel   yes
09:19 RealBadAngel   you have screenie of the new one in pr
09:19 VanessaE       *nod*
09:20 RealBadAngel   VanessaE, i think i would stick to "style" of the new stone one
09:20 VanessaE       RealBadAngel: told you it looks better :)
09:20 RealBadAngel   https://imgrush.com/sjYy4sd6jCKV.png
09:21 RealBadAngel   grass is the same style
09:21 RealBadAngel   pixels are nicely rounded with soft shadows
09:21 VanessaE       looks good.
09:21 VanessaE       that's the idea I was trying to convey earlier :)
09:22 RealBadAngel   such softness in images reminds me the look of blender renders
09:24 RealBadAngel   and is exactly what i was aiming since the very begining
09:24 RealBadAngel   tried to get that look with overriding normals, but relief mapping is way better
09:28 RealBadAngel   btw, who claimed that stairs are properly uv'ed?
09:28 VanessaE       *shrug* dunno
09:28 RealBadAngel   theyre fucked up
09:29 VanessaE       https://github.com/minetest/minetest_game/pull/563
09:29 VanessaE       what's wrong with them?
09:29 RealBadAngel   https://imgrush.com/YvA-jP4mpTV1
09:30 VanessaE       I don't see anything wrong there?
09:30 VanessaE       oh wait
09:30 VanessaE       I see it
09:30 VanessaE       vertical misalignment
09:31 RealBadAngel   it looks like theyre rotated by 90 degs
09:31 VanessaE       no, the rotation looks fine
09:32 VanessaE       but there is a slight vertical compressing issue
09:32 RealBadAngel   its not fine
09:32 RealBadAngel   take a closer look
09:32 VanessaE       I am.
09:32 RealBadAngel   when you will rotate the cube by 90degs, it would fit the stair
09:33 VanessaE       turn off your parallax/normals/bumps
09:33 VanessaE       they're throwing off your impression
09:33 VanessaE       the problem is the side of the stair is vertically stretched a little.
09:34 VanessaE       that slight misalignment makes it look like it's rotated wrong.
09:35 RealBadAngel   im lookin at the top
09:35 VanessaE       *looks again*
09:36 VanessaE       hrm
09:36 * VanessaE     fires up blender
09:36 RealBadAngel   https://imgrush.com/i4lZoNlFELw3
09:36 RealBadAngel   https://imgrush.com/oU41fZaKlnRd
09:36 RealBadAngel   textures at the upper edge should start with the very same pixels, dont you think?
09:38 RealBadAngel   they dont
09:38 VanessaE       stand by, I'll make a new one.
09:39 RealBadAngel   propably the model is flipped when exporting
09:44 VanessaE       here, how's this look to you?
09:44 VanessaE       http://digitalaudioconcepts.com/vanessa/hobbies/minetest/stairs_stair.obj
09:46 VanessaE       RealBadAngel: ^^^
09:49 RealBadAngel   5/6 are correct
09:49 RealBadAngel   top face is flipped by 180degs
09:50 VanessaE       nope.avi
09:50 VanessaE       looks fine in-game
09:50 VanessaE       remember, it's a model, so you have to face north when you place it
09:50 VanessaE       otherwise you won't see the natural alignment
09:51 RealBadAngel   https://imgrush.com/csu-giv8J_-_.png
09:51 RealBadAngel   sorry, not 180. 90
09:51 VanessaE       yeah, now try it while facing north :)
09:52 VanessaE       http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-07-14_05-51-58.png
09:52 RealBadAngel   ah indeed
09:53 VanessaE       https://github.com/minetest/minetest_game/pull/568
10:07 VanessaE       sfan5: *poke*
10:09 kilbith        VanessaE: are you sure it was necessary to add more vertices here ? https://lut.im/KKm0XDIg/yemqH2lI
10:09 VanessaE       kilbith: yes, because the engine doesn't like concave shapes
10:09 kilbith        also blast the floating
10:09 VanessaE       it'll render an ngon, but if it's concave like that, it'll try to fill in the two corners
10:10 asl97          rui914 just close another issue but i suppose this time is ok since it was unclear what it was about (although i guess it's a way to unify the sapling grow function)
10:11 VanessaE       kilbith: I won't mess with the content of the file.  saving those extra bytes is not worth the effort.
10:11 kilbith        it's not that, it's about the parsing
10:11 VanessaE       have you benchmarked it?
10:11 kilbith        no but it's certainly better
10:12 kilbith        10s for doing that
10:12 VanessaE       the difference in parsing speed will be so small that it'll disappear into the "background noise" of startup delay.
10:12 kilbith        while you're speaking, it can be already done
10:14 * VanessaE     shrugs.  I'll fix that extra edge that was added when I triangulated, but outside of that, mt_game devs can take it or leave it.
10:15 kilbith        also why showing a screenshot of the top of the stairs whereas it concerns the sides ?
10:15 VanessaE       it was what I had immediately handy.
10:15 kilbith        ah, oh
10:15 kilbith        strange
10:17 VanessaE       there, updated the model to remove the extra edges.
10:19 VanessaE       and screenshot updated.
10:20 VanessaE       comparison added.
10:24 VanessaE       shit.
10:24 VanessaE       RealBadAngel: the problem is mismatching between your cobblestone normalmap and the autogenerated one being used on the stairs
10:25 kilbith        thanks
10:25 VanessaE       they don't tile together so it looks like it throws off the alignment
10:25 VanessaE       I jsut tested my model with and without normals/etc. and I can see the same misalignment.
10:25 VanessaE       apparent* misalignment.
10:26 kilbith        yeah, i assumed those extra-vertices were pointless
10:27 kilbith        also no meticulous description on what have been done nor preview either :/
10:28 VanessaE       you know me, I'm not the most verbose when I describe something.
10:28 VanessaE       anyway, closed the PR.
10:28 kilbith        thanks for ther try anyhow
10:28 kilbith        -r
10:57 rubenwardy     Who allowed set_nametag_attributes to be merged?
10:58 rubenwardy     It doesn't follow existing color standards in Minetest!
10:58 rubenwardy     nevermind
11:12 est31          rubenwardy, we will have to give up on more "existing standards" the more this becomes an engine and the less a game
11:13 rubenwardy     What i meant was that formspecs etc use #000000 and red
11:13 rubenwardy     whereas the set_name* uses
11:13 rubenwardy     { r = 0, g = 0, b = 0}
11:13 est31          ah that
11:13 rubenwardy     but I found out that set_name does also take #00000
11:13 est31          yea we have gazillions of color standards
11:13 rubenwardy     although it adds an extra FF at the beginning for alpha
11:21 rubenwardy     Why do I get 2015-07-14 12:18:05: ERROR[main]: Client::getMesh(): Mesh not found: "stairs_stair.obj"
11:21 rubenwardy     when there is minetest/games/capturetheflag/mods/stairs/models/stairs_stair.obj
11:37 asl97          since the new update
11:38 asl97          rubenwardy: this commit: https://github.com/minetest/minetest_game/commit/f3f8b22698303c1ee592ea5e9d5ba5ce1427ce57
11:38 rubenwardy     yes
11:38 rubenwardy     but there is a model in models
11:39 rubenwardy     and it isn't getting send to the client
11:41 asl97          oops, i misread
11:46 Calinou        post_effect_color is r/g/b/a
11:46 Calinou        not hex
12:04 kahrl_         rubenwardy: how did you end up solving it?
12:04 rubenwardy     I didn't
12:04 kahrl_         oh
12:04 rubenwardy     if you mean the stairs thing
12:04 kahrl_         yeah, I meant that
12:31 Amaz           #2911
12:31 ShadowBot      https://github.com/minetest/minetest/issues/2911 -- Allow random menu images for subgames by Amaz1
12:31 sfan5          VanessaE_: *poke back*
12:32 VanessaE_      sfan5: nevermind, already resolved.
12:44 RealBadAngel   sfan5, are you ok with https://github.com/minetest/minetest_game/pull/567 ?
12:45 sfan5          hm
12:45 sfan5          RealBadAngel: how are the normal maps for overlayed textures composed?
12:45 RealBadAngel   same way as regular overlay do
12:46 sfan5          i see
12:46 sfan5          I'm ok with game#567
12:46 ShadowBot      https://github.com/minetest/minetest_game/issues/567 -- Better default stone normalmap, sharpened a bit by RealBadAngel
12:47 RealBadAngel   so please merge it then. it has already several dev votes
12:47 RealBadAngel   including paramat, hmmm, est31, me and Ve
12:48 sfan5          in irc?
12:48 RealBadAngel   yes
12:48 RealBadAngel   shall i dig it?
12:48 sfan5          just paramats vote
12:48 RealBadAngel   hold on
12:49 RealBadAngel   sfan5, http://irc.minetest.ru/minetest-dev/2015-07-14#i_4322028
12:50 sfan5          ok
12:50 RealBadAngel   i will try to follow the very same style with all other ones since now
12:50 sfan5          merging it
12:51 RealBadAngel   ty
12:51 RealBadAngel   you will propably get bucket of beer from VE for this mergeing ;)
12:52 VanessaE_      beer?  yech.
12:59 Routh          Mead > beer.
13:01 RealBadAngel   now, shall i push the grass texture?
13:02 VanessaE_      yes
13:02 RealBadAngel   https://imgrush.com/sjYy4sd6jCKV.png
13:03 RealBadAngel   ofc, it will need my engine changes
13:03 RealBadAngel   but texture will be the same
13:03 RealBadAngel   (dont look at hand, its damn fsaa)
13:08 RealBadAngel   btw. with grass and snow im using a simple trick for large areas of those to look consistent
13:08 RealBadAngel   grass and dirt normalmaps are the same
13:08 RealBadAngel   same for snow
14:52 RealBadAngel   https://imgrush.com/5xdAh7snhruo.png
14:53 RealBadAngel   ^^ proposal for default:cobble
14:53 VanessaE_      a bit deep on the displacement but otherwise looks good
14:53 RealBadAngel   hmmm, how do you find it?
14:53 RealBadAngel   VanessaE_, you never sleep, do you? ;)
14:53 VanessaE_      heh
14:54 hmmmm          by the way, RealBadAngel, when are you going to push that commit?
14:54 hmmmm          est31 wanted you to not bump the protocol version yet though
14:54 RealBadAngel   hmmmm,i know
14:54 RealBadAngel   but when i do not, code will remain inactictive
14:55 RealBadAngel   until protocol gets bumped
14:55 RealBadAngel   is that ok?
14:56 sfan5          RealBadAngel: too 'noisy'
14:56 hmmmm          yeah I guess it's okay
14:56 hmmmm          all that his commit is waiting on is a review and a bit more 'testing'... erm
14:56 sfan5          i mean the displacement where there are these seperated patches in the cobble texture
14:56 hmmmm          so in theory it shouldn't take long at all
14:56 sfan5          i hope you know what i mean
14:57 RealBadAngel   sfan5, noisy or too soft?
14:58 RealBadAngel   https://imgrush.com/YSK-Cv9Z7JLE.png
14:58 sfan5          too high differences between the 'heights' of the pixels
14:58 RealBadAngel   theres another version
14:58 VanessaE_      RealBadAngel: too much variation between neighboring big pixels (e.g. the "diffuse" texture)
14:59 VanessaE_      imho the "islands" need to be lower/less displaced, and the pixels that make them up should be higher int he centers than at the edges
14:59 VanessaE_      but only a little bit
14:59 VanessaE_      so that they look like rounded stones (or as rounded as a 16px texture would be able to get)
15:00 RealBadAngel   https://imgrush.com/QtyDtkwXDRRR.png
15:00 RealBadAngel   what about now?
15:00 VanessaE_      still too strong
15:03 RealBadAngel   https://imgrush.com/7lqpV6OuLsJ5.png
15:03 sfan5          yes
15:04 sfan5          way better
15:04 VanessaE_      agreed
15:04 VanessaE_      now raise the centers of the "islands"
15:04 VanessaE_      as if they're rounded stones, but keep it pixely
15:05 sfan5          i prefer the way it is right now
15:05 sfan5          though VE's suggestion could be a good idea
15:05 sfan5          might look good
15:05 VanessaE_      as long as the difference between neighboring pixels is subtle it should look good
15:06 sfan5          hm
15:06 sfan5          the cobble texture does not tile vertically at all
15:09 RealBadAngel   https://imgrush.com/0GfFVWhq02rP.png
15:10 RealBadAngel   sfan5, it does tile on the same planes
15:10 VanessaE_      that's the right idea but the effect istoo strong.
15:11 RealBadAngel   dont expect displaced textures on different planes
15:11 RealBadAngel   *to tile
15:11 RealBadAngel   that will never work
15:13 RealBadAngel   https://imgrush.com/GKR9hh7obO2N.png
15:14 sfan5          still too strong imo
15:14 VanessaE_      yeah
15:14 RealBadAngel   its almost flat now
15:14 VanessaE_      your normalmaps are too strong
15:15 VanessaE_      the displacement map is fine though
15:17 RealBadAngel   https://imgrush.com/GPFItEP6uaW2.png
15:17 VanessaE_      yes
15:17 RealBadAngel   less shadows but bit higher
15:17 VanessaE_      that's pretty close
15:19 RealBadAngel   in which dierction you think?
15:20 VanessaE_      maybe just a HAIR more height in the displacement/parallax map, but keep the normals as they are
15:25 RealBadAngel   https://imgrush.com/vP4nFw-2hsM0.png
15:26 VanessaE_      lgtm
15:27 RealBadAngel   sfan5, hmmm ?
15:27 VanessaE_      need cheapie and sfan5 now :)
15:28 sfan5          looks nice
15:28 est31          yea nice
15:31 RealBadAngel   https://github.com/minetest/minetest_game/pull/569
15:32 VanessaE_      RealBadAngel: don't forget to copy that to desert cobble too
15:32 RealBadAngel   i think desert cobble will require another shape
15:32 VanessaE_      nah
15:32 VanessaE_      it's the same texture, just red
15:32 VanessaE_      same normalmap should work fine for it
15:32 RealBadAngel   you can try it
15:32 VanessaE_      same as desert stone, it's just red-colored default stone
15:33 RealBadAngel   give it a shot and show us screenie
15:33 VanessaE_      too lazy :)
15:33 RealBadAngel   im supposed to do everythin? :P
15:33 VanessaE_      yep! :D
15:33 RealBadAngel   move your lazy ass madam :P
15:34 RealBadAngel   i did the same trick to grass and dirt
15:35 RealBadAngel   propably it can work good for cobbles
15:36 RealBadAngel   but nooooo
15:36 RealBadAngel   ;)
15:36 RealBadAngel   differnt colours, shape should be changed
15:37 VanessaE_      no
15:37 VanessaE_      players routinely use desert and regular cobble together
15:37 VanessaE_      so the normals need to tile well
15:37 RealBadAngel   but color pattern is different
15:37 RealBadAngel   it looks like shit
15:38 VanessaE_      it is?  last I looked, it was exactly the same as default cobble, just tinted red
15:39 RealBadAngel   https://imgrush.com/oE9oU0NSPRUV.png
15:39 VanessaE_      oh wait, I'm wrong
15:39 RealBadAngel   unacteptable
15:39 VanessaE_      I'm thinking of another texture
15:40 VanessaE_      so yeah desert cobble needs its own map
15:40 VanessaE_      however, desert *stone* is indeed identical (I'm looking at it and regular stone now)
15:40 RealBadAngel   yes
15:40 VanessaE_      yeah forget what I said about desert cobble
15:40 * RealBadAngel forgets
15:40 RealBadAngel   and also going to have a nap
15:41 RealBadAngel   im a bit tired
15:41 VanessaE_      stone brick == desert stone brick
15:41 VanessaE_      so you'll want to copy that one too
15:45 RealBadAngel   https://imgrush.com/Yei7bxNd3Gk1
15:45 VanessaE_      eh
15:45 VanessaE_      lacks...definition
15:45 VanessaE_      the lighting feels flat
15:46 VanessaE_      but the displacement there at the edge is a different matter
15:47 VanessaE_      I guess there's no way for the shader to know that the two textures are actually the same, save for their color
15:57 rubenwardy     #1587
15:57 ShadowBot      https://github.com/minetest/minetest/issues/1587 -- Colour codes in chat and console
15:57 nrzkt          Will push a little cleanup in connection.cpp in ~2 min
15:57 nrzkt          https://github.com/nerzhul/minetest/commit/b0a52c314c9d61112692d7420c25cde0c9423aa0
15:57 nrzkt          This construction isn't used anywhere
15:57 hmmmm          you need to give 30 minutes of forewarning anymore
15:58 hmmmm          2 minutes is far too short
15:58 hmmmm          but looks good to me
15:58 nrzkt          2 minutes for a cleanup on a constructor unused is useless, also i'm network maintainer and i'm working on it atm :p, looking a enet implementation on minetest
15:58 nrzkt          30min* sorry :)
15:59 hmmmm          it's not useless, other people need to get a chance to see what's being committed before it happens
15:59 nrzkt          i can wait but maybe i will need to push many commits. Then okay for 10 minutes.
16:00 hmmmm          no, this isn't an amount that can be negotiated
16:00 rubenwardy     Why do you need to push so quickly?
16:00 hmmmm          there is no need to push quickly
16:00 nrzkt          it's a cleanup on my maintainer part and this doesn't cause any problem, and maybe in 30 minutes i will not be there :)
16:01 hmmmm          not our problem
16:01 hmmmm          maybe you should have advertised it earlier
16:01 nrzkt          stop being so icy for so little commits. IT's just stupid :). Ok for changes , but for cleanups... just :(
16:02 hmmmm          cleanups are changes too
16:02 nrzkt          and remember, we are all developers.
16:02 hmmmm          if you're changing the code, guess what, that's a change
16:03 nrzkt          hmmmm: do you know about flexibility and adapt things to situation ?
16:03 nrzkt          or are you just a manual or a lawyer ? :p
16:03 rubenwardy     The point of review periods (ie: 15min, 30min) is to make sure that the commit doesn't have unintended consequences.
16:03 hmmmm          these are all just stupid excuses to push things without oversight
16:03 nrzkt          you see it, you approved it :)
16:03 hmmmm          the minetest users have spoken up
16:04 hmmmm          they expect a higher level of quality
16:04 hmmmm          yes, i approved it, but had i happened to not be around you'd still push it anyway in 2 minutes
16:04 nrzkt          i know, but removing a unused function on a maintainer part from the maintainer doesn't need that
16:04 hmmmm          something that you think may have no side effects may in fact have dire side effects
16:04 rubenwardy     and that requires stricter checking
16:04 rubenwardy     (a higher level of quality does)
16:05 nrzkt          rubenwardy, are you a developper ?
16:05 hmmmm          for example, what if it's a piece of "unused" code that gets conditionally used if some compilation option is set, or on a specific platform
16:05 hmmmm          and then that breaks because of your trivial change
16:05 nrzkt          it's not the case here, sorry
16:05 rubenwardy     I am a developer
16:05 hmmmm          well what if you didn't know that
16:05 hmmmm          that's the purpose of review
16:05 rubenwardy     but I am not a member of the core development team
16:05 nrzkt          yeah i know, but here it's not the case.
16:05 hmmmm          i'm so sorry if peer review is an inconvenience
16:06 hmmmm          but upstream will not be a free-for-all
16:06 nrzkt          i agree with peer review, and you review. but i don't talk about strict time checking, i think about code itself
16:06 nrzkt          the goal is the quality of the code
16:06 hmmmm          based on whose assessment?  your own?
16:06 nrzkt          remember i'm the network maintainer
16:07 hmmmm          what if you're drunk or something at the time you decided to change that code and push it?
16:07 hmmmm          I don't care who you are
16:07 nrzkt          you didn't changed :
16:07 nrzkt          :p
16:07 hmmmm          that doesn't give you carte blanche to shit commit
16:07 nrzkt          in english you talk my language for carte blanche ? i didn't know :D
16:07 nrzkt          it's not a shit commit, stop generalize things :p
16:08 crazyR         why is this such a big argument. i agree that there needs to be some reveiew time. but on the flip side, if a change makes a dire fuck up. then we simply revert the comiit etc
16:08 nrzkt          +1
16:08 nrzkt          but here , the debate is just useless
16:08 nrzkt          i only trash dead code
16:08 hmmmm          because, 1). the negative effects of some bad changes might not be immediately obvious
16:08 nrzkt          as we said in france: hmmmm monte sur ses grands chevaux
16:08 hmmmm          and 2). it's messy
16:09 crazyR         aint that where the get 2 devs approval bit comes in??
16:09 nrzkt          2 devs is stupid
16:09 nrzkt          we are not 30 devs on MT
16:09 hmmmm          and 3). it might cause merge conflicts with others'
16:09 VanessaE_      and 3) reverting a commit that took too long to notice may become impossible if there are later commits in the same code
16:09 nrzkt          if somebody commits on connection.cpp without my review it's not normal
16:09 hmmmm          yeah, that's a better explanation of my #3
16:09 hmmmm          always err on the side of caution
16:10 hmmmm          minetest's upstream master branch is expected to have some semblance of stability due to how widely it's used by non-developers as well
16:10 crazyR         look just to make my point clear. i DO agree that code needs to be held to a high standard but at the same time i also understand the need to be flexable towards devs. at the end oif the day everyone that puts in the work does so at there own expense
16:11 hmmmm          waiting 30 minutes before pushing something with no review is not too much to ask for.  really.
16:11 nrzkt          i always said it's a very big problem to have upstream as stable branch.
16:11 nrzkt          as you pointed: with no review
16:11 nrzkt          you do it :p i know you were here
16:11 hmmmm          you people wouldn't last at my job where you need to wait for all the unit tests to pass on all 15 supported platforms as well as 3 peer-review approvals for ANY change at all, no matter how small
16:12 hmmmm          this ^ may be overkill, but they have the right attitude toward quality at least
16:12 crazyR         hmmmm i suppose at your job you have stable an non stable branches...
16:12 nrzkt          why support minetest on motorola on texas instrucments ? :p
16:13 hmmmm          crazyR, we do have non-stable branches, those are equivalent to individuals github repository forks
16:13 nrzkt          this a problem
16:13 hmmmm          it's not a problem
16:13 nrzkt          we don't have an integration branch
16:13 hmmmm          it's quality
16:13 nrzkt          no
16:13 rubenwardy     Off the top of my head: Windows 32, Windows 64, Mginx, Visual Studio, Ubuntu, Andriod, FreeBSD, the other BSD.
16:13 crazyR         thats not the same an official unstable
16:13 nrzkt          preproduction and integration are the same branch, this is a problem$*
16:14 nrzkt          i didn't see any enterprise which merge preprod and integration for its development processus
16:14 VanessaE_      bbl
16:16 hmmmm          yea
16:16 crazyR         also just a side note.. if a person is "in charge" of a paticular area of code... wouldnt that make him or her the person to have final say based on the opinions of other??
16:16 nrzkt          this is the goal, but, as everytime, hmmmm thinks he is at the head whereas we are equal :)
16:17 hmmmm          crazyR:  "in charge" means "responsible for", it doesn't mean that you can have a free for all on the code and totally wreck it
16:17 hmmmm          no one person should have complete control over an area of code
16:18 hmmmm          if you want that... minetest is not for you.  start a fork or your own personal project
16:18 hmmmm          we collaborate here
16:18 crazyR         no but as the person "responsable" he/she should have overall decistion making ont the area conserned. otherwise how can he accept responcability for others actions.
16:18 crazyR         sorry for my spelling :P
16:19 nrzkt          no problem crazyR you are understandable :p
16:20 rubenwardy     The issue he isn't having the overall decision, it's allowing enough time for checks to take place
16:22 crazyR         ok but nrzkt asked a well known. experianced developer to check it, this developer confirmed it look well. that then makes 2 devs that like the work. one of them being the lead developer for the code concerned. would that not be sufficient... if those 2 people can not identify potential issues then any issues if they exist are likly not to be noticed till they pop up in production anyway
16:25 kahrl_         pushing in 30 minutes: https://github.com/kahrl/minetest/commit/18431d50791e320c0520669ff2aee4a4ef77ad53
16:25 nrzkt          okay for me kahrl_
16:28 kahrl_         thanks :)
16:28 crecca         so is there a "30 minutes rule"?
16:28 crecca         or is there not
16:29 nrzkt          pushing it now
16:31 crazyR         from the arguments above... i presume there is a 30 min rule.... but maybe the rule should be.. "30 mins or 2 dev confirms - what ever is first"
16:31 crazyR         that i would hope would keep all parties happy
16:31 hmmmm          crecca:  the rule is that you need to get a certain number of approval from others
16:32 crazyR         so hmmmm where does the 30 mins come from above that you mentioned
16:32 hmmmm          unless the change is 'trivial'.  the 'trivial' exception is for code changes that are aesthetic in nature or make no functional difference, or are merely modifying some constant values or the like
16:32 hmmmm          the only thing is, trivial changes might not all be that trivial, because whether or not a change is trivial could be subjective
16:32 hmmmm          so you need to give other devs a chance to at least look at what you're pushing before it gets pushed
16:33 hmmmm          that's where the 30 minutes comes in
16:33 hmmmm          if you get all the necessary approval in under 30 minutes, you obviously don't need to wait that long
16:33 crazyR         hmmmm modifying some constant can have as bad a consequence as dodgy code... so nothing is trivial really
16:34 hmmmm          of course, in particular the constants I'm talking about are more or less visual like changing the number of caves generated, or the default cloud height, or minimum viewing range, or things that are not of consequence
16:35 hmmmm          the trivial exception only exists to not completely piss off developers
16:35 hmmmm          but the 30 minute waiting period is a decent compromise
16:36 hmmmm          i don't understand why anybody would argue that this setup is too strict, unless they have something they're trying to hide in the code
16:37 crazyR         or unless the person has a very busy life... and just so happens that he would not be able to push after 30 mins, due some other comitment... not everything has to be with bad intent
16:37 hmmmm          well then, maybe they should just wait until they get back
16:38 crazyR         which puts further delays and possible merge conflicts in the pipeworks
16:38 hmmmm          that's such a nonsensical argument
16:38 hmmmm          merge conflicts might happen if a commit sits around for months
16:38 crazyR         hmmmm im not saying your wrong, im simply looking at it from both perspectives
16:38 hmmmm          i'm sure.
16:38 crazyR         whats that suppose to mean?
16:38 hmmmm          nothing
16:39 crazyR         no please enlighten me...
16:39 crecca         hmmmm: are you kwolekr on github?
16:39 hmmmm          crecca:  yes
16:39 hmmmm          you asked me yesterday but you left before i could respond
16:39 crecca         yeah sorry about that
16:40 hmmmm          np
16:40 crecca         did you receive my email?
16:40 hmmmm          hrmm
16:40 hmmmm          let's see
16:40 hmmmm          CMAKE_BUILD_TYPE?
16:40 crecca         yeah
16:40 hmmmm          you should make that into an issue on github
16:41 crecca         ok
16:41 hmmmm          not many of us here are really that good with cmake
16:41 hmmmm          just functional, in case some library needs to get added or something
16:41 hmmmm          it's rather secondary to our development
16:42 hmmmm          if you're good with cmake we'd appreciate some build system cleanup
16:42 crecca         not sure if good but there are things that can be cleaned up quickly
16:42 hmmmm          but yea thank you for pointing this out
16:43 hmmmm          i added semidebug because I needed some debugging ability to see where something is crashing, maybe, but I need the execution speed to test minetest reasonably
16:44 hmmmm          at first Debug was -O1 but this caused too many problems
16:44 crecca         I see
16:44 hmmmm          so now Debug is a real debug with -O0, and Semidebug is -O1 for when you need to use the debugger in-game
16:45 crecca         It's just I don't want to break how devs use the build system so far, only make it clearer for a novice like me how it is usually used
16:45 crecca         for example, does anybody builds just a `src/' directory?
16:45 hmmmm          not really
16:46 hmmmm          i think it's just an organizational thing
16:51 ExcaliburZero  Have any of the devs taken a look over this issue? https://github.com/minetest/minetest/issues/2874
16:52 hmmmm          i haven't, but i don't really have an opinion or any helpful information on that
16:52 hmmmm          sorry
16:53 ExcaliburZero  That's okay, thanks for letting me know though.
16:54 ExcaliburZero  It's somewhat of an odd issue in that it's really more style related than code related.
16:55 ExcaliburZero  I'd like to try to help out on it, but another more experienced dev would probably have to take a look over the issue and decided what should be done, since it's not a single obvious issue.
16:59 crazyR         would it not make sense for the image formspec to work out the image ratio and size it automatically based on that?
16:59 crazyR         that would solve all the issues
17:02 ExcaliburZero  I suppose something like that would function well, but it might make the screenshot aspect ratios non-uniform.
17:02 ExcaliburZero  That would probably make going through mods a little bit odd, in that the shape of the sceenshots of the mods would change depending on the specific mod..
17:03 ExcaliburZero  Seeing the screenshots for some mods as being rectangles, and others being squares wouldn't make a lot of sense.
17:05 crazyR         that would then be down to the people posting the mods. or even better the mod database could crop the screenshots on upload
17:05 crazyR         at least the image wouldnt be screwed up
17:06 crazyR         just having a keep_aspect_ratio boolean at the end of the image formspec would keep it backwards compatable too
17:06 ExcaliburZero  The issue is that there is currently no set standard for the screenshot aspect ratios. So the person making the mod would not know what aspect ratio to use.
17:07 ExcaliburZero  As you noted, we could do auto-cropping to get the right aspect ratio, but it would probably be easier to just have a set aspect ratio that modders are informed to use.
17:07 crazyR         it would be hard to add a cropping facility to the mod database thought,
17:08 ExcaliburZero  All we really need is to just set one aspect ratio for screenshots and stick with it.
17:09 crazyR         that doesnt fix the over laying issue for all images that look screwed up in formspecs thought.
17:10 crazyR         the current system is great if you want to use a fixed size image, but if you want to use dynamic images then it becomes a problem
17:11 crazyR         actually great isnt the right word... ok is the right word as there is still alot of mucking about with static images to get the image formspec size right
17:11 ExcaliburZero  From my understanding, the issue currently isn't so much about file sizes (ex. 300x200px), but aspect ratios (ex. 3:2).
17:17 ExcaliburZero  The more immediate issue right now is that currently mod screenshots are displayed with an aspect ratio of 3:2, and texture pack screenshots are displayed with an aspect ratio of 4:3.7 .
17:18 ExcaliburZero  It would be good if those ratio could be both made the same, thus screenshot ratios would be uniform.
17:18 ExcaliburZero  Also the selected ratio should be added to the documentation in the section for "screenshot.png".
17:21 rubenwardy     Do we have anything like this in MT?
17:21 rubenwardy     http://lua-users.org/wiki/SortedIteration
18:24 RealBadAngel   https://imgrush.com/6dq_0kzJKBY6.png
18:24 RealBadAngel   what do you think?
18:53 johnnyjoy      I have developed a working PostgreSQL database backend, which has been working perfectly. How can I go about gaining the approval of 2 core developers?
18:55 est31          johnnyjoy, make a pull request on github, we will review it then
18:55 johnnyjoy      Thanks, est31.
19:07 RealBadAngel   est31, https://imgrush.com/ax5ssmI-0yu2.png do you like gravel one?
19:09 est31          no
19:09 est31          looks like one of those IKEA pillows or what they are
19:09 RealBadAngel   rotfl
19:10 RealBadAngel   this one i made a bit different
19:10 RealBadAngel   basically heightmap is inversed there
19:10 RealBadAngel   *inverted
19:11 est31          well it still looks good in some way
19:14 est31          hmmmm, didnt you fix #1218
19:14 ShadowBot      https://github.com/minetest/minetest/issues/1218 -- huge error shouldn't be printed in game
19:14 crecca         is anyone bothered that bumpmapped textures look... "noisy" from a distance?
19:18 RealBadAngel   crecca, what do you mean?
19:20 crecca         grainy, harsh
19:20 crecca         a little bit like sandpaper
19:20 RealBadAngel   use filters then
19:20 RealBadAngel   anisotropic filter helps for that
19:22 crecca         ah, indeed
19:26 RealBadAngel   crecca, thx to those effects, textures are not really 16px anymore
19:26 RealBadAngel   using filters makes sense
19:27 crecca         yes, looks much better
19:27 crecca         and works fast
19:27 RealBadAngel   pre-made normals are faster than autogen
19:28 crecca         you're the author of most of the textures?
19:28 RealBadAngel   autogen has to apply 3x3 filters to the texture realtime, for each pixel drawn
19:29 RealBadAngel   crecca, not for textures. im doing advanced effects. normal maps and heightmaps are mine
19:29 RealBadAngel   and code behind it
19:29 crecca         I see
19:29 crecca         what are heightmaps?
19:30 crecca         and normal maps
19:30 RealBadAngel   thyere used for displacement mapping
19:30 RealBadAngel   some pixels can be higher some lower
19:30 RealBadAngel   depending on view angle
19:30 crecca         so that's the bumpmapping?
19:31 RealBadAngel   no, thats displacement mapping
19:31 crecca         ah okay, different beast
19:31 RealBadAngel   bumpmapping is about light
19:31 crecca         oh really
19:31 RealBadAngel   and how the surface behaves when in touch with light ray
19:32 RealBadAngel   http://www.cescg.org/CESCG-2006/papers/TUBudapest-Premecz-Matyas.pdf
19:32 RealBadAngel   this paper can explain you techiques used
19:34 RealBadAngel   we are using 3 methods described here. most common and old - bumpmapping
19:34 crecca         yeah
19:34 RealBadAngel   parallax with slope information
19:34 RealBadAngel   and relief mapping
19:34 crecca         does it have to do with irrlicht engine?
19:35 RealBadAngel   well, irrlicht supports materials with bumpmapping and simple parallax mapping
19:35 crecca         parallax occlusion effectively kills my laptop
19:35 RealBadAngel   but using them means you cannot use own shaders
19:36 RealBadAngel   crecca, this is not low end boxes effect. it requires good gpu
19:37 RealBadAngel   but it may happen that using hand made normals will be faster for you
19:37 RealBadAngel   i mean fast enough
19:38 RealBadAngel   autogen is damn slow
19:38 RealBadAngel   at least for gpus older than 2-3 yrs and whatever shit intel made
19:38 crecca         so this stuff doesn't has to be real-time?
19:39 RealBadAngel   autogen is realtime
19:39 RealBadAngel   it makes normalmaps when you havent supported any
19:39 RealBadAngel   and thats slow
19:40 crecca         so how to support normalmaps?
19:40 RealBadAngel   make them
19:40 RealBadAngel   gimps normalmap plugin, awesomebump, crazybump, number of photoshop plugins...
19:41 crecca         so its a matter of running a texture through an effect and saving it?
19:43 Calinou        AwesomeBump is pretty much the most complete software
19:43 Calinou        crecca, usually you can use automatic filters, but not always
19:44 Calinou        you are supposed to generate a normal map from an height map, not from a diffuse map
19:44 crecca         I see
19:44 Calinou        (the normal map is the derivate of the height map)
19:44 Calinou        (and the height map is the primitive of the normal map)
19:44 RealBadAngel   crecca, map is the source for displacement/bump calculations
19:44 crecca         so yeah, makes sense, if I don't load more chunks, i.e. I don't move, the fps goes up
19:44 RealBadAngel   havin it prepared saves time
19:45 RealBadAngel   but still you have to calculate light level of a pixel or its displacement
19:45 RealBadAngel   you could "bake" such effects in a texture, but then it wont feel live in the game
19:46 RealBadAngel   point of those effects is that they depend on point of view
19:46 crecca         yeah rigt
19:46 crecca         right*
19:48 RealBadAngel   afk, bbl
19:55 crecca         with normal maps I get a strange glitch
19:56 crecca         some textures have glitchy diagonal lines on them
19:56 crecca         where the faces of a mesh connect
19:58 crecca         might be an issue with my gpu though
21:14 johnnyjoy      sfan5, thanks for being so helpful.
21:14 sfan5          np
21:14 sfan5          nice work you've done
21:14 johnnyjoy      Thanks you.
21:15 johnnyjoy      Sorry, Thank you.
21:39 VanessaE_      anyone here?
21:39 VanessaE_      anyone feel like taking on a random segfault?  *waves backtrace* I got something useful this tiiiiiiime :D
21:39 VanessaE_      http://pastebin.ubuntu.com/11879834/
21:51 VanessaE_      https://github.com/minetest/minetest/issues/2913
21:53 est31          yummy!
21:57 VanessaE       :)
21:57 Amaz           I think that the changes I've made to #2911 (on the advice of sfan5) have made it finished. There may be a couple of style issues (or something along those lines) however.
21:57 ShadowBot      https://github.com/minetest/minetest/issues/2911 -- Allow random menu images for subgames by Amaz1
22:01 est31          VanessaE, http://stackoverflow.com/a/7327366
22:01 est31          doesnt look like a "good" bug
22:03 VanessaE       well I could use that issue to collect future segfaults.  maybe with enough of them it'll end up meaning something
22:04 VanessaE       wish I could make it dump core also but ubuntu has stupid measures in place that seem to prevent that.
22:04 est31          its linux "dont let processes read each other's memory"
22:04 est31          policy
22:05 VanessaE       yep I know
22:05 VanessaE       I guess a core won't be too useful with valgrind, come to think of it
22:07 est31          yea :(
22:08 VanessaE       this must be that ongoing memory corruption that I've seen others mention in the past
22:08 est31          dunno how to approach these bugs, other than with a fuzzer
22:08 est31          manual or automated
22:10 VanessaE       you know, come to think of it, I've seen the server crash with a "double free or corruption" report from glibc more than once.  does that help any? :)
22:18 est31          perhaps we should have clustering one day
22:19 est31          where a crash of one server doesnt affect the whole cluster
22:19 est31          @ least in theory
22:19 VanessaE       minecraft allegedly does that.
22:19 VanessaE       in that each client acts as a node on the server's cluster or some such
22:20 TBC_x          tried to run the server with sanitizers?
22:21 VanessaE       sanitizers?
22:21 TBC_x          gcc and clang sanitizers
22:21 TBC_x          whatever compiler you use
22:21 VanessaE       est31: btw:  pushing into the 120% CPU range with 34 players with your patch, but no appreciable lag.
22:23 TBC_x          I'm now trying to valgrind memory leaks on client
22:23 VanessaE       TBC_x: well I guess that's a core dev thing.  I wouldn't know the first thing about it.
22:24 TBC_x          well... the sanitizers are compiler options you pass while compiling
22:24 est31          I guess its a compiler option
22:25 est31          there is a cmake variable for compiler options
22:25 est31          dunno its name
22:25 TBC_x          the server may get laggy tho
22:25 est31          VanessaE, yesterday at this time, the server had a comparable number of players
22:25 TBC_x          the server WILL get laggy
22:26 est31          I see in the cpu stats that its now around 2 lines
22:26 est31          yesterday it was around 3
22:26 VanessaE       est31: yes, so it did save some CPU
22:26 VanessaE       but I guess not as much as you expected?
22:27 est31          yea
22:27 est31          the quick calculation yielded 80%
22:27 est31          but seems its more like 20% to 40%
22:27 est31          well, still a speedup
22:27 VanessaE       time to look for other ways to speed up the areas mod then
22:28 est31          i think thats very fast already
22:28 VanessaE       faster is better :D
22:32 VanessaE       crap.
22:32 VanessaE       those sanitizer options are only available in gcc 4.8.  I have 4.7.
22:32 est31          clang?
22:33 hmmmm          est31, no it's not fixed until there's some kind of mechanism in logging to separate verbose diagnostics messages that get printed to in-game chat
22:33 hmmmm          looking for a logging level equivalent to errorstream, except it gets printed to the console and logs only
22:34 est31          well as you said, lets wait for SN's pr
22:36 VanessaE       est31: looks like clang is 3.0, and sanitizer options start with 3.7
22:36 VanessaE       that's debian for you :P
22:36 TBC_x          VanessaE: Don't you have any machine with bleeding edge distro?
22:37 VanessaE       TBC_x: nope.
22:40 TBC_x          gonna leave valgrind running overnight to get some report, getting 1000 drawtime so you can imagine how long it takes to generate a mesh, hopefully I'm not wasting time
22:41 VanessaE       wow good luck :)