Time  Nick        Message
00:02 ShadowNinja Should I delete https://github.com/minetest/minetest/pull/1096#issuecomment-32407007 and https://github.com/minetest/minetest/pull/1096#issuecomment-32612146 ? Neither of them seem to be helpfull and relevant.
00:34 xyz         since when are we censoring the comments?
00:35 xyz         well feel free to delete mine if it makes you feel better
00:38 xyz         and before you say it's pointless: it has a point, it tells you that it may be a good idea to stop posting
04:10 VanessaE    xyz: dont shitpost.
04:11 VanessaE    just like you and certain others are always telling everyone else.
04:11 VanessaE    those ^^^^^ are shitposts are are utterly and completely unhelpful to the threads in which they're posted.
05:10 hmmmm       woohoo minetest!
05:10 hmmmm       what's been going on the past week
05:11 VanessaE    everything exploded :)
05:11 hmmmm       oh god
05:12 hmmmm       sapier's using native apis
05:12 hmmmm       when is NtQuerySemaphore initialized
05:13 hmmmm       see if I were him I'd just check if (!NtQuerySemaphore) { NtQuerySemaphore = ... } right before you actually call it
05:14 hmmmm       but the real solution is to avoid Win32's crappy semaphore objects altogether
05:14 hmmmm       no reason why multiple event waiting couldn't be used just as well
05:15 hmmmm       besides, nobody can build jthread as a standalone DLL, support for a separate jthread has been completely removed a long time ago.  it's nothing but its own directory full of source files at this point in time.
05:17 hmmmm       also why did sapier ever think that releasing a semaphore is the same as querying it, and where is GetValue ever used.. i don't see a valid use for that right off hand
05:22 VanessaE    wish I understood all that
05:22 VanessaE    in my day, multitasking was done by IRQs and flags
05:22 VanessaE    get off my lawn, etc.
05:27 xyz         VanessaE: uh oh how could I
05:27 VanessaE    eh?
05:29 xyz         how wrong of me to tell somebody he's being ridiculously stupid
05:29 VanessaE    xyz: unhelpful post is unhelpful.
05:30 xyz         unhelpful post was the one I quoted
05:30 hmmmm       alright
05:30 VanessaE    and yeah, fucking wrong.  if you wanna tell someone they're ridiculously stupid, then take it to email.  THAT thread was the wrong place for it.
05:30 hmmmm       before I start working on some new feature or enhancement, is there anything concerning me that needs immediate fixing?
05:31 xyz         what features do you have in mind?
05:31 xyz         VanessaE: yea
05:32 VanessaE    hmmmm: ask sapier about this server<->client out of sync error we've been fighting, he can explain it.  if the server's fast enough, it causes weirdness at the client end.  Some of the above that you were just looking at is related.
05:32 hmmmm       man, why's he gotta dick around with all the threading stuff
05:33 hmmmm       first off, is it a specific platform or does it happen for everything?
05:33 VanessaE    hmmmm: he succeeded in unnerfing media_FUBAR actually.
05:33 VanessaE    well I use debian on the server, and the clients are multiple platforms, so probably not
05:34 hmmmm       so it's a logic error
05:34 VanessaE    yeah
05:34 VanessaE    it's some sort of obscure race condition
05:34 hmmmm       what do you mean by 'fast enough'
05:34 VanessaE    the server can get just ahead of the client enough to send data when the client doesn't want it, I think
05:35 hmmmm       blocks?
05:35 hmmmm       or what
05:35 hmmmm       media?
05:35 VanessaE    I'm not exactly sure which part of the protocol it happens in
05:35 VanessaE    it's not the media or the block data, but in between
05:35 VanessaE    e.g. node/item defs or something
05:35 VanessaE    lemme check my logs
05:36 xyz         as for features, is it possible to have less locks in emerge?
05:36 hmmmm       what do you mean
05:36 hmmmm       locks aren't done unless they're absolutely necessary, ever
05:37 xyz         I see, alright
05:38 VanessaE    Jan 11 2014 14:40:52 <sapier>   you manage to get lua api running prior connection is completely established
05:38 VanessaE    Jan 11 2014 14:44:45 <sapier>   ok connection is established, but client <-> server intit isn't done
05:38 VanessaE    that's the crux of the issue, hmmmm
05:38 xyz         it's just according to profiler it waits most of the time in various envlocks in emerge threads
05:38 VanessaE    Jan 12 2014 09:04:54 <sapier>   scriptapi sees the client beeing there and immediatly queues those messages ... the init isn't even queued by that time
05:38 hmmmm       ahh.
05:39 hmmmm       dare i say it.. add another lock? :D
05:39 VanessaE    he's got a couple of patches on the horizon that may fix it, but they're non-trivial and ... not entirely free of regression potential, to put it mildly :)
05:39 hmmmm       xyz:  that is impossible to help.  sapier, kahrl, and i have been trying to figure out some rcu transaction setup to remove envlock
05:39 hmmmm       hey look, if you're able to figure out something, please do, it'll make minetest 5000x better
05:40 VanessaE    hmmmm: this bug I just filed against Worldedit might in fact be caused by that ^^^^^ issue, for example:  https://github.com/Uberi/Minetest-WorldEdit/issues/31
05:40 hmmmm       it's not like some specific mod can trigger the issue
05:40 hmmmm       it's a race condition
05:40 hmmmm       that's all
05:51 xyz         nah, minetest's good enough already
05:51 xyz         except some parts where it loads all player files (30k) into std::list and then iterates over it to match player to peer id
08:44 BlockMen    why is #1105 not merged yet?
08:44 ShadowBot   https://github.com/minetest/minetest/issues/1105 -- Small bugfix in menu select by vargad
09:14 BlockMen    sapier, ^
09:16 sapier      hmmm the semaphore count reading is a workaround to not have to change all of minetests old queue waiting at once. At lots of locations minetest asks for queue fill assuming it won't change until it fetches a element from it in next line. For those very special usecases it is used this is most likely fine, but it's not a generic solution.
09:17 sapier      What's wrong about using native api in os specific code? The other option is adding another mutex to protect reading the queue counter.
09:22 sapier      and yes vanessae's issue is a race condition because minetest doesn't care at all about client initialization order. It worked because of those huge locks causing single threaded operation in most locations. But removing those locks, or at least making them quite small, is one of our primary goals.
09:37 BlockMen    sapier, can #1105 be merged?
09:37 ShadowBot   https://github.com/minetest/minetest/issues/1105 -- Small bugfix in menu select by vargad
09:38 sapier      Yes merge it
09:44 BlockMen    done
10:21 VargaD      Is there any mobs mod that use pathfinder?
10:22 sapier      mobf does if you enable it, but pathfinder is to slow for contious usage
10:22 sapier      you can use it to find a path every now and then but don't try to use it in entity step :) I already did this misstake, no use to repeat it ;-)
10:28 proller     BlockMen, when third_person_view will be ready ?
10:30 BlockMen    proller, when i have added a function to register the animations at client when player has joined
10:30 BlockMen    but if u just want support default character its done (for a first implementation)
12:52 nore        do you think a callback such as minetest.register_on _block_load should be added?
12:55 sapier      Server tries to keep blocks in memory as long as possible so this may not be what modders expect it to be. I think chances block load and entity activity range could be quite easyly messed up. But it could be usefull for some situations too.
12:57 nore        it could avoid placing fake entities into blocks to know when they are loaded...
12:57 sapier      no it can't
12:57 nore        why?
12:58 nore        (perhaps a minetest.register_on_block_unload with it then...)
12:58 sapier      as I said blocks keep in memory as long as possible, if you want to spawn mobs in some regular base you can't rely on a block beeing unloaded fast enough
12:59 sapier      e.g. for mobs like vombies which spawn at night the on block load would be of no use at all
13:18 nore        second question: should meta_set_nodedef be rebased to work with new minetest, or do you think it should completely dropped?
13:21 sapier      I don't know what this is supposed to do can you explain to me?
13:21 nore        you can change the nodedef from the metadata of the node: textures, nodebox, etc
13:22 nore        however, it is quite old (like 1y or more), and depends onBKVL
13:22 sapier      do we have a usecase for it?
13:22 nore        a lot of mods would like/need it
13:23 sapier      to do what?
13:23 sapier      would this change allow changing nodedefinitions within game?
13:24 sapier      or at startup only as register node does?
13:24 nore        avoid to define 1000 nodes, do dynamic nodes where 100000 nodedefs would be needed
13:24 nore        well, it would allow to change the nodedef for one particular node by changing its meta
13:24 nore        (including textures/etcÃ
13:24 sapier      yes but nodedef is only sent to client once so we have a lot of additional concurrency issues
13:25 nore        I mean, the new nodedef is in meta
13:25 VanessaE    sapier: the model for a node gets stored within the map and only ever gets loaded/shown when that part of the map is loaded.
13:25 nore        so you don't need to change anything about sending it
13:25 VanessaE    so you define one node, set it somewhere, then you modify the node's model, textures, etc *in the map data* and store it there.
13:26 sapier      can you post a link to that pull request I guess I haven't really understood what this does
13:26 nore        https://github.com/celeron55/minetest/tree/meta_set_nodedef_2
13:26 sapier      so you can't decide about what you have in map based uppon node id?
13:27 nore        well, the objective is mainly about the visuals
13:28 nore        I don't know if you can change the other things too
13:28 sapier      I think about steps for example, if I understood correct you could have a node "stone" which is shown as half a node and another node "stone" which is shown as node 2 blocks high?
13:28 nore        yes, you could
13:29 sapier      that'll break all mods that need to know about map
13:30 nore        do you think so?
13:30 sapier      of course, how should a mob decide if it's ok to jump to a node if it can't be sure it's shown the way it's defined right now?
13:30 kahrl       that particular example can already be done with a leveled nodebox
13:31 sapier      so we add more bugs because we already have one in there kahrl?
13:31 kahrl       what?
13:32 sapier      if this can be done with nodeboxes right now we need to give mods a way to read the current state of that thing,
13:32 sapier      instead of adding another case where this will result in undefined behaviour
13:32 kahrl       well you check the static nodedef and the meta nodedef
13:33 kahrl       if you don't it's a bug in the mod and not in the engine
13:33 sapier      of course I can always check 500 additional things
13:34 sapier      what are mod defs good for if they are just a "suggestion"
13:34 kahrl       that's one of the reasons it was never added
13:34 sapier      -mod defs + node defs
13:34 kahrl       making mesh generation much slower because everything has to be checked twice
13:34 VanessaE    or your mod could just store some byte in the node's metadata when it defines that particular node, that says "ok, this node shaped like X, has textures Y and Z"...
13:35 VanessaE    then it becomes trivial to decide what it is.
13:35 sapier      yes of course I can implement collision detection in lua too  ;-)
13:35 VanessaE    if you're about to bloat up that single node's entry in the map, a few more bytes isn't that egregious
13:35 sapier      actually I do this already but I'd love to get rid of it
13:36 xyz         nore: I'd like to see it merged too
13:36 sapier      it's a decision either more node id's or more complex control flow
13:36 xyz         but lol another serialization format
13:36 sapier      node id's are a matter of memory, control flow a matter of speed
13:37 nore        sapier, sometimes node id's are not enough
13:37 sapier      imho this is a bug
13:38 sapier      a node is defined as a static object if it's supposed to change shape it's no longer a node
13:38 nore        (btw: textures for each box of a nodebox could be useful too...)
13:38 kahrl       torches are not nodes?
13:38 VanessaE    +1000000000
13:38 sapier      of course we can add all those dynamic things but in the end we will end up with nodes == entity
13:38 VanessaE    (nodebox textures)
13:40 xyz         then your mob spawners are nodes as well
13:40 sapier      separate textures for nodeboxes will have a major performance impact
13:40 VanessaE    why would they?
13:41 VanessaE    if they do, you're doing it wrong :P
13:41 sapier      no mob spawners are activeobjects ... sadly there are no server only active objects right now
13:41 xyz         just saying this argument never works
13:42 sapier      no it's a matter of count, mapping texture once is less work then mapping twice 3 times 4 times 100 times, doing this for 100 nodes ... calculate yourself
13:42 VanessaE    what happened to "the video card doesn't care how many textures there are"?
13:43 nore        sapier, perhaps, but then make it an option for each node
13:43 VanessaE    I distinctly remember someone here making that claim not long ago.
13:43 nore        i.e.: that node needs separate textures, that one doesn't
13:44 sapier      I'm not that used to video programming, maybe video cards have optimizations for this ... but it's not a matter of texture count but mapping to some object ... which is something completely different
13:45 VanessaE    which apparently that doesn't matter *either*
13:45 sapier      but maybe this can be done in a fast way e.g. by dynamicaly creating a model and a mapped single texture from the individual ones ... but instead of doing so I'd add a node type model and make mod creators do the mapping work
13:45 VanessaE    it's the number of faces that matters
13:45 sapier      nore sorry don't know what you're pointing at right now
13:46 VanessaE    so whether you have a thousand nodes or a nodebox-based node with a thousand cuboids in it, the number of textures you use between them all will take about the same amount of time to process, or at least that's how it's supposed to work if it's done right
13:46 nore        I mean, about nodebox textures
13:46 VanessaE    (and if you put a thousand cuboids in it, you're insane, but that's a different issue_)
13:46 sapier      I guess for the multitexture nodeboxes we will find a way to add it, but this is something completely different form changeable node defs
13:46 nore        you could add a field to nodedef that would mean "this node need textures for each box" or "that node only needs one texture"
13:47 VanessaE    sapier: yes, of course it's a different issue,
13:47 nore        yes, of course it is
13:47 VanessaE    but they're both things we need
13:47 nore        (even changeable node defs could not allow it)
13:47 sapier      there are a lot of things we need but we can't do all at once ;-)
13:48 sapier      I suggest adding a nodetype model to solve that issue but I'd like to here from someone really understanding graphics if this really is a good idea
13:48 VanessaE    nodetype model?
13:48 VanessaE    you model drawtype?
13:48 VanessaE    nodemodel drawtype* ?
13:48 sapier      ahh yes
13:48 VanessaE    yes, that would solve the per-box textures issue nicely.
13:49 sapier      imho nodeboxes are just simple models, but as people keep making them even more complex the "simplicity" is almost lost
13:50 sapier      yet vanessaE you already experienced what usage of complex models for nodes results at
13:51 VanessaE    yep.
13:51 VanessaE    however,
13:51 VanessaE    much of that is also deficiencies in what the client is doing with those models too
13:51 sapier      think about someone adding a dirt node model with 2000 faces ;-)
13:51 VanessaE    the spawn on my Creative gets a rather low FPS because it has lots of underground pipes....that aren't visible.
13:51 VanessaE    yet they're being fed to the render pipeline == slowing the thing down
13:53 sapier      yes that's a bug but it illustrates the effect of complex nodes
13:55 VanessaE    yep
13:58 Exio4       what overhead is worse, changing a block and all the shit there to another and so on, or just doing stuff directly in the metadata?
13:58 Exio4       the modders will still use 64 nodes for that "thing" and change it there
13:58 sapier      metadata
13:59 Exio4       why?
13:59 sapier      because if you can't rely for node defs to be valid you have to check the metadata everytime while they will be empty in 99.99%
14:00 sapier      so you add overhead in regular case to improove handling in some very very special cases
14:02 nore        sapier, then perhaps add a "can_be_modified_with_meta" field
14:02 nore        (to nodedef)
14:02 sapier      doesn't change the fact you need to check it
14:03 sapier      it's a small check but it's added in 100% of cases
14:03 sapier      1000....000 water drops will still fill a lake
14:04 nore        is checking a single bool for all nodes that slow?
14:04 sapier      if you do it 10000 times a second yes
14:05 Exio4       the whole algorithm is fucking slow right now (mesh gen)
14:06 sapier      fix it ;-)
14:06 Exio4       i don't know shit aboug graphics
14:06 Exio4       about*
14:07 sapier      nore it's just a matter of numbers, if you have 128x128x128 nodes in visible range even a single operation is relevant
14:07 Exio4       also sapier, how big would be the performance "hit"?
14:08 sapier      hard to say without benchmark but on things done that often I'm usually very carefull
15:08 Exio4       https://github.com/minetest/minetest/commit/ee0b8da844451509ff9afc07912f6b31cf12f40b#diff-16525c326f5842e04cbdf0b3ae8254fcR648 shouldn't this be more like https://github.com/EXio4/minetest/commit/1ad750b1b46956f6a28508d50776a6806ed7113f
15:36 sfan5       Exio4: IIRC the burningsvideo software driver supports glsl
15:38 Exio4       do you have an x8 overclocked to 9ghz?
15:38 Exio4       or any hardware that can handle the shaders via software
15:53 VanessaE    ok, question about minetest_game that's got me confused.
15:53 VanessaE    did we ever add anything to the engine that can "un-register" a recipe?
15:54 PilzAdam    IIRC no
15:54 VanessaE    didn't think so.
15:54 VanessaE    ok, so:
15:54 VanessaE    http://pastebin.ubuntu.com/6774759/
15:54 VanessaE    this is the bronze recipe from _game
15:55 VanessaE    and this is what's on my survival server (I copypasted that from my live game).
15:55 VanessaE    it's just vanilla mt_game
15:55 Jordach     VanessaE, you sure it's not moreores or technic?
15:55 VanessaE    is there something wrong with that code that's not letting that recipe work?
15:56 VanessaE    [01-18 10:55] <Jordach> VanessaE, you sure it's not moreores or technic?
15:56 VanessaE    [01-18 10:55] <VanessaE> is there something wrong with that code that's not letting that recipe work?
15:56 VanessaE    [01-18 10:56] <VanessaE> Jordach: moreores' bronze recipe still works.  that's what's got me confused.
15:57 PilzAdam    minetest.register_on_craft() can modify the output of a craft
15:57 VanessaE    ahhhhhhhhh
15:57 VanessaE    that must be why
15:58 VanessaE    hm...
15:58 VanessaE    nope, nothing anywhere in my game uses that call.
15:58 nore        VanessaE, technic does
15:59 VanessaE    root@ks4006351:/home/minetest/.minetest/games/vanessae_game/mods# grep -ir "minetest.register_on_craft()" *
15:59 VanessaE    (no results)
15:59 PilzAdam    -)
15:59 nore        (it uses minetest.register_on_craft_predict only, which will prevent a craft if returns ItemStack(""))
15:59 VanessaE    oh fuck
15:59 VanessaE    I feel stupid
15:59 VanessaE    ()
15:59 nore        1. -> it redefines the craft to give "technic:nothing"
16:00 nore        2. -> any craft that should give technic:nothing is cancelled
16:00 VanessaE    nope.avi
16:00 VanessaE    root@ks4006351:/home/minetest/.minetest/games/vanessae_game/mods# grep -ir "register_on_craft" *
16:00 VanessaE    (no results)
16:01 nore        it is register_craft_predict IIRC
16:02 VanessaE    ah, yep there it is.
16:02 VanessaE    ok, that answers that question
16:02 nore        (btw, why was it a problem?)
16:04 VanessaE    it wasn't a problem, per se - merely a source of confusion.  a user on my server reported that that recipe didn't work at all, I looked it up, went over the code, checked in the craft guide -- which by the way, still shows a valid recipe -- then found that the old two copper, one tin recipe still worked, and came away more confused then I went in.
16:04 VanessaE    it looked, on the surface, like someone had figured out how to "unregister" a recipe.
16:05 nore        (hmmm... craft guide should be updated)
16:06 VanessaE    nore: that said, I think the user reported having lost some copper in the attempt to craft the invalid recipe, btw.  may want to look into that
16:06 VanessaE    --> #minetest
16:07 VanessaE    sorry for the offtopic chatter
16:11 VanessaE    now for something on-topic
16:11 VanessaE    darkrose: *poke*
16:11 VanessaE    [01-18 11:10] <Inocudom@VE-C> VanessaE, did you know that in Minetest Classic. nodeboxes have smooth lighting too?
16:13 darkrose    o.0
16:16 VanessaE    when did you fix that?
16:16 darkrose    couple of months back
16:52 VanessaE    commit 5822c23c49ee9bbb686c470a42cc31f5193bcb9f
16:52 VanessaE    smooth lighting for nodeboxes
16:53 VanessaE    https://gitorious.org/minetest-classic/minetest-classic/commit/5822c23c49ee9bbb686c470a42cc31f5193bcb9f
16:53 VanessaE    in case anyone wants to take a look at the code
16:53 xyz         how visible is the change and does it matter if we have shaders anyway?
16:53 VanessaE    xyz: um...
16:54 VanessaE    think, this:  http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/homedecor1.png
16:54 VanessaE    (the ceiling)
16:54 VanessaE    compare to the floor or walls.
16:54 VanessaE    (except those are signlike nodes.  same effect though)
16:57 xyz         aha, so that's what it's for
16:57 VanessaE    yes, or so I presume.
17:02 xyz         yea, you'll have to find someone to port it
17:02 VanessaE    merely pointing it out.
17:02 xyz         darkrose: is it ok to take those patches under lgpl?
17:02 darkrose    sure
17:03 darkrose    yeah, carpeted floors that looked like that roof were the inspiration
17:04 VanessaE    darkrose: also looks like you did the same for some other drawtypes?
17:04 VanessaE    https://gitorious.org/minetest-classic/minetest-classic/commit/e4ad8ca69883b0ffb0d790cbedfc6d57707705a7
17:17 xyz         yeah, both need to be merged
17:19 nore        https://github.com/Novatux/minetest/tree/meta_set_nodedef_2
17:19 nore        ^ it works, but it is no better than before... there is still work to do
17:19 VanessaE    "something"
17:19 VanessaE    heh
17:20 VanessaE    http://xkcd.com/1296/
17:23 nore        moreover, it has the problem that it is quite slow... don't know why, though
17:23 nore        (I mean, mesh creation)
17:23 xyz         more serializers!
17:24 nore        yes, you must be right
17:24 nore        anyway, thoughts on it?
17:26 xyz         thoughts? remove bkvl
17:26 nore        but why does it depend on it anyway?
17:31 xyz         well I guess celeron55 was hacking around and thought that it may be a good idea to rewrite contentfeatures in an extensible way
17:31 xyz         I want to do this thing with msgpack, every packet will be serialized in a similar way
17:32 hmmmm       oh god ;;
17:32 xyz         nore: does it really depend on it?
17:32 nore        well, it does use it for sure
17:32 nore        I guess without it, it still could work... not sure, though
17:32 hmmmm       stop breaking protocol compatibility when it's not necessary and you can do a better job anyway
17:33 xyz         hm?
17:33 xyz         nore: yea, that's what I meant
17:49 nore        xyz, it looks like it does not need BKVL
17:49 xyz         yup
17:49 xyz         I was sure it didn't
17:49 nore        however, it is no faster without it... each time a block is changed, it creates a new mesh
17:49 nore        and that takes time
17:49 xyz         of course it wouldn't be faster
17:50 nore        however, there is another problem
17:51 nore        server needs to serialize ContentFeatures in the meta, however, the client needs then to have the same protocol version
17:51 xyz         same?
17:52 nore        well, or more recent
17:52 xyz         why's that a problem?
17:52 nore        if server is more recent than client, client won't be able to read the meta, will it?
17:52 xyz         I think it'll just ignore this field, why should it do something else?
17:52 VanessaE    wouldn't this be another thing that belongs in the optional area of the protocol?  client doesn't support it?  ok, it just sees the "default" version of the node
17:52 nore        wasn't there something about compatibility?
17:52 xyz         it's just another field in the metadata
17:52 nore        hmm... yes, you may be right
17:53 xyz         (didn't read the code)
17:54 celeron55   the issue with meta_set_nodedef is that the contentfeatures (aka nodedef) serialization format is not ready for on-disk storage
17:54 nore        another problem I don't understand: with that code, it now takes a few seconds EACH TIME a block is placed/removed to update the mesh
17:54 VanessaE    a few seconds??
17:54 nore        well, a least 1 second
17:55 celeron55   also it's incredibly bloated and people will be surprised by that for sure as they're changing like one boolean and that makes 700 bytes to be stored for the node
17:55 xyz         uhm, what was the usecase for this?
17:55 celeron55   meta_set_nodedef has the "bkvl" experiment in it to try to make nodedef disk-worthy, but it should be replaced with msgpack if it's to be used
17:56 nore        also, something I discovered: why isn't ContentFeatures::serialiaze marked as "const"?
17:56 celeron55   xyz: well, changing the look of a node without changing the node id
17:56 xyz         yea, I figured out as much, but what was the actual use case?
17:56 celeron55   mesecons maybe
17:56 celeron55   somebody wanted it
17:57 celeron55   with meta_set_nodedef you can also eg. make a tool that allows you to turn any node into stairs 8)
17:57 celeron55   it's funny
17:57 xyz         I remember this!
17:57 celeron55   see grass? click it, it becomes stairs; see a pipe? now it's pipestairs
17:57 celeron55   it's funny but bloated
17:58 PilzAdam    in-game nodebox editor!
17:58 nore        celeron55, any idea about what causes the slow mesh making?
17:59 celeron55   well, if it makes mesh making slow, that's no surprise because it's implemented in a way that adds an extra virtual wrapper interface or two between the mesh generator thread and gamedef and nodedef and stuff
17:59 celeron55   because there is no other reasonable way to get all the changes into mesh generation without such
17:59 celeron55   (the reason could be something else though; i don't remember what it exactly does)
18:00 celeron55   also collisions work properly with it
18:00 celeron55   and also there was something about lighting that it had to do and whatever
18:01 nore        maybe add a field to node such as "can_be_modified" then?
18:01 celeron55   it's probably the biggest and nastiest hack i have ever created in minetest
18:01 nore        (for faster meshgen)
18:01 nore        celeron55, it took >2 hours to get it working on the new version, so it is indeed big
18:01 celeron55   dunno, i really don't want to touch it now
18:04 celeron55   in my opinion what needs to be done to it to make it upstream-worthy is a serialization format that we can expect to support through versions and that stores only the difference from the original node definition
18:04 celeron55   or something like that
18:05 celeron55   probably with msgpack that can be doable
18:05 celeron55   that in addition to fixing performance if it needs to be fixed, and agreeing or disagreeing to the general design of it
18:06 xyz         maybe the api for it should be changed
18:07 xyz         or, well, function to add "override' to node should be added
18:07 xyz         not sure why it works the way it does now
18:08 xyz         I'd expect to call a method passing node, position and table of overrides
18:08 hmmmm       what's the fascination with messagepack?
18:08 xyz         and that's all that gets stored, so we can blame mod makers if something goes too bloat
18:09 hmmmm       if we do it the "protobuf" way, you can have reverse compatibility and not waste any data on key storage at all
18:09 xyz         hmmmm: it's simple, supports base types (vectors, maps, strings, floats, etc) and is easy to extend
18:10 xyz         easy to extend: https://gist.github.com/xyzz/3e1ee4b47fff1b48b916/raw/e9a7e9522cf69419b73acc1cae3752c04f473b4f/gistfile1.cpp
18:10 xyz         (I wrote this!)
18:10 hmmmm       god wtf
18:11 hmmmm       i don't know, it just seems like too much to solve a relatively simple problem
18:11 hmmmm       what's so hard with having a single packet in the beginning of the connection to negotiate key positions within messages
18:12 hmmmm       and then if you want to grab the "foobar" value from within the TOCLIENT_WHATEVER packet, you look up the position within the message that was negotiated from a map and just extract it that way
18:13 hmmmm       for things that come after variable length fields, you can specify that too, that it comes after X amount of variable length fields, so you know to skip those before grabbing the correct value
18:14 hmmmm       outdated clients can ignore this initial key:value position handshake message, outdated servers never send it
18:14 hmmmm       and without, they extract values from the messages the same way they have since freaking 4.0
18:14 hmmmm       0.4.0 rather
18:14 nore        https://github.com/Novatux/minetest/blob/meta_set_nodedef_3/src/mapblock_mesh.cpp#L389 <-- this is the performance killer
18:21 celeron55   hmmmm: this is not about network protocol, this is about on-disk storage
18:21 hmmmm       there is no real difference between the two
18:22 celeron55   there is
18:22 hmmmm       such as?
18:22 xyz         hmmmm: well, then do it this way
18:22 xyz         it's not like I'm pushing those changes into Minetest
18:23 celeron55   i have gotten enough from field index based randomly versioned formats in my life; formats that have named fields are much more easily extendable and much more easily compatible
18:23 hmmmm       ..o.k.
18:23 celeron55   but i'm not implementing it in any case
18:25 celeron55   if the one who implements it believes that it won't cause any trouble in the future, i guess it's fine
18:26 celeron55   and again, i am not talking about networking
18:27 celeron55   this stuff just happens to be transferred over network in addition to other things; also the version of it cannot really be modified when it is transferred over network so an older client should preferably be able to understand a newer format)
18:27 celeron55   -)
18:28 celeron55   (not the current versions of clients of course though)
18:29 hmmmm       if an older client comes across data that's serialized in a newer format, it should ignore the new data.  there's no excuse for why this shouldn't be the case.  it's pretty obvious, i'd think
18:29 celeron55   how about two branches of development like minetest and freeminer? freeminer has already added new fields to the end of some packets that minetest won't add because they're badly designed
18:30 hmmmm       ugh
18:30 xyz         no worry, we're breaking the compatibility anyway
18:30 hmmmm       do the people developing freeminer not see the danger in randomly slapping features on
18:32 xyz         we do that? I didn't know
18:33 xyz         but if you say it like that..
20:24 ShadowNinja I updated the changelog.  Please update it yourself when needed.
20:32 ShadowNinja If someone has some time the "0.4.7 -> 0.4.8" section still needs to be updated...
21:21 ShadowNinja Or I'll do it...  Old entries seem to be in the past tense.  What tense should be used?
21:23 ShadowNinja Some things aren't in the past sense, because they're hard to change to the past sense.
21:24 PilzAdam    Calinou originally used the past tense
21:38 Calinou     past tense sounds better
21:38 Calinou     that's what almost all changelogs do, too
21:38 PilzAdam    and it prevents people from copy-pasting from commit messages ;-)
21:48 xyz         hmmm... I wonder if google remote-deletes apps from devices after removing them from play store
22:01 VanessaE    xyz: no, it does not.
22:02 VanessaE    or at least, my copy of buildcraft was still there and usable after it was pulled
22:06 xyz         it seems it went down again
22:07 xyz         anyway, I wanted to say that I'm no longer going to battle them with DMCA reports because fuck it
22:08 VanessaE    interesting.  worldcraft is gone too
22:09 VanessaE    well now's your chance to get freeminer up (good luck with the name though)
22:09 xyz         dunno why
22:10 xyz         I stopped emailing google after they asked for "additional information from you in order to continue investigating" the second time
22:10 VanessaE    looks like the other variants got yanked also.
22:10 xyz         yeah, all three I reported went down
22:10 xyz         and developer webpage is not available either
22:10 xyz         https://play.google.com/store/apps/developer?id=Kevin.de
22:10 xyz         inb4 another account
22:15 proller     2-5 days and start search for new accounr
22:15 VanessaE    seems to still be available for iOS though
22:15 VanessaE    https://itunes.apple.com/us/app/buildcraft-multiplayer-block/id740372768?mt=8
22:16 xyz         > builde it
22:16 VanessaE    interesting they still quote me in the screenshots, but they can't even spell the damn quote right :)
22:16 VanessaE    exactly
22:16 xyz         the sad truth is that there are not even plans to support iOS
22:17 xyz         even OS X is not supported
22:17 xyz         so in the end we can conclude
22:17 xyz         Minetest is licensed under permissive license, like MIT or BSD
22:18 xyz         I mean, it's not, but nobody gives a shit
22:24 VanessaE    "There are two kinds of people in business: the quick, and the dead."
22:25 VanessaE    while this ain't a business, the quick-or-dead part definitely applies.  at least as far as mobile is concerned.
22:26 VanessaE    I know c55 was working on his build, and you had the thing you were doing.  you guys are getting your asses whipped by some snot-nosed kid in china who couldn't even follow the project's license. come on already.
22:26 xyz         uh?
22:27 xyz         the FM android build is put on hold
22:27 xyz         until we do enet/msgpack
22:27 VanessaE    ...
22:28 xyz         maybe this could change, but this really is not a discussion for this channel, and some people are easily annoyed when we talk about FM here
22:29 VanessaE    maybe I'm just less isolated from my userbase, but I would have to guess than at least a quarter of the folks in the Inchra servers are mobile.
22:29 VanessaE    no, they're only annoyed when proller talks fm :P
22:30 proller     FM rulez! MT sucks!
22:30 proller     also joining to your server takes years..
22:31 VanessaE    proller: no one else is having problems.  fix your busted network code.
22:31 VanessaE    :P
22:33 proller     and blocks loading 10-30 seconds when stucking to it
22:33 proller     but its okay for mt
22:33 ShadowNinja Alright, I just finished updating "0.4.7 -> 0.4.8". Someone else can change the tenses...
22:35 VanessaE    xyz: now THAT is not a discussion for this channel ^^^^^ but as for Android/iOS builds, that's a discussion for here simply because engine changes are needed to make the game/client run on those devices.
22:35 VanessaE    or at least that how I'd have decided it.
22:36 proller     ban me
22:36 ShadowNinja I was thinking about a +q actually...  ;-)
22:39 VanessaE    xyz: my point is, you CAN'T wait on the Android build.
22:39 VanessaE    it would be incredibly unwise to wait
22:40 VanessaE    you've got an opening right now.
22:40 VanessaE    while the illegal clients are gone
22:40 VanessaE    get a real one up
22:50 ShadowNinja I see no reason for Enet/TCP/improved UDP to delay a Android client.  They can be updated when it is added.
22:50 ShadowNinja But there should be a Minetest client, not just a Freeminer client.
22:55 xyz         VanessaE: yea, I can see the point
22:59 xyz         I guess I could give it a try
23:41 cj          hey folks
23:41 cj          my daughter wanted to play minecraft but we couldn't scrape together enough dollars
23:41 cj          so I found minetest
23:41 cj          and built it for ubuntu lucid
23:41 PilzAdam    cj, chit-chat goes to #minetest
23:42 cj          the performance is awful.  Can someone help me dig in to it to find out whether it's failing to draw to a hardware opengl surface?
23:42 cj          thanks, PilzAdam.  I'll keep that in mind.
23:42 cj          performance metrics.  I needs them.  where is the code spending most of its time?
23:43 cj          what tools do you folks use to test performance?
23:43 cj          how do i know what drawable the engine is using?
23:44 ShadowNinja cj: There is some info in F5, F6, and I think F8.  The renderer is in the conf.
23:44 ShadowNinja But, take this to #minetest.  There are more people there too.
23:46 cj          roger