| Time |
Nick |
Message |
| 01:07 |
|
OldCoder joined #minetest-dev |
| 01:22 |
|
NakedFury joined #minetest-dev |
| 01:52 |
|
ShadowBot joined #minetest-dev |
| 01:59 |
|
kaeza joined #minetest-dev |
| 02:31 |
|
ShadowBot joined #minetest-dev |
| 02:49 |
|
ShadowBot` joined #minetest-dev |
| 03:24 |
|
harrison joined #minetest-dev |
| 03:42 |
|
kaeza joined #minetest-dev |
| 04:13 |
hmmmm |
hey guys, realtalk |
| 04:14 |
hmmmm |
is the current mapgen v7 used widely enough in mods and everything that a modification, even though it's considered unstable right now, would be disasterous? |
| 04:16 |
iqualfragile |
hmmmm: i just know a single mod using it: snow, but my knowledge might be incomplete |
| 04:16 |
iqualfragile |
and everybody considers it unstable as far as i know |
| 04:17 |
iqualfragile |
aah, wait, nodetopia by pilzadam uses it, too |
| 04:17 |
hmmmm |
alright, good |
| 04:17 |
hmmmm |
ugh |
| 04:17 |
iqualfragile |
but he wont mind rewriting |
| 04:17 |
hmmmm |
I don't know who the hell figured it'd be a good idea to put the mapgen chooser in the world create dialog but it shouldn't be there |
| 04:17 |
iqualfragile |
especialy if it would otherwise hold back an important change |
| 04:17 |
iqualfragile |
indeed |
| 04:17 |
iqualfragile |
what changes do you plan on? |
| 04:17 |
hmmmm |
especially when half of the mapgens there are experimental or otherwise not intended for end users |
| 04:17 |
iqualfragile |
(differential mapgen plz) |
| 04:17 |
hmmmm |
what? |
| 04:18 |
iqualfragile |
well, generating map on block load, saving changes |
| 04:18 |
hmmmm |
that has nothing to do with the mapgen, that has to do with the emergemanager |
| 04:19 |
iqualfragile |
absolutely, still: what changes you you plan on? |
| 04:19 |
hmmmm |
i want to finish up what I started to work on before I got bored with minetest for a while |
| 04:19 |
hmmmm |
basically |
| 04:19 |
iqualfragile |
ok |
| 04:19 |
iqualfragile |
i am realy quite sure pilzadam wont mind |
| 04:19 |
hmmmm |
I want to make the 3d terrain smaller, make everything more buildable |
| 04:20 |
iqualfragile |
or just start v8^^ |
| 04:20 |
hmmmm |
i already have a 3d gaussian blur routine |
| 04:20 |
hmmmm |
that would make a cool post-processing step, like an mapgen flag |
| 04:20 |
iqualfragile |
s/smaller/smoother ? |
| 04:21 |
iqualfragile |
ah, you meant smaller |
| 04:21 |
hmmmm |
the 3d terrain right now is too vast |
| 04:21 |
hmmmm |
I just want the 3d features to be of higher quality but smaller |
| 04:21 |
iqualfragile |
yes, sounds logical |
| 04:21 |
hmmmm |
or at least for there to be wider variance |
| 04:22 |
iqualfragile |
sounds good |
| 04:22 |
iqualfragile |
but could you not just downscale the perlin noise a bit? (it does use that doesnt it?) |
| 05:33 |
hmmmm |
'downscale'? |
| 05:34 |
ShadowNinja |
noiseparams.scale -= x |
| 05:34 |
hmmmm |
a lot of these problems are more complex than you probably anticipate |
| 05:36 |
hmmmm |
already all of the noiseparams have been modified |
| 05:36 |
hmmmm |
(by the way, obviously the current mapgen v7 algorithm could produce nicer terrain but you'd have to play around with the noiseparams to find settings that you personally like) |
| 05:37 |
hmmmm |
I've had the octaves for 3d mountain terrain increased and increased the scale a little, that helps the terrain look more interesting but crazier |
| 05:37 |
hmmmm |
for my own personal use |
| 05:38 |
|
nore joined #minetest-dev |
| 05:39 |
hmmmm |
what i'm essentially doing is fixing the 2d base terrain to produce better results that reflect what it's supposed to be doing in the first place, and then i switched the linear 3d gradient for a cubic one and fiddled with more parameters |
| 05:39 |
hmmmm |
the mapgen is so time intensive, you can blow literally all day tuning parameters |
| 05:40 |
hmmmm |
but my intended result is to have 3d noise mountains that "cut off" sharper (hence the cubic gradient) and therefore have less variable terrain on the top of them instead of coming to peaks and such |
| 05:52 |
nore |
hmmmm, do you think param2 getters and setters should be added to LuaVM? |
| 05:56 |
hmmmm |
nore, i don't think so. |
| 05:56 |
nore |
why? |
| 05:56 |
hmmmm |
setting a param2 for a node is such a special case that i don't believe special provisions should be made for it. |
| 05:56 |
nore |
at least, getting it |
| 05:57 |
hmmmm |
the point of the lua vm is to set nodes in bulk, and if you need to set parameters in bulk like that then something is broken with your approach |
| 05:57 |
nore |
(for example, for doing a circuit simulator in Lua....) |
| 05:57 |
hmmmm |
what's wrong with get_node? |
| 05:57 |
nore |
hmmmm, yes, but also to read the map fast, isn't it? |
| 05:57 |
nore |
get_node is slow |
| 05:57 |
hmmmm |
have you tested it? |
| 05:58 |
hmmmm |
get_node is faster for a small number of nodes |
| 05:58 |
nore |
yep... when it comes to thousands of nodes, it is far slower than VM |
| 05:58 |
hmmmm |
ask sapier, he tried out using voxelmanip for checking the radius of light |
| 05:58 |
nore |
and? |
| 05:58 |
hmmmm |
and it ended up being much slower until he had to set above 10k nodes |
| 05:58 |
hmmmm |
then the LVM started winning out |
| 05:59 |
hmmmm |
LVM is made for doing things in *BULK* |
| 05:59 |
ShadowNinja |
hmmmm: Can you check #1061? |
| 05:59 |
hmmmm |
it's not some sort of silver bullet that speeds up any access |
| 05:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/1061 -- Crash with no error message with `minetest.place_schematic` and table schematic specifier. |
| 05:59 |
hmmmm |
odd |
| 06:00 |
hmmmm |
i'll take a look |
| 06:00 |
hmmmm |
ahhh |
| 06:00 |
hmmmm |
i never set a slice probability from the table |
| 06:16 |
proller |
hmmmm, adjustable heat/humid.... |
| 06:18 |
nore |
hmmmm, about VM vs. get_node: even on 1k nodes, VM wins |
| 06:19 |
nore |
VM: 0.0010080337524414 get_node: 0.0016880035400391 |
| 06:21 |
ShadowNinja |
Just out of curiosity, how long does set_node take comparatively? |
| 06:21 |
hmmmm |
set_node is much much slower |
| 06:22 |
hmmmm |
proller: MT sucks you said, change it yourself :p |
| 06:22 |
hmmmm |
nore: interesting, sapier's implementation must've been flawed somehow |
| 06:23 |
proller |
remove rollback,send event, lighting from set_node - and it wil be much much faster |
| 06:24 |
nore |
VM: 0.0011730194091797 set_node: 0.0013530254364014 |
| 06:24 |
nore |
^ 1k nodes, the VM had to load the area and read it, set_node didn't read anything |
| 06:25 |
hmmmm |
yeah but set_node still needs to emerge the block it's in |
| 06:25 |
nore |
VM wins anyway |
| 06:25 |
hmmmm |
it's just that you don't see that detail |
| 06:25 |
hmmmm |
the way i see it is |
| 06:25 |
hmmmm |
things are fine the way they are |
| 06:25 |
nore |
hmmmm: the block is already emerged by VM right before, am I wrong? |
| 06:25 |
hmmmm |
set_node and get_node are good for things that you don't really do a lot of |
| 06:26 |
hmmmm |
set_node's speed is irrelevant because the only time you'd be setting nodes in bulk you'd have a good use case for lvm so everything's basically covered |
| 06:26 |
hmmmm |
if somebody can make the case to me why there needs to be a param2 bulk set/get, i'd add it |
| 06:26 |
hmmmm |
I mean I suppose it should be there just for instruction orthogonality ubt |
| 06:26 |
hmmmm |
but |
| 06:27 |
hmmmm |
set_node doesn't use a VoxelManipulator at all |
| 06:27 |
nore |
hmmmm, mesecons circuits... (my last one is 200k nodes...) |
| 06:27 |
hmmmm |
the whole point is that the api should be tiny |
| 06:27 |
hmmmm |
smaller than it is right now anyway |
| 06:27 |
nore |
and even 10k wires turning on/off is slow |
| 06:28 |
hmmmm |
i really hate adding more stuff |
| 06:34 |
nore |
btw: I found what was slow in meta_set_nodedef, no idea about how to avoid that though: https://github.com/Novatux/minetest/blob/meta_set_nodedef_3/src/mapblock_mesh.cpp#L422#L424 |
| 06:34 |
|
ImQ009 joined #minetest-dev |
| 06:37 |
hmmmm |
i see |
| 06:37 |
hmmmm |
should ask celeron what the rationale for that code is |
| 06:37 |
hmmmm |
it really does seem useless at first glance |
| 06:38 |
nore |
from what I've seen, it inserts custom node definitions in that MeshGameDef |
| 06:38 |
nore |
and then uses those to display the modified nodes |
| 06:39 |
hmmmm |
ah, setSpecial |
| 06:39 |
ShadowNinja |
hmmmm: So, can you push a fix to that place_schematic issue? |
| 06:40 |
hmmmm |
maybe |
| 06:41 |
hmmmm |
oh nore this is the bvkl thing |
| 06:41 |
hmmmm |
how necessary is it really |
| 06:41 |
hmmmm |
please don't break anything |
| 06:41 |
nore |
hmmmm, no, I have deleted BKVL |
| 06:41 |
hmmmm |
and what's the point of this branch anyway? |
| 06:41 |
ShadowNinja |
I hope that isn't the same maybe as a certain someone else... ;-) |
| 06:41 |
ShadowNinja |
of* |
| 06:42 |
nore |
making meta_set_nodedef work... or will there be another way of making custom node visuals? |
| 06:43 |
hmmmm |
what is that exactly? |
| 06:43 |
hmmmm |
nobody explained it |
| 06:43 |
hmmmm |
that's a proller-tier commit message: "Something" |
| 06:44 |
ShadowNinja |
You can set node def in meta (textures, nodeboxes) so, eg, mesecons would be one node. |
| 06:45 |
ShadowNinja |
Another way to do it would be to have a variation number or similar. I think MineCraft does that. |
| 06:46 |
hmmmm |
minecraft has a bigger param2 and varies things based on that |
| 06:46 |
nore |
ShadowNinja, perhaps a special param2 then? |
| 06:46 |
hmmmm |
but that's not really too hard since mapnodes in minecraft are 8 bytes instead of 4 |
| 06:46 |
nore |
so you could have 256 nodedefs packed into one |
| 06:47 |
hmmmm |
having an entire nodedef inside of a metadata thing |
| 06:47 |
hmmmm |
which effectively makes each node potentially unique |
| 06:47 |
ShadowNinja |
I don't like how you can only have 256 variations, and it rules out facedir and family. |
| 06:47 |
hmmmm |
i suppose that's quite powerful |
| 06:47 |
hmmmm |
no |
| 06:47 |
hmmmm |
facedir only takes up 5 bits, you have 3 left |
| 06:48 |
nore |
the idea would be perhaps to have only additional def in meta, and use the basedef for the other things |
| 06:48 |
ShadowNinja |
Yay! 8 variations! |
| 06:48 |
hmmmm |
nore: honestly the problem you were pointing out is inevitable now that I understand what it's doing |
| 06:49 |
nore |
hmmmm, from what I understand, it copies the whole registered nodedefs.... maybe there would be a way to avoid that |
| 06:49 |
hmmmm |
it should only copy the nodedef that it's modifying |
| 06:49 |
nore |
(perhaps using content_ids > MAX_REGISTERED_CONTENT, that would be looked up in another table) |
| 06:49 |
hmmmm |
erm, not nodedef |
| 06:50 |
hmmmm |
ContentFeatures |
| 06:50 |
ShadowNinja |
+field |
| 06:50 |
hmmmm |
the way you fix this is by changing the big contentfeatures array to an array of pointers to contentfeatures |
| 06:50 |
hmmmm |
this is a huuuuge change though fyi |
| 06:50 |
hmmmm |
huge as in a lot of infrastructure is changed, but you'd only need to modify mapnode.cpp and friends |
| 06:54 |
hmmmm |
nore: my point is that this is going to be slow because now you have to check metadata for the presense of a custom contentfeatures every single time it's drawn which is slow on its own |
| 06:55 |
hmmmm |
but the real nail in the coffin to your branch is, yeah, the fact that m_content_features is a vector of ContentFeatures, not ContentFeatures *. |
| 06:55 |
nore |
hmmmm, it looks like it doesn't do that, and that the nodes that have to be custom are somehow stored somewhere |
| 06:55 |
hmmmm |
nore: how do you know that? |
| 06:55 |
hmmmm |
er rather, how do you not know how this works for sure? you're dealing with it |
| 06:55 |
nore |
&block->m_special_nodedefs; |
| 06:56 |
hmmmm |
ahh |
| 06:56 |
nore |
and I don't know the code well, I only rebased it yesterday... |
| 06:56 |
hmmmm |
so I guess per block there's a map of nodes that have special nodedefs |
| 06:57 |
hmmmm |
that's not as bad, but still, it's not as good. this whole thing is speed critical code and you do 5000 std::map lookups which honestly aren't the fastest thing ever, and so on |
| 06:57 |
hmmmm |
not you, i mean the guy who made this code in the first place |
| 06:57 |
hmmmm |
the inefficiency is baked in so hard that the only reason why minetest is playable is because it just so happens that today's processors are beyond amazing |
| 06:57 |
nore |
tell that to celeron55... ;) |
| 06:59 |
hmmmm |
so nore, do you understand what you need to do in order to get your branch working the right way? |
| 06:59 |
nore |
I'm trying to do that... |
| 06:59 |
|
mrtux joined #minetest-dev |
| 07:03 |
|
ShadowBot` joined #minetest-dev |
| 07:05 |
nore |
https://github.com/Novatux/minetest/blob/meta_set_nodedef_3/src/mapblock_mesh.cpp#L59 <-- I just noticed that... well, it does not copy the whole array in fact |
| 07:06 |
hmmmm |
ahh... then that doesn't really explain the slowness |
| 07:07 |
hmmmm |
at least it doesn't do something stupid like copy the entire array over.. but i wouldn't put it past people to add in stuff like that "as a quick and dirty proof of concept" |
| 07:07 |
hmmmm |
*cough* node groups |
| 07:08 |
nore |
ok, I have the answer now |
| 07:09 |
nore |
hmmmm, that fixed it: https://github.com/Novatux/minetest/commit/ad2dffa9f50a1e80a9ebfee2a0b78abe430941aa |
| 07:10 |
hmmmm |
hahahaha. the creation of the object itself is what's so slow because this branch is old and MAX_REGISTERED_CONTENT used to be not that enormous before. |
| 07:11 |
nore |
yep... |
| 07:12 |
nore |
so we only need to add a MAX_META_CONTENT, and it will work fine |
| 07:12 |
hmmmm |
now, each MeshNodeDefManager is specific to a MapBlock right? |
| 07:12 |
nore |
yep... (and just tested, now if I go above 10 modified nodes, segfault...) |
| 07:13 |
hmmmm |
which means the size of that array would need to be min(MAX_REGISTERED_CONTENT + 1, MAP_BLOCKSIZE * MAP_BLOCKSIZE * MAP_BLOCKSIZE) |
| 07:13 |
nore |
hmmmm, that makes 4096, so only 1/8th of before |
| 07:13 |
hmmmm |
you should make that a ContentFeatures vector |
| 07:15 |
nore |
with 4096, the lag is noticeable, but far better than before |
| 07:15 |
nore |
hmmmm, how does vector work? |
| 07:15 |
hmmmm |
what? you don't know how to use a std::vector? |
| 07:16 |
hmmmm |
are you sure you're qualified to be writing C++? |
| 07:16 |
nore |
I know how to use it a bit... I know C++, but not all data structures... |
| 07:17 |
hmmmm |
you should read this http://www.cplusplus.com/reference/vector/vector/ |
| 07:17 |
hmmmm |
and take a look at the current nodedef.cpp |
| 07:17 |
nore |
I am currently reading it... |
| 07:19 |
ShadowNinja |
Anyone know why vector? Why not dynarray or something that actually sounds like what it is? |
| 07:28 |
|
OldCoder joined #minetest-dev |
| 07:34 |
|
mrtux joined #minetest-dev |
| 07:41 |
nore |
ah, a last question: where should the maximum number of nodes that can be defined in meta be defined? |
| 07:46 |
hmmmm |
i don't feel like you should need to define a maximum, but i would say in node_with_def.h? |
| 07:49 |
nore |
hm.... ok, removed that maximum (it was MAP_BLOCKSIZE^3 anyway) |
| 07:50 |
nore |
anyway, it looks like it works well now |
| 07:51 |
nore |
(however, there are a few things left to do) |
| 08:10 |
|
werwerwer joined #minetest-dev |
| 09:55 |
|
Taoki[mobile] joined #minetest-dev |
| 10:33 |
|
Calinou joined #minetest-dev |
| 10:35 |
|
PilzAdam joined #minetest-dev |
| 11:18 |
|
Taoki[mobile]_1 joined #minetest-dev |
| 11:45 |
VanessaE |
um, wut? |
| 11:45 |
VanessaE |
terminate called after throwing an instance of 'SerializationError' |
| 11:45 |
VanessaE |
what(): String too long for serializeString |
| 11:45 |
VanessaE |
/home/minetest/Scripts/minetestserver-creative.sh: line 26: 7866 Aborted |
| 11:47 |
VanessaE |
the last few things the log shows are a bunch of undefined entities (from having removed the MOBF mod some time ago), and a user digging and placing some routine, ordinary items such as homedecor fences, stone, etc. |
| 11:49 |
nore |
VanessaE, what are the mods in the last lines? |
| 11:50 |
VanessaE |
http://pastebin.ubuntu.com/6779504/ |
| 11:50 |
nore |
... |
| 11:51 |
specing |
strings have to be serialized? WTF? |
| 11:51 |
|
Jordach joined #minetest-dev |
| 11:52 |
VanessaE |
so homedecor, default, and mesecons are represented there. |
| 11:56 |
VanessaE |
I guess mesecons uses some meta in its nodes, but the user reports not having powered that node on, and it works fine elsewhere, so that's not it. |
| 11:57 |
nore |
VanessaE, the meta used in mesecons is very limited |
| 11:57 |
nore |
and you'd need a very full meta to have problems, I have done meta that contained serveral KB without problem |
| 11:58 |
nore |
the limit must be something like 0x10000 |
| 11:58 |
VanessaE |
ok, well then full meta isn't likely the issue here unless the actual server code glitched out |
| 11:59 |
nore |
if(plain.size() > 65535) |
| 11:59 |
nore |
throw SerializationError("String too long for serializeString"); |
| 11:59 |
nore |
^ util/serialize.cpp |
| 12:11 |
VanessaE |
too bad it didn't bother to print some kind of minimal backtrace :-/ |
| 12:13 |
VanessaE |
that by the way was one of those "not logged" errors - it was caught by the extra ">" redirect. |
| 12:15 |
VanessaE |
(I keep debug.txt, and also redirect stderr+stdout to a separate file so I can catch such errors) |
| 13:09 |
|
EvergreenTree joined #minetest-dev |
| 13:09 |
VanessaE |
question: |
| 13:09 |
|
EvergreenTree joined #minetest-dev |
| 13:10 |
VanessaE |
the problem that the bees mod had with the particle spawners it was using, causing horrible fps dropouts with even a few particles (20-30)...was that ever fixed? |
| 13:10 |
VanessaE |
was that an engine problem or a mod problem? |
| 13:39 |
|
Evolykane joined #minetest-dev |
| 13:40 |
|
Evolykane joined #minetest-dev |
| 13:48 |
sfan5 |
which section does #1110 belong to? |
| 13:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/1110 -- Include system info in the HTTP user agent on Windows by sfan5 |
| 13:55 |
nore |
sfan5, any thoughts on https://github.com/Novatux/minetest/tree/meta_set_nodedef_4 ? |
| 13:58 |
|
zat joined #minetest-dev |
| 14:23 |
sfan5 |
nore: what is that supposed to be used for? |
| 14:24 |
nore |
changing the visuals of a node through its metadata |
| 14:25 |
VanessaE |
sfan5: imagine defining a single "stair" model that a thousand different textures could be applied to. |
| 14:25 |
sfan5 |
ah |
| 14:25 |
VanessaE |
one node definition, a thousand different appearances. |
| 14:25 |
sfan5 |
also what is with the 3rd and 4th param to set_node_with_meta |
| 14:25 |
|
Zeitgeist_ joined #minetest-dev |
| 14:25 |
|
Zeitgeist_ joined #minetest-dev |
| 14:25 |
nore |
VanessaE, or a single node to which you could apply different nodeboxes |
| 14:25 |
VanessaE |
now extend that to the 30 or so different shapes that Moreblocks+Stairsplus has |
| 14:26 |
VanessaE |
nore yes, that too |
| 14:26 |
VanessaE |
sfan5: as nore implies, pipes, tubes, mesecons wires - one wire nodedef, hundreds of different models |
| 14:26 |
VanessaE |
(one pipe-, one tube-, etc etc |
| 14:26 |
VanessaE |
) |
| 14:27 |
sfan5 |
yeah, but what are the 3rd and 4th params |
| 14:27 |
sfan5 |
4th is the nodedef, but what is the 3rd param? |
| 14:29 |
|
iqualfragile joined #minetest-dev |
| 14:31 |
|
Zeitgeist_ joined #minetest-dev |
| 14:33 |
nore |
sfan5, IIRC 3rd param is base_nodedef, and 4th is what is added to it |
| 14:33 |
sfan5 |
that should go to lua_api |
| 14:33 |
sfan5 |
.txt |
| 14:34 |
nore |
yes, I know... it is not ready for merging |
| 14:35 |
|
zfvsdgrdg joined #minetest-dev |
| 14:37 |
|
rubenwardy joined #minetest-dev |
| 15:04 |
|
NakedFury joined #minetest-dev |
| 15:12 |
|
Yepoleb_ joined #minetest-dev |
| 15:19 |
|
hmmmm joined #minetest-dev |
| 15:23 |
|
rsiska joined #minetest-dev |
| 15:29 |
|
Gethiox4 joined #minetest-dev |
| 15:38 |
|
Calinou joined #minetest-dev |
| 15:40 |
|
kaeza joined #minetest-dev |
| 15:45 |
|
kaeza joined #minetest-dev |
| 16:29 |
|
diemartin joined #minetest-dev |
| 16:56 |
|
blaaaaargh joined #minetest-dev |
| 17:02 |
|
Megaf joined #minetest-dev |
| 17:02 |
Megaf |
start your server with server_announce = 0 |
| 17:03 |
Megaf |
then log in to your server and do /set server_announce = 1 |
| 17:03 |
Megaf |
that wont work |
| 17:03 |
Megaf |
then turn your server off |
| 17:03 |
Megaf |
and change server_announce back to = 1 |
| 17:03 |
Megaf |
start your server |
| 17:03 |
Megaf |
it will not announce anymore |
| 17:03 |
|
Megaf left #minetest-dev |
| 17:07 |
blaaaaargh |
... |
| 17:15 |
ShadowNinja |
hmmmm: Now update the changelog. :-) |
| 17:22 |
|
Megaf joined #minetest-dev |
| 17:27 |
|
Megaf left #minetest-dev |
| 17:43 |
PilzAdam |
hmmmm, dont worry about Nodetopia when changing the API |
| 17:43 |
hmmmm |
api? |
| 17:45 |
PilzAdam |
I thought you wanted to change the biome API or so, because you asked if mods already use it |
| 17:46 |
hmmmm |
no no I'm changing the terrain |
| 17:46 |
hmmmm |
so any maps currently using nodetopia are screwed up |
| 17:47 |
hmmmm |
what I feared was that too many people are using v7 now |
| 17:47 |
PilzAdam |
Nodetopia isnt release yet, so go ahead |
| 17:47 |
hmmmm |
also, do people like the current v7 terrain? |
| 17:47 |
hmmmm |
i don't |
| 17:47 |
hmmmm |
it has charm to it, but it's not technically good |
| 17:48 |
PilzAdam |
I would prefere more "interesting" terrain |
| 17:49 |
PilzAdam |
by "interesting" I mean more rough terrain, mountains being closer to each other etc. |
| 17:52 |
PilzAdam |
its currently rather boring to explore the terrain in v7 |
| 17:54 |
ShadowNinja |
The rivers are a big improvement, but I'd like more mounains. |
| 17:55 |
PilzAdam |
the rivers are more like ravines, since they cut through the terrain |
| 17:57 |
ShadowNinja |
Hmmm, yes, I suppose they are. Regular rivers would also be good. |
| 17:58 |
PilzAdam |
the current rivers wouldnt be a problem in the mapgen I imagine, but they dont fit the current one |
| 17:59 |
PilzAdam |
btw, a way to change the noise params in on_mapgen_init() would be nice |
| 18:02 |
ShadowNinja |
hmmmm: You should create http://dev.minetest.net/minetest.register_on_mapgen_init . |
| 18:16 |
Sokomine |
hmm. it's quite impractical that formspec labels cannot exceed a certain length. textareas may work, but they're not really optimal for non-input messages |
| 18:17 |
|
kaeza joined #minetest-dev |
| 18:17 |
|
mrtux joined #minetest-dev |
| 18:18 |
Sokomine |
regarding mapgen: it would be best to have some "boring" areas (=nicely flat or with soft hills) for building, and some rough terrain in other parts of the map. i havn't tried v7 yet. last i kneew it did only stone? |
| 18:20 |
PilzAdam |
Sokomine, IMO these flat areas are very boring; if you need place to build then you can always do landscaping |
| 18:22 |
Exio4 |
landscaping looks ugly in a very "rough" terrain |
| 18:23 |
Sokomine |
pilzadam: hm. perhaps it's because i prefer to use many mods that add tons of nature (like in the eden game). with those, even flat areas may look great |
| 18:24 |
PilzAdam |
Exio4, it shouldnt be very rough; the challenge is to find the right roughness so that it looks interesting while still having areas that are easy to landspace |
| 18:24 |
Exio4 |
yeah |
| 18:24 |
PilzAdam |
eh, -typo |
| 18:25 |
PilzAdam |
Sokomine, that might be true; I use a game that only has full cubes |
| 18:29 |
|
Evolykane joined #minetest-dev |
| 18:59 |
|
grrk-bzzt joined #minetest-dev |
| 18:59 |
|
VargaD_ joined #minetest-dev |
| 19:12 |
hmmmm |
ShadowNinja, I documented mapgen param setting on the wiki. |
| 19:14 |
ShadowNinja |
hmmmm: Can you document minetest.register_on_mapgen_init on the dev wiki? |
| 19:15 |
|
EvergreenTree joined #minetest-dev |
| 19:15 |
|
EvergreenTree joined #minetest-dev |
| 19:16 |
hmmmm |
no |
| 19:16 |
ShadowNinja |
hmmmm: No? Why not? |
| 19:16 |
hmmmm |
cause it's already done somewhere else |
| 19:23 |
ShadowNinja |
Well, it should be documented on the dev wiki. If it isn't updated then it becomes pointless to have it. |
| 19:54 |
|
Calinou joined #minetest-dev |
| 20:31 |
hmmmm |
well it's in the lua_api.txt |
| 20:31 |
hmmmm |
also it's present on the wiki in the mapgen param setting page |
| 20:32 |
VanessaE |
but...but.... it's not in a dozen other places also |
| 20:32 |
VanessaE |
:) |
| 20:32 |
hmmmm |
if you're telling me that i absolutely must do this, i might remind you that I'm getting paid exactly $0 for this so you're getting your money's worth |
| 21:10 |
|
grrk-bzzt joined #minetest-dev |
| 21:15 |
|
Weedy joined #minetest-dev |
| 21:31 |
|
EvergreenTree joined #minetest-dev |
| 21:31 |
|
EvergreenTree joined #minetest-dev |
| 22:13 |
|
NakedFury joined #minetest-dev |
| 22:17 |
PilzAdam |
typo fix: https://github.com/PilzAdam/minetest/commit/4585e855a7fe63f4b820d7551a39ac9825b4cb1d |
| 22:17 |
PilzAdam |
pushing in a few minutes |
| 23:00 |
|
VanessaE joined #minetest-dev |
| 23:33 |
|
diemartin joined #minetest-dev |
