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

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/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: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/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		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/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: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/minetest/blob/990a96578f20244626b6b9f67f8e79a7e2e614ea/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 333 - 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: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/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: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/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		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/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		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/VanessaE/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/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: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/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
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/mods/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/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
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/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:48		leat1 joined #minetest-dev
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: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/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		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

← Previous day | Channels | #minetest-dev index | Today | Next day → | Google Search | Plaintext