Time  Nick         Message
00:16 Exio         <<99
00:16 Exio         oops
00:43 ShadowNinja  celeron55: BlockMen's pull should be morged but texturepacks should be renamed to texture_packs and this commit reverted IMO. https://github.com/celeron55/minetest.net_dokutemplate/commit/395084e8e1f047c70fdc17635b3dcb78785b9642
08:54 kahrl        VanessaE: tried my fix for the focus bug when closing menus?
09:10 kahrl        https://github.com/minetest/minetest/pull/743 not a bugfix, but this just optimizes the PNG files so quite unlikely to cause problems. I think it can be merged before the release
09:23 thexyz       that's just fucking great
09:23 thexyz       http://i.imgur.com/SK1G4MP.png
10:32 proller      no coredump?
11:15 Kray         apparently minetest gets to Arch's community repo
11:18 PilzAdam     thexyz, that happens a lot when dealing with meta or inventories
12:03 Kray         https://www.archlinux.org/packages/community/x86_64/minetest/ there
12:05 Kray         it was in AUR for almost two years :d
12:09 thexyz       good
12:09 thexyz       but minetest's license is LGPL
12:10 Kray         well, that was outdated information in my AUR package the maintainer didn't update
13:34 sapier       is there already a "delta" function or macro anywhere in core code?
13:45 kahrl        VanessaE: https://github.com/minetest/minetest/pull/746
13:45 kahrl        sapier: what is that?
13:59 kahrl        the system is down
13:59 kahrl        (github)
14:03 Zeg9         Lol even when it's down github has fancy error pages with visual effects
14:05 celeron55    well they're just static blobs of data
14:05 celeron55    you can make a static page look good too :P
14:16 kahrl        I keep refreshing github to see if that was the last unicorn
14:17 iqualfragile yeah, that unicorn-thingy webserver seems to be quite smart
14:22 sapier       kahrl a function calculating delta between two values ;-)
14:23 kahrl        template<typename T> T delta(T a, T b) { return a - b; }
14:23 kahrl        ?
14:24 sapier       almost ... delta is absolute of difference
14:25 sapier       quick n dirty would be: #define MYDELTA(a,b) ((((a - b) > 0) ? (a-b) : ( a - b) * -1))
14:25 kahrl        fabs(a - b) or abs(a - b) depending on the type
14:25 sapier       hmm to simple :-)
14:27 celeron55    we must use at least 5 template functions and a couple of macros; and definitely needs a couple of new source files
14:27 sapier       I'm working on automatic animation speed update
14:28 sapier       no celeron55 5 isn't quite enough ;-)
14:28 sapier       at least 42
14:53 sweetbomber  whats up with github? keeps giving me err 500 or "This page is taking too long to load"..
14:59 sweetbomber  (this should go to #mt)
15:25 kahrl        https://github.com/minetest/minetest/pull/733 should this be merged?
15:25 kahrl        not sure if this counts as a feature or bugfix
15:31 VanessaE     kahrl: I have not had a chance to try out that focus fix, no (in fact, I'm just now sitting down to the computer after waking up)
15:33 kahrl        good morning then :)
15:34 VanessaE     barely :)
15:37 VanessaE     trying out the focus fix now
15:37 VanessaE     well, building it anyway
15:39 VanessaE     seems to work fine
15:39 VanessaE     what mods were we worried about that this could break?
15:40 kahrl        I'm not sure
15:40 kahrl        did Zeg9 list any?
15:41 VanessaE     not that I recall.
15:41 VanessaE     it doesn't seem to negatively affect unified inventory anyway
15:46 VanessaE     I checked every formspec I could think of (chests, furnaces, inventory, "esc menu", signs, and a few technic devices) and they all behave fine now.
15:47 kahrl        it should work with every menu as long as it is closed by calling quitMenu()
15:48 kahrl        which I believe all do
15:48 Exio         so
15:48 Exio         that long-way problem was just a "remove missing"?
15:49 kahrl        Exio: my one-liner hides a deeper symptom that is caused by irrlicht
15:49 Exio         ah
15:50 kahrl        when the currently hovered gui element is removed from the gui manager, the "Hovered" variable in the gui manager still points to the element
15:50 kahrl        and this means the element can't be deleted because the reference count is nonzero
15:51 kahrl        minetest currently gives keyboard focus back to the main menu in the menu destructor, my patch makes it do that earlier
16:04 Exio         just one thing kahrl
16:04 Exio         https://github.com/kahrl/minetest/commit/114f1052300565499330678b5e084dec3634a8f1#L2R1028 :P
16:04 Exio         how would be that condition non-true? (if block) after an assert?
16:04 Exio         just wondering, i don't know
16:05 kahrl        CMAKE_BUILD_TYPE=Release doesn't check asserts
16:06 celeron55    umm
16:06 celeron55    if you use the assert() found in debug.h, it will always check
16:06 kahrl        if the block is ever NULL for some reason I figure a memory leak would be better than a crash in release mode
16:06 Exio         ah
16:06 celeron55    if you somehow include the C standard one, it will work in whatever way
16:07 kahrl        oh, I didn't know it was redefined
16:07 kahrl        you learn something new every day :)
16:08 celeron55    well it's a bit haphazardly done; nothing makes sure that C's assert.h isn't included after debug.h
16:08 celeron55    but it _shouldn't_ be included :P
16:08 kahrl        sha1.cpp includes it
16:08 kahrl        and luaconf.h, not sure if that is included somewhere
16:08 celeron55    doesn't matter in .cpp files
16:09 celeron55    well that could break something
16:09 kahrl        oh but only if LUA_USE_APICHECK is defined
16:10 kahrl        which doesn't seem to be the case
16:12 celeron55    CPP is so much fun
16:12 Calinou      no, java is funnier
16:12 celeron55    you can't predict anything because anything can override anything
16:13 sapier       if someone complains about minetest beeing laggy next time just tell him/her to try freeorion ... 5s lag on almost any mouseclick in singleplayer ;-) .. feels like github
16:13 celeron55    Calinou: java doesn't have any of the obscurity of the C preprocessor
16:13 Exio         lol sapier
16:13 kahrl        force pushed a new version of clearobjects_unloadblocks without if(block)
16:16 sapier       and xbmc uses 50% cpu load in menu too so minetest isn't as bad in this case too :-)
16:18 celeron55    one can always be worse for sure
16:23 sapier       funny thing is while playing video require 25% only
16:28 VanessaE     kahrl: hah!  corner case for that focus bug:
16:28 VanessaE     press F10.  Hit escape.  Hit escape again to close the escape menu.  Focus doesn't get reset.
16:29 kahrl        nice
16:31 kahrl        hmm I can't reproduce it
16:31 VanessaE     oh wait
16:31 VanessaE     nevermind, this iteration is from my installed copy, not your fixed one
16:37 kahrl        proposing a release agenda: http://paste.dy.fi/bUt
16:45 Zeg9         What about: https://github.com/minetest/minetest_game/pull/166
16:47 VanessaE     kahrl: another thing that needs fixed is the bug in rotation of lighting that was introduced with 6d facedir
16:47 VanessaE     (realbadangel can't fix it before the 0.4.7 window closes - his internet will be down for at least a few days)
16:48 kahrl        I thought he was waiting on introduction of hardware lighting before he wanted to fix that
16:49 kahrl        because it would be too complicated otherwise(?)
16:49 VanessaE     I believe he was, but I'm not so sure we'll be seeing hardware lighting anytime soon
16:51 Exio         i just wonder
16:51 Exio         why not #685?
16:51 Exio         it is just a "cosmetic fix" for some people
16:53 kahrl        Zeg9: looks fine to me
16:54 kahrl        Exio: .gitignore isn't relevant to a release so I didn't include it in the list
16:54 kahrl        doesn't mean I'm against merging it
16:54 Exio         as i said, just a cosmetic fix and doesn't do anything
16:54 Exio         :P
16:54 Exio         it is just*
16:56 kahrl        well if no one is against it I will merge it (685)
16:56 VanessaE     I see no reason not to
17:00 kahrl        Zeg9: 166 is kind of a bugfix but a feature addition also
17:00 kahrl        I'm a bit reluctant to add it during a feature freeze
17:03 kahrl        BRB, dinner. If any core dev sees this please comment on http://paste.dy.fi/bUt
17:03 kahrl        thank you :)
17:04 Jordach      hehe but
17:24 Zeg9         so quiet
17:39 VanessaE     another irritating bug is in selection boxes for thin objects, especially signs and nodeboxes - depending on how/where you are pointing from/at, sometimes the object you're pointing at is not selected.
17:39 VanessaE     most evident in doors and signs.
17:40 VanessaE     the object behind the pointed one is highlighted instead.
17:46 sapier       vanessae animation speed adjustment is way more callangeing than expected ;-) it's quite difficult to get a "natural" experience
17:47 VanessaE     heh
17:48 sapier       and it's not possible prior to 0.4.8 at all
17:59 sapier       https://github.com/sapier/minetest/commits/autoupdate_anim_speed is a possible solution additional to the one I've got a pull request ... the new one should work in laggy environments too
18:33 kahrl        back
18:33 VanessaE     kahrl: regarding #746 -- 22.5GB, not 13.
18:33 VanessaE     (for a 990MB map)
18:34 VanessaE     in case you feel like being completely accurate ;)
18:34 kahrl        not if it is merged :)
18:34 kahrl        do you think the default setting of 4096 blocks is okay?
18:34 kahrl        or too much?
18:34 VanessaE     mmm
18:35 VanessaE     well how big is a block again?
18:35 VanessaE     (memory-wise)
18:35 sapier       900 mb?
18:35 kahrl        16*16*16*3 bytes for the raw data
18:35 VanessaE     so we're only talking about 50 MB worst case
18:35 kahrl        about 12k
18:36 VanessaE     yeah, 4096 sounds fair
18:36 kahrl        err, make that 16*16*16*4=16k
18:36 sapier       does 4096 result in 1gb usage?
18:36 VanessaE     ok so 64MB then :D
19:24 kahrl        This feature freeze will definitely have to be extended. For how long?
19:25 kahrl        (see the #minetest log if you haven't)
19:25 VanessaE     (for the log, I suggested out to 10 days beyond the declared start of the freeze)
19:25 Exio         i'd say 3 days more and then check, if it is enough or if "there is any big bug still around what can be fixed in some small time"
19:27 kahrl        my opinion: until the client crashes on server join are fixed and then 2 more days
19:28 kahrl        or 10 more days, whichever comes first
19:29 kaeza        kahrl, if this helps at all, the client crashes when downloading new media
19:29 sapier       kahrl I guess you can't release it while it crashes .. even if it's in 20 days ;-)
19:29 kaeza        if the media is already cached, it does not crash
19:30 kaeza        (or are at least more frequent when new media is involved)
19:31 kahrl        were the crashes in 0.4.6 too?
19:31 kaeza        yes, and 0.4.5 and 0.4.4
19:31 Jordach      actually, when a .x model is changed, and is re-cached, it causes a mesh error
19:31 kahrl        well then it's at least not a regression, still horrible though
19:32 Jordach      i re-produced it every time i exported a blender model to .x
19:32 sapier       I wonder if this is .x only I tried with b3d models on my mesh cleanup branch .... but I'm not sure if this is exactly what has been added to core
19:33 kahrl        Jordach: ah! that could be why it crashed on the first join to kaeza's server but not afterwards
19:33 Jordach      kahrl, yes
19:33 Jordach      first join kills the client, subsequent non mesh changes will not
19:33 kaeza        I use the soccer_ball.x, so it may be caused by caching it
19:33 Jordach      so the mesh wasnt changed on the second try
19:33 Jordach      then it usually works
19:33 Jordach      b3d is apparently like sapier said, unaffected
19:34 sapier       jordach not sure It's been some time ago I tried
19:36 kahrl        ah good, I deleted the cache and rejoined and it crashed, so it's reproducible
19:38 VanessaE     kahrl: ah, that makes it much easier to find
19:38 kahrl        unfortunately I know nothing about the animated mesh code in minetest so it'll be hard for me to debug
19:38 kaeza        ask Taoki
19:38 Exio         how do you crash it?
19:38 Exio         (as, how do you reproduce it exactly)
19:39 Exio         just connect to kaeza's server without cache
19:39 Exio         ?
19:39 kaeza        Exio, make the client cache a new model
19:39 kahrl        Exio: rm cache/media/*, join kaeza's server
19:40 Exio         ok
19:40 kahrl        next I'll try if just installing the soccer mod locally is enough
19:41 Exio         i think pilzadam added an if (soccer_mod_installed_on_server) random_crash();
19:41 Exio         ;P
19:41 kaeza        HAH
19:41 kaeza        possible :P
19:41 VanessaE     heh
19:41 sapier       nono its if soccer_viewer_at_keyboard
19:41 Exio         lol
19:45 kahrl        install soccer mod; create world; enable soccer mod for world; rm cache/media/*; load world in singleplayer world <-- does not cause a crash
19:45 sapier       :-)
19:47 kaeza        kahrl, maybe it is caused by media DL as I said?
19:47 sapier       doesn't gdb show where it is? compile -O0 ;-)
19:50 kahrl        sapier: it does but it's not overly helpful
19:50 kahrl        http://paste.dy.fi/mqa
19:50 sapier       hmm this is setting a texture by a stall texture pointer where's the pointer from?
19:51 sapier       hmm internaly
19:52 Exio         that is not a debug build kahrl
19:53 kahrl        it is but with -O1
19:53 sapier       but wouldn't help either exio this looks like trying to draw something that has been incorrectly cleaned up
19:53 sapier       e.g. delete a texture, invalid multiple drop ... something like that
19:54 Exio         ah
19:54 celeron55    valgrind is your friend
19:55 BlockMen     c55, checked my pull?
19:56 celeron55    BlockMen: yeah, i'll apply it some day
19:56 celeron55    it's not particularly critical :P
19:56 BlockMen     just wanted know ;)
19:58 BlockMen     celeron55, you are ok when i make a pull for this too? -> https://github.com/BlockMen/minetest.net_dokutemplate/commit/678ab8fb43961d071c23b7c6f7e9331b405e3eb9
20:00 kahrl        rm cache/media/cd5e67d04d9e033e0a005429a1997ea6b0d7ce05 <-- this does not cause a crash when connecting to kaeza's server
20:00 kahrl        that file contains the soccer ball
20:00 kaeza        how about the player model?
20:00 VanessaE     I expect that deleting the object files for sheep, rats, or player models will cause it to crash on my server
20:01 VanessaE     (the latter because I use stu's knees-and-elbows model)
20:01 celeron55    BlockMen: no
20:02 celeron55    viewing page sources and old versions can be useful for anyone (and are available anyway so hiding them is just obscure)
20:02 kahrl        kaeza: doesn't seem to crash it either
20:02 BlockMen     celeron55, thought you will say no :P
20:03 celeron55    BlockMen: and much of those can be disabled from the admin page i guess
20:04 BlockMen     IIRC you can just switch on/off in general from admin page...
20:09 kahrl        deleting wool_white.png from the cache does not crash it
20:10 kahrl        which is the texture used by the soccer ball
20:10 kaeza        how does MT generate the hash?
20:10 kahrl        sha1 of the file contents
20:11 kaeza        hmm
20:11 kahrl        I'm going to try binary search
20:11 kahrl        deleting cache/media/[01234567]* causes a crash
20:12 kaeza        some mem corruption in the caching routine?
20:12 kaeza        maybe too much items to cache
20:12 kahrl        I assume some timing problem
20:13 kaeza        could be too
20:13 kahrl        the mesh is created when the texture is not available yet, or will be deleted later, or something like that
20:13 Jordach      kahrl, kaeza can one of you use a capital letter as a first letter
20:13 Jordach      i mix you two up often
20:14 kaeza        just write one more letter :)
20:14 sapier       is there any duplicated texture name?
20:14 kahrl        I used Kahrl at some point and didn't like it
20:14 sapier       asfaik textures are deleted prior readding on connect ... if there is a double used name this texture would become invalid
20:14 kahrl        deleting cache/media/[0123]* causes a crash
20:15 sapier       and this would explain why it doesn't happen on second time too as the texture beeing there once would stopp both new ones to be requested
20:16 kahrl        sapier: good idea, I'll check that when I'm done with this binary search
20:16 kahrl        deleting cache/media/[01]* does not cause a crash
20:17 sfan5        good night
20:18 kahrl        deleting cache/media/[23]* does not cause a crash. ????
20:18 VanessaE     maybe it's a simple matter of a buffer overflow?
20:18 kaeza        ^ what I said
20:18 VanessaE     yeah, what he said. :P
20:18 kaeza        :P
20:19 Jordach      kaeza is a girls name
20:20 * Jordach    wanted a thats what she said
20:20 kahrl        deleting cache/media/[4567]* causes a crash; certainly looks like the more files need to be added to the cache, the more likely it is to crash
20:20 kaeza        Jordach, "kaeza" is a lazy ass way to spell "cabeza" ("head" in spanish")
20:21 kaeza        -"
20:21 sapier       kahrl textures are stored by their hashes but added to irrlicht by name
20:22 Exio         til what you nick means kaeza lol
20:25 kaeza        :D
20:25 kaeza        okay, let's stop off-topic chit-chat
21:04 kahrl        so yeah. I replaced smgr->getMesh(rfile) in client.cpp with createCubeMesh(v3f(1.0, 1.0, 1.0))
21:04 kahrl        it still crashes
21:05 sapier       kahrl did you check for texture duplicates yet?
21:05 kahrl        I'm not sure how to best check for them
21:06 sapier       it happens on first login true?
21:06 kahrl        it happens on login if your cache is sufficiently empty
21:06 sapier       place an assert in the code where textures are deleted prior adding new one ... of course this will always crash on second login but if there's a duplicated name it happens right on first login
21:09 kahrl        tile.cpp:873 <-- is that the right place?
21:10 sapier       yes seams to be
21:13 sapier       but I'm not sure if this is really the only location
21:14 kahrl        I added an output to verbosestream there, grep of debug.txt: http://paste.dy.fi/mnk
21:14 sapier       wow quite some
21:15 sapier       but are they really duplicated?
21:15 kahrl        but none that are connected to any CAO mesh in some way
21:15 VanessaE     RBA was getting those damn "forcesingle" things all over the place - what are they?
21:15 kahrl        VanessaE: forcesingle is a relic from when the texture atlas existed
21:15 VanessaE     ohhhh
21:16 sapier       cause those textures are only tile related kahrl if it's no tile they aren't added
21:16 sapier       maybe you need to check them on receiving
21:17 sapier       client.cpp line 1767
21:17 sapier       there you have all texturenames
21:18 sapier       I guess in verbose stream you should already see it
21:18 kahrl        they all go through insertSourceImage, I think
21:18 sapier       maybe different models use same texture?
21:19 kahrl        from what I've seen there are only two models
21:19 kahrl        the player and the soccer ball
21:20 sapier       and "player" is same as generic player?
21:20 kahrl        pretty sure it is
21:20 sapier       same texture too?
21:20 kahrl        it looked like it when I was on the server
21:20 sapier       maybe without soccer_mod prefix?
21:21 kahrl        how do you mean that?
21:22 sapier       if both models use a texture with same name but at different locations?
21:22 kahrl        the soccer ball uses wool_white.png
21:23 sapier       hmm this is same as texture for wool??
21:23 kahrl        yes
21:23 sapier       so it's loaded at completely different positions once for a tile once for a mesh but uses same texture name!
21:24 kahrl        not sure what it uses for the black spots, presumably flat black
21:24 sapier       try renaming the texture for ball if it still fails I'm wrong
21:24 kahrl        well I can't
21:25 kahrl        it only fails if I connect to kaeza's server
21:25 kahrl        it doesn't fail if I try it in singleplayer mode
21:25 sapier       with exactly same mods?
21:25 kahrl        no
21:26 kahrl        there are too many, can't be bothered to check them all to be safe
21:26 sapier       it could be a combination of timing and general bug I don't think there's any check for tiles and meshes using exactly same texture name
21:26 sapier       you could check if the name is wool_default and not delete in this case
21:27 sapier       but this is a very very special test of course
21:27 kahrl        well it never prints any wool texture to verbosestream at tile.cpp:873
21:27 kahrl        so that would be pointless
21:27 sapier       true
21:28 sapier       but why?
21:28 sapier       if you have a ball using it it has to be there
21:28 kahrl        I also added a call to isKnowsSourceImage where Client calls insertSourceImage
21:28 kahrl        isKnown*
21:28 kahrl        seems to never return true
21:29 kahrl        in theory, the texture should only be sent once and added as a source image once
21:29 kahrl        which seems to be the case
21:29 sapier       I'd sugges asking irrlicht directly
21:31 kahrl        I don't think any image have been added as textures to the video driver at that point in the program
21:31 kahrl        images
21:31 kahrl        (aside from those needed for the main menu)
21:31 kahrl        they will be added later, in rebuildImagesAndTextures
21:31 sapier       the error you showed is either a completely unrelated memory corruption or a use of a deleted texture
21:32 sapier       at least that's what I would search for
21:33 kahrl        I'll try deleting all removeTexture calls from the entire codebase and see if that changes anything
21:33 VanessaE     so crashing aside, what ultimately happens?  are some textures being loaded into memory more than once?
21:33 sapier       yes if it helps at least this guess is correct
21:34 sapier       irrlicht has a 1:1 relation between texture name and texture representation in memory so it can't be there twice (at least within irrlicht)
21:34 VanessaE     that's what I'd have thought
21:35 sapier       so if by some reason texture names collide and the "old" one is cleaned up prior readding this would render a in use texture pointer invalid
21:35 kahrl        well here we go
21:35 kahrl        doesn't crash anymore (with an empty cache)
21:36 sapier       so we need to find the double used texture
21:36 sapier       and of course how to handle this more gracefully than crashing
21:36 kahrl        I will reenable the removeTexture calls one by one until it crashes again
21:37 sapier       I don't think that'd help kahrl
21:37 sapier       the removal is correct
21:37 kahrl        just to see where it happens
21:37 sapier       it doesn't happen on remove ;-)
21:38 kahrl        huh? disabling all those calls "fixed" the crash
21:38 celeron55    kahrl: just do it, it's the right thing to do :P
21:38 sapier       if you never ever render any texture pointer invalid you can't crash due to invalid pointers ;-P
21:38 sapier       it's like never freeing memory to avoid a use after free
21:39 sapier       but try it ;-)
21:40 celeron55    i sense sapier's fearful attachment to some of his leak removal code that is blocking his brain from functioning 8)
21:40 sapier       no celeron55 I guess my code is reason for this to happen as I didn't ever think about a texture beeing used for completely different things
21:41 sapier       so I guess I didn't add any checks for this to happen
21:42 kaeza        sapier, this happened way before your memory leak fixes
21:42 celeron55    there have already been multiple times in MT's history when overzealous memory leak fixes have broken stuff in obscure ways
21:42 celeron55    maybe it's time to be more careful when doing them
21:42 celeron55    (assuming it is because of some of such)
21:42 sapier       no celeron55 it's time to clean mt's crap memory usage
21:43 sapier       if you claim memory her and there and delete it at completely different locations you don't have to wonder this will fail
21:43 hmmmm        it's fine as long as it's documented
21:44 sapier       you know as good as me that documentation is always outdated
21:44 sapier       and of course ppl don't read it unless something bad happens  ;-)
21:46 hmmmm        i guess I'm guilty of this too, i ought to add a note in EmergeManager that MapgenParams become "property" of Map after it's been associated with it, and therefore is deleted by Map, not EmergeManager
21:47 hmmmm        but nobody would question it if they don't see it in valgrind in the first place
21:47 * kahrl      is about to present some science
21:47 kahrl        connecting to kaeza's server works if and only if ((the cache is sufficiently prefilled) or (tile.cpp:873 is commented out))
21:48 hmmmm        ahh!  the crash-on-connect bug, you solved it?
21:48 hmmmm        :D
21:48 sapier       yes if course ... but not usefull at all if you comment out 873 you don't delete any textures on reconnect
21:48 kahrl        hmmmm: there's at least two crash-on-connect bugs
21:48 hmmmm        you ought to just add a reference counter and call it a day
21:49 kahrl        the other one involves the mesh update thread not running for some reason
21:49 hmmmm        hmm
21:49 VanessaE     the second bug, for reference:  http://pastebin.com/4ctZUC2v
21:50 hmmmm        i remember, before I did my emergethread renovation, celeron complained in the ServerThread at "somehow EmergeThread gets stuck in a stopped state"
21:50 sapier       so if you disable 873 you'll readd the big texture leak ;-)
21:51 hmmmm        might be a similar problem, might be a problem with JThread even, who knows.. my complaint with jthread is that it has all of that really unnecessary synchronization code
21:53 celeron55    sapier: the problem really is that the AtlasPointer references work on the presupposition that as long as the TextureSource they were gotten from hasn't been deleted, they are valid (IIRC)
21:54 celeron55    that might not properly hold true either
21:54 sapier       I can't proove this but I don't think this is related to atlas at all
21:54 celeron55    it might need some kind of an additional indirection that would be centralized in TextureSource
21:54 celeron55    so that it can invalidate them
21:54 sapier       I guess there's a texture with same name used twice
21:54 celeron55    sapier: AtlasPointer has nothing to do with atlas
21:55 celeron55    or, it can have, but it's used for everything
21:55 celeron55    it's an abstraction
21:55 sapier       yes a central texture management doing reference counting would probably solve the issue
21:55 celeron55    but really the way irrlicht works doesn't help at all either
21:56 celeron55    it always caches everything and never removes anything, unless specially told in a cumbersome way
21:56 sapier       maybe it doesn't work because of us doing wrong
21:56 sapier       atm we delete textures on readding new ones
21:56 sapier       if any subsystem deletes it's textures on shutdown this isn't necessary anymore this irrlichts reference counting would take effect
21:57 celeron55    you can't remove any texture of which something has taken an AtlasPointer reference (practically a Texture*) already
21:57 celeron55    s/AtlasPointer reference/AtlasPointer/g
21:58 sapier       sorry I don't understand what you're pointing at celeron
21:59 celeron55    my point is that tile.cpp:873 can't be there without major rework
21:59 sapier       without 873 you allways have to quit minetest on disconnect
22:00 celeron55    it can be in the destructor of TextureSource, by storing all texture pointers that have gotten old in an array
22:00 sapier       unless you have basic textures so you will survive  about 10 times of reconnect
22:00 celeron55    assuming that the mesh generation thread and all drawing is 100% guaranteed to stop before TextureSource is deconstructed
22:01 sapier       isn't TextureSource a static variable?
22:02 sapier       no it isn't
22:03 celeron55    it actually looks like that can be guaranteed
22:03 kahrl        it's tied to a call of the_game
22:03 celeron55    it currently is
22:03 celeron55    Client is destructed by the scope a bit before it, and the draw loop won't be visited again
22:03 celeron55    (when Client goes, there goes mesh generation too)
22:04 sapier       btw the texture source destructor already cleans up textures
22:04 celeron55    it doesn't clean up those that are handled by :873
22:05 celeron55    those texture pointers aren't stored anywhere at that point anymore
22:05 celeron55    thus what i said:
22:05 celeron55    >by storing all texture pointers that have gotten old in an array
22:05 celeron55    or, better said, that were replaced
22:06 sapier       would at least avoid loosing them yes
22:06 celeron55    it will clean them up between games, which is the desired outcome
22:06 sapier       sounds like a reasonable workaround
22:07 sapier       still I guess this shouldn't even happen as texture cache should be empty prior receiving textures
22:07 celeron55    well there are obviously some design flaws in this 8)
22:08 kahrl        sapier: it happens in the cases shown here: http://paste.dy.fi/mnk
22:08 sapier       true very obvious ... I guess we should put "redesign texture handling" on the midterm todo list
22:08 kahrl        when I connected to kaeza's server, anyway
22:09 sapier       I guess someone added default and flowers textures to her/his mod without renaming them
22:09 sapier       but this guess needs confirmation of course
22:10 kahrl        who would add flowers_dandelion_yellow.png but none of the other flowers?
22:11 sapier       no idea kahrl but those textures are far to less to be a generic error
22:11 sapier       its 5 of ... I guess 500?
22:11 sapier       maybe a copy error or something like that
22:13 sapier       of course this is not an excuse for minetest crashing the worst thing minetest should do is print an error message
22:15 PilzAdam     kahrl, just diggin through the logs: re http://paste.dy.fi/bUt: minetest_game's PNGs are already compressed with pngcrush -brute
22:16 kahrl        ah ok
22:17 kahrl        I'll see how much optipng+advpng can still do
22:17 PilzAdam     IMO its not worth it for these little textures, but whatever
22:17 kahrl        sapier: I tried the textures one by one, only allowing it to delete one of the 10 listed
22:17 kahrl        deleting flowers_dandelion_yellow.png^[forcesingle caused it to crash
22:17 VanessaE     also pngquant to turn them into indexed 256 color (if they are't already), since they're 16px anyway, you won't lose any colors.
22:18 sapier       strange
22:18 kahrl        haven't tried the 4 textures below yet
22:18 sapier       so it's unrelated to cao?
22:18 kahrl        possibly
22:19 sapier       maybe multiple problems again :-)
22:19 kahrl        this time the crash happened in CBillboardSceneNode::render
22:19 kahrl        so maybe it was a dandelion item thrown on the ground near me
22:20 sapier       true didn't think about items :-) ... still the question is if really someone duplicated the texture
22:20 kahrl        I have an idea, not sure how solid
22:21 kahrl        the server sends some stuff to the client before it is fully initialized
22:21 kahrl        for example inventory formspec, contents of detached inventories (I saw that in debug.txt)
22:22 kahrl        I think it might send active object messages too
22:22 kahrl        so a dandelion item gets some kind of message and updates its texture before it has been downloaded
22:22 kahrl        probably to some kind of fallback texture (those single color ones)
22:22 sapier       yes but it'd fail using unknown texture instead
22:23 sapier       ok and then it's deleted and replaced by real one
22:23 kahrl        yeah
22:23 kahrl        with the same name --> boom
22:23 sapier       possible yes
22:24 sapier       but does it really use the correct name for dummy textures?
22:24 kahrl        I think it does, but I haven't looked at this part of the codebase in a while
22:25 sapier       another point that may be worth a cange
22:25 kahrl        23:56:57: ERROR[main]: generate_image(): Creating a dummy image for "flowers_dandelion_yellow.png"
22:26 sapier       :-( ok I guess celerons suggestion moving textures in 873 to trash list is a good idea at least for 0.4.7
22:26 kahrl        and similar lines for exactly those 5 textures that were in my paste (except those with ^[forcesingle)
22:27 kahrl        I like the idea of the trash list
22:27 sapier       it's still a workaround only ... most likely one to be there for a long long time
22:27 kahrl        it preserves (or readds) a useful invariant about TextureSource
22:28 kahrl        as you can see, it doesn't happen very often that a texture is deleted in 873
22:28 kahrl        so the memory overhead is small
22:29 sapier       yes I assumed to never happen in 873 but didn't remove it because I thought it wouldn't harm either ... wrong
22:29 Exio         if (t_old != 0) { freeit; t_old = 0; }
22:29 sapier       wouldn't do anything if t_old ever is 0 ;-)
22:30 sapier       -ever +allways
22:30 Exio         what if the free doesn't set it to 0?! ;P
22:30 sapier       nothing
22:30 sapier       t_old is a local variable
22:30 Exio         aw
22:31 sapier       it just good practice to set a pointer to 0 after deletion to make sure you'll recognize a use after free
22:31 Exio         what i said was mostly a joke, btw
22:32 PilzAdam     kahrl, why dont you push https://github.com/minetest/minetest/pull/747 directly?
22:34 kahrl        I never push without another dev's confirmation or at least enough silence
22:35 PilzAdam     I guess typo fixes, link updates and other trivial stuff like this can be pushed without 2 devs agreeing
22:36 kahrl        fair enough
22:38 kahrl        https://gist.github.com/kahrl/5695206
22:39 kahrl        sapier, celeron55: ^
22:39 sapier       wait
22:42 sapier       ok looks fine  I've just been irritated by the "creatTextureSource" in diff
22:42 kahrl        I don't know why it does that
22:42 kahrl        but it's ~TextureSource
22:43 sapier       maybe a m_texture_trash.clear() after all
22:44 kahrl        why?
22:44 kahrl        when ~TextureSource returns it will do that anyway
22:45 sapier       you added something to the vector so you should remove it ... yes I know this is most likely done on deletion of vector too
22:45 sapier       at least for std::vector this will be done
22:46 kahrl        it's kind of the point of these standard containers to not have to worry about such things
22:46 sapier       it's just avoiding mistakes kahrl
22:46 sapier       if you are used to cleanup everything you added you're less likely to forget it
22:47 kahrl        I would add a line like that if it wasn't in the destructor
22:47 kahrl        but there's not much place to do something wrong when the TextureSource is going away anyway
22:47 sapier       line 18 does a clear
22:48 kahrl        I see it and I want to remove it ;)
22:48 sapier       do it ... just look at minetests code ... everyone assumes to be a very good coder and not to for get anything ... still we have lots of bugs because ppl do forget
22:49 sapier       me too of course
22:50 kahrl        bugs usually happen when there's too much code or too many different files involved in a single thing
22:50 VanessaE     regarding bugs, what's gonna be with these entity lighting issue?  (one, where dropped items are way too bright, and the other where mobs/players/etc all get the same lighting/brightness level
22:51 VanessaE     issues*
22:51 kahrl        VanessaE: they've been around forever and don't crash anything
22:51 kahrl        come back when 0.4.7 is released :P
22:51 VanessaE     true.
22:52 VanessaE     when?  if. ;)
22:52 kahrl        indeed
22:52 sapier       bugs happen on ppl think they know what they are doing ... to many files are not an issue if they're independent
22:53 PilzAdam     no, over night the bugman comes and places them in your code
22:54 Exio         cool story bro
22:54 sapier       bugman? isn't that you second nickname PilzAdam? ;-)
22:56 kahrl        kahrl the bug was not being asked, they have simply chased him away
22:56 PilzAdam     the bugs could live without being noticed by anyone (they sometimes do this), but they usually crash the program or produce missbehaviour because they want to be fixed
22:57 PilzAdam     you need to understand the life and behaviour of bugs before you can properly fix them
22:57 sapier       ok I've to work today so have fun guys
23:08 PilzAdam     can I push this tweak to farming: https://github.com/PilzAdam/MiniTest/commit/2e0cf154e84737a7e8b5ce9398adf379976e5be6 ?
23:09 kahrl        imo yes
23:09 VanessaE     yes, but I'd split the difference
23:09 VanessaE     20 -> 5/8?  maybe 20 -> 10/8.
23:09 VanessaE     don't make it too easy to get seeds
23:10 PilzAdam     well, its kinda annoying if you want to start farming and you have to search 20 minutes to find a _single_ grass node and it doesnt drop seeds then
23:10 PilzAdam     grass isnt very common
23:11 VanessaE     aw come on, make those lazy-ass users work for it ;)
23:12 PilzAdam     whats the point in replacing the same grass node 20 times and dig it over and over again?
23:13 PilzAdam     have you tried it in pure survival gameplay yet?
23:13 VanessaE     probably because in practice, the user won't think to do that?
23:13 VanessaE     but ok
23:13 VanessaE     not in survival *mode*, but when I test stuff, I always test it from a survival perspective
23:13 PilzAdam     its just not good for the gameplay to make getting seeds harder
23:14 kahrl        I've you've played skyblock or super hostile or any map of that sort you *will* think of strategies like that
23:14 kahrl        s/I've/if
23:15 VanessaE     I've complete skyblock actually.
23:15 VanessaE     completed*
23:16 PilzAdam     did nobody noticed the bug in that commit? :-)
23:30 sweetbomber  hmmmm: ill implement my getBiome() proposal
23:31 sweetbomber  hmmmm: do you already have some lua scripts that register a few biomes, to ease debuging?
23:33 PilzAdam     http://pastebin.com/xwmCD3ae
23:33 PilzAdam     ^ some test biomes by hmmmm
23:33 Exio         adding a function to the GUIChatConsole, the name it would get should be "closeConsoleonEnter", no?
23:34 Exio         or should it closeConsoleOnEnter?
23:34 PilzAdam     the second one
23:34 Exio         kk
23:36 PilzAdam     its called camelCase
23:39 Exio         i wasn't sure about the "on"
23:39 Exio         i always use something_like_this for functions ;P
23:40 PilzAdam     thats called sneak_case :-)
23:40 VanessaE     I do as Exio does usually.  camelCase is hard for me to read.
23:41 PilzAdam     code more Java :-p
23:41 VanessaE     byte your tongue.
23:42 VanessaE     methinks we have a Mjoang spy in our midst!
23:43 VanessaE     or Mojang even\
23:44 sweetbomber  ty PA, i was (unsuccessfully) looking for some biomes in forum
23:46 kaeza        better CamelCase that m_pHungarian notation
23:47 kaeza        or even that stupid afunctionwithoutspaces notation that Lua and C use
23:48 VanessaE     heh
23:48 Exio         i prefer strcpy than stringCopy
23:55 Exio         should i add a "fake_input" function to the guiChatConsole to do the stuff with the 'backend' used internally or use the backend what is used by it when it is defined directly?
23:56 Exio         fakeInput*
23:56 Exio         s/what is used/that is used/
23:59 kahrl        not sure what you are trying to do