Minetest logo

IRC log for #minetest-dev, 2013-11-09

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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:43 Akien joined #minetest-dev
00:44 VanessaE actually I think it does.
00:44 VanessaE I know I saw something like that recently.
01:12 IceCraft joined #minetest-dev
01:16 kaeza ok, ignore that patch; I'm looking into rewriting player.lua to do a better job
01:58 zat joined #minetest-dev
02:14 Weedy_lappy joined #minetest-dev
02:14 Weedy_lappy joined #minetest-dev
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...
02:53 general3214 joined #minetest-dev
03:06 kaeza ShadowNinja, goto is 5.2/LuaJit afaik
03:08 Warr1024 joined #minetest-dev
03:53 Miner_48er joined #minetest-dev
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:12 Gethiox2 joined #minetest-dev
05:14 VanessaE well, all five servers came back up at least :D
05:19 OWNSyouAll joined #minetest-dev
05:21 OWNSyouAll joined #minetest-dev
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
06:42 pitriss joined #minetest-dev
08:02 darkrose joined #minetest-dev
09:50 sapier joined #minetest-dev
10:18 Akien joined #minetest-dev
10:24 ImQ009 joined #minetest-dev
10:30 RealBadAngel_ joined #minetest-dev
10:42 ydooW joined #minetest-dev
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:32 PilzAdam joined #minetest-dev
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/a3365d4078a977b02a5e51b32f2cda31​6e0e99ca/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/comm​it/4019d283638a77250e6bb4b6915af313619eecab
12:28 Jordach joined #minetest-dev
12:30 sapier guys anyone interested in droping open issue list below 200 this weekend?
12:31 BlockMen joined #minetest-dev
12:32 Block_Men joined #minetest-dev
12:34 Block_Men left #minetest-dev
12:36 BlockMen joined #minetest-dev
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:10 nore joined #minetest-dev
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/commi​t/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:39 Akien joined #minetest-dev
13:39 Zeitgeist_ joined #minetest-dev
13:39 Zeitgeist_ joined #minetest-dev
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:42 BlockMen left #minetest-dev
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/comm​it/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/co​mmit/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:26 djdduty joined #minetest-dev
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:46 ImQ009 joined #minetest-dev
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/wi​ll-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:03 hmmmm joined #minetest-dev
15:10 smoke_fumus joined #minetest-dev
15:12 zat joined #minetest-dev
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
16:35 rubenwardy joined #minetest-dev
17:00 Calinou joined #minetest-dev
18:12 werwerwer_ joined #minetest-dev
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:39 OWNSyouAll joined #minetest-dev
18:49 bas080 joined #minetest-dev
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:22 nyuszika7h joined #minetest-dev
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:25 OWNSyouAll joined #minetest-dev
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:52 zat1 joined #minetest-dev
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/commi​t/b401e58c0dcf0993c6198dcc21e8787c2282d8f6
20:30 hmmmm I know, you're right
20:30 hmmmm even the smallest tasks take 5x longer than it should
20:31 nyuszika7h joined #minetest-dev
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/for​ums/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 joined #minetest-dev
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:15 SpeedProg joined #minetest-dev
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:31 EvergreenTree joined #minetest-dev
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)

| Channels | #minetest-dev index | Today | | Google Search | Plaintext