Time Nick Message 10:27 sapier https://github.com/minetest/minetest/pull/1304 any comments or good to merge? 10:28 sapier https://github.com/minetest/minetest/pull/1457 pushing in a few minutes, it's been agreed on days ago but I didn't manage to push by now 10:30 * Calinou idiocracy-check 10:30 Calinou passed 10:33 Krock those pulls looks good 10:33 Krock -s 10:40 sapier https://github.com/minetest/minetest/pull/1468 I'd like to cleanup and merge this one, basically I'd remove the removal of leveled api and completely cleanup freezmelt 10:40 sapier comments? 10:42 Krock yes. leveled is used by snow 10:42 sapier ok freezmelt seams to be already dead so cleaning up most likely wont break anything 10:42 sapier seems 10:43 Krock I would agree to delete freezemelt and "year_days = 30" in the example file. leveled should stay 10:43 sapier that's what I intended to change about it 10:43 Krock great 10:45 sapier but first I'm gonna merge some simple pulls 10:46 sapier merging https://github.com/minetest/minetest/pull/1477 already agreed by two core devs 10:46 sapier ok actually 3 if you count me too 10:47 Krock hmm, I still wonder about line 711 on the bottom 10:48 Jordach has anyone noticed while trying to connect to any server that sometimes you'll connect and get stuck in this grey world? 10:48 Krock removing a file when rename returned a success... 10:48 Krock Jordach, every 2nd connect to my local server 10:49 Jordach Krock, my VM is random 10:49 PenguinDad Krock: rename returns zero on success 10:49 sapier Jordach: that's a known issue for some minetest client/server combinations whats your combination? 10:49 Krock PenguinDad, and false on fail? 10:49 Jordach sapier, VanessaE's survival server, VM BFD server 10:49 Jordach and it'll stay in this void world until it either connects or times out 10:49 sapier ohh 10:50 Krock I ask because there's just a "if" forboolean values 10:50 sapier then it may be another issue 10:50 Jordach sapier, even locally it's randomised 10:50 sapier since players aren't loaded on startup a player can be immediatly deleted because of block beeing full and player object can't be added 10:51 PenguinDad Krock: http://www.cplusplus.com/reference/cstdio/rename/ 10:51 Jordach sapier, my last pos on VE's server was ~-17km underground 10:51 sapier if you have this case you should see one of those famous maxe objects messages 10:51 Jordach with no objects in range 10:51 sapier are you sure about that? ;-) 10:51 Jordach sapier, she's removed all mobs 10:51 Krock PenguinDad, still. it doesn't return boolean 10:51 sapier yes but e.g. items from digging 10:52 Jordach sapier, there aren't any things in that tunnel down 10:52 sapier ok then I'd guess we've got a new issue 10:52 Jordach (i remove dropped items and trash lots of cobble methodically) 10:52 Jordach and while we're at it, why does the password field in client randomly access violation on hitting enter 10:53 Jordach https://cdn.mediacru.sh/mUbnl1fjionf.png 10:54 Jordach that's where i am, and there's nobody else or other objects at that range 10:54 PenguinDad Krock: 0 is false in c++ 10:55 Krock PenguinDad, stupid but okay... thx 10:55 sapier Jordach: I suggest creating issues for those issues as I can't fix them on the fly ;-) 10:56 Krock I noticed, it _always_ throws 2 access violation when I enter my password for my server... 10:58 sapier as it's reproduceable I suggest running mt in gdb and providing a full backtrace ... could help finding it 10:58 PenguinDad does gdb work on windows? 10:58 Krock > gdb 11:01 sapier but gdb is only usefull on mingw build windows ;-) 11:01 sapier maybe not even there as official one is without debugging symbols 11:16 sapier can someone knowing l-systems code check this one https://github.com/minetest/minetest/pull/1543 ? 11:50 RealBadAngel sapier, give me a minute 11:50 sapier you get two minutes ;-P 11:50 RealBadAngel no, i dont need to 11:51 RealBadAngel the code is ok 11:51 RealBadAngel problem was with squashing them 11:51 sapier can we merge it the way it is now? 11:51 RealBadAngel if you solve two commits per pull problem, then yes 11:52 RealBadAngel and nobody else here knows l-system code, just me 11:52 RealBadAngel zeno is the only one that got it 11:53 sapier why? it's two different things for what I understood for this issue two commits are fine 11:53 RealBadAngel i was told once and for all, that a pull has to be single commit 11:53 PenguinDad sapier: your last commit messed up inventory textures for me https://cdn.mediacru.sh/6LctUsHwhllp.png 11:54 sapier what's messed up there? 11:55 PenguinDad sapier: look at the obsidian glass 11:55 RealBadAngel sapier, i would like to push a few quick bugfixes, will you find a minute to review them? 11:55 sapier sorry I don't know what "obsidian glass" is and how it should look like ;-) 11:58 sapier can you show me what's wrong? 12:00 PenguinDad this is how the inventory textures should like https://cdn.mediacru.sh/KGXWClSQZVcG.png 12:01 sapier hmm 12:01 sapier seems like cleanup fails 12:06 sapier wonder why this doesn't happen for me ... can you try adding: 12:06 sapier driver->draw2DRectangle(video::SColor(0,0,0,0), core::rect(0, 0, 64, 64)); 12:06 sapier to tile.cpp line 870? 12:08 RealBadAngel btw, why the heck sandstone stairs/slab is breakable by hand? 12:08 casimir because sandstone is 12:09 RealBadAngel why? 12:09 RealBadAngel since when one could dig STONE with bare hands? 12:10 sapier depends of variant of sandstone ;-) 12:10 PenguinDad sapier: that doesn't help 12:11 RealBadAngel sapier, propably only mt variant can be dug with hands ;) 12:11 sapier PenguinDad: in this cas I'm just gonna revert it and forget about that fix as preloading is disabled by now the issue became way less important 12:12 sapier hmm wait ... 12:12 sapier maybe drawing is just wrong 12:13 sapier can you set 64, 64 to 800,600 (or what ever your screensize is) ... just for testing not as fix 12:17 PenguinDad When I do that it's even more messed up 12:18 sapier ok was worth a try let's forget about that fix 12:19 sapier reverted 12:21 RealBadAngel is github workin for you? 12:23 sapier yes 12:39 RealBadAngel sapier, https://github.com/RealBadAngel/minetest/commit/c8c203c35497d7ed8b3382df966dd7ef0ff525ff 12:40 sapier is there any visual difference? 12:40 RealBadAngel please note that finalColorBlend in shaders is already deprecated, in ::animate its done on CPU side always 12:40 RealBadAngel no, there isnt 12:40 RealBadAngel but youre free to try 12:41 RealBadAngel only difference is more FPS when shaders enabled 12:41 sapier well without knowing where to look I'll not find it anyway ... as it's way less code merge it 12:41 RealBadAngel point is CPU one is done only on ratio change 12:41 RealBadAngel while on GPU its calculated on each render pass 12:42 RealBadAngel if some1 will stop the time flow, it will be done just on mesh refresh 12:44 sapier sounds like a good idea 12:44 RealBadAngel https://github.com/minetest/minetest/blob/master/src/mapblock_mesh.cpp#L1332 12:44 RealBadAngel heres ::animate 12:44 RealBadAngel as you can see its already done CPU side always, no matter if shaders are used 12:52 RealBadAngel next one: https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L381 and https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L222 12:53 RealBadAngel first is flowing liquid, second source 12:53 sapier sorry but how shall I check the diff from lines ? 12:54 RealBadAngel first have that code that makes liquids that are light sources glow or adapt to surrounding nodes 12:54 RealBadAngel second doesnt 12:54 sapier come one rba do at least a git diff and post it to gist 12:54 RealBadAngel im showing you current state 12:55 RealBadAngel somebody who made the code for flowing ones, forgot bout sources 12:55 sapier you don't need to I already agreed to that https://github.com/RealBadAngel/minetest/commit/c8c203c35497d7ed8b3382df966dd7ef0ff525ff change 12:56 RealBadAngel sapier, im talkin now bout another issue 12:56 RealBadAngel next one: https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L381 and https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L222 12:56 RealBadAngel this is code for liqiud drawtypes 12:56 sapier that's what I meant with diff 12:57 RealBadAngel ok, i will prepare the pull, hold on 12:57 sapier you wrote it you know what you did change but I don't know and a single line number won't tell me ;-) 12:57 RealBadAngel huh i pasted you links to unchanged code for you to see thats bwoken ;) 12:58 RealBadAngel the second shall have the very same code as first does 12:59 sapier am I supposed to reevaluate whats broken if you already found out? ;-) 13:00 RealBadAngel nah, i will just prepare it 13:00 sapier ok :-) 13:02 RealBadAngel btw, thats gonna fix acid liquid issue from Carbone 13:05 RealBadAngel i do have quite long list of bugfixes for today ;) 13:05 sapier well if you did start creating pull requests ppl could have a look for them 13:05 RealBadAngel problem is all are in very same files 13:06 sapier one pull multiple commits ... allowed for minor changes 13:06 sapier at least if all of them are bugfixes and not feature changes ;-) 13:07 RealBadAngel for features i do have pulls open 13:08 RealBadAngel thx to that folks can test them 13:08 RealBadAngel and im not in hurry with them 13:10 RealBadAngel btw nice to see 60fps on my box again 13:25 sapier https://github.com/minetest/minetest/pull/1475 comments? vanessaE is running this on her servers for some days now (unless she forgot to reapply on update) ... reduces felt lag drastically 13:41 sapier https://github.com/minetest/minetest/pull/1491 pushing in a few minutes 13:42 eugd test 13:43 sapier well you won't see anything on pc version ;-) 13:43 sapier at least until https://github.com/minetest/minetest/pull/1490 is merged too 13:43 sapier eugd: read log ;-) 13:46 sapier hmm no I was wrong :-) you can see it as "fixed" size is broken 13:52 sapier https://github.com/minetest/minetest/pull/1490 comments? this is a visual change so it's most likely be controversion yet it's improving consistency quite a lot 13:53 RealBadAngel sapier, offtopic, i need separate tab for shaders 13:53 sapier original reason not to scale menu was because of gui elements not scaling itself as we added it we don't need that workaround 13:53 sapier no 13:53 RealBadAngel theres no place left 13:53 sapier settings need to be cleant up anyway 13:53 sapier I suggest adding subtabs 13:53 RealBadAngel could work 13:54 RealBadAngel i need to add about 10+ settings 13:54 sapier does work http://animalsmod.bplaced.net/screenshots/v2_4/new_menu/multilevel_tabs.jpg 13:54 RealBadAngel theres place for one or two more 13:55 RealBadAngel that looks ok 13:55 sapier maybe we need to update fstk as did some bugfixes to use it from ingame 13:55 sapier but those are minor changes 13:56 sapier if you need it I'm gonna merge it back to my fstk pull 13:56 RealBadAngel i want to add contrast, brightness, gamma, parallax settings, bumpmapping settings, lava/water shaders settings (whole bunch of them) 13:56 sapier ok I'm rebasing that pull including latest fixes from mobf 13:57 sapier pushing table scrollbar scaling now 13:59 RealBadAngel btw, Calinou did great job with dirt with grass node 13:59 RealBadAngel i like its look 14:00 sapier https://github.com/sapier/animals_modpack/blob/master/mobf_settings/tab_info.lua is an example how subtabs work 14:01 RealBadAngel http://i.imgur.com/PJO3WVS.png 14:01 sapier https://github.com/minetest/minetest/pull/1343 these are the changes required for them to work ... actually it's a little bit more, with this changes you could use fstk in game too 14:02 RealBadAngel thx, gonna use that example 14:02 RealBadAngel so merge it, we need them 14:03 hmmmm oh man 14:03 hmmmm so it's official, you're making a Lua irrlicht widget toolkit 14:03 RealBadAngel lol 14:03 sapier hmmmm did you miss it's already in? ;) 14:03 hmmmm wow 14:03 hmmmm all i can say is great job 14:04 sapier whole menu is based upon it as I was annoyed about writing same code for each tab over and over again 14:04 hmmmm but overkill... if I were you I would've been looking to integrate a pre-existing OGL widget toolkit 14:04 RealBadAngel hello hmmmm 14:04 hmmmm the job of minetest is to be a game 14:04 hmmmm hi RBA 14:04 hmmmm minetest sucks 14:04 RealBadAngel hmmmm, could you at least do something with jungle grass? 14:04 hmmmm I should definitely do something 14:04 hmmmm I feel like a useless sack of shit who doesn't contribute anything 14:05 sapier well it's been way more easy to improve main menu then rewriting everything based uppon a new toolkit ... not even talking about the discussions ;-) 14:05 RealBadAngel hmmmm, all of us have such "periods" ;) 14:05 sapier I did rewrite menu once ... I know what I'm talking about ;-) 14:05 hmmmm jungle grass.... 14:05 RealBadAngel yup 14:05 hmmmm hrm 14:05 RealBadAngel move it to lua side 14:05 hmmmm I'd have to make an override to explicitly set the blockseed offset for a decoration 14:06 eugd it's obvious menu should be lua side 14:06 hmmmm and I'd also have to somehow make it share the same perlin noise as the jungle trees 14:06 RealBadAngel so move the trees too 14:06 hmmmm agh 14:06 RealBadAngel jungles are kinda exception rite now 14:07 RealBadAngel thus not moddable 14:07 hmmmm but 14:07 hmmmm they are disable-able 14:07 RealBadAngel but thats not the point 14:07 hmmmm I need to spend time coming up with an elegant non-hack solution to this 14:08 hmmmm also I think decorations somehow got foobared a while ago 14:08 RealBadAngel start with trashing c++ code, and do that in lua from scratch, like other things are done 14:08 hmmmm did you notice how cacti gather up in clumps 14:08 RealBadAngel yup, i know the code 14:08 hmmmm they USED TO WORK FINE until somebody messed around with something 14:09 RealBadAngel you really should develop decorations for v7 14:10 RealBadAngel v6 is too messed up 14:10 RealBadAngel see caves for example 14:10 RealBadAngel i cant believe theyre carved in CONTENT_IGNORE 14:10 hmmmm that is not messed up 14:10 hmmmm that's how it's supposed to work 14:10 hmmmm is it causing problems? 14:10 RealBadAngel ofc it is 14:10 hmmmm how 14:10 RealBadAngel see the checks 14:10 hmmmm the checks? 14:11 RealBadAngel theyre checking for water, lava and air 14:11 RealBadAngel yes? 14:11 RealBadAngel to let the cavegen do anything 14:11 RealBadAngel but 14:11 hmmmm ☑ ☑ ☑ 14:11 RealBadAngel theres no block generated yet 14:11 RealBadAngel so theres no water/lava/air yet 14:11 RealBadAngel check hits the floor 14:11 hmmmm yes 14:11 hmmmm can you come up with something better 14:12 hmmmm I sure can't 14:12 hmmmm this problem will sorta just go away when I add in the perlin noise defined caves in v7 14:12 RealBadAngel dont let cavegen operate on non existant block simply 14:12 hmmmm you get walled-off caves then 14:12 sapier hmm didn't I have some get_surface pull request by some time 14:12 RealBadAngel wait a second 14:13 hmmmm what would you rather, occasional messiness with lava and water, or a horizontal, straight wall of stone spanning the entire boundary of the chunk 14:13 RealBadAngel caves are made on perlin, right? 14:13 hmmmm they aren't right now 14:13 hmmmm they're based off of pseudorandom 14:13 RealBadAngel oh i see 14:13 hmmmm that is the issue 14:13 RealBadAngel now i get it 14:13 hmmmm you can't poll a specific location to see if part of a cave is present 14:14 RealBadAngel so they should be 14:14 RealBadAngel and then overlayed but only on existing blocks 14:15 casimir sapier: on #1490 the left handed text starts to disappear when increasing the window size. 14:15 RealBadAngel this way checks for content will have sense 14:16 RealBadAngel and we wont have caves in the air 14:17 RealBadAngel https://github.com/minetest/minetest/blob/master/src/cavegen.cpp#L251 14:17 RealBadAngel https://github.com/minetest/minetest/blob/master/src/cavegen.cpp#L266 14:17 RealBadAngel by now above checks are obsolete 14:18 RealBadAngel they never find air 14:18 sapier haven't caves in air been intentionally to make surface more interesting 14:18 sapier thanks casimir I'm gonna recheck 14:18 RealBadAngel only check for content ignore can stop the code 14:19 RealBadAngel thats why i made this pull: https://github.com/minetest/minetest/pull/1554 14:20 RealBadAngel but it really cuts off caves to surface, havent thought about nyanlands ;) 14:21 RealBadAngel btw, hmmmm, v7 does pretty the same but in other way 14:21 RealBadAngel there are no floating caves in v7 14:23 sapier RealBadAngel: didn't you have issues with vertlabels lately? 14:28 hmmmm what?? 14:28 hmmmm RealBadAngel, no 14:38 hmmmm see my recent comment on the pull request 14:38 hmmmm i need to go right now 14:38 hmmmm later 14:41 sapier casimir can you check again? I fixed vert label scaling 15:03 VanessaE ob G*d someone PLEASE do something about these hangs in minetest_game 15:04 VanessaE this is getting out of hand. 15:04 VanessaE oh* 15:04 casimir sapier: it works now 15:05 sapier VanessaE RealBadAngel any problems with making main menu scale? 15:06 VanessaE sapier: that's in mainline now? 15:06 sapier not yet 15:06 VanessaE link? 15:06 sapier https://github.com/minetest/minetest/pull/1490 15:06 VanessaE just found it :P 15:07 RealBadAngel sapier, im on the bugs right now, will play with menu propably tommorow 15:07 VanessaE sapier: one minute, lemme give it a shot. 15:08 sapier as font size and other gui components now scale to dpi fixed size main menu has issues. And those things not scaling have been initial reason for not scaling the menu 15:08 sapier well RealBadAngel as this is a gui change I already expect someone to complain right after merge ;-) 15:08 sapier no matter when it's merged 15:08 VanessaE http://xkcd.com/303/ 15:09 VanessaE wow 15:09 RealBadAngel sapier, we are developing soft, nobody expects dev to be stable 15:10 VanessaE sapier: the scaling seems to work, but there's one caveat: the spacing between elements doesn't really look good. 15:10 sapier "nobody expects dev to be stable" I'll quote you ;-) 15:10 VanessaE about the pause menu: frankly, it's too big with my window maximized. 15:11 sapier did you maximize manually or per config file? 15:11 VanessaE manually. 15:11 VanessaE sapier: what I mean is, for example, the size of a button doesn't change, only its position does. I'm not sure this is desireable 15:11 sapier there's a mayor difference 15:11 sapier font size can#t be changed on the fly by now 15:12 VanessaE I never use the config file to set window size. 15:12 VanessaE wait, let me qualify that: 15:12 VanessaE the HEIGHT of the buttons doesn't change 15:12 VanessaE but the width does. 15:12 VanessaE and the spacing between them does 15:12 VanessaE as well as the size of elements like list boxes et al. 15:12 sapier yes because height depends on font size 15:13 VanessaE I'm not sure if the overall effect is desirable. 15:13 sapier in current menu you'll not be able to read text if you set screen to maximized via config 15:13 VanessaE the pause menu is definitely way too big: LOTS of wasted space there. 15:14 sapier even if you set per config? 15:15 VanessaE ? 15:16 sapier screenW/screenH .... hmm maybe it'd be more easy to find a way to fix the fonts too ... give me a couple of minutes 15:16 VanessaE um 15:16 VanessaE that's stupid. 15:16 VanessaE I'm not gonna set those values. 15:16 sapier well try it ;-) right now menu is gonna be broken if you do ;-) 15:17 VanessaE no, better to just disable menu scaling on PCs 15:17 sapier that won't change the menu beeing broken because fonts still scale 15:17 VanessaE it makes sense on tablets, but not on PC, frankly. 15:17 VanessaE or maybe some kind of scale-to-fit would make more sense on a PC\ 15:17 sapier did you realize theres 4k screens getting more and more popular on pc too? 15:18 VanessaE yes but 99% of PC users don't have 4k screens 15:18 sapier you don't wanna have a fixed size 6cm menu on that screen 15:18 sapier still why criple a feature we already haveß 15:18 VanessaE I would venture a guess that most PC users have a 1920x1080 screen or smaller. 15:18 VanessaE I'm not saying to cripple it. 15:18 sapier "most" is not a reason to criple it on high end machines 15:18 VanessaE I'm saying that this implementation will not work into the future without some way to "fill" all of that unused space. 15:18 sapier especially if current way of doing it is briken 15:19 VanessaE the pause menu has no reason to be scaled at all except to fit the font, simply. 15:19 sapier but it doesn't fit the font 15:19 VanessaE I know. 15:20 VanessaE the main menu, on the other hand, definitely needs to have its elements fill it. for example the world list and server list should take up the majority of their respective tabs. 15:20 sapier because you need to change the distances too just making a button bigger for bigger fonts doesn't help 15:20 VanessaE instead, you have all this wasted, blank space around the buttons 15:20 VanessaE and all that blank space to the right of the server list, above the name/password field. 15:20 sapier come on vanessaE set screenW and screenH and have a look at it then you know what I'm talking about 15:20 VanessaE grrrrr 15:21 sapier you'd be first to complain about "broken menu" if it was you used to set your window size that way 15:21 VanessaE no effect. 15:22 sapier do a screnshot ;-) 15:22 VanessaE looks the same whether I maximize using my window manager or with those values 15:22 sapier what's your screen size? 15:23 VanessaE ok, one secong. 15:23 VanessaE second* 15:24 VanessaE 1600x1200, two screens. 15:25 VanessaE ok, on the left is 1560x1180 set via the config file. on the right, no setting at all and simply maximized via my window managerhttp://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/minetest-maxi.png 15:25 VanessaE oops. hit enter too soon,. 15:25 VanessaE http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/minetest-maxi.png 15:25 sapier hmm seems there's another bug because for me it looks this way 15:26 VanessaE I set the size slightly short of my actual screen size int he left image to account for the window manager's decorations 15:27 VanessaE which way? 15:29 sapier http://imgur.com/0jLxCqA,QzhXsIO this is how it looks for me without the patch 15:29 VanessaE yes, that's consistent with mine also except of course I use a larger font (bad eyes) 15:30 VanessaE consistent without the patch that is 15:30 sapier well did you see the captions on text boxes overlaying buttons? 15:30 VanessaE and with? 15:30 VanessaE oh sure, with the larger font yeah 15:30 VanessaE I've noticed that. 15:31 Calinou I use larger font because of wasted space 15:31 VanessaE but scaling the menu with DPI doesn't fix that - you have to scale the menu to fit its content to fix that 15:32 Calinou like that here: https://cdn.mediacru.sh/l6hoDN5w-BBK.png 15:32 sapier http://imgur.com/VXUAuQO,OFGc6qn 15:32 Calinou (hey, it's the same font settings as Warsow console) 15:32 sapier this is the patched version 15:32 VanessaE omg, the old dirt texture 15:32 VanessaE I didn't know we still had that mode :D 15:33 sapier well actually I made it work again for last version because of an issue 15:33 sapier do you see difference between manually and automatic? 15:33 VanessaE of course I can see the difference, sapier, but that doesn't fix the root issue which is that elements can't shift around 15:33 VanessaE menu scaling with DPI is good 15:33 sapier they don't shift around 15:33 VanessaE don't get me wrong 15:34 VanessaE but you can't leave all that empty space 15:34 VanessaE it looks bad. 15:34 Calinou all menu elements should scale with DPI, this is how you properly support high-DPI screens 15:34 Calinou which are more and more common 15:34 Calinou let's do that better than Minecraft 15:34 VanessaE either group everything together, or keep the menu small but make IT fit its contents, or don't scale. 15:34 VanessaE everything == group the buttons together, group the checkboxes together, etc. 15:34 sapier calinou this is what we actually do right now (well almost all) only thing missing is checkbox 15:36 sapier damn vanessaE that doesn't fix the issue and I wont write dozends of new menus for each screen size and dpi level created the next 5 years on various platforms ... and I know you wont gonna do this too ;-P 15:36 VanessaE nonnonono 15:36 VanessaE you're not listening 15:36 VanessaE don't you know what grouping is in a menu? 15:36 sapier we don't have grouping and we wont get it anytime soon 15:37 VanessaE then you can't scale the menu. 15:37 VanessaE simple as that. 15:37 sapier then you're gonna fix the font size issues? 15:37 VanessaE nope 15:37 sapier so we're gonna remove the screen width settings? 15:38 VanessaE if the fix looks worse than the bug, then the solution is to discard the "fix" until a better one can be found/ 15:39 sapier you're telling me this http://imgur.com/VXUAuQO,OFGc6qn#0 looks worse then that http://imgur.com/0jLxCqA,QzhXsIO#1??????? 15:40 VanessaE grrr 15:40 VanessaE try it with a 5:4 display. 15:40 VanessaE STOP USING YOUR G*D DAMNED SCREEN ASPECT TO SCALE WITH! 15:41 VanessaE sorry, this is a real thorn in my side here. 15:41 sapier that's celerons decision and he did make clear he doesn't want this to change ;-) 15:41 VanessaE did you not look at how spread apart the menu items are in my screenshots? 15:42 sapier yes but in your example not even buttons are different so I guess there's another issue 15:42 VanessaE without your patch, my screenshots would have looked identical to yours EXCEPT that on mine, those labels do NOT overwrite like is shown in http://i.imgur.com/QzhXsIO.png 15:43 VanessaE I just noticed the problem you were describing. I have never seen this effect. 15:43 VanessaE I've only seen the text fields overwrite the labels instead, and then only just barely. 15:43 sapier that's no surprise as you already said you don't use the screenW/screenH settings but there are ppl out there using it 15:43 sapier I don't use them too 15:44 * VanessaE fumes 15:47 VanessaE rule #1 with a user interface. don't clutter it. rule #2: don't leave lots of empty space. 15:51 VanessaE right now, we're pretty close to having rule #1 figured out. the UI isn't really cluttered. but with this scaling patch, you badly violate rule #2. that's my complaint. 15:52 sapier and without it you violate rule "make it work for everyone" 15:52 VanessaE it already works for everyone :P 15:52 VanessaE here's an idea: 15:52 VanessaE make the menu SCALE up. 15:52 VanessaE as in, zoom the whole damn thing 15:52 sapier it works for YOU ... for what I remember you're not everyone 15:52 VanessaE like a magnifying glass. 15:53 sapier the only way to do this is completely changing formspec behaviour ... I don't have any problem to do this but it's you to do the fighting 15:54 VanessaE it's the only way to solve the problem right. 15:54 VanessaE but it has to be made available on a per-formspec basis and disabled by default. 15:55 VanessaE otherwise you'll get things like Unified Inventory taking up half of the wall in my computer room if it could ;) 15:55 sapier that's not possible with reasonable ammount of work and maintainable complexity 15:56 VanessaE a scaling factor scattered throughout the code, set once at program start, calculated from screen DPI, is complex? 15:56 sapier I will not fix a bug each week because of some parameter in some obsucre formspec not beeing pased correct between 100 pointers and parts of minetest 15:56 VanessaE I realize it would be a lot of work. 15:56 sapier right now there ain't a scattered parameter 15:57 sapier theres exactly one dpi value any gui element handles that value what you want is something passed from upper layer of a form down to last pixel for it to know if it shall handle dpi or not 15:57 eugd player inventory are just another inventory, right? 15:57 eugd they're not special case in any way? 15:57 VanessaE sapier: nononono 15:57 VanessaE I'm talking about something used at the rendering layer 15:58 sapier there's nothing at rendering layer 15:58 VanessaE sapier: well whatever you call the layer that turns a formspec element into an image on the screen then 15:58 sapier especially as that change is not related to dpi 15:58 VanessaE call it a renderer or rasterizer..whatever 15:58 sapier but how inventorysizes are handled by minetest 15:59 VanessaE the proper place to apply the scaling is at the last step before the on-screen image is created, 15:59 sapier no it aint 15:59 VanessaE yes, it is. 15:59 VanessaE let the rendering engine do it's fucking jov!@ 15:59 VanessaE job! * 15:59 sapier no it isn't because in this case you'd scale up background too 16:00 VanessaE yes, and? 16:00 VanessaE we already do that anyway 16:00 sapier our engine is irrlicht you have to live with it's limitations unless you want to rewrite it 16:00 sapier we can't just take some region of screen and scale it up without messing up everything 16:01 VanessaE what? 16:01 VanessaE who said anything about scaling up a chunk of screen? 16:02 VanessaE I'm talking about scaling the vertexes, screen coordinates, or whatever the damn things are at this layer, before they're drawn 16:02 sapier (17:59:14) VanessaE: the proper place to apply the scaling is at the last step before the on-screen image is created, 16:02 sapier we can't do that because user input is bound to original positions 16:02 sapier so unless you wanna rewrite irrlichts gui handling we HAVE to rezize the individual gui elements 16:03 VanessaE in other words you already have to tell irrlicht "draw this image at these screen coordinates at size X*Y". I'm saying right HERE is the place to apply the scaling to X and Y. 16:03 sapier that's a completely different things, what you see is two different mechanisms (sometimes) colliding 16:03 sapier one is the sane dpi/gui_scaling_factor handling 16:04 VanessaE whether it's an image, or a button, or a checkbox, or whatever - you're telling irrlicht you wanna draw something on the screen at SOMEWHERE, at some specific size. THAT draw event is where you need to apply your scaling tweak. 16:04 sapier the other one is minetests translation of positions to inventorylocation coordinates 16:04 VanessaE we don't care about inventory location coordinates. DOn't translate those. 16:04 VanessaE they're already relative. 16:04 VanessaE leave them alone 16:04 sapier if we change later one I'll not write any code restoring old behaviour 16:05 VanessaE that's an API issue, not a scaling issue 16:05 sapier it is 16:05 sapier because position is defined to be x-,y-th part of your screen 16:06 VanessaE yeah, Xth/Yth part of the screen relative to the start of the formspec, but they're still relative coordinates. 16:06 sapier with any screen no matter of it's size having exactly X and Y split parts 16:06 VanessaE as they're already defined by something that itself will scale up/down with your scaling tweak, you don't need to change them 16:07 VanessaE it's like saying "I want X percent of this" and if "this" suddenly gets larger, you don't have to adjust your X percent to compensate to get a larger amount - you already get the larger amount by virtue of having requested a percent instead of some exact count of items. 16:08 sapier you don't say I want X percent 16:08 VanessaE yes, you're doing exactly that with the UI elements 16:08 VanessaE think about it: 16:08 VanessaE well, formspec inventory slots that it 16:08 VanessaE is 16:08 sapier you say place menu at x-th part of my screen with length y 16:08 VanessaE NONONO 16:08 VanessaE stop 16:08 VanessaE halt 16:08 VanessaE alto 16:08 VanessaE freeze 16:08 sapier api will always exactly mimicry your screen aspect 16:08 VanessaE dammit I said stop 16:09 VanessaE you're not getting Xth part of the screen's pixels - you're getting Xth part of the formspec's inventory slots - but those SLOTS will change in size! 16:09 VanessaE the pixels won't. 16:09 VanessaE so if you scale those slots, your Xth part changes to follow 16:09 VanessaE you're trying to apply your scaling thinking to both parts at the same time 16:10 sapier that's what I'm saying vanessae a formspec doesn't define a fixed aspect but only slot positions 16:11 VanessaE exactly. 16:11 sapier so unless that is changed it will look exactly this way ... the current fixed size is a hack no more 16:11 sapier it's done by "claiming" a fixed screensize of 800x600 ... but that doesn't work for everything 16:11 VanessaE if you apply your scaling uniformly to their initial positions, then it'll work just fine. 16:12 sapier no it doesn't work 16:12 VanessaE why/ 16:12 VanessaE ? 16:12 sapier because it messes up formspecs slot concept 16:12 sapier positioning will be done by slots but size by exact values ... that's not gonna work 16:12 VanessaE then fix both? 16:12 VanessaE where's the issue here? 16:13 sapier the only way to fix is is droppingt the slot concept in total 16:13 sapier but I wont implement switchable behaviour 16:13 VanessaE *facepalm* 16:14 VanessaE there's nothing inherently wrong with using positioning as slots, other than it being as arbitrary as using em's or points or meters. 16:14 VanessaE it's just another measure 16:14 sapier there is 16:14 VanessaE you're conflating two issues here 16:14 sapier because size and width for all elements is given in slot relative values too 16:14 VanessaE I thought we were talking about fixing this scaling issue? 16:14 VanessaE you're talking about trying to fix the API 16:14 VanessaE I know that 16:15 VanessaE I may suck at formspecs, but I *have* used them some, you know :P 16:15 VanessaE (I suck at them because frankly the syntax is shit) 16:15 VanessaE but anyway, 16:15 sapier so what's your suggestion redefining api to make positions slot but size absolute? 16:15 VanessaE don't touch the API at all! 16:15 VanessaE not right now 16:15 VanessaE this is the wrong time to do it 16:15 sapier then explain how you suggest it to be 16:16 VanessaE I don't suggest making any changes to it right now. 16:16 sapier it's always gonna be wrong, right now we have a broken main menu 16:16 VanessaE the syntax sucks because it uses unnamed, positional-dependent fields. 16:16 sapier and to be honest I consider it to be selfish if you just don't notice it because you're not affected 16:17 VanessaE the main menu IS broken, I accept that 16:17 VanessaE and I do have glitches in it too 16:17 VanessaE just not to the same degree as you have 16:17 sapier i'm not talking about glitches but about unusability 16:17 sapier a button slightly shifted right is a glitch 16:17 VanessaE unusable maybe, on a widescreen monitor. I get that. 16:17 sapier not full text overwritten by other menus 16:18 VanessaE which is why I repeat: don't use the screen aspect ratio for anything meaningful. 16:18 VanessaE it's stupid to rely on it 16:18 sapier I don have widescreen as well as 4:3 16:18 VanessaE and this is exactly why. 16:18 VanessaE when I say glitches, I mean glitches. 16:18 VanessaE gimme a minute. 16:18 sapier yet full formspec system bases on screen aspect ratio no matter if you like it or not 16:19 VanessaE and that's why it's broken. 16:20 VanessaE if I threw a 3:1 aspect screen at it, but it was 6000x2000 and 100 DPI, minetest would break horribly. 16:20 VanessaE yet, there would be ample screen space and the DPI would be within 1 percent of what I am using now. 16:21 VanessaE THAT is why you don't use aspect ratio for this. 16:21 VanessaE and if you think I'm joking, remember this: 16:21 VanessaE 4k screens were pretty much unheard of 10 years ago. 16:21 Calinou 2048 × 1536 was cool back then 16:22 VanessaE which is 4:3 and not 4k. 16:22 sapier 4k screens are <500 bucks and they're quite impressive imho they'll spread very fast the coming year 16:22 VanessaE sapier: the majority of the world (read: 95% or more) does not pay 500 bucks for a monitor. 16:23 VanessaE for a TV, maybe you'll get 20% of the world to pay that price. 16:23 VanessaE if the tv is big enough. 16:23 Exio4 i thought 200 was too much 16:23 Calinou the current 600 € ones are bad: some are 30 Hz, most have bad colours 16:23 VanessaE I paid under $200 for the two 1600x1200 monitors I run now. 16:23 Calinou also, you need a lot of graphics card power for Ultra HD gaming 16:24 VanessaE (for the pair, that is) 16:24 Calinou most AAA gamers that do this use SLI/CrossFire 16:25 VanessaE sapier: without your patch, this is the worst I get from a menu glitch (maximized. at 800x600, it's obviously the same) http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2008162014%20-%2012%3a27%3a20%20PM.png 16:25 VanessaE so don't sit there and tell me "it only works for you". I will sit here and tell YOU that it is only broken that badly for YOU. 16:26 Calinou yeah, Password field eats on the field above 16:26 Calinou happens to me too 16:26 Calinou Credits menu is slightly broken too 16:26 sapier you did mee my screenshot without patch 16:27 VanessaE yesI did 16:27 VanessaE and your screenshot says that for you it's really broken 16:27 VanessaE I suggest that for you, some glitch exists in your setup that you didn't account for in the menu, LIKE SCREEN RATIO. 16:27 VanessaE as in don't fucking use it to draw a menu that has nothing to what-so-fucking-ever do with aspect ratio 16:27 * VanessaE grumbles 16:28 VanessaE sapier: I'm getting pissed here because we're not talking about displaying a fucking movie. it's a menu. 16:29 VanessaE aspect ratio simply doesn't enter into it. 16:29 sapier you're not pissed because of this happening in inventory and any other in game form 16:30 VanessaE I'm pissed because you keep dancing around the issue and you KNOW it. 16:31 VanessaE you know as well as I do what the proper way is to fix it without changing the API. 16:31 VanessaE at least generally. 16:31 VanessaE (I don't know the code, obviously) 16:32 sapier we don't have to change api but only api behaviour if slot's aren't related to aspect ratio any longer there wouldn't be an issue 16:34 sapier define minetest slots are x-th part of screen height and quadratic ... then there might be 20 or 40 slots in x direction but aspect ratio would be preserved 16:37 sapier but keep in mind we'd have to rewrite mainmenu as right now "beloved" aspect ratio of slots is 3:2 16:38 sapier wrong 4:3 16:41 VanessaE that's just it 16:41 VanessaE slots have always been assumed to be roughly 1:1 to most people 16:41 VanessaE and 4:3'ish in display 16:41 VanessaE no one realistically expects them to be any different 16:41 sapier I can't change ppl assuming wrong things 16:42 VanessaE because they look like ass if you try to display them differently. 16:42 VanessaE have you EVER seen a screenshot from minetest that showed it any differnet? 16:42 VanessaE different* 16:42 VanessaE or a complaint from someone who thought they should look different? 16:43 VanessaE look, monitors have had square pixels for like 20 years now 16:43 VanessaE just because the display's dimensions are non-square doesn't mean the *pixels* are. 16:44 VanessaE in fact I'd venture a guess that it's closer to 30 years that square pixels have been the norm 16:44 sapier still slots are defined 4:3 ... I can't change history 16:45 VanessaE then just draw them at a fixed ratio. 16:45 VanessaE jeez 16:45 VanessaE how hard is that? 16:45 VanessaE you don't even need to calculate the damn ratio at all here 16:45 sapier not at all but I refuse to make it a optional thing 16:46 VanessaE if you assume square pixels, and that's a fair assumption here (we don't target Commodore 64), then you don't have to even consider aspect ratio of such an element. 16:46 VanessaE you just have to consider relative sizes at draw time 16:46 VanessaE granted, it works out to having an aspect ratio anyway but only in those elements 16:46 VanessaE but this is all just math in your element placement code 16:47 VanessaE the CPU doesn't care if you have two multiply terms or three, the compiler will optimize it down anyway 16:48 sapier but I do care if I have to pass a "old_style_aspect_ratio" calculation throughout minetest 16:49 VanessaE ok I was damned close btw: VGA defined pixels as square in 1987. 16:49 VanessaE so 27 years. 16:49 VanessaE no you don't. 16:49 VanessaE throw it the hell out 16:50 VanessaE we're talking scale-or-don't scale, here. 16:50 Calinou can't DPI be calculated regardless of aspect ratio? 16:50 sapier so any complaints about slot size beeing fixed 4:3 having variable number of x slots go to you 16:50 VanessaE not one-weird-aspect-ratio-versus-good-one 16:50 VanessaE Calinou: of course it can. 16:50 sapier dpi is faked on pc 16:50 sapier you can't calculate a dpi value by definition 16:51 VanessaE you can always just ASK the user, you know (read: config variable) 16:51 sapier it's a technical value specified by screen but pc screens usually don't provide that value 16:51 VanessaE assume 100 DPI, unless otherwise specified, on PC> 16:52 VanessaE you have to have some DPI value to calculate with, so allowing the user to configure it wouldn't add any complexity 16:52 sapier I'll not change the current dpi faking algorithm without you to persuade celeron not to increasegui elements on screen sizes with y > 1024 and y > 1200 16:52 VanessaE celeron55: well how about it? 16:52 VanessaE celeron55: for once can you weigh in on this instead of just saying "but I don't care anymore"? 16:53 sapier last time I was complaining about those strange numbers he said they have to stay that way 16:53 celeron55 what 16:53 VanessaE well, weren't they other weird values before? 16:53 sapier and to be honest as we just don't know the screen dpi any algorithm faking is is as good as another 16:53 celeron55 that comment was only about the hotbar 16:54 sapier true but I'll not add a different scaling facor for each damn gui element 16:54 celeron55 what *is* the issue? 16:54 sapier slot sizes beeing variable aspect ratio 16:55 celeron55 why? 16:55 VanessaE celeron55: no, the issue is scaling formspecs up without being able to re-arrange or re-size the individual elements to properly fill the new space 16:55 celeron55 i haven't suggested making slot sizes have variable aspect ratio 16:55 VanessaE sapier is trying to conflate two other issues. 16:55 sapier because for slot sizes screen is just divided in parts 16:55 sapier celeron55: you've written it that way ;-) 16:56 celeron55 well what the fuck 16:56 celeron55 make them have static aspect ratio 16:56 sapier ok decision done ... I'll create a pull making slots only honor height of screen and having fixed 4:3 aspect ratio 16:57 VanessaE um... 16:57 sapier that's gonna fix your issue VanessaE 16:57 VanessaE shouldn't they honor the height of the *formspec* ? 16:57 sapier no because height of formspec is given in slot sizes 16:57 VanessaE right, derp. 16:58 VanessaE I was thinking about the rendered size that time. 16:58 VanessaE however, that's just one element that isn't even the root of the issue anyway 16:59 VanessaE unless you figure you can carry that same idea over to everything else. 16:59 VanessaE but then you're gonna break tablets I expect (rotate the screen to portrait) 17:00 VanessaE so you should probably honor the smallest dimension rather than simply the window height. 17:00 VanessaE (also, rotated monitors e.g. XRandR) 17:00 sapier minetest has fixed rotation on android 17:01 sapier a scaling menu doesn't fix all form factors but at least a way bigger range then a fixed one 17:01 VanessaE ok so Android is a non-issue, but you should still account for the above. 17:03 sapier what am I supposed to do below the smallest dimension? thet's what I meant with wont fix all form factors ... once menu just doesn't fit screen it wont be displayed correct 17:06 VanessaE um 17:06 VanessaE I mean measure the width and height and pick whichever is smaller. 17:06 VanessaE use that. 17:06 VanessaE don't just use the screen height alone. 17:06 VanessaE s/screen/window/ 17:07 VanessaE that *will* fix all form factors. 17:07 VanessaE as long as you're not talking about something insane like 10000x500 or something equally ridiculous. 17:07 sapier I decided for height because of consistency issues, dpi is already faked based on height so doing it different for slot sizes will result in strange effects 17:08 VanessaE you have to pick the smaller_of(height, width) because what if the user is playing on a rotated screen? 17:08 VanessaE both of mine can rotate. 17:08 VanessaE (though I don't use that feature) 17:10 sapier so you get smaller distances but increased image size on screen beeing 400x1025 ... 17:10 sapier well it's your decision ... don't complain later 17:16 VanessaE that's the whole point... 17:16 VanessaE if you go with 1025 (1024?) as the correct measure, you'd get a menu that wouldn't even fit on the screen in that case. 17:17 sapier no it's not it's nothing technical just a decision the dpi algorithm is arbitrary 17:17 VanessaE ... 17:17 VanessaE a menu that would be sized right if the screen size were chosen at 400, assume the menu just about fills the width. 17:17 sapier there's no reason to do it this or another way 17:17 VanessaE now size that menu for 1025. 17:18 VanessaE suddenly the meny is twice as large as the screen 17:18 VanessaE FAIL. 17:18 VanessaE menu* 17:18 BlockMen nore, i would say no for now, but i will test it by time and then give my final opinion on it->https://github.com/minetest/minetest_game/pull/301 17:18 sapier yes but that's result of decision to do it this way 17:18 VanessaE jeez, am I the only one who can visualize what one rectangle would look like when placed onto another rectangle of a different size and orientation? :P 17:19 nore ok 17:19 sapier just explain to me why my menu items increase in a 400x2000 menu but the space between them gets smaller 17:20 VanessaE sapier: because you chose a badly contrived example again? 17:20 nore (it could also be added as an option, with the current oregen as the default) 17:20 VanessaE sapier: if your menu gets badly misshapen in that instance, it's because you fucked up. 17:20 VanessaE I won't sugar-coat this. 17:20 sapier no I didn't that's what's gonna happen if you fix the slots but don't fix the dpi algorithm 17:21 VanessaE sapier: did I not say earlier to just assume a fixed DPI of 100 on PCs, and let the user configure it for something else if it's wrong? 17:21 VanessaE since you yourself said that PC monitors can't be trusted to give a valid DPI value 17:22 VanessaE it's either that or have your code go online to some database and pick the DPI from some vetted list of monitors. 17:22 sapier celeron55 do you agree to not scaling any gui elements automatically? ... 17:22 sapier as I said I WILL NOT ADD A DIFFERENT SCALING FACTOR FOR EACH GUI ELEMENT 17:23 sapier most likely a different one autodetecting which user is logging on 17:23 VanessaE who said anything about adding different algos per element? 17:23 VanessaE only you keep suggesting this, not me. 17:23 sapier you said fixed assume 100 dpi that's gonna result in hotbars having fixed size too 17:23 VanessaE um. 17:23 VanessaE *headdesk* 17:23 celeron55 i'm fine with having a fixed DPI on PCs as long as there's an easy slider to set it to whatever a user wants 17:24 sapier irrlicht doesn't support sliders 17:24 VanessaE yes it does. 17:24 celeron55 well something to set it 17:24 VanessaE pause menu, "sound volume". 17:24 sapier no it doesn't ... we've something different but usability is a little bit ... well see your self in settings 17:25 sapier it's a scrollbar VanessaE not a slider 17:25 VanessaE ah, well it certainly works well enough 17:25 celeron55 well it's basically the same thing :P 17:25 sapier the difference is you can drag around a slider while this doesn't work very well with a scrollbar 17:26 celeron55 well, for now just buttons for some useful DPIs could be fine 17:26 celeron55 also, same thing for font sizes 17:26 celeron55 font size has been missing from settings for too long (altough, there's no mechanism in place for changing it at runtime, needs work) 17:27 sapier I'm just doing this change 17:28 sapier should've done it before VanessaE wouldn't have even noticed any problem ... now shes complaining because of her way of doing it would be slightly glitched 17:29 VanessaE I am complaining because you were about to make the main menu look like crap for even more people than you propose is already the case. 17:29 celeron55 sapier: do you think having buttons for, say, 70dpi, 100dpi, 130dpi and 160dpi in settings would work? 17:30 VanessaE celeron55: fwiw X had a standard 75DPI setting. 17:30 VanessaE but that was uears ago 17:30 VanessaE years* 17:31 sapier I'd suggest a dropdown not buttons 17:31 sapier RealBadAngel: could you please add a GUI subtab on adding the subtabs to settings too ? ;-) 17:34 RealBadAngel oke doke 17:35 RealBadAngel and vote for dropdown too 17:35 RealBadAngel buttons would look dumb in best case 17:36 RealBadAngel celeron55, blue channel of a vertex is supposed to hold light source value, yes? 17:37 celeron55 one of them holds daytime light, one of them holds nighttime light 17:37 celeron55 and nighttime light equals light source 17:37 RealBadAngel thats r and g 17:37 celeron55 umm... wait 17:38 RealBadAngel r - day, g - night, b - lightsource 17:39 RealBadAngel im asking because b is being fed with different values 17:39 RealBadAngel once nodedef light source value, once encoded one 17:39 RealBadAngel video::SColor c = MapBlock_LightColor(255, l, decode_light(f.light_source)); 17:39 RealBadAngel this is for each and every special drawtype 17:40 RealBadAngel while regular nodes hold here plain one from nodedef 17:41 celeron55 i don't remember what's up with that 17:41 celeron55 i think regular nodes should probably have that too 17:41 celeron55 because shaders don't handle node light decoding 17:42 RealBadAngel shaders do not bother bout it anymore 17:42 RealBadAngel it is inconsistent in the engine 17:43 celeron55 well i guess you can somehow mirror this logic in wherever the stuff is done now 17:43 RealBadAngel def light source is in range 0-15, while decoded 0-255 17:43 RealBadAngel oops, 8-255 17:43 RealBadAngel light table sets 8 for light level = 0 17:44 RealBadAngel and thats the real problem 17:44 celeron55 i know; i don't really understand what the question is 17:44 RealBadAngel i cannot detect light sources properly 17:45 RealBadAngel because blue channel have different values for different drawtypes 17:45 RealBadAngel grass have 0, stone slab 8 17:45 celeron55 why are you continuing this 17:45 RealBadAngel to get the idea behind why it was coded that way 17:46 celeron55 it's a bug that they are handled differently 17:46 celeron55 if that wasn't already clear 17:46 RealBadAngel imho b should carry not encoded light source, do you agree? 17:47 RealBadAngel we can apply reading on table the very same place as shading is done 17:47 celeron55 i think it should always carry a decoded light source value but my knowledge about this thing is outdated because you've been changing it so much 17:47 celeron55 then it's comparable to all the other values that are found in the values 17:47 RealBadAngel actually i havent touched the lights so far 17:47 celeron55 in the color values at that point i mean 17:48 celeron55 anyway, my point is, decode all the things in the same step and not all around the place 17:48 RealBadAngel ok 17:48 celeron55 i don't know where that should be 17:48 RealBadAngel a sec 17:48 celeron55 but maybe do it in such a way that if we decide it should be done in shaders again, it's not going to be a pain in the ass 17:49 celeron55 i mean, the step that you removed from them 17:50 RealBadAngel https://github.com/minetest/minetest/blob/master/src/mapblock_mesh.cpp#L1142 17:50 RealBadAngel here, each vertex has to pass this code, no matter what drawtype 17:51 RealBadAngel and here im failing thx to decoding the light too early for all the special drawtypes , so light_source = 0 is 8 17:52 RealBadAngel so together with faces shading, encoding could be done 18:00 RealBadAngel so, Calinou, sorry but fixing acid will take a bit longer than i thought ;) 18:02 Calinou OK 18:04 RealBadAngel but at least i know what to do 18:05 RealBadAngel almost the same applies to nodeboxes 18:20 RealBadAngel BlockMen, is there a reason for sandstone being able to dug by hand? 18:21 BlockMen idk, didnt add that 18:21 RealBadAngel imho thats worth bug label 18:22 RealBadAngel sandstone, stairs and slabs you can dig by hand 18:22 BlockMen feel free to open an issue 18:22 RealBadAngel for such obvious one you could just make a commit 18:25 VanessaE RealBadAngel: I used to dig sandstone by hand in my grandmother's yard. 18:25 VanessaE it occurs naturally in dirt in eastern Kansas. 18:26 VanessaE (as kids, we used to use it as a sort of "chalk" to draw on sidewalks with) 18:26 VanessaE granted they weren't 1x0.5x1 meter blocks, but you get the point. 18:28 RealBadAngel idk, imho it should be diggable with at least wooden pick 18:29 RealBadAngel i cannot imagine one sitting there and scratching block of sandstone with his nails to cut 1m cube of it ; 18:29 RealBadAngel ;) 18:35 Exio4 i don't imagine anyone cutting an 1m wood cube with their bare hands eithers 18:35 BlockMen RealBadAngel, but i dont want do that now 18:35 VanessaE when remodeling this house, I kinda did :) 18:35 BlockMen and idk what the other think/say about that 18:36 BlockMen so opening an issue is best right now :P 19:25 Calinou what are the causes for failing to publish server on list? 19:25 Calinou some friends keep having a lot of trouble doing it, it doesn't work 19:36 sfan5 which error msg? 21:27 eugd test 21:32 kahrl mine 22:02 eugd std::map m_blocks; 22:02 eugd can someone give me a quick c++ tutorial run-down of this line? 22:03 eugd what do the less-than/greater-than brackets signify, as opposed to normal brackets? 22:03 eugd or parenthesis 22:04 eugd and i am assuming the little s16 is how the size of the map is initialized, but is that really all a map needs? 22:04 sfan5 uh 22:04 sfan5 that defines a key-value map that maps s16 to a MapBlock* 22:05 eugd what's with the brackets though, what do they mean in c++, opposed to "()" or "{}" 22:05 Exio4 template params 22:05 eugd ok i can google that 22:05 eugd thanks 22:12 sfan5 https://forum.minetest.net/viewtopic.php?f=7&t=9940 22:12 sfan5 someone look at that 22:12 eugd the little 's16' thing 22:12 eugd is a custom-defined name, right? 22:13 eugd where is that defined, some header? 22:13 sfan5 yes 22:13 sfan5 s16 -> int16_t -> signed short (for x86(_64)) 22:13 eugd yeah 22:13 eugd is there some namespace for those, or is that unnecesarry? 22:13 eugd and where are they defined? 22:13 sfan5 probably irrlichttypes.h 22:13 sfan5 anyway 22:14 * sfan5 goes to bed 22:14 eugd a major reason for this is to make large changes throughout the entire codebase easier, right? 22:15 eugd and it's all irrelevant performance-wise, written pout at compile? 22:15 eugd *out 22:20 kahrl eugd: well it's not like we would one day decide to make s16 a 32-bit unsigned integer 22:21 eugd that's exactly what i'm wondering 22:21 eugd increasing world size 22:21 kahrl it has nothing to do with that 22:21 kahrl the reason the traditional int/long/... types are not used is because they have different sizes on different platforms 22:22 kahrl leading to obscure bugs 22:22 eugd so the custom names aren't anything to do with easier large changes? 22:22 kahrl yeah 22:22 eugd rather just redefining based on platform? 22:23 kahrl making the world larger would require much more changes than just a different data type 22:23 eugd to memory management backend and such 22:24 eugd but can or are these custom names used for this kind of thing? 22:24 kahrl the database you mean? 22:24 kahrl these names are used for all sorts of things 22:26 kahrl you'd need to rewrite the blockpos <-> integer conversion, the network protocol, many little things in the server and client code if you want to increase the world size 22:26 kahrl plus the corresponding compatibility code 23:42 gentoobro why would you need a bigger world? is 64 kilometers cubed not enough? has anyone actually used/explored the entire world? 23:45 gentoobro (does anyone who plays minetest even have at least 5PB of drive space?) 23:55 Zefram_Fysh travelling 31 km horizontally is totally feasible 23:56 Zefram_Fysh reaching the edge of the world is a pretty sucky result 23:56 Zefram_Fysh you don't have to explore the entire world to run into the edge and find it annoying