Time Nick Message 00:00 VanessaE er, doesn't the engine already have a full-screen AA filter? 00:05 iqualfragile_ if it does it is not too good as distant rows of blocks look bad 00:05 iqualfragile_ but it might be a problem with my graphics card 00:06 VanessaE try mipmap+anisotropic filtering 00:07 VanessaE in the settings menu 00:07 VanessaE it works for some people anyway 00:10 iqualfragile_ mipmapping is something compleetly different 00:13 VanessaE yes I know, but those features, combined, help cut down on distant aliasing noise 00:25 kaeza https://gist.github.com/kaeza/7379702 <-- This patch fixes that "tried to index local 'anim' (a nil value)" error on the player code 00:26 kaeza most of it is junk due to adding an indentation level 00:27 kaeza (as a side note, it would be nice if Lua had a 'continue' statement) 00:44 VanessaE actually I think it does. 00:44 VanessaE I know I saw something like that recently. 01:16 kaeza ok, ignore that patch; I'm looking into rewriting player.lua to do a better job 02:40 ShadowNinja VanessaE: It doesn't have a continue statement, but you can use ::continue:: and goto continue, although that has obvious style issues... 03:06 kaeza ShadowNinja, goto is 5.2/LuaJit afaik 04:42 ShadowNinja kaeza: Yes, it is. 04:44 VanessaE fwiw, this patch from kaeza (against minetest_game) seems to have fixed the breakage of player.lua for me: https://gist.github.com/kaeza/7381115 04:46 kaeza yay got pinged two times in a row 04:46 VanessaE haha 04:46 kaeza anyway, there's a more recent version of that patch (fixing some stuff I noticed) 05:01 Warr1024 if I were to send a media announcement packet to clients after they've emerged, would they download the additional media, or are they only receptive to that when first connecting? 05:05 kaeza okay, patch updated ( https://gist.github.com/kaeza/7381115 ) 05:06 VanessaE what's changed? 05:09 kaeza in the one you're using on your server, the "sneak" animation does not work 05:10 kaeza (shows as fast as walking) 05:10 VanessaE ahh 05:10 VanessaE ok 05:10 * VanessaE deploys it 05:14 VanessaE well, all five servers came back up at least :D 05:41 kaeza teh duck 05:41 VanessaE ? 05:41 kaeza that is not my patch O_o 05:42 VanessaE that would explain why it didn't work as expected :D 05:42 kaeza https://gist.github.com/kaeza/7381115 05:43 VanessaE ok that's different from the other one. 05:44 VanessaE applied. 05:44 kaeza note to self: if you select the patch in the editor, remember to copy it as selecting the text on the gist overwrites the selection 05:44 VanessaE and deployed. 05:47 VanessaE kaeza: that would help "D 05:47 VanessaE :D 10:47 sapier https://github.com/minetest/minetest/pull/991 48x48 game buttons 10:48 sapier https://github.com/minetest/minetest/pull/990 crash without any game 11:43 PilzAdam sapier, I guess #990 is simple enough to merge it if only 1 core dev agrees 11:44 sapier ok if this is an agreement I merge it 11:46 kaeza PilzAdam, https://github.com/minetest/minetest_game/pull/217 11:46 PilzAdam sapier, yes, it is 11:46 sapier thx 11:52 PilzAdam #991 seems to work, but I dont understand how it works 11:59 PilzAdam kaeza, why do you do that: https://github.com/kaeza/minetest_game/blob/a3365d4078a977b02a5e51b32f2cda316e0e99ca/mods/default/player.lua#L81 ? 12:02 kaeza PilzAdam, locals are a bit faster than globals, and since that function is called from the same file, I opted to do that small optimization 12:03 kaeza that line is to export it to other mods 12:03 PilzAdam can you add a comment that its done for speed then? 12:03 kaeza sure 12:03 PilzAdam (same for default.player_models) 12:04 PilzAdam there are no other mods that rely on player_step(), player_update_visuals() or player_get_animations()? 12:07 kaeza they weren't usable anyway, because player.lua registered them as globalstep directly instead of indirectly calling through an anonymous function 12:09 PilzAdam can you add a lua-api.txt style comment at the top of the file? 12:11 kaeza yes 12:12 PilzAdam and is there any reason why we dont add the per-player textures functionality from my player_textures mod? 12:21 sapier PilzAdam 991 just fits resulting image_button size to 48x48 pixels 12:23 PilzAdam sapier, I guess its good then 12:25 sapier and adds a eleventh button (new size allows one button more in bar) 12:27 kaeza PilzAdam, Check now 12:28 kaeza https://github.com/kaeza/minetest_game/commit/4019d283638a77250e6bb4b6915af313619eecab 12:30 sapier guys anyone interested in droping open issue list below 200 this weekend? 12:37 BlockMen sapier, #991 needs hexcolors, so you need to add # 12:37 sapier already fixed some seconds ago ;-) 12:39 BlockMen oh, ok. good then 12:41 kahrl I algebraically calculated the size of the game buttons required for 48x48 pixels once and it was 1.165,1.175 12:41 kahrl the difference between 1.175 and 1.165 may be small enough to not matter 12:43 sapier at least for those buttons we have atm I can't see it yet second decimal does matter for gui in general 12:43 kahrl IIRC the difference between width and height comes from this line in guiFormSpecMenu.cpp: spacing = v2s32(data->screensize.Y/12, data->screensize.Y/13); 12:44 sapier I'd live with it rather complicating it even more 12:49 kahrl I made a screenshot and #991 apparently makes 48x47 buttons 12:49 sapier ok ok I'm gonna fix it 12:50 sapier better? 12:52 kahrl yep, 48x48 now 12:53 sapier ok I squashed commits is it ready for merge? 12:53 kahrl I'd say so 12:53 BlockMen im fine with 12:53 sapier then I merge now 13:00 sapier ok theres only one open issue and a feature enhancement left in #814 and I'm not sure if that issue really is a issue 13:01 sapier to me the selection follows mouse cursor seems to be a feature of listbox we trigger by some reason 13:04 kahrl not really a feature more a quirk of how irrlicht handles focus and hovering 13:04 kahrl I analyzed it once, let me find it again 13:05 sapier you may have noticed I want to get rid of 814 ;-) I guess mainmenu is stable enough now to track remaining bugs in separate issues ;-) 13:06 kahrl http://paste.dy.fi/kaj 13:08 kahrl so basically there are three ways to fix the remaining issue in #814 13:09 kahrl 1. allow the formspec menu to lose focus (this would cause other problems) 13:09 kahrl 2. strange irrlicht black magic (perhaps in preprocessEvent or our custom event handler) that I haven't figured out yet 13:09 kahrl 3. merge formspec_table which does event handling differently from CGUIListBox 13:11 kahrl well, or live with it 13:11 sapier as probability for formspec_table is quite high I guess there's no need for further investigation 13:11 sapier I'd be fine with last one too it's quite rare case ... and can be fixed easyly 13:12 sapier by clicking somewhere 13:12 kahrl yeah 13:12 sapier so imho this wouldn't be a cause to stop 0.4.8 even if formspec_table isn't merged by that time 13:13 kahrl my opinion exactly 13:17 BlockMen agree. and is it ok when i add me to credits? 13:18 nore sry for not having been there last week... I just read the sapling ABM bug... as it been fixed, or should I do that? 13:19 BlockMen nore, its fixed already but shadow suggested to rewrite it with using mts 13:20 nore IIRC, this has already been discussed... mts don't produce good enough trees 13:21 sapier I guess a missing core dev in credits is a bug so you should fix it BlockMen 13:22 BlockMen sapier, lol. is it ok to do that over github.com since i have no acess to my client atm 13:23 PilzAdam AFAIK you cant do it with the webinterface without creating a merge commit 13:24 PilzAdam BlockMen, do you want an e-mail to be listed there? 13:25 BlockMen nah, i dont think so 13:25 BlockMen then i will do that now 13:26 sapier ? merge commits aren't allowed for minetest blockmen ;-) 13:26 BlockMen oh, sry. i read can 13:27 BlockMen then someone else plz or somewhen else 13:27 PilzAdam so I just add "BlockMen" to the list 13:27 BlockMen PilzAdam, thx 13:28 PilzAdam https://github.com/PilzAdam/minetest/commit/0aeecf3f7f1adb37de46d1e6d68653082dd8111a 13:28 PilzAdam anything wrong there? 13:28 BlockMen nope, perfect ;) 13:30 PilzAdam also added you to http://minetest.net/contributors 13:31 BlockMen thx 13:32 kahrl sapier: quickly looked over async_events_plus_httpfetch, some things I noticed: http://paste.dy.fi/dXR 13:33 PilzAdam kaeza, s/ObjectRef/PlayerRef/ and also use "array" when talking about tables indexed by integers 13:34 kaeza k 13:35 kaeza other than that? 13:37 sapier ok two possible solutions for gettext either disallow it in async or use a mutex for protection ... later one would harm async behaviour ... any better ideas? 13:38 PilzAdam kaeza, visual_size is missing in model_def, I think 13:40 kaeza k, anything else? 13:40 kahrl sapier: disable them I guess 13:40 kahrl they're mostly for GUI anyway, not background stuff 13:41 kaeza oh forgot default.player_models table 13:41 sapier I think disabling is more correct too 13:41 BlockMen g2g, bye 13:43 sapier shadows error handler fixes arent merged yet are they? 13:43 kahrl I thought they were 13:43 kahrl maybe not 13:43 sapier I don't think so at least I can't find them in commit list 13:45 kaeza PilzAdam, https://github.com/kaeza/minetest_game/commit/1d5347ac1a6acb7faaa0ef328fe02ee3e1bc53cc 13:45 kahrl yeah, most instances of lua_pcall still pass 0 for the errfunc 13:46 kahrl was there anything that prevented it from getting merged? 13:47 sapier only thing that may prevent is lack of testing by now but vanessae runs this version on server so maybe she can give feedback 13:53 PilzAdam kaeza, what about the per-player textures? 13:53 kaeza wat 13:54 PilzAdam we could add the functionality of the player_textures mod to default 13:55 PilzAdam or that can be done later, if you dont want to add that 13:56 kaeza I'd prefer that to be done later; the basic framework is there (player_set_texture and player_get_animatino) 13:56 kaeza o<<1 13:59 PilzAdam kaeza, the front texture is called "player.png", not "player_front.png" 13:59 kaeza ah 14:01 kaeza updated... yet again 14:02 PilzAdam hmmm... player_set_textures() doesnt seem to work 14:03 PilzAdam https://gist.github.com/PilzAdam/7385720 14:06 PilzAdam ah, player_set_textures() calls default.player_set_model() with the model name player_model[name], but default.player_set_model() returns if player_model[name] == model_name 14:08 PilzAdam it works if the return is removed 14:10 kaeza yep 14:10 kaeza already fixed 14:10 kaeza actually, I call player:set_properties() directly 14:18 sapier kahrl why is result of http fetch a std::string? 14:19 PilzAdam kaeza, its ok then 14:19 PilzAdam updated player_textures mod: https://github.com/PilzAdam/player_textures/commit/518830458a590acb65275243389f06ca48cf38f1 14:20 kaeza good :) 14:21 PilzAdam now another dev needs to agree 14:23 kaeza okay; anyone else? ^^^ 14:24 sapier it's working? 14:24 PilzAdam yep 14:24 kaeza yep, tested on VanessaE's server since yesterday 14:24 sapier code wise it seems to be fine merge it 14:26 PilzAdam great! I merge it then 14:30 kahrl sapier: hmm? 14:30 kahrl isn't it void for async and HTTPFetchResult for sync? 14:31 sapier within the result data is passed as std::string .... for html files this is fine but I don't have a good feeling if you do this with binary files 14:32 kahrl std::string handles nul bytes just fine 14:32 sapier std::string yes but not if you use c_str() on it for example 14:32 kahrl so don't do that ;) 14:33 sapier if you want to pass it to lua you have to ;-) 14:33 kahrl no 14:33 kahrl well 14:33 sapier yes it is possible to handle it correct yet it's not quite something you usually think about when using std::string ;-) 14:34 kahrl doesn't it use lua_pushlstring? 14:35 sapier I don't know I was just talking from lua because I had exactly that bug when creating async 14:35 sapier lost binary data due to 0 termination in c_str() while passing 14:35 kahrl https://github.com/kahrl/minetest/commit/3ad51376916fbe4e98d2f31de7b99cb27f71e061#diff-3fcaee4030e00b8f8895c2ff21d5b364R38 14:36 sapier still doesn't change the trap with 0 in c_str() ;-) 14:37 kahrl what do you suggest? 14:37 sapier char* and size yes this isn't as elegant as std::string but way less error prone 14:38 kahrl ugh... that's ugly 14:38 kahrl std::string is basically a wrapper for those two so why not use it? 14:38 sapier no it's c ;-) 14:38 sapier because it's a string wrapper so you quite abuse it for binary data ;-) 14:41 kahrl what exactly is "binary data"? 14:41 kahrl everything in a modern computer is binary 14:42 sapier when I'm speaking of binary data I'm talking about data not beeing linked to any char codeset 14:43 kahrl and a std::string by itself isn't linked to any codeset 14:43 kahrl the code that interprets it may be 14:45 sapier ok doing a google search about 0-termination of strings we may get an error using std::string in c++11 mode 14:46 kahrl wow, really? 14:47 sapier they enforce 0 termination of strings in c++11 so if your binary data isn't 0 terminated it's not a c++ std::string ... unless that 0 is automaticaly added 14:47 sapier and if it is added data doesn't match downloaded data 14:47 sapier http://stackoverflow.com/questions/6077189/will-stdstring-always-be-null-terminated-in-c11 14:47 kahrl I'm pretty sure that means it automatically appends a 0 but doesn't change size 14:47 sapier at least if I did interpret this discussion correct 14:48 kahrl which is what all supported compilers did anyway under the old standard 14:49 sapier so you mean std::strin("hnfsadhihfg0") and std::string("hnfsadhihfg") result in different string size? 14:49 sapier the last 0 represents a binary 0 14:50 kahrl no, they will be the same 14:50 kahrl because that's a constructor that takes a C-style string 14:50 sapier then std::string is not valid for binary data ... if it adds or removes a 0 from my data 14:50 kahrl umm 14:51 kahrl if you used the constructor variant with a size parameter it would work 14:52 sapier quite ugly pitfalls in there ;-) 14:52 sapier I guess it can be done right with std::string ... but you have to be extremely carefull 14:54 kahrl it isn't really easier with char* + size_t, just more tedious 14:55 sapier with char* + size_t you know you have to be carefull with std::string it's easy to forget ... both options have good reasons for and against ... I guess we need a third opinion to decide 15:35 PilzAdam sapier, Im testing #884 currently 15:36 sapier ok I guess I need to rewrite your whole code to proper use char* + size_t ... to lazy to do so I guess it's fine to make future core devs find their oportunistic std::string usage mistakes 15:36 PilzAdam if you click on "Local install" and then close the window that opens then the menu formspec is messed up 15:37 sapier is this related to 884? 15:37 sapier or i18n fixes? 15:37 PilzAdam dunno, I noticed it while testing 884 15:38 sapier I'll check 15:38 sapier i18n isn't merged yet so if you did master +884 it should be 884 only 15:45 PilzAdam I guess #884 is good enough 15:46 PilzAdam the modstore not, though 15:46 sapier if formspec is broken after local install (by 884) it's not 15:47 PilzAdam can you check that in current master? I guess its there too 15:48 sapier 884 doesn't fix modstore stalls that can only be done by async or some variant of httpfetch ... while later one isn't my prefered option as it adds multiple ways for doing async things ... sorry have to do some rl things now 18:16 hmmmm I really hate talking about ideas and I should really code more but I think this is worth throwing out there 18:16 hmmmm multiple mapgens on a single map - can it be done? 18:16 hmmmm we have a list of mapgen objects that are used to generate each, and I guess a master perlin noise map where each point represents a mapblock 18:17 hmmmm just do something stupid like a 2d noise value treshhold for selecting which to use 18:17 hmmmm the real magic happens in what I would call a "multi-chunk post-processing" routine that lives outside of the mapgens 18:18 hmmmm this would grab already generated bordering chunks sorta like how the mapgen already works with bordering blocks 18:18 hmmmm it does this with the entire chunk though 18:18 hmmmm and you can choose which algorithm to use to blend the two 18:18 hmmmm I guess like bilinear interpolation if you don't feel crafty, or maybe something better like a gaussian blur 18:19 hmmmm for most intents and purposes, this would be like image manipulation 18:20 hmmmm with the main difference being that we don't have all the data available to us at once. so in order to fix that, I suppose you could add attempts to blend with non-existent chunks to a "todo list" that gets handled later - this is easy, remember? because it lives outside of the mapgen 18:21 hmmmm that's basically the same concept as the cutoff list for decorations which I think I may need to come back to eventually. remember, decorations aren't complete, they haven't been complete for a while, but the case for them is looking worse due to luavoxelmanipulator being around 18:23 PilzAdam hmmmm, does this mean that biomes could define their own mapgen; so we can create e.g. mountain biomes, flat biomes etc.? 18:23 hmmmm that would be something possible, except we never dreamed of something like this 18:24 hmmmm and also the performance hit would be massive for this luxury 18:25 hmmmm by no means am I advocating this multi-mapgen feature, I'm just saying it's a wacky idea and I wonder if it could be done, that's all 18:25 hmmmm and if so, how 18:26 hmmmm a much better approach to what this solves is just to make a mapgen that is good enough to not have repetitive features in the first place 18:51 sapier kahrl what do you think about using semaphore in your fetch thread? 19:02 VanessaE hmmmm: there is a way to force it.... 19:02 VanessaE add linear gradients to the main perlin layer for X and Z. 19:03 VanessaE then you're guaranteed to find different stuff in, say, the east than in the southwest 19:05 hmmmm lol. 19:05 hmmmm we get bored of the same terrain, so we have procedurally generated terrain 19:05 hmmmm we get bored of the same features, so we have procedurally generated mapgens 19:06 sapier hmmmmm I know noone wants to hear but fix critical mt bugs for 0.4.8 release ;-P 19:06 hmmmm what bugs yo got 19:06 hmmmm s/yo/you/ 19:08 hmmmm i'm supposed to be fixing a bug right now 19:10 celeron55 we get bored of the same kind of mapgens, so we have procedurally generated mapgen generators 19:11 celeron55 maybe we should have procedurally generated procedularizators 19:11 celeron55 s/same kind of mapgens/same kind of mapgen generators/ 19:12 sapier there's at least a crash with ati graphics cards that didn't happen in 0.3 ;-) 19:12 hmmmm what's up with that? 19:12 hmmmm what changed with the rendering aside from the optional bumpmapping 19:13 sapier I don't have any idea I even disabled all new features yet current crashes 19:18 hmmmm sounds interesting.... 19:18 hmmmm any way to debug it at all? 19:23 sapier the crash is burried deep inside of graphics library so I guess this could be difficult 19:23 hmmmm you don't get a backtrace..? 19:24 VanessaE which crash are we talking about? 19:29 sapier https://github.com/minetest/minetest/issues/984 this one 19:29 sapier found it when I wanted to try if 0.4.7 is really slower than 0.3 19:34 sapier as you see in backtrace the crash happens deep down in graphics stack 19:34 hmmmm yeah 19:35 sapier I don't have any knowledge about it so I'm not very qualified to track it down 19:35 hmmmm the only thing I recall anybody doing with the texture from mesh was kahrl's optimization 19:35 hmmmm I really doubt that's the problem but that's where I'd start anyway 19:35 hmmmm otherwise you could just binary search through the commits to find where it started happening 19:36 sapier :-) guess that'd take some time last known good version is 0.3.3 19:36 hmmmm hmmm I have a computer with a radeon xpress 200, except compiling on it takes a good 20 minutes 19:36 hmmmm sapier, i thought you said this started recently happening 19:37 sapier no I recently discovered it 19:37 hmmmm if you just discovered it now it's either a). recent or b). so obscure that it's not really critical 19:37 sapier that laptop with xpress200 was my only device with ati graphics and I guessed the assumed performance regression may be ati only ... the regression doesn't exist but the crash does 19:38 sapier I don't know if this happens for others using ati too 19:43 hmmmm whaa 19:44 hmmmm kahrl'soptimization thing was never committed? 19:44 hmmmm what why 19:46 hmmmm I mean the render-to-texture optimization for textured cubes 19:48 sapier hmm I guess I need to do some valgrind debuging I get bugs that just can't happen this way 19:53 sapier json value asString is pure crap 19:53 hmmmm i've been using json at work a lot 19:53 hmmmm and i must admit it's nice 19:53 sapier I'm not talking about json but about the implementation 19:53 hmmmm yeah I know, the implementation used here is crap 19:54 sapier I need char* to push it to lua 19:54 hmmmm but if possible I'd like to expand the use of json, possibly start defining formspecs in it 19:54 hmmmm of course, given that there's a better implementation we can switch to 19:55 sapier please DONT do that you need to support old variant as well as new one doubling maintenance effort ... and json isn't really human readable ... imho even less than xml 19:55 hmmmm anything is better than the current format 19:55 hmmmm christ, kill that with fire 19:56 sapier if we'd start new I'd be with you but as we already have formspec we need to maintain both thus benefit of a new thing has to be HUGE to be worth it 19:56 hmmmm actually I'm sorry, formspec altogether is a huge horrible mess and it needs to die 19:56 hmmmm one that doesn't rely on Irrlicht hacks 19:57 PilzAdam formspec was originally designed for inventory lists; currently its just greatly abused 19:57 celeron55 ...that has been my stand since long before sapier made the main menu with formspecs 19:57 hmmmm a widget toolkit for Irrlicht that is better than what currently exists 19:57 sapier if you'd let formspec die before mainmenu rewrite I'd guess it had a chance but now 19:57 hmmmm well it's your fault for letting it live 19:57 hmmmm the formspec mainmenu popped up out of nowhere honestly 19:57 celeron55 sapier: what? it's not like you even asked me how you should do it 19:58 hmmmm there is SO much to do in minetest and such little manpower 19:58 sapier no I didn't because rewriting a whole gui toolkit was never an option .... but if everyone is willing to do 19:58 sapier -everyone +anyone 19:58 hmmmm see the thing is 19:58 hmmmm I think that minetest could spawn off a lot of useful libraries 19:59 hmmmm that everybody would benefit from, not just minetest 19:59 celeron55 the thing is, we could already have a suitable toolkit if work was done towards it instead of mangling this formspec crap to have the features it now does 19:59 sapier there are already gui toolkits out there yet we think we can do it better? 19:59 hmmmm for irrlicht? 19:59 celeron55 and yes, my opinion is that that whatever replaces formspecs should be a library 19:59 hmmmm if there's an alternative for irrlicht then by all means we should check it out 20:00 sapier celeron no we couldn't have it if I wouldn't have been able to reuse about 80% of the work I already had done for mobf I wouldn't ever have started mainmenu rewrite 20:01 sapier and if I had know before how much this would be I wouldn't even have done it ;-) 20:01 celeron55 sapier: oh whatever; i guess i can't know; but in any case it's untolerable 20:01 sapier what is untolerable? 20:01 hmmmm well if you didn't spend that much time on the main menu, it probably wouldn't hurt much if it got wiped out 20:01 hmmmm OF COURSE we need something else to swap in its place, which takes time 20:01 hmmmm and motivation 20:02 sapier I don't have any issues if you wipe it out but I think you too underestimate work to be done by some factors 20:02 sapier and of course I wont do it again 20:02 hmmmm exactly, I always underestimate the amount of work that has to be done 20:03 sapier I'll have more then enough work updating mobf to whatever you design new 20:03 hmmmm and I also underestimate the amount of drive I have to do it :) 20:03 hmmmm overestimate rather 20:03 sapier the new mainmenu was about 2-3 full weeks of work 20:03 hmmmm mind you I wouldn't drop formspec support 20:03 sapier adding completely new design a better aproach is about 4-8 weeks 20:03 hmmmm it'd just be deprecated and marked as such 20:04 sapier thats crap either you really switch to new style or don't do it at all 20:04 hmmmm yes 20:04 hmmmm WE switch to the new formspec 20:04 hmmmm everybody else is strongly encouraged to follow suit 20:04 hmmmm then we axe formspec after a major version or so 20:04 sapier I'm out for this ;-P I'll help findig the loads of bugs but I won't track them down 20:05 hmmmm hold on 20:05 hmmmm this was just a thought experiment 20:05 hmmmm It'd be really great if this could happen but we have many other massive projects 20:05 sapier my next thing to do is async lua support or client side lua ;-) 20:05 hmmmm keep working on async lua support 20:05 hmmmm the client side Lua I think is going to be a joint venture between a bunch of devs 20:05 sapier I don't think it's a good idea to create a new gui toolkit if ever we should learn how to use existing ones 20:05 hmmmm we need requirement definition first before we start hacking away at it 20:06 sapier client side lua is way less work than async ;-P 20:06 hmmmm by the waty 20:06 hmmmm way* 20:06 sapier as async support for ingame scripting requires proper map/environment locking ;-) 20:07 hmmmm is there anything wrong with using GTK for a GUI and restricting use of irrlicht's GUI toolkit for video things and on-screen displays and whatever 20:07 hmmmm I know someone's going to chew me out over suggesting that but 20:08 sapier yes mods can't add settings menus any longer ... did you ever see mobf settings? ;-) 20:08 hmmmm nope 20:08 sapier it's almost as complex as main menu 20:08 hmmmm exactly though 20:08 sapier that's what I meant with reuse lots of mobf code ;-) 20:08 hmmmm the formspec2 would be a scripting interface for GTK+ that's used internally or whatever 20:09 hmmmm so we'd be using an existing GOOD GUI toolkit, which cuts down on work 20:09 sapier aren't there gui description languages out there? why invent a new one? 20:09 hmmmm there is 20:09 hmmmm so what if we plop that in 20:09 sapier I know mozilla has one as well as qt 20:09 hmmmm I don't know about you but this is seeming like not that much work 20:09 sapier there are others for sure too 20:09 hmmmm I'm just saying 20:09 hmmmm what IF 20:10 hmmmm what IF this happens 20:10 sapier in general I'm not against this but I believe it IS a lot of work 20:10 hmmmm it'd be weird to see a video game use GTK for menus and stuff but I believe that it'd be better in the end 20:10 sapier there are opengl toolkits out there too 20:11 hmmmm how well do they work with irrlicht 20:11 sapier I don't know 20:11 hmmmm and are they as complete and problem-free as GTK 20:11 hmmmm that's the thing 20:11 hmmmm any video library-based GUI toolkit is going to be an afterthought 20:12 hmmmm I wish that GTK was at least used for the main menu though, *AT LEAST* 20:12 hmmmm look at eduke32 20:12 sapier so actually best thing to do would use an existing gui description language and implement a own interpreter 20:12 hmmmm they do that, and their main menu is much less complex too 20:13 sapier main menu needs to be at least as complex as current so if this can't be done with another solution that one is out 20:16 hmmmm it's just that I want to do some more involved stuff with the main menu and I'm quickly coming up against problems 20:17 hmmmm problems that exist because of irrlicht nonsense mostly 20:17 hmmmm so I see first hand how horrible it really is 20:17 sapier yes but is mainmenu really most critical problem atm? 20:17 hmmmm everything with the UI blows horrible and needs to die - the description language called formspec, the implementation, and the GUI toolkit it uses 20:17 hmmmm I don't know 20:17 hmmmm it's just that not much more work is going to be done on the main menu if it stays prohibitvely bad 20:18 sapier IS there any work required atm? 20:19 hmmmm aside from my advanced world creation dialog? hrm 20:19 hmmmm not quite, no 20:19 hmmmm everything there works but is very subpar 20:19 sapier imho any more powerfull gui description language is even more complex then formspec ... se the table thing it's quite usefull but it rises complexity again 20:19 hmmmm there's also the configuration 20:19 hmmmm complex is okay if the end result is worth it 20:20 sapier if you want a powerfull all features in gui you need a tool to design it too 20:20 hmmmm I was briefly considering making myself a drag-n-drop formspec editor 20:20 sapier gtk has glade microsoft has visual studio qt has designer 20:20 hmmmm right, and there's another excellent thing, we already have tools for it 20:20 hmmmm off-the-shelf solutions are good 20:21 sapier so actually qt is way to go 20:21 sapier the only thing to work reasonably well on linux and windows 20:21 hmmmm is it? I suppose so, the only reasons why I prefer GTK over qt is because GTK has the C interface and it feels like it has less heft behind it (in terms of dependencies) 20:22 hmmmm I would be willing to look at Qt though. 20:22 sapier using gtk on windows is crap 20:22 sapier and it's slow on linux too 20:22 hmmmm I honestly haven't noticed either of those problems 20:23 sapier did you ever use wireshark with huge amounts of packets? 20:23 hmmmm not recently 20:24 hmmmm the only thing I really used wireshark for was reverse engineering protocols, which was mainly done in my Windows days 20:24 sapier gtk has a huge bug with (errors in) themes using wrong them doesn't cause any noticable error but slows down gui by factors 20:25 sapier yet all this is hypothetical implementing a usefull new gui with same features as current is some months of work if noone is available to do so it won't happen 20:27 hmmmm I don't know if it'll take that long though if we use off-the-shelf parts 20:27 sapier we've got a bug in mystof 20:27 hmmmm like GTK and a GTK editor and an already-existing GTK description language 20:27 hmmmm yes, I know with the dialog 20:27 hmmmm this would solve that problem by the way 20:28 sapier you won't persuade me it's less work without prooving it is less work 20:29 sapier and everythen less than a feature identical rewrite isn't a proove ;-) 20:29 sapier the basic version of formspec rewrite was about 3 days of work ... getting all that small things done was another >2 weeks 20:30 hmmmm proller: https://github.com/minetest/minetest/commit/b401e58c0dcf0993c6198dcc21e8787c2282d8f6 20:30 hmmmm I know, you're right 20:30 hmmmm even the smallest tasks take 5x longer than it should 20:32 sapier any idea why return atof(s.c_str()); causes valgrind to complain? 20:32 hmmmm probably because valgrind isn't perfect 20:32 hmmmm file a bug report haha 20:32 sapier no I don't think so they might be right 20:32 sapier Address 0x16292138 is 24 bytes inside a block of size 29 alloc'd 20:33 sapier and it complains about a 8 byte read 20:33 hmmmm c_str() should not allocate memory. end of story. 20:33 sapier obviously 8 bytes exceed the 29 byte block 20:34 sapier if atof did a 64 bit read this would explain what happens but why should it do it? 20:34 hmmmm check your system's implementation of atof? 20:34 sapier unless that string isn't 0 terminated 20:35 hmmmm c_str() returns a null terminated string, there's no way that's possible 20:35 hmmmm otherwise that's no longer C++ 20:36 hmmmm just wondering does it complain if you set the locale to "C" before you call? 20:37 sapier if this was my i18n fixes numeric locale would be set to C ... but not sure if this is true in this branch too 20:38 sapier talking about i18n if I don't mix it up again you had concerns about scripts and servers does my latest fix work for your scenario? 20:39 hmmmm that was kahrl who mentioned that, I think he was just bringing up a hypothetical problem 20:39 hmmmm I called your approach heavy handed too, wasn't really sure about it 20:41 sapier if you have any better ideas I'd be glad ... best thing I can suggest is just drop msvc support ;-) 20:42 hmmmm well i think the popular idea on how to get around that is to have an option to enable or disable the kludge 20:43 celeron55 http://en.sfml-dev.org/forums/index.php?topic=7823.0 20:44 sapier it's only active if you compile on msvc. linux as well as mingw builds aren't affected 20:44 celeron55 a gui library with swappable input/output front-ends with built-in support for lua 20:44 sapier if you use system default locale no restart will happen too 20:46 sapier using C++11 features 20:46 hmmmm erm, celeron, while it does certainly look nice, it's some random guy posting it on a forum so there's no real support for it and it's bound to have huge problems 20:46 hmmmm I'd rather use something large and well supported 20:47 sapier imho celerons suggestion is best by now yet I'm with hmmm too ... ;-) 20:47 sapier 5 years ... that's a good guess 20:48 hmmmm let's hold off on the gui revamp for a bit, it was just something i mentioned 20:48 sapier we should fix the map environment locking instead of discussing about gui ... yes the gui things are more visible and satisfying but yet the other thing is way more important 20:49 hmmmm minetest certainly won't blow up if we don't do anything about it, but it does stifle innovation or any bolder ideas when it comes to interfaces 20:50 sapier I hate that stupid visible feature driven aproach of innovation ... we have major design flaws within core engine that no one will see if they are fixed but are even more work to fix 20:50 celeron55 fltk has lua bindings, but not sure about how it works inside an irrlicht application 20:50 hmmmm if you don't talk about it, they'll disappear 20:51 celeron55 then there's of course the big ones, but they are probably also a nightmare to integrate (wxwidgets, gtk, qt) 20:51 proller hmmmm, also remove 32xxx values, or weather is unusable 20:51 hmmmm why would weather be unusable 20:51 hmmmm what's wrong with those values exactly 20:52 proller because need to check everywhere 20:52 hmmmm what would you make the value then? 20:52 celeron55 one thing i had in mind was to write the whole toolkit in lua; that way we could get extra workforce from the modding community 20:52 hmmmm celeron, but what about the quality of that work 20:52 celeron55 and have only some basic drawing routines exposed 20:53 celeron55 hmmmm: that's an issue (but maybe a solvable one) 20:53 hmmmm well if we do that 20:53 hmmmm we can remove the hud api too 20:54 proller my idea of usage very simple: minetest.get_heat(pos) < -15 20:54 celeron55 (performance is an other issue, but with some common sense it's probably not an issue) 20:54 proller you force modders to make useless checks 20:54 hmmmm proller, in other words you want weather to be enabled all the time 20:54 hmmmm that's NOT happening 20:54 sapier you know what you're talking abotu hmmmm and celeron? 20:54 hmmmm simple 20:55 celeron55 also, there would probably be a lot of use for an embeddable lua toolkit outside of minetest 20:55 hmmmm sapier, sorta, it'd have to be a client-side thing though I suppose 20:55 proller no, if it disabled - it must return static value from mapgen 20:55 hmmmm alright 20:55 celeron55 the world is full of C++ ones, but not lua ones 20:55 hmmmm so there's one set of API we need for client-side modding 20:55 proller modders can check enabled weather or not, if needed 20:55 sapier that was a rethoric question ... imho it's quite obvious you don't 20:56 hmmmm proller, modders can check for weather with minetest.get_setting("weather") 20:56 proller yes 20:57 proller and no need to return 32xxx values 20:58 hmmmm you shouldn't even bother trying to do operations involving weather if weather is disabled though 20:58 hmmmm -32768 is just some value that's returned because it NEEDS to return a value 20:59 hmmmm if minetest.get_heat(pos) == -32768 then you know weather must be disabled 21:00 hmmmm but you can already check that before you try getting heat from the settings 21:01 proller https://github.com/minetest/minetest_game/pull/211/files - checks everywhere? 21:02 proller why not return static biome value? 21:02 hmmmm because biomes are only really used by v7 21:03 hmmmm those checks aren't really that bad you know 21:03 hmmmm is it breaking your fingers to type "weather and"? 21:04 proller comparing to 32xxx - break 21:05 hmmmm why do you keep saying 32xxx 21:05 hmmmm it's not some random value, it's -0x8000 21:06 hmmmm see the thing is, you want to merge weather right into minetest_game 21:06 hmmmm you should only really need a single check 21:06 hmmmm (that is, your own game) 21:07 proller single check on every getheat, and other single on every hethumidity 21:07 hmmmm how about this: 21:07 PilzAdam weather should really go into a different game 21:07 hmmmm if not weather then don't use this mod 21:07 hmmmm my thoughts exactly pilz 21:07 hmmmm adam 21:08 proller some mods needs in heat-humidity values, even if weather is disabled 21:08 hmmmm then those mods are doing it wrong 21:09 proller better to revert weather from master 21:11 hmmmm weather is in the core because you said it would be too slow otherwise 21:11 hmmmm weather is really something that belongs in a mod, though. 21:11 hmmmm if not minetest.setting_getbool("weather") then 21:12 hmmmm minetest.get_heat = some_function_that_returns_0 21:12 hmmmm SOLVED 21:12 celeron55 the issue is that there are two different things that want heat and humidity 21:13 celeron55 the other one is static properties for map generation (which has always been in the engine), and the other is actual dynamic weather (which hasn't previously been in the engine) 21:14 celeron55 or, well, the first one has kind of half-been 21:14 hmmmm I intend on finishing all that 21:15 sapier https://github.com/minetest/minetest/pull/992 c_str() isn't valid for empty strings 21:16 hmmmm isn't s.length() an O(n) function? 21:16 hmmmm you should check s[0] != '\0' 21:16 sapier so "12344" is empty? 21:16 hmmmm you know what I meant 21:17 thexyz .length is O(1), strlen is O(N) 21:17 sapier no I don't why should s[0] be valid for a empty sting? 21:17 hmmmm ah 21:17 celeron55 we've discussed that before 21:17 hmmmm sapier: it is completely valid, we talked about it and i was correct as per the official standard 21:18 celeron55 the standard says it's valid, but MSVC's debug mode doesn't follow the standard 21:18 sapier don't know but I discovered that issue in linux 21:18 thexyz (although it does look like string length() complexity is unspecified it's safe to assume it's always constant) 21:19 sapier ok so no need to bother about length() complexity 21:19 hmmmm well as long as all the sane platforms have an O(1) complexity that won't hurt too much 21:20 hmmmm I just think that hot functions like the string ones you modified should be as lightweight as possible 21:20 sapier yes but they shouldn't access invalid memory either ;-) 21:20 kahrl uhh I looked that up, it was a bug in valgrind, but I closed the browser because I thought that discussion had ended 21:21 sapier why should this be a bug in valgrind? 21:21 kahrl because it was in their bugzilla and marked as fixed sometime in 2012 21:23 proller hmmmm, 0c 0% with you fix on just-loaded block 21:23 kahrl I think it was this: https://bugs.kde.org/show_bug.cgi?id=297701 21:26 hmmmm proller, I didn't see it when I was testing 21:26 hmmmm maybe you were using an old world 21:27 proller yes, on old 21:28 sapier ok so the error valgrind shows up seems to be a valgrind bug yet can we rely on atof return 0 for ""? 21:29 sapier seems to be 21:30 hmmmm proller, try a new world, you'll se it's fixed 21:38 sapier kahrl is http fetch sync interface thread safe? 21:38 proller hmmmm, "works only in new world" - its half fixed 21:39 hmmmm well 21:40 hmmmm does it work if you add block->weather_update_time = 0; to environment.cpp:813? 21:42 kahrl sapier, yes 21:42 kahrl (minus, as always, any bugs that I don't know of) 21:47 kahrl since the implementation uses objects and httpfetch_sync doesn't share any objects with httpfetch_async (or use any globals) any bug would have to be in curl itself 21:48 sapier https://github.com/sapier/minetest/tree/async_events_plus_httpfetch 21:48 sapier updated version using httpfetch where curl was used before 21:49 sapier I had to add a new define to use sync api it doesn't download anythin if caller is set to default 0 21:50 kahrl oh right, that's fine 21:50 sapier https://github.com/minetest/minetest/pull/993 fixes invalid usage of temp objects in mainmenu too ... some similar fix was pushed yesterday 21:51 kahrl should the httpfetch core be extended so that you can write to a FILE* directly instead of keeping the data in memory? 21:52 sapier might be usefull 21:53 kahrl what do you do with the chunk parameter to fetchJsonValue? 21:54 kahrl oh, I see it now 21:54 kahrl should work 21:54 sapier nothing right now but it was used for additional headers before 21:54 sapier at least nothing in those cases I debugged 21:55 sapier yet this version sometimes results in strange segfaults in debugger I've never seen before no idea if the changes are origin or only cause it 21:56 kahrl hmm 21:57 sapier crash is in vector handling of my asynchronous thread list ... but that vector has it's own mutex to prevent concurrent access 22:00 OldCoder sapier, Hello! May I PM? 22:01 sapier of course 22:01 OldCoder kahrl, do consider requesting a merge. sapier I am PMing. 22:01 kahrl valgrind reports tons of problems deep within curl_easy_perform 22:01 kahrl dunno if any of those are caused by minetest 22:08 sapier I think curl should be quite tested 22:22 kahrl dunno, I get the exact same set of valgrind errors when I valgrind this trivial program: http://paste.dy.fi/wbw 22:23 kahrl whoops, meant to put the curl_easy_cleanup below the curl_easy_getinfo part 22:23 kahrl doesn't change the valgrind errors 22:24 sapier so I guess the curl thing is either correct or curl is broken 22:26 kahrl I get a lot of errors from libssl.so too; scary if you ask me... 22:34 ShadowNinja Um, should I delete half of this? https://github.com/minetest/minetest/issues/534 22:44 celeron55 libraries work badly under valgrind surprisingly often 22:45 celeron55 i guess they tend to have their own ways in maintaining stability, invented before valgrind became a usual tool 23:12 hmmmm hehe 23:12 hmmmm I got v6-like ridges finally 23:13 hmmmm also i figured out how to blend it without adding another 'steepness' noise 23:24 celeron55 kahrl: btw, don't use paste.dy.fi, the maintainer of that isn't really interested in long-term availability anymore 23:32 kahrl hrm, any reasonable replacements that aren't bloated with javascript or ads and support the same amount of languages? 23:32 kahrl pastebin.ubuntu.com? seems they use the same backend 23:40 celeron55 that does work... i tend to randomly choose between gist.github.com and pastebin.com, but those are annoying and slow 23:40 EvergreenTree kahrl, It appears ubuntu pastebin doesn't use javascript 23:40 EvergreenTree use pastie.com 23:40 EvergreenTree I'm not sure if it uses javascript or not 23:40 celeron55 "Failed to load page content" not good 8)