Time  Nick          Message
00:16 paramat       nice, the meshes
04:46 benrob0329    you cant jump off of signs anymore, and some parkour needs that
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: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:41 srifqi2       nerzhul, how about prompt user to reenter password while also asking about whether or not to change server?
08:44 srifqi        !tell nerzhul can you please commit language from weblate before releasing 0.4.16?
08:44 ShadowBot     srifqi: O.K.
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.
10:23 Zeno`         mode 40 is kinda dumb
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       https://github.com/minetest/minetest/issues/5826
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
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
15:08 EDAKIRI       I compile with -DCMAKE_BUILD_TYPE:STRING=Debug and --run-unittests completes without error.
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: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 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: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 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: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 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: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 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 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: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 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 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 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: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 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 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 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 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 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 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: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 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: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: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
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