Minetest logo

IRC log for #minetest-dev, 2014-01-18

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:02 ShadowNinja Should I delete https://github.com/minetest/minete​st/pull/1096#issuecomment-32407007 and https://github.com/minetest/minete​st/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
00:44 Gethiox2 joined #minetest-dev
01:14 diemartin joined #minetest-dev
01:31 anadon joined #minetest-dev
02:02 Zeitgeist_ joined #minetest-dev
02:02 Zeitgeist_ joined #minetest-dev
02:07 mrtux joined #minetest-dev
02:56 bas080 joined #minetest-dev
03:35 mrtux joined #minetest-dev
03:43 mrtux joined #minetest-dev
03:45 ShadowBot joined #minetest-dev
04:02 khonkhortisan joined #minetest-dev
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.
04:30 kaeza joined #minetest-dev
04:31 kaeza joined #minetest-dev
04:32 anadon joined #minetest-dev
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/Mi​netest-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:49 ImQ009 joined #minetest-dev
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
05:53 Zeitgeist_ joined #minetest-dev
06:02 Miner_48er joined #minetest-dev
08:09 werwerwer_ joined #minetest-dev
08:22 bas080 joined #minetest-dev
08:44 BlockMen joined #minetest-dev
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:07 sapier joined #minetest-dev
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:03 e1z0 joined #minetest-dev
10:03 darkrose joined #minetest-dev
10:04 Exio4 joined #minetest-dev
10:06 OldCoder joined #minetest-dev
10:13 Exio4 joined #minetest-dev
10:14 Calinou joined #minetest-dev
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)
10:36 EvergreenTree joined #minetest-dev
10:37 EvergreenTree joined #minetest-dev
10:45 BlockMen left #minetest-dev
11:11 nore joined #minetest-dev
11:39 Jordach joined #minetest-dev
11:50 OldCoder joined #minetest-dev
11:55 VanessaE joined #minetest-dev
11:55 PilzAdam joined #minetest-dev
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:03 Amaz joined #minetest-dev
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/mi​netest/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:01 Zeitgeist_ joined #minetest-dev
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
14:28 zat joined #minetest-dev
14:28 harrison joined #minetest-dev
14:44 hmmmm joined #minetest-dev
15:08 Exio4 https://github.com/minetest/minetest/commi​t/ee0b8da844451509ff9afc07912f6b31cf12f40b​#diff-16525c326f5842e04cbdf0b3ae8254fcR648 shouldn't this be more like https://github.com/EXio4/minetest/commit/​1ad750b1b46956f6a28508d50776a6806ed7113f
15:10 NakedFury joined #minetest-dev
15:14 Yepoleb joined #minetest-dev
15:29 Gethiox3 joined #minetest-dev
15:30 bas080 joined #minetest-dev
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:40 rsiska joined #minetest-dev
15:43 init joined #minetest-dev
15:52 bas080 joined #minetest-dev
15:52 hmmmm joined #minetest-dev
15:52 VanessaE joined #minetest-dev
15:52 ShadowBot joined #minetest-dev
15:52 mrtux joined #minetest-dev
15:52 proller joined #minetest-dev
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 joined #minetest-dev
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 bas080 joined #minetest-dev
15:58 hmmmm joined #minetest-dev
15:58 ShadowBot joined #minetest-dev
15:58 mrtux joined #minetest-dev
15:58 proller joined #minetest-dev
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/.mine​test/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/.mine​test/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:20 Zeitgeist_ joined #minetest-dev
16:27 bas080 joined #minetest-dev
16:42 OldCoder joined #minetest-dev
16:52 VanessaE commit 5822c23c49ee9bbb686c470a42cc31f5193bcb9f
16:52 VanessaE smooth lighting for nodeboxes
16:53 VanessaE https://gitorious.org/minetest-clas​sic/minetest-classic/commit/5822c23​c49ee9bbb686c470a42cc31f5193bcb9f
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/ho​bbies/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-clas​sic/minetest-classic/commit/e4ad8ca​69883b0ffb0d790cbedfc6d57707705a7
17:07 Evolykane joined #minetest-dev
17:17 xyz yeah, both need to be merged
17:19 nore https://github.com/Novatux/min​etest/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:20 kaeza joined #minetest-dev
17:22 diemartin joined #minetest-dev
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:27 rubenwardy joined #minetest-dev
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 diemartin joined #minetest-dev
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:03 Calinou joined #minetest-dev
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/3e1ee4b​47fff1b48b916/raw/e9a7e9522cf69419b7​3acc1cae3752c04f473b4f/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/me​ta_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..
18:45 Calinou joined #minetest-dev
19:03 NakedFury joined #minetest-dev
19:16 diemartin joined #minetest-dev
19:16 us_0gb joined #minetest-dev
19:49 Miner_48er joined #minetest-dev
19:57 Zeitgeist_ joined #minetest-dev
19:57 Zeitgeist_ joined #minetest-dev
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...
20:53 Zeitgeist_ joined #minetest-dev
20:54 Zeitgeist_ joined #minetest-dev
20:58 salamanderrake joined #minetest-dev
21:21 Weedy joined #minetest-dev
21:21 salamanderrake joined #minetest-dev
21:21 Zeitgeist_ joined #minetest-dev
21:21 Miner_48er joined #minetest-dev
21:21 us_0gb joined #minetest-dev
21:21 NakedFury joined #minetest-dev
21:21 Calinou joined #minetest-dev
21:21 Evolykane joined #minetest-dev
21:21 bas080 joined #minetest-dev
21:21 proller joined #minetest-dev
21:21 mrtux joined #minetest-dev
21:21 ShadowBot joined #minetest-dev
21:21 hmmmm joined #minetest-dev
21:21 Exio4 joined #minetest-dev
21:21 rsiska joined #minetest-dev
21:21 Gethiox3 joined #minetest-dev
21:21 Yepoleb joined #minetest-dev
21:21 zat joined #minetest-dev
21:21 PilzAdam joined #minetest-dev
21:21 Jordach joined #minetest-dev
21:21 darkrose joined #minetest-dev
21:21 e1z0 joined #minetest-dev
21:21 werwerwer_ joined #minetest-dev
21:21 khonkhortisan joined #minetest-dev
21:21 pitriss joined #minetest-dev
21:21 kahrl joined #minetest-dev
21:21 Taoki joined #minetest-dev
21:21 specing joined #minetest-dev
21:21 BrandonReese joined #minetest-dev
21:21 IceCraft joined #minetest-dev
21:21 celeron55 joined #minetest-dev
21:21 Robby joined #minetest-dev
21:21 keesj joined #minetest-dev
21:21 ShadowNinja joined #minetest-dev
21:21 sfan5 joined #minetest-dev
21:21 Anchakor_ joined #minetest-dev
21:21 deltib joined #minetest-dev
21:21 OWNSyouAll joined #minetest-dev
21:21 VargaD joined #minetest-dev
21:21 MMN-o joined #minetest-dev
21:21 Kray joined #minetest-dev
21:21 xiong joined #minetest-dev
21:21 Ritchie joined #minetest-dev
21:21 nyuszika7h joined #minetest-dev
21:21 blaise joined #minetest-dev
21:21 xyz|imag1nary joined #minetest-dev
21:21 xrogaan joined #minetest-dev
21:21 yno joined #minetest-dev
21:21 lanxu joined #minetest-dev
21:21 eeew` joined #minetest-dev
21:21 daswort joined #minetest-dev
21:21 psedlak joined #minetest-dev
21:21 Sokomine joined #minetest-dev
21:21 dzho joined #minetest-dev
21:21 xyz joined #minetest-dev
21:21 hax404 joined #minetest-dev
21:21 VanessaE joined #minetest-dev
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/stor​e/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/buildcr​aft-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:49 iqualfragile joined #minetest-dev
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:22 AllegedlyDead joined #minetest-dev
23:41 cj joined #minetest-dev
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
23:56 nyuszika7h joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext