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] 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