Time Nick Message 01:46 Zeno` merging #5130 01:46 ShadowBot https://github.com/minetest/minetest/issues/5130 -- Re-add halo highlight by juhdanad 02:47 Derr I'm thinking about creating my first mod, a flower seed mod. Has a flower seed mod already been created? 02:54 Derr I was wanting one flower seed that would grow randomly into any type of flower 03:01 rubenwardy Derr, #minetest is for mod discussion 04:02 paramat wut? .. no way we can have another release soon, for many reasons 04:04 thePalindrome Sure we can, just switch the versioning to be dates 04:04 thePalindrome "Minetest-2017-01-29" "Minetest-2017-01-30" etc :P 04:04 thePalindrome we can release every day :D 04:04 rubenwardy it's a little early. I say we wait until March/April (3/4 months) 04:24 paramat 'a little' is quite an understatement 04:28 Zeno` release already? 04:28 Zeno` we haven't done anything yet lol 04:29 paramat i've only just recovered from the last release :] 04:29 paramat some are suggesting more frequent releases, 6 months is ok but 3/4 months is too frequent 04:29 Zeno` I dunno... even MArch/April seems too soon to me 04:29 Zeno` yeah 04:30 paramat some reasons: 04:31 paramat preparing for release takes a month and is very busy, exhausting and stressful, more frequent releases means a higher proportion of dev time is busy, exhausting, stressful 04:32 thePalindrome Very much so 04:33 thePalindrome I personally enjoy the "git", or "nightly" versionining 04:33 Zeno` we're already nearly in march 04:33 thePalindrome Where if you *really* want to, there is a pseudo-version to serve as a static commit 04:34 paramat after a release devs are exhausted and need / deserve a month of holiday / relaxing / taking it easy, maybe some take a break. then we need to feel next release is a decent enough time away to not start worrying about it 04:36 paramat so, 1 month relax, 1 month release preparation takes 2 months out of the cycle, there needs to be a decent time between to think, discuss, code, review, bugfix big new features 04:36 paramat i would say 4 months minimum 04:37 paramat so i would see 6 month cycle about right as a minimum 04:37 Zeno` 6 is better :( 04:37 Zeno` 4 months we have no time to properly debug the more complex PRs 04:37 paramat yeah 04:37 Zeno` i.e. give server ops a chance to field test them 04:41 paramat software that updates too often is annoying anyway, feature creep, updating mods etc. 04:44 paramat er well i mean MT specifically 04:46 sofar the only way to make releases less work is to do them more often (not less often) 04:46 sofar automate the shit out of it 04:46 sofar this is how we do two full distro releases of clearlinux every day at my work 04:49 paramat our releases need to be stable and bugtested, peopple can always use dev for daily versions (and do) 04:49 paramat (people) 04:52 sofar automating all the mechanical parts should be done though 04:53 paramat yeah 06:59 nore #5143 06:59 ShadowBot https://github.com/minetest/minetest/issues/5143 -- Fix anticheat resetting client position after the client is teleported. by Ekdohibs 07:18 nrzkt merging #5141 07:18 ShadowBot https://github.com/minetest/minetest/issues/5141 -- Use fabs() instead of abs() by juhdanad 07:24 nore nrzkt: hm, are newlines before & after functions even in headers, and even if there are no newlines between functions for the rest of the class? 07:25 nore (I can add them of course) 07:25 nrzkt when function has only 1 line it's not necessary, but when you inline it in three line it's desirable 07:26 nore ok, should I also add newlines between the other functions of the class? 07:31 nrzkt no 07:31 nrzkt not your pr 07:31 nore well, anyway, this is the second commit 07:31 nore decide what you like best, I'll do it 07:47 nrzkt it's good n,oer :) 07:47 nrzkt nore, 07:51 nore hmm, travis build is still unreliably failing 07:52 nore looks like the network has problems 12:37 red-001 I think I just found a great way to test how minetest responds to a bad connection https://jagt.github.io/clumsy/ 12:39 red-001 tamper seems to be the only one that crashes mt 12:50 paramat please can anyone review / approve #5109 ? simple and well tested 12:50 ShadowBot https://github.com/minetest/minetest/issues/5109 -- OpenAL sound: Use a simpler distance model by paramat 13:15 red-001 is player breath fully serversided now? 13:16 sfan5 yes 13:17 red-001 I suppose that means it can be marked as such in #2370 ? 13:17 ShadowBot https://github.com/minetest/minetest/issues/2370 -- [roadmap] Minetest 0.5.0 objectives 13:17 nrzkt red-001: the cheat is fixed, for health it's a little bit more difficult, in the health PR i solved everything except collision which is a little bit more anoying (falling damages) 13:56 red-001 so for when is next release planned for? 13:57 nrzkt we didn't found a solution, i will open an issue to permit to solve that, invoking all active coredevs 13:59 juhdanad Why should the next release be soon? 13:59 nrzkt not soon, but less far than previous interval (9 months) 13:59 nrzkt 4-5 months can be quite good 13:59 nrzkt we have sufficient things in this release to permit a shorter cycle 14:11 paramat see http://irc.minetest.net/minetest-dev/2017-01-30#i_4799743 for why a short cycle is not good. 6 months seems ok, that would be midsummer / midwinter (solstice) 14:12 paramat devs don't want to think about release yet, we're still recovering from the last one :] 14:16 VanessaE 6 months between releases is too long 14:25 red-001 #5078 anyone? 14:25 ShadowBot https://github.com/minetest/minetest/issues/5078 -- Remove guest nicknames by red-001 14:26 red-001 if it's not going to be merged then generating guest nicks should be fixed 14:26 red-001 it's not ok that users have no idea why the server is kicking them 14:27 VanessaE remove guest nicks. period. 14:29 nrzkt paramat: #5145 14:29 ShadowBot https://github.com/minetest/minetest/issues/5145 -- Scheduling 0.4.16 14:29 nrzkt VanessaE: maybe but as paramat said, freeze needs some energy, because we don't have too many hands, else we should have a devel branch + master 14:30 nrzkt nore, Zeno`, sfan5: ^ 14:31 nrzkt sofar, ShadowNinja: ^ 14:31 VanessaE my point is to skip the freeze and so on 14:31 nrzkt no 14:31 VanessaE if sfan5 can make a dev build in 10 mins or whatever, you can make a release without all the mishegas 14:31 VanessaE no one said it has to be a "full" release. 14:31 VanessaE just a snapshot 14:31 nrzkt for a snapshot release take travis artifacts 14:31 red-001 yeah nicknames are hardly a confusing part of minetest, if anything the way to enable mods is more confusing 14:32 VanessaE nrzkt: the point is, you guys have to declare it "official" and be ready to make another snapshot if something's badly broken 14:33 nrzkt official = responsibility on snapshot, whereas a snapshot is a alpha or beta release 14:34 VanessaE no 14:34 paramat releases have to be bugtested and high quality, people can use any commit of 0.4.15dev already if they want, that's no different to a snapshot release 14:34 VanessaE "official" in this case just means "don't consider it an unofficial dev release made by some J. Random Forum User" :) 14:34 VanessaE see where I'm going with that? 14:34 nrzkt VanessaE: hopefuly there are some forkers which sells our product on android fo rthis :p 14:35 VanessaE heh 14:39 paramat it's simple, i declare today's commit official! now just compile it and use it. what you're asking for is what people already do when they use 0.4.15dev 14:39 VanessaE nono 14:40 VanessaE now YOU just compile it and make a link to it on the main website :) 14:40 nrzkt VanessaE: no 14:40 VanessaE call it "latest official development build" or something 14:40 nrzkt no, we don't have time to maintain that 14:40 VanessaE no one says it has to supersede 0.3.15 14:40 VanessaE maintain what? 14:40 VanessaE it takes like 5 minutes 14:40 nrzkt no 14:40 VanessaE I'm talking no maintenance 14:41 nrzkt 10 min compilation per platform + upload + publication ~ 2h 14:41 VanessaE snapshot, compile, link, tell users "use at your own risk" or something 14:41 paramat do we really need an issue for this? it's a bit early, i'm still exhausted from the last release 14:41 VanessaE ok fine, 10 per platform AUTOMATED 14:41 VanessaE jeez 14:41 nrzkt VanessaE, celeron55: give rights to VanessaE (joke) 14:41 VanessaE no. :P 14:41 VanessaE I don't do windows 14:42 paramat just use the daily builds made by trusted devs 14:42 red-001 couldn't travis be made upload the builds it makes? 14:42 nrzkt red-001: i hope it can build artifacts like gitlab 14:43 VanessaE in the time we spent discussing this, it could have already been done :) 14:43 red-001 that or someone could setup some sort of autobuild 14:45 red-001 https://docs.travis-ci.com/user/deployment/releases/ 14:46 paramat this makes no sense, just use a daily build, what you ask for is already done and available 14:47 VanessaE if I were concerned for myself I'd just build it and be done with it, but I'm talking about my users here. 14:47 VanessaE (and indeed I already do that) 14:47 VanessaE but you can't expect Windows users to reach for daily builds. the best option for them is a snapshot made when the engine seems stable enough to do so 14:47 red-001 looks like this is easy to do: https://docs.travis-ci.com/user/deployment/ 14:47 VanessaE (which is thankfully 99% of the time) 14:48 red-001 just have daily build 14:48 red-001 and make them public 14:48 red-001 of course still have releases 14:49 VanessaE make them public and make them *sanctioned by the core devs* 14:49 VanessaE the whole point is that a user should not look at one of these builds and think "ok this is some lame user-produced dev build that will probably break my machine" 14:50 VanessaE but rather "this build is newer than 0.4.xx and is probably safe to use" 14:51 Warr1024 it would also be nice to have an established standard for how often those nightlies are made (i.e. nightly, at least) 14:52 red-001 could we have a vote on #5078? 14:52 ShadowBot https://github.com/minetest/minetest/issues/5078 -- Remove guest nicknames by red-001 14:52 VanessaE I don't advocate nightlies, just "seems stable enough to let users get feature X" 14:53 Warr1024 I don't advocate nightlies, either; I'd rather just produce a build any time there's (1) a new commit, and (2) a build server not otherwise occupied. 14:54 Warr1024 if features aren't stable enough to try out, then they probably shouldn't be committed into the mainline. 14:54 VanessaE that much is true 14:54 VanessaE (and usually is the case) 14:56 nrzkt your users doesn't need snapshots. It's for experienced users. 14:57 nrzkt do you use firefox nightly build and linux kernel RC 1 ? 14:57 VanessaE I do not, but then again how often is firefox or chrome updated? every few weeks or so 14:57 Warr1024 if it took 6 months for firefox to cut a new release, I probably would. 14:58 VanessaE firefox/chrome is a terrible comparison if you're trying to avoid the idea of rapid releases :) 14:58 red-001 I use firefox dev 14:58 Warr1024 6 months is probably the upper bound for a release cycle, and Firefox has complexity about on par with an operating system, so they might be okay at that point. 15:00 Warr1024 If making a release is such a painful process, then maybe the solution isn't so much making fewer releases as it is trying to fix the release process. 15:01 VanessaE exactly. 15:01 VanessaE making a release ought not take more effort than "make-release.sh" :P 15:01 VanessaE (ok aside from the feature freeze and bug fixes that go in during that time, but that's not any more work than at any other time is it?) 15:01 nrzkt in fact VanessaE it's not our problem if you use hardware node coloring and users doesn't have a compatible client 15:02 VanessaE nrzkt: it's the users' problem if they won't update. 15:02 nrzkt you break your user's experience, it's your problem as you are admin of your servers 15:02 VanessaE but it's you guys' problem for making it *difficult to update* 15:02 nrzkt this feature is not released, it's your problem 15:02 Warr1024 it's not like (1) you have to freeze the whole tree to do testing (that's what branches are for), or that (2) development code is really untested. 15:03 nrzkt it's in the current master branch, but client release is our responsibility and we don't trigger a release, then you are aware that the users cannot see it. We will not release it just because you make it available before the software was released officially 15:04 nrzkt servers owners are responsible of their server part and user's experience, they know the client is not released, and they know without client release some features should wait a little bit 15:06 paramat MT dev is never 'stable enough' during dev, it's either a full bugtested release or an unstable dev version, there's no inbetween state and any effort to obtain an inbetween state disrupts dev. i can understand players and server admin being impatient but that's too bad, either wait or use a daily build from someone you trust 15:07 Warr1024 what is a "full bugtested" release? 15:07 nrzkt in fact paramat it's just a full reviewed branch, not full tested as unit tests doesn't and can't currently cover 100% of our code 15:07 Warr1024 do you have some kind of exhaustive test process you run before an official release? 15:07 VanessaE well I give up. 15:08 juhdanad Warr1024: before a release is out, there is one month of bugfixes. 15:08 nrzkt feature freeze is the release candidat, this is the version experienced end users can use to help us to track bugs 15:08 Warr1024 holy shit, that's a lot of bugs. 15:09 paramat the release process could have more automation yes, but the stress and hard work of preparation and bugfixing is unavoidable. if you're not a core dev you do not know what it's like 15:09 nrzkt Warr1024: one month of possible bugfixes 15:09 Warr1024 what do you do with that month if you're lean on bugs? 15:11 paramat well freeze is usually 2 weeks 15:12 paramat but before that we have to sort out our priorities, work like crazy to get the features ready 15:14 paramat so you have to start working towards the freeze point around a month before it 15:43 celeron55 the only way to achieve "in-between" releases is if non-developers start releasing them just based on some git versions 15:43 red-001 huh minetest particles are a lot more complicated then I though 15:43 VanessaE celeron55: which is already the case. 15:43 VanessaE sfan5 makes frequent builds, but users don't see them as official enough to be worth the "risk". 15:43 celeron55 the problem with that is that it's still not possible to have eg. proper dev-to-dev protocol compatibility 15:44 celeron55 because doing it would just destroy the possibility to even develop stuff 15:44 celeron55 so they inherently have the possibility of being broken 15:46 celeron55 the way i would look at this is that the current half-a-year release cycle is probably the fastest that developers are comfortable with using current tools 15:46 celeron55 if somebody wants a faster cycle, then make tools that make developers comfortable with such 15:46 celeron55 eg. tools that make bugs appear faster 15:47 celeron55 tools that allow measuring performance 15:47 celeron55 stuff like that 15:47 celeron55 tools that allow testing protocol, map and mod compatibility 15:48 sfan5 proper dev-to-dev protocol compatibility is certainly possible 15:48 sfan5 however it makes development much more cumbersome 15:49 celeron55 in practice it's not 16:23 STHGOM noob question: #define CLIENT_PROTOCOL_VERSION_MIN 27 <--- is the # a comment? 16:24 STHGOM oop 16:25 VanessaE no, it's a C++ command 16:25 VanessaE (well some other languages also) 16:25 STHGOM ok, thanks 16:26 paramat i'd like to merge #5045 #5138 #5143 in a moment. nore is 5143 ready to go? 16:26 ShadowBot https://github.com/minetest/minetest/issues/5045 -- Add "multiply" texture modifier which uses multiplication method for colorizing textures by sapier 16:26 ShadowBot https://github.com/minetest/minetest/issues/5138 -- Plantlike visual scale: Send sqrt(visual_scale) to old clients by paramat 16:26 ShadowBot https://github.com/minetest/minetest/issues/5143 -- Fix anticheat resetting client position after the client is teleported. by Ekdohibs 16:27 paramat just wondering if 5143 should have a little more time 16:27 paramat yeah i'll merge the first 2 16:41 paramat now merging the first 2 16:49 paramat merged 17:03 juhdanad >proper dev-to-dev protocol compatibility is certainly possible< Do you mean that dev-to-dev compatibility is not necessary? 17:05 sfan5 it's good practice not to break dev-to-dev compat completely 17:05 sfan5 however there is no rule to enforce compat 17:17 sofar paramat: 5143 is :+1: from me 17:22 red-001 could a issue be opened with a list of things that should be added for CSM? 17:23 red-001 and make it a milestone or something 17:23 paramat ok 17:58 red-001 is using default arguments allowed by the code style guidelines/ oldest c++ standard supported? 17:58 nrzkt you mean in cpp class definition ? 17:59 sfan5 i'm pretty sure default args are supported in c++ since practically always 17:59 red-001 so it's ok to use them? 18:00 nrzkt red-001, you mean void toto(int a = 3) ? 18:00 red-001 yeah 18:00 nrzkt no problem to use it it's already done 18:01 red-001 oh ok I just noticed it seemed to be used quite rarely in the code 18:02 nrzkt because it's rearely needed in fact 18:10 sfan5 ^ 18:26 paramat #5148 18:26 ShadowBot https://github.com/minetest/minetest/issues/5148 -- Mgvalleys: Fix missing decorations at horizontal chunk borders by paramat 19:45 red-001 #5149 19:45 ShadowBot https://github.com/minetest/minetest/issues/5149 -- [CSM] Add `get_node` and `get_node_or_nil` by red-001 19:47 nrzkt red-001, you are so fast 19:47 nrzkt i'm working on mod storage 19:48 juhdanad The development has been faster since the CSM branch opened. 19:49 nrzkt CSM only red-001 and me are working on it fully, and mainly it's porting server side code to client 19:51 red-001 well we are starting to run out of easy to port stuff 19:55 juhdanad Then comes the good part! (solving exciting programming problems) 19:57 red-001 well if you have time you are welcome to make a PR to the CSM branch 19:58 red-001 it would be good to get more people working on it 19:59 red-001 nrzkt, maybe there should be a general todo list for csm? 19:59 juhdanad I don't really like Lua (I don't know the types...) 19:59 nrzkt red-001, it's in 5088 19:59 nrzkt it seems your follow it, i suspect :) 19:59 red-001 isn't that just for merging the PR? 19:59 nrzkt juhdanad, i prefer C++ too but it's required 20:00 red-001 there seems to be quite a bit thats not there 20:00 nrzkt red-001, yeah, but it's the first PR roadmap, after merge we should add another branch maybe to continue working 20:00 nrzkt and it's the main discussion process, if many users talk onto it to add new ideas i can add a future list 20:00 nrzkt having all information on it can be more useful than multiple PR non updated 20:01 red-001 ohh so csm is going to be developed parallel to master? 20:01 nrzkt atm yes, 0.4.16 should be released without it as it seems 20:05 nrzkt i have the first pass for modstorage 20:05 red-001 nice 20:06 red-001 nrzkt, released without the server side of csm or all of it? 20:07 nrzkt i'm doing it full server side 20:07 nrzkt it works perfect, it just needs a proper persistent storage now 20:22 nrzkt update #5131, now we have private mod storages 20:22 ShadowBot https://github.com/minetest/minetest/issues/5131 -- Add ModStorage Lua API by nerzhul 20:22 nrzkt only persistence is missing 20:46 sofar since it's key-value based, are you going to do a json type thing like player attributes? 20:46 sofar the problem I see is with mods putting in binary data 20:47 Fixer don't forget that problem regarding keys/other labeling 20:47 sofar you'd end up using e.g. dbm/gdbm 20:48 sofar what problem? 20:49 sofar Fixer: oh, itemstack meta 20:49 Fixer yes 20:49 sofar Fixer: that's entirely unrelated 20:49 Fixer ok 21:00 red-001 nrzkt, could you add global storage? 21:14 sofar for mods? why would you? 21:24 sofar nrzkt: red-001: thinking aloud about that problem 21:24 sofar I don't think you want to 21:24 sofar if mods expose an API to modify their local storage, then great, let other mods have access to it 21:25 sofar but I like to write my mods in a way that when I do want other mods to access certain functions, I clearly only give access out to those parts 21:25 sofar e.g. I'll keep most of my data `local` 21:28 red-001 i was thinking of a separate global storage 21:29 red-001 so there is mod storage for every mod and one global storage for every world 21:31 sofar I fail to see, outside of mods, who would use that 21:49 nrzkt i agree with sofar 21:57 red-001 well I suppose you are right there isn't that much use for it 21:58 sofar well my point is that -per definition- there are no uses for it 21:58 sofar everything is a mod 21:58 sofar there are no users outside of mods 21:58 sofar the only reason to consider it would be to have some 'shared' storage 21:58 sofar but tbh, I don't think that is a good idea 21:59 sofar let me rephrase: that's a terrible idea :) 22:01 nrzkt sofar, i don't think so, i think mods should expose an API to use their internal storage if needed 22:01 sofar exactly my point 22:01 nrzkt sofar, are you okay with API exposed by #5131 ? 22:02 ShadowBot https://github.com/minetest/minetest/issues/5131 -- Add ModStorage Lua API by nerzhul 22:02 sofar actually, can I comment? 22:03 sofar so if mod A calls an API function in mod B 22:03 sofar and B uses minetest.store_data() in that call 22:03 nrzkt refresh the PR 22:03 nrzkt store_data doesn't exist anymor 22:03 sofar ahhh 22:04 nrzkt now mods should call at loading time minetest.get_mod_storage() to get their private storage 22:04 nrzkt and after: storage:set(k,v) and storage:get(k) 22:04 sofar oh, you didn't squash 22:04 sofar yes! that's what I expected to see 22:04 nrzkt no, you are right, as i rewrote everything i should do it 22:06 nrzkt it's now squashed, not problem 22:06 nrzkt sofar, how do we store values ? a file per mod in a specific folder specified by configuration ? 22:07 sofar well 22:07 sofar there's only ever 1 store per mod, right? 22:07 nrzkt yes 22:07 sofar so I would do a mod_storage folder 22:07 sofar and then underneath there 1 file per mod 22:08 nrzkt in world_dir for server side then 22:08 sofar correct 22:08 nrzkt perfect 22:08 sofar what about the format of the store? 22:08 sofar json? can that handle arbitrary data values? 22:08 nrzkt yes, like we do with player:set_attribute: ) 22:09 sofar if that is safe for binary data then I'm OK 22:09 sofar does it handle arrays and hashes properly? 22:09 sofar can I insert nested tables? 22:09 nrzkt as it seems there is no problem 22:10 nrzkt as all my tests in player:set_attribute permit to set every type into string and next json 22:10 nrzkt json with a single k,v level, we don't need to rewrite all as a pure json, it's useless, right ? 22:12 sofar can I set a value to mintest.write_json({x = 1, y = { a = 3, b = 4}}) 22:12 nrzkt you can to use write_json serializer to convert lua to json ? 22:12 sofar or, can I set a value to {x = 1, y = { a = 3, b = 4}} ? 22:13 sofar e.g. pass a table as value? 22:13 sofar it's ok if I have to serialize it first 22:13 sofar just should be documented 22:13 nrzkt with player extra attributes it's possible, the object is converted as a string and the string is back converted to object by lua it's implicit 22:14 nrzkt i think this can be used there, and also we should be careful about this serialization t oavoid performance penalty 22:15 sofar yes, if we avoid internal serialization it's better 22:15 sofar let the mods handle dangerous data themselves first 22:16 nrzkt yes 22:24 sofar this way, one day we'll get modifyable labels on itemstacks, too ;) 22:41 nore ah, about #5143: I'm nit sure whether I should add some code as well to prevent incorrect on_cheat being reported because the client had lag, what do you think? 22:41 ShadowBot https://github.com/minetest/minetest/issues/5143 -- Fix anticheat resetting client position after the client is teleported. by Ekdohibs 22:42 red-001 I would say so as mods might use on_cheat to punish players