| Time |
Nick |
Message |
| 00:09 |
VanessaE |
screw it. wrote it out as an issue. https://github.com/minetest/minetest/issues/1532 |
| 00:16 |
|
VargaD joined #minetest-dev |
| 00:34 |
|
Zeno` joined #minetest-dev |
| 00:36 |
Zeno` |
Hi. When I make a Debug release, TestSocket does an ipv6 socket test |
| 00:36 |
Zeno` |
however I have ipv6 disabled and therefore the test fails |
| 00:37 |
Zeno` |
So I have to #ifdef that code out. I wonder if there could be a way to make that test optional (on by default) |
| 00:43 |
fu-fu |
Zeno`: Did I do the test-code thing alright? |
| 00:44 |
Zeno` |
fu-fu, yeah. Unfortunately I'm not terribly familiar with that part of the engine. It looked like it should work |
| 00:44 |
Zeno` |
Maybe paste the link again so someone else might see it? |
| 00:46 |
fu-fu |
I'll throw it in a bug report I guess. |
| 00:47 |
fu-fu |
Aaand nvm |
| 00:50 |
fu-fu |
to thr forums. |
| 00:59 |
|
nore_ joined #minetest-dev |
| 01:10 |
|
Exio4 joined #minetest-dev |
| 01:34 |
|
nore_ joined #minetest-dev |
| 01:44 |
|
alexxs joined #minetest-dev |
| 02:03 |
|
fu-fu joined #minetest-dev |
| 02:05 |
|
alexxs joined #minetest-dev |
| 02:13 |
|
alexxs joined #minetest-dev |
| 02:24 |
|
nore_ joined #minetest-dev |
| 02:24 |
|
nore__ joined #minetest-dev |
| 02:58 |
|
Amaz_ joined #minetest-dev |
| 03:00 |
|
celeron55 joined #minetest-dev |
| 03:01 |
|
^v joined #minetest-dev |
| 03:42 |
|
not^v joined #minetest-dev |
| 03:46 |
|
Hunterz joined #minetest-dev |
| 05:01 |
|
Exio joined #minetest-dev |
| 05:05 |
|
Exio joined #minetest-dev |
| 05:35 |
|
smoke_fumus joined #minetest-dev |
| 05:42 |
|
Eater4 joined #minetest-dev |
| 05:44 |
|
Hunterz joined #minetest-dev |
| 06:09 |
|
restcoser joined #minetest-dev |
| 06:32 |
|
grrk-bzzt joined #minetest-dev |
| 06:52 |
|
Krock joined #minetest-dev |
| 06:53 |
|
Exio4 joined #minetest-dev |
| 06:58 |
|
psedlak joined #minetest-dev |
| 07:14 |
sfan5 |
nore__: why would someone need that setting? |
| 07:27 |
|
Eater4 joined #minetest-dev |
| 08:01 |
|
Garmine joined #minetest-dev |
| 08:09 |
|
CWz joined #minetest-dev |
| 08:09 |
|
CWz left #minetest-dev |
| 08:20 |
|
Calinou joined #minetest-dev |
| 08:43 |
|
Exio4 joined #minetest-dev |
| 08:49 |
|
Garmine joined #minetest-dev |
| 09:45 |
|
Xenux_ joined #minetest-dev |
| 09:48 |
|
Exio4 joined #minetest-dev |
| 09:49 |
|
Xenux joined #minetest-dev |
| 09:52 |
|
Taoki[laptop] joined #minetest-dev |
| 09:59 |
|
proller joined #minetest-dev |
| 10:06 |
|
CraigyDavi joined #minetest-dev |
| 10:08 |
|
Xenux joined #minetest-dev |
| 10:41 |
|
alexxs joined #minetest-dev |
| 11:21 |
|
ImQ009 joined #minetest-dev |
| 11:52 |
|
Jordach joined #minetest-dev |
| 11:58 |
|
PenguinDad joined #minetest-dev |
| 12:02 |
|
kahrl joined #minetest-dev |
| 12:15 |
nore__ |
sfan5:; to provide other oregun parameters |
| 12:16 |
nore__ |
s/gun/gen |
| 13:17 |
|
PilzAdam joined #minetest-dev |
| 13:55 |
|
NakedFury joined #minetest-dev |
| 14:06 |
|
Exio4 joined #minetest-dev |
| 14:14 |
|
sfan5 joined #minetest-dev |
| 14:17 |
|
Calinou joined #minetest-dev |
| 14:47 |
|
vifino joined #minetest-dev |
| 14:52 |
|
hmmmm joined #minetest-dev |
| 14:53 |
|
Amaz_ joined #minetest-dev |
| 15:12 |
|
Hunterz joined #minetest-dev |
| 15:33 |
Sokomine |
hmmmm: is there a (good) way to find out which surface node will be the dominant one in one area? i mean those 80x80 mapchunk areas (or roughly that size). i want to create a more abstract map of the world |
| 15:34 |
hmmmm |
sokomine, perhaps you should just downscale a bitmap of each individual node on the surface map |
| 15:34 |
|
Exio4 joined #minetest-dev |
| 15:38 |
Calinou |
use mapper, resize the image down using no interpolation? |
| 15:38 |
Sokomine |
does not work in this context as i want that to be a on-the-fly map. perhaps there's really no general way other than iterating over the surface of each generated chunk (provided it's a "surface" one) |
| 15:40 |
Sokomine |
just thought that those perlin noise things in combination with the known algorithm of a particular mapgen might allow to create a generalized map without generating each chunk. but i don't really know much about that |
| 15:47 |
Exio4 |
? |
| 15:54 |
Sokomine |
exio4: i want a more abstract map. using one from a mapper and downscaling would be one way. what i'm after here right now is another approach. the question is: can the general structure of a map be predicted without calculating each mapchunk? |
| 15:54 |
Exio4 |
abstract map? :P |
| 15:55 |
Sokomine |
yes. if you want to navigate, you usually don't use sattellite photos. maps are abstractions |
| 15:57 |
Sokomine |
coastlines would be particulary intresting i think. coastlines (perhaps also desert) combined with the current position of the player and a handful of points of intrest may be sufficient already. there's no need to have an accurate picture of each tree or cactus on the map |
| 15:58 |
Sokomine |
i'm not sure how the underlying mechanism of mapgens works, but it *seems* they use mathematical functions to determine height and biome type. those functions *might* be used more general to create a picture of how the map would look like where it ever fully explored (which would not fit on any storage anyway) |
| 15:59 |
Exio4 |
oh |
| 15:59 |
Exio4 |
like, biomes map somehow |
| 15:59 |
Exio4 |
'biomes' |
| 15:59 |
Sokomine |
yes, like that |
| 16:01 |
|
kaeza joined #minetest-dev |
| 16:01 |
Sokomine |
based on my very limited current knowledge of mapgens as such (extremly limited), i can't tell if something like that could be calculated easily. it just seems that mapgens use those mathematical functions anyway and that it might be possible to use them for what i have in mind (kind of creating a map with a way lower resolution) |
| 16:03 |
Sokomine |
a map of the entire world may not even be particulary helpful as most mapgens are rather small-scale and would not help much with navigation. still, small parts of such a map might help |
| 16:08 |
hmmmm |
that's not possible |
| 16:10 |
hmmmm |
map is generated by the result of several interacting systems that, while deterministic, cannot be predicted |
| 16:14 |
Sokomine |
what would happen if the "resolution" would be lowered? i.e. only every 4th or 16th node on a map beeing generated, but with x/z values from the current map, and the other nodes around them not computed? would those calculated be the same as if all where calculated? |
| 16:15 |
Sokomine |
perhaps i'll really have to look into this one day in order to ask more intelligent questions :-/ |
| 16:16 |
hmmmm |
I just explained why |
| 16:33 |
Exio4 |
ops/ |
| 16:33 |
Exio4 |
? |
| 16:39 |
|
Exio4 joined #minetest-dev |
| 16:43 |
|
Exio4 joined #minetest-dev |
| 16:44 |
|
Exio joined #minetest-dev |
| 16:59 |
|
Calinou joined #minetest-dev |
| 16:59 |
|
grrk-bzzt joined #minetest-dev |
| 16:59 |
|
grrk-bzzt joined #minetest-dev |
| 17:19 |
|
proller joined #minetest-dev |
| 18:10 |
|
paramat joined #minetest-dev |
| 18:12 |
paramat |
Sokomine "perlin noise things in combination with the known algorithm of a particular mapgen" i think a simple coastline + biome map of the entire world can be done this way |
| 18:16 |
Sokomine |
ah! that would be great already. coastlines + player position(s) + poi + (probably) roads already help a lot. it does look strange if all the later things are put on an "empty" ground |
| 18:18 |
Sokomine |
such a map would be very helpful i think. i'm currently considering storing the dominant node (i.e. grass, water or whatever the biome has) for each 80x80 chunk and will try that out as a map. it has the additional benefit of showing which regions have been visited. i'm not sure how useful that will eventually be |
| 18:18 |
paramat |
i can reproduce mgv6 in simple form in a lua mapgen, then as you say reduce the resolution, perhaps by 16. because i'm no good at mapping i could generate a floating 1/16th scale map of the world with 1 node per pixel |
| 18:19 |
paramat |
then it would be up to you to convert that into a realtime HUD map |
| 18:19 |
Sokomine |
uff :-) |
| 18:20 |
Sokomine |
right now it's a formspec. villages are one big square with no internal texture other than that of the texture which happened to be my choice for that village's representation |
| 18:21 |
paramat |
yeah or formspec whatever. crazy idea just might get me inspired to work on it, you want a map of mg mod or mgv6? |
| 18:21 |
Sokomine |
it'll help a bit that it's (mostly) 2d |
| 18:21 |
Sokomine |
mg i can do myshelf i think. i've just counted the nodes at mapgen time by now. will store that and take a look at how it looks |
| 18:22 |
Sokomine |
but..such a map for mg would be very welcome as well :-) perhaps in a way that it can be adapted to most mapgens out there |
| 18:22 |
sfan5 |
a map for mg? |
| 18:23 |
paramat |
also, such a method can generate a map for areas not visited yet |
| 18:23 |
paramat |
well i might stick to mgv6 only. 1 pixel per 80 nodes will lose a lot of detail, i might try 1 per 16, or variable |
| 18:24 |
Sokomine |
variable sounds very good |
| 18:24 |
Sokomine |
the question is also how fast that may be |
| 18:25 |
paramat |
i might be able to do this with perlinmaps, so fairly fast |
| 18:25 |
sfan5 |
>i'm currently considering storing the dominant node (i.e. grass, water or whatever the biome has) for each 80x80 chunk and will try that out as a map. |
| 18:25 |
sfan5 |
that sounds interesting |
| 18:25 |
Sokomine |
i tried gsmapper, but that basicly has the same problem as all mappers: its resolution is too fine and the area shown too small |
| 18:26 |
paramat |
i can't see the attraction of small local-area maps that just show you what you can already see :) |
| 18:26 |
Sokomine |
well, figuring out that mapnode type was easy - inside the chunk generation code of course. there i can count it. storing...is another matter. either i'll get too many write operations for my taste, or information about generated chunks will be lost |
| 18:28 |
Sokomine |
they have their use - to a degree. inside a village/complex of buildings, it helps to see the relation of the buildings. it just doesn't help on large-scale problems |
| 18:29 |
Sokomine |
don't want to know how many people lost their first house in mt or mc due to never finding back there :-) the home command in minetest_next definitely helps (once people know these commands) |
| 18:55 |
gentoobro |
it would be interesting if there was a way to specify the depth of the map |
| 18:55 |
|
Calinou joined #minetest-dev |
| 18:56 |
gentoobro |
then you could have a map of the surface, as well as maps of your various mines |
| 18:56 |
gentoobro |
perhaps the depth could optionally have a sliding window to account for variations in the mine depth |
| 18:58 |
paramat |
'depth' as in surface elevation? yes that could be found and converted to pixel brightness, i would have to calculate elevation anyway to get coastline |
| 19:03 |
Sokomine |
i don't know; for maps of mines, those small-scale mappers are perhaps best suited? to my knowledge, all those mapping attempts stick to the surface |
| 19:06 |
|
Miner_48er joined #minetest-dev |
| 19:07 |
paramat |
ah i see mapping the depths, default cave generation is not defined by perlin noise so thats's not possible |
| 19:08 |
|
paramat left #minetest-dev |
| 19:09 |
gentoobro |
you'd have to call the map generation function from lua when desired since user-created mines are not in perlin noise either |
| 19:18 |
|
khonkhortisan joined #minetest-dev |
| 19:35 |
Sokomine |
what i suggested is not about player generated structure. it's for a background map (on which player generated structures might be shown independently) |
| 19:40 |
|
hmmmmmm joined #minetest-dev |
| 20:13 |
|
Amaz left #minetest-dev |
| 20:23 |
|
nore__ joined #minetest-dev |
| 20:23 |
|
nore_ joined #minetest-dev |
| 21:16 |
|
zat joined #minetest-dev |
| 21:59 |
|
^v joined #minetest-dev |
| 22:06 |
hmmmm |
sokomine: no, there are still things such as caves and trees. |
| 22:07 |
hmmmm |
caves, especially in mapgen v6, play a very large role in the shape of the terrain |
| 22:07 |
hmmmm |
that's just one example of a procedurally generated layer that is deterministic but not predictable |
| 22:10 |
|
cg72 joined #minetest-dev |
| 22:11 |
cg72 |
what are the new mapgen settings in map_meta.txt for jungles as the old ones dont work now and keep getting kicked back out |
| 22:11 |
hmmmm |
sounds like a #minetest question. please leave if you have nothing development related to ask. |
| 22:12 |
cg72 |
leave well thats very rude as i login her alot |
| 22:12 |
cg72 |
here* |
| 22:13 |
|
Exio4 joined #minetest-dev |
| 22:14 |
cg72 |
just remember hmmmm, rudeness gets you nowhere in life!!!!!!! |
| 22:20 |
proller |
caves is deterministic ??? |
| 22:49 |
|
cg72 left #minetest-dev |
| 22:52 |
Sokomine |
if there's a cave, does that mean that there is a cave (and, naturally, the hole it consists of), or is the landscape as such quite diffrent? |
| 22:53 |
Sokomine |
i thought caves where generated afterwards? would a landscape be the same (minus the caves) if generated with the same seed and caves disabled? |
| 22:55 |
Sokomine |
for now, i just count the surface nodes in nores mapgen and set the most dominant one for the entire 80x80 area. the loss in resolution is there, but as i'm displaying a 2000x2000 nodes area, it is not too dramatic |
| 22:55 |
Sokomine |
not perfect yet either |
| 23:07 |
|
paramat joined #minetest-dev |
| 23:07 |
paramat |
you could compare 2 worlds, one with cavegen disabled, same seed, there is a fair amount of difference |
| 23:14 |
|
Zeno` joined #minetest-dev |
| 23:16 |
|
fu-fu joined #minetest-dev |
| 23:18 |
VanessaE |
hmmmm: to be perfectly fair, cg72's question was relevant to here in that mapgen settings are poorly documented even from a dev standpoint, and not documented at all from a modder/end-user standpoint. If a user has to read the engine code to understand a setting, the documentation has failed and therefore it falls to the devs to correct it. |
| 23:19 |
VanessaE |
and in fact I *think* I answered her question via the dev wiki some time back (before she knew she'd ask it, that is). |
| 23:19 |
paramat |
the new mapgen flags are documented in lua_api.txt |
| 23:19 |
VanessaE |
when was that added? |
| 23:20 |
paramat |
oops sorry in minetest.conf example |
| 23:20 |
VanessaE |
bad place to document them. |
| 23:20 |
VanessaE |
the .example file should not be considered documentation, as such |
| 23:21 |
VanessaE |
also, they're not documented in the .example so much as they're *listed* there with some very basic info |
| 23:21 |
|
cg72 joined #minetest-dev |
| 23:22 |
VanessaE |
no explanation here about what a given setting does, or why |
| 23:22 |
VanessaE |
(with a couple of exceptions) |
| 23:27 |
paramat |
mg flags docs look fine to me :) clearly and simply explained |
| 23:28 |
VanessaE |
too simply |
| 23:28 |
VanessaE |
that's the issue |
| 23:28 |
VanessaE |
and where they're mentioned. |
| 23:28 |
VanessaE |
that stuff belongs somewhere other than the .example |
| 23:28 |
Zeno` |
As an example I didn't really know what 'mud' did until yesterday |
| 23:29 |
cg72 |
rotf Zeno` |
| 23:29 |
Zeno` |
I didn't. I thought it must have been an unimplemented feature until you mentioned it and then I looked at the src code |
| 23:44 |
|
nore__ joined #minetest-dev |
| 23:44 |
|
nore_ joined #minetest-dev |
| 23:55 |
|
cg72 left #minetest-dev |
| 23:59 |
|
paramat left #minetest-dev |
