Minetest logo

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

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

All times shown according to UTC.

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/vi​ewtopic.php?f=18&amp;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

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