Time Nick Message 00:19 VanessaE sapier: saw you join the server.. 00:19 VanessaE something of interest? :) 00:19 sapier valgrinding ... 00:19 VanessaE oh ok 00:20 sapier still waiting to see anything ;-) 00:20 VanessaE you already timed out 00:20 sapier wow 00:20 VanessaE (or signed out) 00:20 sapier a lot of lost memory 00:20 VanessaE bad? 00:20 sapier enough to be relevant 00:40 sofar eh, my bukkit server is sitting at 5gb ram VIRT, minetestserver is 1853M VIRT ... I'm happy ;) 00:41 VanessaE sofar: that's...a tad excessive :) 00:41 VanessaE (even for minetest) 00:42 sofar 16176 minetest 20 0 1853m 1.6g 7392 S 12 20.8 69:35.26 minetestserver 00:42 sofar 3421 minecraf 20 0 4998m 3.2g 1444 S 10 42.9 7154:15 java 00:43 * VanessaE peeks over sapier's shoulder 00:45 sapier wtf 00:45 VanessaE sorry! I won't look anymore 00:45 VanessaE ;) 00:46 sapier no not you VanessaE 00:46 VanessaE dare I ask how bad this had to be to call for a 'wtf' ? 00:49 sapier particle handling is still loosing memory 00:49 VanessaE wait, I thought that was fixed? O_o 00:50 sapier yes but there seem to be additional situations where it ain't fixed 00:51 sapier ah there it is 00:52 sapier client doesn't cleanup it's event queue on shutdown 00:52 sapier sadly that leak is irrelevant for gameplay 00:53 sapier and hard to fix ... at least as long as clientevents are plain datatypes 00:55 sapier I'm gonna try to find a less invasive fix tomorrow 01:53 paramat hi hmmmm please can this be merged #2175 ? so i can work on mgv5 during the freeze 01:53 ShadowBot https://github.com/minetest/minetest/issues/2175 -- Mgv5: Speed optimise noise. Remove blobgen, add large caves. Cavegen: add mgv5 large caves by paramat 02:05 gregorycu #2187 02:05 ShadowBot https://github.com/minetest/minetest/issues/2187 -- Make the GameGlobalShaderConstantSetter use the settings callback by gregorycu 02:06 VanessaE paramat: just fyi, feature freeze now, 0.4.12 release on the 29th 02:07 gregorycu What's the feature freeze for? 02:07 gregorycu Core, or mapgen, or what? 02:08 VanessaE normally it's for the whole engine 02:08 gregorycu Is this stuff in the forum? I should really check that out. 02:08 gregorycu I'm going to look at bug #132 now 02:08 ShadowBot https://github.com/minetest/minetest/issues/132 -- Jump at node edge doesnt work 02:08 VanessaE no but it should be 02:08 gregorycu I don't understand how some of these bugs have not been squashed yet 02:08 hmmmm bFogEnabled? oh please no don't use hungarian notation 02:09 VanessaE no one thought it irritating enough to fix I guess :) 02:09 hmmmm I am not more enlightened now that you prefixed the variable with a 'b' 02:09 VanessaE hmmmm: isn't that camelCase? 02:09 VanessaE oh that 02:09 hmmmm there are two kinds of hungarian notation 02:09 gregorycu Sorry hmmmmm 02:09 gregorycu That's my day job leaking into minetest 02:09 hmmmm the useless kind that you see prevalent, and the original kind first used in microsoft office's original codebase 02:09 gregorycu (I hate hungarien) 02:10 gregorycu Sorry, I hate systems hungarian 02:10 hmmmm the original hungarian notation was to prefix the variables with an abbreviation or letter that signifies its purpose 02:10 hmmmm not... variable type 02:10 gregorycu Yeah 02:11 gregorycu Oh dear, that was criminal of me 02:12 VanessaE string his ass up. ;) 02:16 gregorycu I have amended by commit, please forgive me 02:32 hmmmm not quite understanding this commit https://github.com/gregorycu/minetest/commit/7cededb7b9889bb647b4277d9bcf5a58786f4cf1 02:32 hmmmm were you testing this on a 32 bit machine? 02:33 gregorycu No... ? 02:33 gregorycu Why do you ask? 02:33 hmmmm fwiw i am guessing the majority of the savings comes from fastfaces_new.reserve(512) 02:33 hmmmm because const v3s16 & should be the same speed as passing a v3s16 in theory 02:33 gregorycu Oh 02:34 hmmmm they're both the same size 02:34 gregorycu Yes, at least on my machine, more inlining occured 02:34 gregorycu So, it's a secondary effect 02:34 hmmmm if it's because byval calls the default constructor first I'm going to be very upset 02:35 hmmmm C++ is so difficult to write optimal code for 02:35 gregorycu :) 02:35 hmmmm it just doesn't do the thing you expect it should do 02:35 gregorycu If you think about it, it's one of the easiest 02:35 gregorycu If you know what you're doing 02:35 hmmmm you need to have way too much knowledge 02:35 gregorycu (Compared to higher level languages where you have no control) 02:35 gregorycu Yeah, that's agreed 02:36 gregorycu I'd be fucked if I didn't have my profiler 02:36 hmmmm the optimizer is only going to optimize things where it's absolutely 100% safe to (i.e. not have any side effects you may have possibly wanted) 02:36 hmmmm but... C++ is so extensive that you never know what kind of trap features you're activating 02:36 gregorycu There is one minor bug that slipped in, I'm going to fix this now 02:37 hmmmm you modify n? 02:37 gregorycu But yeah, most of those ref changes triggered inlining to occur 02:37 hmmmm rather, n is modified? 02:37 gregorycu Line 250 of src/mapblock_mesh.cpp 02:37 gregorycu (The first file listed) 02:38 gregorycu I should have called getNodeRefUnsafeCheckFlags 02:38 gregorycu At the moment it can get values from unloaded chunks, which is bad 02:38 hmmmm hmm 02:38 hmmmm ahh 02:38 gregorycu err... unloaded Nodes 02:38 hmmmm so the client extensively utilizes flags in voxelmanipulators 02:39 hmmmm from a server-side perspective, flags are useless in practice 02:39 hmmmm shouldn't that be ContentIgnoreNode? 02:39 n4x C++ is a language where writing high-level code is hard, and low-level code is basically written in a "subset" of it called C 02:40 gregorycu Yeah, it probably should 02:40 gregorycu I'll fix that too 02:41 gregorycu I actually had a massive secondary bunch of changes, but there wasn't enough bang-for-buck for me 02:41 gregorycu Too many changes for not enough gain 02:41 gregorycu Basically I just want to make safe changes that give us sizable perf improvements 02:43 hmmmm i'm quite shocked a number of those modifications actually produce gains 02:44 hmmmm we shouldn't be required to do such tedious micro-optimizing 02:44 hmmmm they told us that the compiler will take care of it all! 02:44 hmmmm what happened! 02:44 hmmmm they told us not to worry! 02:44 gregorycu lol 02:45 gregorycu I am interested to know what type of perf gains people get on different platforms 02:45 hmmmm here I am thinking I need to rewrite 3d noise functions using SIMD and NEON and here we can get significant performance gains by passing things by reference 02:45 VanessaE Don't worry, they said! The compiler is magic, they said! 02:46 hmmmm should just start passing things by reference 02:46 hmmmm fpth 02:46 Brains They were wrong... It is really the JVM/CLR/hot-fad-of-day! No, really! 02:46 hmmmm because the compiler is so obnoxiously slow and it keeps explicitly calling constructors when the state of the object is clearly and easily predictable at compile time 02:46 n4x the problem of C++ code is that it is too low-level to high-level optimizations and too high-level to do low-level optimizations 02:46 hmmmm =/ 02:47 n4x it's a bit of trying to do both things at once and doing both wrong 02:47 hmmmm shit like this man 02:47 hmmmm shit like this makes me want to work on gcc 02:47 gregorycu Don't work on gcc 02:47 hmmmm i know 02:47 gregorycu Work on clang 02:47 hmmmm gcc has no future 02:47 gregorycu Same yourself some sanity 02:48 Brains hmmmm: If you wait a little bit, you might get a chance to work on a gcc fork... One of those might be coming down the pipeline. 02:48 gregorycu Save 02:48 hmmmm Brains, nah I agree with gregory 02:48 hmmmm gcc is insane in several ways 02:48 gregorycu Clang is very exciting 02:49 gregorycu Not that I've looked into it much, just second hand 02:49 Brains Heh, that can be considered quite a polite phrasing of the gcc situation. 02:49 VanessaE [01-23 21:50] latest build still craps out though I got to see aghostly image of where I was. 02:49 VanessaE (offtopic, ish) 02:49 gregorycu By the way, if we were to start using C++11, we could do other perf improvements 02:49 hmmmm like what 02:49 gregorycu For instance, stateful allocators 02:50 gregorycu I had a look at a lighting issue someone was having 02:50 gregorycu And 25% (!) of the time was spent in std::set::insert 02:50 hmmmm in unlightNodes? 02:50 gregorycu Almost all of that was spent in allocating memory for a set node 02:50 hmmmm no offense but the lighting calculations are crap 02:51 gregorycu None taken, I agree 02:51 gregorycu But structures are low hanging fruit 02:51 hmmmm I simply never did optimizations on the map versions of the algorithm 02:51 hmmmm check out Mapgen::calcLighting() if you want to see a truly fast (but bulk) version of the same thing 02:52 gregorycu I will, I have a few things I'm working on at the moment 02:52 hmmmm I think Map::getNode* variants are a little too slow to use on things like this 02:52 hmmmm maybe we should be fetching whole mapblocks 02:52 hmmmm err, mapblock pointers 02:53 hmmmm instead of doing a sector lookup and then mapblock lookup within the sector and a whole bunch of checks at the same time 02:53 gregorycu The problem with that is you then have data shared across thread boudaries 02:53 hmmmm don't worry about synchronization.. 02:53 gregorycu I am very worried 02:53 hmmmm why 02:53 gregorycu Single player is very slow because of thread contention 02:53 VanessaE fwiw, I am attempting to get some info from MichaelEh about his crash 02:53 hmmmm you're envlocked 02:54 gregorycu I don't follow? envlocked? 02:54 hmmmm wait, huh? 02:54 hmmmm why would single player be slow due to contention 02:54 gregorycu Because that's what the profiler tells me 02:54 gregorycu Have you played SP lately? 02:55 hmmmm in a singleplayer world, Environment and ServerEnvironment are two separate structures 02:55 hmmmm each with their own locks 02:55 hmmmm the Client cannot cause contention on the Server and vice versa 02:56 gregorycu To be honest, I've only just started looking into it 02:56 hmmmm I play SP all the time and it seems fine to me. I heard Zeno say that 25% of the time is spent thread switching or whatever 02:56 gregorycu But SP is waaaaay more jittery than server + client 02:56 hmmmm need to check out the valgrind output 02:56 gregorycu I actually think it should be pretty high priority 02:57 gregorycu Because the first thing someone does when they download minetest, is start up singleplayer to take a look 02:57 hmmmm not sure I understand the point behind the suggestion of running the server in a separate process for SP 02:57 hmmmm since everything is separate 02:57 gregorycu No, I don't agree with that 02:57 gregorycu I agree with you in that regard 02:57 gregorycu Except to say, maybe things are not as separate as they should be? 02:57 gregorycu I don't know, i haven't looked at it yet 02:57 hmmmm a process is just a thread with its own memory space. if you don't touch eachother's memory, how is it any different 02:57 gregorycu You are correct 02:57 hmmmm that being said 02:58 gregorycu I suppose you get a guarantee by running it in a different process 02:58 hmmmm IF there is an instance where they share the same data stucture 02:58 hmmmm that's a bug and that's the thing which should be fixed 02:58 gregorycu What about settings? 02:58 gregorycu (just an example) 02:58 hmmmm yeah :/ 02:58 hmmmm that's true, in fact I think we just found our culprit 02:58 hmmmm that did not occur to me 02:59 hmmmm all that pressure on g_settings between client and server could be the cause 02:59 gregorycu I think our best bet is to actually namespace all of our globals into a Server or a Client namespace 03:00 hmmmm so instead of splitting things into separate proceses and adding more settings callbacks, why don't I write up the fast lock/wait free settings read mechanism 03:00 hmmmm this way we can share it and it'd be just as fast 03:00 hmmmm but i'd still rather not share it 03:00 gregorycu It's better not to share it 03:01 gregorycu Cause that simulates more accurately the client + server setup 03:01 hmmmm the global namespace sounds good 03:01 hmmmm but you're going to get pretty sick of typing "using namespace client" everywhere 03:01 hmmmm and then more discression needs to be applied when working inside header files 03:01 gregorycu I think it's worth it 03:01 hmmmm that ought to be tricky 03:02 gregorycu Yeah, it's kind of annoying there isn't a good solution for that problem 03:02 gregorycu As far as I know 03:02 hmmmm right 03:02 gregorycu Anyway, I have a few bugs I've committed to fix, then I want to take a look at why SP is slow for me 03:03 hmmmm gosh, I never felt SP being 'slow' 03:03 gregorycu I just thought that was how minetest was 03:03 gregorycu Then I joined a server 03:03 gregorycu And I was like: "wow, how fast is this" 03:04 gregorycu "The server thread must be the slow thing" 03:04 gregorycu Then i took a look at task manager and the server was hovering at about 5% 03:05 hmmmm well there is a reason for that which doesn't have to do with contention 03:05 hmmmm simply you're not running the serverthread 03:05 hmmmm you offload that other 50% or whatever SP runs at onto the remote server which you don't have a task manager for 03:06 gregorycu No 03:06 gregorycu I was running it local 03:07 gregorycu And the CPU for the server was 5% 03:08 gregorycu Sorry, I was misleading: "I joined a server" = "I started a server instance and joined it" 03:11 VanessaE hmmmm: did you see what MichaelEh said? 03:12 hmmmm ...no 03:12 VanessaE oh, well it's nothing much. I'm just having him try various settings to find a way to stop his crash. 03:13 VanessaE nothing so far works, even changing video drivers. 03:13 hmmmm erm.. 03:13 hmmmm what is the crash? 03:14 VanessaE it's windows 7 so it's just a "this program has stopped" sort of message, nothing in the logs. 03:14 VanessaE and he doesn't know how to use a debugger so little chance of finding the cause :-/ 03:14 hmmmm welp 03:14 hmmmm can't you walk him through how to use a debugger? 03:14 hmmmm no stacktrace makes this useless 03:15 VanessaE the only thing of substance was the RAM usage, about 520-ish megs (out of 4GB) and that no video driver works (even software)...and that 0.4.10 worked. 03:15 VanessaE crashes as soon as it starts to render the world 03:15 VanessaE well I could try to walk him through it, but someone will have to walk ME through it first, I don't know windows :) 03:16 chrisf collect the minidump if it's a build you've got symbols for somewhere? 03:16 VanessaE minidump? 03:16 VanessaE it's sfan5's latest build 03:16 chrisf like a *nix core dump, for postmortem debugging 03:16 VanessaE where will this minidump be located? 03:17 VanessaE yeah, I kinda figured that's what it was, didn't know windows produced those. 03:18 gregorycu (hmmmm, I update the PR with the change of static name you recommended, and also a bug fix to do with lighting) 03:19 chrisf ah, the process has to request one be made, so not useful to you without doing some plumbing 03:19 VanessaE fek. 03:19 VanessaE well checking anyway in case there is one. 03:19 chrisf worth adding the infrastructure to that to mt so you can solve this kind of thing 03:20 chrisf i think breakpad is the easiest way to wire it all up? 03:20 chrisf infrastructure for that * 03:20 gregorycu Yeah, I agree chris 03:21 chrisf of course this is just drive-by advice so... meh ;) 03:23 gregorycu Easier said than done 03:24 VanessaE well that's out, he says his machine's not even producing a minidump dir (C:\windows\minidump or C:\winnt\minidump as I read it) 03:25 gregorycu Ahh, nightmare fuel 03:29 VanessaE I'm attempting to have him install win 7 SDK to get windbg 03:29 VanessaE (from here: https://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx) 03:31 VanessaE and...he's giving up for the night :-/ 03:32 gregorycu Hello there Zeno 03:32 VanessaE \o zenop 03:32 VanessaE \o Zeno` 03:32 Zeno` O/ 03:47 hmmmm a minidump would be helpful but only if he were given an -O0 build 03:47 hmmmm and we'd need to know the very very specific exact version of minetest used 03:47 VanessaE he'd be using 1702c34 03:48 Zeno` which version is he using? msvc or mingw? 03:48 VanessaE if he's using the build I told him to use 03:48 VanessaE https://sfan5.pf-control.de/minetest-builds/?f 03:48 VanessaE he's tried 0.4.11-release also 03:48 VanessaE and a couple of dev builds between there and 1702c34 03:49 Zeno` I can try and replicate it I guess; but I used TDM-gcc (since I can't seem to get mingw to work and it's not maintained anymore by the looks of it anyway) 03:49 Zeno` It's still gcc so I might be able to replicate the issue 03:51 Zeno` If nothing happens in the meantime I'll do that in an hour or so 03:56 VanessaE got another user with a crash issue, very similar to MichaelEh's. he has 6GB of RAM (he only needs 2 for this), using a win32 build from commit 63867b1 03:56 VanessaE (except it hangs rather than crashing, but the display is the same - blank playfield, save for the player's wield and HUD) 03:57 puhfa hey guys, what is this sneak_glitch override shadowninja mentions in a issue report? 03:57 puhfa i was going to file one myself but wont if it is a known issue (altho i couldnt find it in github) 03:58 VanessaE puhfa: sneak+jump can be used to climb zig-zagging blocks 03:58 chrisf VanessaE: is mt built to be 3GB-aware? 03:58 chrisf (for 32bit windows builds) 03:58 VanessaE good question, but should that matter here? 03:59 puhfa VanessaE: thanks 03:59 VanessaE even with the mesh cache turned off, and thus using 1.5 GB, it still crashes. 03:59 chrisf well, if not, then needing 2G is a recipe for heap exhaustion 03:59 VanessaE puhfa: https://i.imgur.com/PP27rSg.png 03:59 hmmmm instead of guessing why not just get him using an -O0 build, get a minidump, and then see for sure 03:59 hmmmm i hate it when people speculate when it's so easy to check 04:00 VanessaE hmmmm: he's already signed off, so I'm seeing what we can get from the other guy now. 04:00 VanessaE (he being MichaelEh, the first reporter) 04:01 puhfa VanessaE: yes, i was aware of that. is that possible with sneak_glitch override disabled or enabled? 04:01 VanessaE I guess disabled allows climbing. 04:01 puhfa ok 04:18 puhfa well that was quick 04:19 gregorycu That's what she said 04:20 puhfa oh you 04:20 gregorycu ;) 04:21 VanessaE ha 04:21 Zeno` I wonder if it has anything to do with the bug I just found 04:22 Zeno` doubt it 04:22 Zeno` making PR 04:24 Zeno` #2189 04:24 ShadowBot https://github.com/minetest/minetest/issues/2189 -- Fix unitialised variable occassionally being used by Zeno- 04:24 Zeno` bbiab 04:33 gregorycu VanessaE: I think I have a fix for #132 04:33 ShadowBot https://github.com/minetest/minetest/issues/132 -- Jump at node edge doesnt work 04:33 gregorycu There is code here that attempts to make it easier to jump onto a node 04:34 VanessaE oh good 04:34 gregorycu Anyway, the code adds a bit of tolerance to the collision detection 04:34 gregorycu That tolerance is the "dead zone" where you can't jump 04:35 gregorycu I've removed the tolerance, which fixes the bug, but I think it means it's harder to jump onto nodes 04:35 gregorycu I'm trying to figure out if that's the case 04:42 hmmmm alright, guys 04:42 hmmmm I have a good compromise (I think) between storage space and other things 04:43 hmmmm we repurpose param1 completely and store node lighting separately 04:43 hmmmm instead a mapblock will have 3 modes 04:43 hmmmm exposed to sunlight, no light, or "has one or more light sources" 04:44 hmmmm the buffer of light values will only exist if it's the last of the three states 04:45 hmmmm this light value buffer could be a 2kb bitmap for all 4-bit light values in the block 04:45 hmmmm which the mapblock will manage a pointer to 04:46 hmmmm it will not be transferred over the network or saved, but upon block activation it will be computed 04:46 hmmmm this way you can have your O(1) lightval lookups 04:46 hmmmm and I can have my light savings 04:48 hmmmm since a mapblock containing at least one light source is a rather rare event, it shouldn't be too harsh of a memory penalty 04:48 VanessaE you know, that's not so bad. 04:49 VanessaE in practice, only about 25 percent of the explored top surfaces of my maps seem to have actual light sources. 04:49 hmmmm as for TrueColor lighting, that's going to consume 6 times as much memory per mapblock that does have a light source though 04:50 hmmmm but still WAY WAY WAY WAY less than if you were to double the size of a MapNode 04:50 VanessaE didn't I suggest some time ago a flag-and-expand scheme? :) 04:50 hmmmm okay so maybe we could have 4 mapblock light states, the three i listed above and then an RGB format lighting 04:50 VanessaE you're just doing it at the block level (which never occurred to me) 04:50 hmmmm your flag-and-expand scheme as explained was variable length encoding 04:51 VanessaE right, and the other four bits in param1 just stores the total light value like it already does? 04:51 hmmmm which is completely implausible for minetest 04:51 hmmmm at the block level it's fine 04:51 hmmmm but not nodes 04:51 hmmmm no, param1 will be completely disused after this 04:51 VanessaE hm, 6 bits actually 04:51 hmmmm light will be a property of the block 04:51 VanessaE oh right, the bitmap 04:51 VanessaE derp 04:51 VanessaE what are you gonna do with the rest? 04:52 hmmmm for what it's worth, if you compromise for 8 light levels instead of 16, you could save 512 bytes per grayscale light bitmap 04:52 hmmmm it can be used for Various Things(tm) 04:52 gregorycu Is it worth it? 04:52 hmmmm one in mind is a full 8 bit color palette index for colorlike nodes 04:52 VanessaE I've no qualms about total number of light levels, in practice in a mod, there's no appreciable difference between say 11 and 12. 04:53 hmmmm and another thing could be to store node damage (i.e how much it's been dug) 04:53 hmmmm I know 04:53 hmmmm that's why I wanted to use only 3 bits for light 04:53 hmmmm :( dammit 04:53 Zeno` merging 2189 04:54 hmmmm Zeno`: looks good 04:54 hmmmm so here we get: 04:54 hmmmm memory savings 04:54 gregorycu VanessaE: Do you make your own builds? 04:54 VanessaE hmmmm: in fact for backward compat, you could easily just double the light value when passing it back to Lua in the various get-light calls 04:54 hmmmm more room for other node attributes 04:55 hmmmm RGB lights are plausible 04:55 gregorycu I would like you to try my fix 04:55 VanessaE gregorycu: I run linux, so I just ... build, but I don't distribute the bins 04:55 hmmmm but on the downside with this method, I can't expand light range 04:55 hmmmm unless I expand node storage 04:55 gregorycu Ok, sweet 04:55 VanessaE oh sure, I can try that if you want 04:55 hmmmm or wait no, I can still do that 04:55 gregorycu I have a fix, but I want a few people to try it, and see if there are uninteneded side effects 04:56 hmmmm we can expand light range right *now* in fact, if we wanted 04:56 VanessaE hmmmm: well light *range* is just a matter of how far you want to stretch the value, not necessarily how HIGh the value goes. 04:56 hmmmm yeah 04:56 hmmmm we can interpolate within the range. 04:56 VanessaE yep 04:56 hmmmm but this makes it confusing 04:56 hmmmm okay so we have two colliding light beams 04:57 hmmmm one will be from a light source with a range of ... I guess 16 04:57 hmmmm the other one would have a range of 20 04:57 hmmmm the whole trick here is that the light beam doesn't always need to decay by 1 each node 04:57 hmmmm for unspreadLight() all you'd need to do is change a condition to stop at >= to > 04:58 gregorycu VanessaE: Are you able to modify collision.cpp, lines 547 - 550 and delete the -d and +d 04:58 gregorycu And then compile, run, and try to repo? 04:58 VanessaE gregorycu: sure, one moment. 04:59 gregorycu I'm interested in two things: does it fix the issue, and does it make jumping unto nodes more difficult/different 04:59 hmmmm some duplicate light values are going to get pidgeonholed but the problem to solve is how do we not make light seem to clump up at specific distances 04:59 gregorycu Thank you, no rush 05:01 VanessaE hmmmm: well if I were doing it the brute force way, on a 2d map, something like new_level = previous_level + last_source / current_distance 05:01 VanessaE iterating through each light in the scene and "drawing" around that source out from 0 to the max throw distance.. 05:02 VanessaE you get the idea. just something really stupidly simple :) 05:02 hmmmm yeah but how are you going to perform unspreadLight() now :( 05:02 VanessaE that part I don't know :-/ 05:02 hmmmm with 3 or more light sources 05:03 VanessaE gregorycu: there's a small jitter when I jump, but it does seem to fix the issue 05:03 gregorycu jitter... 05:04 gregorycu Ok, back to the drawing board 05:04 VanessaE gregorycu: a slight..."bounce"? 05:04 VanessaE hard to describe it 05:04 Zeno` yeah I noticed that slight bounce as well 05:04 gregorycu A bounce, or just getting pushed up slightly? 05:05 VanessaE a bounce. 05:05 gregorycu urgh 05:05 Zeno` no words to describe it! 05:05 Zeno` it's a thing 05:05 Zeno` the thingy effect 05:06 gregorycu I'm going to have trace my y position 05:06 gregorycu I can't notice it 05:06 Zeno` gregorycu, that's because you're used to jumping up and down (being a monkey and all) 05:07 Zeno` :3 05:07 gregorycu That's racist 05:07 VanessaE hmmmm: damn it, you're forcing me to look at the code. 05:07 VanessaE :) 05:07 gregorycu Jokes 05:07 gregorycu Oh, the pic 05:07 hmmmm gregory is an abbo? :p 05:07 gregorycu Right :P 05:07 gregorycu lol, I am actually partially abbo 05:07 gregorycu Like 1/32 05:07 Zeno` I thought you were a monkey with a hat 05:07 Zeno` MonkeyHat Linux 05:08 hmmmm lol hahaa 05:08 hmmmm I thought the same thing when I saw the thumbnail of his avatar before i looked closer 05:09 gregorycu God-damnit 05:09 gregorycu Could the bob be the camera? 05:09 VanessaE hmmmm: *shrug* I got nuthin', man. :P 05:10 hmmmm Zeno` do you have the link to that valgrind output again 05:10 Zeno` hmmmm, which output? 05:10 hmmmm the one with the slow SP 05:10 hmmmm I think that's caused by contention on g_settings 05:10 Zeno` oh, it's in an open issue somewhere. I'll find it 05:11 Zeno` #2145 05:11 ShadowBot https://github.com/minetest/minetest/issues/2145 -- Multi-second lag in default singleplayer game 05:11 hmmmm god damn 05:11 hmmmm multi-second lag :( 05:11 Zeno` see that pic? 05:11 Zeno` that's not really "lag" per se. it's dtime 05:12 hmmmm ok 05:12 hmmmm it's just so depressing because after all the time and effort you put into minetest it's still FUBAR 05:12 hmmmm engineered from the ground up to be slow 05:12 Zeno` the person who made the mod was confused. Although there is some correlation between TTL and dtime of the server 05:13 Zeno` I know :( 05:13 Zeno` but it's fast everywhere except SP :) 05:13 gregorycu VanessaE: If you still have that change, can you go into 3rd person view and tell me if the... bounce looks like it happens 05:13 gregorycu Or if it's just a camera thing 05:13 VanessaE already reverted it 05:13 Zeno` TTL? err RTT I meant 05:14 VanessaE lemme put it back in, one moment. 05:14 VanessaE I see my player jitter vertically relative to the camera. 05:17 kahrl trivial fix for an uninitialized variable I saw in valgrind: https://gist.github.com/kahrl/ad1c5908ce3e40201101 05:17 kahrl pushing ^ in a few minutes 05:18 Zeno` it's hard to make sense of the SP profiles 05:18 Zeno` with everything mixed in as it is 05:18 Zeno` I had a few here and they were similar to Wayward_One's 05:19 gregorycu Thank you 05:36 kahrl gregorycu, question about your last commit: is m_fogEnabled initialized anywhere in GameGlobalShaderConstantSetter? 05:36 kahrl valgrind reports it 05:37 kahrl I don't know much about that code, hence my question 05:37 gregorycu When the setting is set for the first time, the callback fires 05:37 gregorycu Let me double check 05:38 gregorycu Maybe it's a race condition 05:38 kahrl what if the setting is set before the callback is registered? 05:40 gregorycu bad greg 05:40 kahrl also, is the callback ever unregistered when GameGlobalShaderConstantSetter is destructed? 05:41 gregorycu Wouldn't the lifetime be bound the same way settings are? 05:41 gregorycu I'll take a look, these sound like legitimate concerns 05:41 kahrl g_settings is global 05:41 kahrl GameGlobalShaderConstantSetter is constructed and destructed per game 05:42 kahrl iiuc 05:42 gregorycu But the settings are per-game? Right? 05:42 kahrl no 05:42 kahrl per process 05:42 gregorycu ok 05:42 gregorycu Give me 10 minutes, I need to eat something 05:43 kahrl sure 05:43 kahrl don't panic ;) 05:47 gregorycu Too late 05:48 Zeno` I find it hard to believe that there is an 8% improvement in the loop due to making a map lookup :p 05:48 Zeno` Game::run() that is 05:49 gregorycu It's not the map lookup 05:50 gregorycu It's the converting "true" to boolean true 05:50 gregorycu Along with the map lookup 05:50 Zeno` and that consumes 8% of game::run() ? 05:50 gregorycu Yep 05:50 Zeno` we need to start from scratch in that case 05:50 gregorycu One moment, i think I have some old profiling data 05:51 VanessaE hmmmm: I've been wondering about the whole param1 thing.... just how many mods out there even DO anything with param1 other than paramtype="light" anyway? 05:51 Zeno` not even spreadLight() etc use 8% 05:52 Zeno` VanessaE, if they do would it be undefined behaviour? 05:52 VanessaE good question 05:52 Zeno` we need to write the Minetest Scripting Standard 05:54 VanessaE grep -ir paramtype |grep -v light |grep -v paramtype2 --> three results in my entire mods tree. two of those are bogus, one is paramtype = "facedir_simple" 05:54 Zeno` If we had The Standard we could just say "hey, you relied on undefined behaviour. Bad luck! Next!" 05:54 Zeno` So, I think you should write The Standard 05:54 kahrl "If you don't use these functions, you can use them to store arbitrary values. [...] param1 is reserved for the engine when paramtype != "none"" -- doc/lua_api.txt 05:54 Zeno` hmm 05:55 VanessaE out of 1749 paramtype = foo references. 05:55 Zeno` well it's not undefined then :( 05:55 VanessaE hrm 05:56 gregorycu Where can I upload images? 05:56 Zeno` Although perhaps we draft and ratify The Standard as part of the next iteration 05:56 VanessaE gregorycu: tinypic? 05:57 VanessaE wait, WHO should write The Standard? 05:57 Zeno` I'm getting those valgrind errors as well, btw (gregorycu) 05:57 Zeno` VanessaE is writing it apparently 05:57 VanessaE no fucking way 05:57 VanessaE ShadowNinja should write it 05:57 Zeno` Well, the Standards Committee will write it 05:58 VanessaE insert "1776" "You Should Write It" reference here. 05:58 gregorycu http://tinypic.com/view.php?pic=349e14j&s=8 05:59 Zeno` which column is inclusive cost? 06:00 gregorycu 3rd number column 06:00 Zeno` that's not relative to parent? 06:01 Zeno` anyway, I only mentioned it for no reason at all :) 06:01 gregorycu No, it's relative to overall 06:01 Zeno` hmm ok 06:01 gregorycu 3.65 / 37.94 06:01 gregorycu To find relative 06:02 hmmmm VanessaE, any mod that reads the light value 06:02 hmmmm so mobs and plantlife 06:04 VanessaE hmmmm: sure but those are API calls, which can be faked. I'm talking about setting it in a node def. 06:05 VanessaE s/fakes/emulated/ 06:05 gregorycu I've just noticed that the settings callback stuff isn't properly locked... 06:06 Zeno` where? 06:07 gregorycu Settings::registerChangedCallback 06:07 gregorycu Comepare to Settings::doCallbacks 06:07 gregorycu doCallbacks locks the map before access, registerChangedCallback does not 06:07 gregorycu bb in 5 06:13 gregorycu back 06:14 Zeno` something is wrong 06:15 Zeno` I used to get 1-3 fps when profiling the client using callgrind. Now I get 0 06:17 gregorycu More calls? 06:17 kahrl -O0 vs. -O1? 06:17 Zeno` I profile using -O3 06:17 Zeno` (callgrind that is... for valgrind/memcheck I use -O0) 06:18 Zeno` I dunno gregorycu... it hasn't been *that* long since I was profiling nearly every day 06:18 * Zeno` makes sure something else in his setup hasn't changed 06:20 hmmmm hey Zeno? where is it that you see 25% of cpu time is being taken up by thread switching in that callgrind output 06:21 Zeno` cycle 23 06:22 Zeno` 25%? 06:22 Zeno` it's 16 or something 06:22 * Zeno` looks 06:24 hmmmm that says like 69.82% 06:24 Zeno` Wow! Zeno`, lag is down to about 5 seconds now :D 06:25 hmmmm :D ? as of gregory's enable_fog cache? 06:25 Zeno` no... 06:25 Zeno` I can't find what I asked him to do 06:25 Zeno` lol 06:26 Zeno` Wayward_One, can you make sure that enable_mesh_cache = true is NOT in your minetest.conf? 06:26 Wayward_One set enable_mesh_cache = false 06:26 Wayward_One lol 06:26 Zeno` I asked you to do that Wayward_One because yesterday I noticed that I got better in-game performance without it 06:27 Zeno` I suspect that SP uses ~1.6GB for the "cache" 06:27 Wayward_One wow 06:27 Zeno` so maybe there is swapping occurring 06:27 Zeno` in a client only game connecting to VE-S it uses ~800MB 06:27 Zeno` wait... server doesn't create the cache (I don't think?) 06:28 Wayward_One i don't have swap set up btw 06:28 Zeno` anyway I suspected it might have been a memory issue 06:28 Zeno` so maybe check mem usage with and without that setting 06:32 hmmmm how did you determine that "" is a thread switch? 06:32 Zeno` traced it 06:32 Zeno` actually 06:32 Zeno` looking at it now it looks more like a driver thing 06:32 * Zeno` is on painkillers and doing too many things at once :( 06:33 * Zeno` closes about 20 windows 06:34 Zeno` http://i.imgur.com/eito8aF.jpg 06:34 hmmmm yeah 06:34 hmmmm the crappy part about this output is that it keeps conflating all the different threads together 06:34 hmmmm i'm finding it very difficult to make sense of 06:34 Zeno` that's what I meant earlier 06:34 Zeno` when I said it was hard heh 06:35 hmmmm we can't be the first ones to stumble upon this problem 06:35 hmmmm maybe there's some sort of annotation option 06:35 hmmmm to sort by tid 06:35 * Zeno` checks callgrind docs 06:36 hmmmm well, to be sure, let's find a function that we know for sure enters into a wait 06:36 hmmmm like JMutex.Lock() 06:37 hmmmm hum.. the call graph of that one says that whatever that is calls ScopeProfiler::~ScopeProfiler and Settings::get() 06:37 hmmmm no comprendo 06:38 hmmmm you know what I just realized, like right now? 06:38 Zeno` nope 06:38 Zeno` I lost my mind-reading powers after the accident 06:38 hmmmm it's going to be a lot tougher to make settings fetches atomic thanks to my cool settings group 06:39 hmmmm dammit Zeno` 06:39 Zeno` what? 06:39 hmmmm you were cooler when you were able to engage in teleapthy with me 06:39 Zeno` heh 06:40 Zeno` --separate-threads=yes 06:40 Zeno` I'll see if that actually works 06:42 gregorycu Your cool settings group? 06:43 hmmmm yep 06:43 hmmmm I used to have really cool settings groups 06:43 gregorycu I don't even know what that means 06:43 gregorycu By the way, does enabling and disabling fog actually work for anyone? 06:43 Zeno` does for me 06:44 hmmmm lol I'm just acting dumb 06:44 Zeno` well it used to. Haven't checked today ;) 06:44 gregorycu Ok 06:45 Zeno` drawtime=210 lol 06:45 Zeno` 1007! 06:46 hmmmm 2302! 06:46 hmmmm Hrmm 06:46 Zeno` oh it just keeps going up 06:46 Zeno` stabilised at ~1500 06:46 hmmmm 210 seconds? 06:46 hmmmm I thought all times displayed were in seconds 06:46 hmmmm or at least that's what celeron said 06:46 Zeno` I dunno, but that's what it's saying 06:46 hmmmm ms then 06:47 hmmmm well 06:47 hmmmm if I do implement lockfree fast settings, they can't be namespaced 06:47 Zeno` this profile is going to be useless. I can't even move 06:47 hmmmm there goes the entire idea of adding a "client" and "server" namespace to all the settings 06:49 gregorycu Huh? 06:49 gregorycu Lockfree fast settings can't be namespaced? 06:49 hmmmm well it can't be namespaced by using a settings group, which is what they were primarily implemented for 06:50 gregorycu Out of interest, how were you going to implement lock-free settings? 06:51 hmmmm atomically swap string pointers instead of setting std::string contents 06:51 Zeno` ohh 06:51 gregorycu *shrug* 06:52 gregorycu What are we trying to solve here 06:52 Zeno` split up by threads... nice 06:52 gregorycu How often do settings change? 06:52 hmmmm not very often 06:52 gregorycu Look, I'm kind of of the option that there should ONLY be a callback mechanism then 06:52 hmmmm well 06:52 gregorycu ie. You can't query, only register a callback 06:53 gregorycu The first time you register, it will fire, and give you the value 06:53 gregorycu But beyond that 06:53 hmmmm that certainly is a way to solve the problem 06:53 hmmmm but you have to modify a lot more code 06:53 gregorycu That does push the synchronization requirement onto the consumer 06:54 hmmmm my idea is to remove the need for locking with settings fetch 06:54 hmmmm and make it a very lightweight operation in general, so there IS no need for each component to maintain a cache 06:55 hmmmm and to speed up all of the other settings that currently don't maintain a cache (which is a lot of them) 06:55 gregorycu There still will be a map lookup... 06:55 hmmmm nope 06:55 gregorycu No? 06:55 hmmmm I'd store it in a vector 06:55 gregorycu There are two factors here 06:56 gregorycu There is the synchronization factor, and there is the hardly-ever-changing factor 06:56 gregorycu You're trying to fix the thread contention issue, I'm trying to fix the general slowness issue 06:56 hmmmm well this would help both 06:57 hmmmm this would essentially turn it into fetching a value from an array 06:57 hmmmm and in the case where it is being written to, well, it's written atomically so there are no malformed reads ever 06:57 gregorycu Well, it's not an index lookup 06:57 hmmmm as-is 06:57 gregorycu It's a pretty fast O(n) operation though 06:58 gregorycu How often is it written to? Not very often... 06:58 gregorycu Oh, and the other thing I think that needs to be thought about 06:58 hmmmm this would require an interface change but one that can be solved by somehow morphing text in the format of g_settings->getX("foobar") to g_settings->getX(CSET_FOOBAR) 06:58 hmmmm I'm not very good with sed so 06:59 gregorycu Should settings be mandated to only change at the start of a render loop 06:59 hmmmm I think that makes sense 06:59 gregorycu As in, can you do half your render, and then a settings change, and the other half of the render is different? 06:59 gregorycu Render, or tick... whatever 07:00 hmmmm but at the same time like what happens if you change the texture filtering 07:00 gregorycu And it's half way through the loop? 07:00 hmmmm only newly generated meshes would use the filtering set 07:00 gregorycu Ahh ok 07:00 gregorycu Well, how often do settings change? 07:00 gregorycu lol 07:00 gregorycu What are we optiming here 07:00 hmmmm like i said - not often 07:01 hmmmm we are optimizing the read case 07:01 gregorycu optimising 07:01 hmmmm the read case can't be done quickly without removing the lock, and you can't remove the lock without using an atomic write 07:01 hmmmm on most architectures I realize this isn't a problem, but you can't rely on that.. 07:02 gregorycu How about this, a cache, completely lockfree 07:02 gregorycu With the exception of a queue, and at a certain time, you can nominate the queue to be applied to the cache 07:02 gregorycu The queue is a queue of changes 07:03 gregorycu So, you get your "once a render loop" changes 07:03 gregorycu And the only think you need to worry about locking is when harvesting the queue 07:03 Zeno` I implemented that a few months ago 07:03 Zeno` the settings got updated every server (or client) tick 07:03 Zeno` updated/checked 07:04 Zeno` but it was a bit messy the way I did it 07:04 Zeno` I have a better way 75% finished 07:04 Zeno` But, honestly, most of the things that were causing slowness are now cached 07:05 Zeno` calls to Settings in the client consume... let me check 07:05 gregorycu Unless the settings are the cause of contention 07:06 Zeno` http://i.imgur.com/xBwf8Rk.jpg 07:06 Zeno` bugger all CPU 07:07 Zeno` which is why I'm taking so long with the callback class 07:07 hmmmm gregorycu: it is 07:08 hmmmm that's literally the only possible source of contention between Server and Client 07:08 gregorycu ok 07:08 hmmmm because it's the only data structure shared between them 07:08 Zeno` I have a nice profile split up into threads 07:08 hmmmm coo 07:08 hmmmm let's see it 07:08 Zeno` Can't make sense of it though lol 07:08 hmmmm :( 07:08 gregorycu I'm fairly certain that there should be two settings objects 07:08 Zeno` I'll upload it somewhere 07:09 gregorycu In a regular Client + Server they are not the same object 07:09 gregorycu Why is single player different 07:09 gregorycu Single player should just be an emulation of Client + Server 07:09 hmmmm gregorycu: you could lock-in settings changes per render loop by doing something like this, I reckon: 07:10 hmmmm bool enable_fog = g_settings->get(CSET_ENABLE_FOG); bool do_other_thing = g_settings->get(CSET_OTHER_THING); ... 07:10 hmmmm at the beginning of the render loop 07:10 hmmmm =D 07:10 Zeno` hmmmm, https://www.dropbox.com/s/9y64ks4xs56pqmr/spgame.tar.gz?dl=0 07:11 Zeno` it's only a short profile. I'll make a larger one later, I just wanted to see if I'd be able to interpret these results first 07:11 gregorycu hmmmm: But then you have to pass around those guys evertwgere 07:11 gregorycu everywhere 07:11 hmmmm what do you mean pass them around everywhere 07:11 gregorycu And for sure, someone will query the settings directly 07:11 hmmmm oh 07:11 hmmmm yeah well 07:11 hmmmm even so, it's plenty cheap 07:11 gregorycu Anyway, I'm not saying it's a hard requirement 07:11 hmmmm it's one of those things nice-to-have 07:11 gregorycu Just saying maybe it's desirable 07:12 gregorycu In any case 07:12 gregorycu I think we are going about this the wrong way 07:12 hmmmm hrmm 07:12 gregorycu Because there MUST already be a synchronization mechanism between Client + Server 07:13 hmmmm and of course, we need to guess which thread each callgrind output is 07:13 gregorycu How else do remote servers set settings in the client? 07:13 hmmmm they don't 07:13 Zeno` well there are only 4 main ones 07:13 Zeno` in KCachegrind they're easy enough to see :) 07:13 gregorycu So, the set of settings between client and server are different? 07:13 hmmmm gregorycu: yes 07:13 gregorycu So, shouldn't they be in different containers? 07:13 hmmmm sure.. 07:14 gregorycu Game settings and client settings 07:14 hmmmm but that only solves the contention issue 07:14 gregorycu Right 07:14 hmmmm we can kill two birds with one stone by doing this 07:14 hmmmm and by the time we're done talking about it, it could already be coded 07:14 hmmmm could've* 07:14 hmmmm could've been* 07:14 Zeno` thread 6 seems to be connection thread 07:14 gregorycu We talk about it now so when people ask why we did it the way we did it, we have good answers 07:14 Zeno` thread 9 emerge 07:14 Zeno` thread 10 mesh update 07:15 hmmmm I had a really stupid "deferred thing get" mechanism in 0.4.9 that I called the NodeResolver 07:15 gregorycu I have a question 07:15 hmmmm reminds me a lot of this situation 07:15 gregorycu Are some settings stored against the world? 07:15 hmmmm yes. 07:16 hmmmm they're stored in map_meta.txt 07:16 gregorycu And that gets loaded into g_settings on world load? 07:16 hmmmm nope, they override what g_settings set the parameters to 07:16 gregorycu They override defaults? 07:16 Zeno` is the server even in a thread? 07:16 hmmmm Zeno`: lol, yes 07:16 Zeno` oh, thread 6 07:17 Zeno` sorry, I've never tried this split profile approach before :) 07:17 gregorycu *sigh* I don't really care that much, but I still don't like it how client and game settings are just all chucked together 07:17 gregorycu But I'll be quiet now 07:17 hmmmm gregorycu, no it's like: active_parameters.apply(g_settings); active_parameters.apply(world_specific_settings); 07:18 Zeno` lol, I told you that profile would be useless 07:18 Zeno` it never got out of send/recieve data (and I did not turn instrumentation on until the game was up and running!) 07:19 Zeno` well, maybe not so useless... it was running for about 10 minutes with instrumentation on 07:19 hmmmm heh 07:19 hmmmm I want to see the EmergeThread 07:20 Zeno` seems to be thread 9 07:20 Zeno` the one with -09 07:21 hmmmm yep 07:22 hmmmm I'm not sure I'm understanding the results correctly 07:22 hmmmm so for example, on the emergethread output, for CNodeDefManager::getId() 07:22 hmmmm the all callers tab tells you all of the functions that called this, and how much each percentage they make up of the calls? 07:23 hmmmm (well, execution time) 07:23 Zeno` 35% 07:23 Zeno` yeah 07:23 Zeno` you need... umm 07:23 hmmmm what is 35%? 07:23 hmmmm err oh 07:24 hmmmm I'm not talking about percentage relative to the entire execution 07:24 hmmmm in any case that figure of 35% sounds really shocking. so I'm trying to find out which functions call it the most 07:24 Zeno` well it was called 203962362 times 07:25 hmmmm now in All Callers, it has a whole bunch of 100.00 %s 07:25 hmmmm but then it has two 22% and then one 0.12% 07:25 Zeno` mostly by correctBlockNodIds 07:25 hmmmm aren't they supposed to add up to something? 07:25 Zeno` how are you viewing the results? 07:25 Zeno` just as text? 07:26 hmmmm no, in kcachegrind like you are 07:26 Zeno` click relative to parent at the top 07:27 hmmmm there's still ~87% missing 07:27 hmmmm that helped for the bottom window with the Ir and Ir per call 07:28 Zeno` All callers 07:28 hmmmm yes that's where I am right now 07:28 Zeno` mine add up 07:28 Zeno` to the total inclusive cost 07:28 Zeno` maybe there is something in settings that I have different 07:29 hmmmm hrmm 07:29 hmmmm for some reason it's as if I'm missing several 07:30 Zeno` dunno why :/ 07:31 Zeno` BUT I would not take those results too seriously; if you look at the other threads it never got around to doing much at all 07:31 hmmmm yeah 07:31 hmmmm I can tell that 10 blocks got generated 07:31 Zeno` so it's 35% of nothing 07:31 hmmmm err.. 10 chunks 07:32 hmmmm most of the ndef->getId() happened when loading blocks from the db... that part literally can't be helped, no way to improve it 07:32 hmmmm aside from improving the storage structure 07:32 Zeno` I'll let it run for a few hours tonight and /ms you a link 07:32 hmmmm well 07:32 Zeno` I can't believe how slow it is (profiling SP game that is) 07:32 hmmmm I'm not TOO interested 07:33 Zeno` Well, I am. So I'll paste a link somewhere anyway :) 07:33 hmmmm how do I fix the paths for missing files in the source code tab? 07:34 Zeno` don't think you can :( They're generated by -g AFAIK 07:35 Zeno` for Wayward_One's I setup a sym link (yuck) 07:45 hmmmm wow =/ 07:45 hmmmm 99.25% of execution time spent loading a block is spent doing std::map lookups 07:46 Zeno` oops 07:46 Zeno` http://i.imgur.com/eXnPtJq.jpg 07:46 Zeno` ^--- I meant to post that before 07:46 hmmmm that's just sad... but it's too bad callgrind doesn't tell you how much the absolute time spent is, so you can't figure out how long the loads took 07:46 Zeno` you can get absolute time I think... somehow 07:47 Zeno` but probably have to re-profile 07:47 hmmmm that would be cool to check for lock contention as well 07:47 hmmmm time to acquire != number of instructions executed :p 07:47 hmmmm which is why I was saying your conclusion that 25% of the time is being spent on thread switching sounds wrong 07:48 Zeno` maybe helgrind does that... never looked at it 07:48 hmmmm i thought that was for catching race conditions 07:49 Zeno` dunno. Haven't read what it can do 07:49 Zeno` valgrind checks for memleaks 07:50 Zeno` + other stuff :p So maybe helgrind has + other stuff also 07:51 Zeno` it's got "Inconsistent Lock Orderings" 07:51 Zeno` dunno if that'd be helpful 07:52 hmmmm yeah, a longer run with callgrind would be very helpful 07:52 hmmmm possibly with mapgen v5 too 07:53 Zeno` I can make longer runs easier just for server or client... it's only singleplayer that takes so @*$(@@*$(@ long 07:53 Zeno` I'll run it for maybe 1 hour tonight though 07:54 hmmmm hem 07:54 Zeno` and see how that looks; if it's stupid, I'll run for 2 07:54 hmmmm hrm* 07:54 Zeno` maybe I'll just run for 2 07:54 Zeno` save have to waste an hour if an hour is not long enough 07:55 hmmmm you know, writes to settings are rare 07:55 Zeno` very 07:55 hmmmm Zeno`, try removing locking from Settings calls 07:55 hmmmm and just see 07:55 hmmmm if SP runs as smooth as multiplayer 07:56 Zeno` reads are pretty rare as well 07:56 Zeno` but I will do it 07:57 Zeno` wait, reads are not locked anyway :) 07:57 hmmmm erm.. they're not..? 07:57 hmmmm they most definitely are 07:58 Zeno` yes 07:58 Zeno` didn't notice they all went back to Settings::getEntry 07:59 hmmmm for what it's worth, we can do a small optimization by unlocking before we go to look up in m_defaults 08:01 Zeno` well I can move at least 08:03 Zeno` based on max_lag it does seem to make a difference. And it *seems* smoother 08:03 Zeno` I'll try to work out a way to quantify it 08:05 hmmmm hey whaddya know 08:05 hmmmm from what you said though it doesn't seem like it's all the way as good as running in separate processes 08:06 hmmmm we should figure that part out 08:06 Zeno` oh yeah, it's been like that for a long time 08:06 Zeno` which is why I never noticed SP was slow 08:06 Zeno` because I never ran SP games that way heh 08:09 Zeno` hmmmm, https://www.dropbox.com/s/xo23l2e768ljy1w/spnosettinglocks.tar.gz?dl=0 08:09 Zeno` I didn't bother separate threads, and that's a very short run again 08:09 Zeno` The profile looks quite different to my earlier ones though 08:09 Zeno` anyway, in a hurry! 08:10 Zeno` cyas 08:10 hmmmm bye 08:15 gregorycu ffs 08:16 gregorycu Zeno, why is git so hard? 08:16 gregorycu https://github.com/gregorycu/minetest/commits/Settings-Fixes says I am two commits ahead 08:17 gregorycu Even though one of the two commits has already been merge to master 08:17 gregorycu https://github.com/minetest/minetest/commits/master 08:17 gregorycu "Make the GameGlobalShaderConstantSetter use the settings callback " 09:09 nrzkt 26 ? yesterday is was 29 09:10 gregorycu ? 09:10 gregorycu TENATIVE RELEASE DATE: 2015-01-29 09:10 nrzkt oh, i think it was old message not updated :p 09:10 nrzkt it's good now, sorry 09:24 nrzkt WTF bug 09:24 nrzkt i can cause an assert on any server with a modificated client xD 09:30 gregorycu Nice bro 09:31 * cheapie hands nrzkt an empty bug report to fill out 09:31 nrzkt i don't do a bug report 09:31 nrzkt i'll do a PR when i handle this throw which cause server to stop 09:32 cheapie That works too. 09:32 nrzkt (i found this because i'm working on client networking reworks) 09:32 cheapie Yeah... I forgot these are mostly devs here. 09:32 gregorycu Someone should create a dedicated IRC channel for the devs 09:32 gregorycu Oh 09:32 nrzkt it's here :D 09:33 * cheapie resizes his channel list so he can see the full name of the channel instead of just "#minetest-" 09:34 cheapie Meh, I'm a (lazy) mod dev. Close enough. 09:34 * cheapie wanders back off to #debian 09:42 gregorycu #2190 09:42 ShadowBot https://github.com/minetest/minetest/issues/2190 -- Settings related fixes by gregorycu 09:42 sfan5 TIL there is a feature freeze 09:45 gregorycu sfan5: Are you able to comment on my profiler fix, even if just to say "ok" #2173 09:45 ShadowBot https://github.com/minetest/minetest/issues/2173 -- Speed up Profiler::avg by a factor of 10 by gregorycu 09:45 sfan5 gregorycu: done 09:46 gregorycu Thanks sfan5 :) 09:49 gregorycu #2191 09:49 ShadowBot https://github.com/minetest/minetest/issues/2191 -- Fix chat scrolling bug (trying to negate unsigned) by gregorycu 09:49 * gregorycu & 09:51 jin_xi hm re collision, its really bad if you make more particle spawn and have them stick around longer. 09:52 jin_xi lots of false hits on node borders, resulting in grid like patterns of particles. they use same collision function as players 10:05 nrzkt ok i found the issue, we test serialize < 24 but SER_FMT_VER_LOWEST is 0 10:06 nrzkt then if i set a INIT command with version < 24, server crash 10:06 nrzkt ... 10:10 nrzkt Please merge #2192 10:10 ShadowBot https://github.com/minetest/minetest/issues/2192 -- Fix a crash (assert) when client set serial version < 24 in INIT command by nerzhul 10:23 nrzkt you must commit #2192 fast, i tested it on 5 public servers, each server crash. now vulnerability is public 10:23 ShadowBot https://github.com/minetest/minetest/issues/2192 -- Fix a crash (assert) when client set serial version < 24 in INIT command by nerzhul 10:23 kilbith i confirm, nrzkt has crashed a server in my presence 10:25 Krock https://github.com/nerzhul/minetest/commit/ac699798#diff-a3d43cc239efc733a8a046ff0a6bc91eL532 use return; 10:25 nrzkt no 10:25 nrzkt version is set when _INIT command is sent 10:25 Krock it would throw an error later 10:25 nrzkt and isn't modified elsewhere 10:25 nrzkt look at _INIT packet handling 10:26 nrzkt the throw become useless because we handle it when client sent _INIT command with wrong serial version 10:26 nrzkt then this test is useless. 10:26 nrzkt in the PR we didn't see the _INIT handling, but i can tell you it's the case, because it's how i found the issue :) 10:28 Krock sorry but "if(!ser_ver_supported(version))" throws an other exception now because the version is not supported anymore 10:29 Krock or I just misunderstand that 10:29 nrzkt if tested a 0.4.11-dev server and it works perfect 10:29 nrzkt i* 10:29 Krock hmh 10:30 nrzkt i tested game and there are no issue after this fix. Client sent serial version 26 in 0.4.11, and we must have 24, it's the minimum for mapblock 11:01 gregorycu ... 11:02 gregorycu You know, I like to think I'm a guy with (slightly) above intelligence 11:02 gregorycu Why the fuck am I having so much trouble with git 11:03 gregorycu Like, I almost want to cry 11:03 gregorycu I'm that frustrated 11:05 jin_xi did you rtfm? 11:06 gregorycu What do you mean? 11:08 jin_xi read the fucking manual, classical non helpful reply to software frustrations 11:08 gregorycu Indeed 11:08 gregorycu Like, I do a git status, and everything looks fine 11:09 gregorycu I then do a git push --force, and it updates other branches 11:09 gregorycu Like, didn't see that coming 11:09 gregorycu All because I wanted to do a small amendment to a commit 11:26 gregorycu You know what never gets old, redoing the same fixes over and over again 12:03 gregorycu #2193 12:03 ShadowBot https://github.com/minetest/minetest/issues/2193 -- Settings fixes by gregorycu 12:13 nrzkt zeno please commit #2192 fast, security fix 12:13 ShadowBot https://github.com/minetest/minetest/issues/2192 -- Fix a crash (assert) when client set serial version < 24 in INIT command by nerzhul 12:15 Zeno` so.. the server does not accept clients that don't use version 24? 12:15 nrzkt if you set version < 24 server accept you but mapblock::serialize assert. Then die 12:15 nrzkt the MIN is not set, and the throw became useless if you set the MIN_SERIAL because it's tested, before 12:16 nrzkt i have tested it on 5 public servers today, it works perfect :p 12:16 nrzkt sent a _INIT packet with first byte crafted and BOUM 12:16 Zeno` where is the assert? 12:17 nrzkt look at this PR. 12:17 nrzkt or give me you server IP i connect and crash your server :p 12:17 Zeno` I have, but where is the assert that fails? 12:18 nrzkt i don't found it, it's related to AsyncRunTask 12:18 nrzkt but my fix works perfect because MIN_SERIAL is set, then client set a proper version for serial, which is >= 24 and then we don't need the throw. 12:18 Zeno` surely it can be found... it doesn't give a file and line number? 12:18 nrzkt no 12:19 Zeno` assert() prints it to stdout 12:19 nrzkt i know, thanks. 12:19 Zeno` I see what you're saying and I agree this is important 12:19 nrzkt i have a ASSERT 0 and it show the throw error. 12:20 nrzkt not the assert line 12:20 nrzkt give me your server, i connect to it and you have the stdout. 12:20 nrzkt the fix is there please patch. 12:20 Zeno` I believe you :p 12:20 nrzkt i explained you what is the problem, fixed it properly because core dev forget to update a global variable which is very important for protocol and create a big hole 12:21 Zeno` I only just joined though... give be time to digest this ;) 12:22 nrzkt to be precise. When _INIT is handled, it set serial_version to client. But the test for MIN_SERIAL is to test, actually, if MIN_SERIAL < 0 (impossible, it's a u8), because DEFINE is wrong 12:22 Zeno` what a mess 12:22 Zeno` yeah, it's always true 12:22 Zeno` I've looked at this code before 12:22 nrzkt if client serial_verison is set properly, then MapBlock::serialize don't have problem because it's impossible to have a unhandled serial version 12:22 Zeno` and was told "theoretically we support version 0" :/ 12:22 Zeno` which is rubbish if you ask me 12:23 nrzkt it's wrong, because version 0 = crash on mapblock :p 12:23 Zeno` I know it's wrong :( 12:24 Zeno` It's a DoS 12:24 Zeno` geez 12:24 Zeno` umm 12:25 Zeno` when was version 24 introduced? 12:25 nrzkt i don't know, but client is in version 26 12:25 Zeno` yeah I need to know when version 24 was implemented though to at least help make a decision 12:26 nrzkt decision is simple, patch or i crash every server :p 12:26 Zeno` there are a lot of clients out there that are still version 0.4.9 (for example 12:26 Krock 0.3.1 is very popular somehow 12:26 nrzkt i patch for 0.4.12 12:27 Zeno` what serialization version does 0.3.1 use? 12:27 nrzkt previous 0.4 release must upgrade 12:27 Zeno` nrzkt, what I don't want to see happen is that people using the 0.3.1 client unable to connect to servers 12:27 nrzkt 0.4.x must go to 0.4.11 12:27 Zeno` this is not my decision but a decision made before I even joined the team 12:27 nrzkt i look at stable-0.3 ? 12:28 Zeno` Krock, does stable-0.3 sound reasonable? 12:28 nrzkt SER_FMT_VER_HIGHEST is the value to look 12:28 Krock Zeno`, I don't know 12:28 nrzkt https://github.com/minetest/minetest/blob/stable-0.3/src/serialization.h 12:28 nrzkt 0.3 is incompatible with 0.4 12:28 nrzkt #define SER_FMT_VER_HIGHEST 20 12:28 Zeno` hmm 12:28 nrzkt 20 is sent to server 12:29 nrzkt then server will crash :p 12:29 Zeno` yes, I can see how that would happen 12:29 nrzkt then 0.4 servers and incompatible with 0. 12:30 nrzkt 0.3, because only > 24 is supported by MapBlock::serialize 12:32 Zeno` wtf is the server throwing an error for if the version is incorrect anyway? 12:32 nrzkt now, we need to patch 0.4 series. Because they are ALL vulnerable 12:32 nrzkt ofc, but it must be handled at connection, like now, because client CANNOT receive mapblocks. 12:33 Zeno` shouldn't it just drop the connection though? 12:33 nrzkt and my patch is the only solution. If we CANT serialize, we must block the client. 12:33 nrzkt my solution permit to say at connection: client version incompatible. It's the right way. 12:34 Zeno` please find out when ser. version was introduced 12:34 Zeno` version 24 12:34 nrzkt long time ago. It's already in 0.3 12:34 nrzkt https://github.com/minetest/minetest/blob/stable-0.2/src/serialization.h 12:34 nrzkt and already in 0.2 12:34 nrzkt then... FIX 12:35 Zeno` your link says version 20 :P 12:35 nrzkt yes, but serial version was in 0.2. it was already here. Then everytime it exists. 12:35 kilbith nrzkt has crashed like 10 servers this morning 12:35 Zeno` I don't deny the bug is there 12:35 nrzkt now, don't search to handle things unhandled. 0.4.12 need to be stable, fix the crash is a stabilization. Handle 0.3 client isn't. 12:35 Zeno` I just want to know the range of clients that will no longer be able to connect 12:36 nrzkt every < 0.4 client. 12:37 nrzkt here 12:37 nrzkt https://github.com/minetest/minetest/commit/fd845f27f5b3e3c6587c472be76235567a7b934d 12:37 nrzkt 23 Jul 2012, two years and 6 month ago. 12:37 nrzkt 0.4.2-rc1 12:38 Zeno` ok, let me review the code again 12:38 nrzkt ok, fixing MIN_SERIAL_VER block client unhandled on mapblock::serialize. This permit every client from 0.4.2 to now 12:39 nrzkt because vers 24 25 and 26 are handled by server 12:39 Zeno` ok, it all looks ok 12:39 Zeno` I'll merge it 12:39 nrzkt thanks 12:47 Zeno` gregorycu, is that uninit var. fixeD? 12:47 gregorycu Yes 12:47 gregorycu umm... 12:48 Zeno` ahh I see it is 12:48 Zeno` will merge in a minute. Give me 10 to review? 12:48 gregorycu #2193 12:48 ShadowBot https://github.com/minetest/minetest/issues/2193 -- Settings fixes by gregorycu 12:48 gregorycu Yep 12:48 gregorycu At your leasure 12:49 Zeno` I can't see where deregister() is called from (in game.cpp) 12:50 gregorycu Seriously? 12:50 gregorycu Yeah 12:50 gregorycu ffs 12:50 gregorycu I've been battling against git for the past 2 hours 12:51 gregorycu Had to do that change like 3 times 12:52 gregorycu (In the end I destroyed and recreated my local git repo) 12:52 Zeno` :) 12:52 gregorycu here is a pro tip 12:53 Zeno` gawd I hate that term, but anyway... waiting heh 12:53 gregorycu git push --force will force push all your changes, not just changes for the current branch 12:53 Zeno` oh, yeah, it will 12:53 gregorycu That's what screwed me 12:53 gregorycu I had two repos, and they were fighting over the pushes 12:55 Zeno` d'oh :) 12:56 gregorycu it's pretty fucking retarded that there is no command to say: "I want to reclone" 13:04 Zeno` gregorycu, doCallbacks() seems wrong 13:05 Zeno` if the callback calls getSetting() (or whatever it's called) there is another lock 13:05 Zeno` and it will be a deadlock if I'm not mistaken 13:05 Zeno` which, I guess, was the reason for the tempvector in the first place 13:05 gregorycu Surely the lock is reentrant 13:06 gregorycu The thing is, you have to lock 13:06 gregorycu The think you are dispatching to may deregister itself and get destroye 13:06 gregorycu d 13:06 gregorycu While you are iterating through the temp vector 13:06 Zeno` hmm, yes 13:07 gregorycu I didn't deadlock on myself when i was testing 13:07 Zeno` ok, with your code open up a command console in a singleplayer game and press whatever the key is to enable/disable fog 13:08 Zeno` doh 13:08 Zeno` ok, with your code start a singleplayer game and press whatever the key is to enable/disable fog 13:08 gregorycu Right 13:08 gregorycu It doesn't work 13:08 gregorycu It never worked 13:08 gregorycu (i asked if it was working before) 13:09 Zeno` testing now 13:09 Zeno` it used to work for me 13:09 Zeno` haven't tested in ages though 13:09 gregorycu If you restart the map it takes effect 13:09 gregorycu There is a cache in the game 13:09 gregorycu I was going to fix it, but I have too much on my plate at the moment 13:10 gregorycu Especially if the settings system will be reworked 13:12 gregorycu Fucking hell, I'm segv ing 13:14 gregorycu Ok, config error 13:18 Zeno` who broke fog? 13:19 gregorycu There are caches in game 13:19 gregorycu No idea if they get updated 13:20 Zeno` seems I did 13:20 gregorycu m_cache_enable_fog 13:22 gregorycu Classic Zeno move 13:22 Zeno` yeah I think it was left over after I removed the callback (because people didn't like it) 13:23 gregorycu On the plus side, there is a new callback to use 13:27 gregorycu #2193 has been updated 13:27 ShadowBot https://github.com/minetest/minetest/issues/2193 -- Settings fixes by gregorycu 13:31 kilbith 2156 is abandonned ? 13:31 gregorycu #2156 13:31 ShadowBot https://github.com/minetest/minetest/issues/2156 -- Optimise MapBlockMesh functions by gregorycu 13:31 gregorycu Shouldn't be 13:32 gregorycu Looks fine to me? 13:33 Zeno` oh I've disabled fog :/ 13:34 gregorycu That's a bit of a dick move 13:35 Zeno` no, locally 13:37 gregorycu I really don't understand what this collision detection code was about, and I can't understand what you and V were about when you said there was bouncing after jumping 13:39 Zeno` why is making a change to my local settings a dick move? :p 13:40 gregorycu I thought you had checked it in and broken fog 13:40 Zeno` such faith! 13:42 gregorycu That's me 13:42 gregorycu They don't call me faithless greg for nothing 13:44 gregorycu How would you describe this bounce? 13:44 gregorycu Could you describe it as an additional jump? 13:44 gregorycu Cause if I hold down space, my dude jumps the second he is on the new block 13:45 gregorycu Well, not the second, the moment 13:45 Zeno` it's a bounce and then slow sinking 13:45 gregorycu lol 13:45 Zeno` :D 13:46 gregorycu Fuck me, what the hell is going on 13:47 Zeno` gregorycu, regarding what I said about locks... 13:47 gregorycu Yeah? 13:48 jin_xi collisionMoveSimple is broken in some ways for sure 13:48 Zeno` a) start a single player game; b) open console; c) type /set enable_fog = false 13:48 Zeno` (with your latest patch) 13:48 gregorycu Ok, let me build 13:48 Zeno` it'll sit there waiting for the mutex to be freed 13:51 gregorycu Well, I'm segfaulting, which is nice 13:53 Zeno` I saw from the code (before I even compiled) that the mutex would not be released and that the callback would deadlock :P~ 13:55 gregorycu It worked for me 13:56 gregorycu Different underlying lock? 13:56 Zeno` /set enable_fog = false works for you? 13:56 gregorycu Yes, and as soon as this finishes compiling, I'll confirm 13:56 Zeno` well there is a different underlying lock. From memory on Linux the POSIX locks are used 13:57 Zeno` On Windows... not sure 13:59 gregorycu "When a thread owns a critical section, it can make additional calls to EnterCriticalSection or TryEnterCriticalSection without blocking its execution. This prevents a thread from deadlocking itself while waiting for a critical section that it already owns. " 14:00 gregorycu CRITICAL_SECTION mutex; 14:00 gregorycu So yeah, fine on windows 14:01 gregorycu Bad on linux 14:01 gregorycu What's the solution 14:01 Zeno` don't call the callback until the mutex is released 14:01 gregorycu lol 14:01 gregorycu You can't 14:01 gregorycu That's a race condition 14:02 Zeno` yes you can 14:02 Zeno` that was the whole point of the tempvector 14:02 gregorycu Right, and it was a race condition 14:02 Zeno` well, we have a problem then :) 14:02 Zeno` right now on linux (with the patch) it deadlocks 14:02 gregorycu I don't deny that is a bit of a showstopper 14:03 Zeno` kinda ;) 14:03 gregorycu So, a solution may involve sending the value as part of the callback call 14:04 gregorycu Another option is sending an assessor object, as part of the callback call 14:04 gregorycu (So people can fetch a specific type) 14:05 gregorycu Or use a reentrant lock 14:05 Zeno` the race condition can be eliminated by not calling the callback(s) straight away 14:05 Zeno` i.e. you lock the queue and not the settings 14:05 Zeno` (the callback queue) 14:05 gregorycu That's another option, separate locks for settings and callbacks 14:06 gregorycu Maybe the easiest option 14:09 Zeno` It's what I'd do 14:09 Zeno` and call the callbacks at a location that is determinant 14:09 Zeno` instead of from... well, from wherever 14:10 gregorycu determinant on what? 14:10 Zeno` i.e. the callstack would be known 14:10 gregorycu Aren't we replacing all this? 14:10 Zeno` probably 14:10 Zeno` :) 14:10 Zeno` But for now it has to work 14:10 gregorycu Why must the callstack be known? 14:11 Zeno` it doesn't need to be known; it's easier to avoid race conditions and for debugging though if you know "run callbacks" always happens from a certain place 14:11 Zeno` (with it's predecessor the same) 14:12 gregorycu The only thing you can't do in a callback is register another callback 14:12 gregorycu Which is always bad, no matter the callstack 14:12 gregorycu Anything else is always good 14:12 Zeno` and, at the moment, call any of the Settings:get*() functions :) 14:12 gregorycu Not when I'm through with it 14:13 gregorycu You know, if we use C++11 locking, we wouldn't have this problem 14:13 Zeno` can 14:13 Zeno` can't :( we support pre C++11 14:13 gregorycu For how long? 14:13 Zeno` 2021 14:13 gregorycu C++03 is over 10 years old 14:13 Zeno` it should be stable by 2021 14:13 gregorycu It is stable 14:14 Zeno` not until 2021! 14:14 Zeno` it always takes 10 years 14:14 gregorycu C++14 is where it is at now 14:14 Zeno` :p ;) 14:14 Zeno` that will be stable in 2024 14:14 Zeno` maybe 2034 14:15 Zeno` it's not needed anyway 14:15 Zeno` :/ 14:15 Zeno` I guess that's the point 14:15 Zeno` I could do all this in c89 14:16 Zeno` if I was that crazy 14:17 gregorycu Yes 14:17 gregorycu I mean 14:17 gregorycu You could do it all in brainfuck 14:17 gregorycu Doesn't mean it's smart 14:18 gregorycu How old are you? Like 40 I'm thinking? 14:18 gregorycu Stuck in your ways because "I've always done it this way and I know it works" 14:22 Zeno` huh? 14:22 Zeno` All I'm saying is that it deadlocks on Linux. Nothing more, nothing less. 14:22 gregorycu brainfuck is a programming language 14:23 Zeno` yes, a turing complete language 14:23 Zeno` dunno what this has to do with the discussion though 14:23 gregorycu We were just talking about C++11 14:23 Zeno` the issue is this: it doesn't work on Linux and therefore probably doesn't work on Android 14:24 gregorycu And you suggested you could do all of this in c89 14:24 Zeno` yeah, that was just nonsense talk 14:24 gregorycu The natural extension is to do it in brainfuck 14:24 gregorycu I'll have a fix soon 14:26 Zeno` *sigh* 14:27 Zeno` I'm not stuck in my ways, btw. I'm just sick of people relying on a language (and the abstractions such and such language or revision of the language introduces) without knowing what is being abstracted 14:28 Zeno` Not sure why you turned this into an argument :/ 14:29 gregorycu I did it because you are wrong. 14:29 Zeno` No, I'm not wrong 14:29 Zeno` there are LTS operating systems out there that do not support C++11 14:29 gregorycu Let's look at JMutex. I relied on JMutex and it appeared to work. But it does different things on different platforms. Using the standard library, and you get less varience 14:30 Zeno` once they all support C++11 then fine 14:30 gregorycu Fuck them 14:30 gregorycu Why are we concerned with them 14:30 Zeno` because that's how open source works 14:30 gregorycu If I release a LTS operating system and not update for 50 years will the project get held back 14:31 gregorycu You need to make an informed assessment on market share and benefit 14:31 Zeno` a LTS release implies backporting bugs and fixes 14:31 gregorycu What does that mean in this context? 14:32 gregorycu So, i have an LTS operating system where I backport bugs and fixes 14:32 Zeno` it means that there are *current* operating systems that are receiving long-term support from the vendor, by the vendor providing bug fixes and backporting of some things for a specified period 14:33 gregorycu We are not the vendor 14:33 gregorycu Do we have to support every LTS operating system from every vendor? 14:33 Zeno` Why not? 14:34 gregorycu Because the definition of vendor is hazy, as is LTS 14:34 Zeno` My answer would, btw, be yes 14:34 gregorycu And it holds us back 14:34 gregorycu That's crazy 14:34 Zeno` it doesn't hold us back 14:34 gregorycu Are we using C++11? 14:34 Zeno` how does it hold us back? 14:34 Zeno` what can you do in C++11 that you cannot do in C++03? 14:35 gregorycu rvalue references 14:35 gregorycu initialiser lists 14:35 Zeno` that's just syntax 14:35 gregorycu vararg templates 14:35 gregorycu I can list them all if you want 14:35 gregorycu Why don't we code in C? 14:35 gregorycu Why don't we code in ASM? 14:35 Zeno` ASM is not portable 14:35 gregorycu That's the reason? 14:36 gregorycu We support only a few platforms, we could easily port the ASM 14:36 jin_xi there is this previous discussion, i thought that was the conclusion: http://irc.minetest.ru/minetest-dev/2014-12-23#i_4075355 14:36 Zeno` ffs, I don't know why you're making a big deal about this. Your patch is broken. 14:36 Zeno` Your initial commit is broken 14:37 Zeno` I'm a nice person, but don't push me for no reason other than pointing out that something doesn't work 14:37 gregorycu I didn't 14:37 gregorycu Let's rewind 14:37 Zeno` good :) 14:37 nrzkt question, why are we using jthread instead of std::thread ? they both have same functionnalities :) 14:37 gregorycu That was my point 14:38 gregorycu What nrzkt just said was my point 14:38 gregorycu If we were using C++11 and using std::thread we would not have silently diverging functionality of JMutex 14:38 Zeno` And I've addressed that 14:38 Zeno` What we need to worry about, right now, though is what we have 14:38 Zeno` and currently we do not have std::thread 14:39 gregorycu You addressed nothing, you starting crapping on about how C++11 is useless 14:39 gregorycu Did you expect me to say nothing? 14:39 Zeno` I didn't say it was useless :/ 14:39 Zeno` I said that relying on something that's in a standard that we don't currently support is not a solution 14:40 Zeno` at least that's what I meant to say 14:40 nrzkt we need to cleanup the code and then change the c++ functionnalities, maybe for next release ? switching to c++11 before 1.0.0 will be great, and many developpers can be interested in 14:40 Zeno` I said "this can be solved" 14:41 Zeno` and it can be solved without c++11 14:41 gregorycu I know, we previously discussed a solution 14:42 Zeno` here, have a beer 14:42 nrzkt one thing by one thing. Make the core be stable and next switching the coding standards :p 14:42 gregorycu I don't know what stable is 14:42 gregorycu For this game 14:42 Zeno` nrzkt, that is what I am implying 14:42 Zeno` There is nothing stable about this game :) 14:43 nrzkt at this time not 14:44 Zeno` there are the current standards: http://dev.minetest.net/Code_style_guidelines (and, no, I don't agree with them all) 14:44 nrzkt but we are cleaning up, many devs are working on graphic and minetest engine, i'm working on network, i hope in 1 year we will have a minetest 1.0 with great features and good code 14:44 Zeno` s/there/these 14:45 nrzkt i mean standards, not minetest guidelines, standards are not written by minetest :p 14:45 Zeno` Notice the section on "Do not be too C++y " 14:45 Zeno` nrzkt, I know what you meant ;) 14:46 nrzkt when i finish to rewrite networking code and sapier and me find the best network layer handling we will have a stable and evolutive protocol 14:48 gregorycu Didn't freeminer redo their network stack? 14:48 est31 yea 14:49 est31 but they are GPL 14:49 gregorycu What are we? 14:49 est31 LGPL 14:49 gregorycu lol 14:49 est31 LGPL->GPL is allowed but not the other way 14:49 gregorycu Are we LGPL so mods can be whatever license they want? 14:49 est31 dunno 14:49 est31 but I guess so 14:52 Zeno` I think we're LGPL so people can make a game, sell it commercially, and not have to release the source code (unless they modify the engine itself) 14:53 T4im well builtin being lgpl allows mods to take other licenses too 14:55 T4im instead of requiring mod authors to read up on their opensource legal situations and check if they are using gpl (freeminer?) functions in their open but non-gpl compatible mod 14:55 Zeno` mods aren't compelled to be GPL even if the engine is 14:56 T4im well they do use builtin/ functions though 14:56 T4im engine itself is unimportant, but that interface might not 14:56 Zeno` hmm 14:56 Zeno` but unless they modify builtin there is no issue 14:56 T4im at the moment, since its lgpl, yes :) 14:57 Zeno` how so? 14:57 T4im they are allowed to link it due to being lgpl, so there's no issue unless they change builtin/ 14:57 est31 proller: what do you think, can freeminer mods be non-gpl? 14:57 Zeno` https://www.dropbox.com/s/p0tsrq4xck5bqmm/spmgv5.tar.gz?dl=0 14:57 Zeno` oops 14:57 nrzkt no mods doesn't need to be compatible with core licence. Like World of Warcraft mods have they own licence, like minecraft mods have their own licence 14:58 T4im if it were gpl (without linking exception that is), you would have to ask yourself if the calling/linking of those functions is intimate enough to fall under gpl protection… I'd say in this case yes 14:58 T4im nrzkt: that's because they are not compelled to 14:58 Zeno` there is no linking of builtin though 14:58 Zeno` they are loaded at runtime 14:58 T4im a proprietary license can allow you to link to it too 14:59 T4im gpl however might compell, nrzkt 14:59 est31 linux is also GPL, and still you can use it with whatever license you want 14:59 T4im kernel mods not 14:59 T4im modules* 15:00 Zeno` sure they can 15:00 T4im the software running on that is according to the faq not in a intimate relationship iirc 15:00 Zeno` as long as they don't modify the kernel they can be whatever license they like 15:00 Zeno` modify the kernel source code* 15:01 gregorycu What is the difference between LGPL and GPL? 15:01 T4im est31: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation 15:01 T4im "By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. " 15:02 T4im Zeno`: the modules: " If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program." 15:02 T4im same link 15:02 T4im gregorycu: you are allowed to link to lgpl, also you grant lgpl authors a right to reverse engineer for the purpose of keeping stuff working 15:03 T4im (the latter part is not so widely known) 15:03 Zeno` you also grant the right to change the license to GPL 15:03 T4im yes 15:05 T4im there's a fuzzy line when it comes to modular software like this… minetest would probably be in a totally different situation if the api/interface would not be minetest specific, but an interface standard used by multiple different software 15:05 T4im because: then the mods could run without minetest (or a derivate thereof) 15:05 T4im but they cannot, they are dependend on that builtin/ stuff :/ 15:05 T4im they do not constitute a separate program 15:06 Zeno` lgpl is a very strange choice for something like this anyway (IMO) 15:06 T4im well yes… I do think a "gpl with linking exception" also known as "classpath exception" due to its usage by java (or rather the classpath project preceeding it), might be a better fit 15:07 T4im its basicly a gpl with the exception: you may link to the api 15:07 T4im that would allow mods to continue doing what they do without any headaches 15:07 Zeno` you know the difference between dynamic and static linking, right? 15:07 T4im I don't think this is important for gpl though is it? 15:08 Zeno` nope. It is for the lgpl though 15:08 T4im ah 15:08 DFeniks how can people work like this . do you never look into freeminer code to not get your brain contaminated? 15:08 T4im DFeniks: they better not… 15:08 T4im :D 15:09 Zeno` actually it's important for the GPL as well 15:09 Zeno` a dynamically linked module can have whatever license it wants 15:09 DFeniks i heard microsoft doesnt allow its employees to read opensource code. or was it a myth? 15:09 est31 microsoft has its own github page with open sourced code 15:10 est31 its a myth 15:10 T4im Zeno`: 2 or 3? 15:10 Zeno` both 15:10 DFeniks ah , i thought so 15:10 T4im DFeniks: they might have _some_ employees that are not allowed, see the concept of a cleanroom implementation 15:10 DFeniks but you never know , its microsoft 15:11 est31 MS has changed alot in the last years 15:11 est31 they even release components of their OS as open source 15:11 T4im that ballmer was crazy as cobble, so no surprise there 15:12 T4im (that they changed somewhat after he was gone) 15:12 DFeniks anyway living in this age of copyright , i dont know what is right anymore 15:12 T4im anyway microsoft -> #minetest 15:14 DFeniks i know my brain will try to copy and collect everything it finds useful , is it bad? but how can i do otherwise? everything i know was inspired by something 15:14 T4im Zeno`: the fsf stand on that is there's no difference.. either its derivating or not 15:14 T4im https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic 15:14 T4im for gpl that is 15:15 T4im lgpl has its own section underneath :D 15:15 T4im so lgpl would only allow dynamic linking… but I think that works with mods 15:18 Zeno` oh, I dunno 15:18 Zeno` I'm not a lawyer 15:18 Zeno` heh 15:18 T4im and you can't even take any random lawer on this :P I've had some interesting re-interprations with local lawers on that stuff 15:19 T4im gpl 2.0 distribution for example is interpreted in germany differently thani n the u.s. 15:19 T4im gpl 3.0 changed that though 15:20 nore sfan5, what about 401, 405, 407, 410, 412? 15:20 nore ... ShadowBot didn't add the links :( 15:20 T4im missing # 15:20 kilbith game# 15:21 nore so: game#401, game#405, game#407, game#410, game#412 15:21 ShadowBot https://github.com/minetest/minetest_game/issues/401 -- Add an outlined crosshair by Calinou 15:21 ShadowBot https://github.com/minetest/minetest_game/issues/405 -- Textures Update by kilbith2 15:21 ShadowBot https://github.com/minetest/minetest_game/issues/407 -- Mossycobble fixes by MT-Modder 15:21 ShadowBot https://github.com/minetest/minetest_game/issues/410 -- Fix typo for obsidian glass door texture by Xanthin 15:21 ShadowBot https://github.com/minetest/minetest_game/issues/412 -- Default/mapgen.lua: Add dirt/sand/gravel blobs for mgv5. Select and order functions per mapgen by paramat 15:21 nore yep, but previously, it added the links in mt_game if there was no "#" 15:22 Zeno` I will be reverting #2187 until issues are resolved 15:22 ShadowBot https://github.com/minetest/minetest/issues/2187 -- Make the GameGlobalShaderConstantSetter use the settings callback by gregorycu 15:23 Zeno` i.e. a) unitialised vars; and b) potential for dangling pointers/references 15:25 Zeno` can't re-open :/ 16:34 shadowzone Hello 16:50 shadowzone Hello kilbith. 16:51 kilbith hi 16:52 shadowzone Hello Zeno` 16:52 Zeno` o/ 17:14 shadowzone Hello hmmmm, kaeza and celeron55 17:16 kaeza hi 19:14 rubenwardy #2196 19:14 ShadowBot https://github.com/minetest/minetest/issues/2196 -- Mod Store Mockup Design 19:15 * Calinou sighs 19:26 VanessaE huh, I just spotted a bug in digging particles 19:26 VanessaE only happens when digging a mesh node: the texture shown on the particle is the raw texture, not something a "rendered" view of the object 19:27 VanessaE so you can see the UV layout of the texture in the particles 19:27 VanessaE s/something/something like/ 19:28 kahrl most likely by design 19:28 VanessaE probably an artifact of pre-mesh design, yeah 19:28 kahrl there isn't really a good way to convert the uv texture to a "rendered" one 19:28 VanessaE I would suggest particles pick from the mesh's polys or something 19:28 kahrl (short of rendering the whole mesh to a texture or something expensive like that) 19:29 VanessaE nah, that'd be wasteful for this 19:29 est31 What are mesh nodes? 19:29 VanessaE est31: anything using the mesh drawtype 19:30 kahrl yeah, picking an arbitrary poly might work (for low-poly meshes, at least) 19:30 VanessaE such as a homedecor desk lamp or a technic slope 19:30 est31 k 19:30 kahrl might be hard to code though 19:30 VanessaE kahrl: yeah, just random polys with each particle that is spawned would probably look fine 19:30 VanessaE yeah, probably so 19:32 kahrl another solution would be another field in the node definition, particle_texture = "..." 19:33 jin_xi i like this idea 19:34 VanessaE kahrl: that would work too I guess, or particles could be drawn from the rendered inventory image 19:34 sfan5 nore: 412 ok; 407 ok; 410 is ok if it fixes something 19:35 VanessaE since the game already renders one anyway 19:36 kahrl they might have too much transparency 19:36 kahrl but it could be worth a try 19:37 nore sfan5, what about game#405? 19:37 ShadowBot https://github.com/minetest/minetest_game/issues/405 -- Textures Update by kilbith2 19:38 sfan5 nore: some of those texture don't need updating 19:38 sfan5 I'll be more specific in a github comment 19:38 nore ah, about 410: right now, both textures are the same 19:38 nore but texture packs may want to use two different ones 19:39 nore (for top/bottom of obsidian door) 19:39 kilbith sfan5: i'm waiting for your feedback but i hope you have read the comments in that PR 19:42 nore for 412, I'll wait for the engine dependent pull request to be merged 19:43 kilbith 413 is good too 19:50 sfan5 nore, kilbith: https://github.com/minetest/minetest_game/pull/405#issuecomment-71334265 19:51 kilbith sfan5: https://cloud.githubusercontent.com/assets/9149204/5794247/c54dad0e-9f65-11e4-983d-5265b403e2ea.png 19:51 sfan5 ? 19:51 kilbith the copper ingot currently doesn't follow the new copper block color 19:53 kilbith and the bronze ingot is more faithful with the bronze block one 19:53 kilbith you see what i'm talking about ? 19:55 sfan5 hm 19:55 sfan5 you're right 19:55 kilbith i've updated the copper & bronze blocks recently, remember ? 19:55 kilbith so i was forced to update the ingots too 19:55 sfan5 changed my comment accordingly 19:56 kilbith as for the Mese, ok, i revert it 19:56 sfan5 the other ingot textures still don't need any changing 19:57 kilbith ok, will revert 20:00 kilbith sfan5: reverted and squashed. 21:53 VanessaE hmmmm: still wasn't able to get a backtrace, but Michael continued his testing and found something interesting: https://forum.minetest.net/viewtopic.php?f=10&t=4057&p=168709#p168709 21:54 hmmmm still not very helpful 22:11 sofar 14:11:01: ACTION[main]: Mod bucket is explicitly disabled in world.mt 22:11 sofar awesome, I can now disable "default" mods in world.mt 22:11 sofar will post patch 22:21 sofar are there any specific pull request requirements, like S-O-B lines? 22:22 sfan5 what are S-O-B lines 22:22 sofar Signed-Off-By 22:22 VanessaE other than mentioning what you did and things like "fixed #xxxx", avoid calling the person who broke what you're fixing a SOB. :P 22:22 sofar hehehe 22:22 VanessaE fixes* 22:22 sofar https://github.com/minetest/minetest/pull/2197 22:23 sofar VanessaE: I should be capable of making reasonable commit messages by now ;^) 22:24 sofar feedback welcome, this is the first time in 15 years or so that I've actually read more than 5 lines of C++ code (I'm a pure C type of guy) 22:24 sfan5 we don't use too many C++-y constructs 22:24 sfan5 so.. 22:25 sofar it's not too bad, but kernel style C code is so radically different 22:26 sofar ah lol, typos 22:27 * sofar fixes 22:27 sofar actually I can pull up the worldmt settings declaration so it's not done every single loop run 22:38 sofar https://github.com/minetest/minetest/pull/2198 22:39 sofar thanks for the comments 23:05 paramat hmmmmm thanks for merging the first commit from #2175 , is there an issue with the second commit? the necessary MTgame PR for replacement blobs is now ready https://github.com/minetest/minetest_game/pull/412 23:05 ShadowBot https://github.com/minetest/minetest/issues/2175 -- Mgv5: Speed optimise noise. Remove blobgen, add large caves. Cavegen: add mgv5 large caves by paramat 23:35 hmmmm ermm 23:35 hmmmm i thought there was only one commit for some reason