| Time |
Nick |
Message |
| 00:14 |
|
Taoki joined #minetest-dev |
| 00:16 |
Exio |
<<99 |
| 00:16 |
Exio |
oops |
| 00:17 |
|
Jordach joined #minetest-dev |
| 00:18 |
|
sapier1 joined #minetest-dev |
| 00:21 |
|
BlockMen left #minetest-dev |
| 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 |
| 02:47 |
|
VanessaE joined #minetest-dev |
| 04:36 |
|
VanessaE joined #minetest-dev |
| 06:17 |
|
zweipktfkt joined #minetest-dev |
| 06:21 |
|
TB`oFF|Vibe-X joined #minetest-dev |
| 06:21 |
|
Anchakor joined #minetest-dev |
| 06:21 |
|
thexyz joined #minetest-dev |
| 06:21 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 06:30 |
|
Anchakor1 joined #minetest-dev |
| 06:49 |
|
TB`oFF|Vibe-X joined #minetest-dev |
| 06:49 |
|
thexyz joined #minetest-dev |
| 06:49 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 06:58 |
|
emptty joined #minetest-dev |
| 07:30 |
|
Calinou joined #minetest-dev |
| 08:42 |
|
kahrl joined #minetest-dev |
| 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:18 |
|
Calinou joined #minetest-dev |
| 09:23 |
thexyz |
that's just fucking great |
| 09:23 |
thexyz |
http://i.imgur.com/SK1G4MP.png |
| 10:31 |
|
celeron55 joined #minetest-dev |
| 10:32 |
proller |
no coredump? |
| 10:33 |
|
Jordach joined #minetest-dev |
| 10:35 |
|
celeron55 joined #minetest-dev |
| 11:08 |
|
PilzAdam joined #minetest-dev |
| 11:15 |
Kray |
apparently minetest gets to Arch's community repo |
| 11:16 |
|
Taoki joined #minetest-dev |
| 11:18 |
PilzAdam |
thexyz, that happens a lot when dealing with meta or inventories |
| 11:23 |
|
Calinou joined #minetest-dev |
| 11:38 |
|
iqualfragile joined #minetest-dev |
| 11:51 |
|
ImQ009 joined #minetest-dev |
| 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 |
| 12:35 |
|
Zeg9 joined #minetest-dev |
| 12:36 |
|
celeron55 joined #minetest-dev |
| 13:10 |
|
serengeor joined #minetest-dev |
| 13:34 |
|
sapier joined #minetest-dev |
| 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:49 |
|
hmmmm joined #minetest-dev |
| 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:11 |
|
Jordach joined #minetest-dev |
| 14:11 |
|
Jordach joined #minetest-dev |
| 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:18 |
|
NakedFury joined #minetest-dev |
| 14:18 |
|
sweetbomber joined #minetest-dev |
| 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:30 |
|
iqualfragile joined #minetest-dev |
| 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:46 |
|
Calinou joined #minetest-dev |
| 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:00 |
|
iqualfragile_ joined #minetest-dev |
| 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:21 |
|
emptty1 joined #minetest-dev |
| 16:22 |
|
emptty2 joined #minetest-dev |
| 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:39 |
|
MinerofLands joined #minetest-dev |
| 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:17 |
|
mrtux joined #minetest-dev |
| 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:48 |
|
BlockMen joined #minetest-dev |
| 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:56 |
|
ImQ009 joined #minetest-dev |
| 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 |
|
BlockMen left #minetest-dev |
| 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 |
| 20:38 |
|
Topic for #minetest-dev is now >>> FREEZE until at least June 5 23:59 UTC (0.4.7) <<< Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 20:54 |
|
BlockMen joined #minetest-dev |
| 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 |
|
emptty joined #minetest-dev |
| 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:35 |
|
BlockMen left #minetest-dev |
| 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:15 |
|
salamanderrake joined #minetest-dev |
| 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 |
| 22:57 |
|
sapier left #minetest-dev |
| 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 |
|
sweetbomber joined #minetest-dev |
| 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:52 |
|
ch98 joined #minetest-dev |
| 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 |
