Time Nick Message 02:10 ShadowNinja I'll merge #1671, #1534, and #1353 in a day or so if there aren't any concerns raised. They're just roting now and at least they'll get some exposure so any bugs can be found. 02:10 ShadowBot https://github.com/minetest/minetest/issues/1671 -- Update credits menu by ShadowNinja 02:10 ShadowBot https://github.com/minetest/minetest/issues/1534 -- Tweak core.serialize by ShadowNinja 02:10 ShadowBot https://github.com/minetest/minetest/issues/1353 -- Add strict module by ShadowNinja 02:10 shadowzone Yikes 02:10 ShadowNinja Those are fairly trivial, but I'd like to get my other, bigger, PRs merged soon. 02:47 Zeno` ShadowNinja, have you also looked again at #1826 ? 02:47 ShadowBot https://github.com/minetest/minetest/issues/1826 -- Fix for various Android build errors. Enable landscape rotation. by KodexKy 02:52 Zeno` No Zeno in 1671. /me cries 03:09 Zeno` Actually should #1826 have some kind of tag to indicate that it needs to be applied before 0.4.11 is released? 03:09 ShadowBot https://github.com/minetest/minetest/issues/1826 -- Fix for various Android build errors. Enable landscape rotation. by KodexKy 03:10 Zeno` s/tag/label 05:24 Zeno` I anyone able to review #1826 05:24 ShadowBot https://github.com/minetest/minetest/issues/1826 -- Fix for various Android build errors. Enable landscape rotation. by KodexKy 05:25 Zeno` It looks ok to me but I don't have an Android toolchain (or an Android for that matter) 06:29 Zeno` Does anyone know about Travis builds? I.e. is #1850 correct and ok to merge? 06:29 ShadowBot https://github.com/minetest/minetest/issues/1850 -- Add gettext to Travis build by ShadowNinja 06:30 Zeno` It looks fine but I don't want to be the one to break poor Travis :) 06:30 sfan5 can't you see the ' All is well — The Travis CI build passed · Details' 06:31 Zeno` well yes, but do those changes incorporate those changes? I guess they must 06:31 sfan5 https://travis-ci.org/minetest/minetest/jobs/41409953#L107 06:31 sfan5 travis already picked up the new stuff 06:32 Zeno` ok so it seems like a good idea then 06:32 * Zeno` reads the output 06:32 Zeno` Travis is quite clever 07:40 hmmmm hey guys, aside from organization, are there any benefits at all to adding an include directive to minetest configuration files? 07:42 Zeno` aside from organisation, probably not 07:47 hmmmm and organization is a very flakey argument to begin with 07:47 hmmmm you're never going to have enough settings to actually warrant multiple files 07:48 hmmmm alright, I'm glad I thought about the 'why' before I started the 'do' 07:48 Zeno` I can't remember why this came up? 07:49 hmmmm me neither 07:49 Zeno` Oh, ... hierarchy I think 07:49 hmmmm you certainly don't need multiple files in order to have a settingsheirarchy 07:49 Zeno` for mapgen params 07:49 hmmmm if mapgen params really take up that much space, i can make a separate file for mapgen params 07:49 Zeno` yeah I think there was ... meh, who cares what it was heh 07:50 hmmmm yeah 07:50 hmmmm I was thinking it over a bit more and the functionality of having multiple config files for a single Settings is actually difficult to add 07:51 hmmmm not necessarily difficult, it's just that adding it would detract from the simplictic beauty of the Settings implementation 07:51 hmmmm it's not the reading, it's the writing part that frustrates matters :) 07:53 Zeno` yeah I remember you saying that 08:09 Zeno` https://github.com/minetest/minetest/pull/1851/files#diff-18513665750ef5adf42b5ec29e14162eL2828 <-- that ifndef was there before I refactored the_game(). Can anyone familiar with android builds confirm whether it's correct or not? (i.e. see line 2827 and the difference) 08:56 kahrl Zeno`: seems right to me 08:56 kahrl see the note at the bottom of http://supertuxkart.sourceforge.net/User:Xapantu/Android 08:57 Zeno` what note? 08:57 Zeno` and what are you commenting on? :) 08:57 kahrl "We can't se a visible cursor" 08:57 Zeno` Maybe I should ask fewer questions hehe 08:57 kahrl set* 08:58 Zeno` I was more referring to the #ifndef __ANDROID__ vs. #ifndef ANDROID 08:58 kahrl is there a difference? 08:58 Zeno` I dunno, that's probably my question :) 08:59 Zeno` It's just that a few lines above the line I linked to it's __ANDROID__ and where I linked to it's ANDROID 08:59 Zeno` If there is no difference they should be the same to avoid people like me asking questions hehe 08:59 kahrl ah, I remember some discussion about those two, but I don't remember any details 09:00 Zeno` I'll leave it for now 09:00 Zeno` better safe than sorry 09:00 kahrl https://github.com/minetest/minetest/pull/1851/files#diff-18513665750ef5adf42b5ec29e14162eR2883 <-- this can be simplified a bit with rangelim 09:01 Zeno` ugh, I even meant to do that. Thanks 09:04 Zeno` err wait, I know why I didn't do it 09:04 Zeno` rangelim() only works with s16 09:05 Zeno` oh 09:05 Zeno` of course there are TWO rangelim()s 09:09 Zeno` ok, changed to use rangelim 09:09 Zeno` can I suggest that the function rangelim be removed and the function-like macro rangelim be renamed RANGELIM? 09:10 Zeno` might have to change too many files though 09:10 Zeno` But.. hmm, I do find it confusing 09:14 kahrl Zeno`: huh, you're right 09:14 kahrl I don't think that's intentional 09:15 kahrl let's just remove the function 09:18 kahrl it isn't even used 09:21 Zeno` :D 09:22 kahrl done :) 09:27 Zeno` full speed ahead 11:45 Zeno` kahrl, any luck with that silly playername business? 12:23 Zeno` sfan5 12:23 sfan5 Zeno` 12:23 Zeno` sorry, I was typing and hit enter :/ 12:24 Zeno` sfan5, so #1850 looks ok? 12:24 ShadowBot https://github.com/minetest/minetest/issues/1850 -- Add gettext to Travis build by ShadowNinja 12:25 Zeno` no matter... I can't merge that anyway 12:25 Zeno` too hard with 2 commits 12:25 sfan5 huh? 12:25 sfan5 I agree to 1850 12:25 Zeno` <-- being lazy 12:26 Zeno` *sigh*, ok I'll merge then because that's 3 core dev votes 12:26 sfan5 what do you mean with 'too hard with 2 commits'? 12:26 Zeno` nothing I'll leave it as 2... I was suddenly trying to be lazy heh 13:24 Zeno` can I have some feedback on #1732 please? 13:24 ShadowBot https://github.com/minetest/minetest/issues/1732 -- Add (optional) client-side saving of server map to disk by sfan5 13:26 Zeno` My personal thoughts are that not allowing people to do it (and as mentioned they can do it with a hacked client anyway) is not a very good argument for not allowing it 13:27 Zeno` I say this as a person who runs a server as well. Nothing (well, not a lot) on my server is created by me. Minetest is open source and I think that stuff like this should be allowed without people jumping through hoops and modifying their client 13:28 gravgun Zeno`: I think it should be implemented, not necessarily used though. Caching map is no problem (as you mentionned, hacked clients). However I didn't look through the patch, does it save the whole map? 13:28 Zeno` gravgun, only what the client has "seen" 13:29 gravgun Zeno`: So it progressively saves the map? 13:30 Zeno` yes 13:31 Zeno` sfan5, save me looking at the source again... it's off by default right? 13:32 sfan5 of course 13:32 Zeno` I honestly don't have a problem with this patch 13:32 gravgun Mmm, same opinion as ShadowNinja about creating a Server object; but on a non-code point of view, it'd be great. Also, why not add another parameters to specify save location (e.g. be able to save on a tmpfs for fast "caching") 13:33 Zeno` I'm not sure caching and saving should be mixed into one pull request though 13:34 Zeno` I mean, it's worthwhile, but if this was to be merged then the caching, IMO, should be something separate 13:36 Zeno` At least, as it currently is, if there are bugs it only affects the saved map (no big deal if there's a bug) 13:36 Zeno` I'll add my thumbs up to the PR, because I like it 13:37 Zeno` :) 13:39 gravgun (I put "caching" in quotes, that was just an exmaple, it's still an actual map save) 13:41 Zeno` yeah, I dunno how useful "caching" would be without thinking some more but at least this also paves the way for that if it's useful 13:42 Zeno` I guess the cache would have to somehow compare its state with the state of the received data so I'm not totally sure it would lead to any improvement 13:43 Zeno` It might though, I dunno 13:45 kahrl not yet re: kahrl, any luck with that silly playername business? 13:47 Zeno` that'd be right (I didn't check too much either though lol) 13:48 Zeno` kahrl, spaces... you're driving me batty 13:50 kahrl I just want to take this opportunity to fix those ;) 13:55 kahrl ok, I think I'm done with the space pedantics 14:06 Zeno` :D 14:06 Zeno` keep going kahrl... as you said they may as well be fixed now 14:07 Zeno` ok, I've tested #1732 saving the map of my server and all seems good to me 14:07 ShadowBot https://github.com/minetest/minetest/issues/1732 -- Add (optional) client-side saving of server map to disk by sfan5 14:08 sfan5 Zeno`: can I merge? 14:08 kahrl idea for determining whether anisotropic filtering makes textures blurred: render a checkerboard 16x16 texture into RTT and examine the histogram of the produced pixels 14:09 Zeno` sfan5, the majority of the comments are positive right? 14:09 Zeno` and we've just discussed it. Unless someone has an objection I can't see why not 14:09 sfan5 Zeno`: as far as I know coredevs need to agree by IRC 14:09 Zeno` IMO these things should be merged sooner rather than later 14:10 Zeno` I agree then 14:10 kahrl (this idea is for #1844 and #1848) 14:10 ShadowBot https://github.com/minetest/minetest/issues/1844 -- odd wield item glitch 2 14:10 ShadowBot https://github.com/minetest/minetest/issues/1848 -- Use anisotropic_filtering config value in wieldmesh. by oleastre 14:10 Zeno` sfan5, merge away :) 14:10 sfan5 kahrl: are the effects of ansitropic filtering gfc card/driver specific? 14:10 kahrl it appears so 14:11 kahrl I guess it's a driver bug 14:12 * kahrl brb 14:13 sfan5 Zeno`: tip: people don't need to squash commits, the person merging them can squash them 14:13 Zeno` kahrl, the problem with wield changes is that I didn't experience ANY ill effects from the start 14:14 Zeno` sfan5, true 14:14 Zeno` kahrl, so I can't comment on them at all :/ 14:15 kahrl Zeno`: same here 14:16 kahrl the cause for the black lines in the image in linked in #1848 is the Y slices in the extrusion mesh 14:16 ShadowBot https://github.com/minetest/minetest/issues/1848 -- Use anisotropic_filtering config value in wieldmesh. by oleastre 14:17 kahrl s/ in / I / 14:17 kahrl which are viewed at a very oblique angle in some parts of the wield animation 14:18 Zeno` I haven't tested that PR 14:18 kahrl best might be to tell the video card: "please render these slices, but only if the angle it's viewed from is less than blahblahblah degrees" 14:19 kahrl I doubt there is such a material flag though... 14:19 Zeno` how to do that though? 14:19 kahrl probably impossible without shader tricks 14:19 kahrl I can remove the Y slices but that's ugly too 14:20 Zeno` yeah I dunno... I'm staying far away from it hehehe 14:21 Zeno` the whole thing scares me because it was right from the start on my computer hehe 14:21 kahrl maybe the wield animation could be modified so the angle is not as oblique 14:36 Megaf Hi everyone 14:37 Megaf We believe that Minetest is coded for Irrlicht 1.7 14:37 Megaf What about changing it and optimizing to at lesat 1.8? Or even the upcoming 1.9 14:46 kaeza Megaf, it works on both 1.7 and 1.8 14:47 kaeza not sure if support for 1,9, assuming anything changes, is a priority 15:07 Megaf kaeza: I know it works 15:07 Megaf it has a bug with 1.7 actually 15:07 Megaf but I mean, doesnt version 1.8 introduced some better feature or solve some limitation that could be useful to Minetest? 15:50 Megaf Irrlicht log: JPEG FATAL ERROR in _tempreadfile: Wrong JPEG library version: library is 80, caller expects 62 15:50 Megaf 15:47:24: ERROR[main]: Client: Cannot create image from data of file "bg_signs_lib.jpg" 17:47 ShadowNinja Comments on #1418? 17:47 ShadowBot https://github.com/minetest/minetest/issues/1418 -- Clean up rollback by ShadowNinja 17:48 hmmmm looks good 17:48 hmmmm but i have a question - why doesn't the rollback manager use the database abstraction layer? 17:49 hmmmm also, if (itemdef) name = itemdef->getAlias(name); eww 17:49 hmmmm the style is 17:49 hmmmm if (itemdef) 17:49 hmmmm itemdef->getAlias(name); 17:50 hmmmm i hate when people put a control statement body on the same line. it's like they have something to hide 17:51 ShadowNinja hmmmm: Database abstraction layer? 17:51 hmmmm database.cpp 17:52 ShadowNinja hmmmm: It's database os nothing like the map DB, so it can't use those classes. 17:52 hmmmm then perhaps the classes should be extended 17:52 ShadowNinja hmmmm: It stores actions, items, actors, etc each in a table. 17:52 ShadowNinja hmmmm: The DB classes are just designed for v3s16 -> BLOB. 17:53 hmmmm i've seen interest in a redis rollback manager anyway 17:54 ShadowNinja hmmmm: You'd need a completely seperate API for it. Not all DB backends do things the same way. SQLite3 is pretty full-featured, but redis ony has k->v, and LevelDB aditionally only supports one table. 17:55 hmmmm so the rollback manager uses different keys? 17:56 celeron55 it's a completely separate system 17:56 ShadowNinja hmmmm: Schema: http://pastebin.ubuntu.com/9100793/ 17:57 celeron55 to which it was upgraded from an initial text-based system 17:57 ShadowNinja Definitely not something that can be sanely emulated by redis or LevelDB. 17:57 celeron55 and yes, it actually uses SQL unlike the map backend 17:58 hmmmm ahh, i see, you search by actor and by position 18:00 ShadowNinja celeron55: Does it seem O.K. to you? 18:02 ShadowNinja BTW, this might improve speed slightly. I made the pos limitations a little easier to optimize. 18:02 ShadowNinja I haven't tested it though. 18:02 celeron55 why is the itemdef parameter made optional? 18:03 celeron55 seems like it can result in quite uncontrollable behavior as nothing defines when it is NULL and when not 18:03 ShadowNinja celeron55: The rollback manager needs to read items without resolving aliases. 18:04 celeron55 when? 18:04 shadowzone hi celeron55 18:05 ShadowNinja celeron55: Line 680 or so. 18:05 ShadowNinja (rollback.cpp) 18:07 celeron55 okay i see; but doesn't this lead to bugs when people will obviously forget it in invocations of the itemstack deserialization in future code elsewhere 18:08 celeron55 as it currently is, they can't forget it as it isn't optional 18:08 celeron55 it at least needs a comment stating when it can be left out and when not 18:08 ShadowNinja The percieved speed of rollback could be improved massively by changing the default limit to 1. That would make it resier to get the wrong player though. 18:09 ShadowNinja celeron55: Well, it's still in the type signature. 18:09 ShadowNinja I can add a comment though. 18:09 celeron55 but nobody is explaining why it is there and why it is optional 18:09 ShadowNinja "Use when you want aliases resolved" r so. 18:10 celeron55 "Do not leave itemdef as NULL unless you are sure you do not want aliases to be resolved." 18:10 celeron55 nobody will know whether they want that or not, so it's better to state what the default is supposed to be 18:11 celeron55 and the ifs look horrible as hmmmm said 18:12 ShadowNinja celeron55: Changed locally. 18:13 celeron55 the rollbackmanager changes are quite obfuscated, i guess nobody can review those 18:13 ShadowNinja RollbackManager is rather big. 18:14 ShadowNinja I guess getItemString should stay in the source file since it requires . 18:16 kaeza comments? https://github.com/kaeza/minetest/commit/fb8bc8913fb7c5f476fbb82086d08f20cc89e43e 18:17 kaeza (part of builtin cleanup, still WIP, just posting here so devs can make suggestions while I work on it) 18:18 Krock kaeza, I don't get what's better in the 1st file 18:18 Krock chatcommands.lua 18:18 celeron55 i don't like the way this moves a lot of implementation details into rollback.h 18:18 celeron55 headers shouldn't contain implementations 18:19 kaeza Krock, avoids creating a table every time the function is called 18:19 celeron55 that header isn't included in a lot of places so it's not that bad but it could end up so, and then compile times will increase and everyone will cry and go away 18:19 Krock kaeza, https://github.com/kaeza/minetest/commit/fb8bc8913fb7c5f476fbb82086d08f20cc89e43e#diff-a93e20fc47b20484bdc9d6f539b9d631R200 vector.floor() should be added instead 18:19 Krock or even vector.round in this case 18:19 Krock IMO 18:20 ShadowNinja kaeza: facedir_to_dir is 1000000x clearer. :-) 18:20 celeron55 it doesn't seem to be a necessary change at all, so why is the change there 18:20 celeron55 (the move to rollback.h) 18:20 kaeza Krock, in this case, it's faster to hold those in locals than create a table/vector every time 18:20 ShadowNinja celeron55: rollback_interface.h implements everything that the restof the project sees. 18:21 ShadowNinja I can move some things back if you prefer though. 18:21 celeron55 ShadowNinja: where are the comments that state this clearly 18:21 kaeza and since nodeupdate could be called potentially hundreds if not thousands of times, it shaves quite a bit of time 18:21 ShadowNinja celeron55: Nowhere, I had to figure this out be asking you and looking around. 18:23 celeron55 ShadowNinja: that is my last complaint, so if those are added, i'm happy with this 18:23 celeron55 it could be done with file names even; just rollback.h -> rollback_internal.h and rollback_interface.h -> rollback.h 18:25 celeron55 (yes, i will always bitch about header bloat; it's one of the most common and worst thing to mess up in C++) 18:27 ShadowNinja BTW, we should probably have a defined header include order. It seems like the best method is local - global - system, because it helps to find missing includes. 18:27 ShadowNinja ^ That issue made me need to touch a bunch of files that depended on settings.h including debug.h, log.h, main.h, ... 18:28 celeron55 yes, i agree with local, global, system because it allows reliably definining macros for system headers that sometimes need them 18:29 celeron55 (it might bring up some problems though as every file uses a random-but-working-order currently) 18:29 hmmmm really? 18:29 hmmmm i've been doing system global local the whole while 18:29 hmmmm :( 18:30 celeron55 well, macros are the only actual reason for ordering them in any order, and those cause the preference of putting system stuff last 18:30 celeron55 i hadn't thought about this some years ago but then stumbled upon this fact 18:32 kaeza I've always used system-global-local as well, but now your comment makes a good point on doing the inverse, I guess. 18:33 ShadowNinja hmmmm: Me too, but I searched for a ordering a while ago, and I didn't find any good reasons for that ordering other than it looks better (which it does IMO, but still). 18:35 ShadowNinja celeron55: Look good now? 18:37 ShadowNinja Hmmm, minor style issue in ItemStackRow... 18:37 celeron55 well, you didn't do anything to my last concern 18:38 ShadowNinja celeron55: What concern? 18:38 celeron55 the concern about the headers 18:39 celeron55 you can ignore it, but i will blame you when someone messes up with them 18:39 ShadowNinja celeron55: I moved the internal stuff into the .cpp. 18:39 ShadowNinja celeron55: And right not rollback.* is internal anyways (glob notation) 18:39 ShadowNinja now* 18:41 celeron55 why is rollback.h still including sqlite3.h? sqlite3's types aren't used in minetest's internal interfaces 18:41 celeron55 i really hate C++'s private class members; they are the worst offenders in header bloat 18:41 celeron55 they make people think you should put everything in a header because private will save you 18:41 ShadowNinja celeron55: The sqlite3 and sqlite3_stmt types. 18:42 ShadowNinja They're members. 18:42 celeron55 whatever, i give up 18:44 celeron55 i will still repeat that i hate it that "private" basically means "yes, nobody can't use this information, but i still want it to be bloating up my header with all its dependencies" 18:45 ShadowNinja celeron55: It's also included in every instance, unlike the global system of before. But header bloct isn't an issue, _interface salves that and is what everything includes. 18:45 ShadowNinja bloat* 18:47 ShadowNinja celeron55: `touch src/rollback.cpp` only causes two files to be rebuilt, rollback.cpp, and server.cpp (it instantiates the manager). 18:48 ShadowNinja touching _interface rebuilds about 25 files though. That seems like a lot. 18:51 ShadowNinja I reduced it to 6. 18:52 ShadowNinja celeron55: So, all good? 18:53 ShadowNinja celeron55: Also, there's another reason for the ordering. One minute... 18:56 ShadowNinja celeron55: http://pastebin.ubuntu.com/9101894/ 19:05 celeron55 that isn't usually very effective in real code though, because many files include a long series of other files, and the first non-system one will include many system headers already 19:05 celeron55 but yes, the chance of that increases 19:06 ShadowNinja Comments on #1826? 19:06 ShadowBot https://github.com/minetest/minetest/issues/1826 -- Fix for various Android build errors. Enable landscape rotation. by KodexKy 19:19 ShadowNinja RealBadAngel: Um, this isn't how your wallmounted rotation is supposed to work... https://mediacru.sh/lHLnnCgyzxoO.png 19:19 shadowzone Lol 19:20 VanessaE eep 19:34 kaeza mod_profiling.lua is a real mess :/ 19:34 kaeza https://github.com/kaeza/minetest/commit/e8f56cecc820348027b5d20229ddc5863d17e24b 19:36 RealBadAngel ShadowNinja, please do read how torchllike works 19:36 RealBadAngel this has nothing to do with wallmounted 19:36 RealBadAngel ZERO 19:36 ShadowNinja RealBadAngel: I'm not using torchlike. 19:36 ShadowNinja I'm using 3D models with wallmounted. 19:37 RealBadAngel so dont expect wallmounted to rotate torches like torchlike does 19:37 VanessaE RealBadAngel: I think he means that the model doesn't stay "right side up". 19:37 VanessaE regardless of what the model may be 19:37 VanessaE if I put a wallmounted calendar there, the same problem would happen ") 19:37 VanessaE :) 19:38 RealBadAngel ShadowNinja, upload that mod code somewhere please, i will look for the probem 19:38 RealBadAngel *problem 19:39 ShadowNinja http://sprunge.us/XQPZ 19:39 RealBadAngel http://i.imgur.com/hjtT1Xj.png 19:39 RealBadAngel this is how wallmounted works for me 19:40 shadowzone o.O 19:41 ShadowNinja RealBadAngel: Well, not for me. 19:42 kilbith the issue may come from the torch model itself maybe ? 19:42 VanessaE it is notable that RBA's image depicts the same model on the "upright" surface as on the sides of the block 19:43 VanessaE but ShadowNinja's image has a different model for those two situations. 19:45 RealBadAngel VanessaE, yes, thats the point of the wallmounted 19:45 ShadowNinja VanessaE: Yes, but the side one seems rotated randomly, it's not just off by a constant ammount. 19:46 RealBadAngel torchlike (current one) is something different, it draws one on the ground, another on the ceiling and 4 different at the walls 19:46 VanessaE RealBadAngel: that's not torchlike. 19:46 ShadowNinja Maybe I'm doing something wrong, but if so I don't know what. 19:46 RealBadAngel ShadowNinja, i will re-check the rotation, but theres noting much to fiddle with 19:46 VanessaE that's just a model that looks like a torch. totally unrelated. 19:47 ShadowNinja ^ 19:47 RealBadAngel wallmounted is just axisdir 19:47 RealBadAngel except for that current wallmounted values are messed up 19:47 RealBadAngel 0 is at ceiling, 1 bottom, etc 19:48 ShadowNinja RealBadAngel: I tried to re-do the table and I think I came up with the same thing as you, but it's just not working. 19:48 RealBadAngel imho we shall just fix the wallmounted 19:48 ShadowNinja RealBadAngel: How are they messed up? They seem more logical than facedir since they're ordered by axis. 19:49 RealBadAngel 0 at the ceilng? 19:49 RealBadAngel so you have to rotate your models (wallmounted ones) to be show correctly in inventory 19:49 RealBadAngel otherwise they will be show upside down 19:50 RealBadAngel 0 always meant no rotation at all, standing on the bottom 19:50 RealBadAngel why the heck wallmounted has to be different? 19:51 RealBadAngel facedit IS ordered by axis 19:52 RealBadAngel top of the node points the axis 19:52 RealBadAngel as your head, it points up 19:54 RealBadAngel wallmounted should be redefined to be just axisdir, so conversion should be just facedir/4 = wallmounted 19:54 RealBadAngel or wallmounted*4 = facedir 19:57 RealBadAngel ShadowNinja, anyway, until its fixed i will try to get your mod working, just a bit later, i need a nap now 19:58 ShadowNinja RealBadAngel: Hmmm, I think I figured out the issue. 20:03 RealBadAngel yes? 20:07 ShadowNinja RealBadAngel: Close: https://mediacru.sh/192737be885b 20:07 ShadowNinja RealBadAngel: Your mushroms don't show that because they don't depend on orientation. 20:08 ShadowNinja You can see it on them, but they don't depend on it. 20:08 VanessaE RealBadAngel: try it with one of the slopes from my mesh test mod. 20:15 kaeza last commit for builtin/game cleanup: https://github.com/kaeza/minetest/commit/1af70b8d0333103f0ba6530f04e11ec0996c83d1 20:17 VanessaE kaeza: "are writing WORDS!" you blew the line! :) 20:17 kaeza :( 20:18 PenguinDad kaeza: is the setmetatable still needed? 20:18 ShadowNinja RealBadAngel: Fixed it: static const u8 wm_to_6d[6] = {20, 0, 16+1, 12+3, 8, 4+2}; 20:18 ShadowNinja (changes added as +%d) 20:19 ShadowNinja RealBadAngel: You'll have to apply that to the mesh cache rotation code too though. 20:19 kaeza PenguinDad, in voxelarea? yes 20:19 ShadowNinja (Or better yet, unify the rotation to one place) 20:21 PenguinDad Then I just don't see why it's needed right now 20:22 ShadowNinja RealBadAngel: I have a commit ready, just check my rotation array and confirm. 20:22 VanessaE you may want to revisit #1808 also then 20:22 ShadowBot https://github.com/minetest/minetest/issues/1808 -- Adjust the values of dirs1 and dirs2 so that rotate_and_place orients textures correctly by dvere 20:24 VanessaE (though it's still my opinion that the guy using that code is just using it wrongly) 20:27 kaeza PenguinDad, it is done so you can do local va = VoxelArea:new() va:foobar(); it's a common trick to implement OOP in Lua 20:49 Sokomine thanks for adding the save-to-localmap function! i'm very glad it's finally included 20:50 Sokomine now the only point where my version of mt still has to differ from the master branch is regarding commit 1b4908b i'd be very glad if a config option could be added to disable that "feature" there. and other players think similar 20:51 Sokomine adding a single line would be sufficient to make it a config option i think 21:17 RealBadAngel ShadowNinja, if that works then ok 21:18 RealBadAngel i think i was checkin that with nodes that didnt needed extra facedir rotations 21:19 RealBadAngel mushrooms were symetrical to some degree, so i havent noticed the problem 21:28 ShadowNinja kaeza: For your cleanup: make nodedef_default / craftdef_default "inherit" from a common ancestor (itemdef_default?) 21:33 ShadowNinja Does #1843 look O.K? I've trimmed out the whitespace changes so it won't confilct with kaeza's cleanup. 21:33 ShadowBot https://github.com/minetest/minetest/issues/1843 -- Add setting to customise stack max by rubenwardy 21:38 VanessaE oh that'll be handy. 21:51 ShadowNinja sfan5: I think can remove that server-created-by-the-client ugliness in my SQLite3 pos split patch, since I removed the ServerMap dependency and ServerMap::saveBlock(MapBlock, Database) can be made static. :-D 22:25 ShadowNinja sfan5: beginSave() starts queueing blocks to be written until endSave() is called. The client doesn't call endSave() until shutdown. That could cause a freeze when shutting down.