Time Nick Message 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 hmmmm b-b-b-ut you're the only one who has an android setup :( 09:22 PilzAdam sfan5, https://github.com/minetest/minetest/issues/1445 09:22 sfan5 not an engine issue 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 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: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/minetest/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 PilzAdam sapier, I guess the intlGUIEditBox was there for a reason: https://github.com/minetest/minetest/commit/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: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 :-( 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: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 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: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/archives/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/viewtopic.php?f=21&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/minetest/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/minetest/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/PilzAdam/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 btw, memory leak fix: https://gist.github.com/PilzAdam/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 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: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 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/wchar-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 sapier for what reason? the array is as big as thestring? 14:26 sfan5 no 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 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 sapier this has been seen on pc too but way les often 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: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 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:48 celeron55 Calinou: it should be possible to segfault anything from mod code; so no 14:48 celeron55 shouldn't* 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: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 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: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/sapier/3db8d19cfac358446294 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: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/sapier/1ead5784c5bb1c339004 here 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/sapier/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 Megaf Curiosity: Time to compile minetest + minetestserver without redis nor leveldb support real 2m24.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 real 2m33.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 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: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: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: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 sapier I don't know about sqlite yet 17:36 sapier I just added debug code there to see it 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 sapier errorcode os 1 18:08 celeron55 sqlite error 1? 18:09 sapier yes 18:09 sapier so most simple SQLITE_ERROR 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: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: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: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: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: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/sapier/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/minetest/issues?milestone=3&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/commit/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: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 #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 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: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 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/sapier/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/sapier/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: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: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/releases/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 " 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: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: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: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/sapier/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/minetest_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/releases/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/viewtopic.php?f=18&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/viewtopic.php?f=3&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 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 sapier ShadowNinja: that screenshot isn't n7 is it? 23:34 sapier because there the inventory images are fine 23:39 ShadowNinja saIt's N10. 23:39 ShadowNinja :-| 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 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 :)