| Time |
Nick |
Message |
| 00:00 |
kahrl |
hmm now it is 10-15 FPS |
| 00:01 |
kahrl |
it settled at 10 FPS (range 9-12) |
| 00:02 |
VanessaE |
11fps for me and it's dropping slowly. |
| 00:03 |
kahrl |
yeah, it is dropping, now I'm starting to get 8 FPS sometimes |
| 00:03 |
VanessaE |
this is definitely not the contents of the world doing it |
| 00:06 |
kahrl |
have you tried making all the pipes drawtype normal? |
| 00:06 |
VanessaE |
not yet, but it isn't the pipes doing it |
| 00:06 |
kahrl |
sure? |
| 00:06 |
VanessaE |
normally I get 20-23 fps around the spawn. Now, abotu 11 |
| 00:07 |
VanessaE |
with no changes whatever to the contents of the world near the spawn, nor to the pipeworks mod |
| 00:08 |
kahrl |
the alpha trees aren't the problem either? |
| 00:08 |
VanessaE |
what alpha? |
| 00:08 |
VanessaE |
you mean the leaves? |
| 00:09 |
kahrl |
the tree with alpha glass around it |
| 00:09 |
VanessaE |
nope, that's been there forever |
| 00:09 |
kahrl |
with an actual alpha texture? |
| 00:09 |
VanessaE |
yep. |
| 00:09 |
VanessaE |
this performance issue has been going on for a few weeks at most, but that tree has been there at least for a couple months |
| 00:09 |
kahrl |
how was this done? some abuse of liquid drawtype? |
| 00:09 |
kahrl |
because alpha was only added recently |
| 00:09 |
VanessaE |
nope, use_texture_alpha + shaders, some stuff hmmmm added. |
| 00:10 |
kahrl |
well that's not forever :P |
| 00:10 |
VanessaE |
ok maybe the tree's not as old as I suggest, but it's been there long before the performance problems started. |
| 00:10 |
kahrl |
when was that? |
| 00:10 |
VanessaE |
a couple of weeks maybe |
| 00:16 |
VanessaE |
perhaps less |
| 00:16 |
VanessaE |
I get so frustrated at such things I lose track of when it happens. |
| 00:17 |
kahrl |
did you get a lot of 'Meshbuffer ran out of indices' at the spawn before I fixed that? |
| 00:17 |
VanessaE |
no actually. |
| 00:17 |
VanessaE |
I didn't. |
| 00:17 |
VanessaE |
or only very rarely. |
| 00:18 |
VanessaE |
in fact, whether I got those errors or not was rather random |
| 00:19 |
VanessaE |
I'd like to speculate on what I think it is, but I can't remember the terminologu. |
| 00:19 |
VanessaE |
terminology* |
| 00:19 |
kahrl |
"thing" and "stuff" always works |
| 00:19 |
VanessaE |
where the world should be broken up into manageable chunks from irrlicht's perspective, but isn't |
| 00:20 |
VanessaE |
scene nodes or something like that? |
| 00:20 |
kahrl |
mapblocks? |
| 00:20 |
VanessaE |
no, not from MT's perspective, but from irrlicht's |
| 00:20 |
kahrl |
I see. Well there is only one (important) scene node |
| 00:21 |
VanessaE |
I'm wondering if maybe we're just "overloading" irrlicht? |
| 00:21 |
kahrl |
no, because all irrlicht does it calling the draw function of ClientMap |
| 00:21 |
VanessaE |
hm. |
| 00:22 |
kahrl |
which renders the meshbuffers of the world in some order, the same would happen if it were in separate scene nodes |
| 00:22 |
VanessaE |
ok, so that really doesn't matter then |
| 00:22 |
VanessaE |
so it comes down to how *much* is being rendered,. |
| 00:22 |
VanessaE |
rather than how it's packaged/partitioned. |
| 00:23 |
kahrl |
it does matter a bit, that's why meshbuffers are sorted by material |
| 00:23 |
VanessaE |
I've returned to the spawn, loaded up all of the surrounding map, and now it's rendering at ~21 fps. |
| 00:23 |
kahrl |
but the quantity of the geometry data is the major thing |
| 00:23 |
VanessaE |
where earlier (half hour ago?) I was getting half of that |
| 00:24 |
Exio |
maybe something stacking up somewhere? |
| 00:24 |
kahrl |
fewer players around? |
| 00:24 |
VanessaE |
I think so - the longer I run my client, the worse my fps gets until I am forced to restart it. |
| 00:24 |
VanessaE |
exio ^^^ |
| 00:24 |
VanessaE |
kahrl: doubt it, but it may have something to do with meshes in general |
| 00:26 |
VanessaE |
there's been some speculation that the entity duplication bug may be at fault. |
| 00:26 |
kahrl |
possible |
| 00:27 |
Exio |
any way to check entities around? |
| 00:27 |
VanessaE |
fps dropping to 18 now, and I haven't moved or turned for the past 4 minutes. |
| 00:27 |
Exio |
the number of entities* |
| 00:27 |
VanessaE |
Exio: there is a Lua function for that, but nothing like a server command |
| 00:27 |
Exio |
and debug screen? |
| 00:27 |
Exio |
and i mean in a visible range and so on |
| 00:28 |
Exio |
MC haz it! (yes, kill me!) |
| 00:28 |
Exio |
:P |
| 00:28 |
kahrl |
I'll let PA do it then :P |
| 00:28 |
VanessaE |
ah, animated meshes, 21 |
| 00:28 |
VanessaE |
(f6, page 1) |
| 00:29 |
kahrl |
does f6 look weird for anyone else? |
| 00:29 |
VanessaE |
define weird |
| 00:29 |
kahrl |
no newlines or word wrapping |
| 00:29 |
VanessaE |
nope, works fine for me. |
| 00:29 |
kahrl |
huh. |
| 00:30 |
Exio |
same here kahrl |
| 00:30 |
kahrl |
I recently enabled freetype, does that do it? |
| 00:31 |
VanessaE |
no idea, freetype and I don't get along :) |
| 00:31 |
Exio |
my build has freetype enabled; too |
| 00:35 |
kahrl |
indeed freetype is the cause |
| 00:35 |
kahrl |
well the freetype support code in minetest |
| 00:39 |
VanessaE |
kahrl: trying your suggestion of swapping nodebox for normal, I only see roughly a 5 fps difference between the two. |
| 00:40 |
VanessaE |
max 24 fps on the server as you saw it, averaging 31 fps in singleplayer on the same map, standing in the same spot. All nodebox drawtypes have been replaced with "normal". |
| 00:40 |
VanessaE |
it's varying widely though, just standing here. 31...33...34...30.. |
| 00:41 |
VanessaE |
seems to want to settle at around 32, which is ~6 fps higher than I'd get under "normal" circumstances. |
| 00:42 |
VanessaE |
pan over a little, drops to about 27. |
| 00:43 |
kahrl |
I'm used to 50-60 so all of these are low for me :P |
| 00:43 |
VanessaE |
looking at the buildings north of the spawn with the "B I" and "B C" signs on them |
| 00:44 |
VanessaE |
solid verticies drawm, about 125k, so clearly less with all cubes than with nodeboxes, but the actual performance doesn't follow. |
| 00:44 |
VanessaE |
154k.. |
| 00:44 |
VanessaE |
170k there. |
| 00:45 |
VanessaE |
still think nodeboxes are the root cause of my performance issue? :) |
| 00:45 |
Exio |
what the fuck? |
| 00:46 |
VanessaE |
this is with a view distance of 50 and 256px HDX textures. |
| 00:46 |
VanessaE |
on an HD6870 video card, which I am sure you know should be able to pull off far more. |
| 00:46 |
VanessaE |
Exio: what? |
| 00:47 |
Exio |
170k solid vertices? |
| 00:47 |
VanessaE |
Exio: yep. |
| 00:48 |
VanessaE |
Exio: it explodes into the 500k range when I'm on the live map/unmodified game |
| 00:58 |
VanessaE |
confirmed. 475k vertices and ~22 fps on the live map/unmodded game with the same view distance of 50 and 256px textures. |
| 01:10 |
kahrl |
Anyone who gets the mesh update thread error regularly want to try something? |
| 01:11 |
kahrl |
https://github.com/kahrl/minetest/commits/latemedia |
| 01:11 |
kahrl |
in particular https://github.com/kahrl/minetest/commit/8fd1e9b56a90d46e624da2da4ad7a9d93d2a1c88 |
| 01:12 |
kahrl |
(this should not break compatibility with any server) |
| 01:13 |
kahrl |
brb |
| 01:25 |
|
BlockMen left #minetest-dev |
| 02:06 |
|
ecube joined #minetest-dev |
| 02:14 |
VanessaE |
kahrl: that glitchy water seems to be restricted to irrlicht 1.8 - it isn't bugging out when the client is built against irrlicht 1.7.2. |
| 02:16 |
VanessaE |
one thing about liquids that does need fixed is that certain angles of flowing water have the animation running in the wrong direction. |
| 02:56 |
|
dexter0 joined #minetest-dev |
| 04:11 |
|
ssieb joined #minetest-dev |
| 04:15 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 04:47 |
|
neko259 joined #minetest-dev |
| 06:16 |
|
darkrose joined #minetest-dev |
| 06:16 |
|
darkrose joined #minetest-dev |
| 06:46 |
kahrl |
updated my latemedia commit: https://github.com/kahrl/minetest/commit/bd5123776a15e9f0bbff915e0b57be2747e5ac2b |
| 06:46 |
kahrl |
https://github.com/minetest/minetest/pull/770 |
| 06:51 |
kahrl |
should https://github.com/minetest/minetest/pull/767 be re-merged? [Fix multiple texture support for animated meshnodes] |
| 07:16 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 07:19 |
|
Calinou joined #minetest-dev |
| 08:15 |
|
proller joined #minetest-dev |
| 08:24 |
|
serengeor joined #minetest-dev |
| 08:51 |
Taoki |
Hi. Can anyone suggest how I can extract a Lua table from a Lua table in the code? In the Lua function I first add if(lua_istable(L, 1)), but what if that table contains multiple tables I need to extract? |
| 08:52 |
Taoki |
Hmm... maybe I need to do a for loop and use if(lua_istable(L, x)) instead (where x is the looping integer) |
| 08:53 |
Taoki |
Still, how would I extract multiple tables from a table... |
| 08:54 |
|
ssieb joined #minetest-dev |
| 08:56 |
|
Calinou joined #minetest-dev |
| 09:22 |
|
kaeza joined #minetest-dev |
| 10:22 |
|
PilzAdam joined #minetest-dev |
| 10:30 |
|
smoke_fumus joined #minetest-dev |
| 10:42 |
|
iqualfragile joined #minetest-dev |
| 10:52 |
|
iqualfragile joined #minetest-dev |
| 10:52 |
|
Zeg9 joined #minetest-dev |
| 11:01 |
|
Calinou joined #minetest-dev |
| 11:29 |
|
proller joined #minetest-dev |
| 12:11 |
kahrl |
Taoki: you should be able to see that in register_craft |
| 12:11 |
kahrl |
it does a lot of type-dependent, dynamic and nested table reading |
| 12:18 |
PilzAdam |
kahrl, re F6 is all in one line with freetype: I had this issue with the "SINGLEPLAYER" thingy in the main menu when adding freetype; IIRC it was fixed by setting line wrapping to true |
| 12:18 |
PilzAdam |
or word wrapping or whatever Irrlicht calls it |
| 12:27 |
kahrl |
PilzAdam: ah nice, that did it |
| 12:28 |
kahrl |
https://gist.github.com/kahrl/5773295 |
| 12:28 |
PilzAdam |
seems like \n only works with that if freetype is used |
| 12:30 |
PilzAdam |
kahrl, feel free to push it |
| 13:00 |
PilzAdam |
kahrl, https://github.com/PilzAdam/minetest/commit/1f0d04b1938fb41830d5a3d8651bf9aebf74ea28 |
| 13:02 |
|
bookwar1 joined #minetest-dev |
| 13:05 |
kahrl |
that looks like a controversial change |
| 13:06 |
kahrl |
why only for the mousewheel and not 1-8 keys? |
| 13:07 |
PilzAdam |
gameplay wise its good that you cant change to a lower pickaxe after using the faster one for all the "work"; and it also doesnt make sense that a hand can keep the crack a pickaxe has produced when releasing the left mouse button removes the crack instantly |
| 13:08 |
kahrl |
I personally am not opposed to it but some people might not like it |
| 13:10 |
kahrl |
the way it is implemented in minecraft is stupid: if you have e.g. tree trunks in your hand and punch a tree with them, and then pick up the tree blocks you broke, it resets your dig time |
| 13:12 |
kahrl |
however if you're only resetting it when the selected hotbar slot changes there can be "exploits" |
| 13:12 |
kahrl |
for example dropping an expensive pick while mining a tough to break node |
| 13:13 |
PilzAdam |
the is most likely not able to break the rest of the node |
| 13:13 |
kahrl |
and then pick the pick back up -> didn't use durability |
| 13:13 |
|
bookwar1 left #minetest-dev |
| 13:13 |
PilzAdam |
+hand |
| 13:13 |
kahrl |
oh, yeah that is true in minetest |
| 13:14 |
PilzAdam |
the player cant really do anything against mods changing his wield item, but he is responsible for changing the selected item |
| 13:16 |
PilzAdam |
btw, it also applies to keys changing the selected item: https://github.com/PilzAdam/minetest/commit/d159842c984378b3de6ca55e26226b080c8cfaa3 |
| 13:16 |
PilzAdam |
+now |
| 13:18 |
kahrl |
another option would be to not fully reset, but scale the dig_time to the new dig_time_complete |
| 13:18 |
kahrl |
it's not realistic but might be better gameplay wise |
| 13:19 |
kahrl |
wait how does this work |
| 13:20 |
kahrl |
if you change from a fast pick to a slow one it changes dig_time_complete but not dig_time |
| 13:20 |
kahrl |
so you don't gain anything from doing that |
| 13:20 |
kahrl |
^ (without your patch) |
| 13:21 |
PilzAdam |
oh, true |
| 13:25 |
PilzAdam |
what you can do is holding down left mouse button on something you cant dig with your hand and then switch to a tool and its instantly removed |
| 13:26 |
PilzAdam |
you dont get any advantage from that but its illogical |
| 13:26 |
kahrl |
yeah |
| 13:26 |
kahrl |
perhaps set dig_time to min(dig_time, old_dig_time * new_dig_time_complete / old_dig_time_complete) |
| 13:27 |
kahrl |
old_dig_time = dig_time |
| 13:29 |
PilzAdam |
if(dig_time_complete < 100000.0) dig_time += dtime; else dig_time = 0; works too |
| 13:30 |
kahrl |
yep |
| 13:30 |
PilzAdam |
so you lose your dig_time if switching to a tool that cant dig the node |
| 13:30 |
PilzAdam |
otherwise the dig_time is kept |
| 13:31 |
kahrl |
it still does the insta-mine thing if you switch from a wooden pick to a mese pick |
| 13:31 |
kahrl |
but it's not as bad |
| 13:31 |
PilzAdam |
yep |
| 13:32 |
PilzAdam |
there needs to be a client.setCrack(-1, nodepos); in the else block too |
| 13:33 |
PilzAdam |
so the cracks are removed when switching to the hand |
| 13:35 |
kahrl |
right |
| 13:36 |
PilzAdam |
so it looks like this: https://github.com/PilzAdam/minetest/commit/7a58c1d4ca7a59f05043ff3c2caeab16c0a78a0d |
| 13:37 |
PilzAdam |
this also fixes the bug that you can dig stone with your hand in 100000 seconds |
| 13:37 |
kahrl |
heh |
| 13:39 |
kahrl |
isn't it 10000000? |
| 13:39 |
kahrl |
so tape down the left mouse button for half a year :P |
| 13:40 |
kahrl |
I think setCrack should only be called if the dig_time was not previously 0, because otherwise doesn't this trigger a mesh update every frame? |
| 13:41 |
kahrl |
ah no setCrack handles that |
| 13:43 |
|
bookwar1 joined #minetest-dev |
| 13:43 |
kahrl |
I think the patch is good then |
| 13:46 |
kahrl |
if you want to merge it go ahead :) |
| 13:47 |
PilzAdam |
done |
| 13:55 |
|
bookwar1 joined #minetest-dev |
| 14:11 |
|
iqualfragile joined #minetest-dev |
| 14:26 |
|
ImQ009 joined #minetest-dev |
| 14:30 |
|
iqualfragile joined #minetest-dev |
| 14:33 |
|
iqualfragile joined #minetest-dev |
| 14:35 |
sfan5 |
can I merge https://github.com/minetest/minetest/pull/738? that bug annoys the f**k out of me |
| 14:38 |
PilzAdam |
sfan5, if that doesnt break anything |
| 14:38 |
sfan5 |
it shouldn't |
| 14:40 |
|
iqualfragile joined #minetest-dev |
| 15:17 |
PilzAdam |
kahrl, you forgot to close your freetype F6 bug issue |
| 15:30 |
|
Zeg9 joined #minetest-dev |
| 15:46 |
|
rubenwardy joined #minetest-dev |
| 15:57 |
|
Anchakor_ joined #minetest-dev |
| 16:11 |
|
Exio joined #minetest-dev |
| 16:21 |
|
Jordach joined #minetest-dev |
| 16:21 |
|
Jordach joined #minetest-dev |
| 16:35 |
|
Calinou joined #minetest-dev |
| 16:40 |
|
neko259 joined #minetest-dev |
| 16:43 |
|
Jordach joined #minetest-dev |
| 16:56 |
VanessaE |
about the frame rate/view distance autotuner, can someone please fix it so it's actually useful? |
| 16:57 |
Calinou |
not trivial, afaik |
| 17:03 |
VanessaE |
well it's just that it adjusts way too slowly. |
| 17:04 |
VanessaE |
like 0.1 nodes in 5 seconds or something |
| 17:04 |
|
hmmmm joined #minetest-dev |
| 17:12 |
Calinou |
2 nodes/second should do ok, probably |
| 17:13 |
VanessaE |
that's still too slow |
| 17:13 |
VanessaE |
more like 5 to 10/second |
| 17:13 |
Calinou |
or better, make adjustment speed configurable. ;) |
| 17:13 |
VanessaE |
or do that :P |
| 17:32 |
|
sapier joined #minetest-dev |
| 18:42 |
|
Abrado}{ joined #minetest-dev |
| 19:07 |
|
proller joined #minetest-dev |
| 19:23 |
kahrl |
PilzAdam: oops, thanks for doing that |
| 19:36 |
|
Calinou joined #minetest-dev |
| 19:42 |
kahrl |
so what exactly did the latest commit break? |
| 19:43 |
PilzAdam |
hm? |
| 19:43 |
VanessaE |
nothing as far as I know? |
| 19:55 |
|
iqualfragile joined #minetest-dev |
| 21:02 |
|
NakedFury joined #minetest-dev |
| 21:07 |
|
init joined #minetest-dev |
| 21:14 |
Taoki |
PilzAdam: http://forum.minetest.net/viewtopic.php?pid=94639#p94639 |
| 21:16 |
PilzAdam |
Taoki, oh, havent you read the pull request Nore linked? |
| 21:16 |
Taoki |
hmm? |
| 21:16 |
Taoki |
Didn't see any |
| 21:17 |
PilzAdam |
https://github.com/minetest/minetest/pull/440 |
| 21:17 |
Taoki |
Ah. Didn't notice it |
| 21:17 |
Taoki |
Guess now the two have to be compared with each other :P |
| 21:18 |
Taoki |
But I see it works the same way, so it's good... can be used in looping functions as much |
| 21:18 |
Taoki |
Guess I worked for nothing, but at least there's two implementations just in case :) |
| 21:18 |
PilzAdam |
Taoki, did you read the closing reason? |
| 21:18 |
PilzAdam |
(last comment) |
| 21:19 |
Taoki |
I see it, although it doesn't make much sense |
| 21:19 |
Taoki |
It's not for a single mod also, many mods could use it at this point |
| 21:19 |
Taoki |
And I've no idea what voxel manipulator could be better. This is the best and only way I can think of |
| 21:21 |
Taoki |
Does that reason still stand after 4 months? Since again this wouldn't be for a single mod, nor can I imagine what voxel manipulator would work better |
| 21:21 |
PilzAdam |
yes |
| 21:21 |
Taoki |
That's really bad :/ |
| 21:22 |
PilzAdam |
Im sorry that wasted your time :-/ |
| 21:22 |
Taoki |
That's ok. I'm more sorry some decisions aren't taken over useful and logical reasons, in my opinion at least |
| 21:24 |
|
kahrl joined #minetest-dev |
| 21:32 |
Taoki |
This is my comment on the other one: https://github.com/minetest/minetest/pull/440#issuecomment-19426484 |
| 21:34 |
Exio |
Taoki: do you know what the "voxel manipulator" is? |
| 21:34 |
Taoki |
Exio: Functions to add / remove / change nodes I assume |
| 21:46 |
|
loggingbot_ joined #minetest-dev |
| 21:46 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 21:46 |
hmmmm |
Because the Lua API is not to be modified on someone's whims, it's for real solutions |
| 21:46 |
Exio |
ew :P |
| 21:46 |
PilzAdam |
Taoki, if we would follow your ideas, we wouldnt have the API at all |
| 21:46 |
Taoki |
hmmmm: I hoped this was a real solution |
| 21:46 |
Taoki |
PilzAdam: I always supported the idea of the API, not really |
| 21:47 |
PilzAdam |
"your ideas" = something simple that just has to work and nothing else |
| 21:47 |
hmmmm |
Taoki, do you also get upset and start accusing others of being illogical when your hack of a workaround doesn't get accepted by other FOSS projects? |
| 21:47 |
hmmmm |
Minetest is way easier to contribute to, FYI |
| 21:50 |
Taoki |
PilzAdam, hmmmm: Ok, sorry about it. I spend most of the day working on the code, and right when I post it find out there's a duplicate AND the idea is rejected. It is incorrect to complain without knowing the other idea first |
| 21:51 |
Taoki |
Part of it is I'm afraid the voxel manipulator idea (which includedly is something more complex and fancy) might never get done, and mods aimed at rezzing large structures will have to be stuck with the current slow and buggy way |
| 21:51 |
hmmmm |
Taoki, I'm sorry you wasted your time, but hurt feelings aren't a good enough reason to add things to the API |
| 21:51 |
hmmmm |
And whatever, I'll do the VoxelManipulator thing since it ties in to what I left off working on anyway. |
| 21:52 |
Taoki |
Yeah. They're not really a reason I wanted it. I mainly thought allowing list of nodes to be spawned would be a good enough system. And was kinda surprised anyone would expect more |
| 21:52 |
Taoki |
hmmmm: Depending on what it's meant to do, maybe I can help as well. I'm not looking to be an ass for no reason, even if I don't understand some things at first. If it's good I do wish for it to be done |
| 21:53 |
hmmmm |
Did you read the TODO at least? |
| 21:54 |
Taoki |
I read a wishlist some time ago I think |
| 21:54 |
hmmmm |
I have a pretty solid set of requirements for Lua MMVM |
| 21:55 |
Taoki |
Main question is if this system is meant to allow spawning a list of nodes in a way managed quickly by the code... as one of the features |
| 21:56 |
PilzAdam |
Taoki, Im sorry that I didnt remembered the old pull request and pointed you earlier to it |
| 21:56 |
Taoki |
PilzAdam: That's ok. There are probably many of them and no one can remember all. I'm sorry I got upset over it... like I said I was surprised an idea which at least to me seemed like the best one was rejected over a distant plan that might not happen (I understand it better now though). |
| 21:58 |
Taoki |
I think for a project like Minetest, the codes might make sense to think over on a larger scale. In other projects I'm used to features being accepted as long as their base idea is wanted, never had issues like waiting for something to be done on larger scale |
| 21:58 |
Exio |
minetest is already full of a single-term things |
| 21:59 |
Exio |
if you want a big example about that, i think formspec is a good one |
| 21:59 |
Exio |
it got added only for very basic stuff |
| 21:59 |
Taoki |
Can't say I get why formspec is bad either :P Though I can see how it could be implemented better (eg: A full function) |
| 21:59 |
Exio |
Taoki: the formspec main menu |
| 22:00 |
Taoki |
ah |
| 22:00 |
Exio |
ask sapier how "painful" it is ;P |
| 22:00 |
PilzAdam |
formspecs suck |
| 22:00 |
Exio |
er, not single-term, short-term i meant |
| 22:01 |
Taoki |
It is worth appreciating some adimns care a lot for the code to be clean and useful, I agree there... |
| 22:01 |
Exio |
well, as talking about terms |
| 22:02 |
Exio |
any "roadmap" for the minetest_game for a long-term? |
| 22:02 |
PilzAdam |
not yet |
| 22:02 |
Exio |
s/for a/in the/ |
| 22:02 |
Exio |
hm |
| 22:02 |
PilzAdam |
if we decide for any direction for minetest_game we will get a massive shitstorm |
| 22:03 |
Exio |
i think as soon as sapier's menu gets a "stable" status, that won't be a problem |
| 22:04 |
Exio |
as saying "download a mod for that" will just be random clicking :P |
| 22:04 |
PilzAdam |
so, we kinda have a feature freeze for minetest_game until we decide on a general direction |
| 22:04 |
Taoki |
PilzAdam: Isn't a direction decided yet? The artistic style looks defined enough, even if it's a bit more simple |
| 22:05 |
Exio |
what is the direction? |
| 22:05 |
PilzAdam |
Taoki, nope |
| 22:08 |
Taoki |
Personally I think the issue with minetest_game currently is that it's still too simple. I know some prefer the trend of a simplistic and easy item set, but whenever I compare to MineCraft (NOT to copy from it :P ) I notice the immersion is much lower in MT, because there's way less to do and create |
| 22:09 |
PilzAdam |
the difference is that MC doesnt support mods, thus they need to add into the main game |
| 22:09 |
PilzAdam |
in Minetest we only need a good base for mods |
| 22:10 |
Taoki |
Yeah. Whenever I think that MC "has all those items and parameters hard-coded" I go like "weee" |
| 22:10 |
PilzAdam |
although the game itself should be fun to play, too |
| 22:10 |
Taoki |
*"ewww" |
| 22:10 |
Taoki |
And yeah. Here I didn't mean the engine, just minetest_game |
| 22:10 |
Taoki |
The engine is slowly getting to as good and awesome as it can be. Or will get there once we have hardware lighting, sorta the last stop :3 |
| 22:10 |
PilzAdam |
I heard MC has a single file per node... awful |
| 22:11 |
Taoki |
Ouch... |
| 22:11 |
Exio |
ehm, no |
| 22:11 |
Taoki |
Sounds awful indeed. I'd go for a single file per chunk of set of cuhunks |
| 22:11 |
Exio |
that is what mc does afaik |
| 22:12 |
Taoki |
That's good then |
| 22:12 |
Taoki |
A file per chunk sounds best IMO |
| 22:13 |
VanessaE |
surely he means one file per node definition? |
| 22:13 |
kahrl |
Taoki: that's what minetest used to do, until servers started to run out of inodes |
| 22:14 |
VanessaE |
(which is almost as ugly) |
| 22:14 |
Taoki |
kahrl: How did that happen? |
| 22:14 |
kahrl |
1 file per mapblock + gigantic maps |
| 22:14 |
Taoki |
VanessaE: Ah, I thought one file per node in-world |
| 22:14 |
Taoki |
kahrl: Why did it reach the limit though? |
| 22:14 |
Taoki |
And what is the current way? |
| 22:15 |
VanessaE |
a big-ass database file :) |
| 22:15 |
kahrl |
I don't know why it reached the limit, it just did |
| 22:15 |
Taoki |
heh. I wonder how it's working now |
| 22:15 |
VanessaE |
kahrl: because there are max ~775 chunks per X/Y/Z axis, that's about 465 billion chunks. |
| 22:15 |
kahrl |
not *all* of those were created ;) |
| 22:16 |
VanessaE |
I could see that running a fs out real damn quick |
| 22:16 |
VanessaE |
well of course not :) |
| 22:16 |
VanessaE |
oh hell, you said mapblock, that's even worse :P |
| 22:17 |
VanessaE |
3875 per axis, about 58 trillion max :) |
| 22:17 |
kahrl |
chunks are only used in mapgen and only recently, but nowhere else |
| 22:19 |
Exio |
it is only 58 trillion |
| 22:22 |
Taoki |
Anyway. Are there any detailed descriptions about how the Voxel Manipulator for Lua is meant to be like? What its purposes are, how it should be coded, what functions it should have, and so on. Would like to look at it and listen to its opinion |
| 22:23 |
Exio |
the TOdO |
| 22:23 |
Exio |
TODO * |
| 22:23 |
Exio |
http://dev.minetest.net/TODO#Lua_MapVoxelManipulator_Interface |
| 22:31 |
Taoki |
Ok. That sounds like a good idea yes |
| 22:32 |
Taoki |
I wonder: Could the code I made work as the writing part of the Voxel Manipulator? Maybe it can be integrated and used as one of the API's. Since it does mention working with array's, if I understand all well |
| 22:33 |
Exio |
i guess hmmmm wants the VM to be in lua like it is "in" C++ |
| 22:36 |
Taoki |
hmmmm: https://github.com/minetest/minetest/pull/771 If you wish to look at this code, what would need to be changed in it to properly work like the Voxel Manager system (the write part in this case). Can I adapt it into something that would work and be helpful? |
| 22:37 |
Taoki |
Like... it already works with writing arrays of nodes. I assume it could be used as part of the VM, maybe with some structure changes |
| 22:38 |
Taoki |
PilzAdam: ^ |
| 22:39 |
|
ch98 joined #minetest-dev |
| 23:01 |
hmmmm |
taoki, a whole lot |
| 23:01 |
hmmmm |
basically you'd need something entirely different |
| 23:02 |
Taoki |
hmmmm: Ehh, ok. Was hoping I could adapt the format a bit and make a read version as well. Means the idea is more different than what I understood |
| 23:02 |
hmmmm |
yes, we're not merely looping through setnode() |
| 23:04 |
hmmmm |
i mean seriously, looking at the original API for this that i shot down, "up to 15% faster" "up to 50% faster", those are jokes |
| 23:04 |
hmmmm |
doing this the proper way would make it more like 20x faster |
| 23:04 |
Taoki |
That would be even nicer :) |
| 23:05 |
Taoki |
Well you prolly wouldn't see anything up to 20x faster. Since it would bottleneck at least at notifying the blocks to you. Even online but also locally |
| 23:05 |
Taoki |
Could be a lot faster though yes |
| 23:05 |
hmmmm |
what? |
| 23:05 |
hmmmm |
anyway |
| 23:06 |
hmmmm |
this would be the first step in making an entire lua mapgen |
| 23:06 |
Taoki |
I mean, if adding a lot of nodes at once would be 20 times faster, the user would probably not really notice that much. Since it would be still slow to register all nodes then notify them |
| 23:06 |
Taoki |
nice |
| 23:06 |
hmmmm |
set to singlenode = CONTENT_IGNORE, and just do all of the node manipulation in the MMVM passed to you in on_generate() |
| 23:06 |
Taoki |
I still tend to agree with the mapgen being C++, BUT with Lua being able to hook a lot into it |
| 23:07 |
hmmmm |
this would open the door for serious experimentation |
| 23:07 |
PilzAdam |
hmmmm, mapgen v8 ;-) |
| 23:07 |
Exio |
that would make it even slower than only lua if the lua side is done faster |
| 23:07 |
Exio |
s/faster/in a good way/ |
| 23:07 |
hmmmm |
nothing official |
| 23:07 |
hmmmm |
i'm looking at paramat and the like |
| 23:07 |
Exio |
the overhead between Lua and C++ :P |
| 23:07 |
hmmmm |
they have some interesting ideas that are awesome, and it'd be great if it was faster, but it's a fringe thing and not really mainstream minetest at all |
| 23:08 |
hmmmm |
but there are way more uses than just this |
| 23:08 |
hmmmm |
i'm just saying, a complete lua mapgen would be the most extreme example of what you'd be able to do |
| 23:08 |
hmmmm |
(and it'd be fast too) |
| 23:12 |
PilzAdam |
hmmmm, http://forum.minetest.net/viewtopic.php?pid=94660#p94660 |
| 23:13 |
PilzAdam |
"Upgrading from 0.4.4 to 0.4.6 has increased structure generation speed by roughly 50% which makes me happy." |
| 23:14 |
hmmmm |
that's all luajit though |
| 23:14 |
Exio |
and generate_ore |
| 23:15 |
hmmmm |
really don't like how people are using generate_ore so hackily like that |
| 23:15 |
hmmmm |
with this they'd be able to do what they really wanted to do |
| 23:15 |
PilzAdam |
I guess "people" is me and "like that" is nether mod? |
| 23:15 |
Exio |
poor PilzAdam |
| 23:15 |
hmmmm |
your nether would be able to look like a real nether with this |
| 23:15 |
Exio |
;P |
| 23:15 |
PilzAdam |
hmmmm, sry, never saw the real nether |
| 23:16 |
Exio |
a nether with real terrain |
| 23:16 |
hmmmm |
it's basically negative 3d noise with lava seas occuring at some height point |
| 23:16 |
hmmmm |
nothing really special but it looks pretty nice |
| 23:17 |
PilzAdam |
who said that it should be negative 3d noise? |
| 23:17 |
hmmmm |
minecraft |
| 23:17 |
Exio |
and mc's nether looks very nice |
| 23:17 |
PilzAdam |
the current nether mod is what I think a nether should look like |
| 23:18 |
PilzAdam |
though to break nodes in a very small cave |
| 23:18 |
Exio |
it doesn't look so cool |
| 23:18 |
PilzAdam |
it has to be annoying |
| 23:18 |
Exio |
why? |
| 23:19 |
PilzAdam |
well, you are not in heaven ;-) |
| 23:19 |
Exio |
that doesn't mean it needs to be annoying |
| 23:21 |
|
iqualfragile_ joined #minetest-dev |
| 23:45 |
Taoki |
Someone please tell me the new snow in minetest_game also spawns naturally :D (though I doubt that's been coded since I assume it requires mapgen changes) |
| 23:46 |
VanessaE |
not in mgv6. |
| 23:47 |
Taoki |
ok. Any mapgen has it? Like ifdev |
| 23:47 |
Taoki |
erm, indev |
| 23:49 |
hmmmm |
v7 |
| 23:49 |
hmmmm |
I needed it for biomes with snow |
| 23:50 |
Taoki |
Awesome. Even more eager to try v7 now :) |
| 23:50 |
Taoki |
But I assume it's not ready enough yet, right? |
| 23:50 |
hmmmm |
it's not |
| 23:51 |
Taoki |
What sort of scary world do I get if I enable it in master? :P |
| 23:51 |
VanessaE |
Taoki: lava where water should be, TNT where grass should be.... ;) |
| 23:52 |
Taoki |
:) |
| 23:52 |
Taoki |
That would probably be called "mapgen-hardcore" |
| 23:55 |
VanessaE |
Taoki: and liquid concrete ( http://forum.minetest.net/viewtopic.php?pid=86565 ) where stone should be |
| 23:55 |
VanessaE |
with floating entities that randomly harden into coal, iron, etc. |
| 23:55 |
VanessaE |
THAT would be hardcore :D |
