Time Nick Message 01:34 est31 network protocol only resends parts of the map if the map actually changed? 02:15 Zeno` Wayward_One, that's interesting then isn't it. The question is why? 02:16 Zeno` I love continuing conversations after a 12 hour break 02:16 acerspyro lol 02:16 acerspyro Someone lost track of time here 02:16 Zeno` hmmmm, Wayward_One's "issue" is fixed 02:27 Zeno` Must get feature freeze thawed 02:29 * Tesseract would like SQLite3 and translations to be fixed first (PRs already made). 02:30 Tesseract Also, now that Lua 5.3's been out for a while is 5.2 old enough to use? 02:30 Tesseract 5.1 is only, like 9 years old now. 02:31 acerspyro Tesseract: You do know there's a game with your name, right? 02:32 Tesseract acerspyro: I've only been told 256 times, please, tell me again. ;-P 02:32 acerspyro Tesseract: You do know there's a game with your name, right? 02:33 acerspyro That NEEDS to be 512 times now 02:34 Brains Wonder if he used signed storage for that... And what being told something - means. 02:36 Zeno` ? 02:37 Brains Zeno`: Lame joke about Tesseract storing the number of times he's been told about the game of the same name. Lame and OT to boot. 02:38 Zeno` :) 02:47 T4im Tesseract: luajit is at 5.2. right? wouldn't it be right to assume that a more recent luajit can do a lot more runtime optimizations and thus run faster? :D 02:49 Tesseract T4im: No, luajit is at 2.0.3 or so. It's compatible with 5.1, supports most 5.2 features, and has one or two 5.3 features though. 02:49 T4im ah, yes I meant compatible with 5.2 :) 03:13 hmmmm Zeno`: Saw that, holy crap 03:13 hmmmm Zeno`: What was taking up more cpu time in clientmap though?? 03:13 hmmmm my guess is that my change somewhere caused a flood of exceptions 03:14 Zeno` hmmmm, I'm just spent another 30 minutes looking at it and I really don't know. It's baffling 03:14 hmmmm i'll try to figure it out so it never happens again 03:16 Zeno` If you figure it out before I do be sure to let me know because I really want to know. I can't see anything that jumps out. Even looking through these valgrind logs... it's odd. 03:17 hmmmm Zeno`: So reverting the changes in clientmap.cpp in that commit specifically fixes it? 03:17 Zeno` It increases performance, yes 03:18 Zeno` Oh. I reverted the whole commit 03:18 Zeno` so it could be any of those changes 03:18 hmmmm why'd you say clientmap.cpp then 03:18 Zeno` the order of ::render() and ::renderMap() is reversed 03:19 hmmmm oh dear 03:19 Zeno` hmmmm, not sure. It was late. Let me profile with just reverting clientmap.cpp 03:20 Zeno` By the time I came across this innocent looking commit I'd been profiling for 8 hours; I was going cross-eyed heh. But reverting it definately changes things. Trying to narrow down even more now 03:21 Zeno` https://github.com/Zeno-/minetest/tree/experiment is what I got Wayward_One to try before I passed out from lack of sleep 03:21 Zeno` ok, back to looking 03:26 Zeno` Whatever it turns out to be (*root* cause) it's likely to be somewhere else... because I can't see anything in that entire commit that should cause such a difference (suggesting something somewhere else is flaky) 03:59 Zeno` I'm getting frustrated now 04:24 Zeno` ok, it's more than 1 commit 04:24 Zeno` arrgh 04:37 Zeno` I don't know what to do now :/ 04:40 Zeno` and what is #2252? 04:40 ShadowBot https://github.com/minetest/minetest/issues/2252 -- Framerate cut in half, HUD problem ? 05:19 Zeno` time to clutch at straws again :( 05:31 Zeno` I've worked out what the problem is: client rendering is now too fast. Might have to add a sleep() 05:32 Zeno` for those who do not understand my sense of humour (the sleep() bit anyway) 07:00 Zeno` ok, I found the real problem 07:01 Zeno` Client::ProcessData() is now being called too often (and therefore mesh update thread) 07:02 T4im that thread is quite visible in (h)top, spiking cpu quite drasticly.. kudos for fixing another noticeable performance hit :D 07:03 Zeno` The faster everything else gets the more processData() gets called 07:03 Zeno` T4im, well I haven't fixed it yet 07:03 Zeno` :) 07:03 T4im ah, finding the problem is half the job ;) 07:03 T4im if not more :) 07:04 Zeno` I just know it's the problem because changing sleep_ms(3); to sleep_ms(25); in the mesh update thread "fixes" the problem (changing to 25 is not a solution; I did it to prove to myself that this was the real issue) 07:05 Zeno` I really don't know how to fix it 07:05 Zeno` need to work out some reasonable interval on which to base the sleep time on 07:29 kahrl Zeno`: do you have an idea why that would cause general slowness? 07:29 kahrl I mean it's a thread, so in theory it should run in parallel 07:29 kahrl is there contention on some lock? 07:32 Zeno` I think that's part of the issue yes (lock contention) 07:32 Zeno` haven't worked out all the "why's" yet 07:32 Zeno` But also clientmap::render seems to be doing more work than it should (for some reason) 07:33 Zeno` I'm finding it quite difficult to debug (with the threads) 07:34 kahrl I can imagine 07:35 Zeno` What I've been thinking about is that sleep(3) in the thread... 07:35 Zeno` should that 3 be based on "something" 07:35 Zeno` like some kind of "aimed for interval" 07:35 kahrl I don't like that it is polling at all 07:35 kahrl it should condition variables or something like that 07:35 kahrl should use* 07:35 Zeno` correct 07:35 Zeno` I was saying that to someone else earlier 07:36 Zeno` some kind of signal to say "hey go process data" 07:36 Zeno` maybe after map update is complete (I think that was the potential solution) 07:36 Zeno` soltuion/suggestion 07:37 kahrl the threadsafe stuff in util/container.h used to sleep too to wait on new data, now they use semaphores 07:37 Zeno` should semaphores be used here then? 07:37 kahrl probably 07:38 kahrl personally I prefer condition variables (semaphores feel too low level and error prone) but we don't have that in jthread 07:39 kahrl actually I guess since this is a simple producer-consumer thing, semaphores would be fine 07:40 Zeno` hmm 07:44 Zeno` it's (probably) /really/ ProcessData being called more often and therefore adding more "mesh update tasks" 07:45 Zeno` I'm not sure... I've been looking at this too long now 07:46 T4im kahrl: that thread also spikes heavily in cpu and memory, which might easily overpower a slower pc if it gets more time than the main thread 07:47 kahrl should its priority be reduced then? 07:47 T4im maybe.. would there be any drawbacks? 07:48 kahrl well if the main thread is running all the time and the mesh update thread has low priority, mesh updated might not happen at all 07:48 kahrl that would be the only danger I can think of 07:48 kahrl mesh updates* 07:51 Zeno` I need a break. I expect kahrl and/or T4im to have fixed this once I get back (lol) 07:51 * kahrl hands the responsibility to T4im 07:51 * T4im quickly flees 07:52 * VanessaE hides too just to be safe 07:52 * Zeno` hides as well then 07:53 Zeno` ok, something easier? 07:54 Zeno` T4im, can you change the sleep time in that thread just to confirm things? 07:54 Zeno` and anyone else as well 07:54 kahrl Zeno`: #2255 07:54 ShadowBot https://github.com/minetest/minetest/issues/2255 -- Fix download URL by blha303 07:55 Zeno` I think that's safe to merge 07:55 kahrl yep 07:55 kahrl easy enough? :P 07:55 Zeno` hopefully there are no side effects 07:55 Zeno` lol 07:56 Zeno` you'd better profile the game after you merge it though, rofl 07:56 * Zeno` is certainly tired 08:06 Krock tested #2256 , compiles without fails 08:06 ShadowBot https://github.com/minetest/minetest/issues/2256 -- Give full breath after death by SmallJoker 08:06 Krock ShadowBot, it's not an issue. it's a pull 08:40 kilbith hmm, the releasing is constipated and may need a laxative... 08:42 VanessaE there is currently a polyp or two to be excised. 10:24 rubenwardy #2257 10:24 ShadowBot https://github.com/minetest/minetest/issues/2257 -- Change assignment to global to warning by rubenwardy 10:24 Krock rubenwardy, why not "info" log level? 10:25 Krock or yeah. warning level 10:25 rubenwardy The reading from global uses the warn() function 12:05 Zeno` merging #2255 (get it out of the way) 12:05 ShadowBot https://github.com/minetest/minetest/issues/2255 -- Fix download URL by blha303 12:06 Zeno` (karhl agreed to this and additionally it's a trivial doc change) 13:04 Zeno` What's going on with this feature freeze? 13:10 Zeno` no blockers? 13:10 Zeno` so... 13:14 Zeno` ok, to put it more clearly: what is holding up the release of 0.4.12? 13:25 Krock ping some devs 13:28 Zeno` ping 13:35 Zeno` bool threadSetPriority(threadid_t tid, int prio); 13:35 Zeno` is prio a precentage? 13:52 Zeno` is there any way to get the thread ID? 13:54 Zeno` nvm 14:13 Krock Zeno`, is #2256 acceptable for you? 14:13 ShadowBot https://github.com/minetest/minetest/issues/2256 -- Give full breath after death by SmallJoker 14:15 Zeno` yes 14:17 Zeno` I was looking at that earlier 16:38 Zeno` preparing to merge #2218 16:38 ShadowBot https://github.com/minetest/minetest/issues/2218 -- Suppress 4 gcc 4.9.2 warnings in CGUITTFont.cpp by ngosang 16:38 Zeno` not a bug fix, but it's trivial and fixes warnings 16:50 Zeno` hmmmm, what will it take to get 0.4.12 released? 17:19 rubenwardy #2257 17:19 ShadowBot https://github.com/minetest/minetest/issues/2257 -- Change assignment to global to warning by rubenwardy 17:22 Zeno` I think that should be merged 17:24 Zeno` It's not an "error"... it's a warning that something might be wrong. So it should, IMO, be a warning 17:24 rubenwardy These sound like a blocker: https://forum.minetest.net/viewtopic.php?f=6&t=11145 17:24 rubenwardy And yes, I agree. 17:25 rubenwardy Most importantly, it shouldn't spam the chat console. 17:29 Zeno` you'll probably have to debate with Tesseract ;) 17:30 Zeno` I can't remember the reasoning behind making it an error in the first place 17:32 Zeno` It's obviously not an error. If it was an error then it should abort 17:37 Tesseract Zeno`: I made one of the warnings print to errorstream because it was espacially bad. It's a bug in all or almost all cases and easy to silence in the other ones. 17:37 T4im I've seen false error reports about that already 17:38 Zeno` shadowing parameters in C or C++ is almost always an error as well 17:38 T4im from what I've seen you prepared a way for silencing them, but so far its not silenceable is it? 17:39 Zeno` But, it's (in C or C++) a warning 17:41 Tesseract T4im: No, the error that produces a error just needs a `varname = nil` line somewhere to declare that you're going o be using that global later inside a function. 17:42 Tesseract T4im: There's a warning that's a little harder to silence though. It's still silencable by using rawget directly though. 17:42 T4im but then testing it for nilness is kinda pointless because you know its nil 17:42 Tesseract T4im: The error is for code like this: ... 17:43 T4im I mean something like `if not declared then fallback() end` 17:44 T4im or something like https://github.com/minetest-technic/technic/blob/master/technic/init.lua#L5 17:44 Zeno` hold the horses. If there is a way to silence them then that's further support indicating that it should be a warning and not an error 17:44 Tesseract http://pastebin.ubuntu.com/10057154/ 17:44 Tesseract T4im: ^ That's the only thing that's printed to errorstream and therefore the chat. 17:45 Zeno` also the word "probably" 17:45 Tesseract The `if not foo then` thing can be silenced by `if not rawget(_G, "thing") then`. 17:46 Krock I don't like magical variables, like that _G and rawget 17:46 Tesseract Zeno`: I used errorstream to indicate that it's a serious problem. It could not be a bug, but even if it isn't a bug it should be declared. 17:46 T4im ah, nice.. I tried a few _G tricks, but rawget did the trick 17:46 T4im krock: nothing magical about that 17:47 Tesseract Really, you shouldn't use globals at all, except for the functions from the Lua libs, but we have a bit to do before that will work well. 17:47 Zeno` yeah you shouldn't. But is that advice (a warning) or an error? 17:47 T4im well… the fact that there is a way to "intentionally" test, while finding all accidents… lets say you can call me satisfied :) 17:49 Tesseract Krock: rawget and _G aren't magical, they're just a metatable bypass function and the globals table, respectively. I'd prefer a name like "glogals", but they had to maintain compatability whe they added it and probably wanted to minimize collisions. 17:49 Krock okay :/ 17:51 Tesseract Zeno`: It's closer to an error than a warning since it's at least very bad style if not a bug. 17:51 Zeno` it's terrible style 17:54 Zeno` int main(void) { callFunction(); } (C) is probably bad style as well but it's not an error and it's not even undefined- or implementation- behaviour 17:55 rubenwardy The point is that is confuses users. It's only good for new mods being created. 17:56 rubenwardy The point is that it shouldn't spam the console. 17:56 est31 ^ 17:56 rubenwardy It isn't an error, although it could cause errors. 18:01 Zeno` "could cause errors" 18:01 Zeno` that's a warning 18:01 rubenwardy Exactly 18:09 Zeno` we should add -Wextra -Werror to the compile options :) 18:13 Zeno` sigh 18:54 puhfa hey guys, is max_hear_distance in minetest.sound_play supposed to work? 18:55 puhfa i used 256 as max_hear_distance and 64 for gain, the sound plays globally for everyone at maximum volume 18:55 Calinou 64 gain?! 18:55 puhfa well it was a loud noise 18:55 Calinou gain should usually not be above 1, and certainly not above 2 18:56 puhfa documentation was not too verbose on that aspect :| 18:56 puhfa but thanks, thats probably messing it up then 19:50 Krock Tesseract, what do you think about #2256? I guess that's a bugfix and should be merged soon ;) 19:50 ShadowBot https://github.com/minetest/minetest/issues/2256 -- Give full breath after death by SmallJoker 20:09 Tesseract Others: #2245 and ^ O.K? 20:09 ShadowBot https://github.com/minetest/minetest/issues/2245 -- Fix dying of lava causes repeated death by gregorycu 20:19 VanessaE maybe "dieing in lava" ? 20:19 VanessaE I'm pretty sure no one's applying a color to lava. :P 20:20 crazyR does anyone have a rough idea how long it will be till the lighting issues are fixed with mesh nodes? 20:21 VanessaE ^^^^ especially wield/in-hand mesges 20:21 VanessaE meshes* 20:22 est31 why, when I have a pick in my hand, I dont see it when its dark 20:22 est31 and when there is light, I see the pick 20:23 est31 its weird though 20:23 est31 lights in MT are bad 20:24 est31 eg when I build the whole ceiling full with homedecor glowlights, its still worse than placing the glowlight next to the node 20:25 est31 in RL, there is no "maximum light" 20:26 est31 crazyR: what are the other issues? 20:28 crazyR other issues? 20:29 VanessaE #2150 20:29 ShadowBot https://github.com/minetest/minetest/issues/2150 -- Meshnode ligthing issues create unwanted patterns 20:29 VanessaE may as well properly reference it 20:30 est31 do you know which commit introduced this 20:30 est31 if not I gonna bisect 20:30 VanessaE no, I haven't had a chance to bisect it 20:30 VanessaE but it's probably been there since mesh nodes were available 20:30 est31 ok then /me does 20:30 VanessaE seems to me the solution is simple though: 20:30 est31 there are before/ after images 20:30 VanessaE just give each vertex on a poly the same lighting value 20:30 est31 so there should be some before? 20:31 VanessaE whatever value that is, give them all the same one 20:31 est31 T4im might be interested in discussion bout #2150 20:31 ShadowBot https://github.com/minetest/minetest/issues/2150 -- Meshnode ligthing issues create unwanted patterns 20:31 VanessaE you'll get flat lighting, but it'll look far better than a gradient across a node, then another across its neighbor, repeat ad nauseum. 20:31 T4im yea :) 20:31 VanessaE est31: the "before" images are nodebox-based objects 20:32 VanessaE so invalid as far as lighting on meshes is concerned. 20:32 est31 ah ok 20:32 est31 any source to read about the difference between nodebox and mesh? 20:33 VanessaE idk exactly - there were a couple commits back around the middle of last year that convert all nodeboxes into irrlicht meshes internally 20:33 VanessaE but that's not the same thing 20:38 VanessaE and then after that, if I remember right, there was a fix to the lighting of nodeboxes to at least get the side-shading right 20:38 VanessaE but that won't apply to a mesh node 20:43 kahrl_ can #2150 be reproduced with slope_test? 20:43 ShadowBot https://github.com/minetest/minetest/issues/2150 -- Meshnode ligthing issues create unwanted patterns 20:43 kahrl I tried it and it doesn't happen 20:44 VanessaE kahrl: try rotating some nodes 20:44 VanessaE I think that's what triggers the lighting bugs 20:44 kahrl well they are rotated when I place them 20:44 kahrl but I'll try the screwdriver 20:45 VanessaE the lighting is rotated with the nodes instead of being applied after 20:46 kahrl ok yeah, I see it now 20:46 VanessaE might be a lighting glitch in the models, but in blender they look right 20:46 kahrl perhaps the issue is, once again, normals? 20:46 VanessaE could be 20:46 kahrl in particular that they aren't rotated with the mesh? 20:47 VanessaE that's what I was thinking 20:49 VanessaE a really bad one is pipeworks' spigot mesh 20:49 VanessaE for lighting I mean 20:49 VanessaE flip that one upside down, and what now faces upward will have the worst shadow on it you ever saw :) 20:50 VanessaE (or it did when I last checked) 20:51 VanessaE mm, not so much anymore 20:55 kahrl how many vertices are there per "corner" of the mesh? 20:56 kahrl one (aka one arbitrary-ish normal) or one per incident face (with a different normal for each face)? 20:56 VanessaE well for a basic slope there should only be one 20:56 VanessaE (I started with the standard Blender cube, moved one edge, removed doubles, leaving me with a prism) 20:58 kahrl if you want different normals you need different vertices 20:59 VanessaE hm. well I'm only familiar with how to make the model :) 20:59 kahrl I think if you use just one vertex, blender calculates a "mean" normal from the normals of the incident faces, which isn't really helpful in any way 21:00 kahrl not at sharp corners, at least 21:01 VanessaE maybe my models are just broken then? 21:03 kahrl could be 21:03 kahrl I don't know enough blender to tell you how to fix them :/ 21:03 VanessaE well no, that can't be it 21:03 VanessaE I jsut now checked 21:03 VanessaE just* 21:04 VanessaE in my original slope_test models where the UV-maps call for custom textures, the tiling/lighting is perfect. 21:04 VanessaE in the versions where the only thing I did was change the UV maps so that default textures could be wrapped around them, the lighting is bugged 21:05 VanessaE technic's models are 1:1 copies of slope_test's "_onetexture" models (the ones UV-mapped to use default textures) 21:05 kahrl perhaps you removed doubles in the process of changing the UV coordinates? 21:05 VanessaE with some new ones where I just loaded the model and did a scale-Z "-1" to flip it over, or similar, and rotated the UVs 21:06 VanessaE nope, pretty sure I didn't change the models themselves at all 21:06 kahrl hmm, ok 21:06 VanessaE I would have avoided that, for fear of creating models that didn't tile next to each other perfectly. 21:06 kahrl it's of course also possible that irrlicht's recalculateNormals is bugged 21:08 VanessaE http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2002042015%20-%2004%3a10%3a24%20PM.png 21:08 VanessaE the standard ones are wood, _onetexture (same as technic) is the stone version 21:12 kilbith https://lut.im/SKNSikyb/fmyJIj9t 21:18 kahrl perhaps instead of calling recalculateNormals, the existing normals should simply be multiplied by the inverse transpose of the transformation matrix 21:18 kahrl (since the transformation is just a rotation, the inverse transpose is just the matrix itself) 21:45 VanessaE kahrl: ok, can you clear something up for me? 21:45 VanessaE UVs are supposed to ONLY be for position/size/rotation of the textures on a poly, right? they're not supposed to affect lighting et al? 21:46 VanessaE (that's where normals come into play?) 21:46 kahrl that is correct, afaik 21:46 VanessaE ok 21:46 VanessaE I'm sitting here busting my brain trying to figure out how my models could be screwed up, if they in fact are. 21:46 kahrl (unless you also use a bump map or similar, mapped by uv coordinates, of course) 21:46 VanessaE right, which isn't the case here. 21:48 kahrl I would try to figure it out if I knew how to use blender :/ 21:48 kahrl RBA would probably know 21:48 VanessaE yeah 21:48 VanessaE he'll probably just point to lighting being "faked" in some manner 21:49 kahrl ugh, I can't even install blender because the specific deps it wants conflict with all the other things I've installed 21:49 VanessaE heh 21:50 kahrl I used to have it installed, then this deps problem appeared and since then I don't have it anymore 21:50 kahrl though it might be fixed by now, no dice 21:50 kahrl thought* 23:02 VanessaE kahrl: you see that conversation in #minetest ? 23:04 kahrl VanessaE: yes 23:04 kahrl were there any conclusions yet? it was a bit chaotic 23:06 VanessaE checking now. 23:06 acerspyro Maybe splitting edges won't do it, or maybe it will, since it's not the same UV island 23:07 VanessaE nope, no good.