Minetest logo

IRC log for #minetest-dev, 2014-07-06

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

All times shown according to UTC.

Time Nick Message
00:07 Piggybear87 joined #minetest-dev
00:07 Piggybear87 left #minetest-dev
00:11 sapier joined #minetest-dev
01:03 sapier hmmmm I don't understand how this code results in user placed nodes to do mud flowing
01:05 hmmmm sapier, huh?
01:05 sapier doesn't makeChunk always create a new block based only on seed?
01:06 hmmmm based off of seed and mapgen parameters
01:06 hmmmm why worry about that, though?  we know the issue is in block unloading
01:06 hmmmm i took a nap before and I actually dreamt that I was looking for calls to updateTimer
01:06 hmmmm lol
01:07 sapier I start to believe it's not the reason
01:07 hmmmm what?  why
01:07 sapier I'm more about loading the block
01:07 hmmmm all logic and reason points to the block unloading
01:07 sapier not only, a block unloaded has to be loaded again too
01:07 sapier so the error could happen there too
01:08 hmmmm yeah, but we're clearly seeing blocks that had just been generated getting unloaded.
01:08 hmmmm that's the problem.
01:08 sapier thats ONE problem maybe we have more
01:09 sapier think about following scenario, block is loaded user manipulates that block, it's unloaded ... and on loading the mud flow is aplied to the user modified block
01:09 sapier because that's what I see, I see my placed nodes to flow
01:09 hmmmm yes
01:10 hmmmm that's because that block is inside of a chunk that gets a request to be generated again
01:10 sapier yes but my data is present
01:10 hmmmm and it so happens that when it loads, m_generated is false because it wasn't able to get reloaded in finishBlockMake to set that
01:10 hmmmm your data being present only means it's not a dummy block
01:11 sapier yes but if it's generated from scratch how can my nodes be still present and flow
01:11 hmmmm no no no
01:11 hmmmm you're not understanding
01:11 hmmmm makeChunk does not always create the same exact result given any block
01:11 sapier that's why I'm asking
01:12 sapier I'm not talking about some random variation
01:12 hmmmm if you give a chunk of already generated land terrain to mapgen v6, it'll re-do all the steps that it had already done
01:12 sapier oh
01:12 hmmmm one of the steps, adding mud, involves doing a downward probe to find the ground (after things had been re-added)
01:13 hmmmm then TO THE GROUND LEVEL IT FOUND it'll add the dirt nodes
01:13 hmmmm so if the first non-air block it hits is dirt with grass, or maybe a brick block, it'll start adding another dirt node on top of that
01:13 sapier so we give generated data to mapgen?
01:13 hmmmm that is the result of giving already-generated map to mapgen
01:14 sapier why is this even possible?
01:14 hmmmm i experienced the same problem when I went to make my minecraft classic -> minetest map converter.  i wrote the blocks manually to the database but i forgot to set generated = true
01:15 hmmmm and mapgen v6 kept shitting all over my buildings with mud
01:15 hmmmm it's possible because base terrain (stone and air) aren't written if the content isn't content_ignore
01:16 hmmmm however, the mud adding and flowing phase places the blocks on the ground level that it found regardless of the previous content type (air or not)
01:16 hmmmm luckily for you, this behavior allowed us to find such a horrible issue
01:17 sapier I'm not as sure as you are we really found it
01:20 hmmmm if it weren't for the mud adding, you would've never known about this and we'd just wonder why the Android version has such horrible performance and write it off as the hardware sucking, when in fact blocks are getting unloaded and reloaded and regenerated every millisecond
01:22 sapier true
01:23 sapier still we don't have any idea why it happens
01:23 sapier and we don't know what's wrong if this happens ... I'd guess this happens on pc too but there blocks aren't unloaded very often
01:24 hmmmm well obviously after the first unloading interval the block unloader starts going insane
01:24 hmmmm so i know where to start looking at least
01:24 sapier who's supposed to reset the timer?
01:24 sapier block unloader is correct they really time out
01:25 sapier but why
01:25 hmmmm that's the part we still need to figure out!
01:28 sapier hmm at least reseting that timer may have concurrency issues
01:28 hmmmm what timer, m_map_timer_and_unload_interval?
01:29 sapier m_usage_timer in block
01:29 hmmmm oh
01:29 hmmmm there are no other threads that write to m_usage_timer though
01:30 hmmmm that one call is literally the only call that increments the usage timer
01:30 sapier no I was wrong the lock is just taken five levels above
01:31 sapier this way of locking is crap you never know what lock is used to do what
01:31 hmmmm OH
01:31 hmmmm you're talking about resetUsageTimer
01:32 sapier yes that's what's causing the block to unload ... at least if I'm not towards completely wrong direction ... which is perfectly possible too
01:33 hmmmm GetNextBlocks is envlocked iirc
01:33 kahrl does what you are talking about have anything to do with the comment at the beginning of ServerEnvironment::activateBlock?
01:34 hmmmm lol what
01:35 sapier hmm nanoseconds ... on what machine?
01:36 hmmmm I don't understand that comment... the block unloading is envlocked as well as anything that calls activateBlock
01:36 kahrl is CiaranG around sometimes?
01:37 sapier haven't seem him for a while
01:40 sapier maybe the locks in emerge are to small
01:40 hmmmm they're not
01:40 hmmmm they're perfectly where they should be
01:42 hmmmm I think it would be a smarter design to add the finished blocks straight to map instead of doing it in initBlockMake
01:45 hmmmm sapier, to confirm the issue, at least, you should enclose everything inside of the try statement in emergethread in an envlock
01:45 hmmmm that should in theory fix the bug
01:45 hmmmm (but it's not a solution)
01:47 sapier map.cpp L2310 that 3d loop we should be able to get all blocks there shouldn't we?
01:48 hmmmm yes, if the second parameter were true
01:49 sapier ohh ok
01:49 hmmmm I really dislike how it's been overridden by ServerMap and has a second boolean parameter with a completely different meaning
01:51 hmmmm if you change that to true, then in theory you should start seeing a lot of blocks popping up with CONTENT_IGNORE rather than blocks covered with mud 8)
01:51 sapier using try catch block for lock isn't a good idea :-/ causes deadlock
01:51 hmmmm that loop is pretty stupid and it shouldn't be there, but it is because apparently this problem has been around a while there blocks suddenly start falling out of the sky and get unloaded before finishing the make
01:51 hmmmm oh
01:52 hmmmm you obviously need to remove the other cases where envlock is done
01:52 hmmmm or make it into a recursive mutex
01:53 sapier hopefully those functions taking the lock aren't called by someone else
01:53 hmmmm they aren't.  they are separate functions for code clarity
01:54 hmmmm in any case, recursive pthread mutexes for JMutex has been added to my wishlist (windows mutexes are already recursive by default)
01:55 sapier where I work we've got a saying if you need recursive mutexes you're just to lazy to do it correct ;)
01:56 hmmmm or you're interested in modular code where you don't need to worry about who holds a lock where
01:57 sapier usually a big lock is already a mistake
01:57 hmmmm talk is cheap, show me the mapblock transaction code!
01:58 sapier hmmmm I don't need to write minetest on my own ;-)
01:58 hmmmm heh
01:59 sapier I'll gladly leave some parts for others ;-)
02:01 sapier ok it's time to get some sleep this is not gonna give any results tonight (at least not by me)
02:01 sapier left #minetest-dev
02:01 hmmmm b-b-b-ut you're the only one who has an android setup :(
03:11 kaeza joined #minetest-dev
03:31 us`0gb joined #minetest-dev
03:36 OldCoder joined #minetest-dev
03:54 diemartin joined #minetest-dev
03:54 OldCoder joined #minetest-dev
04:25 blaaaaargh joined #minetest-dev
04:32 CraigyDavi joined #minetest-dev
04:48 BrandonReese joined #minetest-dev
04:49 Taoki joined #minetest-dev
04:55 deltib joined #minetest-dev
06:08 Taoki[mobile] joined #minetest-dev
06:51 nore joined #minetest-dev
06:54 CraigyDavi joined #minetest-dev
07:03 SmugLeaf joined #minetest-dev
07:03 SmugLeaf joined #minetest-dev
07:08 Weedy joined #minetest-dev
07:08 Weedy joined #minetest-dev
07:11 Hunterz joined #minetest-dev
07:12 us`0gb joined #minetest-dev
07:20 Weedy joined #minetest-dev
07:20 Weedy joined #minetest-dev
07:26 grrk-bzzt joined #minetest-dev
07:48 tomreyn joined #minetest-dev
08:11 BlockMen joined #minetest-dev
08:23 LemonLake joined #minetest-dev
08:34 PenguinDad joined #minetest-dev
08:41 proller joined #minetest-dev
08:49 grrk-bzzt joined #minetest-dev
09:05 grrk-bzzt joined #minetest-dev
09:05 grrk-bzzt joined #minetest-dev
09:14 PilzAdam joined #minetest-dev
09:14 sapier joined #minetest-dev
09:22 PilzAdam sfan5, https://github.com/minetest/minetest/issues/1445
09:22 sfan5 not an engine issue
09:22 Calinou joined #minetest-dev
09:23 PilzAdam see my comment
09:23 sfan5 :/
09:24 sfan5 so you want the server to check for all of the ActiveObjects in the sourrounding blocks whether one of them is attached to the removed ActiveObject?
09:25 Calinou joined #minetest-dev
09:25 sfan5 ^ PilzAdam
09:25 PilzAdam how did it work in 0.4.9?
09:25 sfan5 dunno
09:26 PilzAdam also https://github.com/minetest/minetest/issues/1158
09:26 Calinou joined #minetest-dev
09:27 sfan5 PilzAdam: are you using gcc? gcc sucks
09:27 PilzAdam you cant close issues because you think a compiler sucks
09:28 PilzAdam "minetest/po/be/minetest.po: warning: Charset "CHARSET" is not a portable encoding name." <- this can be fixed by just writing UTF-8 in the .po file
09:28 sfan5 PilzAdam: were you using gcc or not?
09:28 PilzAdam yes
09:29 Calinou about compilers… https://github.com/minetest/minetest/issues/143
09:30 PilzAdam sapier, https://github.com/minetest/minetes​t/issues/786#issuecomment-48107058
09:31 sfan5 Calinou: gcc isn't any better https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902
09:33 sapier can someone check if this was in formspecs as long as they exist?
09:34 sapier sfan5: Calinou I'm not sure if this was a compiler issue at all cause on android same effect occured on race condition
09:36 sapier can someone else have a look at those? I'm busy trying to find the mapgen issue right now
09:36 ImQ009 joined #minetest-dev
09:36 PilzAdam sapier, I guess the intlGUIEditBox was there for a reason: https://github.com/minetest/minetest/commi​t/c0e4551249dcc1e09ee09877f136ce12fe359520
09:37 sapier no it's been just crap
09:37 sapier if it had a reason it's been a hack not a solution
09:39 PilzAdam I'm resetting to the previous commit and check if signs support äöü
09:39 sapier resetting is not an option
09:39 PilzAdam just checking if it's really the cause
09:40 sapier hmm guess we don't have other formspec fields to check
09:40 sapier well I think you'll find a sane way to fix it ... not that sure about the mapgen/emerge/whatever issue
09:41 BlockMen for me umlauts work
09:42 PilzAdam sapier, yep, signs only have umlauts if using the old "hack:sign_text_input"
09:42 PilzAdam (which uses the intlGUIEditBox)
09:44 PilzAdam sapier, IMO this should be fixed before the release
09:44 PilzAdam and I wonder why nobody tested this before
09:44 sapier well I wonder same about the mapgen bug on android ... seems everyone did test on multiplayer only
09:46 sapier If I haven't found a solution by about 4 o'clock this afternoon that's gonna be the "solution" for 0.4.10 too ... disable singleplayer
09:46 sapier on android of course
09:46 us`0gb joined #minetest-dev
09:47 sapier PilzAdam could this be another variant of the irrlicht i18n issues we experienced in file select dialog?
09:48 PilzAdam umm... dunno?
09:49 sapier we had issues there for hmmm 0.4.8 ... irrlicht did mess up localization so we disabled the local install feature
09:54 sapier did anyone ever have thread safety in mind on writing that code :-(
09:56 casimir joined #minetest-dev
10:04 Taoki Hey. How many hours from now is the release taking place? Curious when new features can start flowing in GIT again :D
10:05 Taoki Considering there are any waiting to be merged and only on hold due to the feature freeze, of course
10:06 PilzAdam Taoki, apparently people did not test enough in the feature freeze; and all the bugs that appear now need to be fixed more or less
10:07 Taoki Ah. Great, a delay :P
10:08 Taoki I use latest GIT all the time also. Didn't notice any bugs. Depends what mods / features are tested of course
10:23 vifino joined #minetest-dev
10:31 lemonlake_ joined #minetest-dev
10:35 us`0gb joined #minetest-dev
10:44 Taoki So, no chance of it being released today any more? When is it expected to be released then?
10:45 sfan5 Taoki: who said it isn't going to get released today?
10:45 sapier by now nothing is decided
10:45 Taoki sfan5: Misunderstood PilzAdam then. Thought he meant there are a lot of bugs left so a delay is needed
10:46 sapier sfan5 we've got major issues so questioning release isn't that far
10:47 sfan5 the issues have been known for a long time
10:47 sfan5 it's not like we've only known about them since yesterday
10:49 PilzAdam sfan5, the attachment bug we talked about earlier; the waving water by RealBadAngel; the broken umlauts in chat
10:49 PilzAdam thats all bugs we know since yesterday (or today)
10:49 sfan5 the broken umlauts in chat
10:49 sfan5 uh no
10:49 sfan5 we know of that since at least one year
10:50 RealBadAngel whats the issue with waving water??
10:50 BlockMen PilzAdam, the attachment bug is not a blocker
10:50 sapier yes ... and the android singleplayer issue ... which seems to be a generic issue just happening way more often on android
10:50 PilzAdam RealBadAngel, that you apply waving to all liquids
10:50 PilzAdam we talked about that yesterday
10:51 BlockMen ^ that is not even issued on github
10:51 PilzAdam sfan5, they worked for me until sapier replaced intlGUIEditBox with generic formspec
10:51 PilzAdam thats like a few weeks ago
10:51 BlockMen and thats and improvement, not a bug at all
10:51 RealBadAngel you have waving liquids since months already and you call it an issue just now?
10:51 sfan5 PilzAdam: I'm pretty sure you've noticed that earlier
10:51 PilzAdam RealBadAngel, months? was it in the last release?
10:52 BlockMen ^ yes
10:52 PilzAdam sfan5, the chat? no
10:52 casimir joined #minetest-dev
10:52 BlockMen the chat seems to be linux exclusive
10:53 PilzAdam BlockMen, so what?
10:53 BlockMen that is called "feedback", PilzAdam
10:53 sfan5 PilzAdam: then you haven't; but we know that non-ASCII chat is basically broken since >1 year
10:53 PilzAdam RealBadAngel, still, there needs to be way for me to turn it off, since waving liquids don't make sense in Nodetopia
10:53 sapier instead of discussing could someone plz try to find it?
10:54 PilzAdam its not generally an "improvement"
10:54 BlockMen but not a bug too^
10:55 RealBadAngel 3 Dec 2013
10:55 sapier there is a bug but it's not in chat but in formspec text input handling ... that bug was there before ... but didn't occur on that location by now
10:55 BlockMen IMO we should release anyway, especially in the sense, that 0.4.9 stable is damn unstable
10:55 RealBadAngel waving water is here for more than half a year
10:55 PilzAdam sfan5, I just rechecked it; umlauts in chat are broken since 23 days
10:56 BlockMen and this are (except mapgen bug) minor issues
10:56 PilzAdam I dont understand how you can know that for over a year
10:56 RealBadAngel PilzAdam, and even more, you have pushed that code in
10:56 sfan5 PilzAdam: https://github.com/minetest/minetest/issues/786 we know that it was broken anyway, even without the formspec change
10:57 PilzAdam RealBadAngel, maybe I got confused because I always had that setting turned off
10:57 sfan5 PilzAdam: 2 people (megaf & calinou) reported it being broken before sapier made the formspec change
10:57 PilzAdam sfan5, it worked with freetype
10:57 PenguinDad PilzAdam: it didn't work with freetype for me
10:57 PilzAdam sfan5, there seem to be 2 issues; at least one is caused by sapier's changes
10:58 PilzAdam the other affects Calinou and Megaf
10:58 sapier wtf how can a abm be called for a not loaded position
10:59 PilzAdam sfan5, and the fact that something is broken for some people doesn't justify to break it for more people
11:00 RealBadAngel PilzAdam, thats not my fault then. You had enough time to notice that feature. Calling that an issue right now is kinda bad joke.
11:00 PilzAdam RealBadAngel, yes, so we move that to after the release
11:02 RealBadAngel PilzAdam, ok. i will make an open issue on water and other liquids, because i wanna change that anyway
11:03 sapier ok what about the mapgen issue ... I'm almost sure it's there in pc version too but results in something different, maybe the occasional crashes we still have
11:03 sapier I call it mapgen issue knowing it's not exactly mapgen
11:08 sfan5 incoming commit in 5 minutes: http://sprunge.us/ieRT
11:09 sapier stop ... why do remove the const?
11:10 sapier what does clang complain about it?
11:11 sfan5 it complains because GenericCAO::isPlayer has const and ClientActiveObject::isPlayer doesn't
11:11 sfan5 if you were to call isPlayer on a GenericCAO casted to ClientActiveObject it would not find the method
11:12 sapier any reason not to add the const to ClientActiveObject too?
11:12 sfan5 (or something like that)
11:12 sfan5 I don't think there is any
11:12 sfan5 I think I'll do that instead
11:12 sapier is CLientActiveObject modified by isPlayer?
11:13 sapier adding is always better then removing
11:13 sapier reduced risk someone does bad things
11:13 sfan5 why would it?
11:13 sapier I don't know ... there are strange things happening in mt sometimes ;-)
11:17 sfan5 sapier: http://sprunge.us/hFQB better?
11:19 sapier yes
11:19 sfan5 ok, pushing
11:22 Taoki RealBadAngel: Hey. I'm around and available for the next hours, if you want to work on that shader issue now (you said next morning).
11:22 Taoki Kinda hoping it could make it into 4.10, so other people with ATI cards won't get the flicker
11:24 RealBadAngel Taoki, i do have code almost rdy, need half an hour or so
11:24 Taoki oh, ok
11:31 sapier argh ... we really should fix that damn loging concurrency issue ... it always results in memory curruption
11:53 celeron55 may i suggest getting the release out ASAP?
11:53 celeron55 we still have a ton of traffic coming from the reddit post
11:54 celeron55 and everyone who downloads stuff gets 0.4.9 while they could be getting 0.4.10
11:54 celeron55 and by asap i mean "preferably 20 hours ago but that's not possible"
11:55 BlockMen should i build with leveldb?
11:55 celeron55 why?
11:55 BlockMen then ppl an use if they want?
11:55 BlockMen but idc, im just asking
11:56 Taoki celeron55: As far as I'm concerned, I only suggest waiting until I fix the shader flickering with RBA. It's possible that shaders cause an annoying flicker on all ATI cards... at least on mine they do
11:56 celeron55 i think that's not needed, also if you do that, then everyone doing official windows builds would have to do it from now on
11:56 Taoki But we'll probably figure it out in a few
11:56 celeron55 which is a useless burden
11:56 RealBadAngel Taoki, thats not ati issue
11:56 BlockMen celeron55, k
11:56 Taoki oh
11:56 RealBadAngel im on radean card and dont have it
11:56 Taoki Might be an issue with Mesa / Gallium then. I'm one of the few people who game on free video drivers in Linux :P
11:57 RealBadAngel it is issue that also nore has, but  fix that works for him, apparently doesnt work for you
11:58 RealBadAngel trying to google something on possible reason
11:58 Taoki I see. Strange then
12:01 nore Taoki: I also use free drivers
12:02 Taoki Ok. That explains why we both had it then
12:02 Taoki Nvidia or ATI?
12:02 nore amd == ati, right?
12:02 nore so yes, ati
12:03 nore and also using mesa/gallium
12:06 RealBadAngel what drivers paramat is using? anybody knows?
12:12 Jordach joined #minetest-dev
12:26 Taoki nore: Interesting. ATI too and I still get it
12:26 Taoki After RBA's suggestions so far
12:27 VanessaE what issue are we talking about exactly?
12:28 RealBadAngel problems with gl_Normal vector on open source drivers
12:28 Taoki VanessaE: Apparently, shaders cause surfaces to flicker between dark and bright on the free video driver
12:28 sfan5 <Taoki> celeron55: As far as I'm concerned, I only suggest waiting until I fix the shader flickering with RBA. It's possible that shaders cause an annoying flicker on all ATI cards... at least on mine they do
12:28 sfan5 that one
12:28 VanessaE oh that
12:28 VanessaE yeah, not an issue on my box
12:28 RealBadAngel apparently not all ati cards
12:28 VanessaE AMD+fglrz here
12:29 VanessaE fglrx*
12:29 RealBadAngel this seems to happen only on open source ones
12:30 Taoki Yeah, you won't get it on fglrx
12:30 RealBadAngel this seems to be related: http://lists.freedesktop.org/archive​s/mesa-commit/2014-March/048733.html
12:30 RealBadAngel Despite not correctly converting normal vectors from
12:30 RealBadAngel +       * GLbyte[3] to float[4], the rendering looks OK.
12:55 sfan5 I am just running minetest in valgrind
12:56 sfan5 and my (fullscreen) console overflows with text before the mainmenu even appears
12:56 sapier if you find anything except "invalid access of length 4" it's worth looking for it
12:57 sfan5 >invalid access of length 4
12:57 sfan5 not a bug or what?
12:57 sapier it is a bug ... but in valgrind
12:57 sfan5 suuurrreee
12:58 sapier I didn't believe that when I was told first too ;-)
12:58 sfan5 ==21522== Invalid read of size 2
12:58 sfan5 better?
12:58 sfan5 it does not even start
12:58 sfan5 but that is probably the fault of the intel driver being so broken
12:59 sfan5 oh right.. I have to disable luajit
12:59 PilzAdam at least there are no memory leaks when starting to the menu and then exiting
13:01 sapier well known issues are overlapping memcpy in openal too ... but we can't do a lot about this
13:01 sfan5 fork OpenAL
13:02 sfan5 RealBadAngel: is this shader bug your fault? https://forum.minetest.net/v​iewtopic.php?f=21&amp;t=9676
13:02 sapier if you wanna do it and sign a contract you're gonna fix all bugs within 4 weeks within the next 10 years ;-)
13:02 sfan5 pff
13:02 sfan5 you can't simply fix "all" bugs
13:03 sapier did I said "simply"? ;-)
13:03 sfan5 you can't do it non-simply either
13:05 sfan5 ==23182==    definitely lost: 2,272 bytes in 18 blocks
13:05 sfan5 gg
13:08 sfan5 sapier: I did not find a single "invalid read of size 4"
13:09 sapier 64 bit?
13:09 sfan5 yes
13:09 sapier did you find size 8?
13:09 sfan5 yes
13:09 sapier there it is
13:10 sapier native read size is 8 so compiler tries to read 8 bytes even if only a single one is required
13:10 sfan5 can you link me the bug in valgrind? (I'm sure they have a bug reporting system)
13:10 sapier so in worst case 7 bytes are out of range while you're actually only interested in first one
13:10 sfan5 it would be a compiler bug if it would read more than requested
13:10 sapier no I'm not a human link collection ;-)
13:10 sfan5 or a bug in the code
13:13 RealBadAngel sfan5, im not sure what i can see here
13:14 RealBadAngel it looks like weird textures for me
13:14 RealBadAngel also he complains about not waving stuff, outdated game?
13:14 sapier no it's not reading 8 bytes is way faster on those machines as long as only those bytes within allocated memory are used it's perfectly fine to read more
13:16 sfan5 RealBadAngel: he says "this [shaders not working] is sad, because I would like to have waving plants" in his 2nd post
13:17 sfan5 sapier: if the compiler does not know whether that memory area is useable, it would be a bug if it were to read 8 bytes
13:17 RealBadAngel to have waving plants game has to define waving property
13:17 RealBadAngel enabling shaders option is not enough
13:18 sapier but copiler knows about intel having 8 bytes access available
13:18 sapier and amd64 too
13:18 sapier bus width is 64 bits so there's no way the first byte can be available and one of the others not
13:19 sfan5 are you telling me my CPU can't read just a single byte?
13:19 sapier it can but it's horribly slow compared to 64 bit access
13:27 sfan5 wtf
13:27 sfan5 WTF
13:28 PilzAdam sfan5, why do you keep closing this if the warning is not fixed for me? https://github.com/minetest/minetes​t/issues/1158#issuecomment-48107614
13:29 sfan5 why do you keep opening this if the warning is fixed for me?
13:29 sfan5 how is this not giving a warning? https://github.com/minetest/minetes​t/blob/master/src/nodedef.cpp#L859
13:29 sfan5 getId expects a reference
13:30 sapier seems to be ok but quite ugly
13:31 sfan5 you can't pass a value to a reference
13:31 PilzAdam sfan5, so you think that if a issue is fixed for a single person it can be closed?
13:31 sapier you can
13:31 sfan5 PilzAdam: since when are you multiple persons?
13:31 PilzAdam btw, memory leak fix: https://gist.github.com/Pil​zAdam/34358b9e90c4cf7e13dc
13:31 PilzAdam sfan5, what?
13:32 sfan5 PilzAdam: who else confirmed this is an issue right now (= with latest git)?
13:32 PilzAdam why do you want someone else to confirm it?
13:33 sfan5 <PilzAdam> sfan5, so you think that if a issue is fixed for a single person
13:33 sfan5 "so you think if an issue is not fixed for a single person it can't be closed"
13:34 sfan5 and this is just a compiler warning
13:34 PilzAdam yes, an issue can only be closed if its fixed for everyone
13:35 sapier argh .... MapgenV6 is a perfect example for WHY you SHOULD use m_ prefixes ... did anyone of you ever read a 1000 line function mixing local and member variables?
13:36 sapier btw MapgenV6 is singlethreaded only never ever try to generate multiple chunks a once
13:37 PilzAdam sfan5, yes, since compilers are different you can't close issues about them just because you can't reproduce them
13:38 sfan5 PilzAdam: does that mean we support building with gcc 3.1.2?
13:38 PilzAdam you need to verify that its fixed for the one who originally opened / reopened the issue
13:38 sfan5 did you originally report it? no
13:38 sapier well if that one doesn't anwer within reasonable time you can close it for old age
13:38 PilzAdam sfan5, read one word more
13:41 sfan5 <PilzAdam> btw, memory leak fix: https://gist.github.com/Pil​zAdam/34358b9e90c4cf7e13dc
13:41 sfan5 ^ you can push that
13:50 sfan5 sapier: I changed an offset and all "invalid read of size {2,8}" disappeared, didn't you say there were a valgrind bug?
13:50 sfan5 they*
13:51 sapier what offset?
13:52 sfan5 of some memset
13:52 sapier show me
13:52 Jordach joined #minetest-dev
13:52 sfan5 I'll do that after I've investigated something
13:53 sapier so how am I supposed to change my opinion because of you did something and something did happen ;-)
13:59 sapier but if you really found a way to stop valgrind from running insane that'd be great as it's been a mess to find the real bugs in there
14:00 sfan5 why is chartowchar_t not using mbstowcs?
14:01 sapier because mbstowcs isn't available on some architectures and behaves quite different on about any architecture/os
14:02 sapier if you change something there you've to be very carefully chances to break something are about ... hmm ... 90% ;-)
14:04 Anchakor_ joined #minetest-dev
14:05 sfan5 sapier: just correcting the memset seems to have silented the errors
14:05 sapier which memset?
14:06 sfan5 sapier: someone did a memset(something, 0, length); without multiplying with sizeof(something)
14:06 sfan5 and there were sizeof(wchar_t)*1 too many bytes
14:07 sfan5 s/$/ copied/
14:07 sapier can you show me? not sure but this realy seems to be an error
14:08 sfan5 http://sprunge.us/AZCS?diff
14:08 sapier why +1?
14:09 sfan5 size_t l = strlen(str)+1;
14:09 sfan5 I moved that +1 to the individual ones
14:09 sapier ah you remove it up
14:09 sfan5 (except the last one)
14:09 sfan5 this ensures there is a zero wchar_t at the end
14:10 sapier hmm that code seems familiar, if it wasn't me I may have been at least last one touching it without noticing
14:13 sapier but if I read correct that code won't cause  bug, it's just a incomplete memset ... which could be removed anyway
14:14 sfan5 valgrind complained
14:15 sapier blind trust in tools ...
14:15 sapier see l is strlen +1
14:16 sapier so nstr has one char more then required
14:16 Piggybear87 joined #minetest-dev
14:16 Piggybear87 left #minetest-dev
14:16 sapier memset initilizes first bytes (most likely half of array) to 0
14:17 sapier later memcpy copys length * sizeof(wchar) (the exact size of that array)  memory
14:17 sfan5 you don't need to explain
14:18 sapier I'd hope for someone to explain why valgrind is supposed to complain about that ;-)
14:18 sfan5 because memcpy might do a read on that uninitalised part
14:18 sfan5 modern memcpy implementations may use xor for speed
14:18 sapier why?
14:20 sapier wait length +1 ... does lenght contain the null terminator or not?
14:20 sapier according to man page not
14:21 sfan5 strlen is only the number of chars
14:21 sfan5 http://sprunge.us/GjLH?diff may I push this?
14:21 sapier hmm guess for wchar a null terminator is still 1 byte only
14:22 sfan5 that would make no sense
14:22 sfan5 1 byte can't be a wchar_t
14:22 sfan5 and functions couldn't do while(*p != 0) ...
14:22 sfan5 I don't think someone would design it this complicated
14:23 sapier ok so this isn't a explanation too
14:23 sfan5 http://stackoverflow.com/questions/12305868/wc​har-ends-with-single-null-byte-or-two-of-them
14:23 sfan5 >Since a wide string is an array of wide characters, it couldn't even end in an one-byte NUL.
14:23 sfan5 basically what I said
14:24 sapier yes that's what I expected too but results in this code should be perfectly fine
14:24 sapier except of the half memset of course
14:24 sfan5 soo.. I can push this?
14:25 sapier if it's the memset only why not fix it by removing it?
14:25 sapier instead of changing the way to count too
14:25 sfan5 the memset is needed because of the forced 0 wchar_t
14:26 sfan5 the memcpy only copies (l) bytes while memset sets (l+1)
14:26 us`0gb joined #minetest-dev
14:26 sapier for what reason? the array is as big as thestring?
14:26 sfan5 no
14:26 casimir joined #minetest-dev
14:26 sfan5 the array is the string + terminator
14:26 sapier then there's a bug anyway ;-)
14:27 sapier array should be created after creating the intermediate string using it's length
14:27 sfan5 wide strings are guaranteed to be length*sizeof(wchar_t)
14:27 sapier then we don't need a memset
14:28 sapier because wstring is guaranteed to be 0-terminated
14:28 sfan5 the compiler will optimize it away anyway
14:28 sfan5 leave the memset alone :(
14:28 sapier why?
14:28 sapier we don't need to write things that aren't required, especially if we know it ;-)
14:29 sfan5 kk, I'll remove it
14:29 sapier you should check if this fixes it too ;)
14:30 celeron55 so what is the status of 0.4.10?
14:30 sapier depends on how problematic you see the mapgen bug
14:31 sapier for what I know now the reason is there in pc code too but doesn't cause the bug to appear (by now)
14:31 celeron55 has anyone seen it happen anywhere else than android?
14:31 BlockMen IMO we should release anyway
14:31 sfan5 sapier: valgrind is complaining again
14:31 BlockMen and no, only on android
14:31 celeron55 then it is not a problem
14:31 sfan5 ^
14:31 sapier then we haven't understood what's happening there sfan5
14:31 rubenwardy joined #minetest-dev
14:31 sfan5 maybe it is really a bug in valgrind
14:31 celeron55 any other large issues?
14:32 sapier BlockMen: you don't know it's android only .... we just know it happens there way more often
14:32 sfan5 I'll just push http://sprunge.us/GjLH?diff (the inital thing)
14:32 celeron55 did the amd open source driver thing end up in something?
14:32 sapier I hate fixes without having understood what happens
14:32 BlockMen he asked wheather anyone seen somewhere else
14:32 sfan5 ^ commit incoming right now
14:32 BlockMen not if it is android only, spaier
14:32 BlockMen *sapier, sry
14:32 sapier IT ISNT ANDROID ONLY
14:33 BlockMen reread what i said
14:33 Calinou joined #minetest-dev
14:33 sapier this has been seen on pc too but way les often
14:33 werwerwer joined #minetest-dev
14:33 BlockMen issue?^
14:33 celeron55 the question is, is it going to get a fix soon
14:33 celeron55 if not, then we will release
14:33 sapier obsucure crashes and segfaults
14:33 vifino joined #minetest-dev
14:34 celeron55 if it will get a fix, then we will fait for the fix
14:34 celeron55 wait*
14:34 sapier ok then I'll stop investigating now and disable singleplayer for android for this release
14:34 BlockMen you dont know if this is caused by same issue, sapier
14:34 BlockMen do you?
14:35 celeron55 fixing this should be top priority after release though
14:35 sapier so we're going to release because of not having proove a major issue happens on pc too ... great way of doing a release blockmen ;-P
14:35 PilzAdam celeron55, here is a large issue: https://github.com/minetest/minetest/issues/1445
14:35 celeron55 and a new release should happen once it is solved
14:35 BlockMen what? since when i can decide when and how we do releases?
14:35 sapier I have no proove true but it's more then likely it's there in pc too
14:37 celeron55 are people going to fix this stuff if the release is pushed to next weekend or will everyone just go to sleep and we have the exact same situation then?
14:37 sapier I know about that bug since yesterday
14:37 sapier I can't guarante to have a fix till next weekend but I'm working at it
14:38 celeron55 i think we will move the release by one week then
14:38 sapier I don't know a lot about mapgen code so I'm still trying to find out how it's supposed to work
14:40 Krock joined #minetest-dev
14:40 celeron55 i moved the milestone to 2014-07-13
14:41 celeron55 as it seems it's impossible to get a release out without major bugs otherwise
14:42 BlockMen the bugs are smaller than in current "stable"
14:42 celeron55 how much smaller?
14:43 PilzAdam BlockMen, current stable was released without notifying everyone and without a feature freeze
14:43 BlockMen PilzAdam, even worse
14:44 BlockMen celeron55, i would say it does as randomly as 0.4.9 does (at least for win)
14:44 BlockMen see the news thread for 0.4.9 about that
14:44 celeron55 what
14:44 celeron55 that sentence didn't make any sense
14:45 BlockMen *doesnt crash as 0.4.9 does randomly
14:45 BlockMen better?
14:46 BlockMen well, w/e. i guess one week makes no big difference
14:46 celeron55 having a map generator bug is quite serious though, and having a reliable way to segfault a client by the server is kind of... just not good
14:46 celeron55 if these can be gotten rid of in a week, it's a win for everyone
14:47 Calinou if mods are modified, won't the bug be fixed? by making the mentioned boat undiggable while there's a rider, or by making it detach when dug
14:47 BlockMen i ment "no big difference" in term of "providing 0.4.9" ;)
14:47 BlockMen Calinou, its already fixed in next
14:47 arsdragonfly joined #minetest-dev
14:48 celeron55 Calinou: it should be possible to segfault anything from mod code; so no
14:48 celeron55 shouldn't*
14:57 diemartin joined #minetest-dev
15:03 BlockMen celeron55, mergin _next also moved to next week i guess?
15:04 celeron55 i guess it can be done already if people are bored otherwise
15:05 celeron55 i'm not going to change my mind on that anymore
15:05 PilzAdam BlockMen, you break my farming_plus mod by doing that, right?
15:05 BlockMen PilzAdam, i already told you how to easily fix
15:06 BlockMen you just need to rename your function(s)
15:07 PilzAdam :-/
15:13 BlockMen ok, last change to scream, i will push following in 10 min https://github.com/BlockMen/minetest_game
15:16 rubenwardy When were boats added to minetest_game?
15:16 BlockMen they were added to minetest_next and this get merged into _game now
15:17 rubenwardy ah!
15:17 PilzAdam BlockMen, have you at least created proper boat models?
15:17 BlockMen PilzAdam, do you want say you are providing a bad model with your mod?
15:18 PilzAdam I can imagine better models
15:18 BlockMen make a pull^
15:19 VanessaE I thought the model looked fine, frankly.  just the textures need improvement
15:19 hmmmm joined #minetest-dev
15:24 BlockMen pushing now
15:35 Jordach if someone has the blend for said model, i'll improve it into a real boat
15:35 hmmmm 09:22 sfan5 not an engine issue
15:35 hmmmm WTF
15:35 hmmmm a segfault is ALWAYS an engine issue
15:35 sfan5 it was 09:22
15:35 sfan5 maybe I didn't have my coffee yet
15:43 sapier hmmmm new information for mapgen bug, it doesn't require makeChunk to be called twice
15:43 hmmmm it what?
15:44 sapier for same area
15:44 hmmmm that wouldn't make any sense
15:44 sapier the bug happens even without overlapping areas
15:44 hmmmm this would be a lot easier if i were able to debug it myself...
15:44 hmmmm erm anyway
15:44 sapier I know this doesn't make sense but that's what I see
15:44 hmmmm so what were the results of extending the envlock to the entire try-catch block and removing the other locks?
15:45 cenegd joined #minetest-dev
15:45 hmmmm the two locks you needed to remove were the one in getBlockOrStartGen() and then another one in the scope after makeChunk
15:53 sapier hmm it's not regenerated ... because it's not generated at all :-(
15:54 sapier emerge thread is waiting in queue so no deadlock there
15:54 hmmmm oh oh
15:55 hmmmm start the lock underneath the queue wait
15:55 sapier server thread is waiting for lock
15:55 hmmmm the point of this is to include getBlockOrStartGen, makeChunk, and the block after makeChunk all inside of the same lock
15:55 sapier ahhh silly me
15:56 sapier guess I should take a break :-/
16:01 Calinou_ joined #minetest-dev
16:02 rubenwardy joined #minetest-dev
16:04 sapier hmmmm still happening
16:04 hmmmm what does the piece of code look like after you modified it?
16:07 sapier https://gist.github.com/sa​pier/3db8d19cfac358446294
16:09 LemonLake joined #minetest-dev
16:10 cenegd left #minetest-dev
16:16 sapier but in this scenario we get double generation again so maybe the lock fixes one bug but not all
16:17 hmmmm what was the one bug it fixed?
16:17 sapier split locks?
16:17 sapier the bug happening without double generation?
16:17 hmmmm the double generation is the main bug
16:18 sapier well doesn't matter if there's a main bug if another one causes same to happen ;-)
16:18 hmmmm let's reason out this result:
16:19 hmmmm because the map generation was locked from initblockmake (the point at which the MapBlocks were actually created and added to Map), the time in between actual generation, to the setGenerated(true) and the blit back
16:19 hmmmm it should be logically impossible for you to ever see blocks with block == true but generated == false
16:21 hmmmm which means that the only error case that should happen would be for the block to be seemingly nonexistant
16:21 EvergreenTree joined #minetest-dev
16:22 hmmmm but then it doesn't find it in the db for some reason ... before a block is unloaded, it is saved
16:22 sapier whttps://gist.github.com/gists this is a full map generation till the bug happened once
16:22 sapier wait
16:22 sapier https://gist.github.com/sa​pier/1ead5784c5bb1c339004 here
16:23 Megaf joined #minetest-dev
16:24 hmmmm how is it possible for m_generated to be false
16:24 sapier there are even two blocks double generated in there first is (1,0,-2) ... first occurance of that blockpos is unload
16:24 hmmmm there is absolutely no gap in between the time the block is created and generated is set to true
16:24 sapier have a look at my code I initialize it to false for printing
16:24 sapier those values are irrelevant if block is false
16:24 hmmmm yes, but block is clearly true
16:25 sapier oops
16:25 hmmmm so anyway I think you're not going to get anywhere by just printfing things and guessing
16:26 hmmmm perhaps it's time to run it under a debugger
16:26 sapier btw on unloading the mentioned block "isGenerated" is set to true
16:26 hmmmm set memory breakpoints on m_generated
16:26 sfan5 warnings I got while building windows -rc1 builds: 32: http://sprunge.us/fAiN 64: http://sprunge.us/ZfLh
16:26 hmmmm so it's re-loaded with isGenerated set to false??
16:26 sapier memory breakpoints on android? ;-)
16:26 sfan5 maybe someone cares enough to fix those
16:27 sapier if they didn't add it this release that's not gonna be available
16:27 hmmmm humm
16:27 hmmmm sapier, looking at your log there seems to be an even spread of blocks getting unloaded with isGenerated true and false
16:28 hmmmm lol
16:28 sapier yes, have a look at 18:12:13 there the block to be reloaded is unloaded with generated true
16:28 hmmmm sapier, just for the hell of it, explicitly perform block->setGenerated(true) on the block that is being unloaded
16:29 sapier and in 18:13:24 it's loaded with isgenerated is false
16:30 sapier well actually it's not loaded at all as block is false too
16:32 sapier hmm
16:32 hmmmm did that fix it?
16:32 sapier it's not saved if it's not modified
16:32 hmmmm ahh
16:33 sapier let's print that info too
16:33 hmmmm I think the block modification is set in finishBlockMake, the same as setGenerated
16:34 hmmmm so it's likely the blocks have isGenerated == false are going to have no reason and not get saved
16:34 sapier yes but I fail to read a block having isGenerated set to true
16:34 hmmmm hmm
16:41 Megaf as days goes by more seg faults I get
16:41 Megaf Irrlicht log: GLSL version: 1.3
16:41 Megaf Segmentation fault
16:41 Megaf client side
16:41 Megaf segfaults turned to be really often since the merge of android thing
16:41 Megaf sometimes I will get this
16:41 Megaf Font size: 8 15
16:41 Megaf ^\Quit
16:41 hmmmm that's nice to know.... but do you have any information about them?
16:42 Megaf nope
16:42 hmmmm =/
16:42 Megaf It happens on a really random manner
16:42 hmmmm if they're really as common as you say, you should start running minetest in a debugger and taking a backtrace of it.
16:42 sapier https://gist.github.com/sa​pier/cf5eac763cf96a15aef1 any idea why I get same node range for different block positions?
16:42 Megaf but it seems to be more often when alternating tasks/windows or in background
16:43 hmmmm sapier, wher?
16:43 sapier 18:38:18: <-> 18:40:11:
16:44 hmmmm both of those are the same block positions
16:44 VanessaE hmmmm: I didn't take a backtrace of it, but I can give you a reproducible one:  start a cryptocoin mining app that runs on your GPU, crank it up fairly high until your desktop starts to "lag" a little, then start minetest and quickly take your focus away from the minetest window to something else.  80% chance Minetest will segfault.
16:44 hmmmm -2, -2, -2, to 2, 2, 2
16:44 sapier but 1,0, -1 isn't 2,0,2
16:44 werwerwer_ joined #minetest-dev
16:44 Megaf Curiosity: Time to compile minetest + minetestserver without redis nor leveldb support real2m24.487s
16:44 hmmmm oh oh oh
16:45 VanessaE (I suggest the crypto mining app only because it's easy to heavily-load the GPU and cause Minetest to be slow to start.  makes it easy to spot this crash.  that's all)
16:45 hmmmm whoops, sorry, I was looking at blockpos-min and blockpos-max
16:45 Megaf time to compile it with redis + leveldb support real2m33.429s
16:45 hmmmm sapier, that's because (1, 0, -1) is contained in the same 5x5x5 block chunk as (2, 0, 2)
16:45 sapier ok so we're actually looking for chunk regen
16:46 hmmmm when you go to generate a block, the entire chunk it's being contained in gets generated
16:46 hmmmm you probably thought that the chunk being generated is centered around pos
16:46 hmmmm which is false
16:46 sapier I thought something like that but you know there's a whole in emerge queue
16:47 sapier if that block is already taken from queue but not completed yet you can request same chunk again
16:47 sapier even if the blocks aren't unloaded as it happens in our case
16:47 hmmmm but why does this happen on android only if that's the real problem
16:48 sapier android is a quite slow device and most likely does way more scheduling
16:48 tomreyn joined #minetest-dev
16:48 sapier and it's arm so even memory access may be different
16:49 hmmmm so you push a block onto the emerge queue
16:49 hmmmm you find it's not generated
16:49 hmmmm you go to generate the entire containing chunk
16:49 sapier ok those blocks are generated but not modified on unloading
16:50 hmmmm ohhh...
16:51 sapier doesn't seem like they ever get set modified
16:51 hmmmm this might be caused by your voxelmainpulator optimization
16:51 sapier possible but how?
16:51 hmmmm that i am looking at right now
16:51 sapier memory result after all is done should be identical
16:56 zat joined #minetest-dev
16:57 hmmmm did MapVoxelManipulator use to define an addArea?
16:58 sapier yes
16:58 hmmmm er rather emerge
16:58 sapier I know what you meant
16:58 hmmmm so you removed MapVoxelManipulator, and then set it to addArea
16:59 sapier which was used before too
16:59 hmmmm ManualMapVoxelManipulator doesn't define an addArea though so it falls back to VoxelManipulator::addArea
16:59 hmmmm which does very different things from what MapVoxelManipulator::emerge did
17:00 sapier let me check
17:02 sapier no ManualMapVoxelManipulator had an emerge before just calling addArea from VoxelManipulator
17:02 rubenwardy joined #minetest-dev
17:03 hmmmm yeah but addArea does not load map the same way emerge does
17:04 sapier but emerge in ManualMapVoxelManupulator did just call addArea and didn't do anything else how could this result in an error if it's called directly?
17:04 sapier not sure if I understand what you wanna tell me :-/
17:04 hmmmm oh you're right
17:04 hmmmm i didn't realize it just called addArea and set flags
17:05 hmmmm i thought it loaded map
17:05 celeron55 ManualMapVoxelManupulator is called Manual because it actually doesn't do any of the automation that VoxelManipulator's emerge is allowed to do
17:07 celeron55 (MapVoxelManipulator did do that)
17:08 celeron55 the optimization changes there seem insanely error prone 8)
17:08 sapier well removing MapVoxelManipulator was your idea ;-)
17:10 sapier ok right now I see blocks getting unloaded that have been generated before and are flagged "not modified" some seconds later those blocks are tried to be loaded and I'm told "not generated"
17:12 Calinou joined #minetest-dev
17:16 Megaf Hm, it seems like pipeworks/mesecons are not respecting the max range of active objects, there are a machine working even when theres no one nearby nor online
17:16 Megaf thats not good
17:16 Megaf 14:16:21: ACTION[ServerThread]: :pipeworks takes stuff from chest at (-41,-2,748)
17:16 Megaf and I'm at 0,10,0
17:16 VanessaE why are you reporting that here?
17:17 Megaf because is the server who activate them?
17:18 celeron55 are you using forceloading
17:19 Megaf kind of
17:19 Megaf http://paste.debian.net/108400/
17:19 Megaf thats my actual minetest.conf
17:19 celeron55 "kind of" <- WTF?
17:19 Megaf celeron55; max_forceloaded_blocks = 1
17:20 celeron55 just file an issue on github
17:20 celeron55 nobody cares now
17:20 celeron55 and include more information than this
17:21 Megaf disable forceloading, and as soon as the server starts pipeworks will start too
17:21 BlockMen ShadowNinja, could you check the privs at forum? devs cant post topics on new
17:21 BlockMen +s
17:22 ShadowNinja BlockMen: I just fixed that.
17:22 BlockMen great
17:22 hmmmm hey sapier, what happens if you move the block->raiseModified and expireDayNightDiff things in finishBlockMake to the loop that sets the blocks as generated
17:22 sapier setGenerated already sets the modified flag
17:23 hmmmm ah true
17:23 hmmmm hmmm
17:23 sapier question fails saving or loading?
17:23 hmmmm ...check both?
17:23 hmmmm I'd say saving
17:24 hmmmm i don't think this behavior should happen if a save fails though
17:25 sapier hmm what if this isn't permanent error but the block just not loadable on checking if it's present
17:25 sapier that'd explain why user placed nodes flow
17:28 sapier great ... sqlite still resets the modified flag if it failed to write the block
17:32 celeron55 if it fails to write it, chances are it will fail forever and it will just overload a broken filesystem
17:33 celeron55 there'd need to be a controlled failure state that is reported to the user (there isn't)
17:33 sapier it's not even considered to be an error and written to infostream only ;-)
17:34 sapier "hey we couldn't write your map but don't bother that's not a problem" ;-)
17:35 celeron55 so is the issue that sapier's phone's memory is full or broken
17:35 sfan5 how about both?
17:35 hmmmm so wait
17:35 hmmmm it's confirmed that the map saving is busted?
17:35 sapier happens on at least 3 different devices ;-) all of them have enough memory left to write tons of debug.txt info ;-)
17:35 vifino joined #minetest-dev
17:35 sapier I don't know about sqlite yet
17:36 sapier I just added debug code there to see it
17:38 kaeza joined #minetest-dev
17:41 sapier 19:38:48: ERROR[ServerThread]: saveBlock: written=false there it is
17:44 hmmmm so wait, the save fails, but how does the block get re-requested and found in memory as not-generated
17:45 hmmmm the isGenerated = false part makes this odd
17:45 sapier it's not found in memory
17:46 sapier maybe saving doesn't fail but just tell "please wait" ;-)
17:46 hmmmm then block should be false
17:46 sapier let's see what sqlite tells about it
17:46 sapier it is false
17:47 hmmmm yeah but some of those blocks have block = true but isgenerated = false
17:47 sapier true so some piece is still missing
17:48 celeron55 reference for sqlite's result codes: https://www.sqlite.org/c3ref/c_abort.html
17:48 sapier SQL logic error or missing database
17:49 celeron55 are you printing those out there?
17:49 sapier argh I should have printed the number not sqls error message
17:49 sapier now I do
17:50 sapier imho database errors should go to errorstream not infostream
17:51 celeron55 probably so 8)
17:52 sapier we would have had that information about 24 hours ago :-(
17:53 sapier wtf: // TODO this mught not be the right length
18:02 sapier can someone explain to me why out main database code isn't sure if it's saving the right data ?
18:03 celeron55 i can't understand why it uses ostringstream::tellp
18:03 celeron55 it should use tmp.size()
18:04 sapier I changed it that way but I don't really believe thats the error
18:04 celeron55 it probably isn't the error
18:06 casimir joined #minetest-dev
18:06 sapier errorcode os 1
18:08 celeron55 sqlite error 1?
18:09 sapier yes
18:09 sapier so most simple SQLITE_ERROR
18:09 GhostDoge joined #minetest-dev
18:10 celeron55 https://www.sqlite.org/c3ref/c_abort_rollback.html https://www.sqlite.org/c3ref​/extended_result_codes.html
18:10 celeron55 try this
18:14 Krock hmm sqlite error? https://github.com/minetest/minetest/issues/1450
18:15 celeron55 Krock: that's not an sqlite error, go away
18:15 * Krock hides
18:15 Krock left #minetest-dev
18:19 sapier same
18:21 celeron55 umm... so it's an sql error?
18:21 celeron55 can you get that out as some kind of useful readable text
18:22 celeron55 it looks like this probably cannot happen on PC in practice and is something to do with the android sqlite port or its version or something
18:22 celeron55 so maybe 0.4.10 today? 8)
18:22 sapier I hope this way but It's same sqlite code as used on pc
18:22 celeron55 maybe if it's made to not fuck up things when sqlite fails we can release it
18:23 celeron55 so that it will just cease to work instead of messing up worlds
18:23 celeron55 messing up a random user's world is almost the worst thing that can happen and that's why this release is hanging
18:23 sapier assuming it's really android only the most easy way would be just disable singleplayer on android
18:24 celeron55 i
18:24 celeron55 i'm thinking of the case that this may happen on PC in some case
18:24 sapier if map can't be saved it's not worth releasing
18:24 celeron55 i'm not concerned of android; for all that matters to me we could just skip android
18:24 sapier talking about android right now and releasing that feature only
18:25 sapier hmm If it's sqlite ... I've got leveldb too ... I disabled it to not reduce size ... reenabling it and making it default for android might help
18:25 Jordach_ joined #minetest-dev
18:34 celeron55 https://github.com/minetest/minetest/issues/1436
18:34 celeron55 wtf is up with this?
18:34 celeron55 why is it broken
18:35 Calinou make Android multiplayer-only
18:35 OldCoder joined #minetest-dev
18:36 Calinou people could host a server on their PC anyway… also gives higher performance
18:36 sapier I may have a backup solution
18:36 sapier I already have leveldb support and just need to enable it
18:36 sfan5 not using sqlite3 seems to solve many android problems
18:36 sapier if it works this is a proove for it to be a sqlite issue only too
18:37 celeron55 does someone know which commit caused #1436?
18:37 sfan5 probably the shading rework
18:38 celeron55 this is annoying
18:38 celeron55 when someone makes something high-end, then low-end breaks
18:38 celeron55 and the other way around
18:38 celeron55 why can't people test properly after making things for themselves
18:39 sapier because there's to many possible build variants we have ;-)
18:39 celeron55 am i supposed to fix this?
18:40 celeron55 i don't want to
18:40 celeron55 but i don't want this to be broken
18:40 celeron55 where is RBA again
18:40 sapier prior blaming we should first try to find out what broke it ... I fixed a bug I made but I could still have missed something
18:40 celeron55 i'm going to ask him for money for the time i use for fixing this
18:42 RealBadAngel im trying to find a solution for issues with mesa/gallium drivers
18:42 RealBadAngel but still havent found anything
18:43 PilzAdam RealBadAngel, haven't we talked about why builtin:item shouldn't use "wielditem" drawtype a while ago?
18:43 Piggybear87 joined #minetest-dev
18:44 Piggybear87 left #minetest-dev
18:44 Calinou I could try each commit one by one
18:44 celeron55 i'm going to bisect this
18:45 celeron55 i have the fastest computer anyway for compiling it again and again...
18:45 Calinou which CPU? ;)
18:45 celeron55 i7-4800MQ
18:45 Calinou by the way, things seem OK to me, both with shaders and without shaders, on the latest commit
18:46 celeron55 disable smooth lighting
18:46 Calinou that should be as fast as mine
18:46 Calinou it's off indeed
18:46 Calinou for testing I use a pure white block (maptools:white)
18:46 Calinou trying with sand, looks OK too
18:48 Calinou oh, wait, I was using the “debug” light table; with the default one, the variation is literally invisible
18:48 Calinou we can conclude: there's variation but it's invisible
18:48 celeron55 [a0f78659f31abdce973bc6641b5b5a58f2ba9afc] Improved faces shading with and without shaders.
18:48 celeron55 that breaks it
18:48 gustav1 joined #minetest-dev
18:49 celeron55 working: http://c55.me/random/2014-07/mt​/tscrot-2014-07-06_21-49-13.png
18:50 celeron55 broken: http://c55.me/random/2014-07/mt​/tscrot-2014-07-06_21-48-50.png
18:50 celeron55 RealBadAngel: ^
18:51 Calinou first one is with debug light table, second one with normal light table: https://mediacru.sh/6f227a55246c
18:51 Calinou shaders off
18:52 celeron55 yes, that is too dark
18:52 celeron55 just as reported https://github.com/minetest/minetest/issues/1436
18:52 sapier https://gist.github.com/sa​pier/a3e0e767771567ebd904 this fixes that mapregen issue for me
18:58 celeron55 umm... how are shaders without smooth lighting supposed to look like?
18:59 celeron55 currently the sides of nodes are really dark
19:00 celeron55 well it has never been tweaked to look good so whatever
19:04 celeron55 okay so, can we now release despite of the segfault bugs?
19:04 celeron55 https://github.com/minetest/minetes​t/issues?milestone=3&amp;state=open
19:04 celeron55 and the one other blocker
19:04 celeron55 nobody is interested in fixing them
19:05 celeron55 do we wait until tomorrow and see if people report something of rc1?
19:05 sfan5 #1445 could be fixed if the server were to check all SAOs in adjacent MapBlocks whether they are attached to the removed SAO
19:05 sapier celeron55 prior addition of leveldb modified flag wasn't set back on save error ... and the error was sent to errorstream
19:05 sapier so how is it supposed to be?
19:06 sapier ttps://github.com/minetest/minetest/commit​/58841ef12f6cba1bb622353c1fcaa0e3c6fb46c9 map.cpp lines 3807...
19:07 hmmmm so changing the database works
19:07 hmmmm hmmm
19:07 hmmmm okay, there are still a number of bugs...
19:08 hmmmm we need to find the problem with sqlite3 on android, of course, but also block saving and loading needs to be revamped so that this sort of problem can never happen again and it'd be totally obvious that some saves failed
19:09 sapier h ttps://github.com/minetest/minetest/commit​/58841ef12f6cba1bb622353c1fcaa0e3c6fb46c9 map.cpp lines 3807...
19:09 sapier argh
19:09 sapier https://github.com/minetest/minetest/commi​t/58841ef12f6cba1bb622353c1fcaa0e3c6fb46c9 map.cpp lines 3807...
19:09 sapier it would've been obvious if it wasn't changed on leveldb addition
19:10 sapier question is shall we change it back?
19:11 sapier we've got reports about similar behaviour of leveldb ... guess the underlying error (unable to save) is same in those cases
19:12 sfan5 http://sprunge.us/ATGc?diff can I merge this? (aka does this count as bugfix?)
19:12 sfan5 s/merge/push/
19:13 sapier looks more like maintenance then bugfix
19:13 sfan5 yes or no?
19:13 sapier push it but be prepared to have your head cut of if it breaks something ;-)
19:14 sfan5 the bug is "leveldb backend does not give useful errors", so it's a bugfix
19:14 sfan5 k, pushed
19:16 sapier have you pushed it?
19:18 sfan5 yes
19:18 sfan5 oshit
19:18 sfan5 it does not compile
19:19 sapier lol :-)
19:19 sfan5 :)
19:19 PilzAdam lets release now!
19:19 sfan5 ^
19:19 hmmmm what I still can't understand is how not being able to save a mapblock causes such an error.  so the save fails, so that means future loadBlocks fail as well.  a new, blank block should be prepared for generation then
19:20 hmmmm unless it was that particular block that didn't get re-generated
19:21 hmmmm nevermind, i get it
19:21 hmmmm that had to be the case, logically.
19:22 sapier still how to behave on map save fail, reset the modified flag or not
19:22 sapier original code didn't reset it
19:22 hmmmm it's designed that way so it doesn't keep trying to save the failed block
19:22 BlockMen cant reproduce the bug either with whatever sapier gave me to test
19:23 hmmmm if the save fails, though, the usage timer should be reset and the unload should be canceled
19:23 sapier at least failing to save map should result in a error message not a info message ;-)
19:23 hmmmm yes, indeed, that would fix up the inappropriate behaviors observed in finishBlockMake as well
19:24 hmmmm as for the re-generation for blocks that had already been generated...
19:25 hmmmm how should that be tackled?  would it be wise to not blit back mapblocks that have already been marked as generated?
19:25 hmmmm (rather, make blitBackAll take a boolean parameter specifying whether or not generated blocks should be blitted back as well)
19:26 sapier oops
19:26 hmmmm this happened before with vanessae
19:26 sapier that branch was not supposed to end up on minetest repository
19:26 hmmmm she manually deleted a couple of erronoeous blocks
19:26 sapier I'll delete it soon
19:26 hmmmm and then the mapgen kept regenerating things like ores back in mid air
19:26 hmmmm and other oddities
19:27 hmmmm alright
19:27 hmmmm three corrective actions to take
19:27 hmmmm perhaps four if I want to combine block insertion and write
19:27 hmmmm this will be for the next version though
19:29 Tom-s joined #minetest-dev
19:31 sapier I'm pushing the leveldb switch now
19:31 sapier android only of course
19:32 sapier any news on #1445?
19:33 sfan5 <sfan5> #1445 could be fixed if the server were to check all SAOs in adjacent MapBlocks whether they are attached to the removed SAO
19:33 sfan5 somebody do that
19:33 sapier hmm hopefully there'll never be a lot of attached entities
19:34 celeron55 sfan5: wtf? it's a client-side segfault, you can't fix it in the server
19:35 celeron55 a malicious server could re-enable it
19:35 sfan5 celeron55: only the server can cause the player to de-attach
19:35 sfan5 oh.. you are viewing it from that point
19:35 sfan5 then..
19:35 celeron55 the client should never crash, no matter what is sent to it and no matter where it connects
19:35 sfan5 client should make sure removed CAO is not attached to LocalPlayer
19:36 celeron55 (or, it can crash, but not uncontrollably like segfault)
19:36 celeron55 sfan5: implement that
19:36 proller joined #minetest-dev
19:36 sfan5 -ENOTIME
19:37 sfan5 I have to prepare something for OldCoder and then help Jordach
19:37 sfan5 after that I could..
19:37 celeron55 i guess the client could just disconnect and go to the menu if that happens
19:37 celeron55 because... basically the client was deleted from the game
19:37 OldCoder Hi
19:38 celeron55 umm or
19:38 OldCoder Working on it with sfan5 today
19:38 celeron55 well yes, that's what the client should do if the server behaves like it does now
19:38 sfan5 celeron55: it's not the client that is deleted but the object the client is attached to
19:38 hmmmm a segfault is a possible remote execution vulnerability.
19:38 hmmmm i can't believe you don't have time to fix that
19:39 celeron55 well, it's not sfan5's bug in any way
19:39 sfan5 don't forget that everyone here does this voluntarily
19:39 celeron55 i took a quick look at it previously but didn't know where the check should go
19:39 sapier object attachements are quite messed up too
19:40 sfan5 and it's "just" a segfault by accessing freed memory anyway
19:40 sfan5 there is no possiblity of code exec there
19:40 sapier maybe instead of adding a quick hack we should schedule a real fix ... fixing new clients not beeing notified about existing attachements too
19:40 sfan5 hm.. maybe there is
19:41 sfan5 anyway, someone should fix it
19:44 celeron55 this would need some kind of a weak pointer
19:44 celeron55 which requires the original pointers to be shared pointers
19:44 grrk-bzzt joined #minetest-dev
19:45 celeron55 or alternatively there should be no direct pointer to the parent object but instead just the id, which is always re-fetched
19:45 sfan5 I don't think code exec would be possible as the segfault occurrs directly after the packet was received and you're not able to put any code there before the crash occurrs
19:45 sfan5 and there is NX, and ASLR
19:45 sfan5 ...
19:45 celeron55 manually syncing this is pretty much impossible for a human being to implement
19:45 sapier not sure if fetching that one is a good idea
19:45 sapier for what I remember it's used in main draw loop
19:46 sapier hmm funny we already have that code
19:46 celeron55 well... it's bearable, but for the same effort a better solution can be made
19:46 sapier ClientActiveObject* GenericCAO::getParent()
19:47 celeron55 anyway, this is the only bug that can be reasonably fixed for 0.4.10
19:48 celeron55 the rest will have to be handled later
19:49 sapier bug is CAO being already deleted isn't it?
19:49 celeron55 no
19:49 sapier then I'm looking wrong direction :-/
19:50 celeron55 the bug is this: the server tells the client (as controlled by a mod) that the client's player is attached to an object, and then deletes the object, which is synced to the client and the client then deletes the object from its memory
19:50 celeron55 this leaves a dangling pointer to the local player
19:50 celeron55 which is then accessed in the next frame in a camera update, and possibly would be in other places too
19:51 sapier ahh
19:52 celeron55 are you taking the challenge? 8)
19:52 sapier I'll try it ... but only for an hour
19:54 sapier local player pointer isn't saved
19:54 sapier it's always read from player list
19:55 celeron55 it's "ClientActiveObject *parent;" in localplayer.h:43
19:55 sapier that's a cao not a player ;-)
19:55 celeron55 the trivial fix is that every time ClientEnvironment::removeActiveObject is called (in client.cpp:1280), the local player should be checked for whether it has that parent set, and whether the parent is the thing being removed, and if so, the removal to be synced there
19:56 celeron55 well that is in the player class, pointing to a cao
19:56 vifino joined #minetest-dev
19:56 celeron55 replacing the pointer with an object id could be a solid fix for now, leaving optimization for later?
19:57 celeron55 i guess even hmmmm values no segfaults more than performance
19:57 sapier https://gist.github.com/sa​pier/2e98e2dca334c1f2a5ec this should cause it to do a clean assert :-)
19:58 sapier added in void GenericCAO::removeFromScene(bool permanent)
19:58 celeron55 is setCAO(NULL) called in that case?
19:58 celeron55 umm wait
19:58 sapier if the cao is unloaded it should be called
19:59 sapier that doesn't stop mt from crashing ... but it will crash in a more "clean" way
19:59 celeron55 that won't do anythin
19:59 celeron55 +g
19:59 celeron55 the player's CAO isn't being removed
20:00 celeron55 an object to which the player's CAO is attached is being removed
20:00 celeron55 s/object/CAO/
20:00 sapier ok so the pointer in localplayer should be still valid
20:00 celeron55 no, the localplayer pointer isn't pointing to the player CAO but the attachment parent CAO
20:00 celeron55 the cao pointer is m_cao there at the bottom of the file
20:00 sapier ahhh wrong cao
20:01 celeron55 goddamnit
20:01 sapier argh
20:01 celeron55 now fix it and don't make me explain it more 8D
20:02 celeron55 these could use a bit more comments in the code
20:02 sapier https://gist.github.com/sa​pier/2e98e2dca334c1f2a5ec
20:02 celeron55 also player->isAttached = false
20:03 sapier do we have someone to test?
20:03 celeron55 (why the hell that even exists, the pointer being not NULL already means it...)
20:03 * sfan5 can test
20:03 sapier as I said attachement code is completely messed up
20:04 sapier add the upper gist to void GenericCAO::removeFromScene(bool permanent) content_cao.cpp L737
20:04 sapier preferably withing the if (( m_env != 0 block ;-)
20:04 sfan5 shouldn't that code only get called if permanent == true
20:05 sapier yes if ((m_env != 0 block ;-)
20:05 celeron55 so L741
20:08 sfan5 works
20:08 celeron55 now everyone hope that this doesn't cause some crazy regression
20:09 sapier I'll push it
20:13 us`0gb joined #minetest-dev
20:14 hmmmm I do value no segfaults more
20:14 celeron55 are we then good to go for 0.4.10?
20:14 hmmmm it needs to work and be safe
20:14 hmmmm yeah pretty much
20:14 * sfan5 says yes
20:15 celeron55 has there been any feedback from the rc1 builds?
20:15 sfan5 not much
20:15 sfan5 we should wait a few days
20:15 celeron55 well, we probably don't have to wait
20:15 sfan5 what about https://github.com/minetest/minetest/issues/1397 ?
20:16 celeron55 many people have been playing the dev builds during this week, that's enough
20:16 sapier it's an sqlite error sfan5 most likely it doesn't even happen on pc and for android we're switching to leveldb
20:17 celeron55 well the original reporter of that bug probably isn't on android
20:17 sapier https://github.com/minetest/minetest/issues/1425 so only this one is left not a crash but a dos by broken mod
20:18 celeron55 that isn't important
20:18 sapier I should read titles more carefully ... I'm gonna unflag 1425  from blocker
20:19 celeron55 yes, do that
20:19 sapier and delete the milestone
20:20 sapier so only "random segfaults" is left
20:20 celeron55 you mean close?
20:20 sapier no
20:20 celeron55 milestones shouldn't be deleted
20:20 sapier I removed the milestone from that issue
20:20 celeron55 oh that, whatever then
20:20 sapier shall I do same for segfaults?
20:21 sapier once I do this 0.4.10 autocloses
20:21 celeron55 it's quite obscure, we can't fix it in time
20:21 celeron55 i don't think anyone has the energy for that
20:21 sapier ok so I'll remove milestone and make it a ordinary bug
20:22 sapier no autoclosing milestone? ... I'm disapointed
20:22 celeron55 autoclosing would be annoying
20:23 sapier ok so what to do for release ... version number, android version code ... what else?
20:23 sapier guess I'm starting with version code
20:23 celeron55 http://dev.minetest.net/Releasing_Minetest
20:23 celeron55 this should be somewhat up-to-date
20:23 celeron55 if it isn't, it should be updated in the process
20:24 sfan5 are we going to wait till 13th or release earlier?
20:25 celeron55 no, we'll release now
20:25 sfan5 >22:25
20:25 sfan5 >tired
20:25 sfan5 who updates the changelog?
20:25 sfan5 not me
20:25 celeron55 hmm, well we can't release if everyone isn't available
20:26 celeron55 BlockMen?
20:26 BlockMen hm?
20:27 celeron55 are you available for making builds during the next hour
20:27 BlockMen sure
20:28 sapier I'm changing the version numbers
20:29 celeron55 go ahead then
20:31 PilzAdam don't forget lua_api.txt and menu_api.txt
20:31 sapier menu api?
20:32 PilzAdam doc/menu_lua_api.txt
20:32 celeron55 those are well listed on the wiki page
20:32 celeron55 just read it and work like a robot
20:32 sapier menu api is already at 0.4.10 :-)
20:32 celeron55 (i
20:32 celeron55 (i'm updating it a bit)
20:34 sapier I'm doing a testbuild and push once completed
20:35 sfan5 ShadowNinja: are you around to update the changelog?
20:37 PilzAdam is the changelog for 0.4.9 even up to date?
20:37 sfan5 no
20:38 BlockMen should _next changelog be added aswell?
20:38 sfan5 yes
20:38 sfan5 BlockMen: can you do that?
20:38 sfan5 I'll try to do the rest
20:38 PilzAdam make a visible difference between game and engine changelog
20:39 BlockMen ^ how?
20:39 BlockMen until now it was always mixed
20:39 celeron55 put minetest_game stuff under "Game Content Changes"
20:39 celeron55 "Game Content Changes (minetest_game)"
20:39 celeron55 that way it's understandable to everyone
20:40 BlockMen k
20:41 sapier shouldn't there be Minetest 0.4.10 written in upper left corner?
20:42 PilzAdam yes
20:42 sapier after changing cmakelists.txt I still have date git there
20:42 PilzAdam "Comment out the line that sets VERSION_PATCH to ${VERSION_PATCH}-dev. " did you do that?
20:43 sapier yes
20:43 celeron55 you have to add the git tag i guess
20:43 sapier ahh
20:43 celeron55 it's mentioned later on the wiki page, if this works i'll update wiki
20:44 ShadowNinja sfan5: Yes.
20:45 ShadowNinja I see the release date was moved back...
20:46 sapier yes after finding out what's been really wrong with mapgen we found a workaround too
20:46 celeron55 waiting a week more would just kill everyone
20:48 sapier oops guess I just pushed more tags then I wanted to push ... deleting them again
20:49 ShadowNinja BlockMen: Are you working on the changelog now or should I start on it?
20:49 BlockMen ShadowNinja, give me 4 min, then im done with game changes
20:50 sfan5 ..damn ubuntu
20:50 ShadowNinja Alright, I'll finish up these datastorage and UI changes...
20:50 EvergreenTree joined #minetest-dev
20:51 sfan5 ShadowNinja: are you going to do the rest of the changelog?
20:52 ShadowNinja sfan5: Yes, once BM finishes.
20:52 sfan5 ok, thanks
20:52 sapier https://github.com/minetest/​minetest/releases/tag/0.4.10
20:53 sfan5 sapier: you could've changed the tag for the untagged one, I'll do that
20:54 sapier no idea what you're talking about :-)
20:54 sfan5 oops
20:54 sfan5 looks like I released it already
20:54 BlockMen ShadowNinja, done
20:54 sfan5 note to self: don't press enter
20:55 * sfan5 made it into a draft again
20:55 sfan5 hmmm
20:56 sfan5 sapier: the tag will get created when https://github.com/minetest/minetest/rel​eases/tag/untagged-17a201e222ba300265b9 is published
20:56 celeron55 so, now according to the wiki page we're waiting for windows packages
20:56 PilzAdam who's gonna tag _game?
20:56 * sfan5 starts building
20:57 sapier nice feature
20:57 sapier sfan5 you can't build without tag
20:57 sfan5 I can
20:57 sapier a local one?
20:57 sfan5 yes
20:57 sapier ok ok :-)
20:57 PilzAdam celeron55, now "tag" is 2 times on the wiki page
20:58 celeron55 PilzAdam: i know, it needs to be
20:58 celeron55 the tag shouldn't be pushed to github initially but only after the builds are checked to be working
20:59 celeron55 but it needs to be created before so that the cmake version scripts can be checked
20:59 sfan5 -- *** Will build version 0.4.10 ***
20:59 PilzAdam does the win build run on windows xp? if yes then we can say we have better support for win than microsoft
20:59 sfan5 this is right, isn't it?
20:59 sfan5 we don't need a tag
20:59 sfan5 it seems to be enough to set VERSION_EXTRA to ''
21:00 sfan5 PilzAdam: mine should run on XP
21:00 BlockMen yes, it runs under xp
21:02 PilzAdam be sure to add that to the forum post
21:02 sapier minetest_next is already merged to minetest_game?
21:02 PilzAdam yes
21:04 OldCoder sfan5 and others: Meowtest (sfan5 0.4.10) server is built. If people will explain setup of minetest_next and/or other changes, I will provide a testbed as requested by sfan5.
21:05 sapier LOL ... I'm gonna kill those irrlicht guys
21:05 celeron55 this sounds good
21:06 BlockMen done with build can i upload it to github or is it better just one person does?
21:06 PilzAdam where is the "Pray that nothing breaks" instruction in the wiki page?
21:06 BlockMen oh, wait. damn version string was not updated
21:06 celeron55 we don't believe in god, we belive in hard work and clueless users!
21:06 BlockMen *grmbl*
21:07 PilzAdam celeron55, for releases we need all help we can get! ;-)
21:07 celeron55 it's implied between each step
21:07 celeron55 writing it there would scare everyone away
21:08 PilzAdam the quote at the top does that already
21:08 sapier anyone continuing after reading "<celeron55> horrible, horrible work" is tough
21:09 sfan5 BlockMen: upload to github named 'minetest-0.4.10-msvc-win(32|64).zip'
21:09 BlockMen why not just minetest-0.4.10?
21:09 BlockMen like minetest 0.4.9
21:10 celeron55 i removed the quote a moment ago
21:10 sfan5 BlockMen: just add the msvc thing, allows distinguishing them easier
21:11 celeron55 now i added a new text at the top
21:11 PilzAdam celeron55, so you want to trick us into releasing more often
21:11 BlockMen msvc says the most user nothing
21:11 celeron55 PilzAdam: yes
21:12 sapier guess I'm gonna archive that android source tree to be able to rebuild it case one of our library dependencys break
21:12 BlockMen dont confuse win users more than neccessary ;)
21:12 celeron55 PilzAdam: my plan isn't working very well
21:12 cheapie joined #minetest-dev
21:13 celeron55 BlockMen: i think it should be included, the windows user will just click it anyway
21:14 sapier "run and check if the thing seems to be working" I'm going to have a problem to do tis on android mips and x86 version ;-)
21:17 BlockMen i still think its more confusing user, but hey, then with msvc
21:17 * BlockMen uploading right now
21:18 sfan5 now for uploading...
21:19 alexxss joined #minetest-dev
21:21 BlockMen ok, msvc builds uploaded
21:21 * sfan5 still uploading
21:21 sapier who did the leveldb changes?
21:21 sfan5 leveldb?
21:21 sapier V/Minetest(10424): 23:21:25: ERROR[ServerThread]: ERROR: An unhandled exception occurred: LevelDB error: NotFound:
21:22 sfan5 that is just leveldb providing your with a sane error
21:22 sapier well it did work before ;)
21:23 cheapie Speaking of databases, is it normal for a --migrate redis to take a ~3GB LevelDB world and turn it into something like 10GB?
21:23 sfan5 sapier: the only place where I added error handling is saveBlock
21:23 sfan5 cheapie: leveldb may use compression, so yes
21:24 cheapie OK.
21:24 BlockMen celeron55, saw you already did some change on mainpage. guess you want do it when done again?
21:24 * cheapie wanders back off
21:25 celeron55 BlockMen: feel free to do it
21:25 celeron55 i just added the 0.4.10 teaser :P
21:25 BlockMen k
21:26 celeron55 (and played around with an unrelated joke thing)
21:27 sfan5 random thing: minetest.net could use a new header image that isn't jpg
21:27 PilzAdam random thing: minetest.net should load way faster
21:28 sfan5 random suggestion: nginx
21:28 PilzAdam who tests the win builds currently?
21:28 * sfan5 won't get up to find a Windows laptop
21:29 PilzAdam Ill ask in #minetest
21:29 celeron55 i'm probably going to redo and rehost minetest.net at some point
21:30 OldCoder Meowtest 0.4.10 "SEGFAULTY!" is now open for business at sfan5 request. Server minetest.org Port 30018 and direct questions to sfan5. Have fun.
21:30 BlockMen i will add "androi"d section before "other" on /download
21:30 sfan5 nice adjective
21:30 sfan5 and you should probably post this to #minetest
21:30 OldCoder kk
21:31 * OldCoder obeys
21:31 sapier at least android version is broken
21:32 sapier can someone check if leveldb is broken on pc too?
21:32 PilzAdam is it just me or do other people wince too when they get pinged during a release?
21:34 us`0gb joined #minetest-dev
21:35 celeron55 i tested the win32-msvc build on wine on 64bit fedora (nothing seems broken)
21:35 sapier changes in loadBlock seem to cause it
21:36 PilzAdam sfan5, shouldnt it be "win32-mingw" instead of "mingw-win32"?
21:36 sfan5 PilzAdam: I'm not reuploading them
21:36 ShadowNinja Changelog updated
21:36 celeron55 i realized a thing though: the default font size is still overly small
21:36 celeron55 it could be set a few pixels larger without breaking any of the UI at all (and i personally have it set so)
21:37 PilzAdam shit, what about translations?
21:37 * OldCoder is prepared to offer his own 32 bit and 64 bit Windows buildings using the MaxGW framework
21:37 sfan5 PilzAdam: I'll rename them after I've finished uploading
21:37 OldCoder builds, not buildings; damn typos
21:43 sapier hmm oldcoder always want to have the full set ... minimal isn't enough for him ;-)
21:44 sfan5 wtf github
21:44 sfan5 why does it keep releasing 0.4.10
21:44 celeron55 i'm going to sleep now, i guess you can handle the release
21:44 PilzAdam sfan5, there is this big green button "RELEASE!", and the little gray button "Save draft"
21:45 sfan5 PilzAdam: it releases if I press enter
21:45 sfan5 UI wasn't designed after principle of least surprise
21:45 PilzAdam celeron55, no! I dont want to do launchpad
21:45 celeron55 PilzAdam: i'll do it in the morning then
21:46 celeron55 i will enjoy my breakfast with a bunch of launchpad rage
21:47 celeron55 or, umm...
21:47 celeron55 well i'll try to do it now
21:48 celeron55 if something doesn't work, i'll just sleep
21:49 PilzAdam sapier, so, whats up with android?
21:49 sapier :-/ no mips build for leveldb ... that's been the reason why I switched back to sqlite ... most devices are arm
21:49 sapier https://gist.github.com/sa​pier/3e91c0ce6c23e8e134b6 this patch fixes it ... for what I understand that error should be on pc too
21:49 sapier so no leveldb for 0.4.10 official release
21:50 sfan5 then it's broken, who cares
21:51 sfan5 wasn't 0.4.11 supposed to be a bugfix release anyway?
21:52 sapier sfan5 you shouldn't shout that loud I might remember my threat with head and things like that ;-P
21:52 sfan5 I'm not shouting
21:52 PilzAdam we almost had a release without problems...
21:52 sfan5 not a single letter was caps
21:52 celeron55 can minetest_game be tagged with 0.4.10 now?
21:53 sfan5 yes
21:53 sapier that's been a german saying ;-)
21:53 celeron55 it wouldn't be a release if it didn't have problems
21:53 celeron55 i base this on the fact that i have never seen a release with no problems
21:53 PilzAdam let us dream
21:54 sapier if it's only android I'll just build those packages slightly next to 0.4.10 ... if it's pc too ... well I don't use leveldb
21:54 PilzAdam BlockMen, care to test leveldb on windows?
21:54 sfan5 technically 0.4.10 is not released yet
21:55 sfan5 if you insist I'll build my packages again
21:55 BlockMen already doing....
21:55 PilzAdam sfan5, by looking at the github timeline you released it already 2 times ;-)
21:55 sapier and android mips is dropped for 0.4.10
21:55 sapier I can live with that
21:55 celeron55 launchpad is now building
21:55 celeron55 hopefully most of them succeed
21:56 PilzAdam celeron55, I can test them in 24 hours
21:56 sfan5 I guess this means leveldb stays broken in 0.4.10
21:57 PilzAdam sfan5, lets wait for BlockMen's test results first
21:57 sfan5 PilzAdam: i can guarantee you that it will not work on windows either
21:58 sapier I guess it's gonna work as long as you don't leave generated area :-)
22:00 BlockMen i dont get it. two times clean build with level db, both time "unkown map format"
22:00 BlockMen like its not included
22:01 BlockMen i can build it a third time
22:01 BlockMen or it stays as is
22:01 PilzAdam sfan5, is it broken on linux too?
22:01 sfan5 PilzAdam: lemme test
22:01 PilzAdam in that we case we shouldn't release with broken leveldb
22:02 sfan5 00:01:47: ERROR[main]: cannot open /home/stefan/minetest/bin/../games/​minetest_game/mods/legacy/init.lua: Datei oder Verzeichnis nicht gefunden
22:02 sfan5 wtf
22:02 BlockMen legacy is doch weg?!
22:02 PilzAdam wtf
22:02 BlockMen *oh, sry. i ment legacy is removed
22:03 PilzAdam thats not good
22:03 sfan5 BlockMen: nope, was just a bug on my side
22:04 sfan5 PilzAdam: leveldb broken on linux too
22:04 BlockMen ofc it is https://github.com/minetest/m​inetest_game/tree/master/mods
22:05 PilzAdam we cant release like that
22:05 sapier shall I push the fix?
22:05 sfan5 sapier: yes
22:08 PilzAdam should I cancel the launchpad builds?
22:09 sfan5 ffs, I need to re-compile
22:09 BlockMen ^ without leveldb
22:10 PilzAdam I need to sleep too
22:16 OldCoder sapier, I don't use Windows. This is for others. Oh, you mean MaxGW? This is an experiment of mine.
22:19 sfan5 sapier: whe n
22:19 sfan5 sapier: are the android builds ready?
22:21 sapier I'm trying to upload right now
22:22 BlockMen i need at least 5 min.
22:22 ShadowNinja G+ release post is ready.
22:24 sapier argh ... need to build again
22:25 sapier deleting "minimal" causes git to believe it's dirty
22:26 sfan5 BlockMen: the pkgs that are at GH currently are the wrong ones, right?
22:26 BlockMen wait a sec
22:27 BlockMen screw it, leave this builds
22:27 BlockMen leveldb doesnt want complile right now, idk why
22:29 sapier nope .. build system issue ... I'll hardcode the number for this release and fix it later
22:31 sfan5 sapier: .apk.zip
22:31 sfan5 wtf
22:31 sfan5 an .apk is essentially a .zip
22:31 sapier githu doesn't allow apk files
22:31 sfan5 ok, then
22:31 sapier I think this is stupid too
22:32 sapier maybe we should mention it in release notes
22:32 sfan5 maybe
22:32 BlockMen that makes no sense at all, leveldb enabled in cmake, lib is also linked correct, it builds but it always say "unknown map backend"
22:41 sapier ok uploading android packages now
22:41 sfan5 I thought they already were uploaded
22:42 sapier no had to rename them
22:42 sfan5 you can rename them without re-uploading
22:42 sfan5 https://github.com/minetest/minetest/rel​eases/edit/untagged-0ebfb8cc5c9296415c8e
22:42 sapier but not the file within the zip
22:43 sfan5 oh..
22:43 sapier and uploading multiple files is broken too argh
22:44 sapier at least on drag and drop
22:49 BlockMen i got it :D
22:49 BlockMen it works
22:49 BlockMen ok, in ~5 min i can update my builds
22:49 sfan5 finally
22:49 sfan5 I'll release it now
22:50 sapier ok uploaded
22:50 sfan5 I'll also do the news post
22:52 sfan5 https://forum.minetest.net/v​iewtopic.php?f=18&amp;t=9688
22:52 sapier can we mention the android forum thread in changelog?
22:53 BlockMen ey, what?
22:53 BlockMen i said 5 min
22:53 sfan5 which thread?
22:53 sfan5 BlockMen: idc, I want to sleep
22:54 sapier https://forum.minetest.net/v​iewtopic.php?f=3&amp;t=9389
22:54 sfan5 BlockMen: you can update them, just make sure to use the same file name
22:55 sfan5 sapier: added link
22:55 BlockMen its buggy
22:56 BlockMen its say "dont support that file type"
22:56 sfan5 then just don't update them
22:56 * sfan5 finally goes to sleep
22:56 BlockMen fuck you
22:56 sfan5 not my fault
22:57 BlockMen 5 min more or less
22:58 BlockMen so yes, its yours
23:04 GhostDoge joined #minetest-dev
23:04 ShadowNinja minetest.net/download needs to be updated.
23:05 ShadowNinja I'll do it.
23:06 ShadowNinja BlockMen: What's the difference between msvc and msvc2 packages?
23:07 BlockMen none, it was temporary
23:08 BlockMen and i was right now finiesh with mainpage update
23:08 BlockMen how can you even lock it when im editing?
23:09 BlockMen ShadowNinja^
23:09 BlockMen can i just save it now?
23:09 sapier if he did change it that might be dangerous
23:09 ShadowNinja BlockMen: Did you add the 64-bit builds?  And remove the temporary one.
23:10 BlockMen yes
23:10 BlockMen and they are
23:11 BlockMen its still locked
23:12 BlockMen ShadowNinja^
23:12 ShadowNinja BlockMen: Released.
23:12 ShadowNinja (As in un-loaked ;-) )
23:12 ShadowNinja un-locked*
23:14 BlockMen done
23:14 BlockMen better titel for the android releases?
23:14 ShadowNinja BlockMen: More than one link is bolded.
23:14 ShadowNinja Also, add Android links somewhere with a note that they're still very buggy.
23:15 ShadowNinja Er, you did, but without the note.
23:15 BlockMen so just 32 bit bold?
23:15 sapier buggy ... yes very ... I don't think so
23:15 ShadowNinja BlockMen: Yes, since it works with both.
23:16 ShadowNinja sapier: ?
23:16 BlockMen arm bold?
23:16 BlockMen yes/no?
23:16 ShadowNinja sapier: Do you aggree that they're buggy or not?
23:16 sapier if I'd consider android to be very buggy I'd not have released it ... and buggy .. well depends on pov ... it's for sure not polished
23:17 ShadowNinja BlockMen: Yes.  Also remove the ':' and the full link to the x86 one.
23:17 sapier but by now the only severe issue left is highdpi screens
23:17 sapier and that one most likely would be fixed if not someone would've removed the sqlite error message ;-)
23:18 ShadowNinja sapier: Lots of things don't scale, inventory images are messed up, and there's still some chat-flooding debug statements.
23:18 sapier where are inventory images messed up?
23:18 sapier and what debug messages?
23:18 ShadowNinja sapier: On aforementioned N7.  Engine-generated cube ones are upside-down.
23:19 BlockMen ok, then i add "very buggy" to android caption
23:19 sapier why don't you tell those things? I basicaly have to fix this for each device as they behave different
23:20 ShadowNinja Also, pressing PWR+VolDn for screenchot sometimes prints something like "unrecignozed key code 00000000".  Possibly one of those keys gets pressed first and MT gets that event.
23:20 sapier I can only fix things I know and especially for android it's very likely to not happen for me
23:21 ShadowNinja sapier: And it printed some debug info when using formspecs.  "fields = {...}" or some such.
23:21 BlockMen ok, mainpage is updated now (old releases aswell)
23:22 ShadowNinja (In chat)
23:22 sapier if you mentioned those things about 4h ago they most likely would be fixed now ... and they haven't been added the last days
23:22 ShadowNinja G+ post published.
23:23 ShadowNinja sapier: And I noticed a mapgen bug, one minute...
23:27 Jordach hold it!
23:27 ShadowNinja sapier: http://imgur.com/eDLbCcd,y1hO4QL,yS1QFUL  #1=chat messages #2=World corruption (same map as before, but world reloaded) #3=Loading bar scaling.
23:28 sapier that's minimal game not android version
23:28 Jordach http://paste.debian.net/108454/
23:28 sapier the fields
23:28 Jordach ^ bug
23:28 ShadowNinja sapier: Ah, but the 00000000 thing?
23:29 sapier that's a bug
23:29 ShadowNinja Jordach: Mod error?
23:31 Jordach ShadowNinja, register_item_raw(itemdef) from builtin/game/register.lua seems to be the cause
23:33 Jordach or i put quotes around a group
23:33 sapier still anyone finding android bugs please report it's not very likely they happen for someone else having a different device
23:34 cg72 joined #minetest-dev
23:34 sapier ShadowNinja: that screenshot isn't n7 is it?
23:34 sapier because there the inventory images are fine
23:36 sapier left #minetest-dev
23:39 ShadowNinja saIt's N10.
23:39 ShadowNinja :-|
23:44 kaeza joined #minetest-dev
23:50 stormchaser3000 joined #minetest-dev
23:51 VanessaE *sigh&
23:51 VanessaE *sigh*
23:51 VanessaE yet another rushed release, I see
23:52 VanessaE not that it's more buggy than usual but from reading the backlog, G*d damn you guys got yourselves all in a tizzy about it.
23:54 VanessaE and why the fuck was #1425 taken off the milestone?  that is a bad bug regardless of what brought it on.  Any time the engine auto-deletes excess entities, it risks deleting and disconnecting in those blocks.
23:54 VanessaE what the fuck are you guys thinking?
23:55 stormchaser3000_ joined #minetest-dev
23:55 ShadowNinja I'll remove minor changes such as code style changes from the changelog if nobody objects.  I'll add a link to the commit log with a note about changes that aren't mentioned.
23:58 Taoki Yay, 4.10 was released today after all :)

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