Time Nick Message 00:32 sapier https://github.com/minetest/minetest/pull/1136 should fix the not working non exceptioning functions, as I had to change each of them I renamed them too 00:33 sapier but it may need some testing as I'm not sure if checking for numeric conversion errors wont cause some bugs to show up 02:48 hmmmm wait, what does that actually do? 02:49 hmmmm i was intending on fixing it by not having Setting::get throw an exception, but rather the exceptioned versions on top of the non-except 02:51 hmmmm i can see that you fix the case where 0 is a valid return, except in that situatiton it doesn't realllly matter since 0 is never a valid port 03:06 hmmmm ohhhhh shiiiiitt 03:06 hmmmm my no exception things do work fine, i did not realize that i left them blank like that 03:07 VanessaE [02-04 18:14] * VanessaE waits for the "oh shit...I did THAT?" moment....... 03:07 VanessaE VINDICATED! :D 03:08 hmmmm alright 03:08 hmmmm i can't use the NoEx variants there, i do need to explicitly check against empty 03:08 VanessaE only kidding, hmmmm :) 03:09 hmmmm my original intent was that empty but present means, "let the emergemanager decide what the limit should be" 03:09 hmmmm but non-present means use the defaults 03:09 hmmmm and present means use what is given 03:21 hmmmm sapier, do you have any pieces of code in mind that call emergeBlock() and would benefit from an asynchronous callback when the block actually finishes getting loaded? 03:21 hmmmm i know the stuff you were working on with the duplicate objects is one thing but anything else? 03:40 VanessaE current HEAD seems to work fine now 03:43 VanessaE staging it for the servers, for the morning restart. may as well give it a wider test. 04:01 ShadowNinja hmmmm: It looks like you forgot to close the PR. 04:16 * VanessaE wanders off to bed 04:18 hmmmm ShadowNinja, why don't you do that instead of telling me about it? 04:18 hmmmm it takes a text select, copy, paste, and then click another button 04:22 ShadowNinja hmmmm: Because you pushed it. :-) 04:22 hmmmm so? 04:22 hmmmm there's no unwritten rule for that 04:22 ShadowNinja I'll do that next time if you prefer. 04:24 hmmmm somebody who sees some minor chore like that left undone, it's much more productive to just do it yourself rather than not doing it but expending the energy to verbally tell the person you feel is in charge of that chore to do their chore 04:51 hmmmm I really wonder if adding a new exception that wasn't there before to Settings was a wise thing to do now 04:52 hmmmm this kind of thing is the reason why I aimed to not change the what Settings does in the first place, because it's simply too widely used. well, not only that, now sapier has changed the behavior of a primitive integer conversion function 05:03 hmmmm sapier, problem: any time there's an invalid character encountered in one of the plain Settings::get*-with-numeric-conversions, that's going to cause a NumericException that nobody handles except for what you made it handle this far 05:04 hmmmm although the idea of making errors explicit rather than hidden is a noble one, it's just not working out in practice here 05:05 hmmmm for now at least I say we revert 3f376a0 and i'll just fix up the two problematic settings in EmergeManager ctor 11:39 xyz do we really need EMT_TRANSPARENT_ALPHA_CHANNEL_REF as the MaterialType for TILE_MATERIAL_BASIC? is there anything that makes use of it? 14:14 RealBadAngel hi hmmmm 15:14 VanessaE ok something BAD happened last night after the restart - LOTS of C++ exceptions now 15:15 VanessaE oh, new I see new changes. guess I better pull those 15:17 VanessaE and...deployed. 15:31 Megaf when 0.4.10 is out, I will stick with it, in the stable branch 15:46 VanessaE ShadowNinja: are you going to push those fixes we talked about? 15:53 RealBadAngel 0.4.10?? why not 0.5? 15:55 Kray why it would be 0.5? 15:55 Kray does it introduce breaking changes? 15:56 VanessaE version numbers are not decimal :) 15:59 RealBadAngel shit, this way we will wont leave 0.4.x stage this century :P 16:04 NakedFury I thought shaders alone would push it to 0.5.x numbered version 16:04 NakedFury or at least push it to 4.5.0 16:07 RealBadAngel lol 16:08 VanessaE I thought 0.5.x is supposed to be for some major change that totally breaks compatibility with 0.4.x 16:14 RealBadAngel keeping things compatible breaks more things than keeping them working 16:15 RealBadAngel there are lotsa examples on that 16:16 RealBadAngel major change and a reason to change version big time imho is change of net protocol 16:17 RealBadAngel not some fancy schmancy eye candies 17:17 sapier well I know the NumericException is quite invasive that's why I didn't push it without discussion. Basicaly it's about deciding what to do if you can't convert something. The current behaviour is just hide it and use 0 ... you don't have any way to decide if 0 is the converted value or a error return 17:18 sapier this is not only about settings 17:23 sapier another point to discuss is settings.h ... this file has gotten way to big and contains too much code for a header file, imho we should add a settings.cpp 17:25 sapier https://github.com/minetest/minetest/pull/1135 any complains about this one? 17:26 sapier https://github.com/minetest/minetest/pull/1131 ShadowNinja I'm gonna merge this today I added your last suggestions 17:28 ShadowNinja sapier: Alright, the only thing I noticed was that the 0.0.0.0/:: checks were still there. Other than that it's good. 17:29 ShadowNinja And 1135 seems good too, although I haven't looked at it very closely. 17:30 sapier are there still 0.0.0.0 checks in there? thought I removed them with latest commit 17:30 sapier oh I missed a location 17:33 sapier the only functional change in 1135 is removal of a "external" debug function in client class ... debug function accessible from outside ... if someone really needs this information he/she 's supposed to use a debugger. 17:33 sapier especially as that information is very very very specific for a single debug case 17:35 sapier ok now all 0.0.0.0 locations should be gone 17:35 xyz sapier: apparently marshal causes sigbus on android sometimes when unmarshalling a function 17:36 sapier sigbus? 17:36 sapier First guess is stack overflow 17:36 sapier increase stack size 17:37 sapier not as fix but as check if this is true 17:37 sapier marshaling as any other serialization may do quite some recursion so it's prone to issues like that one 17:38 sapier I wonder if it's be worth a to check this for emptty's debian jit problem too 17:39 xyz it's still not resolved? 17:40 sapier no I still can't reproduce and the error trace wasn't helpfull 17:40 xyz maybe we can work around it? 17:40 xyz like pass function name as a string, not serialized body 17:41 sapier that's how it's done 17:41 sapier the serialized data isn't jitted code 17:42 sapier it's plain text and will be "rejitted" on async thread 17:42 sapier emptty did some tests, in crash situation serialized data is still correct 17:43 sapier as it doesn't happen always it may be a race condition or a random memory corruption too 17:44 sapier but in case of a memory corruption I'd expect to be the reason somewhere around async/marshall too, it's quite unlikely to always cause problems there for something completely different 17:47 sapier btw there are way to many "workarounds" within minetest just because everyone is to lazy to find the source of a problem. Imho we should remove them not add new ones 17:49 sapier does anyone have a system with gcc and clang and knows how to tell cmake to use clang/gcc? 17:53 xyz so it's plain text 17:53 xyz and a race condition 17:54 xyz which happens always 17:55 sapier depends emtty told about 3 of 4 times 17:55 sapier so quite often 17:56 sapier but by now there's no obvious reason ... could be something completely different too 17:56 xyz did you test it with luajit beta7? 17:57 sapier not yet I used beta9 by now but if there was a problem in 7 that got fixed I don't see a reason why to look there 17:57 sapier emtty has 2.0.2 17:58 sapier beta9 is latest available for wheezy 17:59 xyz well have fun debugging it 18:00 sapier well prior debugging I need to be able to reproduce it 18:01 xyz yes just install luajit beta7 then 18:03 sapier there ain't a debian package for beta7 and I won't mess up my disti without a real reason. I remember you told the beta7 bug was already fixed so why should it be back in 2.0.2 18:03 sapier ? 18:06 xyz because we don't know if that's a bug 18:06 xyz why do you assume it is? 18:06 xyz moreover, I've never told you the bug was fixed 18:06 xyz stop imagining things 18:11 RealBadAngel sapier, 1135 looks fine, bout 1131 i dont know the problem so i cant say anythin 18:14 sapier ok xyz sorry I missinterpreted "it works with 2.0.2" as "it was fixed in 2.0.2" 18:16 xyz yes yes you did 18:16 sapier I tend to not believe this is really related to luajit version ... and the message you liked last time tells the error checking is cleaned up ... I interpret "not working function serialization" as not working c-function serialization ... which is quite obvious true ... and not required at all 18:16 sapier linked not liked 18:18 xyz if it's about c functions then why'd he talk about luajit 18:18 sapier because you can use c functions in lua code which obviously won't be serialized 18:19 sapier at least that's what I understood 18:20 sapier http://lua-users.org/wiki/TableSerialization I used marshalling because it is capable of serializing functions 18:26 sapier ok now on luajit beta7 still no crash for me 18:27 xyz strange 18:27 xyz try running marshal tests 18:27 xyz provided in its git repo 18:33 sapier I'm switching back to beta9 to do so as compiling against something out of tree isn't quite user friendly 18:39 sapier works 18:40 sapier there has to be some other reason 18:42 xyz so did you check marshal tests? 18:42 xyz with luajit beta7 18:44 sapier well I can't compile against beta7 I used beta9 18:45 sapier not sure if a marshall lib compiled against beta9 is supposed to work against beta7 library ... but it doesn't work 18:45 sapier https://gist.github.com/sapier/8830371 18:47 xyz it compiled fine for me and it didn't work in the same way 18:48 sapier ok so we're right where we've been befor luajit beta7 is broken and shouldn't be used 18:57 sapier https://gist.github.com/sapier/8830371 UPDATED as you can see it's broken till beta7 and fixed as of beta8 19:57 Megaf_ sapier: Hi, any update on 1132/1134? 19:58 sapier 1134 should be fixed 1132 still isn't decided 20:05 ShadowNinja The protocol bump seems to be the selected option. 20:06 sapier at least it seems to be prefered version by now PilzAdam is for it I'm for it too ... I assume you're same opinion ShadowNinja? 20:06 sapier -versio+variant 20:10 sapier but right now I'm more concerned about the (possible) luajit<->marshalling issues 20:16 ShadowNinja sapier: Yes, the proto bump seems best. 20:22 sapier https://github.com/minetest/minetest/pull/1131 merging in about 15 minutes 20:33 VanessaE ShadowNinja: um...how do I add another user to the core? 20:34 VanessaE oops 20:34 VanessaE wrong channel. 21:33 xyz everybody keeps ignoring me so I'll just spam this again, do we really need EMT_TRANSPARENT_ALPHA_CHANNEL_REF as the MaterialType for TILE_MATERIAL_BASIC? is there anything that makes use of it? 21:35 sapier I assume RealBadAngel is the only one who even knows what this is about ;-) 21:36 sapier is it faster without EMT_TRANSPARENT_ALPHA_CHANNEL_REF ? whatever this is 21:37 xyz it's buggy on android/ogles 21:37 xyz the one without ref works fine but probably is slower and also requires z sorting enabled 21:37 xyz dunno if there's actually any noticeable difference 21:38 sapier we should find out first, if it's just a minor penalty and no visible changes it's not a big thing to disable, but if it isn't I suggest do an architecture specific change only 21:56 khonkhortisan I want to add a source file. What do I edit to compile it in? 21:57 ShadowNinja khonkhortisan: src/CMakeLists.txt 21:57 khonkhortisan thanks 22:24 CiaranG So (lua api), player:get_look_yaw() returns a value that is 90 degrees offset from the one you should pass to player:get_look_yaw() 22:24 CiaranG Is there some kind of reason for that, or is it just a bug? 22:25 CiaranG er, set_look_yaw, I mean, for the second one 22:26 sapier some people seem to assume this is correct behaviour (it's wrong for all entities). but breaking all mods out there isn't an option so we have to live with it 22:26 CiaranG Documenting it might be an idea then, if it's staying like that 22:27 CiaranG Would have saved me an hour of insanity ; 22:28 sapier :-) you're free to document it and write a pull request. please one pull for one feature 22:28 CiaranG Yeah, sorry about that, it did only have one commit in it when I made the pull request 22:29 sapier no problem 22:29 CiaranG The 'remap mouse buttons/view direction keys' thing wasn't supposed to be pull-requested at all yet 22:29 CiaranG It works great, but there's an issue. You can't ever remap the mouse buttons back to the actual mouse buttons, because the gui is capturing them when it's asking you to press the new key to define 22:30 sapier well adding that one with it's upper commit message would have caused quite a lot of confusion ;-) 22:30 CiaranG Probably I can just turn off the capturing during the 'press the new key' but I haven't bothered to try it yet 22:33 ShadowNinja I think the offset can be fixed, looking 90 degrees off might mean you're facing the wrong way for a teleporter or something, but it isn't game-breaking. 22:34 CiaranG It really ought to be fixed, it makes no sense at all. But it could be fixed in a non-breaking way if it really mattered by adding new functions and leaving the old ones deprecated as they are. 22:34 CiaranG get_look_yaw_sane() 22:37 CiaranG On another subject, if I created a pull request that allowed lua entities to set themselves 'active' (which means the blocks they are in stay active, as if they were a player) would that be accepted? 22:37 ShadowNinja Hehe. 22:37 ShadowNinja CiaranG: Nope, already done, called force_load. 22:37 CiaranG Really? 22:37 ShadowNinja And you can use minetest.forceload_block 22:38 CiaranG Huh, so I've done it again for nothing. I guess that will teach me to read the code more. 22:38 ShadowNinja The PR was made, but only the forceload_block method was accepted. 22:38 sapier BUT you're strongly discourage that feature 22:39 CiaranG Oh, ok, so I haven't done it for nothing :) 22:40 sapier there's very little you actually need this feature and don't have another chance to do it. In most situations you're just gonna use it because of beeing lazy ;-) 22:50 CiaranG So I have lots of uses for it (which are not being lazy), but I'll keep it to my own server 22:55 sapier well you should think about each entity causing map block load will increase server load as much as an additional server. Case this entity is moving and running havoc you'll never find it again if its somewhere far far away 22:56 sapier -additional server + additional player 22:56 CiaranG Yep, fully aware of that 22:57 sapier hope you really know what you're doing cause this will not show up immediatly 22:57 CiaranG I really know what I'm doing 22:58 sapier may I ask what you need it for? 22:58 CiaranG Sure... 22:59 CiaranG Two current examples. 1. a mob that can be sent to another player, 2. a cart (i.e. on rails) that goes where it's supposed to go, and also comes back, without you riding in it 23:00 CiaranG The latter is transporting stuff, i.e. collecting it and bringing it back 23:00 sapier well true ... but both are the most critical situations too 23:01 CiaranG Well the first could cause the problems you're talking about, if it goes wrong 23:01 CiaranG The cart can't leave the rails though, so it's less of an issue 23:02 sapier it's an entity so it can move everywhere ;-) 23:02 CiaranG It definitely can't 23:02 CiaranG It's an entity that can only move where there are rails 23:02 sapier I'm not talking about if it's supposed to do to this 23:03 sapier :-) how do you intend to mak the mob walk from player to player? 23:04 sapier pathfinding wont work for large (3 digit) node distances 23:06 CiaranG I'm not using any kind of pathfinding currently, it's following pre-determined routes 23:06 CiaranG (which are laid out as paths on the ground) 23:06 sapier hmm you know mobf already supports this? 23:07 CiaranG I saw it has some pathfinding stuff yeah. I don't know if it's what I want though 23:07 sapier no I'm not talking about pathinding 23:07 CiaranG Oh, sorry, what then? 23:49 Robby nice addition that bind_address option 23:49 Robby can it also take a , separated list? 23:49 Robby I want to for example bind it on one IPv4 and one IPv6 address 23:51 Robby oh, nvm, I forgot about enable_ipv6 :)