Time  Nick         Message
00:01 celeron55    (or something similar that is not based on polling)
00:02 CiaranG      Now would be the time for you to point out that I forgot to include the change to doc/lua_api.txt
00:03 CiaranG      I thought about adding the event at the same time, but I also thought that an entity that's interested in collsion will be polling for the static information anyway, so you'd just end up giving it the information twice
00:07 CiaranG      On the other hand, doing it event-based allows the entity to actual return a response to the collision. But that's a bigger change than this was intended to be.
00:33 CiaranG      Ok, fixed the constructor and the crappy squashed name
04:09 hmmmm        agh crap
04:10 hmmmm        ShadowNinja, your ostringstream commit broke negative integer values
04:11 hmmmm        i didn't see for myself but i'm willing to bet that'll cause default mapgen v6 settings to screw up hard when saved to map_meta.txt
08:16 ShadowNinja  Whoops, droped part of the signedness logic.  I'll fix that...
08:28 ShadowNinja  This ought to do: http://sprunge.us/UUVZ?diff  Comments?
08:38 RealBadAngel if works then ok
08:56 ShadowNinja  Minetest is consistently throwing bad_alloc on startup now.  But now just with that patch...
09:17 ShadowNinja  Well, this gets it to run: http://ix.io/bcp/diff  And it seems to work.
15:50 Sokomine     i was able to reproduce the problem with that particular tree twoelk had on vanessas server. saving the tree with the vines, importing it into a fresh map with very limited amount of mods installed, and digging a node triggered the bug
15:50 Sokomine     the schem can be found here: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/invasionofthevines.mts
15:50 Sokomine     currently trying to figure out more
15:51 VanessaE     file size is about 5 kB
15:51 VanessaE     so no complaints about download times :P
16:07 twoelk       hi, regarding the servercrashing tree on VE-Creative I'm pretty sure by now it has something to do with the removing node part in the vines mod
16:07 VanessaE     twoelk: check the log.
16:07 VanessaE     http://irc.minetest.ru/minetest-dev/2014-03-21#i_3623135
16:07 twoelk       ? which log?
16:08 VanessaE     Sokomine beat oy by about 15 mins :)
16:08 VanessaE     you*
16:08 Sokomine     twoelk: possibly. i was able to reproduce it in a singleplayer world with that tree that gave you all that trouble
16:09 Sokomine     after inserting a print statement somewhere, it suddenly worked. now it seems to work even without the print statement
16:09 Sokomine     what is quite obvious is that a single dig of a vine may require checking half the tree
16:09 twoelk       but do the vines still behave strangly?
16:10 twoelk       digging a bottom vine should not destroy vines above
16:11 twoelk       and digging a block nearby should not affect a vine not attached to the block I interact with
16:11 Sokomine     hmm. digging something seems to trigger checks for falling nodes in the nodes around
16:11 VanessaE     and since she's doing this in a freshly-created singleplayer world with a .mts file she saved and I made available to her, that means it ain't my map file
16:12 twoelk       never said so ;-)
16:12 VanessaE     Sokomine: what mods are installed in your test world, aside from vines and I presume moretrees/plants_lib ?
16:12 VanessaE     twoelk: I know - I was afraid maybe my map was corrupted, but clearly that isn't the case here.
16:12 twoelk       I made a skyblock with 4 trees and lots of vines, same behaviour of the vines there
16:13 twoelk       though no crashes
16:13 VanessaE     vines mod hasn't been touched in about 5 months, so I doubt it's a bug in that mod
16:13 VanessaE     at least not a new bug anyway
16:13 twoelk       I have never befor approached those trees, so I can't say
16:14 twoelk       I remember though changes of the vines mod while playing on VE-Survival
16:16 Sokomine     VanessaE: none relevant i'd say. mostly mods i'm working on
16:17 VanessaE     Sokomine: not even the vines mod at this point? O_o
16:17 twoelk       where is the group parameter "hanging_node=1" described?
16:17 Sokomine     VanessaE: of course the vines mod :-) i tested first without even moretrees
16:17 VanessaE     Sokomine: ok
16:18 VanessaE     Sokomine: just had to check :)
16:18 Sokomine     twoelk: special group defined by the vines i guess
16:18 twoelk       cant find it there
16:18 Sokomine     yet the result of vines without moretrees and vines with moretrees is diffrent
16:18 Sokomine     twoelk: the group is just used. nothing more happens there (or anywhere i could find)
16:19 twoelk       it is definitly not described in LuaApi.text
16:19 Sokomine     what happens if i dig a vine on the tree: half the tree loses its sideway vines. only those that are attached to leaves or tree trunks keep hanging
16:20 VanessaE     Sokomine: maybe because moretrees/plants_lib adds a bunch of leaf decay abms, hence a miniscule cpu overhead - but those do nothing if the decay code doesn't have to actually run.
16:22 VanessaE     yep, a quick grep shows hanging_node troup is only used within the vines mod, but it doesn't appear to actually be *used* for anything
16:22 VanessaE     group*
16:23 twoelk       the avoid radius in the spawning code has similar values (3 and 5) to the values I notcied the vines get deleted around the trigger node
16:23 VanessaE     I'd call that a coincidence really
16:23 twoelk       hopefully
16:28 twoelk       If adding a print statement between functions and deleting that again fixed the crash problem, maybe something between functions was missing? Can lua functions leak into each other if not seperated properly?
16:28 Sokomine     ok...now debug message *and* crash can happen simultaneously. i cheated a bit by not using moretrees in that test world - thus more vines are bound to decay
16:29 twoelk       and another theorie proved wrong within seconds
16:31 Sokomine     digging a single vine ends up in 4058 checks in that special situation before the stack overflow happens
16:33 twoelk       uh?
16:34 VanessaE     4058??
16:34 VanessaE     that's impossible
16:34 VanessaE     there can't be THAT many vines
16:34 VanessaE     even a whole TREE ain't THAT big
16:35 VanessaE     (there shouldn't be more than maybe a 10:1 ratio of leaves:vines, at the most, I'd guess)
16:36 Sokomine     no, they're not all vines. some are air nodes. those are checked as well
16:41 VanessaE     ah
16:41 twoelk       to be honest I can't really find the code that deletes vines:willow or vines:side; only the one for the rope
16:42 Sokomine     nodeupdate in builtin/falling.lua does check all nodes around the node concerned - with one in each direction, that leads to 9 nodes (3x3x3 cube) beeing checked
16:43 Sokomine     and in our case, at least some of these contain vines as well
16:45 twoelk       paramtype2 = "wallmounted" so if falling.lua finds no wall it might consider the vine prone to falling?
16:45 Sokomine     yes, and in my world, those nodes get removed/fall down
16:46 ShadowNinja  nodeupdate_single might be helpfull, but it sounds like it's doing something wrong.
16:46 Sokomine     only what is attached to leaves remains. this may not be what the author intended
16:46 Sokomine     shadowninja: did you take a look at the sample tree?
16:47 Sokomine     twoelk: that also explains why the crash occoured already when you changed a node next to a vine. the vine was the neighbour, and that triggered the update
16:47 ShadowNinja  Sokomine: No.  It sounds like this issue is a mod issue, not a engine issue, though.
16:47 twoelk       so the 9 node checking triggers an endless cascade
16:48 Sokomine     ShadowNinja: ah. hm. yes, in this case it might be eaiser/more useful to fix it in the mod concerned. yet such bugs that are hard to find are a bit problematic
16:49 Sokomine     not really endless, but...too large a cascade for the stack to handle in this case
16:49 kahrl        why does the recursive call in builtin/falling.lua:185 ignore the delay parameter anyway?
16:50 twoelk       so maybe nodeupdate should back out if a certain value is reached?
16:51 kahrl        (probably unrelated to the vines issue)
16:51 VanessaE     why did this only just start in the past weeks?
16:51 kahrl        actually no it probably is
16:51 VanessaE     this mod has been in place for....months
16:52 twoelk       was there a recent change in falling.lua?
16:52 VanessaE     beats me
16:52 kahrl        git log builtin/falling.lua -> last change 2013-10-01
16:52 ShadowNinja  Last change I remember was by me, and long ago.
16:53 Sokomine     kahrl: does not look as if the code where the delay would take effect would be called in nodeupdate_single
16:53 ShadowNinja  I remember thinking that nodeupdate* looked ugly though.
16:53 VanessaE     so maybe this tree just got overgrown enough with vines to actually trigger a latent bug no one found until now?
16:54 twoelk       nobody dared to touch a large tree :-D
16:56 Sokomine     who knows. perhaps twoelk spent too much time next to it so that the vines had time to thoughly take it over
16:56 twoelk       so "hanging_node" mighthave been intended to bridge the gap between "wallmounted" nodes but never really made to work
16:56 Sokomine     twoelk: i'd guess so, yes
16:57 proller      nodeupdate must be in c++
16:57 Sokomine     twoelk: the behaviour of falling_node does not seem to be the intended one for the vines anyway. they ought to be happy as long as the topmost vine can cling to anything. they even grow from top to bottom
16:57 Sokomine     proller: perhaps. would have made debugging even worse in this case though
16:58 twoelk       so falling.lua has to be convinced to ignore hanging nodes
16:58 proller      but it will be 10-100x faster
17:00 Sokomine     falling.lua would have to treat hanging nodes differently
17:01 twoelk       so if indeed paramtype2 = "wallmounted" triggers the falling, what is the alternative?
17:02 twoelk       proller: I wonder if that would also make the crash faster
17:02 proller      crash?
17:06 ShadowNinja  That would probably mean less Lua -> C and back switches.  So it should be a bit faster.
17:06 proller      bit - like your mg speed tests ?
17:06 proller      ok, 20x then
17:10 Sokomine     perhaps it might be cheapest to let the topmost vine check via abm if the node it's clinging to still exists. if not, it can check how many of its kind hang below and take care of their removal and remove itshelf
17:10 Sokomine     or - especially regarding completition of the api - something like neighbour_digged as a callback in the node definition?
17:11 Sokomine     that way, perhaps even digged trees mapy propagate their digging state and attached leaves decide to give up
17:13 twoelk       another way of decay?
17:14 Sokomine     in a way, yes
17:14 Sokomine     might trigger the same problem we ran into here though
17:15 Sokomine     especially if too many nodes are intrested in the state of their neighbours and too many of them are in one area
17:16 twoelk       the checking seems recursive
17:18 twoelk       so if I have vines hanging hundreds of nodes from a skyblock, if I kill the bottom most one all hanging ones to all sides dissappear if they are neighbours
17:18 twoelk       or crash if there are too many
17:18 Sokomine     yes
17:19 Sokomine     might be less worse in such a situation - a single long vine affects less nodes than one that conquered a moretrees jungletree
17:20 twoelk       I was thinking of curtains of vines
17:21 Sokomine     curtains - still 2d. yours had 3d to take over
17:21 twoelk       actually I guess this only affects loaded chunks so It might really be a rare situation
17:28 twoelk       so if "check_attached_node" in falling.lua first checks for "group = hanging_node" it could exclude affecting nodes that are attached to something other than blocktype nodes
17:31 Sokomine     hmm. supporting hanging nodes as such might be nice; after all they're similar to falling_nodes - they just care about a node at another position than the falling ones
17:32 twoelk       actually I think this could be usefull in rope-like and curtain-like mods
17:34 Sokomine     that's true. there are situations where such a behaviour is very desirable
17:36 Sokomine     the vines mod already has a possible solution for the problem - the ropebox. it requires 3 diffrent nodes (top node, undiggable middle part, growing lower end) to achieve it but works pretty well
17:39 twoelk       ah but we havn't yet checked a rope with that many nodes in it
17:40 twoelk       and the rope delting definitly is meant to be recursive
17:40 twoelk       *deleting
17:40 sapier       I guess it'll be impossible to make people realize c++ isn't by definition faster then lua but only for some sorts of things .... btw "10x-100x" seems to be quite standard ... can we establish some sort of java is 5-10 times slower then lua pardigm? ;-)
17:41 Sokomine     *nod* but it does have an advantage: the rope only goes up and down. far less nodes to be checked than with 3d recursion
17:41 sapier       did anyoone try my latest android build?
17:41 twoelk       I guess it depends on what you use java for
17:41 twoelk       It surely was never intended for 3d games
17:41 sapier       twoelk: you're absolutely right ;-) ... depends is always right answer
17:42 sapier       well c++ wasn't intended for 3d games too ;-)
17:42 Sokomine     sapier: i think in this case the point was about possible overhead if switching back and forth between languages occours
17:43 sapier       as a rule of thumb the more often you need to fetch information about map the faster a c++ implementation will be ... but this is only true if you need more then ... well I don't have exact numbers but for what I remember less then around 50 accesses don't really matter
17:44 twoelk       so the more players you have the better c++ gets?
17:44 sapier       so if you have a call done once a minute looking for 30 map locations you'll be most likely better in pure lua
17:45 sapier       player number is not really related to lua calls
17:45 twoelk       well if 50players on a server open a protected chest.......
17:45 sapier       at least if you don't count the increased base load resulting from more players
17:46 sapier       then you have 50 calls if they do it exactly same time
17:46 sapier       not relevant
17:46 proller      whats about global lua lock?
17:46 twoelk       add one and c++ gets better :-D
17:47 sapier       its not a lua lock but a server step lock
17:47 proller      lua must be locket, even if server will be real multithreaded
17:48 sapier       twoelk: if you manage to syncronize 50 human players to open a chest in eyactly same server step I'll agree to you ;-P
17:48 CiaranG      That could be easy, depends how long the server step is ;)
17:48 proller      mt can have 5-10+ seconds step with 20 players- > no problem ;)
17:49 sapier       CiaranG if server step is 5 seconds we don't have to bother about lua processing time ;-)
17:49 twoelk       I would bet some complicated mesecon/technic contraption plus some quary modsetc can easily amount to that many calls on a busy server
17:49 sapier       no it can't everything above half a second will cause major lag and is result of bugs in mods
17:50 proller      90% from 5s can be lua
17:50 proller      ^ with mobf for example ;)
17:50 sapier       proller I can write a loop sleeping for 10 seconds in c++ too
17:50 VanessaE     all of this doesn't help solve the stack overflow in the falling code though :P
17:50 proller      mobf have sleeps?
17:51 proller      VanessaE, fixed in FM half year ago ;)
17:51 sapier       nope mobf is perfectly fine on default minetest it's freeminer breaking base parameters mobf relies on
17:51 sapier       e.g. player movement speed
17:51 VanessaE     proller: would be nice if you could contribute that fix back to mt then :P
17:51 proller      grab it
17:52 sapier       wrong license you have to write a pull request
17:52 proller      it was but..
17:53 sapier       well back to android port guess noone tested it by now?
17:53 VanessaE     sapier: sorry, haven't had time
17:53 twoelk       got no android device :-(
17:53 sapier       does anyone have an idea about the rail graphics corruption?
17:55 CiaranG      Heh, leave that in, my son is fascinated by it. He wants to know where all the rails going up into the sky lead to.
17:55 sapier       lol
17:55 CiaranG      I'll try the latest on a few devices tomorrow if I get time
17:56 * twoelk     is still digesting ..everything above half a second will cause major lag...
17:56 sapier       thanks I guess there'll be quite some bugs left to fix prior it's in shape for merge
17:57 sapier       don't take the half a second to be a hard limit ... doesn't matter if it's 0.4 or 0.6 ;-)
17:59 sapier       hmm tile.cpp isn't the only way to create a texture
18:09 spillz       @sapier: I tried you android build yesterday on galaxy note 2. startup took crazy long time (nexus 7 didn't have this problem on a previous build) and interact/dig/place objects still sucks (at least in singleplayer) on all my devices. don't you have this problem?
18:10 sapier       no I can dig and place quite fine ... what happens for you?
18:12 sapier       does it take long time showing the progress bar or somewhere else?
18:14 VanessaE     proller: so exactly how did you fix it?
18:15 proller      - bad code
18:15 proller      + good code
18:15 Sokomine     i only remember that i saw shingles (which use raillike drawtype as well) shoot into the sky with an older build from stu as well
18:16 proller      ok, not good, just working
18:16 Sokomine     as far as lag goes: the record may be one particular server. a chat message where the other player replied immediately after reading it took 20 minutes before the answer arrived
18:16 VanessaE     proller: and that good code consists of what sort of logic? :P
18:17 proller      make world better ;)
18:17 celeron55    spillz: does your galaxy note have an sd card in it while nexus 7 not? those are usually very slow unless a very expensive one and that will make the copying very slow
18:17 celeron55    or do you mean some other part of the startup
18:18 Sokomine     hm, startup of new versions of mt on anrdoid always took some patience the fist time
18:18 VanessaE     I suggested to sokomine just a minute ago, that the code should dump out after a certain put, without erroring/crashing, and set some flag that means "wait, there's more to do", which the server could come back around and examine later (say a few server steps later or something), at which point it could just start up the routine from the beginning, but at a new starting position in the world or something
18:18 celeron55    (on my phone it's not really slow at all)
18:18 VanessaE     certain point*
18:18 VanessaE     e.g. some reasonable limit of recursion depth
18:18 spillz       I have to tap then hold sometimes 10 times before the game will properly accept that I am trying to break stuff
18:19 spillz       Re slow start, it's the scanning step. I have sd card, but I though the mt folder was in normal storage
18:19 Sokomine     a limit to the recursion depth might be fine
18:19 sfan5        celeron55: some phones also have /sdcard symlinked to internal memory
18:19 sfan5        (like mine)
18:19 spillz       slow start is every time not just first
18:20 VanessaE     sfan5: my tablet puts its internal flash there.
18:20 celeron55    sfan5: mine too
18:20 Sokomine     almost always a crash (especially with an error message nobody understands) is more critical to mt than if a few blocks which ought to drop down don't - if the player cares, he can trigger a new drop-sequence by digging nearby
18:20 celeron55    sfan5: but maybe some don't
18:20 sapier       spillz is it possible your touchscreen generates move events on tapping instead of stable tap detection?
18:21 sapier       I know about at least on high dpi screen having this problem
18:21 spillz       On note 2, sd card is extsd.  maybe note 2 has slow internal storage but it is high end phone
18:21 sfan5        celeron55: the crappy old one I had didn't (have /sdcard -> internal memory)
18:21 sfan5        it also had just about 100MB internal mem
18:21 sfan5        in that case it makes sense to not make apps but everything into the internal mem
18:21 celeron55    having /sdcard that isn't actually an sd card is totally stupid though
18:22 celeron55    it's like the most misleading thing in this world
18:22 spillz       @sapier: quite possibly. what are you using for tap detection - android API?
18:23 sfan5        the real sd card is /storage/extSdCard on mine
18:23 sapier       celeron55 did you forget about start to shutdown?
18:23 sfan5        specing: you can't use everything besides the android api to get touches (reliably)?
18:23 sfan5        s/?//
18:23 sfan5        damnit
18:23 celeron55    sapier: that's obvious; you start shutting down
18:23 sfan5        spillz: you can't use everything besides the android api to get touches (reliably)
18:24 sapier       spillz: tabs are always detected by android api as well as moves are generated but right now any tab moved after touch will be ignored for digging (and placing)
18:24 sapier       that could explain your problems
18:24 celeron55    well minetest uses irrlicht, but irrlicht is custom-patched to get the touches from the android api :P
18:24 celeron55    or has that changed?
18:24 spillz       @celeron55: Samsung phone, need I say more? (although isn't misleading storage naming pervasive in android)
18:25 sapier       irrlicht got most of our early changes in by now
18:25 sfan5        celeron55: irrlicht obviously uses the official android api for touches
18:26 spillz       That's what I am wondering - whether you guys have actually checked the android API calls or just relying on irrlicht code to do it correctly.
18:26 sfan5        irrlicht does it correctly
18:26 sapier       we did as irrlicht isn't finished by now but we need to handle a few things ourself
18:27 sapier       yet that crapy tab thing is done by android
18:27 sapier       btw is it tab or tap?
18:27 sfan5        sapier: <random thing> my irrlicht fork already translates touch inputs to mouse events, no need to do that in minetest https://github.com/sfan5/irrlicht-android </random thing>
18:28 spillz       Think you mean tap?
18:28 sfan5        "tap" I think
18:28 sapier       I don't use irrlicht forks
18:28 sfan5        but you're applying a patch to irrlicht
18:28 sfan5        that is almost the same as using a fork
18:29 sapier       nope my changes are minor and I plan to get them back to irrlicht as soon as possible
18:29 sfan5        my changes are minor too
18:29 sfan5        I just store them in a repo for easier managing
18:29 sapier       but they're not separated from irrlicht that's a major issue on rebasing to new irrlicht code
18:30 sapier       and I really doubt irrlicht guys will accept translation of touch events to mouse events
18:30 spillz       @sapier: "tab moved after touch ignored" does that mean if the move comes in before the tap that you ignore the tap. maybe that's a problem, especially on high DPI screen?
18:31 sfan5        sapier: why?
18:31 sapier       because they have touch events they won't throw touch and mouse events onto each other
18:32 sapier       no spilz, android api creates unique id's for each touch
18:32 sapier       in current implementation if a touch is moved it won't cause a dig or place any longer
18:35 sapier       I guess if we want to translate touch events to mouse events we have to do this on our own irrlicht wont do this for us
18:35 sapier       that's why I made touchscreengui to be a event translator
18:35 sapier       btw does anyone know what eurasiaicon is?
18:36 sapier       wait eurasiacon
18:43 sfan5        sapier: google
18:44 sapier       doesn't result in any helpful thing (at least for me) ;-P
18:46 spillz       sapier: "if a touch is moved" on high DPI phone almost impossible not to move a touch. maybe add a move threshold? but not sure why you need that at all...
18:47 sapier       because a moving touch is changing view
18:47 sapier       it's annoying to start digging if you just wanna look around ;-)
18:49 spillz       Isn't there a measure of the touch strength? strong touch dig, weak touch ignore (user meant to look around)
18:49 sapier       I don't think so
18:50 spillz       anyway, however you are doing it just won't work. there's always a risk of a little movement when you press your finger down
18:51 spillz       so threshold...
18:51 sapier       not if you've got a high quality screen ;-) ... but yes I need to find a workaround for buggy screens anyway
18:51 twoelk       by now listening to this I guess an extra button soley for digging would be best. This way moving and digging could be combined in a more controllable way
18:51 sapier       that's what I wanted to avoid ;-)
18:52 sapier       as you should be able to place and dig anywhere on screen (doesn't work due to a bug right now)
18:52 spillz       But it works fine as touch on minecraft pocket, survivalcraft, blockstory, ...
18:53 sapier       you can only build and dig on crosshair there true?
18:54 twoelk       my fingers are too clumsy for such sensetive devices anyway
18:54 sapier       we won't be possible to find a control suiteable for every clumsy huge finger person ... but we should try to do best we can ;-)
18:55 twoelk       maybe I should take of my gloves?
18:56 sapier       don't bother to do so just accept you're one of those we can't fix it for ;-)
18:56 sapier       <-- just joking of course ;-)
18:56 spillz       Try minecraft pocket or any of the other clones. on mc pe you can build or dig wherever you touch (if in range). Also want you start digging, moving around doesn't stop digging.
18:57 spillz       *Want = once
18:57 sapier       my tablet doesn't have play store access ... but if they can do it we'll be able to do so too
18:58 spillz       Re "not if high quality screen" that's just wrong. Note 2 has one of the finest screen available when it was released.
18:59 spillz       The problem is the sensitivity to movement is also extremely high, so you need to filter events you don't want to respond to
19:00 sapier       imho filtering events is responsibility of os not application
19:02 spillz       gotta work with the tools you have :)
19:02 sapier       my tool does work ;-)
19:02 sapier       but that's why I want you to test it
19:04 spillz       relevant: http://stackoverflow.com/questions/4324362/detect-touch-press-vs-long-press-vs-movement
19:06 sapier       well I use similar code for other things in mt right now ;-)
19:06 sapier       it's not a big deal to add the threshold
19:16 twoelk       stackoverflow?   - oh Android, not Vines :-(
20:07 sapier       touchscreen_threshold in latest binary version is setting for touch threshold, it's set to 20 can those with touch issues try if this is enough?
21:41 ShadowNinja  sapier: Is there a reason that you chose marshal over string.dump?
21:44 spillz       sapier: latest apk works much better, playable now :) will be good when you can touch to choose the node interact with or the node face to attach new node to
21:59 sapier       yes marshal is able to encode functions too
22:00 sapier       marshal should only be used in async by now
22:34 ShadowNinja  sapier: string.dump(function)
22:35 ShadowNinja  I don't mean minetest's dump(tbl), which isn't meant to be machine readable anyways.
22:36 sapier       does it work for arbitrary things?
22:36 ShadowNinja  Er, I didn't paste that correctly.
22:36 sapier       e.g. tables containing functions as well as function pointers?
22:36 ShadowNinja  sapier: No, just functions.  minetest.serializa could be extended to use it though.
22:37 ShadowNinja  sapier: Don't you only use to for serializing async callables?
22:38 sapier       well if you wanna do this you're welcome the less code the less chance for bugs ... but for what I've read getting this done in a performant way is not a simple task
22:38 ShadowNinja  It's a builtin Lua function, so it should be just about as fast as it gets.
22:39 sapier       you can try it but as I said for what I know marshall code is the only serialization version capable of doing function serialization too
22:40 sapier       I assume if it was as simple as using string.dump() others would've used this variant before