| 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 |
| 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/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: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/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: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/commit/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/.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 |
rootks4006351:/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] <InocudomVE-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-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:07 |
|
Evolykane joined #minetest-dev |
| 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: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/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.. |
| 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/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: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 |
