Minetest logo

IRC log for #minetest-dev, 2015-07-14

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

All times shown according to UTC.

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:40 paramat joined #minetest-dev
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 twoelk|2 joined #minetest-dev
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/com​mit/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:50 asl97 joined #minetest-dev
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/HybridD​og/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 Routh joined #minetest-dev
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 luizrpgluiz left #minetest-dev
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?
02:59 paramat left #minetest-dev
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 OldCoder joined #minetest-dev
03:43 hmmmm re-review my commit?
03:43 hmmmm I did it a slightly different way
03:48 blaise joined #minetest-dev
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/minetes​t/blob/990a96578f20244626b6b9f67f8e​79a7e2e614ea/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:13 kahrl_ joined #minetest-dev
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 leat1 joined #minetest-dev
05:19 johnnyjoy disorder
05:20 johnnyjoy Sorry, wrong window.
05:38 leat1 joined #minetest-dev
05:40 leat1 joined #minetest-dev
05:41 Hunterz joined #minetest-dev
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 chchjesus_ joined #minetest-dev
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 leat1 joined #minetest-dev
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/minete​st/blob/990a96578f20244626b6b9f67f​8e79a7e2e614ea/src/mapnode.h#L126
06:29 est31 so we will have to leave out leaves
06:31 leat1 joined #minetest-dev
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 leat1 joined #minetest-dev
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 leat1 joined #minetest-dev
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/kw​olekr/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:57 Amaz joined #minetest-dev
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/kw​olekr/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:21 leat1 joined #minetest-dev
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/minetes​t/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/minete​st/blob/990a96578f20244626b6b9f67f​8e79a7e2e614ea/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 leat1 joined #minetest-dev
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:39 jin_xi joined #minetest-dev
07:39 Calinou joined #minetest-dev
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/minete​st/blob/990a96578f20244626b6b9f67f​8e79a7e2e614ea/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 crecca joined #minetest-dev
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:52 leat1 joined #minetest-dev
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 Yepoleb_ joined #minetest-dev
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:09 Krock joined #minetest-dev
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 leat1 joined #minetest-dev
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/Van​essaE/6a31cc55d1a2c263bdd0
08:30 VanessaE get current moretrees and apply this
08:30 rubenwardy joined #minetest-dev
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 leat1 joined #minetest-dev
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:48 leat1 joined #minetest-dev
08:51 VanessaE est31: ok that seems to work properly
08:53 VanessaE https://gist.github.com/Van​essaE/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:03 leat1 joined #minetest-dev
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:13 leat1 joined #minetest-dev
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 leat1 joined #minetest-dev
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:34 Fritigern joined #minetest-dev
09:34 leat1 joined #minetest-dev
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 leat1 joined #minetest-dev
09:44 VanessaE http://digitalaudioconcepts.com/vanes​sa/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/vanes​sa/hobbies/minetest/screenshots/rando​m/Screenshot_2015-07-14_05-51-58.png
09:52 RealBadAngel ah indeed
09:53 VanessaE https://github.com/minetest/minetest_game/pull/568
09:55 leat1 joined #minetest-dev
10:06 leat1 joined #minetest-dev
10:07 VanessaE sfan5: *poke*
10:08 kilbith joined #minetest-dev
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:10 Fritigern joined #minetest-dev
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 leat1 joined #minetest-dev
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:45 leat1 joined #minetest-dev
10:50 H-H-H joined #minetest-dev
10:56 dv- joined #minetest-dev
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
10:59 Dartmouth joined #minetest-dev
11:00 exoplanet joined #minetest-dev
11:06 leat1 joined #minetest-dev
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:17 leat1 joined #minetest-dev
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/mod​s/stairs/models/stairs_stair.obj
11:26 leat1 joined #minetest-dev
11:35 est31 joined #minetest-dev
11:35 proller joined #minetest-dev
11:37 leat1 joined #minetest-dev
11:37 asl97 since the new update
11:38 VanessaE joined #minetest-dev
11:38 asl97 rubenwardy: this commit: https://github.com/minetest/minetest_game/com​mit/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
11:47 leat1 joined #minetest-dev
11:57 leat1 joined #minetest-dev
12:02 SopaXorzTaker joined #minetest-dev
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:07 leat1 joined #minetest-dev
12:10 Taoki joined #minetest-dev
12:16 ExcaliburZero joined #minetest-dev
12:18 leat1 joined #minetest-dev
12:20 VanessaE_ joined #minetest-dev
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:38 leat1 joined #minetest-dev
12:44 MinetestForFun joined #minetest-dev
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/minetes​t/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:48 leat1 joined #minetest-dev
12:49 RealBadAngel sfan5, http://irc.minetest.ru/minet​est-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:50 _tutima joined #minetest-dev
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.
12:59 leat1 joined #minetest-dev
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
13:19 leat1 joined #minetest-dev
13:24 est31 joined #minetest-dev
13:31 SopaXorzTaker joined #minetest-dev
13:34 FR^2 joined #minetest-dev
13:39 leat1 joined #minetest-dev
13:44 FR^2 joined #minetest-dev
13:50 leat1 joined #minetest-dev
14:00 leat1 joined #minetest-dev
14:07 MinetestForFun joined #minetest-dev
14:11 Hunterz joined #minetest-dev
14:17 RealBadAngel joined #minetest-dev
14:30 CraigyDavi joined #minetest-dev
14:37 hmmmm joined #minetest-dev
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 zat joined #minetest-dev
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:51 nrzkt joined #minetest-dev
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 crecca joined #minetest-dev
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:58 harrison joined #minetest-dev
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 OldCoder joined #minetest-dev
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 leat1 joined #minetest-dev
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 Hunterz joined #minetest-dev
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 Robert_Zenz joined #minetest-dev
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:24 Puma_rc joined #minetest-dev
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:28 sloantothebone_ joined #minetest-dev
16:29 proller joined #minetest-dev
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 sloantothebone joined #minetest-dev
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:53 MinetestForFun joined #minetest-dev
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:00 TBC_x joined #minetest-dev
17:01 leat1 joined #minetest-dev
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:13 rubenwardy joined #minetest-dev
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
17:34 jin_xi joined #minetest-dev
17:48 MinetestForFun joined #minetest-dev
17:54 kilbith joined #minetest-dev
17:55 kilbith left #minetest-dev
18:02 leat1 joined #minetest-dev
18:11 proller joined #minetest-dev
18:12 AnotherBrick joined #minetest-dev
18:24 ShadowBot` joined #minetest-dev
18:24 RealBadAngel https://imgrush.com/6dq_0kzJKBY6.png
18:24 RealBadAngel what do you think?
18:26 dv-_ joined #minetest-dev
18:29 Robby_ joined #minetest-dev
18:29 blais3 joined #minetest-dev
18:29 cheapie_ joined #minetest-dev
18:37 luizrpgluiz joined #minetest-dev
18:41 est31 joined #minetest-dev
18:43 leat1 joined #minetest-dev
18:46 twoelk joined #minetest-dev
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 leat1 joined #minetest-dev
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/pa​pers/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 proller joined #minetest-dev
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:49 H-H-H joined #minetest-dev
19:49 Taoki joined #minetest-dev
19:49 MinetestForFun joined #minetest-dev
19:50 MinetestForFun_ joined #minetest-dev
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
19:59 friti joined #minetest-dev
20:26 Fritigern joined #minetest-dev
20:31 Fritigern joined #minetest-dev
20:48 Fritigern joined #minetest-dev
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:32 Fritigern joined #minetest-dev
21:32 AnotherBrick joined #minetest-dev
21:39 Fritigern joined #minetest-dev
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:43 Fritigern joined #minetest-dev
21:50 est31 joined #minetest-dev
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:09 Fritigern joined #minetest-dev
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 Fritigern joined #minetest-dev
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 :)
22:47 Fritigern joined #minetest-dev
23:21 leat1 joined #minetest-dev
23:37 ottodachshund joined #minetest-dev
23:39 luizrpgluiz left #minetest-dev
23:51 sloantothebone joined #minetest-dev

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