Time Nick Message 01:30 hmmmm SegFault22, please take it to #minetest or post on the "feature requests" section of the forums 01:30 hmmmm this channel is for development discussion only 01:31 SegFault22 I tried taking it to #minetest, and one of your moderators suggested to take it here. 01:31 hmmmm welp 01:31 SegFault22 There is no feature requests section, by the way. 01:32 hmmmm perhaps the feature Discussion page then 01:33 SegFault22 That has been tried once before. But seeing the number of people who responded, I now understand that on the forums, I have to do something against the rules/bad for anyone to recognize it... 01:33 SegFault22 So here is the best, and seemingly only place, for contacting the developers. 02:37 ShadowNinja About LuaJIT packaging: I would rather have no libs packaged in Minetest and use dynamic libs. I agree with segfault, but you shouldn't have to register types, just store it as a std::string rather than a enumeration. 02:38 ShadowNinja I actually tried using the builtin method and was surprised that craft types were hardcoded. 02:38 ShadowNinja (For a technic machine) 04:04 OldCoder This is not yet a bug report. It won't be unless I see a definite pattern. But thought I'd mention that multiple worlds of mine, running git close to current, hang sometimes on Item Definitions load. 04:45 Sokomine question: why is a map where all the chunks the server sent so much smaller than the map on the server? even though it seems to encompass all the buildings? 04:46 Sokomine part of it may be underground (with mines), explored but unbuilt territory, air? 04:46 VanessaE underground. 04:46 Sokomine it can't be all underground 04:46 * Sokomine looks frightened 04:46 VanessaE wanna bet? :) 04:46 * Sokomine takes picks away from players! :-) 04:49 OldCoder Sokomine, the other world is online and very nice 04:49 OldCoder See me in PM or other chanels 04:49 OldCoder * channels 09:49 nore I found a bug: inv:set_size("space crash", 1) for an inventory crashes the server 09:49 nore with segfault 09:49 nore (the problem is the space inside the list name) 09:49 nore any thoughts on this? 09:56 nore debug_log_level = 4 gives nothing more that the traditionnal: 09:57 nore 10:53:50: ACTION[ServerThread]: singleplayer places node test:crafting_table at (-19,6,23) 09:57 nore 10:53:50: ACTION[ServerThread]: facedir: 2 09:57 nore and after that, server crash with segfault 09:57 nore so, does anyone knows where it comes from? 10:10 nore ah, and another bug: a negative list size does _not_ crash the server immediately, but when it goes to saving the map, it uses 100% CPU power 10:11 nore and it seems it uses a lot of RAM too since it was very hard to stop it and after having stopped it, there was still lag 10:23 nore BlockMen, https://github.com/minetest/minetest/issues/996 10:24 nore ^ what do you think should be done? 10:31 BlockMen does it crash in singleplayer for you? 10:32 nore yes 10:32 nore the very moment I place the node, I got a segfault 10:33 nore what OS do you use? it may not be the same as me... 10:34 nore I guess I should write that in the issue too 10:34 BlockMen thats strange...first times it worked for me, now it crashes with "bad allocation" 10:34 BlockMen and win7 64bit 10:34 nore for me it is Debian... I will write that 10:35 BlockMen but i had not last git, so i will need to compile first and then test again 10:36 nore I have found another bug too: a negative list size value will _not_ crash the server (I mean, when there is no space in the name), but at map save, the server eats 100% CPU and RAM 10:36 nore it was very hard to stop it 10:40 BlockMen for me it throws also "bad allocation" but freezes then 10:41 nore the negative stack count? 10:42 nore does it freeze your computer? (I had a lot of difficulties to stop it the first time) 10:43 nore the second time, I did something that killed minetest after 30 seconds (and it was enough to make it eat a lot of RAM) 10:44 BlockMen yes, the negative list size. it freezes minetest and windows kills the task then 10:44 nore I guess it is killed because it eats too much RAM or something like that 10:45 BlockMen i dont think so because it freezes nearly instantly 10:45 nore anyway, those two bugs need to be fixed (at least a better error message for the first one and a clean crash with error message for the second one) 10:46 BlockMen yeah, will take a look at it later, need to do other things now 10:46 BlockMen you made a report for the second one too? 10:47 nore no, not yet 10:47 BlockMen *on git 10:47 nore will do that 13:54 nore hmmmm, what do you think of that: https://github.com/minetest/minetest/issues/996 https://github.com/minetest/minetest/issues/997 13:54 nore (what should be done?) 15:43 celeron55 hmm, i have had this thing stubbornly floating in my head for enough time that i must do something to it 15:43 OldCoder What thing? 15:47 nore celeron55, what? 15:50 celeron55 is anyone whose thoughts i generally tend to approve interested in attempting a from-scratch redesign of the minetest engine, privately with me, with the goal of getting a good understanding of what kind of approaches are possible, what their pros and cons are and how the development of each could possibly work in the future (and publishing the end result)? 15:50 celeron55 i'm mostly pointing at kahrl, but i understand that kahrl is terribly busy 15:51 nore I don't understand the engine nor C++ enough, and currently have almost no time, so it can't be me... 15:52 nore but when you say from-scratch, that would change the whole API/etc too? 15:52 Jordach celeron55, ask darkrose, she'd help 15:52 celeron55 it's one of the many questions, and i don't want to start a discussion here because they almost always de-evolve into some kind of shouting competitions 15:54 OldCoder Here? 15:54 OldCoder This channel seems quiet 15:55 OldCoder One thing, celeron55... would such a rewrite be completely backwards compatible? 15:55 celeron55 it's one of the many questions 15:55 OldCoder Yes; if it was *not* the project might fail 15:55 celeron55 well that's one of the many questions too 15:55 OldCoder People will wish their old worlds to continue 15:55 kaeza or maybe not... 15:55 OldCoder But, then, a rewrite will let folks learn from past mistakes 15:56 celeron55 yes, one of the many questions! 15:56 OldCoder Heh. Do not rush. But imagine the possibilities. I assume that it would still be C++ 15:56 OldCoder Oh, well... Life is not perfect 15:57 celeron55 there are like infinite possibilities but the question is whether any of them makes any sense 15:57 OldCoder Perhaps you could design a new language with C as the back-end. The new language could be used to write the core engine. Possibly layers on top of mods as well. 15:58 nore OldCoder, about the old world thing: it would not be very difficult (compared to the other things to do) to make a map converter... 15:59 kaeza suddenly: Minetest written in Python 8) 15:59 proller php ! 16:00 celeron55 don't get hyped though; the end result likely is that nothing makes sense 16:00 proller celeron55, also make it really threaded, for using all cores 16:00 OldCoder nore If that was taken seriously, yes. But I am upgrading worlds right now inside of a consistent framework and everything breaks. Backwards compatibility requires thought. 16:01 OldCoder Multi-Threaded. celeron55 there is an idea most will agree on. 16:01 celeron55 proller: this kind of discussion is completely counterproductive; i wish people would just stick to the original question and some thoughtful person would volunteer 16:02 OldCoder celeron55, You must allow people to dream and to joke if you wish buy-in to the concept 16:02 OldCoder PHP is pushing it though :-) 16:03 OldCoder celeron55, Besides this *is* productive... 16:03 OldCoder You have identified backwards compatible and multi-threaded as concepts. And keep my "new language with C as back end" thought on the table; it might open up new possibilities. 16:04 celeron55 i already had those in mind and the whoever i would like to thoroughly dig this through would too have had them in mind; it's bringing nothing to the table except hiding my request 16:07 celeron55 (except that "new language" is nonsense) 16:09 proller celeron55, can you define short goal? like "threads, physics, speed, ...." 16:09 OldCoder As you wish, celeron55. Good luck. 16:09 celeron55 proller: no, because that is the question 16:10 proller + sizeof(int) world size 16:13 nore proller, that is not a good idea because it is architecture-dependent 16:17 proller okay, 2^32 16:19 proller but it not very big problem make with current code 16:24 OldCoder Why limit to 32 bits? 16:24 nore proller, there are problems (float precision, etc.) with Irrlicht when you go too far away 16:24 VanessaE nore: that's more a problem with how minetest uses irrlicht I guess 16:25 proller where problems started? if near 2^31 - it not a problem 16:29 general3214 Anyone online? 16:30 VanessaE no. 16:34 general3214 Oh okay 16:34 general3214 I'll just not bother VanessaE since VanessaE is not online. 16:34 VanessaE :P 16:35 general3214 :D 16:36 proller celeron55, and maybe something like ogre or... as renderer 16:36 general3214 What's celeron like? 16:37 general3214 Wait 16:37 thexyz this is not the channel for offtopic 16:37 general3214 Wrong channel 16:37 thexyz please don't shitpost here 16:37 general3214 omg these people so sensitive 16:37 VanessaE general3214: this channel has a fairly strict subject limit. 16:38 thexyz please stop 16:38 general3214 I know. I ain't dumb 16:38 general3214 general3214> Wrong channel 16:42 Calinou proller, there are problems (float precision, etc.) with Irrlicht when you go too far away 16:42 Calinou fix: move mesh around camera instead of moving camera around mesh 16:42 Calinou (iirc) 16:43 Calinou floating point precision errors always happe,n 16:44 nore Calinou, how do you store object pos then? 16:45 Calinou don't know that :P 16:45 Calinou fix is very hard to do 16:47 nore we would then need fixed point... (and rewrite a lot of things) 17:04 general3214 Is this channel ONLY about core development, or development in general? 17:04 thexyz read the topic 17:05 general3214|AFK I take that as a yes 17:05 thexyz and be aware that while I personally don't give a shit some people are easily irritated by afk nicknames and the most crazy ones can even kick you for that, I think 17:09 sapier can someone explain to my why recently everyone wants to start from scratch? 17:09 thexyz read the log 17:10 sapier I did that's why I ask 17:10 thexyz it doesn't seem to me that everyone wants to 17:10 thexyz people are just showing interest 17:10 sapier is there any major issue that would be fixed by starting from scratch I missed by now 17:11 thexyz it seems announcing it was not the best idea 17:11 nore perhaps entity duplication (dunno though) 17:11 ShadowNinja Speed, perhaps using a better graphics library, better network stack, etc. 17:11 sapier entity mechanics could be rewritten without rewriting whole minetest ;-) 17:12 sapier same for most other things ;-) 17:12 sapier the only benefit a complete rewrite would have is "yes that feature will be added later" ;-) 17:13 ShadowNinja Anyone have experience with SFML? I've also heard of using just plain OpenGL. 17:14 sapier dropping irrlicht means rewriting/replacing whole gui too 17:14 sapier both ingame as well as menu 17:15 sapier and there is no guarantee our own engine will be faster or more portable than irrlicht my personal bet is it wont be 17:15 nore on the other hand, there would be only one to rewrite now we have formspec menu... 17:15 ShadowNinja Yes, and changing v3f and the like too. 17:15 sapier I guess formspec will be dropped too 17:16 sapier and our main problem won't be fixed ... lack of parallelism within main game engine core 17:16 nore perhaps something good to do would be to change all v3s16 types to a POS type with a #define somewhere, so it can easily be changed in the future 17:16 nore and float pos too, etc 17:16 sapier it's not a matter of beeing good or not it's just a matter of time to be spent to fix it 17:17 ShadowNinja nore: There are also constants used in places like position hashing. 17:17 sapier https://github.com/minetest/minetest/pull/971 what about this one I wont add things that ugly without clear permission of at least 2 core devs 17:17 ShadowNinja 32-bit positions would be wholy incompatible with 16-bit ones. 17:18 nore ShadowNinja, there should be some world conversion probably then 17:18 sapier we already have performance issues do you really think increasing complexity will do any better? 17:18 ShadowNinja nore: Yes, it would probably be mostly runtime incompatabilities though. 17:19 ShadowNinja sapier: No need for 32-bit positions now. Just discussing it. 17:19 sapier is that bug already fixed segfault22 discovered? 17:19 ShadowNinja As for #971 I echo what kwolekr said. 17:20 nore that's why I suggest a #define POS_TYPE v3s16 ... 17:20 nore sapier, what bug? 17:20 ShadowNinja Or typedef. 17:20 sapier echo what? 17:20 nore ShadowNinja, what's typedef? 17:21 ShadowNinja nore: It adds another name for a type, eg size_t is typedefed to something like unsigned int. 17:21 sapier nore the crash with invalid list sizes 17:23 sapier ShadowNinja as kwolekr didn't say yes or no what's your oppinion to 971 17:26 ShadowNinja sapier: It's awully ugly, and I would really rather have a better option. But if there is no other way... 17:28 sapier YES or NO ... a maybe is useless ... I'm gonna continue repair my car now if noone has courage to decide by time I'm finished I wont ask again 17:29 thexyz sapier: unrelated, why do you put /******************************************************************************/ everywhere? I don't remember seeing stuff like that in our code guidelines 17:29 thexyz it's yes for sure 17:29 thexyz too bad that's what happens with most of pulls 17:29 thexyz people who didn't research the subject complain about stuff they contain and can't decide whether to merge it or not 17:29 thexyz so people who did the research and made pull request eventually burn out 17:30 proller i'm ready to join all my pulls in one 17:30 proller now i cant make many things 17:31 thexyz proller: did you see https://github.com/minetest/minetest/pull/895#issuecomment-28129708 17:32 proller no problem with abm timers, they increase chance if some calls was missed 17:33 proller but some every second on_step will be skipped 17:34 proller but anyway it better than now in master 17:44 proller idea: improve commiting rules: if pull waits more than [1-2] weeks and have no objections - every core dev can commit it (even pull creator) 17:44 proller no future in current state 18:21 sapier proller not a good idea as any crap can be merged if just enough core devs didn't have time to review 18:23 VanessaE sapier: to be fair, "just any crap" could be merged anyway, regardless of such a rule. 18:26 sapier thexyz I added the /**/ because I regularly do this in all of my cpp files to have a chance to find functions ... there's no other function separator defined in coding style so /***/ is as good as any other. I still believe it's way more readyble but if this is the only reason for not merging it I'm gonna remove it 18:27 thexyz it's not, it's just something I find strange 18:27 thexyz the pull is OK 18:27 sapier Ok let me be more precise VanessaE any crap might be merged even more easy ;-) 18:28 sapier especially if there are many small functions code with /***/ in there is more readable ... at least to me 18:28 VanessaE actually, there IS a defined separator, unofficially. 18:28 PilzAdam nore, https://github.com/minetest/minetest/issues/996#issuecomment-28225332 18:28 VanessaE it's just that it isn't really written down and it's only been used in a few places - a line of ------- 18:29 VanessaE (see some of the files in builtin) 18:29 sapier that's MY separator too for lua code ;-) 18:30 sapier /***/ variant is ancestor of ----- as comments are -- in lua :-) 18:30 sapier "best.gir.never.wins..." ?? :-) 18:32 sapier ok as I now have at least one clear yes vote for 971 I'm gonna count my own vote as second yes and merge in half an hour ... so last chance to veto 18:32 PilzAdam celeron55, I am very interested in such a rewrite because it would give me the ability to understand the basic concepts of such and engine better 18:32 sapier ShadowNinja did you merge your lua error handler fixes yet? 18:33 PilzAdam celeron55, although I dont know if you would benefit from that 18:33 sapier I suggest forking rewrite to minetest2 18:38 sapier another suggestion for speeding up merges what about assigning pull requests to core devs to review? method of assignment has to be defined. maybe most simple variant credit core devs with lines changed reviews 18:43 sapier REQUESTING FEATURE FREEZE FOR 0.4.8 RELEASE at end of November anyone agree? 18:44 * sfan5 agree 18:44 sfan5 s 18:45 sapier maybe we could create a integration branch to not stall development while freeze is active 18:46 sfan5 wouldn't that be messy? 18:46 sapier no merges during feature freeze should be minor bugfixes onla 18:46 sapier only 18:47 troller sapier, something like dev branch - https://forum.minetest.net/viewtopic.php?id=7033 18:47 sapier similar yes but with same merge rules as current master 18:49 sapier I'm not talking about a permanent thing only while feature freeze is active once release is done this branch should be merged to master ... this way we could review merges for next version and don't have to check again after 0.4.8 release 18:49 troller current rules like for atomic station software 18:49 troller and result is frozen development 18:50 sapier imho we'd need a stable as well as development branch ... but that's another issue 18:53 PilzAdam we have a stable branch 18:53 VanessaE sapier: agreed, with the proviso that the release be delayed beyond the end of November if some bugs just can't be fixed in time. 18:53 sapier we do? when was it used last time? 18:54 celeron55 it has been updated on each release 18:54 PilzAdam https://github.com/minetest/minetest/tree/stable-0.4 18:54 PilzAdam master is our dev branch 18:54 sapier of course VanessaE End of november would be only "target date" 18:55 sapier wow didn't even know about that one this is 0.4.7 not 0.4.0? 19:17 BlockMen i noticed a problem with lvm. after doing a few more calculations i get an "not enough memory" error, even by letting grow a lot saplings. http://pastebin.com/FFVcFyjV 19:17 BlockMen is there a problem with not released memory? 19:18 sapier did you check memory usage on your system? asking to be sure it's a out of memory not some "in lua" limitation 19:23 sapier ok pushing i18n pull request now 19:24 sapier plz test it I checked linux mingw32 and vs2012 32 bit only hope this is enough 19:27 BlockMen its stable around ~330mb (minetest) until it uses lvm. then it increases more and more until mem usage 80%+ 19:27 sapier what are you doing in there? 19:28 PilzAdam sapier, "/home/adam/Minetest/minetest/src/guiChatConsole.cpp:560:78: warning: ignoring return value of 'int mbtowc(wchar_t*, const char*, size_t)', declared with attribute warn_unused_result [-Wunused-result]" IIRC this was there before your patch too? 19:28 BlockMen growing 200 saplings 19:29 sapier I don't remember changeing anything in chatconsole 19:30 sapier nope changed almost all other gui files but not this one ;-) 19:30 PilzAdam this seems to be the last warning left (for gcc, that is) 19:31 sapier sadly I didn't see it I'd have fixed it 19:31 sapier fixed some other warnings within that patch too 19:34 sapier is saplings using l-tree? 19:35 nore sapier, no 19:36 sapier strange would be more likely to eat up all memory on recursive algorithms 19:37 nore the strange thing is that I have already used LVM for quite intensive tasks (i.e., reading ~100 4x150x4 areas every 2 seconds) 19:37 nore and I never had this problem (except when I tried to read a 240x150x140 area) 19:38 sapier maybe it's a special function triggering the bug, blockmen can you provide code to trigger it? 19:38 sapier lol I'd not consider that a problem nore just buy a bigger machine if you want to do things like that 19:39 nore I don't consider it a problem either... anyway, that was badly-written code, I optimized it much after... 19:40 nore gtg 19:40 BlockMen sapier, i uses the code from default, so https://github.com/minetest/minetest_game/blob/master/mods/default/functions.lua#L138 19:41 BlockMen but i also noticed when using my mines mods, etc. everything that uses lvm and used for a lot of operations/time 19:41 sapier yes but how do you grow 200 saplings? :-) manually? 19:41 BlockMen ya, sure. 200 is plant fast (<2min) ;P 19:41 BlockMen s/plant/plated 19:42 sapier lol ... I'm gonna try once ;-) 19:43 BlockMen even if it wont crash...the mem usage increases from ~330mb to ~1,5gb just because of lvm 19:47 sapier maybe a garbage collection issue? 19:49 sapier I just planted 250 saplings no noticable memory increase 19:54 BlockMen well, if it just happen for me then we have no problem :) 19:55 sapier we have a problem we just need more information and as you're the only one to notice by now it's up to you to find out how to reproduce ;-) 20:00 sapier https://github.com/minetest/minetest/pull/993 any comment? 20:01 PilzAdam valgrind anyone? 20:02 PilzAdam (re that sapling problem) 20:03 sapier I can't reproduce so blockmen has to do 20:03 troller sapier, copypaste 8( 20:04 sapier copypaste? 20:06 thexyz copypasta indeed 20:07 thexyz sapier: he's complaining about some blocks of code looking too similar 20:07 thexyz like, they're exactly same 20:08 sapier it's json parser what do you expect? 20:08 sapier yet that's already in master as well as the bugs ;-) 20:09 thexyz I'd expect maybe a function to which you pass the string? 20:09 thexyz and this is exactly what happens when you copypasta 20:09 thexyz you have to fix bugs in multiple places 20:09 thexyz but meh, I guess you know all of that 20:10 sapier I do yet someone said to create a better json parser 20:10 sapier if I remember correctly it was proller 20:11 troller yes, but... ;) 20:12 sapier but what? *g* 20:12 sapier *g* --> :-) 20:13 troller in my queue was more important (for me) things 20:14 sapier I won't write it either so we'll have to stick with current suboptimal version 22:09 hmmmm celeron, a from-the-ground approach is not a very good one 22:11 hmmmm the codebase we have today is not just a huge block of code, it's days, weeks, months, and years of labor and knowledge gained 22:11 hmmmm you say you want to use the knowledge gained from minetest to make the right decisions a second time, but how do you know you're not going to make more bad decisions on other parts? 22:12 hmmmm also what if much of the knowledge gained only pertains to designs only made because of some root design choices 22:13 sapier https://github.com/minetest/minetest/pull/993 hmmmm do you agree to this one? 22:13 hmmmm if you go with something fundamentally different, say for example, executing things on events instead of polling a queue every step, what you have learned might not be very helpful at all 22:14 hmmmm and then there are things like the modding api that really are decent for what it is and we can't do much better due to the nature of scripting 22:15 hmmmm don't really understand the point of changing *clients_raw != 0 to clients_raw != "" when you kept the thing to the right of it 22:15 sapier asString() creates a temporary object 22:15 sapier thus storing a pointer to a temporary object is quite dangerous ;-) 22:16 hmmmm oh oh nevermind, you changed that from c_str() 22:16 hmmmm makes sense 22:16 hmmmm yeah, what you did looks fine 22:16 sapier yes done it at other place recently didn't know it's hidden here too 22:16 hmmmm yes, can't you push things on your own anymore? 22:16 sapier I can yet I need agreement ;-) 22:17 hmmmm not so much for a bugfix that you know is going to solve the problem 22:17 sapier I'm still the new one so I stick to the rules ;-) 22:17 hmmmm more controversial things like restarting the process under a different locale, that could take agreement I'd say 22:18 sapier actually I didn't merge it without agreement 22:18 hmmmm i know you didn't, I was just using that as an example of something that anybody would need a consensus on to merge 22:18 sapier btw it's only done for silly msvc build ... I strongly discourage building mt with it 22:18 hmmmm whereas a memory leak fix like above is fine 22:19 sapier it's more a possible access violation ... most likely it wont cause any harm but the other ones did cause harm on windows 22:20 hmmmm oh, access violation? hmr 22:20 sapier actually it's more likely you read crap 22:21 hmmmm oh, sorry 22:21 hmmmm I'm not paying enough attention to what I'm reading 22:21 sapier that pointer is just random space ... ok not exactly random as it's data most likely is still there, but it may have already been reused 22:21 hmmmm just got back from a day of work 22:22 sapier oh I see :-) btw I do think same at rewrite thematic ... partial rewrite of components yes but not a complete rewrite 22:22 sapier and partial can be done within normal development (if there's someone who really cares to do) 22:22 hmmmm right 22:23 hmmmm I'd rather work on specific things that need work rather than the clean slate rewrite, e.g. formspec and mainmenu 22:23 sapier what about the real issues? map/environment locking? *smile* 22:23 hmmmm right 22:23 hmmmm we need to really work on that 22:24 sapier formspec and mainmenu may be suboptimal but missing map/environment locking stops any attempts to gain performance by parallelization 22:25 troller and dont save not changed new blocks 22:25 sapier pushing temp object fixes now 22:25 troller my map 2.6G already 8( 22:25 hmmmm troller, that would screw up minetestmapper 22:25 troller minetestmapper dont work on my map too ;) 22:26 troller then make it adjustable 22:27 sapier https://github.com/minetest/minetest/issues/997 I consider this to be a blocker issue for 0.4.8 what do you think? 23:04 sapier https://github.com/minetest/minetest/pull/998 should fix 996 as well as 997 23:09 ShadowNinja Actually the mapper thing isn't that important because you usually don't need to see what is in unmodified blocks. 23:10 sapier ahh Shadow :-) what about your lua errorhandler fixes? 23:14 ShadowNinja sapier: I don't have agreement for them yet. And there is a small issue that I tried to fix locally... 23:15 sapier what issue? 23:15 ShadowNinja sapier: 'throw LuaError("Something")' from a API function causes "ServerError: LuaError: C++ exception." I think LuaJIT is at fault for this. 23:16 ShadowNinja And Regular LuaError's din't have a traceback anymore. (I added that locally) 23:16 ShadowNinja s/R/r/ 23:16 ShadowNinja don't* 23:17 ShadowNinja I don't know how to compile with non-JIT Lua though... 23:17 sapier ok they should have tracebacks for sure 23:17 sapier didn't we have issues with exceptions within lua called functions before? 23:17 ShadowNinja Put adding the traceback is pointless when you just get "C++ exception" 23:17 ShadowNinja Yes. 23:17 sapier of course 23:18 sapier worst thing is enclosing all lua functions within try catch .... quite a lot of work and no guarantee to work 23:23 ShadowNinja sapier: This is what I have locally, does it look good? https://gist.github.com/ShadowNinja/7422436 23:27 sapier sorry to late to review today I recommend updating your pull request if you think it's better than the current one.