Time Nick Message 00:18 Zefram_Fysh with recent master, I can't get the label and buttons in the creative form to align at any window size. they're most nearly aligned for large window sizes, but even at fullscreen they're visibly misaligned 00:18 Zefram_Fysh can you show me a screenshot of the aligned state? 00:23 Zefram_Fysh ''tell sapier with recent master, I can't get the label and buttons in the creative form to align at any window size. they're most nearly aligned for large window sizes, but even at fullscreen they're visibly misaligned. can you show me a screenshot of the aligned state? 00:23 HLuaBot I'll tell that to "sapier" next time I see them around. 07:14 realbadangel_ https://github.com/RealBadAngel/minetest/commit/7847614784758b009e41ac4b0a4cea6fb26954e8 07:14 realbadangel_ any comments? 07:19 Zeno` yes, why is continuous_tiles_count cast to f32? 07:20 Zeno` the other values in the expression are double, so I'm not sure why that cast is needed (it will be "recast" to double) 07:23 Zeno` gosh I'm sorry 07:23 Zeno` that's pretty pedantic lol 07:23 RealBadAngel v3f is vector of floats 07:24 RealBadAngel but i touched that line because 2. and changed it to 2.0 07:26 RealBadAngel btw, http://forum.voxelands.com/viewtopic.php?id=256 07:26 RealBadAngel darkrose has nodeboxes with def in meta 07:27 Zeno` well as far as I can see, and for what little it matters, your code looks good 07:27 RealBadAngel using decode_light there was a bug 07:27 darkrose >.> 07:28 RealBadAngel hi darkrose 07:28 RealBadAngel i was just reading that code 07:28 darkrose hi 07:28 RealBadAngel was also lookin at nodeboxes lighting code 07:28 RealBadAngel its quite ok, but have some flaws 07:29 darkrose I need to redo that lightinng code, it's kinda dodgy 07:29 darkrose yeah 07:29 RealBadAngel you can see that on stairs especially 07:29 darkrose the nodebox meta stuff lets me do things like: https://www.youtube.com/watch?v=blfvdffe11w 07:30 RealBadAngel neat 07:30 RealBadAngel that thing is needed to cut down number of nodedef for many things 07:30 RealBadAngel pipes, cables, tubes etc 07:31 RealBadAngel basically all the nodes that previously required multiple defs can become just one 07:31 darkrose yeah, well in voxelands I just add new drawtypes for things like wires and roofs 07:32 RealBadAngel i havent saw the wires yet, theyre already in? 07:32 darkrose in next, will be in the next release 07:33 darkrose pistons: https://www.youtube.com/watch?v=viK1NV96Kyg 07:33 RealBadAngel i wanted to code them but have no time for that 07:34 RealBadAngel btw, highlighting is nice idea 07:34 RealBadAngel way better than selection boxes 07:34 darkrose yeah, I've got it as a setting though... someone claimed the highlighting was hypnotising them o.0 07:35 RealBadAngel rotfl 07:38 darkrose mind you, this is the same person who removes oerkkis because they're against his religion 07:39 Jordach not even ghosts ;) 07:47 RealBadAngel darkrose, bout nodeboxes lights, it should be enough to do some scaling with distance to the edge of full node 07:48 darkrose maybe, the problem is take a slab on top of stone, put a torch on top... the top should be fully lit, but it'd show as dark 07:50 RealBadAngel i need to fix that to have work with current lighting system finished 07:50 RealBadAngel then going to make it optional 07:51 RealBadAngel and strip it down just to light level calculations and work with irrlicht lights 07:51 RealBadAngel effects are pretty promising 07:51 RealBadAngel http://i.imgur.com/wHjL1dJ.png 07:52 darkrose yeah I had a bit of a play with irrlicht lighting a while ago... was cool watching shadows moving around throughout the day 07:52 RealBadAngel that will play nicely with bumpmapping and specular lights 07:53 RealBadAngel but im a bit afraid of one thing i found out, one scene node can have max of 8 dynamic lights 07:55 darkrose yeah, that was ultimately why I stopped experimenting 07:55 RealBadAngel while its not a problem when doing sunlight, it may be a problem to use them for nodes 07:55 RealBadAngel so maybe combination of two light systems will be needed 07:55 RealBadAngel one for torches etc and irrlicht for sun 07:59 RealBadAngel hi PilzAdam 08:00 RealBadAngel PilzAdam, https://github.com/RealBadAngel/minetest/commit/7847614784758b009e41ac4b0a4cea6fb26954e8 08:00 RealBadAngel anything against those fixes? 10:01 sapier Zefram_Fysh: A screenshot with correct alignment on fullscreen was within those where I showed you the wrong alignment, but no problem http://imgur.com/eeaMcGN,tExC4hr,f38B2Kc,Bc7XFKy,9EtZoJz,AO0ODuy,bJbBz9c,Pk7arBt,0nXfr0Q,P5O3gN2,RXpGmth,NXylk2C#10 10:02 sapier Zefram_Fysh: don't rely on hulabot it did fail ... again 10:08 Zeno` Can https://github.com/minetest/minetest/pull/1543 me merged? It doesn't affect make_ltree() calls by mapgen 10:08 RealBadAngel sapier, going to merge this: https://github.com/RealBadAngel/minetest/commit/7847614784758b009e41ac4b0a4cea6fb26954e8 10:08 RealBadAngel any objections? 10:09 Zeno` in fact I'm not even sure mapgen calls make_ltree() at all 10:10 RealBadAngel no, mapgens do not use l-system trees yet 10:10 RealBadAngel v7 is supposed to do so 10:12 Zeno` It shouldn't affect v7 though (if it supplies a seed) 10:13 Zeno` if v7 /doesn't/ supply a seed then that's a different issue (IMO) 10:13 sapier RealBadAngel: hope you know what you're doing ;-) ... wait 10:13 sapier line 274 what happens if light_amount becomes negative? 10:15 Zeno` line 274 of what? 10:15 sapier was talking to rba 10:15 Zeno` that's ok, I'd still like to know :) 10:15 sapier as that situation would be a new reason for a crash, in original code this couldn't happen 10:17 sapier sqrtf(light_amount) ... without making sure light_amount is >= 0 is usually a bad idea 10:20 Zeno` it's not possible for light_amount to be < 0 10:21 sapier why? 10:21 kahrl sapier: wouldn't sqrtf(something negative) just return NaN? not crash? 10:21 Zeno` because 0 <= ambient_occlussion <= 8 10:22 sapier where's that limit enforced? 10:22 Zeno` in the loop 236-258 10:23 sapier kahrl: are you sure rounding clamping and multiplying and passing NAN to irrlicht wouldn't cause a crash? 10:24 kahrl no 10:24 Zeno` it's not "enforced" as such, it's a post-condition 10:24 sapier Zeno`: ok seems to be fine, yet I'd feel better if taht strange "ambient_occlusion -= 4;" would be replaced by mentioning this :) 10:24 Zeno` yeah, or make 8 a constant 10:25 Zeno` and even add an assert() to make it obvious 10:25 sapier well as long as it's ensured within the function Imho an assert isn't necessary but that's a personal preference 10:26 RealBadAngel sapier it cannot be negative 10:26 RealBadAngel if(ambient_occlusion > 4) 10:27 sapier RealBadAngel: sorry but that check doesn't help ;-) 10:27 sapier well not completely 10:28 sapier if ambient_occlusion would be 9 it'd stell be > 4 ... yet a negative value would happen .. but it' can't be 9 as zeno mentioned 10:29 RealBadAngel code runs in my sandbox for 3 days already, havent experienced any crashes 10:31 sapier RealBadAngel: In this special case it can't crash because of the precondidion Zeno`mentioned which I did miss, yet testing is not a proove for correctness ;-) ... btw what's that comment about -4 there? at least I don't understand what it's supposed to tell. maybe it's a relic of old code? 10:32 RealBadAngel idk 10:32 RealBadAngel the equation is still present in voxelands for example 10:32 RealBadAngel here it is commented out for ages 10:33 Zeno` a comment would be nice, but the code is correct 10:34 sapier to me that comment seems to be some old variant of this calculation, but I'm not sure 10:34 RealBadAngel light_amount have values 0-1 10:36 RealBadAngel and ambient_occlusion passed there is in range 5-7 10:39 RealBadAngel ok loop is 0-8, ambient_occlusion start value is 0, it can be increased up to 8 times 10:39 rubenwardy Has there been any investigations / proof of concepts into client side ambient sounds? 10:39 RealBadAngel so the value expressed cannot become negative in any way 10:40 RealBadAngel check is not necesary 10:40 Zeno` I said that earlier RBA :p 10:41 sapier RealBadAngel: yes you're right we already found that out ;-) a comment would be nice to save next one from having to find out again but it'd be not "necassary" as of causing a crash without ;-) 10:41 RealBadAngel yup i know, but i had to check rthat too 10:41 sapier see sqrt(variable) is one of those operations causing a trigger to look at code more close ;-) 10:42 sapier same as / variable 10:42 RealBadAngel what i should comment? that it cannot be negative? 10:42 sapier something like // caclulated before rane 0-7 10:42 sapier range 10:43 RealBadAngel force me to comment the math and i will make a precalculated table for that 10:43 RealBadAngel ;) 10:43 RealBadAngel and we will gain some more cycyles ;) 10:44 sapier I don't force you I do only suggest commenting it as it'd make life more easy for others 10:44 RealBadAngel in fact its a good idea 10:44 RealBadAngel changing it now to const table of floats 10:46 sapier not a problem but tables usually need some comments to explain what they represent too ;-) 10:46 RealBadAngel it can have just three possible values 10:46 RealBadAngel lol 10:46 RealBadAngel 0.25 0.5 and 0.75 10:46 RealBadAngel so nonsense using sqrt here 10:47 Zeno` I'd just write //assert(ambient_occlusion >=0 && ambient_occlusion <= 8) (as a comment) 10:47 sapier quite a small table then ;-) guess comment would be more then table 10:47 RealBadAngel but sqrt is quite heavy 10:47 RealBadAngel reading a table is fast 10:47 sapier Zeno`: doing it that way would make me interpret it as "someone did comment out that assert because it tid hit" ;-) 10:47 Zeno` heh, maybe 10:48 Zeno` sqrt() is not *that* heavy (at least on x86) 10:48 sapier Zeno`: but we do have arm too 10:48 sapier and mips 10:48 sapier ohhh ..... 10:48 Zeno` yeah, I'd have to look at mips. I think sqrt() is an intrinsic instruction for ARM though 10:49 sapier for what I've seen in profiler all those multiplication division operations are quite heavy on arm 10:49 Zeno` but since it's only 8 values a LUT may be ok 10:49 Zeno` ok, I haven't profiled on ARM :) 10:49 sapier well they're not done in draw loop ... they aren't RealBadAngel? 10:50 sapier Zeno`: it's quite amazing how prominent those math calculations are in "top cpu time per function" list on arm ... especially compared to x86 10:51 RealBadAngel sapier, its called pretty often 10:51 RealBadAngel whenever lights are changing 10:51 RealBadAngel that includes change of daynight ratio 10:54 sapier hmm well the original code wasn't exactly "lightweight" too 10:55 sapier 5 multiply operations to 1 mp + sqrt .. on first glance I'd guess a slight benefit for new variant 11:03 RealBadAngel new one is twice as fast 11:04 RealBadAngel and the next will even more faster 11:04 RealBadAngel ambient_occlusion -= 5; 11:04 RealBadAngel const float light_amount[4] = {0.75, 0.5, 0.25, 0.0}; 11:04 RealBadAngel light = core::clamp(core::round32(light*light_amount[ambient_occlusion]), 0, 255); 11:09 RealBadAngel ah, just need to put there sqrt of those values ;) 11:10 sapier ok but please add comments ;-) 11:13 RealBadAngel for comments make any sense i should leave original code propably 11:15 RealBadAngel https://github.com/RealBadAngel/minetest/compare/lights1#diff-c2f90db5de8c33a259c27113939c63c5L273 11:16 sapier not sure but is there a way to make preprocessor calc those strange numbers from better ones? 11:17 sapier and now you really have to explain why ambient_occlusion -= 5; ;-) 11:17 RealBadAngel ok, will do that 11:18 RealBadAngel anyway i have to recalc those values, theyre not really correct 11:18 RealBadAngel pow here was 2.2 not 2.0 11:18 RealBadAngel so its not really sqrt here 11:18 sapier as I said if preprocessor yould do this it'd be better if not you should add a comment how they are calculated 11:20 Zeno` I have an announcement 11:20 Zeno` I haven't frequented this channel for very long, but this is the first time I've seen proper feedback and constructive crit. I like it. 11:21 Zeno` Announcement over. I may get drunk now. 11:22 RealBadAngel hehe 12:17 sapier https://github.com/minetest/minetest/pull/1561 plz review, I fixed the remaining glitches (named top left and progress bar beeing cut on high dpi) ... formspecs are still broken on high dpi settings bu that's topic of Zefram_Fysh's work 12:18 sapier https://github.com/minetest/minetest/pull/875 ShadowNinja what's your opinion on this? 15:21 sapier https://gist.github.com/sapier/de28cd52166453ce7e54 comments? it's supposed to avoid calling a playerevent without actually having a player to do an event for 15:21 sfan5 looks ok 15:27 sapier ok pushing that small fix 20:50 RealBadAngel sapier, https://github.com/RealBadAngel/minetest/commit/24efa37231113c1411c4002f14fb76d81511c8cc#diff-c2f90db5de8c33a259c27113939c63c5L273 20:51 RealBadAngel https://github.com/RealBadAngel/minetest/commit/bf8fc9b39e191879edd75985aa33a3180c15587c#diff-c2f90db5de8c33a259c27113939c63c5R270 20:51 RealBadAngel oops, wrong link before 20:53 sapier seems to be fine 20:57 RealBadAngel ok, so merging it and will code now improved lights for nodeboxes and special drawtypes 20:58 RealBadAngel kinda like that one by darkrose but i hope without flaws 21:05 iqualfragile RealBadAngel: oh, that would be wonderfull 21:05 * VanessaE peeks in 21:21 zat Guys, someone knows what are the humidity_point and heat_point supposed to mean? In respect to, are they equivalent to air humidity percentage and celcius degrees respectively? 21:24 sapier zat for what I know humidity doesn't exist any longer 21:24 zat sapier: in v7? 21:24 zat how so 21:24 sapier ah v7 ... ok that's something different 21:25 sapier guess I was mixing up things 21:25 zat isn't hmmmm working on it? (ping) 21:26 proller s/working/worked/ 21:26 hmmmm don't use it, it's not meant for end-users 21:26 zat hmmmm: I am making the biomes definitions. 21:28 VanessaE hmmmm: Zeno` was looking at the mapgen code the other day trying to sort out that vmanip vs. set_node() issue. might have a clue to it. the code seems to be passing the same map state/data to all on_generated() calls e.g. one read from the map, pass it to everyone. sound right to you? 21:29 hmmmm yes... how is that news 21:29 hmmmm i explained that 500 times 21:29 VanessaE because now it makes sense? :P 21:29 VanessaE and it explains the whole problem. 21:29 hmmmm no, it still makes as much sense as it did back then 21:29 zat hmmmm: but do you know what are the real world equivalent for these values? 21:29 hmmmm zat, there is no real world equivalent. 21:29 zat proller: who is currently working on it? 21:30 zat hmmmm: its just 0 to 100 then? 21:30 proller zat, nobody 21:30 zat proller: so abandoned? 21:30 hmmmm yes, 0 to 100. 21:31 zat hmmmm: I am going to consider them from 0 to 100% humidity and 0 to 100% of 0 to 100°C. 21:32 hmmmm great 21:32 VanessaE hmmmm: well anyways I guess the proposal now is to have the engine mark a mapblock as dirty (not unlike what you proposed when this was last discussed) but have the writeback occur before the next pass through the loop that runs all the on_generated callbacks 21:32 VanessaE i.e. transparent to the mods that use that callback 21:33 hmmmm vanessae, I don't understand. what are you suggesting was the problem? 21:33 VanessaE hmmmm: well remember how we thought it was mod A reads, mod B reads, mod B writes, then mod A writes? 21:33 hmmmm we thought? 21:33 VanessaE and how that was totally impossible?" 21:33 VanessaE we being zeno and SPlizard and so forth, not you 21:33 hmmmm which mod is using set_node/get_node, and which mod is using voxel manip 21:33 hmmmm A or B 21:34 VanessaE snow mod, mtz, paramat's mapgens all use vm's. call any one of those "mod A". plants_lib uses set_node, that's mod B. 21:35 VanessaE well of course that's not what was happening. it's just that A and B were both starting with the same clean map state and it just happens that A was being executed last. 21:35 VanessaE which is useless in either case because maybe B needs some of the *modified* map that was generated by A 21:35 hmmmm so in other words, I was right about everything and you were mistaken about the order in which the mods were executed 21:36 VanessaE no 21:36 VanessaE order didn't matter 21:36 hmmmm the order does matter 21:36 VanessaE if they both start with the exact same clean map state, then they are both gonna try to write that same clean map 21:36 twoelk random at it's best ;-P 21:36 VanessaE meaning that one can't possibly have a chance to modify the other's results 21:36 VanessaE i.e. I can no longer add trees to snow mod's biomes because of this 21:37 VanessaE because I will never see snow mod's biome data. I will only ever get to see the mapgen's default data - the self same data that snow mod gets from the mapgen 21:37 VanessaE (mgv6) 21:37 hmmmm the only order in which this works okay is if the mods using voxelmanip execute first 21:37 hmmmm and then the get/set node ones do their thing after 21:37 VanessaE but if they do that, then I never get to see their modified map 21:37 VanessaE s/I/mod B/ 21:37 hmmmm the order that causes problems is if you were to run a mod that uses get/set node first, and then a voxelmanip mod runs after 21:37 VanessaE no 21:37 hmmmm ?? 21:37 VanessaE either order will fail 21:38 hmmmm why would the first circumstance fail 21:38 VanessaE because both mods are getting the exact same map data 21:38 VanessaE i.e. a mapblock full of dirt, stone, trees, etc. 21:38 VanessaE snow mod modifies it, saves it. but then plants_lib will never get to see it 21:38 VanessaE plants_lib only ever gets to see that same dirt/stone/trees mapblock that was given to snow mod 21:39 hmmmm plants_lib meaning the get/set_node mod 21:39 VanessaE yes. 21:39 hmmmm and snow mod being the vmanip one 21:39 VanessaE yes. 21:39 hmmmm now why is that 21:39 VanessaE that appears to be why it fails. 21:39 hmmmm but how does that make any sense 21:39 hmmmm how do they "see the same map" 21:40 VanessaE I don't know, I'm going by what Zeno saw in the code - appearently there's one map read that's then passed to all on_generated callbacks 21:40 hmmmm yes.. that one map read is the voxelmanip read 21:40 VanessaE yes. 21:40 VanessaE and then it enters the loop that runs all the on_generated callbacks 21:40 VanessaE and never writes their results back to the map until after the loop complet 21:40 VanessaE completes* 21:41 hmmmm set_node writes back to the map immediately 21:41 hmmmm the results of get_node are the map as it is right then at that state 21:41 VanessaE but not if a vmanip is involved. 21:41 hmmmm that doesn't make any sense though 21:41 VanessaE I know it doesn't. 21:42 hmmmm look, I never even observed this bug by myself so I am going 100% based off of what you're reporting 21:42 hmmmm all of this is speculation as far as i'm concerned 21:42 VanessaE not just me. zeno confirmed the same on one of his mapgen mods too 21:42 VanessaE SPlizard also 21:42 VanessaE and someone before him was the first to report it 21:43 VanessaE he had to rewrite his mapgen mod to not use vm's just so it could work alongside plants_lib, which btw just does two on_generated calls now. 21:45 VanessaE so anyway my theory here is that there's one last vm that's "pending" at the end of the on_generated loop, that gets written out finally, and that it contains the results of whatever was done in the meantime, but only if a vm was used and only the results thereof 21:45 VanessaE but since I can't really read C++ too well I can only speculate as well. 21:46 VanessaE s/he had to/zeno had to/ 21:55 VanessaE I just figured I'd grab your ear before you had a chance to wander off :P 21:56 VanessaE since Zeno` won't be showing up for a while yet. 22:00 paramat VanessaE, have you tried snow mod plus plants_lib since you speeded up your plants_lib code? sometimes i have seen weird results if one mod is very slow 22:00 VanessaE paramat: not since then, no. 22:01 paramat i haven't seen your bug but then i don't often run mods together 22:01 VanessaE the only functional difference, from that standpoint, is that plants_lib registers only 2 mapgen hooks (and around 40 actions) instead of 120-ish. 22:02 paramat i was considering your use of 'find nodes in area' might have been the slow code? 22:03 paramat 'find nodes near' was always very slow for me even with a small radius 22:04 VanessaE it's the fastest way to grab a chunk of map data while being able to filter it by node name 22:04 VanessaE else I'd have to use a vm and compare every node manually. 22:05 paramat perhaps use dependancies to have snow mod run first 22:05 VanessaE tried that. 22:06 VanessaE snow mod has a hack in place to disable its mapgen code outside of its own biome areas, but that still means I can't e.g. add trees and dry grass on a snow biome. 22:14 paramat zat, mgv7 heat is from -25 to +75 so you can think of it as celcius if you want 22:14 paramat humidity is from 0 to 100 so i would consider that %humidity 22:15 proller heat is from -25 to +75 - wat ?? 22:15 VanessaE just don't go trying to calculate a dewpoint from it :P 22:15 proller nparams_biome_def_heat(50, 50, 22:20 zat uh? 22:20 zat paramat: are you sure 22:22 paramat oh i was going by .conf 'mgv7_np_heat = 25, 50, (500, 500, 500), 35293, 1, 0' 22:23 paramat thats latest git 22:24 paramat biome definition docs may be out of date 22:28 proller and its working? 22:31 Zefram_Fysh screenshots and analysis on label/button alignment with my form patch now available at http://www.fysh.org/~zefram/tmp/form_align.html 22:31 paramat '25, 50' are offset and scale so unless that's a typo heat will be 50 either side of 25 22:32 paramat ... but only because there's 1 octave 22:34 VanessaE Zefram_Fysh: looks good 22:36 proller paramat, and this setting working ? 22:38 proller Zefram_Fysh, what about 240x240 screen ? 22:40 VanessaE what are you playing on, a VC-20? :P 22:40 paramat proller i can't be bothered to test 22:40 proller no, its smallest available androids 22:42 VanessaE what, a smartwatch? 22:42 VanessaE what moron would play MT on a one of those? 22:43 * proller . 22:43 VanessaE still I think it's pretty clear that the formspec scaling will fit those small screens also. 22:44 VanessaE the HUD will be a problem at that size 22:44 VanessaE but that's not a formspec and not what this patch addresses. 23:11 zat VanessaE: I am one of those morons apparently. 23:11 VanessaE :) 23:12 sapier VanessaE: if dpi is set correct hud will scale to same factor ... so only dependence is quality of your glasses ;-) 23:12 VanessaE well enjoy your 2px tall fonts I suppose. seems like it would be impossible to play what you can't see :P 23:12 VanessaE sapier: heh 23:13 VanessaE you're still a moron for trying to play games on a smartwatch ;) 23:13 sapier hmm ok sorry but smallest font size to be provided for non ttf will be 4 23:14 VanessaE sapier: no TTF on android? 23:17 sapier for what I remember our offical build uses freetype but that's not a must have 23:17 VanessaE hm ok 23:17 VanessaE well seems like you'd want that on android 23:20 sapier actually the non ttf fonts never would've been that bad if someone did spend just a little bit more time on implementation ;-) 23:25 Zefram_Fysh I selected 500x400 as the smallest size for my screenshots simply because at the next size down that I would have used the old code didn't scale the form down to fit, so the part I was interested in wasn't in the shot. my patch incidentally makes the code more willing to scale forms down, but really you'd want to reduce gui_scaling if you're on a screen as small as 240x240 23:26 sapier Zefram_Fysh: any reason why you didn't do any screenshots with current default window size? ;-) 23:28 Zefram_Fysh I wanted to use a consistent aspect ratio. to get screenshots the windows all had to fit on my screen, which is a 5:4 aspect ratio, so to get a shot with as many as 1000 lines I was constrained to use my screen's aspect ratio. that's all 23:33 sapier not showing the default size is ... well ... doubtfull 23:35 sapier still I'll support your version anyway because it's best chance to get scaling fonts in anytime soon