Time Nick Message 02:16 Wayward_One Zeno`: yes, i still have the lag problem with singleplayer :/ 02:49 Zeno` is it real? :) 02:49 Zeno` i.e. remove the mod that shows the lag and use /status instead 02:51 Zeno` It'd be nice to get this nailed. Another question might be: how does the performance of HEAD compare to 0.4.11 at release? Or even 0.4.10 05:29 Zeno` Lucky Tesseract gets to check if his own patch works... dunno how that works 05:32 Tesseract Zeno`: I don't feel like blowing a day setting up an Android build env, so I just asked someone that already had it set up. 05:32 Zeno` That's what I meant by "not sure how that works" 05:33 Zeno` I wish I'd written down what I did to make my Android build env. Not sure if I have the energy to set it up again 05:34 Zeno` well /set font_size 10 crashes... I suppose I'd better write an issue since I can't fix it myself 05:36 Zeno` all these /set this and that, that people can do gives me a headache 05:51 Zeno` I don't suppose anyone knows why RBA added: https://github.com/minetest/minetest/blob/master/src/itemdef.cpp#L375 ?? 05:57 Zeno` It probably doesn't do anything anymore 05:58 kahrl probably because the RTT thing uses hardware lighting and the shaders don't support that 05:59 Zeno` I think he must have worked around it some other way because in map_block_mesh.cpp "enable_shaders" is cached 05:59 Zeno` and not updated if g_settings->set("enable.... is called 06:00 Zeno` The reason I bring it up is that the g_settings->get/set/set is expensive 06:01 Zeno` and I can't find where it's being used anyway (unless I'm blind) 06:01 kahrl where is it cached? 06:01 kahrl except for the per-instance m_enable_shaders 06:03 Zeno` yeah, the per instance 06:03 kahrl well, the code in itemdef.cpp creates a new instance 06:03 * Zeno` sets breakpoint 06:03 kahrl line 385 06:04 Zeno` yeah 06:04 Zeno` what is RTT? 06:04 kahrl render to texture 06:04 Zeno` ah ok 06:04 kahrl or round trip time :P 06:05 Zeno` I knew the second definition but it didn't fit with the context :P 06:06 Zeno` it might be worth adding another parameter to the MapBlockMesh::MapBlockMesh() I think 06:06 kahrl yeah, I'd like to remove the workaround as well, mostly because it's a case of using global state to fix a local problem 06:06 kahrl which is almost always bad 06:07 Zeno` yeah that's what's worried me more ... I called it "using a setting as a variable", which I guess is the same as your fancier description :) 06:07 kahrl I got it from http://blogs.msdn.com/b/oldnewthing/archive/2008/12/11/9193695.aspx :) 06:09 kahrl it should be OK in this case, since only the main thread is probably interested in the enable_shaders setting, but I'm not even sure about that 06:09 est31 as there is now a freeze branch, can you consider merging #2225 ? 06:09 ShadowBot https://github.com/minetest/minetest/issues/2225 -- Fixes for minetest.get_(all_)craft_recipe(s) by gregorycu 06:10 kahrl but yeah an additional MapBlockMesh parameter would be nicer 06:10 kahrl perhaps a flag in MeshMakeData 06:11 Zeno` I'm just wondering about the best way to approach it. I don't like adding a parameter with a default value to the default ctor 06:11 Zeno` oh it's not default dtor anyway 06:11 Zeno` heh 06:13 kahrl move m_enable_shaders from MapBlockMesh to MeshMakeData? 06:16 Zeno` hmm 06:18 Zeno` hmm, hmm, hmm 06:18 kahrl are you trying to summon a certain dev? :P 06:19 Zeno` no 06:19 Zeno` trying to think 06:19 Zeno` hahha 06:20 Zeno` his nick is the name of my thinking word which is... hmm 06:21 * VanessaE plays the Jeopardy theme for Zeno` 06:21 VanessaE good morning. 06:21 Zeno` And I am thinking becayse I'm wondering if I should take your advice or leave my current solution haha 06:21 Zeno` guten morgen 06:22 Zeno` current solution is https://gist.github.com/Zeno-/61a7ec602dc6860b57a5 (with tidying up) 06:24 kahrl with the MeshMakeData solution you can remove another unneeded g_settings->getBool 06:25 Zeno` true 06:25 Zeno` ok, that's settled then 06:31 Zeno` MeshMakeData doesn't seem to be used a lot 06:31 kahrl 3 times as far as I know: from client.cpp, itemdef.cpp, wieldmesh.cpp 06:32 Zeno` I'm not complaining :) I was expecting more 06:33 kahrl well there aren't that many reasons to make a mesh from a mapblock ;) 06:36 Zeno` sane reasoning does not always count 06:36 Zeno` so, we're good to go adding commits to master? 06:36 Zeno` and bug fixes etc to that freeze branch? 06:37 kahrl yeah 06:37 nrzkt oh yeah ! 06:37 Zeno` nice 06:38 Zeno` so I should be able to cache "enable_shaders" at a much higher level.. even better 06:39 Calinou cache ALL the things! 06:39 nrzkt cache me please :D 06:40 Zeno` Calinou, trying to. Just making some small changes to make it reality ;) 06:40 kahrl one thing I wonder about is tags 06:40 kahrl is it a problem if the 0.4.12 tag points to a commit that is in a deleted branch? 06:40 kahrl and never was in the master branch? 06:40 nrzkt commits must be both in 0.4.12 branch and master 06:41 kahrl nrzkt, but a tag can't point to two commits 06:41 nrzkt and after for the release feature freeze must be merged into stable 0.4 06:41 nrzkt no, but commit is same 06:41 kahrl we don't merge 06:41 kahrl rebase only 06:41 Zeno` I thought the branch would just stay 06:41 nrzkt look 06:41 nrzkt https://github.com/nerzhul/ocsms/commit/c3b55fbde910c1dfb88a95bb41f0e9f83dbc33cc 06:42 nrzkt https://github.com/nerzhul/ocsms/commits/stable 06:42 nrzkt master & stable 06:42 Zeno` i.e. rename the branch after it's not frozen anymore 06:42 Zeno` then there is no point to a tag... is there? 06:43 Zeno` oh 06:43 Zeno` could do it that way also 06:43 nrzkt pull feature freeze in stable-0.4 06:43 nrzkt it's not a merge 06:43 Zeno` and have tags in the "stable" branch 06:43 nrzkt it's only a copy :) 06:44 nrzkt because there is no way to have conflicts, but master must have the same commit, be careful 06:44 Zeno` anyway, I'll bbl... must do my exercise so I can sleep properly 06:45 kahrl https://github.com/nerzhul/ocsms/commit/2b0701ccc734acfa86151ae312120096356f86a1 06:45 kahrl is that not a merge? 07:55 nrzkt kahrl, yes i use it some times :) 07:55 nrzkt why using only rebase and not merge, if travis said it's good ? 07:56 nrzkt and this merge comes from PR accepted, not merge between my branches :) 07:58 JakubVanek rebase makes linear history, not sure about merge 07:59 nrzkt sure, merge let the commit at its date in history, but merge is shown at proper date 07:59 hmmmm hey guys, what are the advantages to mingw builds exactly?? 08:00 nrzkt compile for windows on unix 08:00 hmmmm huh 08:00 Calinou free compiler 08:00 Calinou no shady optimizations 08:00 * Calinou nuff said 08:00 nrzkt can #2209 and #2214 be merged into master ? They are little commits, easy to read :) 08:00 hmmmm calinou, visual studio is free 08:00 ShadowBot https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul 08:00 ShadowBot https://github.com/minetest/minetest/issues/2214 -- Performance improvement -> Craftdef.cpp: Improve loop and mathematics for CraftDefinitionShaped::check by nerzhul 08:00 Calinou it isn't 08:00 JakubVanek i586-mingw32msvc toolchain 08:00 hmmmm maybe it's not free as in freedom but neither is clang using that argument 08:00 nrzkt windows is not free 08:01 Calinou it's proprietary 08:01 hmmmm visual studio express + windows platform SDK is freeware 08:01 Calinou ;) 08:01 Calinou and we don't want your “freeware” 08:01 hmmmm i wonder if we should start trying out icc builds 08:02 Calinou nope. 08:02 Calinou just nope. 08:02 Calinou it's Intel-biased and suffers from the same problems as MSVC 08:02 Calinou no one uses ICC in the free software world, too :P 08:02 hmmmm or maybe it produces the fastest code which is something very desirable 08:02 Calinou it probably doesn't, too 08:03 Calinou try out Clang? 08:03 hmmmm clang is still immature vs. gcc in terms of performance 08:03 hmmmm if it can't beat gcc, how can it even have a chance against icc? 08:04 hmmmm when push comes to shove, people tend to not really give a crap about 'freedom' and end up using the technically best tool for the job 08:04 Calinou but you're the one shoving proprietary software on people here 08:05 hmmmm by compiling things using a certain compiler? :/ 08:05 Calinou compilers ought to be free, because nasty stuff happens otherwise 08:05 hmmmm our code is free 08:05 Calinou yes, proprietary compilers are evil and biased 08:05 Calinou it is widely known that ICC cheats at benchmarks 08:05 hmmmm maybe they should be using a free operating system if they're so worried about freedom 08:05 hmmmm i don't understand the rationale behind using mingw builds because it was built using a "free" compiler when every other aspect of their platform is nonfree 08:06 hmmmm I'm not going to do MSVC builds.. it's just added work 08:06 hmmmm err, MinGW builds 08:06 hmmmm for this time around anyway 08:06 Calinou cross-compilation is an useful upside 08:14 nrzkt hmmmm, in the future i can help minetest by do an automated task on my jenkins instance is that could help 08:16 Calinou we could have some kind of CI for daily builds, yes 08:16 Calinou post it on forum once it is set up 08:16 Calinou and dev wiki 08:17 nrzkt ofc, i'm using FreeBSD for my jenkins, then i could build for Windows & Linux (and also build .debs :) ) 08:17 hmmmm wait, i though travis-ci was fixed 08:18 hmmmm grr, seems like I can't use static libraries 08:18 hmmmm welp, need to recompile ogg/vorbis/vorbisfile AGAIN 08:19 JakubVanek ogg/vorbis/... in visual studio are hell 08:20 hmmmm haha 08:20 hmmmm no they're ok 08:20 hmmmm you want to know true hell? try compiling leveldb for windows 08:21 hmmmm so 99% of people who run minetest on windows are going to be fine with sqlite because it's likely they're not running any serious servers, but rather connecting to servers 08:21 nrzkt xD, troll spotted :p but i think you are right 08:22 JakubVanek maybe ogg in mingw; i don't know leveldb well 08:25 hmmmm weird 08:25 hmmmm out of all the libraries so far i seem to be having the most trouble with gettext 08:25 hmmmm on windows is gettext and iconv supposed to be combined into a single libintl.dll? 08:26 hmmmm i think i got this one from the official GTK website 08:40 kahrl hmmmm: I don't think so; I see both libintl.dll and libiconv.dll in older minetest msvc builds 08:41 kahrl hmmmm: CMakeLists.txt looks for a iconv dll as well 08:41 hmmmm yeah i had to download iconv separately 08:41 kahrl did you manage to build it? (and gettext) 08:42 est31 dunno what latest HEAD commit wanted to achieve, but didnt work for me 08:42 est31 lifebar still drawn too low 08:42 hmmmm I downloaded the binaries from gtk 08:42 hmmmm in any case I'm getting weird errors now 08:43 hmmmm c:\users\b\desktop\mtbuild\minetest\src\cguittfont\irrUString.h(3864) : error C2039: 'unary_function' : is not a member of 'std' 08:43 hmmmm i guess it's trying to build with C++11??? 08:44 hmmmm C++11 shouldn't be in visual C++ 2008 though 08:44 hmmmm what's going on 08:44 kahrl ah I see, they're not as horribly outdated as the official gettext msvc build 08:45 kahrl I didn't know about them when I tried to build minetest so I started making my own visual studio project :S 08:46 kahrl https://github.com/kahrl/gettext-msvc 08:46 hmmmm hrmm i don't understand this 08:46 kahrl (got bored, so ^^ is a bit incomplete, notably msgfmt is missing) 08:46 hmmmm did I not configure it right or is xCGUITTFont.cpp broken under windows? 08:47 hmmmm looking at http://support.microsoft.com/kb/243444 08:47 kahrl hmmmm: well, people have managed to compile it... 08:54 kahrl hmmmm: apparently for some people #include is needed, https://forum.minetest.net/viewtopic.php?f=7&t=7033&start=50 08:56 Zeno` kahrl, I'm preparing to merge #2119 08:56 ShadowBot https://github.com/minetest/minetest/issues/2119 -- [patch 1/4] Network rework: Rewrite client/server packet handling & packet reading by nerzhul 08:56 kahrl hmmmm: std::unary_function is not a C++11 thing, in fact it has been deprecated in C++11 08:56 nrzkt oh yeah 08:56 Zeno` it's been running on my server for 24 days and ran on VanessaE's servers until last week 08:56 hmmmm right 08:57 Zeno` hmmmm is awake? :-o 08:57 nrzkt don't forget little fixes like #2214 and #2209 08:57 ShadowBot https://github.com/minetest/minetest/issues/2214 -- Performance improvement -> Craftdef.cpp: Improve loop and mathematics for CraftDefinitionShaped::check by nerzhul 08:57 ShadowBot https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul 08:57 Zeno` nrzkt, I'll do a few at a time (those that I've tested) 08:57 Zeno` 2119 is surely thoroughly tested by now ;) 08:59 kahrl https://github.com/minetest/minetest/pull/2119/files#diff-60f7e3708240135081fe3828dea97c93R351 is a bit ridiculous :P 09:00 kahrl but there's no good way around that I guess 09:00 Zeno` That's how I'd probably have done it in the first place 09:01 Zeno` most of my "toy machines" (virtual machines) use a similar method 09:01 Zeno` void handleCommand_EyeOffset(ToClientPacket* pkt) <--- I'd prefer the * to be against the parameter name 09:03 Zeno` anyway, I have to eat. I plan to merge this 2119 in the next 8 hours (just giving you all a heads up and a chance to object) ;) 09:03 Zeno` afk for a bit 09:03 hmmmm nrzkt, I heard you wanted to change the protocol to use TCP 09:04 hmmmm TCP isn't used because it ensures in-order-delivery, and in doing so, creates much higher latencies than acceptable 09:04 hmmmm this is a conscious design decision and we don't really think it's a good idea to change it 09:05 nrzkt hmmmm 09:05 nrzkt look at this PR and you'll see many packets are sent as reliable, then the order is important. 09:05 nrzkt the TCP overhead is less important than the minetest TCP over UDP 09:06 nrzkt and for example, world of warcraft uses TCP 09:06 hmmmm huh?? 09:06 Zeno` I'll let you two debate that one :D 09:06 hmmmm just because a packet is sent as reliable does not mean the order is important 09:06 kilbith sapier wanted to use TCP too 09:06 nrzkt but we can do a mix, and use a TCP connection and a UDP connection together 09:06 nrzkt TCP for reliable and UDP for nobody cares packets 09:07 nrzkt TCP permit to use proper sessions on the server too 09:13 hmmmm pfffff 09:13 hmmmm well I'm stuck 09:13 hmmmm to fix KB946040 I need to apply a hotfix, but the link is broken 09:13 kahrl hmmmm: #include did not work? 09:13 hmmmm no this is a pdb problem 09:17 hmmmm kahrl: including did solve the xCGUITTFont.cpp problem. now it seems all that's left is the pdb error and this libintl.h error 09:18 hmmmm rather that's not a libintl.h error, hmm 09:18 kahrl why does it even try to build a pdb in release mode? 09:19 hmmmm i don't really know, but we do need them from now on since the msvc builds generate minidumps on crash 09:19 kahrl oh, right 09:19 hmmmm so we don't have to go through the "can you please get a backtrace of the crash" rigamarole with users experiencing problems 09:20 hmmmm ahhhhh ok 09:20 hmmmm so for whatever reason WinNls.h is included without Windows.h in gettext.cpp 09:20 hmmmm after I fix this problem I'm only going to have 5000 linker errors :) 09:21 kahrl :) 09:21 hmmmm on the bright side, once I get this rig working I'll presumably never have to redo it again 09:21 kahrl I wouldn't count on it 09:22 kahrl once we switch to C++11, msvc 2008 won't do :P 09:22 hmmmm :( 09:24 hmmmm here's one: ..\..\minetest\src\gettext.cpp(68) : error C2065: 'LOCALE_SENGLISHLANGUAGENAME' : undeclared identifier 09:24 kahrl that was also mentioned in the thread I linked, let me check 09:25 hmmmm yea 09:26 hmmmm i see it 09:29 hmmmm ah shoot look at how late it is 09:29 hmmmm gotta go NOW 09:29 nrzkt xD 09:31 Zeno` oh, that reminds me... I have to report the CGUITTFont.cpp segfault 09:31 Zeno` and assign it to kahrl 09:32 * Zeno` hides 09:32 kahrl you better hide 09:34 * Zeno` triple hides 09:35 Zeno` maybe some things should not be changeable using /set... but that's a big can of worms :( 09:37 Zeno` kahrl, what is hmmmm doing? 09:37 Zeno` building with msvc? 09:37 kahrl well he was before he left 09:38 Zeno` could krock be of help here? 09:38 est31 as we now have a release branch, can we merge #2225 ? 09:38 ShadowBot https://github.com/minetest/minetest/issues/2225 -- Fixes for minetest.get_(all_)craft_recipe(s) by gregorycu 09:38 kahrl he might 09:39 Zeno` est31, has it been reviewed and tested? 09:39 est31 I have tested it. 09:40 est31 I've brought this up before, they said It was ok, but I should come back when the freeze is over 09:40 jin_xi krocks pasted solution is this: -#include 09:40 jin_xi +#include 09:40 jin_xi but dunno if it applies here 09:40 kahrl we shouldn't discuss #2225 here 09:40 ShadowBot https://github.com/minetest/minetest/issues/2225 -- Fixes for minetest.get_(all_)craft_recipe(s) by gregorycu 09:41 kahrl gregorycu wants it to be discussed on github only 09:41 est31 when you come up with an issue, I'll notify that on github 09:42 est31 note* 09:50 kahrl Zeno`: well it seems obvious why /set font_size changes 09:50 kahrl FontEngine::readSettings calls cleanCache which drops the old fonts 09:51 kahrl for example the m_font in GUIChatConsole, which the latter will happily continue to use 09:52 kahrl whoops s/changes/crashes 09:53 kahrl if you comment out iter->second->drop() in cleanCache, the segfault disappears (but of course there's a nice leak) 09:54 Zeno` I know *why* it happens I just don't know how to fix it properly ;) 09:55 kahrl ah 09:58 kahrl how about https://gist.github.com/kahrl/24d5c037e1688b860918 10:01 kahrl btw, is the font supposed to become extremely blocky when I change font_size in-game? 10:03 nrzkt Zeno` #2119 whitespaces fixed 10:03 ShadowBot https://github.com/minetest/minetest/issues/2119 -- [patch 1/4] Network rework: Rewrite client/server packet handling & packet reading by nerzhul 10:04 Zeno` ok, merging now 10:04 Zeno` there have been no objections have there? 10:05 Zeno` pushed 10:12 Zeno` what's the other PR that needs a lot of testing? 10:12 Zeno` nrzkt? 10:13 Zeno` oh wait... the big one breaks backward compat? 10:13 nrzkt yes ? 10:13 Zeno` ok, I'll leave that for now until it's been discussed more 10:14 Zeno` looking at your other 2 10:14 nrzkt the other PR doesn't need many tests, i think testing it 3 or 4 days could be good 10:14 nrzkt i will redo the patch 2/4 PR 10:14 est31 is "the big one" the tcp move? 10:15 nrzkt no 10:15 nrzkt TCP move isn't finished yet 10:15 est31 k 10:15 nrzkt at this time it needs more things, i only break the connection model, i need to work on transmission and session rework now 10:15 est31 so old client cant connect to the new server? 10:16 est31 s/the/a/ 10:16 nrzkt in fact protocol is purely bugued at this time 10:16 nrzkt it need a break for future release 10:16 est31 yea 10:16 nrzkt some packets are wrong, some others aren't well formed, and i need to have a well designed API to write packets. PR 1 and PR2 have compat, but PR 3 will fix design 10:17 est31 there are just some ppl that offer their servers from master. 10:17 est31 like vanessae 10:17 Zeno` what are some other PRs that need looking at? 10:18 est31 Zeno`, scroll up :) 10:18 nrzkt #2214 and #2209 10:18 ShadowBot https://github.com/minetest/minetest/issues/2214 -- Performance improvement -> Craftdef.cpp: Improve loop and mathematics for CraftDefinitionShaped::check by nerzhul 10:18 ShadowBot https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul 10:18 nrzkt they are little, comparing with network :p 10:18 Zeno` apart from those :P 10:19 Zeno` I'm already looking at those two 10:19 Zeno` est31, I can't merge 2225 10:19 est31 why 10:20 Zeno` because it's not allowed to be discussed 10:20 Zeno` someone else will have to do it I guess 10:20 est31 I'm keeping out of your dispute 10:20 Zeno` If there is an obstacle that makes my work harder (e.g. cannot discuss on IRC) then I just won't bother 10:21 nrzkt ok #2273 is out. Tests before merge are require, i recommend 3 days on running servers 10:21 ShadowBot https://github.com/minetest/minetest/issues/2273 -- [Patch 2/4] Network rework: packet writing, sending and cleanups by nerzhul 10:21 est31 I'll relay everything you note to github 10:22 Zeno` est31, all I am saying is that I'm not going to spend the time reviewing the PR when the author will not spend the time talking about it. If that's petty then I am petty 10:22 Zeno` There are other coredevs who can look at it 10:22 est31 ok 10:22 Zeno` I merged one of his PRs only 2 days ago, btw 10:22 Zeno` so there is no malice... I'm just being lazy 10:25 est31 #2073 is ready too -- most of the comments are just about fixing something completely different 10:25 ShadowBot https://github.com/minetest/minetest/issues/2073 -- Simplify Readme build steps by est31 10:26 nrzkt for 2073, i think we must add a reference into game to minetest_game, this permit to clone recursive 10:27 est31 not neccessarily 10:28 nrzkt no but this is very useful :) 10:28 nrzkt #2273 need review please :) 10:28 ShadowBot https://github.com/minetest/minetest/issues/2273 -- [Patch 2/4] Network rework: packet writing, sending and cleanups by nerzhul 10:30 Zeno` yeah, that looks ok at first glance 10:30 Zeno` (2073) I mean 10:36 JakubVanek_ oh PR #2261 needs to rewritten now, i'll try 10:36 ShadowBot https://github.com/minetest/minetest/issues/2261 -- damage_per_second negative number implementation by JakubVanek 10:37 nrzkt wait for #2261 10:37 ShadowBot https://github.com/minetest/minetest/issues/2261 -- damage_per_second negative number implementation by JakubVanek 10:37 nrzkt i think i must fix it in network rewrite before 10:37 nrzkt the fix needs a protocol break 10:38 JakubVanek_ ok 10:38 nrzkt rebase it now, but it need to be a little bit rewrited when patch 2/4 will be merged 11:06 Zeno` any comments on #2217? 11:06 ShadowBot https://github.com/minetest/minetest/issues/2217 -- Fix Exit to OS button focus in Pause Menu by ngosang 11:07 nrzkt seems good 11:14 Zeno` I think focused_element is a sound idea 11:14 Zeno` I'm inclined to merge it 11:19 est31 what does 2073 need to get merged? 11:26 Zeno` est31, what is pilzadam's comment referring to? 11:27 Zeno` doesn't seem related to the diff at all :/ 11:28 Zeno` speak of the devil 11:29 Zeno` est31, lines 120- work for any distro and not just debian/ubuntu/debian-derived 11:31 Zeno` lines 108, 111, and 115 should be clarified to show they're using git (the only distro specific thing is, really, lines 108/109 11:31 Zeno` lines 111 and 115* 11:34 est31 Zeno`, PilzAdams comment is about which packages to have in line 106 11:34 est31 so unrelated 11:35 est31 Where is it written that the commands only work for debian/ubuntu? 11:35 est31 I can clarify in line 108 that its an example for debian/ubuntu 11:36 est31 lines 111 and 115 already contain a hint, but I can make it even clearer if you wish :) 11:36 Zeno` yeah, maybe just clarify that. Change it to something like make sure git is installed, for example on @*$(@*$(*@($*@( you can use apt-get *$(@*#$(@ 11:37 Zeno` well, I know Ubuntu is popular but 111- and 115- are fine (and distro agnostic) 11:38 est31 yea gonna change 108 11:39 Zeno` e.g. maybe there needs to be an extra heading before lines 111 and 120??? 11:40 Zeno` other than that the rest is good as far as I can see 11:41 est31 yea good idea, just idk how to format it, there is no example of that headline level 11:41 Zeno` -j2 might need explanation (e.g. $make -j2 # comment here) but that's pedantic 11:42 Zeno` maybe... hmm... Downloading using git and Downloading archive? I dunno 11:42 Zeno` hard 11:43 est31 yea but how to make the headlines. there are two levels of headlines currently in readme: one at the start underlined with ==== and many others underlined with ----- 11:43 est31 the only 3rd-level "headlines" I could find worked with identation 11:43 Zeno` Maybe they shouldn't even be part of "Compiling on GNU/Linux:" 11:43 Zeno` they should be getting the source 11:44 est31 isnt that too complicated? 11:44 celeron55 i'm adding nerzhul to the core team on github now 11:44 JakubVanek_ nrzkt: would you mind if i add getS8() to NetworkPacket? if so, it's okay, I'll read u8 and cast it 11:44 Zeno` Not sure... getting the source and compiling are two different things 11:44 celeron55 (aka nrzkt) 11:44 Zeno` celeron55, good call 11:46 celeron55 without any assigned subsystem for now; you can note me if you have ideas about those 11:46 Zeno` I don't have a subsystem either lol 11:46 Zeno` I'm just a drifter 11:46 est31 a serious drifter :) 11:47 celeron55 in my opinion some of the subsystem maintainers should probably be replaced by more active people, but i'm not sure who would fit which 11:47 nrzkt ofc Jakub 11:47 celeron55 and... the open ones should be filled in 11:47 celeron55 (http://dev.minetest.net/Organisation) 11:47 nrzkt but getS8 will be removed in part 2 to use the << >> operators 11:48 nrzkt i can take network part :) 11:48 celeron55 that probably makes a lot of sense as you're reworking a lot of it anyway 11:48 nrzkt Thanks c55 :) 11:49 nrzkt i go to lunch 11:50 Zeno` est31, anyway once the ... hmmm... ambiguities? that we've spoken about are incorporated I'll merge the PR 11:50 celeron55 (i guess sapier won't mind as he's hasn't been that active in the past month) 11:51 Zeno` est31, it's hard to tell where to stop. E.g. I don't do "in source" builds heh 11:51 est31 ? 11:51 Zeno` I guess it's a "yep, this is the basic way to do it" 11:51 Zeno` I don't do cmake . 11:52 est31 but? 11:52 Zeno` I prefer to keep my builds completely out of minetest so I have ~/minetest-build and do cmake ../minetest/ but it's a bit complicated 11:53 Zeno` I'm just saying to demonstrate that keeping it simple is the way to go (and you're 99% of the way there) 11:54 Zeno` I was just saying it as a sort of curiosity statement. I should have kept my mouth shut 11:54 est31 nono curiosity is good 11:54 est31 :) 11:54 celeron55 (this means nrzkt can push his own changes to the networking part, but of course nrzkt has the responsibility to make sure people are genreally okay with the changes) 11:55 celeron55 generally* 11:59 Zeno` is #2265 ok to push? 11:59 ShadowBot https://github.com/minetest/minetest/issues/2265 -- Increase MapBlock::actuallyUpdateDayNightDiff() performance by 2-8x by Zeno- 12:00 celeron55 where did you get that 8x figure from? 12:00 Zeno` callgrind 12:00 celeron55 to me it looks like quite strictly a 2x improvement 12:00 est31 differs wasnt initialized ? lol 12:00 Zeno` I expected only 2x performance as well 12:00 celeron55 (50% calls to nodemgr->get() means a 2x improvement) 12:00 Zeno` but callgrind disagrees 12:01 Zeno` maybe cache? 12:02 est31 updated 2073 12:02 celeron55 Zeno`: have you tested whether that actually works? 12:02 celeron55 because i think i see a bug 12:04 Zeno` with differs? 12:04 celeron55 at least one bug is immediately obvious: the light level of a node has to be interpreted as f.light_source if the node does not store a light value 12:04 celeron55 your code seems to assume that if a node does not store a light value, the end result is 0, while it should f.light_source 12:04 JakubVanek_ oh travis ci builds readme :) 12:05 celeron55 at least that's how the old code works 12:05 Zeno` which lines? 12:06 celeron55 in your code MapNode::isLightDayNightEq, in the old code MapNode::getLight and the comparison done directly in MapBlock::actuallyUpdateDayNightDiff 12:07 celeron55 there really should be a unit test for this as this is so prone to regressions 12:08 celeron55 your optimization really makes the code less maintainable and readable 12:09 Zeno` I can't see the error but I'll double check it 12:10 celeron55 hmm wait 12:11 celeron55 hmm i think i was wrong 12:11 celeron55 the reason why i was wrong is because there isn't a separate f.light_source value for LIGHTBANK_DAY and LIGHTBANK_NIGHT 12:11 Zeno` right 12:12 Zeno` I'll double check it anyway 12:13 celeron55 yeah so it looks fine to me 12:17 celeron55 let's try to make a habit of commenting "+1" to a pull request always if you check it to be pushable, even if you already say it on IRC 12:18 Zeno` I think that's a good idea 12:18 Zeno` I suggested it to SN a while ago 12:18 Zeno` because of time differences etc 12:18 celeron55 yeah i realized this when i was away for a long time and then wanted to see if there are any pull requests that i might want to merge 12:18 celeron55 the problem becomes, there was no easy way of knowing whether anyone had checked it 12:19 Zeno` I agree 12:20 Zeno` should nrzkt be voiced? 12:21 celeron55 yes but he won't be because of laziness 12:21 Zeno` hah 12:21 celeron55 (is nrzkt even "he"? stupid english with gender-locked pronouns) 12:21 Zeno` est31, 2073 looks better 12:21 Zeno` I'd rather not call him "it" 12:22 celeron55 i do assume nrzkt is a human 12:22 * Zeno` adds a +1 to 2073 12:23 Zeno` ok, bbl 12:23 est31 celeron55, you want to review 2073 too? then we can merge it :) 12:27 twoelk regarding discussions about core-dev activity, do take into account that the lifestyle of quite a few has changed just recently as instead of being pupils at school they are now students at university with different schedules and intensive exam times. So the dev- regulations system should offer sollutions for problems concerning seasonal-workers of which there seem to be quit a lot. 12:29 twoelk maybe also a is-on-holiday should be added so that others know when not to wait for activty from someone in charge of something 12:30 twoelk er, is-on-holiday-status I meant 12:31 gregorycu Isn't uni more flexible than school? 12:31 gregorycu But I think it's a good point 12:31 twoelk may be so but also much more intensiv 12:32 gregorycu Fair enough, I did 2 degrees at once 12:32 twoelk I used to fall of the face of earth for some weeks or even months during exam times 12:32 gregorycu But I didn't attend lectures or tutorials 12:32 gregorycu Only the stuff I had to attend 12:33 gregorycu I'm sure others are more sudious 12:33 gregorycu Like, attend spelling lectures etc. 12:35 twoelk I attended way too much and most of it off-topic - but 12:37 twoelk I think minetest should be carefull to not force activity on people on a too fixed form 12:37 celeron55 est31: commented 12:41 celeron55 twoelk: if people gracefully drop their tasks and not clinch to them while not doing anything to them, they can come back just as easily 12:41 nrzkt i'm back 12:42 celeron55 twoelk: the point is to try to allow progress to be made independently of whether a certain person is making it or not 12:43 celeron55 so if you stop having time for development, state it so that others can adjust to it and aren't waiting for anything 12:44 celeron55 that isn't too much to be asked 12:44 est31 celeron55, added two packages 12:45 twoelk that's why I think there should be a formal way to do this - like an extended afk/holiday note of sorts 12:45 gregorycu I'm back 12:46 gregorycu From my perspective, if you trust people to be contributors, there is no reason to un-trust them, even if they are UA 12:47 celeron55 being a core developer serves multiple purposes, only one of which is trust 12:47 gregorycu That is true, what are the other purposes? 12:48 gregorycu I use the term "trust" to mean several things, trust in ability, trust in diplomacy, trust in terms of responsibility 12:48 twoelk I would rather think the problem is that it is not clear wether somebody is working activily on a subject or not. And wether the afk is due to going to toilet or rather a mountain tour of several weeks 12:49 gregorycu I don't understand what "subject" means 12:50 gregorycu Surely a contributor, or just a member of the community has the same responsibility to be transparent about they ability to contribute to tasks worked on many people 12:50 celeron55 i guess the other purposes aren't well-defined, but it kind of implies that the person will allocate time for the project quite regularly and it implies that because of that, the person can take on larger tasks in the project without too much interference from others 12:50 twoelk and stating something on irc is not the same as displaying a status somewhere static that may show the status much as the master server list does for servers for example 12:51 celeron55 s/and it implies that because of that/and because of that/ 12:51 celeron55 (i can't english) 12:52 gregorycu If I commit to working on a serious bug, I think I should be held to a similar standard to a contributor 12:52 gregorycu Not just me, I mean as a member of the community 12:53 celeron55 can anyone come up with a practical solution to what twoelk is talking about 12:53 celeron55 it seems to be so low-bandwidth and high interval stuff that it's not worth maintaining a system for that 12:53 gregorycu I think it's a wrong solution 12:54 celeron55 what do you think is the problem and how would you solve it in practice? 12:54 gregorycu I think things should continue to function, even if someone doesn't report themselves AFK properly 12:55 gregorycu And you do that by regular updates when working on tasks, so that others can pick up the work and continue if you go away 12:55 nrzkt gregorycu, i will help you to commit things and discuss with you if they are good, without problems :) 12:55 gregorycu Thanks nrzkt 12:55 gregorycu :) 12:56 gregorycu I suppose I don't think it's a good idea to tighten the requirements to be a contributor (I hate this word) 12:58 gregorycu Because I feel there are not enough and, if I can be so frank, doing so too much could be seen as a little disrespectful to the contributors and the work they put in for RL commitments 12:58 gregorycu (I don't want to be a contributor, let me be clear) 12:58 nrzkt if you do a pr you are a contributor :) 12:59 gregorycu I don't know what the term is 12:59 nrzkt core-dev 12:59 gregorycu Thank you 13:01 nrzkt someone have objection for #2209 and #2214 ? Kahrl ? 13:01 ShadowBot https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul 13:01 ShadowBot https://github.com/minetest/minetest/issues/2214 -- Performance improvement -> Craftdef.cpp: Improve loop and mathematics for CraftDefinitionShaped::check by nerzhul 13:02 gregorycu I look at the 107 pull requests, I don't think they are outstanding because the current crop of core-devs are bad, there is just not enough of em :) 13:03 twoelk there are parts tha+1 13:03 twoelk I hate my cache :( 13:04 est31 yea, in fact I've wanted to improve the core too, but then I saw the long list of PRs, and decided to make a test pr (you guess which) in order to find out how fast PRs get merged. 13:04 twoelk I only typed +1 13:05 nrzkt est31 i'll start a cleanup today, but i have to fix problems at work before :) 13:06 twoelk gtgnow, just was affraid the new regulation suggestions might be not compatible with some life- and contribution styles 13:06 est31 nrzkt, nobody requires you to review test and merge them all today. 13:06 nrzkt no, but i'll talk with PR senders and ask if they are present :) 13:10 celeron55 gregorycu: as i see it, being a core-dev is more of a responsibility than a privilege; i wonder if that is why i don't really see those things you mentioned as being problems 13:12 gregorycu In my eyes you can't have responsibility without privilege, or the other way around 13:12 gregorycu I mean to say, does it hurt the project if a person goes on an unscheduled hiatus for a little while? 13:18 nrzkt Can i close #138 ? 13:18 ShadowBot https://github.com/minetest/minetest/issues/138 -- Health bars above player names 13:18 celeron55 gregorycu: it may, but it shouldn't have to 13:20 gregorycu Part of the solution is to ensure you always have a big enough bus factor 13:20 celeron55 i was just going to say exactly that with a lot more complex words 8) 13:21 celeron55 the fact is, we don't have a big bus factor, and it doesn't even seem to be very achievable 13:22 celeron55 part of the problem regarding to that is that people are mostly driven by the technology, not the end product 13:22 celeron55 it has been a common issue for years 13:23 gregorycu Well, let's get this part of the discussion then 13:23 gregorycu You are starting that with your 5 points for a PR 13:23 gregorycu If I'm not mistaken 13:24 celeron55 starting what with what? i don't get anything of what that line means 13:27 celeron55 ...i'm really curious of what that might have meant 13:27 gregorycu Trying to find the thing in the wiki 13:27 celeron55 wait do you mean the... thing 13:28 celeron55 the thing that nobody ever looked at 13:28 celeron55 this? http://dev.minetest.net/Merging_core_pull_requests_to_upstream 13:28 gregorycu Yeah, point number 1 13:29 celeron55 what's the issue 13:29 celeron55 (note that nobody has ever followed or probably even read that page) 13:30 est31 I guess if somebody actually merges PRs based on this, or employ this, others will follow 13:31 gregorycu I thought the page was a new thing 13:31 gregorycu I thought you were addressing: "part of the problem regarding to that is that people are mostly driven by the technology, not the end product" 13:32 celeron55 it looks like i made that page in June last year, so yeah it's relatively new 13:36 celeron55 i probably made that page in response to some kind of complaint by someone about PRs being hard to review and tried to come up with at least something that people can refer to 13:36 celeron55 i still don't understand whether gregorycu thinks this is a problem or a solution, lol 13:36 gregorycu :) 13:37 gregorycu I think the bus factor issue needs a solution 13:37 celeron55 it certainly hasn't solved nor caused any problems so that's a starting point for this discussion 13:37 gregorycu I'm happy with the core-devs we have, I don't think they need to be filtered 13:37 gregorycu This is of course, an outsiders perspective, as I'm not a core-dev 13:38 gregorycu An example is what held up the release 13:39 gregorycu There was nothing on github listed as a blocker 13:39 gregorycu I'm sure there were some core-devs looking into whatever problem it was 13:39 gregorycu But I would have liked to take a casual look, see what has been tried, maybe try something myself 13:40 gregorycu I guess I would have had to come in here, and fluked catching one of the people working on it 13:40 celeron55 i too am very unaware of what's going on with that 13:40 gregorycu Did some of them get hit by a bus? I don't know. No visibility. 13:41 gregorycu I honestly don't care about them, or their personal lives, only the issue and how they are progressing if they are making progress 13:41 celeron55 i assume a few people were looking into it and then when the week started had to pause it, and didn't really document it anywhere but this channel 13:42 celeron55 i guess they were expecting it to be a smaller problem and didn't plan that it would be come a multi-week bughunt 13:42 celeron55 become* 13:43 gregorycu A website with peoples holidays doesn't help here 13:43 gregorycu Anyway, I'm ranting a bit 13:44 celeron55 this is not a very common occurrence so i'm just hoping it will sort itself out 13:45 celeron55 (by moving the feature freeze out of the way of other development) 13:46 celeron55 but really, the issue here was that when some people don't have time to work on things, they were able to freeze almost the whole project by thinking that nobody else would be doing anything at any faster pace than them 13:46 celeron55 which is ideally really just a small quirk in the process 13:47 gregorycu MT doesn't always have priority in peoples lives, the process has to make it so when it is a priority they do the boring "paperwork" so that other people can carry on 13:47 gregorycu Paperwork = gihub comments, forum discussions 13:48 celeron55 i have tried to make it clear that people should be transparent in what they do, but i've kind of failed 13:48 celeron55 maybe the things that have to be done should be more strictly defined 13:48 celeron55 not a fan of that, but if it works, then it works 13:49 gregorycu They have degrees in Project Management 13:49 gregorycu Because it's hard to get right I suppose 13:50 gregorycu Anyway, I have a small problem with the PR churn rate, 107 pull requests is a lot. I'm attributing it to the "long" feature freeze 13:56 celeron55 the main issue with PRs still is that judging their quality is relatively easy, but judging their content is difficult 13:58 est31 yea 13:59 est31 but if people explained how to test it, then reviewers would follow their thought processes which makes it more likely both miss a bug 13:59 celeron55 i mean, not technical content; it's still in the easy part 14:00 celeron55 purely technical PRs are easy 14:01 gregorycu I'm just waiting until microsoft fucks up minecraft, then I feel we'll have an onslaught of PRs, mods and new players 14:01 celeron55 actually, now that i look at the PR listing this in mind, almost all of them are purely technical 14:02 celeron55 yeah this project will be strongly supported by microsoft in the future 14:02 gregorycu Right, you are concerned about PRs where you are not sure they meet point 1 14:03 celeron55 historically point 1 has been a huge problem, but it's simply not the problem right now 14:03 celeron55 is there a problem to begin with? lol 14:04 gregorycu There are pull requests from 2013 14:05 gregorycu And 107 PRs in total 14:06 celeron55 it's not that bad; there are 1177 closed PRs since 2011 14:07 gregorycu I suppose my opinion comes from my own outstanding PRs 14:08 celeron55 that's a possibility 8) 14:09 celeron55 there exists no requirement for anyone to handle PRs in a justifiably fair order 14:09 celeron55 it's probably better for general progress that way 14:10 celeron55 gregorycu: plug them in this chat right now, maybe that'll push them forward a bit 14:10 gregorycu #2173 #2224 #2225 #2241 #2242 14:10 ShadowBot https://github.com/minetest/minetest/issues/2173 -- Speed up Profiler::avg by a factor of 10 by gregorycu 14:10 ShadowBot https://github.com/minetest/minetest/issues/2224 -- Fix jumping at node edge by gregorycu 14:10 ShadowBot https://github.com/minetest/minetest/issues/2225 -- Fixes for minetest.get_(all_)craft_recipe(s) by gregorycu 14:10 ShadowBot https://github.com/minetest/minetest/issues/2241 -- Fix for disable_jump group doesnt work on nodeboxes by gregorycu 14:10 ShadowBot https://github.com/minetest/minetest/issues/2242 -- Optimise MapBlockMesh functions by gregorycu 14:11 nrzkt i'll look at this later greg 14:12 gregorycu I should really try to exploit your green eagerness :) 14:12 nrzkt sfan5 are you there ? 14:12 est31 celeron55, like the updates for 2073 ? 14:14 celeron55 est31: it's still fine 14:14 gregorycu I gotta run, it's late, thanks for the chat 14:14 est31 merge, then? 14:14 gregorycu est31: Let's discuss the API improvements again in the near future 14:15 est31 gregorycu, ok 14:15 nrzkt sfan5, can you tell me if #1020 is valid ? 14:15 ShadowBot https://github.com/minetest/minetest/issues/1020 -- Whole menu messes up when using Local Install from Mods menu and pressing Cancel 14:16 celeron55 est31: i'll merge it (with a different commit message; it's as much about recommending git as simplifying) 14:23 celeron55 (done) 14:23 est31 thanks :) 14:24 celeron55 i think what i'll say to core devs from now on is "we have closed on average 1 PR per day through our history and we are doing fine; how can you imagine doing worse than that?" 14:25 celeron55 this is the answer to all complaints 14:30 celeron55 i'm a bit unsure about these new core developer rules based on gregorycu's point about it being mostly about trust 14:33 celeron55 i'm going to change these to be more sloppy about activity and be worded a bit differently 14:35 nrzkt what do you think about #1521 ? I test a personnal rebase and it works very well 14:35 ShadowBot https://github.com/minetest/minetest/issues/1521 -- Water surface shader. by RealBadAngel 14:37 nrzkt celeron55 can i close #1228, i override your PR :) 14:37 ShadowBot https://github.com/minetest/minetest/issues/1228 -- Move packet creation to a central location (work in progress) by celeron55 14:38 celeron55 feel free to 14:39 nrzkt thanks 14:42 celeron55 i changed the rules like this: https://forum.minetest.net/viewtopic.php?p=169838#p169838 14:45 nrzkt very good ! 14:50 Zeno` geez nrzkt :P Calm down 14:50 nrzkt i only answer to old issues ^^ 14:50 Zeno` main() (and the_game()) were both refactored before 0.4.11 :P 14:50 nrzkt main.cpp is big now too :( 14:51 Zeno` the actual file is, yes 14:51 nrzkt and it's spaggethis, mamma mia 14:51 Zeno` but the function which used to be 2000 lines long is now... I dunno 14:51 nrzkt okay ! 14:52 Zeno` it still needs work though. To get it merged I had to make it "kind of close" to how it used to be 14:52 nrzkt no problem 14:53 Zeno` lol, it's fine 14:53 Zeno` I don't mind old stuff being opened but... 14:53 nrzkt many issues seems to be pertinent, i don't know about most of the issues, but they can be possible :s 14:53 PilzAdam nrzkt, we don't assign people to PRs 14:53 PilzAdam (or issues) 14:54 PilzAdam it looks as if you are saying "nobody is allowed to fix this bug except me" 14:54 nrzkt oh ? i saw some issues assigned to kahrl 14:55 nrzkt okay, i would tell: i'll fix it, don't duplicates work , but if nobody wants, that's ok 14:58 celeron55 the issue assignments are mostly pointing to people who are known to know the subject well to fix it 14:58 nrzkt i see 14:58 nrzkt Zeno`, PilzAdam, agree with #2209 (rebased freshly because network part 1 broke it) 14:58 ShadowBot https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul 14:59 Zeno` I can't merge atm 14:59 Zeno` in... errr, don't shoot me... Windows 14:59 nrzkt i can do it, if you agree 15:00 Zeno` here is what main.cpp looked like around the time 957 was opened: https://github.com/minetest/minetest/blob/996ea60642c5d78fc915573af0641d78bc7e2d49/src/main.cpp 15:00 Zeno` 2209 is fine 15:00 nrzkt ouch 15:01 nrzkt i understand now :p 15:02 Zeno` but, yeah, it still needs more work 15:03 Zeno` merge 2209 I think 15:03 nrzkt i do it 15:03 Zeno` maybe remove the word ugly :P 15:04 nrzkt already done ^^ 15:04 Zeno` xD 15:04 nrzkt Application : Replace getPlayer(playername) by getPlayer(peer_id) in some possible cases. ok @Zeno- 15:04 sfan5 nrzkt: I'm here 15:04 sfan5 (now) 15:04 nrzkt sfan5, can you tell me if #1020 is valid ? 15:04 ShadowBot https://github.com/minetest/minetest/issues/1020 -- Whole menu messes up when using Local Install from Mods menu and pressing Cancel 15:05 sfan5 nrzkt: i dunno, it was a bug that happened before we released 0.4.8; the local install option is currently disabled anyway so it's not an issue right now 15:06 nrzkt can i close it ? 15:07 sfan5 i think it would still happen if the "local install" option was enabled 15:07 sfan5 let me test 15:09 sfan5 yup 15:09 sfan5 still happens 15:11 nrzkt hmmm, then the issue is valid 15:17 Zeno` can someone merge #2265 please? c55 has agreed 15:17 ShadowBot https://github.com/minetest/minetest/issues/2265 -- Increase MapBlock::actuallyUpdateDayNightDiff() performance by 2-8x by Zeno- 15:17 nrzkt i look at this 15:18 Zeno` thanks. I'd do it myself but I don't want to reboot this close to going to sleep ;) 15:23 nrzkt done 15:24 est31 comments on #2275? 15:24 ShadowBot https://github.com/minetest/minetest/issues/2275 -- lua_api.txt should have a since field for every function 15:24 nrzkt there isn't any documentation on wiki ? 15:25 est31 http://dev.minetest.net/minetest.forceload_block 15:25 est31 quite alot 15:25 nrzkt it miss the supported version on each call 15:25 est31 then add it to the issue description :) 15:26 est31 as comment* 15:27 est31 what do you mean with call? 15:29 nrzkt api call 15:29 est31 and what do you mean with version steps? 15:30 Zeno` #2261 will need to be squashed I think (if it's to be merged) 15:30 ShadowBot https://github.com/minetest/minetest/issues/2261 -- damage_per_second negative number implementation by JakubVanek 15:30 nrzkt cannot be merged, protocol break 15:31 Zeno` maybe that should be a github label :P 15:31 nrzkt i tagged protocol bump, is this right ? 15:33 Zeno` seems there is no other appropriate label/tag 15:34 nrzkt this commit must wait network rework part 2 and could be merged with network rework part 3, which introduce a massive protocol break 15:34 nrzkt (4-5 incompatible packets) 15:35 est31 protocol break == protocol version increment?? 15:36 nrzkt indeed 15:36 nrzkt the actual protocol has some bugs and need some design rework 15:37 Brains nrzkt: I think I'm confused about how the XDG issues (#395 & #864) worked out... The issues were closed with no PRs but you said something about approving the change in #395. 15:37 ShadowBot https://github.com/minetest/minetest/issues/864 -- XDG Base Directory Specs 15:37 ShadowBot https://github.com/minetest/minetest/issues/395 -- Config file on XDG dir on Linux 15:37 Zeno` it's not a very good label IMO. Protocol bump does not necessarily mean backward compatibility will break 15:37 nrzkt Brains duplicates 15:38 nrzkt i keep 864 because it's more recent and the discussion have more elements 15:38 nrzkt has* 15:38 Zeno` I think it needs to be made clear "older clients will not work" 15:38 nrzkt "protocol break" tag ? 15:38 celeron55 that pull request doesn't need a brotocol break, it's just what will probably happen soon enough for it to be simply included in it 15:38 hmmmm before reverse compatibility is broken, we need to see this commit to assess whether it's worth it 15:38 Brains nrzkt: I see my mistake, I thought 864 was closed. Nevermind me... Sorry. 15:39 nrzkt Brains: no problem 15:39 hmmmm and I completely veto using TCP 15:39 nrzkt then, rewrite all network. 15:40 celeron55 i suggest nobody vetoes TCP until they have actually tested how well it works 15:40 celeron55 at least that is what i will personally do 15:40 nrzkt we can use both TCP and UDP if this could satisfy any. TCP for security and UDP for packet we don't care. 15:40 nrzkt but stop invent TCP over UDP. 15:40 Zeno` it needs to be labeled that it will break older clients though... surely 15:40 hmmmm I used to be in the camp that tcp could be mixed in with the protocol into parts latency-agnostic bits but I changed my stance since I feel that rUDP could be made better by simply improving what is already there 15:40 est31 security is uncoupled from tcp vs udp 15:40 hmmmm forget about that 15:40 hmmmm there's one major difference here: 15:41 est31 you can also encrypt udp 15:41 celeron55 Zeno`: it can't be done in the way the pull request wants to; if it would be included before the break, then it would have to be modified to add the field in a backwards-compatible manner 15:41 hmmmm tcp blocks all packets from being handled until it receives every single one needed to be in order 15:41 nrzkt i don't talk about security of the transmission but reliability 15:41 celeron55 Zeno`: i think that should be just commented to it, i'll go and do that 15:41 est31 ah 15:41 Zeno` yeah, ok a comment would be good enough 15:41 nrzkt hmmmm: only media information will come with multiple packets. Other uses only one packet 15:41 Zeno` just *something* so it's obvious 15:42 hmmmm nrzkt: but media is downloaded using cURL. that already uses TCP 15:42 hmmmm what's the point then?? 15:42 nrzkt TCP is better for handling sessions and reliability of the transmission 15:42 nrzkt 85% of MT packets are reliable. 15:44 nrzkt MT is not a FPS, it's like a RPG. World of Warcraft uses TCP by default and doesn't have any problem with latency. 15:44 celeron55 the HTTP media server is a hack that shouldn't be needed at all 15:44 celeron55 ideally it should be removed when it isn't needed anymore 15:44 hmmmm as to your first point. that's true, but so what? how is that any better at all than minetest's reliable udp implementation 15:45 hmmmm second, I'm sure they are mostly reliable. but they can still be latency-critical 15:45 nrzkt MT reliable UDP implementation is like spaghettis 15:45 nrzkt many threads, queues, locks. 15:45 hmmmm then fix the implementation instead of introducing an incredible amount of latency 15:45 nrzkt no latency with TCP. Please stop using a satellite for playing 15:45 hmmmm latency is a huge concern 15:46 hmmmm yes, there IS latency with TCP that's not necessary. 15:46 hmmmm it's real, it exists, and it could be potentially horrible. 15:46 hmmmm I vote unconditionally against TCP. 15:46 nrzkt as i said, 85% from MT are reliable. Then they are using a TCP like implementation 15:46 hmmmm holy shit I said already 15:46 hmmmm minetest's reliable UDP does not have all the same characteristics as TCP does 15:47 hmmmm I'm not going to repeat myself any more 15:47 Vexyl I thought mixing TCP and UDP was generally a horrible idea. 15:47 celeron55 yeah it's probably worse in pretty much all aspects 15:47 nrzkt now, wait for my implementation, test it and say what you want. 15:47 celeron55 minetest's reliable UDP implementation that is 15:47 hmmmm if it's so horrible, I'd rather learn what makes it horrible, and fix that 15:47 hmmmm as of right now it has a clear advantage over TCP in terms of latency 15:47 celeron55 the only way to make it actually work is to switch to enet 15:47 hmmmm and enet is udp based 15:47 hmmmm so what's your point 15:48 celeron55 yes; it's the competent rudp implementation if such is wanted 15:48 celeron55 we shouldn't make it ourselves 15:48 nrzkt ofc. Let the OS properly do what he knows doing. 15:48 kilbith sapier told me in PM that enet is the 2nd faster solution behind a custom TCP, for info 15:49 celeron55 nrzkt: for your own sanity, you should probably just ignore hmmmm though 15:49 hmmmm I remember sapier did have a patch in his own branch that adds enet support 15:49 celeron55 otherwise you'll get brain cancer or something if you disagree with him 15:49 hmmmm but this is all ridiculous 15:49 hmmmm instead of just saying "nope. we can't do it" let's figure out how they do it and see if we can't do the same 15:49 nrzkt in fact sapier implementation uses the current design, and we need to rework all the stack 15:49 celeron55 sapier also has a tcp+udp implementation which is close to what nrzkt is going to do 15:49 celeron55 and he didn't report any considerable issues with it 15:50 Brains Make the appropriate interface, swap out netcode underneath it, and let history decide. *shrug* 15:50 est31 swappable ... neat 15:50 celeron55 that interface already exists, sapier made it a year ago for the exact purpose of figuring out what we should actually used underneath it 15:51 celeron55 actually use* 15:51 nrzkt the protocol change isn't today, it will be in the PR in 2 or 3 weeks, i need to properly change clientiface.cpp and use the new native connection 15:51 JakubVanek_ oh i feel bit stupid with my coding style fixes 15:51 celeron55 and he also reworked the udp-only implementation to work with that interface, which is frankly an overcomplicated mess but it's there anyway currently 15:51 hmmmm if the underlying problem with reliable UDP is something in the protocol that fixing would ruin backwards compatibility, then I can understand the case for using enet 15:51 nrzkt JakubVanek_: don't forget to rebase your commits 15:52 Brains celeron55: You wouldn't happen to have a link to some docs or anything on that handy? Now I'm curious. 15:52 hmmmm but has anybody actually done this research? 15:52 celeron55 hmmmm: well i personally designed the protocol years ago and i can confirm it's very crappy 15:52 hmmmm because it sounds to me like a lot of changes in minetest are being done for the sake of change based off of somebody's prejudices, not necessarily making it better 15:52 nrzkt in fact you can trash backward compat because there are many issues on the protocol which need a break 15:53 hmmmm such as..... 15:53 hmmmm come on, I can't do this right now, I have work... 15:53 nrzkt using wrong types into packets 15:53 nrzkt go work instead of trolling without testing... 15:53 celeron55 hmmmm: go away then, you're not making any progress happen with this discussion 15:54 nrzkt or using two differents string serializations (one isn't a huge cost) 15:54 nrzkt or pass some strings as simple char[X] without serialize 15:55 hmmmm an opinion you disagree with isn't trolling 15:55 hmmmm I don't quite understand how what I'm saying is stupid 15:55 celeron55 trolling is a completely incorrect term for that but the point is clear 15:55 nrzkt in fact this isn't an opinion problem, i read the networking code. Did you ? 15:55 hmmmm all I'm suggesting is that actual research is done before knee-jerk large codebase changes are made 15:56 nrzkt it's a codebase change ! network is important 15:56 hmmmm and right now it seems like it hasn't 15:56 luizrpgluiz hi 15:56 nrzkt hmmmm: please release 0.4.12 15:56 celeron55 hmmmm: nobody is going to listen to you because you haven't researched it either; hoever we will gladly listen to eg. sapier if he comes aroun 15:56 hmmmm luzrpgluiz: do you actually say anything other than 'hi'? 15:56 celeron55 around* 15:56 celeron55 however* 15:56 hmmmm celeron, that is so nonsensical 15:57 hmmmm so unless I take on the full burden of doing all the work that should've been done beforehand, we should allow changes to get added willy nilly 15:57 hmmmm okay I have an idea. 15:57 hmmmm we should blank out all of the source files in the entire project. 15:57 celeron55 this is actually beyond ridiculous, lol 15:57 hmmmm this will improve code organization and optimize execution time. 15:58 Wayward_One Zeno`, yes, i've tested using /status as well 15:58 celeron55 hmmmm: if nrzkt is ready to rework the entire thing, he's not taking anything away from you 15:58 luizrpgluiz all, which will have the new version of minetest? there will be changes in the engine? 15:58 celeron55 and he does have experience on the subject 15:59 celeron55 and the end result will be reviewed before it'll touch upstream 15:59 hmmmm celeron55: and I'm not saying that I am going to stop him 15:59 celeron55 there's nothing to worry about 15:59 hmmmm yes there is 15:59 hmmmm it'll get shoved into upstream without so much as a second thought 15:59 hmmmm "tested it on my server for 2 weeks, can't see any problems! let's add it!" 15:59 nrzkt it's why my commits are separated PR's 15:59 nrzkt in fact network is simple to test 16:00 nrzkt send one packet of each type, if each part handle it properly it works. 16:01 luizrpgluiz I wanted to be part of the beta test to test new versions of the game before officially launch 16:01 celeron55 hmmmm: what kind of data do you think should be gotten before deciding to do it, then? 16:02 nrzkt and also, for compat, i tested all the cases: legacy client with current server, legacy server with current client and current with current. Then i'll send the PR, wait the review of unpartial persons 16:05 nrzkt it seems that #2164 is ready, everybody agrees ? 16:05 ShadowBot https://github.com/minetest/minetest/issues/2164 -- Fix FTBFS on GNU/Hurd platform by apoleon 16:05 est31 ~protect 16:06 est31 aw sorry 16:06 est31 wrong # channel :( 16:09 Zeno` hang on. So legacy clients will still be able to connect to servers with the new "protocol"? 16:09 Zeno` and vice versa? 16:09 nrzkt no 16:09 nrzkt it's impossible 16:09 celeron55 nrzkt is working on many layers, one at a time 16:10 Zeno` I know... just confused about the comment: 16:10 nrzkt but Patch 2/4 don't 16:10 Zeno` nrzkt> and also, for compat, i tested all the cases: legacy client with current server, legacy server with current client and current with current. Then i'll send the PR, wait the review of unpartial persons 16:10 nrzkt i talk about Patch 1/4 and 2/4 16:10 nrzkt no compat break here 16:10 Zeno` yep 16:11 celeron55 nrzkt: can you explain here when and for what purpose on what layer you plan on breaking compatibility on? 16:11 celeron55 i mean, this should be made perfectly clear to everyone 16:11 celeron55 so that people can comment properly to begin with 16:12 Brains Could it be pasted to github/forum/wiki/something so that those of us not present can see as well? 16:12 nrzkt okay, 16:12 nrzkt the first part of the breakage was here 16:12 nrzkt https://github.com/nerzhul/minetest/commit/ad85f1c9ecc45cb39a7eada6c2fb5b179131648f 16:13 nrzkt This cleanup the API, removing static char copy into packets. And _INIT packet is modified. 16:13 nrzkt This also remove some old interfaces to use NetworkPacket in a lower layer (connection.cpp) 16:14 nrzkt This break the AccessDenied packet, using an ID instead of a string, this permit to use intl on client for server auth messages, but i kept LUA API compat with a special type SERVER_ACCESSDENIED_CUSTOM_STRING 16:15 nrzkt it also fix DeleteParticleSpawner, the server currently send a U16 whereas it's a U32... 16:16 nrzkt this is the first part of this PR, but i think i'll add a breakage on string serialization in the packet 16:16 nrzkt at this time, we have : *pkt << std::string and pkt->putLongString 16:17 nrzkt the only difference between those two types of string is the length. First: u16, second u32 16:17 nrzkt using a u32 for all strings permit to use *pkt << std::string and remove putLongString 16:18 nrzkt then it's all for the third PR. But as JakubVanek_ point, the _damage packet is also wrong and need to be fixed fix a larger modification 16:18 nrzkt fixing* 16:18 hmmmm celeron55, I reckon it'd be useful to know... 1). min/median/max and average RTT, packet overhead, throughput for the current implementation, TCP implementation, and an enet implementation 16:19 nrzkt hmmmm: i agree 16:19 hmmmm 2). I'd like to directly compare enet's protocol vs. minetest's reliable udp protocol and find what differences between the two make the most difference in metrics and why 16:19 nrzkt RTT is lost with pure TCP because we don't know each packet, we know a transaction 16:20 hmmmm 3). I'd like to know if the increased latency in TCP negatively affects actual game experience 16:20 nrzkt and MT doesn't need a 1Gbps bandwidth with 0.0001ms of latency 16:21 nrzkt i agree with the third point too 16:21 nrzkt but TCP will not add 10sec of latency 16:21 hmmmm you don't need to add 10 seconds of latency to negatievly impact the end user's experience 16:22 hmmmm negatively 16:22 nrzkt i know :) 16:22 hmmmm it could be as low as a half second even 16:22 nrzkt tcp doesn't take 0.5sec latency 16:22 hmmmm and half second latencies with TCP are not uncommon, because a packet got corrupted in transmission and so ALL network stops during that time until an unbroken packet is actually received 16:23 hmmmm there is absolutely no functional need for ordering with minetest's protocol 16:24 celeron55 there are two potential places for breaking network compatibility: 1) at the packet level, i.e. making L6 packets sane by not using weird formats and versioning conventions for things all over thte place, 2) at the low level; this is where the rUDP/TCP/enet talk happens 16:24 hmmmm sapier added enet without breaking the current implementation in his branch 16:25 celeron55 (2) doesn't necessarily have to break anything; different protocols can exist there 16:25 hmmmm of course 16:26 hmmmm for what it's worth, I have no issues with removing backwards compatibility seeing as how we're coming up against a major release next 16:26 fireglow I would also be great if minetestserver could use more than one listener 16:26 celeron55 but (1) is quite fundamental to the design of the program; making it sane will help avoiding future compatibility issues and help developers not pulling their hair out on updates that could be trivial 16:27 celeron55 nrzkt: is this in line with what you have planned? 16:31 celeron55 if this isn't, then i too might disagree with the plans 16:32 nrzkt in fact hmmmm the problem is not the protocol itself, it's all the implementation 16:32 nrzkt its enet implementation integrates properly with current connection.cpp 16:32 hmmmm which layer of the protocol are we talking about 16:32 nrzkt 4->6 16:32 hmmmm fireglow, binding to multiple ports you mean? 16:33 hmmmm sounds like a feature request, you can add that as an issue on the github page 16:34 celeron55 really what makes most sense to me is to first go after all the weird L6 formats and make the thing allow robustly adding more features, and then go after L4, attempting to finally choose whether the existing rudp, enet or tcp or tcp+udp works best 16:34 nrzkt for the (1), i must say: wait. The layer rework isn't done, i have broke current working connection between client and server to rework on socket and client handling. Packet reading will be ready soon 16:34 hmmmm I think you guys (actually, celeron mostly) are unreasonably angry with my request that the utility and impact of changes to code be researched first before actually committing it 16:35 celeron55 you started unreasonably angry too so it's now a tie 16:35 hmmmm I don't go around making major changes to core data structures without hard data to back it up, and before making every attempt possible to fix the current implementation 16:35 nrzkt for my PR, patch 1,2,3 doesn't break the layer 4->6. wait the patch 4 before decide something. 16:36 nrzkt the current implementation is complete but hard. The TCP implementation i'll write will be very very simple, with a SessionManager to handle clients and will be very pretty and little 16:37 nrzkt in fact i tried to add TCP wrapper into current implementation but it was very very hard to add and a complete rework make it simpler, because current implementation is done for UDP, not for TCP and many things will slow TCP connection without interest 16:38 celeron55 you'll want to make it something that is able to work with enet too; otherwise we can't compare anything properly 16:38 nrzkt i think it's possible. But i need to finish SessionManager before 16:39 celeron55 that might get weird though 16:40 nrzkt and i think we need to compare current implementation between current implementation with enet (like sapier does) with the rewritten implementation with pure TCP 16:40 celeron55 enet probably is something like what the current implementation would be if it was improved infinitely 16:41 celeron55 performance-wise 16:41 nrzkt ofc 16:42 nrzkt i need to go back home, see you 16:43 nrzkt #1188 need a review 16:43 ShadowBot https://github.com/minetest/minetest/issues/1188 -- getTime refactoring by Selat 16:48 celeron55 Brains: i do not think it was documented outside of the code itself 16:51 celeron55 Brains: https://github.com/sapier/minetest/commit/bbc8195950b114c77794d801c74a6887c1c44d95 16:52 celeron55 https://github.com/sapier/minetest/commits/network_addon_enet_6 https://github.com/sapier/minetest/commits/network_addon_tcp_2 16:52 celeron55 these give some idea on it 16:54 celeron55 frankly it's not really a plugin layer of any kind, but it's possible to add other protocols to it 16:54 celeron55 unlike previously 16:56 celeron55 that stuff isn't very pretty though because it closely follows the original MT-rUDP's interfafce 16:56 celeron55 interface* 17:00 JakubVanek_ these two PR are duplicates: #2183 #2071, i would prefer the ngosang's #2183 rather than mine. what do you think? 17:00 ShadowBot https://github.com/minetest/minetest/issues/2183 -- Fix Download complete dialog in the mods store by ngosang 17:00 ShadowBot https://github.com/minetest/minetest/issues/2071 -- Remove last installed mods name concatenation by JakubVanek 17:00 ShadowBot https://github.com/minetest/minetest/issues/2183 -- Fix Download complete dialog in the mods store by ngosang 17:53 nrzkt ofc celeron, an intermediate layer is required. I'll think about it 19:10 MattJ Couldn't figure out why the multispawn mod wasn't working for me 19:10 MattJ I traced it down to fields.quit == "true" when the form fields are received from the client 19:10 MattJ It uses button_exit to submit the form, should quit == true? 19:21 nrzkt i think about project, why not using compiled libraires instead of compiling twice and not sharing compiled code ? 19:22 nrzkt it would be great to add for example a sharedlib which contains common utils 19:57 nrzkt sfan5: wget: unable to resolve host address `sfan5.pf-control.de' on travis 19:57 nrzkt can you fix it ? 19:57 nrzkt it break windows builds on travis 20:02 sfan5 nrzkt: works for me 20:15 nrzkt can you relaunch https://travis-ci.org/minetest/minetest/builds/50239329 for my pr ? :) 20:16 nrzkt oh, i can do it myself by signing with github 21:11 nrzkt If some developper have time, i moved ClientLauncher and InputHandlers from main.cpp to dedidated .cpp and .h, and also cleanup useless includes. PR #2277 21:11 ShadowBot https://github.com/minetest/minetest/issues/2277 -- Main.cpp cleanup: Move ClientLauncher and InputHandlers to dedicated files by nerzhul 22:23 * Tesseract throws #1606 on the table now that 0.5 is coming up. 22:23 ShadowBot https://github.com/minetest/minetest/issues/1606 -- Add mod security by ShadowNinja 22:25 Tesseract Also, #1943 is high-prio since I know of a practical (easy) remote code execution exploit related to it. 22:25 ShadowBot https://github.com/minetest/minetest/issues/1943 -- Improve client authentication 22:27 est31 case insensitivity, whos on windows :) 22:31 Tesseract est31: It makes sense for usernames. And AFAIK only one core dev uses Windows, and he's been MIA for a while. 22:33 Calinou aka. BlockMen 22:34 est31 I dont think the main issue that its SHA-1, the problem is this replay vuln. 22:34 est31 there is no known practical 2nd preimage attack for sha-1 22:34 est31 but yes a very serious issue 22:46 est31 guess you knew that just didnt want to mention it :)