| 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/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: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/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: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/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: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/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: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/commit/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/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 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) |
