IRC log for #minetest-dev, 2017-05-27

Time	Nick	Message
00:16	paramat	nice, the meshes
00:56		octacian_ joined #minetest-dev
01:23		QwertyDragon joined #minetest-dev
01:28		torgdor joined #minetest-dev
01:32		benrob0329 joined #minetest-dev
01:52		Tmanyo joined #minetest-dev
02:50		kaeza joined #minetest-dev
04:46	benrob0329	you cant jump off of signs anymore, and some parkour needs that
05:21		Hunterz joined #minetest-dev
05:42		kilbith joined #minetest-dev
06:12		luk3yx joined #minetest-dev
06:13	benrob0329	Idea: add a simple player:send_to_server(server, port) command
06:14	benrob0329	It would act like a normal server connect, using the current uname and pword, opting to have a popup if auth fails.
07:01		nerzhul joined #minetest-dev
07:42		DS-minetest joined #minetest-dev
07:50		srifqi joined #minetest-dev
07:54		srifqi joined #minetest-dev
07:55	srifqi	benrob0329, how about disconnect from that server and reconnect it to new server?
08:03	benrob0329	srifqi: thays basically what I'm saying
08:03	benrob0329	Just in a nice way that can be automated with mods
08:10	nerzhul	or not
08:10	nerzhul	security should be considered at there are passwords :)
08:11	nerzhul	if you want us to add a server "cluster" it's more complicated than that, and also it requires to have a specific communication protocol for exchanging data
08:15		Raven262 joined #minetest-dev
08:16		AntumDeluge joined #minetest-dev
08:23		Raven262 joined #minetest-dev
08:40		srifqi2 joined #minetest-dev
08:41	srifqi2	nerzhul, how about prompt user to reenter password while also asking about whether or not to change server?
08:42		srifqi joined #minetest-dev
08:44	srifqi	!tell nerzhul can you please commit language from weblate before releasing 0.4.16?
08:44	ShadowBot	srifqi: O.K.
08:47		YuGiOhJCJ joined #minetest-dev
08:57		Zeno` joined #minetest-dev
09:15		EDAKIRI joined #minetest-dev
09:17	red-002	is mapgeneration stoping before MAX_MAP_GENERATION_LIMIT a bug?
09:18	red-002	it seems to stop a few nodes before it
09:19	Zeno`	I think those few nodes are "padding" around the chunks
09:19	Zeno`	so probably not
09:19	Hijiri	is it correct to say that CSM globalsteps are run every frame
09:19	red-002	anyway to calculate that without just using a magic number?
09:19	red-002	Hijiri, I don't think thats correct
09:20	Hijiri	red-002: why not?
09:20	red-002	it runs every client step
09:20	Hijiri	it looks like the client is stepped every frame
09:20	red-002	I don't think that is run every frame
09:21	red-002	well in that case it should
09:21	Hijiri	alright
09:22	Zeno`	red-002, probably not because the internals of mapgen (and padding in particular) probably should be considered opaque and not relied upon
09:22	red-002	well I guess will just use a magic number and hope someone suggests a better solution
09:23	Hijiri	#define MAGIC_NUMBER 0xdeadbeef
09:25	Zeno`	red-002, ask paramat. But exposing the padding (if any) amount would break forward compatibility
09:27	srifqi	red-002, I think it stops because next mapblock is cutting the limit. Because I think it only generate map when all node in mapblock is inside limit. But, maybe ask paramat.
09:28	red-002	well I need some way to check this since I'm working on removing entities outside the map
09:30	srifqi	31000 mod 80 = 40, so probably that's why it has ~40 block "padding".
09:32	red-002	it seems to be diffrent on both sides of the map
09:32	srifqi	Is it?
09:33	red-002	-30012
09:33	red-002	and 30927
09:34	srifqi	When we change mapblock size, does it also change?
09:34	srifqi	Sorry, I just can't trying it now.
09:34	red-002	chunksize?
09:35	srifqi	idk the term tbh
09:35	red-002	yeah it changes
09:36	red-002	also that caused dungeon-gen to get out of control
09:37	red-002	spammed dungeons everywhere
09:49	srifqi	I hope the size is not hard-coded.
09:52		cd2 joined #minetest-dev
10:23	Zeno`	mode 40 is kinda dumb
10:23		Fixer joined #minetest-dev
10:23	Zeno`	if it's really doing mod 40 then that would probably be a bug
10:24	Zeno`	I'm not sure it should (or does) use mod at all
10:24	Zeno`	the better way is to mask the lower bits
10:26		EDAKIRI joined #minetest-dev
10:26	EDAKIRI	https://github.com/minetest/minetest/issues/5826
10:43		DI3HARD139 joined #minetest-dev
10:44	celeron55	mapgen refuses to do anything with less than a mapgen chunk, and mapgen chunks are aligned to mapblocks kind of funnily
10:45	celeron55	in such a way that the mapblock at 0,0,0 is at the middle of a chunk
10:47	celeron55	were they 5x5x5 mapblocks? that means the 0,0,0 chunk is -2,-2,-2 to 2,2,2 mapblocks inclusive
10:47	celeron55	and then they just go from there
10:49	celeron55	in nodes that'd be from -32,-32,-32 to 47,47,47
11:07		lisac joined #minetest-dev
11:37		Krock joined #minetest-dev
12:23		Taoki joined #minetest-dev
12:33		ShadowNinja joined #minetest-dev
12:36		DS-minetest joined #minetest-dev
13:35		srifqi joined #minetest-dev
13:36	* srifqi	is confused
13:37	* red-arch	wonders why srifqi is confused
13:37	srifqi	after reading celeron55's explanation
13:39	* srifqi	is still amazed on how 0, 0, 0 is the center of mapchunk.
13:40	Krock	the chunksize can be changed manually in one of the world settings
13:41	Krock	but the blocksize is hardcoded value of 16
13:59	srifqi	Is it because of how the map saving works?
14:04	Krock	the chunksize has nothing to do with map saving. it's just for the mapgen stuff
14:31	EDAKIRI	TestRandom : Floating point exception
14:31	EDAKIRI	I suppose I can catch it in GDB and look at it. It's been a while since GDB.
14:32	EDAKIRI	From current Dev HEAD.
14:32	EDAKIRI	[PASS] testPcgRandom - 0ms : was the last test to succeed
14:33	EDAKIRI	setting video_driver = software also crashes . but the unit test crashes independently of that.
14:38	EDAKIRI	setting video_driver = burningsvideo works at 3FPS
14:39	EDAKIRI	with HDX512 textures
14:45		DFeniks joined #minetest-dev
15:02		kaeza joined #minetest-dev
15:08	EDAKIRI	I compile with -DCMAKE_BUILD_TYPE:STRING=Debug and --run-unittests completes without error.
15:09		paramat joined #minetest-dev
15:14	paramat	red-???, map gen limit has no bugs, i can explain further. the furthest generated terrain is at a different distance for + and - for a reason, and terrain stops before the limit for a reason. it's not doing mod 80
15:15	* paramat	is a world edge expert :]
15:15	srifqi	"for a reason", why?
15:16	red-001	so how would I go about calculating where the edge is?
15:17	paramat	it is possibe to calculate the furthest terrain, will explain ..
15:17	srifqi	we're waiting
15:20	paramat	mapgen only generates in full chunks, 80^3 nodes (or whatever chunksize^3). if a chunk cuts the set map gen limit it will not generate
15:20	paramat	however
15:21	paramat	the volume processed for each chunk is the chunk plus a 16 node deep shell around it, if that shell cuts the limit the chunk will not generate
15:21	paramat	chunk minp is at -32 + n * chunksize for each axis
15:22	paramat	maxp is 47 + n * chunksize
15:22	paramat	max point of the processed volume is 47 + (n * chunksze) + 16
15:23	paramat	chunk size is a multiple of 16 because it is a collection of mapblocks, 16^3 nodes
15:24	paramat	the 'chunksize' setting is default 5, and is the width of a chunk in mapblocks
15:25	paramat	blahblah
15:25	srifqi	Why 16 node addition?
15:26	paramat	"the volume processed for each chunk is the chunk plus a 16 node deep shell around it, if that shell cuts the limit the chunk will not generate"
15:27	paramat	or do you mean, why the shell?
15:29	paramat	so, terrain will always stop at least 16 nodes before 31000 or whatever limit is set
15:30		nerzhul joined #minetest-dev
15:31	Zeno`	that cannot be documented though!
15:32	Zeno`	what if it changes to 32 nodes in the future?
15:32	Zeno`	since it can't be documented then if people need this value then there needs to be a function that provides that value
15:34	Zeno`	if not a function then a Lua constant (but I don't know if that's possible offhand)
15:34	srifqi	paramat, why the shell?
15:35	Zeno`	it's more accurately called padding then a shell, but, yeah, paramat can explain
15:38	paramat	i think the padding size is a constant in engine code, perhaps it should be set as a constant in mtg
15:39	paramat	the padding is for structures that extend beyond the chunk border on generation: large caves, dungeons, trees
15:39	srifqi	I mean, why it is there in the first place?
15:39	paramat	trees is the main reason
15:39	srifqi	Oh, okay. I receive it just after I send.
15:40		Raven262 joined #minetest-dev
15:40	paramat	if trees could not extend above a chunk on generation then they would not appear if their root is within 16 nodes of the chunk top border
15:41	paramat	large caves extend beyond in the hope they overlap, and to make them larger
15:41	paramat	same for dungeons
15:42	paramat	this is also why trees cannot be > 16 nodes tall if you want them to appear at all altitudes
15:43	paramat	but, i'm working on a big jungletree that will have restricted altitude to allow it to be taller
15:44	EDAKIRI	compiling with -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo also did not crash unittests. I don't know what CXXFLAGS it uses.
15:53	nerzhul	world corner found at 30927,10,30927
15:53	nerzhul	strange
15:53	paramat	that's normal
15:55	nerzhul	maybe, no problem , i'm fixing #5824
15:55	ShadowBot	https://github.com/minetest/minetest/issues/5824 -- Entities can get out of map boundaries (Â±31000)
15:56	paramat	that needs care as i commented
15:56	nerzhul	no bug for me
15:56	nerzhul	entity look at its position and world limits, if outside, removed.
15:56	paramat	will look
16:02	nerzhul	#5829 is the global idea, i just need to fix the position check because it seems wrong, but idea is there
16:02	ShadowBot	https://github.com/minetest/minetest/issues/5829 -- Remove SAO when mapgen limits are reached by nerzhul
16:10	nerzhul	paramat, seems blockpos_over_mapgen_limit is not accurate
16:12		YuGiOhJCJ joined #minetest-dev
16:13	Zeno`	paramat, it must be a constant
16:13	Zeno`	i.e. defined somewhere
16:13	Zeno`	otherwise mods will use there own magic values (like 16)
16:13	Zeno`	s/there/their
16:13	Zeno`	there is no perhaps ;)
16:15	Zeno`	That it's not should be opened as a bug report
16:17	Zeno`	maybe even a blocker
16:21	nerzhul	wow mapgen spams when somebody is a mapblock limit
16:22	Zeno`	we all know why that 31000 is the "traditional" limit right?
16:22	Zeno`	or has that been forgotten?
16:22	nerzhul	it's not exactly that
16:22	Zeno`	yeah it is that
16:23	Zeno`	we should not be adding checks everywhere
16:23	nerzhul	i'm adding check on the LuaEntitySAO, it's normla
16:23	Zeno`	but we have to if we allow it to be less than 31000
16:23	Zeno`	so the original intention becomes pointless
16:24	Zeno`	we have to add the checks everywhere
16:24	nerzhul	i'm doing the fix based on mapgen itself, it's dynamic
16:24	Zeno`	the original intention was an optimisation choice to avoid checking that things that don't overflow (and since it's a signed value overflow is undefined behaviour)
16:26		srifqi2 joined #minetest-dev
16:26	Zeno`	so since things have changed we have to check limits everywhere. Right?
16:27	Zeno`	those checks can't even be omitted in mapgen
16:27	paramat	why is 'blockpos over mapgen limit' not accurate? it is in block co-ordinates remember, see my comments in your PR, you made a mistake
16:27	Zeno`	mods also have to check it, or whatever calls they make must make sure they're valid
16:28	nerzhul	paramat, no it's good, it's just the calcul to translate SAO to block pos which is crazy and not good...
16:28	paramat	and yes i agree the entity limit should be linked to the set 'map gen limit'
16:32	nerzhul	okay i have the good calcul
16:34	nerzhul	oh there is a better function, i didn't known
16:34	paramat	it canbe roughm because remember terrain stops long before the 'map gen limit' setting
16:34	nerzhul	i'm testing it, it's simpler :)
16:34	paramat	* can be rough
16:35	nerzhul	doesn't seems accurate
16:35	nerzhul	objectpos_over_limit is not good
16:36	paramat	terrain always stops at least 16 nodes before the limit you don't need accuracy higher than 16 nodes
16:36	nerzhul	i throw item in the non generated terrain and the function doesn't match
16:36	nerzhul	309299 / 310000
16:36	nerzhul	here is the limit and the SAO pos
16:37	paramat	well i just explained why
16:37	nerzhul	and 31000 * BS is not good
16:37	nerzhul	object is in the nether
16:38	Krock	please keep in mind that we also support limiting the map, so these should be respected too
16:38	paramat	what do you mean by 'function doesn't match'?
16:39	nerzhul	i throw an iterm stack, it's in the not generated limits, and the item stack fall into it
16:39	paramat	and shouldn't you be using the 'map gen limit' setting instead?
16:39	nerzhul	because of X position i show you before
16:39	nerzhul	i'm doing this but it's more complicated :p
16:39	nerzhul	because i want accuracy here
16:40	paramat	yes i explained why terrain stops long before mapgen limit
16:40	paramat	read logs
16:40	nerzhul	that doesn't solve my problem
16:40	paramat	ok well i know how to make it accurate
16:41	nerzhul	i have the function, but if you have better show me
16:41	paramat	i think i should take over on this
16:42	paramat	shall we respect the mapgen limit setting or remove entities at 31000 always?
16:42	paramat	i think the former
16:44	nerzhul	i updated the PR
16:44	nerzhul	https://youtu.be/bqAj0N0e-xk
16:44	paramat	looking
16:46	paramat	do you want accuracy to the node so that an entity cannot fall down the side of the world?
16:47	paramat	i might be able to do this
16:51	paramat	yes it will need a new function such as 'sao pos over mapgen limit'. i guess this is wanted for release? if so i will work on it
16:55		Grandolf joined #minetest-dev
16:56		Grandolf joined #minetest-dev
16:58	paramat	what i can do is calculate the 'furthest generated terrain node' is positive and negative directions for the current 'mapgen limit' setting, then use these values in this check for SAO position
16:59	paramat	(*in positive and negative ..)
16:59	paramat	those values may be useful elsewhere, maybe even fetchable from lua
17:01	ShadowNinja	nerzhul, rubenwardy, sfan5, Zeno`, Krock, nore, paramat, celeron55: Dev meeting in an hour.
17:04	nerzhul	paramat, my pr adds it
17:04	nerzhul	it's not the best accuracy but i works as intended
17:04	nerzhul	return blockpos_over_mapgen_limit(floatToInt(p, BS * MAP_BLOCKSIZE - 0.4f));
17:06	nerzhul	for the lua maybe, here i'm addressing SAO over map limits
17:10	Krock	nerzhul, what are you trying to do there?
17:11	Krock	for an object pos it should rather be return blockpos_over_mapgen_limit(floatToInt(p / MAP_BLOCKSIZE, BS)); no?
17:11	paramat	ok, i'm not insisting on node accuracy, will review and test
17:12	Krock	oh, I see. floatToInt agument 2 basically does the same
17:13		torgdor joined #minetest-dev
17:13	Krock	what I'm worried about is rather the '-0.4f', as it disorts the blockpos the further you go away
17:13	paramat	yes it should be p / MAP_BLOCKSIZE
17:13	nerzhul	no
17:14	Krock	paramat, (p, BS * MAP_BLOCKSIZE) and (p / MAP_BLOCKSIZE, BS) will have the same effect, as I jsut noticed
17:14	nerzhul	p / MAPBLOCK_SIZE, BS = p BS * MAPBLOCK_SIZE but it's not accurate, the -0.4f permit to fix the limit, else it's a little bit far from the limits
17:15	sfan5	Krock: floatToInt(a, b) is basically (a) / (b)
17:15	paramat	or rather p / (MAP_BLOCKSIZE * BS) ?
17:15	nerzhul	if you have better formula to find the real limit, okay for me, else if works as intended
17:15	Krock	sfan5, with some rounding magic around but yeah. ik
17:15	sfan5	but for correctness reasons you shouldn't put multiplications or division in the first param
17:16	paramat	ok i see
17:16	paramat	it's just the - 0.4f that is concerning
17:17	Krock	you're basically doing round(x / 159.4), which causes an error
17:17	Krock	s/.4/.6/
17:18		minetestproject joined #minetest-dev
17:18		minetestproject left #minetest-dev
17:20	paramat	also needs checking at negative world edge as behaviour will be different, but yes doesn't need to be completely accurate
17:21	paramat	on which side of the terrain edge should the sao limit be? perhaps it's better to remove just inside than just outside?
17:22	paramat	.. to avoid stuff falling down endlessly over the edge
17:30	paramat	yes 'blockpos over mapgen limit' will be very inaccurate because terrain can stop up to 96 nodes before the mapgen limit. so keeping the removal inside the terrain edge means it could happen up to 96 nodes inside the terrain edge. however this could be considered 'weirdness at world's edge' :]
17:42	ShadowNinja	Zeno`: Banning all logged in users? :-P
17:42	Zeno`	lol oops
17:42	Zeno`	how do I remove that?
17:42	ShadowNinja	Done.
17:44		Grandolf was kicked by Zeno`: Grandolf
17:44	VanessaE	$a: ?
17:44	VanessaE	oh.
17:59	paramat	that ban covers -hub too i hope
18:00	VanessaE	it does now.
18:00	ShadowNinja	nerzhul, rubenwardy, sfan5, Zeno`, Krock, nore, paramat, celeron55: Dev meeting now.
18:00	ShadowNinja	Calinou: Any progress on the website?
18:00	ShadowNinja	Last blocker to consider: https://github.com/minetest/minetest/pull/5767: Don't add damage flash while punch texture modifier is active
18:01	ShadowNinja	Has anyone tested it?
18:01	VanessaE	#5767
18:01	ShadowBot	https://github.com/minetest/minetest/issues/5767 -- Don't add damage flash while punch texture modifier is active by stujones11
18:01	VanessaE	(GH didn't like your link)
18:02	ShadowNinja	Works for me, your client must thing : is part of the URL.
18:02	VanessaE	maybe.
18:03	rubenwardy	I was involved with reviewing that code previously, and that fix looks correct to me
18:03	rubenwardy	but still needs testing
18:04	Calinou	ShadowNinja: no
18:04	ShadowNinja	rubenwardy: Could you do that now?
18:04	rubenwardy	do you think it should extend the flash period?
18:04	Calinou	what about just capping damage flash?
18:05	VanessaE	ShadowNinja, Calinou: some of the images in here may be useful also, https://daconcepts.com/vanessa/hobbies/minetest/screenshots/
18:05	Calinou	I mean, the first-person one
18:05	rubenwardy	as in, reseting the timer to 0.05, but not reapplying the brighten as it's already done
18:05	rubenwardy	ShadowNinja: compiling
18:05	Calinou	VanessaE: yeah but I need consistent settings :/
18:05	VanessaE	(it's a lot of random crap though)
18:06	ShadowNinja	rubenwardy: Yeah, each hit should probably reset the flash countdown timer, just not continue adding to it.
18:06	paramat	i think it should not extend the flash length
18:06	rubenwardy	currently if there is a flash in progress, it just ignores the requested one. Ie: the timer stays the same, and finishes as if there was no punch
18:07	rubenwardy	I guess the time is reasonable small this won't matter
18:07	paramat	since it is a brighteneing just a quick flash is all that is needed, if the flash becomes long it looks weird
18:07	rubenwardy	not extending is simpler
18:07	rubenwardy	by extending, I mean that the flash would end X time after the last click
18:08	rubenwardy	so not an add, but a set
18:08	ShadowNinja	rubenwardy: Looks like you could move the m_reset_textures_timer code after the loop to get it to just extend the time.
18:09	ShadowNinja	And remove the other added condition likely (although I'd have to look closer and test to be sure).
18:11	paramat	i don't like how it extends the timer on damage amount
18:11	paramat	long flashes don't look good
18:12	ShadowNinja	I don't mind much, just choose whichever way you prefer rubenwardy, as long as the brightens don't stack.
18:12		DFeniks left #minetest-dev
18:12	rubenwardy	I think that it's simpler to not extend the flash, and the flash is so small it would be hard to notice it anyway
18:13	paramat	fine with me
18:15	ShadowNinja	We also have https://github.com/minetest/minetest/issues/4810 -- Unittests crash on release build. It's not a new bug though. I'm doing some testing ATM to see if it's compiler specific and to try and trace the error.
18:16	rubenwardy	ok, I can confirm that it fixes the bug
18:17	ShadowNinja	clang doesn't have the unittest bug, and volatile fixes it, so it looks a bit like a compiler bug.
18:19	rubenwardy	argh
18:19	sfan5	yes looks like a compiler bug
18:20	sfan5	it does not cause problems in practice though so no hurry in fixing it
18:20		kilbith joined #minetest-dev
18:22	ShadowNinja	Anything else that any devs would like to discuss at this meeting?
18:22	sfan5	no other blockers for release?
18:22	Zeno`	I don't think we should fix that "compiler bug"
18:22	Zeno`	apart from that I have no issues to raise
18:23	VanessaE	ShadowNinja: #5640 ... and also, what would the recipe look like to directly-craft a pre-colorized node?
18:23	ShadowBot	https://github.com/minetest/minetest/issues/5640 -- Automatic item and node colorization by juhdanad
18:23	VanessaE	(there's some feature in mt_game that relies on that ^ )
18:23	rubenwardy	feature freeze :P
18:24	ShadowNinja	sfan5: Nope, apparently not.
18:24	rubenwardy	although if there's no other blockers, no harm discussing it
18:24	VanessaE	rubenwardy: special case. some mt_game feature was merged before that ^ was, so one needs the other.
18:24	sfan5	well then
18:24	VanessaE	all blockers appear to have been satisfied.
18:25	paramat	well, juhdanad said mtg is not broken if 5640 is not merged
18:25	VanessaE	paramat: ok, that's fine then. still shouldn't that go in for completeness?
18:25	* VanessaE	<-- paranoid about engine breakage after that 32/64 bit debacle
18:26	Zeno`	there is one instance of a use of an unitialized variabke
18:26	Zeno`	variable*
18:26	paramat	yes would be good to have 5640 in, but is it too late? dunno
18:26	Zeno`	but I'm not going to open a bug report because it appears harmless (plus I can't track it down LOL)
18:26		GreenDimond joined #minetest-dev
18:26	VanessaE	it's only too late if no one wants to do some extensive testing of it
18:26	ShadowNinja	I suppose we'll just focus on releas at the next meeting.
18:28	VanessaE	what about the crafting question?
18:28	VanessaE	I haven't seen any documentation or discussion about crafting a pre-param2-colorized item (e.g. to complement colored item stacks)
18:29		Grandolf joined #minetest-dev
18:29	paramat	see discussion in #5768
18:29	ShadowBot	https://github.com/minetest/minetest/issues/5768 -- Item and node colorization PRs in engine and game possibly essential for release
18:29	GreenDimond	paramat I don't know how to fix the stair model on game#1736 ... one way the metal outline orientation is wrong, the other way the wood grain is wrong :/
18:29	ShadowBot	https://github.com/minetest/minetest_game/issues/1736 -- Add inner and outer stair corners by MarkuBu
18:29	VanessaE	paramat: there ain't much conversation there..
18:30		Grandolf left #minetest-dev
18:30	paramat	^ Grandolf appears
18:30	VanessaE	...and disappears.
18:32	ShadowNinja	The changelog could probably use an update: http://dev.minetest.net/Changelog
18:32	paramat	GreenDiamond weird how the wood texture does that
18:32	GreenDimond	:/
18:32	paramat	.. since the lower half is horizontal
18:33	GreenDimond	would we rather have messed up wood grain or messed up metal outline? I want neither Dx
18:33	paramat	i assumed the texture was projected onto the side, so the top half of the wood stair should not be vertical
18:33	GreenDimond	Hrm.. I got another idea...
18:34	ShadowNinja	Devs: Do you all think we're ready to make a release at the next meeting?
18:34	ShadowNinja	That would move the release date forward one day.
18:35	VanessaE	paramat: commented.
18:35	paramat	yes i saw your crafting question, good question. seems hardware colouring is not quite done yet
18:36	VanessaE	ok.
18:36	GreenDimond	I am in love with the saving window size
18:36	paramat	more people are around on a weekend so releasing late-Sat early-Sun seems good
18:37	GreenDimond	Hm. I think I found the prob...
18:37	paramat	so i'm fine with 3rd June
18:37	GreenDimond	The textures seem linked to certain faces, and I didn't use the stair side texture on the top part apparently?
18:37	GreenDimond	Meh.
18:38	GreenDimond	Ill just try it and see what happens :/
18:39	GreenDimond	Whoever decided to make the sides of stairs 3 triangles made it really hard to make corner stairs.
18:40		red-002 joined #minetest-dev
18:40		red-002 joined #minetest-dev
18:42	nerzhul	sorry guys i was late, no, i don't see any other blocker in the current list
18:42	nerzhul	but if possible it can be nice to fix many issues PR
18:42	nerzhul	issues (without pr :p)
18:43	nerzhul	if somes are interested #5829 needs some help to finish
18:43	ShadowBot	https://github.com/minetest/minetest/issues/5829 -- Remove SAO when mapgen limits are reached by nerzhul
18:43	paramat	yes i'm on that
18:43	nerzhul	nice :) if you have the correct formula for the PR tell me
18:44	paramat	will do, within a day i hope
18:44	nerzhul	no problem, i just hope we can fix it before release, could be nice
18:44	paramat	i expect so
18:45	VanessaE	paramat: I really feel the need to delay release.
18:45	VanessaE	until the craft issue and 5640 are resolved.
18:45	VanessaE	incomplete features in release is a bad thing imho
18:45	rubenwardy	#5640
18:46	ShadowBot	https://github.com/minetest/minetest/issues/5640 -- Automatic item and node colorization by juhdanad
18:46	rubenwardy	heh
18:46	rubenwardy	the point of feature freeze is to increase stability, not completeness
18:46	nerzhul	exact
18:46	VanessaE	no one said it was :)
18:46	nerzhul	if feature is not finished, just disable if it's so critical
18:46	rubenwardy	If MTG is 'imcomplete
18:46	rubenwardy	oops
18:47	nerzhul	just fix MTG, it should be ready for release, for the android build
18:47	ShadowNinja	Krock, sfan5, nerzhul, celeron55: You would have to be here at the next meeting to make builds and update launchpad.
18:47	VanessaE	but if it's possible to complete a feature with only trivial changes, why not do so?
18:47	nerzhul	release is on sunday not saturday ShadowNinja
18:47	ShadowNinja	nerzhul: It doesn't have to be.
18:47	rubenwardy	If MTG is 'incomplete' due to missing features, then revert the things that made it such. Ie: if there's no craftitem coloring of wool, revert the change to one node wool
18:47	nerzhul	ShadowNinja, but we fixed a date for our end users :p
18:48	nerzhul	agreed with rubenwardy
18:48	rubenwardy	I bet they would be horrified if the release came a day early
18:48	paramat	revert game#1707
18:48	ShadowBot	https://github.com/minetest/minetest_game/issues/1707 -- Automatic item colorization for creative mode by juhdanad
18:48	nerzhul	yes :)
18:48	VanessaE	why are you guys so intent on releasing on THAT day?
18:48	nerzhul	because it make VanessaE talking
18:49	ShadowNinja	nerzhul: It will stibb be done by the 4th. The release date is tentative, it's not a strict contract to release on that day.
18:49	VanessaE	very funny ;P
18:49	Krock	it's not like they could already get a very new dev build...
18:49	GreenDimond	success!
18:49	ShadowNinja	s/stibb/still/
18:49	Krock	I'll be here next weekend :)
18:49	GreenDimond	I got the outer stair fixed :)
18:49	paramat	good
18:49	GreenDimond	I had to use the correct faces
18:49	nerzhul	ShadowNinja, i'm not sure i will be there this day, but no problem for me as i release Android and the play store is long, i need just MTG too
18:49	GreenDimond	now to redo the inner stair xD
18:49	VanessaE	nerzhul: I really want an answer to my question
18:49	nerzhul	i'm there on the morning (GMT) because i need to be at home
18:50	VanessaE	why does it HAVE to be released on Sunday?
18:50	VanessaE	what's so bad about delaying it a day or a week or whatever?
18:50	nerzhul	VanessaE, it was decided months ago because ~ 6 months after previous release and may was not optimum
18:50	paramat	so yes we should perhaps revert gmae1707, although, see #5768 i'm not sure a revert is needed?
18:50	ShadowBot	https://github.com/minetest/minetest/issues/5768 -- Item and node colorization PRs in engine and game possibly essential for release
18:50	GreenDimond	Also, Minetest has it's own "void".
18:50	nerzhul	generally devs are here on sunday
18:50	ShadowNinja	nerzhul: Alright, it's fine with me if an official Android build takes a day.
18:50	VanessaE	nerzhul: this isn't Ubuntu, we don't HAVE to release on a 6-month schedule.....
18:50	GreenDimond	If you miss a face on a model, it becomes static.
18:51	nerzhul	ShadowNinja, compilation is done in ~ 15 mins on my PC, but it's not important, i just need a valid mtg tag and release tag
18:51	nerzhul	i will jsut verify the compilation on Friday to ensure this time i can release on the exact tag not a backport :p
18:51	nerzhul	VanessaE, no, but the date is the date
18:51	paramat	we don't have to release by 4th June, but if no problems arise we can
18:51	VanessaE	nerzhul: then CHANGE the date.
18:51	nerzhul	NO
18:51	nerzhul	1 week is needed to ensure no blocking bugs are remaining
18:51	paramat	if necessary we can delay a week
18:52	nerzhul	it's not necessary
18:52	VanessaE	what if it is?
18:52	VanessaE	and you just don't see it as such, at the moment?
18:52	rubenwardy	I personally think we should release more than 6 months
18:52	nerzhul	all blockers are solved. 1 week security, if no more blockers just before release, release.
18:52	rubenwardy	have stable back patches
18:52	VanessaE	nerzhul: the problem is as rubenwardy just alluded to
18:52	nerzhul	4 months car be good, but 0.4 will take 6 months at least if think
18:52	VanessaE	releases are too far apart
18:52	nerzhul	0.5*
18:53	VanessaE	either delay this release as needed until everything we all want is actually in (and can reasonably be), or make another point release shortly after
18:53	nerzhul	maybe we can shorten cycles after that, i tried to convince everybody to release in april, but it was not accepted :)
18:53	VanessaE	6 months is way too long for MT users
18:53	nerzhul	no.
18:53	nerzhul	There is always a PR someone need
18:53	VanessaE	true
18:53	VanessaE	but you know perfectly well what I meant.
18:53	VanessaE	if the person wanting some PR isn't here to press for it, is it THAT badly needed?
18:53	GreenDimond	Hm. I wonder if is easier to create the inner stair from a full block mesh...
18:54	paramat	there is currently no need to dealy to after 4th June
18:54	nerzhul	a fixed date permit to ensure all should have verified it will be integrated, if not, it's also a little bit problem of the PR owner to not sell his PR to coredevs
18:54	VanessaE	GreenDimond: get your stairs meshes from moreblocks.
18:54	paramat	*delay
18:54	GreenDimond	VanessaE: Moreblocks doesn't use meshes
18:54	VanessaE	GreenDimond: it uses meshes where they make sense.
18:54	ShadowNinja	We've been frozen for a week and we still have a week left with no blockers (as soon as rubenwardy merges the one fix). We could even release today or tomorrow.
18:54	nerzhul	i go with my wife on TV, i will re-discuss after if needed, but release on next weekend is good
18:54	nerzhul	i don't care if it's sunday or saturday :)
18:55	GreenDimond	VanessaE: It uses meshes for slopes, but not for stairs.
18:55	nerzhul	ShadowNinja, regression can happen on blocking fix, 1 week test is required to be sure.
18:55	VanessaE	ShadowNinja: and if we do, then we have to wait another 6 months for the next one
18:55	VanessaE	we need to work on making faster point releases
18:55	nerzhul	0.5 is breaking release it take time :p
18:55	rubenwardy	anyone else want to approve #5767 ?
18:55	ShadowBot	https://github.com/minetest/minetest/issues/5767 -- Don't add damage flash while punch texture modifier is active by stujones11
18:55	VanessaE	and by that I mean say 2 weeks or a month if that's what it takes.
18:56	VanessaE	ShadowNinja, nerzhul I'm getting tired of telling my users "get the latest git" because release is too fucking old!
18:56	GreenDimond	agreed^
18:56	VanessaE	I'd rather tell them "get release x.y.z" or "wait for release x.y.z+1" where z+1 might be just a couple weeks away or something
18:56	GreenDimond	~3 releases a year might be better.
18:56	paramat	too bad, a release takes time, 5 months is short enough, as i and others have explained
18:57	VanessaE	no, paramat
18:57	GreenDimond	But I don't want to get into this so forget I said anything.
18:57	VanessaE	a release does NOT take that much time
18:57	VanessaE	15 mins to build for android, 5-15 mins for each linux and windows build. so in a couple hours, you have all the release files.
18:57	VanessaE	it's all politics to agree WHEN to rlease
18:57	Krock	you'll see a few days after 0.4.16 comes out, there will be a topic for 0.5.1 :P
18:57	ShadowNinja	0.5 isn't breaking acording to semver (which it supposedly what we want to do). I say we just call the next version 0.5 and don't break anything.
18:57	VanessaE	not IF.
18:58	ShadowNinja	Then make a point release every month or so.
18:58	VanessaE	sorry guys, I just ain't buying "it takes months and months to plan a release". it takes hours, not months.
18:58	VanessaE	ShadowNinja: that's what I've been saying
18:58	VanessaE	precisely that.
18:59	Krock	VanessaE, well, there might be bugs and PRs outstanding that must be in the next release
18:59	paramat	that's naive, a release needs a long time for big features to be worked on, plenty of time for completing things, then freeze. also a month of relaxation for devs after a release is good
18:59	Krock	"relaxation"? what?
18:59	VanessaE	Krock: then make another release.
18:59	paramat	point releases would never have stability
19:00	Krock	VanessaE, soon: Minetest 0.4.16.2
19:00	VanessaE	Krock: no
19:00	VanessaE	0.4.17.
19:00	VanessaE	or 0.4.18
19:00	paramat	so they are no different from grabbing current dev version, as people already do
19:00	VanessaE	or however many it takes until things "catch up"
19:00	VanessaE	paramat: users DON'T WANT dev versions
19:00	VanessaE	they want releases
19:00	Krock	VanessaE, the thing is that there will most likely be a rewrite in the protocol. Also, C++11 is a notable change
19:01	VanessaE	Krock: that's a whole different issue
19:01	VanessaE	that's something that belongs on another branch from master then
19:01	paramat	yes dev holiday after a release, it's stessful and hard work, we need to relax a bit after a release
19:02	VanessaE	paramat: if you need to "relax after release" you're doing the release incorrectlyu.
19:02	VanessaE	-u
19:02	paramat	point releases cannot be more stable than dev versions
19:02	VanessaE	a release should not be so stressful
19:02	VanessaE	paramat: you're missing the point
19:02	VanessaE	users DO NOT WANT "dev". they want "release", even if the latter isn't necessarily more stable.
19:02	VanessaE	it's about giving users a version number, not a random commit ID or date or whatever.
19:03	GreenDimond	I thought CSM would break stuff...
19:03		Fixer joined #minetest-dev
19:03	VanessaE	GreenDimond: it generally didn't.
19:03	paramat	Vanessa, needing to relax after something means you put effort into it, some of us work very hard on MT
19:03	GreenDimond	True^
19:03	VanessaE	paramat: exactly, and release should not require a bunch of effort
19:03	VanessaE	if it does, you're doing it wrong.
19:03	GreenDimond	The release part is not what they need to relax from, its all the work the put into the game for the release.
19:03	rubenwardy	it's better to make mistakes and release patches, rather than putting loads of effort into a release because it'll stay broken for 6 months
19:04	VanessaE	rubenwardy: exactly my pointy
19:04	GreenDimond	^That's what Minecraft does
19:04	VanessaE	-y
19:04	rubenwardy	we don't even need a real release every month, we could just release bug fix updates
19:04	VanessaE	release patches and tag them with a version number or something
19:04	Fixer	rubenwardy: +1
19:04	paramat	well, we could just label a current dev version with a point number, but how is that different from using a dev version if there is no extra stability?
19:04	Fixer	0.4.16.1
19:04	Fixer	.2 etc
19:04	VanessaE	even if that means going to four digits on the versioning scheme
19:04	VanessaE	(but it shouldn't)
19:04	VanessaE	paramat: you're not listening to me :(
19:05	red-002	have a seperate branch for dev and patches?
19:05	paramat	wtf? MT requires effort
19:05	GreenDimond	No one is listening to anyone. We are reading chat ;)
19:05	rubenwardy	also, any release on 0.* can be a breaking change in SemVar
19:05	VanessaE	users don't want "get the latest git from Foovember 43rd". they want "get version 1.2.3.4 or later". it's about the language I have to use to tell them what to get.
19:06	paramat	i am listening and you're making zero sense and stating ridiculous things
19:06	VanessaE	wtf?
19:06	rubenwardy	I agree with VanessaE here
19:06	GreenDimond	Maybe we discuss this after 0.4.16 release?
19:06	rubenwardy	but it is more work
19:06	VanessaE	you don't have to deal with users on a daily basis, paramat. I do.
19:07	VanessaE	telling the user to "go get git pull Foovember 34th or later" makes no sense to them!
19:07	VanessaE	they don't know what a dev build is.
19:07	rubenwardy	as in, you still have to make sure you complete blockers before a release, even if the feature freeze is shorter
19:07	VanessaE	regular users need VERSION numbers
19:07	VanessaE	and that means more frequent releases
19:07	rubenwardy	the compromise is a feature release every 6 months, as we do know, and bug fixes releases every month
19:07	GreenDimond	That... is also true :/
19:07	VanessaE	so that I don't have to tell them to reach for a dev build
19:07	rubenwardy	*now
19:07	paramat	the process running up to a release is hard work and stressful, you're not a core dev so it isn't for you
19:07		red-001 joined #minetest-dev
19:07	VanessaE	paramat: if it's that damned hard, then you're doing it wrong, jeez
19:08	rubenwardy	that's because the feature freeze is long, and because we have to fix 6 months of blockers
19:08	rubenwardy	well, more the latter
19:08	VanessaE	and I will thank you NOT to play the "you're not a core dev" card here, please.
19:08	paramat	"putting effort into a release is doing it wrong" so game dev is about being lazy and not putting in effort?
19:08	Shara	I have to agree with VanessaE, really.
19:08	VanessaE	paramat: I did not say that.
19:09	VanessaE	I said, and I quote: [05-27 15:07] <VanessaE> paramat: if it's that damned hard, then you're doing it wrong, jeez
19:09	VanessaE	the key word is "that"./
19:09	Fixer	red-002: stable branch and dev branch, stable branch gets critical bugfixes backported into (if possible) and released as 0.x.x.x
19:09	paramat	if it's that hard, effort was put into something = good
19:09	GreenDimond	Can we like, stop arguing? This is pointless. You guys have gotten nowhere...
19:09	VanessaE	in other words if you're putting so much effort into the process of creating a release that you need a big rest afterward, you're doing the release process wrong.
19:09	VanessaE	at no point did I say that effort into the engine/game itself is wrong/bad/etc.
19:09	ShadowNinja	If releases are so difficult to do that we can't do them once every month or two then there's something wrong.
19:10	VanessaE	ShadowNinja: exactly my point
19:10	VanessaE	script the fucking thing
19:10	VanessaE	just like I do for dreambuilder and HDX.
19:10	GreenDimond	'-'
19:11	paramat	we can add a version number often sure, but the point releases will not be any more stable than dev versions, because stability takes time and effort
19:11	VanessaE	paramat: they don't HAVE to be more stable
19:11	VanessaE	they just have to be a reliable point of reference
19:11	ShadowNinja	Part of the issue is that we need 3+ different people to do all the builds. (OSX, Ws MinGw, Ws MSVC, Android, launchpad, etc).
19:11	Zeno`	well, this release is not going to be stable I know that
19:11	red-001	just call them unstable releases
19:11	VanessaE	red-001: no, more like "beta" releases
19:12	VanessaE	Zeno`: what's unstable at it in this case?
19:12	Zeno`	there is too much focus on "features"
19:12	red-001	anyway minetest-dev isn't that much more unstable then minetest-stable
19:12	Zeno`	nothing has been check for "stable"
19:12	paramat	well it's obvious i'm writing about relaxing after the effort of the whole release cycle
19:12	Zeno`	there is a feature freeze
19:13	VanessaE	paramat: and it's obvious I'm writing about the effort of the release cycle -- not the effort going into the engine/game over time.
19:13	Zeno`	shit, just last week most devs told me there was not a client memory leak
19:13	GreenDimond	Somehow I managed to get the texture of the inner stair magnified :P
19:14	VanessaE	GreenDimond: why are you so hung up on using mesh nodes here anyways? nodeboxes are converted into meshes at runtime anyway
19:14	paramat	what is 'the release cycle' for you, is it the few hours of actually bumping the release?
19:14	Zeno`	actually all devs told me that
19:14	GreenDimond	But the grain is right wtf xD
19:14	VanessaE	paramat: it's the two or three weeks of these kinds of arguments.
19:14	VanessaE	not the preceding 5 months
19:14	Zeno`	so if I wasn't a stubborn bastard it would have been in the stable release
19:14	GreenDimond	I dont know VanessaE, ask paramat or MarkuBu. It was requested, so I am making it.
19:15	paramat	the 2-3 weeks running up to release is hard work, after that we feel like unwnding a little
19:15	paramat	*unwinding
19:15	VanessaE	paramat: and that's my point. you shouldn't NEED to work hard just to get a damn release out.
19:15	Zeno`	let's not release then
19:15	paramat	it is inevitably is hard work
19:16	paramat	*-is
19:16	VanessaE	then you're doing it wrong.
19:16	paramat	crap
19:16	paramat	working hard is not wrong
19:16	VanessaE	working hard is not inherently wrong. working hard when you should not have to, IS.
19:16	kilbith	don't you understand "hard work" means arguing on github for him
19:16	VanessaE	because it puts too much load on YOU
19:16	Zeno`	I happen to agree with VanessaE
19:17	VanessaE	hush, kilbith :P
19:17	Zeno`	making a release should be no harder than adding a tag
19:17	VanessaE	if you can't execute a couple of scripts to push out a release for all supported platforms, you're doing something wrong
19:17	paramat	why should game dev not be hard work?
19:17	VanessaE	paramat: again, I did not say game/engine dev shouldn't be hard work
19:17	VanessaE	I said the few weeks leading up to release should not be
19:18	rubenwardy	it's ensuring that the engine is free of blockers that is the hard part
19:18	paramat	that's not what you're describing, you are talking about 2-3 weekd of run-up to a release, that is hard work
19:18		Grandolf joined #minetest-dev
19:18	Zeno`	the weeks leading up to release should actually be very easy
19:18	rubenwardy	but surely that would be easier if you did that more often? The fixing of them, less the testing
19:18	VanessaE	rubenwardy: let's see. download patch. apply. run it. ok, that's 5 minutes. then what?
19:18	Fixer	just relax guys
19:18	rubenwardy	VanessaE: testing and making those patches
19:19	VanessaE	rubenwardy: I'm speaking in the context of a third-party PR
19:19	rubenwardy	there's no guarantee one would occur
19:19		Grandolf left #minetest-dev
19:19	Fixer	there are servers that use newest engine and do sorta prerelease test
19:19	rubenwardy	which means that a core dev would need to investigate
19:19	Zeno`	Once feature freeze is invoked there is nothing hard that should be left to be done
19:20	VanessaE	Zeno`: exactly, short of having to implement new code to fix a bug of course.
19:20	paramat	look, i totally agree that the actual few hours of bumping a release is easy. but if you talk about 2-3 weeks of bugfixing and rushing to finish thiings, that is hard work
19:20	GreenDimond	Still have no idea how these textures got magnified o_0
19:20	Zeno`	paramat, that's the point. We should no be doing that
19:20	VanessaE	paramat: I think you forget just how many lines of code I have to maintain, and how long I've been doing this. just because I don't code on minetest engine does not mean I don't understand the release process.
19:21	paramat	feature freeze can sometimes be hard work, is was last time
19:21	Zeno`	if it's hard then our quality control is not good
19:21	VanessaE	paramat: there should not have to BE 2-3 weeks' of freezes, and there wouldn't be if point releases came out every several weeks instead of always a major release every 6 months
19:22	rubenwardy	it's worth noting that paramat has made about half of the bug fixes since the feature fe=reeze
19:22	rubenwardy	approximately one a day
19:22	VanessaE	rubenwardy: which is a good thing!
19:22	VanessaE	I'm glad he's here coding on it
19:22		Grandolf joined #minetest-dev
19:22	Fixer	Zeno`: not only tag, translation update, build stuff for few platforms, do changelog and update website, tada
19:22	rubenwardy	there is a compromise here
19:22	VanessaE	but paramat, you can't extrapolate against your personal workload
19:23	paramat	no, sometimes stuff arises that makes it hard
19:23	Warr1024	ah, freezes ... reminds me of the days before they invented branches...
19:23	Fixer	i agree you can make releases more relaxed process
19:23	rubenwardy	users are slow to update, we don't want to release a 0.x when we know it's unstable, as they may not upgrade to 0.x.1
19:23	paramat	feature freeze is necessary, din't say it is not
19:23	Fixer	nerzhul wants to autobuild packages already, maybe even for all platforms
19:24	VanessaE	let's see.. 14:45 to 15:23. So in the 40 minutes we've been arguing, a release could have already been pushed, tagged, and maybe even a preliminary announcement thereof.
19:24		Grandolf was kicked by Zeno`: Grandolf
19:24		Fuchs joined #minetest-dev
19:24	Fixer	then you just update translations by running script (east), do changelog, release
19:24	rubenwardy	Warr1024, a dev branch would be nice, but we don't have enough core devs to multitask well enough
19:24	rubenwardy	well, for previous releases
19:24	rubenwardy	this one seems to have less blockers atm (touch wood)
19:24	paramat	*don't say
19:25	rubenwardy	finished exams yesterday, and there's no big bugs left to fix!
19:25	VanessaE	paramat: feature freeze is necessary. 2 weeks of busting your ass during the freeze should not be, and would not be IF THERE WERE POINT RELEASES every several weeks
19:25	VanessaE	there simply would be no need for long freezes
19:25	VanessaE	if any at all
19:25		Fixer joined #minetest-dev
19:26	VanessaE	even at a major release you wouldn't need much of a freeze, because 90% of the work was already done in the previous few point releases.
19:26	rubenwardy	well, as said users are slow to update, VanessaE, which means we should do some testing, but less than if it were 6 months until the next release
19:26	paramat	Vanessa you are not talking about the few mins of bumping release, you are talking about 2-3 weeks of release preparation, please stop switching between one and the other to confuse the argument
19:26	VanessaE	rubenwardy: that's what I'm saying.
19:26	VanessaE	paramat: I'm talking about both, try to keep up :)
19:27	rubenwardy	additionally, less time between releases means less bugs probabilistically, I'd say
19:27	Warr1024	you don't need a complete feature freeze at all, just "no new features in this branch" combined with "bug fixes always first, before new features."
19:27	VanessaE	paramat: let's simplify the argument: 6 months between releases, with 2-4 weeks of busting your ass right before it. Or: releases every several weeks, with far less testing and NO busting your ass.
19:27	paramat	if there were point releases every few weeks, each needing to be stable, there would be no time to develop and perfect any large feature
19:28	VanessaE	paramat: again, they do not have to be "Stable"
19:28	VanessaE	they just have to be beta.
19:28	VanessaE	there just has to be a version number to point users to.
19:28	paramat	point releases cannot be as stable as out current 'stable' release
19:28	rubenwardy	I'd say no less than 4 weeks between patch/bug fix only releases, unless there are major breaking bugs
19:28	VanessaE	paramat: no one ever said they had to be!
19:28	VanessaE	why are you complicating the issue?
19:29	VanessaE	rubenwardy: that's why I said "several" weeks, I'm not really sure what the best timing for point releases would be.
19:29	exio4	ignoring that I am a completely outsider to the issue, why not go for both?
19:29	VanessaE	rubenwardy: so say 6-8 weeks between points.
19:29	VanessaE	hey exio4, long time no see.
19:29	rubenwardy	hey exio4
19:29	paramat	if they don't need to be stable, then a feature freeze as done now would still be required
19:29	exio4	hello :)
19:30	Warr1024	fixed time intervals work well for projects that have fairly consistent availability of resources (i.e. devs * time)
19:30	VanessaE	paramat: no it wouldn't be - because by the time you get to a major release date, most of the critical bugs would have already been worked out, and you already HAVE several weeks between the last point release and the major release, so you STILL have time for a feature freeze if you really need it.
19:31	paramat	then you are describing point releases being stable, which you are also arguing against
19:31	VanessaE	no, I am not
19:31	VanessaE	"stable" != bug free
19:31	exio4	why don't we go with the even-odd releases? and "releases every maybe 2-4 months"?
19:32	VanessaE	"stable" = doesn't have major differences in API/compatibility between versions
19:32	rubenwardy	that's a stable API
19:32	paramat	we do actually already fix bugs as they arise, so what's different? nothing, just add a point version number and we continue as normal
19:32	VanessaE	paramat: in other words, I am using the Debian definition of the word
19:33	rubenwardy	actually, nnm
19:33	rubenwardy	*nvm
19:33	GreenDimond	Got the meshes right. MarkuBu or someone will have to define new hit/selection boxes though
19:34	Warr1024	if you release too infrequently, then you either have your hard work gathering dust instead of reaching your audience, or you have everyone saying "just run the dev builds because the 'release' ones are too ancient."
19:34	VanessaE	paramat: that's my point exactly. if some commit works okay enough that a server owner can safely point their users at it, that commit should be considered as a point release candidate. it doesn't have to be bug-free, it just has to work and be new enough to get whatever feature or older bugfix it is that the server admin is interested in.
19:34	exio4	Warr1024: that's why I propose even-odd releases
19:34	Warr1024	the "dev build" problem can also fragment your community.
19:34	paramat	ok
19:35	Warr1024	what are even/odd? ist that like the tick/tock thing intel did?
19:35	paramat	Vanessa that sounds reasonable
19:35	VanessaE	paramat: so right now, here, today, at this exact hour and minute, the engine works well enough that a server can safely run it. right?
19:35	exio4	and then there are only long feature freezes for even releases, and maybe just 4-5 days for an odd release
19:35	exio4	Warr1024: even releases are "stable", odd releases are "dev"
19:36	VanessaE	paramat: then, assuming for the moment that we weren't talking about making a major release, RUN ALL THE SCRIPTS "\o/ and bam, point release!
19:36	VanessaE	shit, I blew the meme
19:36	VanessaE	"\:D/
19:36	VanessaE	there.
19:36	paramat	at times of low-risk
19:36	VanessaE	yes exactly!
19:37	nerzhul	Fixer, autobuild is done for Debian/Ubuntu but only in debug no release
19:37	VanessaE	that way you get in-field testing, and if there's some major bug, it gets reported sooner anyway
19:37	paramat	ok. i was more taking issue with the ridiculous things said, rather than the actual concept
19:37	VanessaE	paramat: ok, which things were ridiculous?
19:37	GreenDimond	You don't need release dates anyway. Just throw a release out there and say "Hey. New release." out of the blue.
19:37	VanessaE	because from my standpoint, everything I said makes sense.
19:37	Warr1024	why not kust make all releases dev and stable? there will be new features, probably SOME bugs, but protocols will rarely change in a way that creates significant breakage?
19:38	nerzhul	but yes, i always talked about automate our build process, and i agree it should be done, but not with travis which is pure shit
19:38	VanessaE	GreenDimond: well yeah exactly that, for a "point" release.
19:38	GreenDimond	Of course everything from your standpoint makes sense just like everything from paramats standpoint makes sense.
19:38	paramat	well, see above, that's enough arguing :]
19:38	VanessaE	nerzhul: nah, fuck travis (if he's your type :P )..
19:38	VanessaE	paramat: honestly, I don't know which terms you're disagreeing with
19:38	VanessaE	because you're falling behind :)
19:38	Warr1024	if you can find decent automation, no reason you couldn't release every day...
19:39	nerzhul	gitlab-ci is more and more powerful, because we can take any docker container as a build distro to test all distros
19:39	GreenDimond	So what is the outcome?
19:39	VanessaE	Warr1024: well that's a little extreme :P
19:39	nerzhul	release every day doesn't make sense.
19:39	GreenDimond	What's the decision?
19:39	Warr1024	no, extreme is "release == commit"
19:39	nerzhul	the decision is this cycle will finish next week. Release will be done on saturday on sunday
19:39	exio4	Warr1024: nightly relase
19:40	nerzhul	nightly already exists on gitlab and should be completed
19:40	GreenDimond	And what is the new cycle?
19:40	exio4	I don't think any kind of static cycle would work for Minetest
19:40	GreenDimond	Next version is 0.5.0 and then release whenever it works?
19:40	nerzhul	if you want deb => https://gitlab.com/minetest/minetest/pipelines
19:40	exio4	unless I missed something and you've got some funding
19:40	nerzhul	seriously, release whenever it works ? ...
19:41	GreenDimond	I don't know :P
19:41	nerzhul	without 100% unit tests and integration test it's not possible
19:41	Warr1024	depends on what you mean by "release". The word, itself, implies more of a "letting go," while most people talk about releases as if they require a "push" sort of effort. The difference is mainly in managing downstream expectations.
19:41	GreenDimond	That's what I got out of all this xD
19:41	nerzhul	and release too often mean being stuck with too many retrocompat modes to maintain and loose readability
19:41	VanessaE	nerzhul: yes, actually. whenever it works, issue a release if it has been more than say 6 weeks or so, maybe
19:41	GreenDimond	Hence, why I asked. What's the decision!?
19:42	VanessaE	run scripts, tag the current commit, post an announcement. an hour's work, tops.
19:42	exio4	nerzhul: why don't we propose different "levels" for APIs?
19:42	VanessaE	(well assuming you guys can fix the automated build problem)
19:42	nerzhul	0.5.0 cannot be release too fast as we have big refactor to do with C++11
19:42	exio4	nerzhul: that'd mean things added would first be `experimental` for maybe two releases
19:42	GreenDimond	So are we doing 0.4.16.x?
19:42	nerzhul	enhancing the gitlab pipeline can help
19:42	nerzhul	no
19:42	VanessaE	nerzhul: well semver isn't decimal, so it's not like 0.5.0 has to happen right after 0.4.16. it could be 0.4.5453 if it had to be
19:43	VanessaE	GreenDimond: 0.4.16.
19:43	GreenDimond	okay...
19:43	nerzhul	ridiculous
19:43	VanessaE	what is?
19:43	nerzhul	we release 0.4.16 next week, after breaking compat, 4++ => 0.5, reset 16 to 0
19:43	Warr1024	isn't 0.5.0 the "pipe dream" milestone that everyone will keep talking about forever, and will include all the refactors everone wishes were possible, as they toil away endlessly on 0.4.99999999?
19:43	VanessaE	nerzhul: yes, I just said that.
19:43	GreenDimond	So just plain ol' 0.4.16, and then the next release?
19:43	VanessaE	nerzhul: it doesn't matter what the third number is when you wanna bump the x.4.x
19:44	exio4	I propose the experimental tag for changes
19:44	GreenDimond	So it goes as normal... 0.4.16 => 0.5.0 => 0.5.1 => etc..?
19:44	VanessaE	it's not decimal
19:44	nerzhul	exio4, no.
19:44	nerzhul	yeah 0.5.1 after 0.5.0
19:44	nerzhul	0.5 is for compat break, after we return back to a compatible mode
19:44	rubenwardy	Warr1024, 0.5 will be the release after 0.4.16
19:44	VanessaE	GreenDimond: 0.5.x and beyond happen only if no one finds a reason for a 0.4.17 release, or .18, .19, whatever
19:44	nerzhul	like the 0.4 cycle, for a time, 2 years of stable devel sounds reasonable
19:44	exio4	so if there are more releases in a small timeframe, you can have a window for changes
19:44	Warr1024	is 0.5.0 actually approaching complete?
19:44	VanessaE	rubenwardy: you mean the next major release.
19:44	VanessaE	not the next point release
19:44	nerzhul	0.5.0 was not started.
19:45	nerzhul	the dev cycle will start after 0.4.16
19:45	GreenDimond	Okay good. So this whole thing was not about release numbers, just when they are released.
19:45	rubenwardy	it will be the one after this one, unless we move to a patch system
19:45	VanessaE	rubenwardy: we need to move to a patch system
19:45	VanessaE	or rather, a frequent-point-release system,
19:45	VanessaE	as previously discussed.
19:45	VanessaE	"discussed"
19:45	rubenwardy	we do
19:45	rubenwardy	doesn't make my point invalid
19:46	Warr1024	I pop my head in here every few months/years to hear people mention 0.5.0 in passing as they're talking about the next impending 0.4.* release...
19:46	rubenwardy	just not fully qualified
19:46	rubenwardy	Warr1024, we have client side modding
19:46	GreenDimond	So if we move to "patch" system or whatever, it will be 0.4.16 => 0.4.16.x (etc..) => 0.5.0 => etc?
19:46	VanessaE	GreenDimond: it would be 0.4.16-> 0.4.17 .... and eventually 0.5.0
19:47	VanessaE	I don't think anyone here wants to add a fourth digit
19:47	GreenDimond	the x in 0.4.x is the patch?
19:47	rubenwardy	I'd rather patch releases be added as a new number
19:47	rubenwardy	GreenDimond, no, minor
19:47	rubenwardy	we basically use 0.major.minor
19:47	VanessaE	GreenDimond: in semver, yes.
19:47	GreenDimond	so what is the patch number o_O
19:47	VanessaE	"Given a version number MAJOR.MINOR.PATCH, increment the:"
19:47	rubenwardy	semvar is major.minor.patch
19:48	VanessaE	(according to semver 2.0.0)
19:48	rubenwardy	so we should either move to be semvar compliant
19:48	rubenwardy	or we should add a forth number
19:48	VanessaE	I thought we already technically did?
19:48	rubenwardy	I prefer the former, tbh
19:48	paramat	i sometimes can't keep up with rapid exchanges on IRC, i'm slow with social communication by text, slow to process what is written, and type slowly (borderline aspergers)
19:48	GreenDimond	So if we switch to patch system it will be major.minor.patch and currently it's 0.major.minor
19:48	VanessaE	semver doesn't acknowledge a fourth parameter.
19:48	rubenwardy	VanessaE, we don't use semvar
19:48	VanessaE	paramat: no worries.
19:49	VanessaE	rubenwardy: eh? I thought we switched to that a few versions back?
19:49	rubenwardy	nope
19:49	VanessaE	huh.
19:49	rubenwardy	patches must only be bug fixes
19:49	VanessaE	ok well then the semver argument doesn't even apply anyway
19:49	GreenDimond	if we use 0.major.minor right now, then what is the 0?
19:49	exio4	GreenDimond: it's a 0
19:49	rubenwardy	GreenDimond, to show we're unfinished :)
19:49	GreenDimond	That's it?
19:49	VanessaE	so let's just stick to 0.4.x and increment x with every point release until 0.5.0 comes out
19:49	GreenDimond	But when will 0.5.0 come out?
19:49	GreenDimond	When it breaks right?>
19:49	exio4	what's 0.5 about?
19:49	rubenwardy	December
19:50	VanessaE	it'll be out in forever. :P
19:50	paramat	i'm still now going back through all the comments by others i didn't have time to read :]
19:50	GreenDimond	With the new C++11 or whatever?
19:50	exio4	I like C++11 <3
19:50	exio4	let's use boost too!
19:50	VanessaE	GreenDimond: when we're ready to break something big or at least that's what 0.5.0 was supposed to be for
19:50	Warr1024	0 indicates that it's an open-source project. only commercial dev houses give two shits about the magical and arbitrary 1.0. :-D
19:51	GreenDimond	Does changing to the latest C++ indicate a "break"?
19:51	rubenwardy	no
19:51	rubenwardy	I wouldn't say so
19:51	GreenDimond	Okay...
19:51	exio4	there are probably breaking changes while doing so
19:51	GreenDimond	Why should we break stuff anyway?
19:51	rubenwardy	it's a change in dependency, but wouldn't break any worlds or the API
19:51	exio4	to make use of the C++11 awesomeness
19:51	VanessaE	GreenDimond: think more like network compatibility
19:51	GreenDimond	So mods would still be unaffected?
19:51	VanessaE	maybe? maybe not
19:51	VanessaE	depends.
19:51	GreenDimond	If the API is left alone, they should be fine?
19:52	DS-minetest	the last number could be incremented further for ever, at the moment it's number of issues * 0.02
19:53	Warr1024	no, eventually it will hit overflow :-D
19:53	DS-minetest	there's no overflow
19:53	GreenDimond	Who cares if it doesn't break anything. Just change to 0.5.0 on the release after 0.4.16 because that's what everyone has been told and is expecting.
19:54	GreenDimond	Then after that we can worry about breaking things
19:54	GreenDimond	and changing ver. # because of it
19:54	rubenwardy	0.4.65537
19:54	GreenDimond	lol
19:54	Warr1024	naw, unexpected things will start to break, and you'll find obscure scripts and stuff that expect to be able to parse the version number as a series of signed int32's or something ... it's a fundamental law of the universe.
19:55	Warr1024	just like dark matter and dark energy, there are dark dependencies, and dark bugs in them...
19:55	DS-minetest	yeah, somewhen there's not enough disk space
19:56	DS-minetest	(the number could be split to multiple numbers)
19:57	DS-minetest	i mean multiple long unsigned ints
19:57	DS-minetest	that make one number
19:57	GreenDimond	0.4.Ï€
19:57	DS-minetest	mhm
19:58	VanessaE	heh
19:59	* DS-minetest	thinks the number is not that important
19:59	GreenDimond	eventually Ï€.Ï€.Ï€
19:59	ShadowNinja	I think I found the unittest bug: https://github.com/minetest/minetest/issues/4810#issuecomment-304472708
19:59	GreenDimond	0.4.Î©
20:00	DS-minetest	GreenDimond: 0.Ï€ because Ï€ has a .
20:00	GreenDimond	truuuu
20:00	GreenDimond	but Î© doesn't :P
20:01	GreenDimond	or how about 0.4.â„µâ‚’
20:02	paramat	well, there was a suggestion to switch to 4.16.0, then later 5.0.0, that gives us the extra number for point releases
20:03	paramat	while keeping a progression
20:03	GreenDimond	We should do april fools releases xd
20:03	GreenDimond	*xD
20:04	GreenDimond	0.c.55
20:04	DS-minetest	ha
20:04	VanessaE	well according to semver it has to be 1.0.0 but for the sake of continuity, 5.0.0 might work.
20:04		behalebabo joined #minetest-dev
20:04	VanessaE	GreenDimond: 0.186000.55 ?
20:04	VanessaE	:)
20:04	exio4	VanessaE: 186k? I think you're using the wrong units
20:04	DS-minetest	0.300000000.55
20:04	VanessaE	heh
20:04	VanessaE	well I'm in the US so nyah. :P
20:04	DS-minetest	use m/s
20:05	Warr1024	ha, I'm in the US and I completely forgot that 186k number.
20:05	VanessaE	paramat: well according to semver it has to be 1.0.0 but for the sake of continuity, 5.0.0 might work.
20:05	GreenDimond	We could change the header to "Mintest" on the apr. fools release xD
20:06	VanessaE	paramat: semver says major version has to increment on a backward-incompatible change in the "public API"
20:06	GreenDimond	Minecraft has a random chance of a "Minceraft" header
20:06	* VanessaE	is reading http://semver.org/
20:06	Warr1024	"Mintest" actually sounds like a reasonable name for a minimalist subgame
20:06	GreenDimond	Merptest
20:06	VanessaE	derptest :P
20:06	Warr1024	Minetset or something might work
20:07	VanessaE	let's just call the next release mesetint :P
20:07	GreenDimond	"mintest" and "minetset" are both common typos
20:07	DS-minetest	+
20:08	paramat	well i don't care about semver :]
20:08	Warr1024	minet, mineter, minetest
20:08	paramat	lol mintest!
20:08	GreenDimond	or how about this version number \u0030\u002e\u0034\u002e\u0031\u0036
20:08	paramat	mindset
20:09	Warr1024	isn't semver basically xkcd #927 for version numbering?
20:09	ShadowBot	https://github.com/minetest/minetest/issues/927 -- Fix compiling issue of MSVC by BlockMen
20:09	Warr1024	argh, dumb bot, wrong context
20:10	paramat	i just dislike the idea of ever using 1.0.0 because it implies 'doneness' which doesn't suit MT
20:11	paramat	raises expectations too high
20:11	Warr1024	same here
20:11	Warr1024	I'd say it lowers expectations in a way.
20:11	* DS-minetest	likes the 0.4.x
20:12	Warr1024	I associate 1.0 less with "no glaring deficiencies" as much as with "significant reduction in development speed"
20:12		Fuchs left #minetest-dev
20:13	Fixer	or release 0.5 now, since you have CSM and stuff...
20:13	Warr1024	maybe 0.(4.5).0 ? :-D
20:13	VanessaE	heh
20:14	VanessaE	oh also,
20:14	Warr1024	my unicode-fu is not sufficient to dig out the '1/2' char...
20:14	VanessaE	http://semver.org/#spec-item-9 <--- we ARE allowed to write e.g. 0.4.17-1234 if wanted.
20:15	VanessaE	er +1234
20:16	paramat	oh and about nodebox meshes, they get generated with the internal faces of all boxes, which is why .obj meshes are better, no internals, faster render
20:16	Warr1024	if semver is a.b.c, then it seems minetest is 0.a.(b+c)
20:18	Warr1024	paramat: is there a reason why they generate internal faces, or could/should they just be made not to?
20:18	VanessaE	paramat: but meshes have another problem - hidden faces aren't really hidden
20:18	VanessaE	(well they are at the driver/opengl level, but not at the meshgen level)
20:20	Warr1024	what tools do you use to make obj meshes, anyway? I've always stuck to nodebozes because they're the only ones I knew how to make.
20:20	VanessaE	paramat: so with e.g. a cube as a mesh node there will necessarily be three faces that the mesh gen has to process, even if they'll be culled at th driver level
20:20	VanessaE	Warr1024: blender.
20:20	Warr1024	argh, was hoping you wouldn't say blender
20:20		GreenDimond joined #minetest-dev
20:21	VanessaE	blender isn't hard to leanr
20:21	VanessaE	learn*
20:21	GreenDimond	Not hard at all
20:21	VanessaE	and most of the skills you learn there can transfer over to other 3d-related stuff e.g. 3d printing
20:21	GreenDimond	Well, the basics aren't difficult :)
20:21	GreenDimond	Its the memorization that's the hard part
20:21	GreenDimond	stupid hexchat doesn't update all the chat I missed when my internet went offline >:/
20:21	GreenDimond	Kiwi does
20:22	GreenDimond	At least logs exist :P
20:22	Warr1024	I hate memorization, and don't do enoigh 3d stuff to make it worth it.
20:23	Warr1024	blender is too modal for me too, and I use vi.
20:23	VanessaE	heh
20:23	GreenDimond	I have barely stepped into the world of poly-ing. I do more sculpting, but I have gotten bored of that so I am messing with polying now :P
20:24	GreenDimond	making the stairs was easy enough
20:28	paramat	Warr1024 conversion from nodeboxes to meshes preserves internal faces, better if they didn't but that's how RBA coded it. Not sure it's easy or fast to determine if a face is internal or not, maybe it was kept simple for performance
20:30	Warr1024	I guess we could adopt a "pre-optimized" nodebox format, or even something like just specifying faces directly in lua ... or maybe the nodebox optimization could be done automatically, bu only once...
20:30	Warr1024	the "direct faces in lua" thing is basically obj meshes w/o the obj file, I guess...
20:31	Warr1024	I should go see what's IN an obj file ... maybe it's something not completely unreasonable to edit by hand...
20:37	Warr1024	It looks like somebody intrepid enough COULD write something to convert nodeboxes to obj meshes, and maybe do some reasonable optimizations ... dunno if I'd be able to get to it anytime foreseeably soon, though.
20:40	nerzhul	paramat, i agree, a 1.0 is not reasonable atm as there are many refactor to do in both server and client to have a nice 1.0 :)
20:46	VanessaE	Warr1024: already did that.
20:46	VanessaE	look on the forum for the "slope test" thread
20:47	Warr1024	VanessaE: ah, thanks
20:47	VanessaE	I wrote a script and put it in there to convert nodeboxes to .obj
20:47	VanessaE	I think rubenwardy's nodebox editor can do it, too
20:47	VanessaE	the script does not attempt to cull hidden/buried faces though
20:48	GreenDimond	Seems many people are having problems with running latest MT as a server
20:49	GreenDimond	And by 'many' I mean 2
20:49	VanessaE	^^^ paramat see? THIS is why we need frequent point releases. what does "latest MT" mean? :)
20:49	GreenDimond	-_-
20:49	GreenDimond	Fine. 'Feature Freeze Release' if you will.
20:49	VanessaE	heh
20:49	Fixer	GreenDimond: what problems?
20:50	GreenDimond	https://forum.minetest.net/viewtopic.php?f=18&t=17708
20:50	GreenDimond	read up :)
20:50	GreenDimond	Actually 3 ppl having probs
20:50	GreenDimond	or maybe only 2
20:50	GreenDimond	point is they having problem
20:51	GreenDimond	*problems
20:56	Fixer	there currently at least 77 servers that are using 0.4.15-dev, and 27 have players on them right now, i don't see major problems or some huge inflow of bugs posted
20:56	Fixer	maikerumine problem is not clear and may be out of memory error
20:57	Fixer	iirc he still uses 32 bit builds
20:57	Fixer	that custom subgame may be outdated and have bugs
20:59	VanessaE	Fixer: that's because there just really aren't that many big, critical bugs that actually affect end users
20:59	Fixer	"e server was running great for 20 minutes, then became unresponsive to the point where there was no error, just total game freeze."
21:00	Fixer	i have impression he run out of memory
21:13	Fixer	settingtypes is up to date?
21:19	paramat	should be, apart from #5836
21:19	ShadowBot	https://github.com/minetest/minetest/issues/5836 -- Added missing levels to logging menu by NathanSalapat
21:56		QwertyDragon joined #minetest-dev
22:20		GreenDimond joined #minetest-dev
22:31		paramat joined #minetest-dev
22:35		chris__ joined #minetest-dev
22:59		nyuszika7h joined #minetest-dev
23:07		silwol joined #minetest-dev
23:51		DI3HARD139 joined #minetest-dev
23:51		Tmanyo joined #minetest-dev
23:58	Hijiri	fixed some of the issues with #5819
23:58	ShadowBot	https://github.com/minetest/minetest/issues/5819 -- Fix default item callbacks to work with nil users by raymoo

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