Time Nick Message 05:09 sofar bug related question 05:09 sofar does class GUIFormSpecMenu know or have a member to indicate that it is being executed in a MAINMENU context or in a GAME/CLIENT context? 05:10 sofar #5593 05:10 ShadowBot https://github.com/minetest/minetest/issues/5593 -- Game exits when [tab] key pressed in server login page at [user] field 05:10 sofar can fix this bug if I can somehow determine `if (in_mainmenu)` 05:11 sofar m_client == NULL? 05:14 sofar ahhh yes, that actually works 05:16 sofar yay, fixed my own weird bug 05:40 rdococ hello 05:40 rdococ I'm here. You should go and hide. 07:25 nerzhul merging #4981 07:25 ShadowBot https://github.com/minetest/minetest/issues/4981 -- Partial damage cheat fix: node damages server side by nerzhul 10:16 Krock nerzhul, what about https://github.com/minetest/minetest/pull/5493#discussion_r111555540 ? 10:17 nerzhul Krock, yeah, sorry i forget to answer 10:18 nerzhul on first test when i'm doing this overwrite on m_bgcolor there was a problem, i need to re-test since last changes 10:56 celeron55 Fixer: try this https://github.com/celeron55/minetest/tree/mesh_update_block_cache 11:01 celeron55 or wait for a moment, i'm fixing a thing 11:03 celeron55 ok now 11:17 Fixer celeron55: will try but little later @ dinner 11:17 Krock ^ throws a weird MSVC error about converting "const v3s16" to "size_t" is not possible with "CachedMapBlockData *" 11:18 Krock will look into this one deeper 11:18 celeron55 wut? 11:18 celeron55 well i suppose it tells you a line number 11:20 Krock I suppose it's something with the cpp11 containers: https://pastebin.com/raw/GBub9E1x 11:21 Krock actually thrown in mesh_generator_thread.cpp 11:25 Krock looks like it can't generate a hash from v3s16 as map key o.0 11:30 nerzhul yes 11:30 nerzhul std::unordered_map doesn't support v2xxx and v3xxx as they are not hashable containers celeron55 11:31 Krock fixed by replacing with std::map 11:35 celeron55 oh, oops; switching to std::map 11:37 Krock but it works.. so far 11:43 celeron55 it's a performance improvement; what you should be looking for is the almost complete disappearance of stutter from adding tasks to the mesh generator 11:44 Krock yes, I'm testing it right now 11:44 celeron55 there are other kinds of stutter, i don't know if people have learned to notice that exact kind of stutter :P 11:44 celeron55 this is a reasonable test config to make it more apparent: 11:44 celeron55 max_simultaneous_block_sends_server_total = 100 11:44 celeron55 max_simultaneous_block_sends_per_client = 100 11:44 celeron55 mesh_generation_interval = 0 11:45 celeron55 (on a high end system) 11:46 celeron55 also if someone makes a windows build, throw that to me, i can test on my media pc that doesn't have a compiler or anything 11:46 Krock okay, will upload 11:50 Krock https://www.dropbox.com/s/bpwfpqwohdnn79o/minetest_170415_1c851e0_mesh_update_block_cache.7z 11:51 Krock 32-bit and std::map patched manually, so it's the most recent version 11:59 Krock ah, increasing the minimal view range helps. 12:02 celeron55 anything that causes more stuff to be copied to the mesh generator will exaggerate the difference 12:05 celeron55 which is, anything that causes the server to send more mapblocks 12:06 celeron55 it can be masked by mapblocks that have heavy use of node metadata though as it's able to cause a different stutter that can be much higher than the copying-mapblocks-for-meshgen one 12:08 Krock http://i.imgur.com/X51IW7M.png local world 12:09 Krock but there weren't so many processed blocks in the new one. will have to do more testse 12:09 Krock *tests 12:12 Krock but overall feels smoother now 12:33 Krock Pushing this fix in 15 minutes: https://pastebin.com/raw/qN2A6ZE5 13:04 Fixer celeron55: i'm back, will look now 13:09 Fixer celeron55: don't see much difference, default config, spawned near jungle, stuttered like crazy https://i.imgur.com/QgP4bSx.png (tested without std::map commit) 13:11 Fixer will try std::map version 13:16 celeron55 it doesn't look like what i would expect, are you sure you built the right version? 13:24 Fixer celeron55: is not krock's screenshot also suggests there is tons of stutter anyway 13:24 Krock right, there's also sometimes no sleep time for the main thread 13:26 Krock but what counts is the speed of copying the map data 13:34 Fixer tried krock's build, right away in forests observed very visible shitty stuttering https://i.imgur.com/p2Z26RI.png 13:34 celeron55 Fixer: actually, looks like in that screenshot basically all of the block receive related stutter is gone, not counting the single big spike 13:35 celeron55 that shows the same thing 13:36 celeron55 there's both _other and _draw stutter left that isn't related to the toclient_blockdata handler 13:36 celeron55 what CPU and GPU does this system have? 13:37 Fixer core i3 2120 3.3ghz + 8gb ram + amd hd6870 1gb vram 13:38 Fixer 0.095 ms mainloop_dtime... karl 13:38 Fixer mainloop_draw* 13:38 Fixer i have no idea how it helps since game stutters like crazy anyway 13:38 Fixer default config 13:39 Fixer 0.095 sec* 13:39 celeron55 basically the same cpu as my media pc then (this has 2100) 13:42 celeron55 yeah, i can see the stutter i set out to get rid of is gone 13:42 celeron55 and that there are at least 2 other stutters left 13:53 celeron55 the stutters left in mainloop_other don't correlate with anything that's currently graphed, the stutters left in mainloop_draw seem to partly correlate with # processed meshes and partly not with anything that is currently graphed 14:51 celeron55 https://github.com/minetest/minetest/pull/5595 15:12 Krock poor travis got a lot to do right now :/ 15:22 paramat Zeno` are you +1 for #5519 ? i moved the temporary old move code to the end of the file to make things cleaner 15:22 kilbith why the dominant male ain't allowed to push straight ahead if he wants to 15:22 ShadowBot https://github.com/minetest/minetest/issues/5519 -- Sneak: Add option for old move code by paramat 15:22 celeron55 kilbith: why would i want to; these nice people will catch my errors so i don't need to 15:22 celeron55 lol 15:23 kilbith I remember hmmmm enforcing the rules on you 15:24 kilbith you need some praetorian guards to defend your rights of dictator IMO 15:25 Krock we'd get nowhere if our dictator could do what he wants :P 15:25 celeron55 well someone would try enforcing them for sure, and if i made any errors it'd be kind of bad 15:25 nerzhul lol the dictator era is finished in minetest (not on earth, we have three WW3 competitors) 15:31 Krock duh, if the order of including our header files matter, then something's going wrong with the structure 15:31 celeron55 yeah i added an initial commit that adds the include into util/thread.h 15:31 celeron55 util/thread.h was broken 15:34 celeron55 should be fixed now 15:38 paramat celeron55 since you are concerned about the issue, are you able to +1 #5519 ? 15:38 ShadowBot https://github.com/minetest/minetest/issues/5519 -- Sneak: Add option for old move code by paramat 15:41 paramat or maybe just a concept review 15:44 paramat nore ^ any opinion on that? 15:44 nore paramat: need to think about it 15:45 paramat ok thanks 15:46 celeron55 i think the concept is fine 15:47 celeron55 the only thing left from that in the long term is the byte added to the protocol 15:52 paramat hmm from the extra physics override 15:52 paramat i had not considered that 15:53 paramat new sneak code is going well, we now have all ladders working as before, we have 2 node sneak jump, and basic sneak behaviour only has minor issues left 15:56 celeron55 (the code is fine to me also) 15:56 celeron55 are we doing these partial reviews nowadays? 15:56 nerzhul what do you mean with partial review ? 15:57 celeron55 there's no actual rule for how to take into account something like someone saying "+1 for concept", or is there? 15:57 celeron55 i wrote about it a long time ago but i guess it ended up as a suggestion 15:57 nerzhul no rule, concept != quality 15:59 celeron55 if someone says +1 (implying everything) and then three others say "+1 for concept", "+1 for code", "tested to work fine", i guess it sums up as two full +1s 16:00 celeron55 except that then you can forget to check the protocol or something 16:00 celeron55 do we even need 2 +1s for anything else than concept 16:04 celeron55 i'd suggest 2 +1s should be required for concept and persistent data (being network protocol and disk formats), and for everything else one +1 is enough 16:05 Remy_ +1 16:05 nerzhul celeron55, you mean less +1 ? and what about coredev ? 16:06 celeron55 i mean all of those from coredevs 16:07 nerzhul it's already the case for coredevs, 16:07 nerzhul 2 +1 for external , 1 for coredev PR 16:07 paramat no concept rule is not an official thing, i was just asking your opinion on the concept (since you probably don't have time to review fully) 16:08 paramat sorry i mean 'concept approval' 16:09 paramat a +1 is only official if it is a full review: code and concept 16:10 celeron55 really the only reason i ask is because personally i like to review concepts and protocols 16:10 paramat and a core dev's approval of their own PR counts towards the 2, which helps 16:15 * Fixer .oO(minetest stone soup) 16:46 nerzhul okay guis #5475 is now ready and has bidirectional migration, like map 16:46 ShadowBot https://github.com/minetest/minetest/issues/5475 -- WIP: player data to Database by nerzhul 16:46 nerzhul guys* 16:47 nerzhul the only missing thing is a little bit more documentation on minetest wiki linked into client 17:07 nerzhul who manages wiki.minetest.net accounts ? 17:07 Calinou nerzhul: me 17:07 nerzhul Calinou, can you create me an accouhnt ? 17:08 Calinou nerzhul: sure, PM me your e-mail address and desired username 17:08 Calinou (note that username must start with an uppercase character) 17:12 nerzhul i PM you 17:50 ShadowNinja The first Minetest developer meeting is in 10 minutes. :-) nore, sofar, celeron55, sfan5, paramat: you said this time worked for you, are you available today? nerzhul, Zeno`: I didn't hear from you, please tell me if this time (18:00 UTC) works for you. All devs: please join -staff for private discussion if you have not joined already. 17:50 nore ShadowNinja: I'm there 17:51 kilbith it's 3:50 AM where Zeno` lives 17:52 * sofar yawns 17:52 sofar I thought it was 50 minutes ago 17:52 ShadowNinja kilbith: Oh, I suppose he won't be able to participate then. :-| 17:53 kilbith and can you please explain why the development discussion has to be that opaque ? 17:53 nore I just rebased two of the pulls https://github.com/Ekdohibs/minetest/tree/pull-3299 and https://github.com/Ekdohibs/minetest/tree/pull-3651 btw 17:53 nore one of these is completely untested (the build one), the other only had a quick testing though 17:54 ShadowNinja kilbith: What do you mean? The -staff part? That's mainly just for stuff like the meeting notes (they're editable to anyone with the URL). 17:55 Fixer minetest-dev feels very b-rocratic 17:55 kilbith yeah, I don't know it has to be private, there are people actually living on MT and they need to anticipate from what has been decided in upstream 17:56 nore ShadowNinja: isn't there a way to have a public url that isn't editable? 17:57 sofar brt 17:57 ShadowNinja nore: Not with the service that I'm using (AFAIK), but we could use something else. Any ideas? 18:00 ShadowNinja Good evening and welcome to the first edition of the Minetest weekly(?) developer meeting. 18:00 ShadowNinja The purpose of this meeting is to quickly reach a decision on a number of PRs at a time when enough developers are available to quickly approve/deny them. This meeting is intended to be fairly fast-paced. If we decide to merge a PR it will be assigned to someone and should be merged shortly after the meeting. If a PR warrants an extended discussion we'll delay it until after the meeting. We're going to focus on the engine for now. 18:00 ShadowNinja First order of business: #1188 I don't see any reason why this shouldn't be merged, although it does require some rebasing. Any objections to merging? If not, any volunteers to do the rebase and merge? 18:00 ShadowBot https://github.com/minetest/minetest/issues/1188 -- getTime refactoring by Selat 18:00 nore it was a good PR, so +1 for merging from me 18:00 nore I can try to rebase it 18:02 sofar careful 18:02 sofar I rewrote a bunch of gettime.h 18:02 sofar so there's conflicts for the core parts 18:03 ShadowNinja nore: Alright, great. Moving on... #3580 / #4664 (alternate implementations) Merge or close? 18:03 sofar but, yes we should merge what we can from this 18:03 ShadowBot https://github.com/minetest/minetest/issues/3580 -- Added delayed shutdown feature by pinkysnowman 18:03 ShadowBot https://github.com/minetest/minetest/issues/4664 -- Implement delayed server shutdown with cancelation by nerzhul 18:04 nore I would say concept-wise, it is an useful feature 18:05 sofar normally I'd agree that we want mods to do things where applicable, but this is still something I don't mind seeing in c++ 18:05 sofar doesn't help that hmmmm and est31 are no longer here :) 18:05 sofar and Zeno`'s alseep 18:05 nore I guess we could rebase #4664 and merge it probably 18:05 ShadowBot https://github.com/minetest/minetest/issues/4664 -- Implement delayed server shutdown with cancelation by nerzhul 18:05 nore (as it seems more complete than 3580) 18:06 sofar if nerzhul rebases I'm fine with it 18:06 paramat here 18:06 sofar but I'm looking at others more, I was already ok with it before 18:08 ShadowNinja IMO nrz's implementation is overcomplicated. The simple Lua implementation should work just about as well, right? 18:09 nore ShadowNinja: it doesn't allow cancelling 18:09 ShadowNinja nore: True, but that could be added in Lua. 18:09 nore ShadowNinja: yes, but it's not easy because it uses minetest.after 18:10 nore I mean it can be done but most of the PR would have to be rewritten 18:11 ShadowNinja Yeah, I guess I just like the simplicity of the Lua solution. But if you all prefer the C++ impl, we'll do that. 18:11 ShadowNinja It seems we're in agreement to merge at least one of them though? 18:11 nore it looks like so, yes :) 18:12 nore next item on the list then, I guess? 18:12 ShadowNinja paramat, sofar: opinions on which to use? 18:13 paramat no opinion 18:13 sofar nrz's version, since he's here to redo it 18:13 paramat are we going through old PRs oldest first? 18:13 ShadowNinja nerzhul: Will you rebase and merge your PR? 18:14 ShadowNinja paramat: Yep. 18:14 ShadowNinja (more-or-less) 18:14 celeron55 i like the C++ one more 18:15 paramat ah you're going by least recently updated, i was thinking oldest by number 18:15 celeron55 (altough, it's almost criminal how wasteful duration_to_string is about lines of code use) 18:17 ShadowNinja Alright, nerzhul's taking too long, I'll assign the PR to him for now. Next: #2085 -- Merge or close? 18:17 ShadowBot https://github.com/minetest/minetest/issues/2085 -- Disable font scaling on non-Android platforms by cheapie 18:18 nore is it still relevant or not? 18:18 nore I mean, is font scaling still there? 18:19 ShadowNinja I'm not sure. 18:21 ShadowNinja The PR is old and it seems font-scaling is working nore-or-less fine now, so I vote close. Does that sound good? 18:22 nore hmmm, with quick testing (xrandr --scale 0.5x0.5, where I get text ~2 bigger), it looks like there's no problem 18:22 nore so I would say close as well 18:22 celeron55 i don't think making formspec behave differently on different devices is going to make anything better to anyone 18:22 paramat i'm fine with close 18:23 nore (interestingly, with --scale 2x2 I get text twice smaller, but some elements don't scale... well) 18:23 celeron55 it would be nice to add a proper reference to this log in the closing messages 18:24 ShadowNinja Alright, done. #3651: Seems ready to merge, just needs someone to rebase(trivial) and merge. Any volunteers? 18:24 ShadowBot https://github.com/minetest/minetest/issues/3651 -- Disable android leveldb by default by MoNTE48 18:24 celeron55 otherwise nobody will remember even after a few days 18:24 nore already rebased it, but untested 18:24 nore https://github.com/Ekdohibs/minetest/tree/pull-3651 18:24 ShadowNinja celeron55: I'll add it in. 18:25 nore I can't test however, but this is a rebased version of it 18:25 ShadowNinja nore: Well, since you've rebased it I think in makes sense for you to test/merge it. Is that fine? 18:25 paramat could you open a new PR then? so we can close this one? 18:26 nore ShadowNinja: as I said, this is android build and I can't test it 18:26 celeron55 i would trust MoNTE48's choices on android 18:26 nerzhul oh it's now ? :) 18:26 nore that's why it is completely untested 18:26 nerzhul sorry for to be late then 18:27 paramat others can test the new PR 18:27 sofar Wayward_One ? 18:27 nerzhul yes i can rebase 4664 without doubt 18:28 ShadowNinja nore: O.K., uh, anyone else to test it? (if not, I'd just say go for it) 18:29 nore --> opened #5596 as paramat requested 18:29 ShadowBot https://github.com/minetest/minetest/issues/5596 -- Disable android leveldb by default by Ekdohibs 18:29 paramat PR opened. so close 3651? 18:29 nerzhul paramat, yes 18:30 paramat will do 18:30 paramat done 18:30 ShadowNinja Alright, nore: the Travis build will probably do. I'll leave you to merge it as soon as it's ready. 18:31 ShadowNinja Next: #1439 -- Reabse and merge or close? 18:31 ShadowBot https://github.com/minetest/minetest/issues/1439 -- Add configurable key bindings for selecting next/previous hotbar item and changing the volume by Wuzzy2 18:31 nore Didn't est31 said he could still help with android builds btw? 18:31 nerzhul travis deosn't test android build 18:31 nerzhul nore est31 left us 18:32 nore nerzhul: I know, but he said he could still help with something I seem to remember was android building 18:32 nore but anyway 18:32 nerzhul i do the android builds for release, i can test it, but not know i'm rebasing the delayed shutdown pr 18:32 nore I like 1439 18:32 ShadowNinja I'll leave nore to figure it out, I'd like to keep moving. :-) 18:33 nore it's simple enough, so I'd just say rebase & merge 18:33 nore however, paramat thought more keybindings were not needed 18:34 nore depends on what others want then 18:35 paramat 1439 i think there's a new PR that covers this? 18:36 celeron55 i think 1439 is fine, altough maybe the defaults should be nothing 18:36 ShadowNinja There are complaints that the keybindings aren't very flexible, but that's really just an issue with our input system, not this PR in particular. 18:36 celeron55 as most people probably won't use them 18:36 paramat i think there's a newer PR that allows keybindings for hotbars of any size, up to 23 18:36 celeron55 ShadowNinja: the PR is good for going to that direction 18:37 celeron55 it adds more things to bind to, which is needed anyway 18:37 celeron55 as it's useless to have a better system for binding things without anything to map inputs to :P 18:37 celeron55 any actions, i mean 18:38 ShadowNinja Alright, I support merging. I don't care whether they're enabled by default sonce they're configurable. 18:38 paramat i still don't think these are very useful, next/previous when we have number key access 18:38 celeron55 well you can always think of disabled people or something 18:39 paramat volume is not much needed in-game and can be controlled at hardware level 18:39 nore paramat: some people think they are useful, and it causes no problem to have more keys to bind 18:39 celeron55 if mouse wheel becomes freely bindable some day, then that's probably the code it's bound to 18:39 ShadowNinja paramat: Well, it doesn't work with extended hotbars (>10 hotbar elements). 18:39 ShadowNinja (it = number keys) 18:39 celeron55 (and the previous mouse wheel code is removed) 18:39 paramat there's another PR for extended hotbars 18:39 nore paramat: let's say I want to mute only minetest 18:40 ShadowNinja paramat: It's fine if there's more than one way to do it, they're just defferent input styles that different people will prefer. 18:40 paramat yeah mute could be useful 18:40 nore #4929 indeed, but the two PRs are not mutually exclusive 18:40 ShadowBot https://github.com/minetest/minetest/issues/4929 -- Make direct item selection keys freely bindable by Wuzzy2 18:41 paramat so, i'm not stringly opposed, more neutral 18:41 nore also, maybe you only want to bind 10 keys because your keyboard hasn't an infinite number of keys, so the other keys for next/previous are still useful 18:41 ShadowNinja Anyways it seems like everyone but paramat is in favor of merging, correct? Are there any volunteers to merge? 18:41 nore hmmm, I can try to rebase 18:43 paramat *strongly, not stringly :] 18:43 ShadowNinja nore: Alright. Maybe someone else can step up for the later ones... :-) 18:44 nore heh, I already rebased #3299 ;) 18:44 ShadowBot https://github.com/minetest/minetest/issues/3299 -- Added afternoon/morning red tint by kaadmy 18:44 ShadowNinja Next: #4035 -- ~~Needs rebase~~, merge or close? 18:44 ShadowBot https://github.com/minetest/minetest/issues/4035 -- Additional hooks for inventory manipulations callbacks. by Foghrye4 18:44 ShadowNinja er... 18:45 paramat 3299 strongly opposed 18:45 ShadowNinja Lets do 4035 first, it _does_ need a rebase. 18:46 paramat foghrye4 has been inactive in MT since Nov 18:47 nore 4035 is interesting, it allows to track *every* item movement 18:47 nore I don't think that's possible without it 18:47 ShadowNinja paramat: Yeah, but if someone else can fix it up we could merge it. 18:48 nore i.e. you can't even track movement of items within a player's own inventory I think? 18:48 paramat i know :] added adoption needed, didn't mean that to mean close it 18:48 nore I vote for rebasing 18:49 nerzhul please note #4664 is now rebased and mergeable, i tested it :) 18:49 paramat i meant, author not likely to rebase it 18:49 ShadowBot https://github.com/minetest/minetest/issues/4664 -- Implement delayed server shutdown with cancelation by nerzhul 18:49 nore (& merge) 18:49 celeron55 4035 is massive, i wonder if anyone has done any kind of code review 18:49 sofar it touches a lot of parts that nerzhul has modified 18:49 nore yeah, that's the problem with it 18:49 sofar hence the conflicts, perhaps nerzhul can take a look at it? 18:50 nerzhul huge callback pr 18:50 nerzhul i don't have time to rebase this PR as i already have player to db pr as a huge pr :p 18:50 nerzhul and i am finishing the chat protocol rewrite, it's nearly complete 18:51 nerzhul (for better CSM/SSM integration with chat 18:51 nore okay, maybe it can wait a bit though -> leave it open and rebase it some time later, except if someone else can rebase it? 18:51 ShadowNinja Before we rebase it, are we in agreement that the concept is good, regardless of the current implementation/code quality? 18:52 nore +1 from me 18:52 celeron55 to me, 4035 is fine in concept (but a lot of potential for bad code) 18:52 paramat 4035 seems potentially useful 18:52 nerzhul it needs some cleanups, i don't like the GameScripting interface passed to inventorylist 18:53 nore ^ yeah, same, the concept is good but I don't like that point of the current implementation 18:53 ShadowNinja Alright, I'll put it on hold for the next meeting, avaiting someone to adopt it and clean it up a bit. 18:54 nerzhul maybe we should have some singleton in core at a moment to have better code interfaces, for example a singleton for the GameScripting and CSM will permit to call callbacks without adding those things, and these are singleton by essence 18:54 nerzhul i see he prepared CSM part, it's interesting to take it, but we need more time 18:54 celeron55 no; the codebase is designed to work in a situation where you have multiple Servers for whatever weird reason 18:54 nerzhul celeron55, very strange situation :p 18:55 celeron55 but IGameDef is designed for fetching server- or client-wide singletons 18:55 celeron55 when you need something like that 18:55 nerzhul it's designed for but not used as is 18:55 celeron55 well, it can be added for that purpose to anywhere if needed, that's its purpose 18:55 nerzhul imagine: ClientScripting::get_instance()->on_use(blah); 18:55 nore I guess it could be useful for things such as server redirections or the like 18:56 ShadowNinja Let's keep moving please. Next: #3299: Already rebased by nore, merge or close? 18:56 ShadowBot https://github.com/minetest/minetest/issues/3299 -- Added afternoon/morning red tint by kaadmy 18:56 celeron55 some complex testing might want to compare two server instances or whtaever 18:56 celeron55 whatever* 18:56 nerzhul celeron55, except unittests i don't see where we can have a such thing 18:56 celeron55 it's a design decision i made and we should stick with it 18:56 nore paramat says he's strongly opposed to 3299 but didn't explain why yet 18:57 paramat explained in thread 18:58 nore hmm 18:58 paramat has issues and i feel should be in shaders 18:59 nore bottleneck of meshgen -> not at all, the bottleneck is not there but in getTileInfo 18:59 ShadowNinja It looks like it will cause color changes in an underground bunker with no natural light, 18:59 nore however yes, there's the second problem 18:59 nore maybe it should wait for the change of lightbanks meaning 18:59 paramat ok bottleneck comment not valid :] 19:00 ShadowNinja The effect is nice, but I think it needs a better implementation. 19:00 nore ShadowNinja: note the new implementation is even simpler: https://github.com/Ekdohibs/minetest/commit/aedc81bf7b3999e9f166dad69d343821fbdce173 19:00 paramat it's level of fanciness means best in shader code 19:00 nore (it's literally just modifying the function giving the sunlight color) 19:01 paramat and at least needs to be optional 19:01 ShadowNinja nore: That works the same and doesn't affect only artificially-lit areas? 19:02 nore ShadowNinja: unfortunately it does as lightbanks meaning was not changed yet 19:03 nore which is something we need to change I would say, as this would allow setting the sunlight color 19:04 ShadowNinja Alright, I'll mention in the natural/artificial light thread and close it for now. 19:05 nore ah no, it should work in most cases with artificially-lit areas 19:05 nore if it's only artificially-lit it should work 19:06 nore however if it's both artifically-lit and sunlit there won't be red tint 19:07 ShadowNinja nore: Still buggy, so my position's the same. 19:08 ShadowNinja We're done with PRs for now. sofar mentioned that he's be willing to host a mumble server if we wanted to use it for future meetings. What are your thoughts on that? 19:08 paramat even if it doesn't affect artificial light, i think it needs to be in shaders and optional 19:08 paramat eh? i was just getting into this 19:09 nore well, we need to change lightbanks meaning, but if we do so, it would be easy to set sunlight color as a texture to fetch from so it would be easy to make it optional, just change the texture 19:09 sofar we should keep it to an hour, I need to pack boxes and feed kids atm 19:09 paramat IRC is fine, why use elsewhere 19:10 nore I don't really want to use voice if possible, but I can put up with it if needed 19:10 sofar voice chat may help to keep the pace up, but, everyone should be OK with it 19:10 sofar so, irc is ok for now 19:11 celeron55 some of us (like me) aren't native english speakers; it would probably just slow things down 19:11 nerzhul except if you want to hear my french english accent i prefer IRC :p 19:11 paramat voice chat =/ pace up is the problem, writing helps with thought 19:11 celeron55 i and nerzhul would slow it to a standstill trying to say words 8) 19:11 paramat IRC has logs too 19:11 ShadowNinja Voice would probably be faster, but not everyone's comfortable with it and we have non-native speakers, so I think we should pass on that. 19:12 nore same as celeron55 & nerzhul, I have a problem of parsing what others say as well when speaking, it's easier when written :) 19:12 sofar alright then 19:12 nore hmmm maybe try to find a time for the minetest_game meeting 19:12 nerzhul can we finish the remaining points ? 19:13 sofar I have to leave 19:13 nerzhul if we don't sofar will be ate by his kids 19:13 ShadowNinja Next: C++11? It's supported by basically everything now and we already use some of its features. 19:13 nore there are less devs active for it though (sofar, paramat, sfan5 and myself I guess?) 19:13 nerzhul ShadowNinja, you forgot #5451 19:13 paramat (i wouldn't participate in voice chat anyway :] too shy) 19:13 ShadowBot https://github.com/minetest/minetest/issues/5451 -- Rename doc/*.txt to *.md. by ensonic 19:13 celeron55 to me, 3299 is fine in concept but it needs code review AND i want to take an artistic look about it as i've kind of designed the sunrise/sunset stuff 19:14 ShadowNinja nerzhul: Oh, you're right. We'll do that right after C++11. 19:14 celeron55 or, i mean, not really code review but an optimization review 19:15 nore celeron55: you can test the rebased version if you want, but anyway, maybe changing light banks meaning first would be good 19:15 nore it would fix a lot of problems as well 19:15 nerzhul for C++11 it's time to switch, compilers are a little bit late, norm was released in 2011, and GCC 4.9 and Clang 3.6 have all C++11 features which can be required by minetest 19:15 nerzhul the only problem i need to test is android build, which can be a problem 19:15 nore note that the android build scripts seem to use GCC 4.9 now anyway 19:15 nerzhul two years ago NDK didn't permit C++11 i should test with last NDK 19:16 ShadowNinja Any objections to switching to C++11? 19:16 nerzhul nore the problem is not GCC for android but NDK 19:16 nore nerzhul: oh, ok 19:16 celeron55 can we try disabling non-C++11 compilers and just seeing how many complaints we get, before actually starting to use C++11? 19:16 celeron55 like, a week 19:16 nerzhul no no, wait for release :) 19:17 nerzhul Debian 8 doesn't have C++11 compiler 19:17 nerzhul after release, Debian 9 will release (on August or September) with a C++14 compiler 19:17 nore hmmm, maybe wait until that time then 19:17 nerzhul nore, for NDK, some stdlib parts was missing on my last test in Android 19:18 nerzhul but two years ago on Android 4.1 :p 19:19 ShadowNinja O.K. I guess we'll delay it for Debian 9. 19:19 nore but I'm for switching to C++11 as soon as it is released 19:19 nerzhul everybody is okay for switching to C++11 after MT release ? 19:19 nerzhul (June) 19:19 celeron55 can we all agree debian isn't really doing any benefit to open source projects by being like that when closed source projects have been using C++11 since 2011 19:19 ShadowNinja I have to go now, so I'll let celeron55 take over. #5451 is next. 19:19 ShadowBot https://github.com/minetest/minetest/issues/5451 -- Rename doc/*.txt to *.md. by ensonic 19:20 nerzhul see you ShadowNinja :) maybe have a shortest list next time 19:20 nerzhul celeron55, nore okay for that after 0.4.16 ? 19:20 nore nerzhul: ok for me 19:21 paramat can't judge but no objection 19:21 nerzhul paramat, constexpr can benefit on your code parts in client :) 19:21 nerzhul or lambdas 19:21 celeron55 ok for me at whatever point debian 9 is released; i don't think that is set in stone 19:22 paramat 5451 next? weird order :] 19:22 nerzhul yeah #5451 19:22 ShadowBot https://github.com/minetest/minetest/issues/5451 -- Rename doc/*.txt to *.md. by ensonic 19:22 nore hmm, both are fine with me for 5451 19:22 nerzhul in CSM we started to wrote it using md, because it was new and permit to have only documentation on github 19:23 nerzhul md are easily readable on vim (with support md syntax) if needed 19:23 kilbith it's too fancy (tm) 19:23 celeron55 do we think windows users need to be able to read the README without extra software or not? 19:24 paramat hard on the eyes for me, and can't link to single lines 19:24 celeron55 the issue is, regular windows is quite handicapped with almost everything 19:24 nerzhul windows user doesn't use console, in notepad++ it's supported too, and in some IDE too (like clion and VS with a plugin) 19:24 celeron55 yeah i mean we have users that aren't developers, have you noticed 19:25 nerzhul will a non developper read a lua developper API ? 19:25 paramat client lua api should have been .txt for consistency 19:25 celeron55 wait, this doesn't touch README 19:25 celeron55 it's ok to me then, lol 19:27 paramat the MD formatting of he docs needs improving 19:27 paramat *the 19:27 nore hmmm, I must go now, but I don't think there's anything left to discuss anyway 19:28 nerzhul seems we don't have any consensus :) 19:28 nore (I meant except that and I'm neutral on it :p) 19:29 Calinou celeron55: I don't think our userbase is even knowledgeable enough to open a README :/ 19:29 Calinou I don't think they need to read it anyway 19:29 paramat Krock has issues with it too 19:29 Calinou it's mostly information about compiling 19:31 celeron55 maybe there should be a second readme that would be used in compiled windows packages 19:33 celeron55 so does anyone actually object 5451? 19:37 nerzhul not really in both cases 19:39 celeron55 we're leaving it hanging around collecting better ideas then i guess 19:39 nerzhul yes 19:39 Calinou most people don't read READMEs anyway (except really curious people like me :P) 19:40 nerzhul for the last point, clang-format just delay it on next meeting when more users will be present 19:40 Calinou if we have official Windows installers ready for prime-time, we can show an information window, this is very easy to do 19:40 Calinou (why do we still lack installers? .zip for Windows should be the secondary installation option for portable uses, definitely not the primary one) 19:40 Calinou like… most software today 19:41 nerzhul celeron55, can you review #4664 i rebased it :) 19:41 ShadowBot https://github.com/minetest/minetest/issues/4664 -- Implement delayed server shutdown with cancelation by nerzhul 19:41 nerzhul (and tested it) 19:45 celeron55 do we translate any server chat messages? 19:45 nerzhul it depends 19:45 nerzhul with the chat protocol i'm designing it can be possible more easily 19:45 nerzhul as we have a proper distinct between chat, announces, system messages and raw messages 19:46 nerzhul then announce and system can be catched by gettext to be translated :) 19:46 celeron55 but currently? 19:46 nerzhul no 19:46 paramat i object 5451 i thought that's obvious 19:46 nerzhul the only server message which are translated are standard denied messages (not custom) 19:46 celeron55 paramat: yeah i forgot to acknowledge that 19:47 paramat :] 19:47 paramat Krock too :] 19:49 nerzhul i updated http://wiki.minetest.net/Database_backends with postgresql, 1 year after merging not too late :p 19:50 Calinou (updated page, added a missing "s") 19:53 celeron55 nerzhul: does /shutdown -1 cancel a shutdown? 19:54 celeron55 it doesn't really handle that very well; i think it says " shuts down server" and cancels the shutdown 8) 19:54 celeron55 and is not documented in params 19:55 celeron55 wait, no, it says nothing 19:55 celeron55 should be in params as it's a useful feature 20:04 paramat Krock nerzhul any opinions/objectons (not necessarily reviews) for #5519 ? i'm considering merging it later 20:04 ShadowBot https://github.com/minetest/minetest/issues/5519 -- Sneak: Add option for old move code by paramat 20:04 Krock looks like I've missed quite much here. However, I'm neutral on that pull 20:05 paramat ok 20:07 Krock nerzhul, can't believe that postgres wasn't added yet. What do you think about replacing http://dev.minetest.net/CMake_Options with a README link? That page is potentially quite outdated 20:07 Krock and a duplicated documentation too 20:32 nerzhul Krock, as we maintain readme seems lgtm to replace it with link yes 20:32 nerzhul paramat, sorry i'm not sneak aware :( 20:32 paramat no problem 20:33 nerzhul celeron55, sorry for to be late, yes negative value cancel it, i'm adding documentaiton 20:33 nerzhul and the server announce cancel is shutdown :) 20:34 paramat i'll merge 5519 later if no objections 20:38 nerzhul paramat, please factorize a little code with existing code 20:40 nerzhul celeron55, thanks for the review, i'm waiting for travis and will merge 20:42 paramat the duplication is intentional for various reasons 20:43 nerzhul there is no reason to duplicate code here as it's very very similar, don't do this 20:44 paramat there is 20:44 nerzhul explain with good arguments ? 20:45 paramat see thread comments 20:46 paramat also, the code will be removed at the end of 0.4.16, a separate block of code makes it easier to remove 20:46 celeron55 yeah it's explained already 20:47 paramat if it was permanent i would agree with you of course 20:47 nerzhul i don't understand, it's a temporary commit which will be removed before release ? 20:48 paramat at end of 0.4.16 20:49 paramat so at 0.5 20:51 Krock what about "readU8"? what does it return when the end of the stream is reached? (i.e. old server) 20:52 Krock looks like it's 0, which would make it to default true, which is intended 20:54 celeron55 maybe the boolean should be added as a u8 bitfield so as not to waste 7 bytes at a time for each new boolean value... 20:54 celeron55 7 bits* 20:55 Fixer Calinou: portable option is essential too, since a lot of people distrast installers those days (because of crapware/adware/malware included) 20:55 Fixer zipped one i mean 20:56 celeron55 do you know what's probably the stupidest thing ever? the way the MT client unloads mapblocks and then the server just sends all of the unloaded ones again: http://i.imgur.com/ysOslwd.png 20:57 celeron55 i think the thing i'm doing next is ripping off the mapblock sending code from the farmap PR 20:57 Krock >.< 20:58 celeron55 i want my PR reviewed and merged though, i'm going to want to build these on top of each other 20:59 celeron55 nobody dared to +1 it yet 20:59 Krock same feeling on my PRs 20:59 nerzhul which PR celeron55 ? 20:59 nerzhul i also have the same feeling but we don't work on same parts :p 20:59 Krock #5595 20:59 ShadowBot https://github.com/minetest/minetest/issues/5595 -- Cache MapBlock data in the mesh generator thread for less stutter by celeron55 20:59 nerzhul i started to review it , as you see :p 21:00 nerzhul the idea is excellent i was thinking about exactly same concept when the Fixer complains appear 21:01 nerzhul celeron55, what is the cache memory usage ? i think about android build 21:03 paramat i'll test 5595 21:04 celeron55 nerzhul: it quite directly depends on the view range 21:04 celeron55 what range does android generally use? 21:05 Fixer nerzhul: it is not a silver bullet though, you can hardly see much difference since it stutters like crazy anyway %) 21:05 celeron55 at 50 the cache seems to peak at something like 8 MB 21:05 nerzhul active_block_range 1 viewing_range 25 21:06 Fixer nerzhul: it kinda fixes one stutter but elefant stutters remain 21:06 Calinou Fixer: it's essential but shouldn't be the promoted option 21:06 Calinou it's not convenient for newbies at all 21:07 celeron55 nerzhul: generally on the client the most memory hungry thing is mapblock meshes; the base mapblocks don't really use a lot of memory even if all of them were left in the cache forever 21:07 nerzhul okay 21:07 celeron55 well, 4kB each 21:08 celeron55 wait 21:08 celeron55 i mean 16kB 21:11 celeron55 being a cache it does exchange memory for lessened processing though, obviously 21:15 celeron55 my best guess for viewing_range=25 is 3 MB 21:16 celeron55 does it need to conserve memory more aggressively? 21:17 nerzhul no it seems reasonable 21:17 sofar we hundreds of mb of ram elsewhere 21:18 sofar that needs to go on a diet 21:18 sofar not this :) 21:19 nerzhul sofar, did you get some time ? :) 21:19 nerzhul #4664 merged 21:19 * sofar eats lunch, needs to run again 21:19 ShadowBot https://github.com/minetest/minetest/issues/4664 -- Implement delayed server shutdown with cancelation by nerzhul 21:19 Fixer minetest 32bit has problems staying below that limit 21:20 nerzhul sofar, when you get time i finished the player db backend, for using it you should use --migrate-players options in server 21:20 celeron55 with large ranges it can take like 50 MB 21:21 nerzhul maybe we should use sqlite3 by default on new worlds for players ? and let existing worlds migrate ? 21:24 celeron55 i just flew around with a range of 320 and got the cache to 90 MB... i think i'll do something to this, it shouldn't need _that_ much in any use 21:44 thePalindrome Think we could get #2727 for 0.4.16? (Just asking "can this be done without breaking things") 21:44 ShadowBot https://github.com/minetest/minetest/issues/2727 -- Sound pitch 21:45 nerzhul thePalindrome, i don't know, there are many things to finish and present in the milestone 21:49 thePalindrome Alrighty, I figured, just more wondering if it would break compatability 21:50 nerzhul i don't think 22:00 VanessaE celeron55: you need to tell github that your fork of minetest != the official upstream, btw 22:01 VanessaE nevermind 22:01 VanessaE the website's just being obscure. as usual. 22:14 VanessaE anyway your PR does help some. 23:11 nore #5597 23:11 ShadowBot https://github.com/minetest/minetest/issues/5597 -- getTime refactoring by Ekdohibs