Having a humongous mountain in your world can be really cool, and I can recommend this mod if you would figure out how to get ores to spawn in there.
But I wish this mod could work with every game (e.g. NodeCore) by using the default mapgen blocks there and allow ore spawning by default (e.g. overwrite some variables by optionally depending on something that needs it). The default place for the mountain could also be right next to spawn instead of in the player (e.g. X:1000, Z:2000). Thank you!
Edit: The developer is already realising my suggestions, as you can see in the comments below
Thanks,
i changed the default spawning position as you suggested.
The other wishes are also quite reasonable,
i'll do my my best to make it compatible with more games,
VoxelLibre seems possible, but Nodecore is quite confusing to me.
And the ore-spawning is something i can add, but only globally.
So i'll do something about that, not neccessarily the right thing ;-)
I removed the dependency from default.
the mountain will be build in every game, but only from "mapgen_stone".
Minetest_Game and VoxelLibre will produce the mountain with all features.
Thank you for doing my suggestions! Maybe I can help a bit:
For the mountain in every game, you can also take advantage of the v6 mapgen aliases, which from my testing in NodeCore should work with non-v6 mapgens too. However you should always check if the alias is even defined in the 1st place, as maybe some games wouldn't have e.g. mapgen_dirt, to fall back to stone. If a game doesn't have snow/isn't supported, maybe you could use such a mapgen alias instead like mapgen_dirt and mapgen_dirt_with_grass for the mountain top.
If you're confused about NodeCore, here's some info about it: it is a minimalistic game, with no biome-specific stone/grass/trees variants (except stained stone which hints at lode ore position, but isn't biome specific), and seems to look the same everywhere like if it had only 1 biome (but it does have beaches, sand and plants), and ice and snow are not a thing. While testing your mod now I saw that gravel, water and pumwater(lava) spawn normally on it, but stained stone and lode ore (metal/iron) don't. You can find more info on the NodeCore wiki if you need it (this link goes to in-game elements).
Lastly, for ore spawn height correction you could check if a specific ore does spawn in normal mountains (e.g. NodeCore lode is maxy=48, while MTG coal maxy=64 and extra coal maxy=0), and then increase the height accordingly if needed (check for maxy=0 or 10?), to work in sandbox games and with mods that aren't supported. You could also add a setting for the maxy height check (so it can be set e.g. to -10 or just completely disabled).
I removed all dependencies.
Now v6 mapgen_aliases are used, with a fallback to the base mapgen_aliases.
It test very nice in Minetest_Game, VoxelLibre & NodeCore.
Thanks for the idea.
And i added a very basic ore-generator.
It's a bit krude, but you get all the ores the game has defined that spawn above y:-1000.
As I said, you can add a setting to modify the variable that in this case is set to -1000 since some players may not want a super easy gameplay. After the check for an ore's spawn maxY you could just overwrite it, so the ore can spawn using its own rules, or somehow make it only spawn in the mountain (min/maxX and min/maxZ?) but still respecting its laws like earlier.
-- Get lowest Y value for each ore for the check
lowY=core.settings:get(y)
for (every ore) do
-- If the ore's maxY is higher or equal to lowY, it qualifies as a mountain spawning ore
if (ore.maxY>=lowY) ore.maxY=1000 (... or ...) SpawnInMountain(ore)
end
Edit 6 hours later: change minimum Y to lowest Y to avoid confusion
Yep, it's quite shiny right now.
Your idea would work probably for nodecore, but minetest_game would get no ores then.
The ore generation will always be a bit strange in the mountain,
but i'll make the max amount of spawned ores adjustable, so you can turn it down.
I mean that the minimum Y (or should've I called it 'lowest' or something instead?) could be adjusted so instead of the y:-1000 it could be adjusted to not spawn OP ores like diamonds. It would work in not only nodecore, but also minetest_game. I also said that they could spawn by just adjusting the maxY of the ore so they spawn correctly for sure (respecting e.g. specific mechanics of some games like e.g. NC or configuration in the ore definition like the shape).
I agree that adding a setting for adjusting ore spawn rate would be good with a custom ore generator.
Thank you! Now the only left thing I could think of is making the ores spawn more naturally instead of mountain ore-gen, adjusting the maxY of an ore to 1000 or similar. However, probably an ore gen for e.g. minetest_game would make more sense, while in games like nodecore or with certain mods it would be better with the maxY adjust instead. You could add a setting then to swap to this method (except if maybe there's another way to address this issue or this may make more problems? tell me what you think).
# Toggle the type of ore spawning in the mountain. Mountain ore-gen
# finds ores of spawn type "scatter" above adjustable Y and scatters them
# around. If false, the method will fall back to modifying the ores' spawn
# maximum Y, which may be less performant, but most accurate.
01_a_mountain.method (Mountain ore gen) bool true
# Depends: 01_a_mountain.method
01_a_mountain.orefactor
if (core.settings:get_bool(01_a_mountain.method, true)) then
do the mountain ore gen
else
for (every ore) do
if (ore.maxY>=aboveY) ore.maxY=1000
end
end
that is a great idea, but unfortunately,
i just tested it, changing the maxY (or the minY or any other value) in that table does not affect the ore generation.
it seems core.registered_ores ist just for reference, not for manipulating the registered ore definitions.
And i can't just cache all the ore temporarily, clear the ores & re-register them all with changed values,
because you can only do that at load-time, and at load-time i don't have the ore-definitions yet.
Maybe you should not clear them, but instead register another version of the ore instead. Btw minetest_game does this below y=0 for extra coal and in high y for every ore in floatlands.
else
for (every ore) do
-- Remember that every 'ore' table is just a reference
-- Check if ore qualifies
if (ore.maxY>=aboveY) then
-- copy the ore table so the reference doesn't get modified
ore1=ore
-- and modify it to register it to spawn in the mountain
ore1.maxY=1000
ore1.minY=ore1.minY+1
core.register_ore(ore1)
end
end
end
Yeah,
but you can only do that at load-time as well, and at load-time i don't have the ore-definitions yet.
I would need to reintroduce dependencies. There would be supported games and unsupported games again,
And i am far to happy to have lost these dependencies, to go this route.
I'm going through the api-documentation right now to see if i have missed something useful,
but i kinda doubt it.
Oh, I thought you meant that only clearing all of the ores and such wasn't possible at load time. It seems like to use this method the mod would need to load last. I saw a mod one day that had the same problem so it just has an optional dependency on every thing (Cozy Lights mod) but I'm not sure if there's a different approach.
Edit: Wait, but how did you get the mountain ore-gen to work then in load time? How did you get the ores?
I saw a mod one day that had the same problem so it just has an optional dependency on every thing (Cozy Lights mod)
Ok, that is probably an option, but i really don't like it. Then i will be overwriting everything other mods added to the map. The mountain needs to be generated early to avoid that.
Edit: Wait, but how did you get the mountain ore-gen to work then in load time? How did you get the ores?
i use the 'core.register_on_mods_loaded' callback to get the ores after all mods have been loaded.
So you first generated the mountain before everything and then added ores after every mod loads, so it doesn't overwrite anything. Is that really required to not overwrite anything? If it would work with the biomes touching the mountain or other things, the mountain could spawn after everything else (via core.register_on_mods_loaded) if we can't find another way for natural ore generation.
But is it possible to use the core.register_on_mods_loaded after generating the mountain to let the natural generation continue? If not maybe there could be another ore-gen by the mod to replicate the effects of normal ore-gen by reading the ore table (basically mountain ore-gen upgraded), but I'm not sure if that would be a bit too big/advanced.
The last thing I could think of right now is optionally depending on every ore mod, but that could be tedious and unnice (I agree that the Cozy Lights option is bad) if it would need to be done normally/manually (which may be the only way).
Ah, you got the wrong impression on how the mountain is generated.
What happens in the mod right now is:
On Load-Time:
Besides some basic setup, there are only two callbacks registered
core.register_on_mods_loaded &
core.register_on_generated
After all Mods are loaded, the core.register_on_mods_loaded callback triggers.
Here we get all the node and ore data. The mapgen_aliases are present and all the ores are registered, so we can read them.
The building blocks for mountain and the ores for the internal ore-gen are defined here.
Everytime the engine creates a mapchunk, the core.register_on_generated callback triggers.
if the mapchunk is part of the mountain-area, we then generate one chunk of the mountain(, not the whole mountain in one go).
After the mapchunk is filled with mountain, the ores and decoration is handled.
First the internal ore-gen is run.
Then the natural ore generation is re-triggered for that mapchunk (core.generate_ores()) &
then the natural decoration generation is re-triggered (core.generate_decorations())
So i don't want to add and maintain a long list of dependencies. And i'm not competent enough to recreate the whole natural ore generation.
I'm still reading the api.docs looking for ideas, but right now i see only:
small tweaks to the internal ore-gen to make a bit better &
a second mini-mod that just registers some ores for a particular game. (e.g. Mountain-Ores for Nodecore)
I'm not an expert in modding (and especially in mapgen) yet, and I was trying to figure out here how the process goes, so thank you for clarifying it to me.
It seems like it would be perfect if it would be possible to get after the mods and ores registering, but before the map generation. There, it would be possible to register the new versions of ores and then make the generation happen. It seems possible by just defining the core.register_on_generated() callback and doing the things in there.
If it isn't possible to get in that frame without problems though, is it instead possible to, after generating the mountain, call the core.generate_ores() function after defining the extra versions of ores to spawn in the mountain and disabling the other ones?
it would be ideal if we could change or add the ores in the core.register_on_generated() callback,
that would solve all the problems, we could even change the ores back after the core.generate_ores()-call and only ever affect the mountain.
But we can't, core.register_ore is only ever allowed during mod load-time.
Right now, i'm reading up on the mapgen-environment, i didn't know that it existed, until now. Maybe the rules in there are different.
And i made post on the forum asking for help on that issue: https://forum.luanti.org/viewtopic.php?t=31331 , not sure if something turns up there.
Quick status update: Something turned up :-)
I got 3 solutions via the forum and the feature request.
At least we can go back to your initial idea, and maybe we can even restrict the modified ore-definitions to just the mountain.
But i need some time to process and test all the new information.
Maybe I could shorten BlockHead's hacks: Nevermind I think it would be copyright infringement, except something little like this:
1: Make an exclusive biome for the mountain, with its exclusive ores
2: Create the mountain super high/low and then move it into the desired place
but I recommend you shorten all for yourself to remove redundant words (and get really familiar with the text that way).
Out of the 2 I think I would pick the 1st as it is less hacky and risky (except if 3rd is better but I didn't check it). Then when your feature gets into minetest, you could make a check if version == e.g. 5.11.0 do the new thing (some can't already update to next version).
OK, i added the new "boosted" ore-generation.
Eventually i used sfan5s method (which is like Blockheads 2nd idea, but "virtual").
Now ores are generated in an underground Voxelmanip-Object, that never gets actually written to map.
Per default the y-level for the ore-gen is the negative of the y-level of the mountain-mapchunk, so at height 500 you get ores from -500.
And i added a liquid-filter, lava & water will be removed on the mountain (for most games at least), to avoid spilling.
But i also had to add a couple of fixes for several games.
besides 2 optional dependencies, there some limitations:
all games with mcl_biomes-mod (the mineclone-type games) have ore-gen fixed to y= -90, as world ends on -100.
mineclonia has decorations deactivated, because the whole area gets filled with trees otherwise.
and exile does not get any "boosted"-ore-gen, because it uses ore-gen to place buildings & stairs even in the air.
It was quite an ordeal. And i'm not sure if you like how the mountain looks in nodecore now, but that's it for now.
Ok, thank you so much for the effort! In nodecore it looks like this now, with weird hardened stone everywhere (harder stones appear deep underground) and on other parts of terrain, so it would be great if the next Minetest/Luanti update brings your git requested feature so it can be removed (or keep the hard stone but somehow make it not spawn on other mountains, but not sure if that's possible), but it is still great that it works with other games.
For now though I agree that resting is a good idea.
Thanks.
Just to clarify, all the weird hardened stone is generated by the ore-generator of nodecore, not by me.
This is just the natural generation of ores in nodecore. It turns out, game-creators use the ore-generator for all kind of weird stuff,
in exile the ore-generator creates buildings, in mesecraft it makes caves.
But all the effects of the mod are limited to the mod-mountain-area, nothing will happen to other areas of the map.
So there is no hard stone spawning on other mountains.
As a possible change for nodecore, i could either fix the y-level for the boosted-ore-gen to -90, like in Voxellibre, or deactivate it completely, like in exile.
But all the effects of the mod are limited to the mod-mountain-area, nothing will happen to other areas of the map. So there is no hard stone spawning on other mountains.
I meant that in the mountain area, the other parts of terrain get the extra ores too. You can see it in the 1st image I sent. However maybe it's not that much of an issue if a game gets the weird ores removed such as nodecore's hardened stone.
As a possible change for nodecore, i could either fix the y-level for the boosted-ore-gen to -90, like in Voxellibre, or deactivate it completely, like in exile.
You could do the Voxelibre -90 y change for NodeCore (or even -120), as its hardened stone appears at ~-130. This way both lode and lux will spawn.
At the same time though you could later also make a change so e.g. mountain y 100 = ores at y -10 (my/10*-1) and cap it at -90 (if my>900 y=-90 or if y<-90 y=-90), so there aren't e.g. diamonds/lux right at the bottom and makes more sense to climb the mountain.
Maybe like this (line 99:init.lua)
else
g_minp.y = (g_minp.y/10) * -1
-- don't go lower than y_pretend
if (g_minp.y < y_pretend) g_minp.y = y_pretend
end
I tested the 2nd idea: the overlapping of virtual and actual voxelmanip-objects caused the mountain to be sliced up vertically.
so i now fixed the ore-gen to y= -120 for nodecore.
Not sure what you mean... Oh nevermind I see, the mountain just gets sliced for some reason, but the fixed y=-120 seems to work good anyway in nodecore, as there aren't so many ores spawning in the mountain (atleast from outside) so lux is gonna be still rare anyway.
Edit: Lower amounts of ores may be because of the weird ore distribution as shown in previous images of hardened stone and this one (using 4bidden texture pack for easy stained stone vision and g_minp.y=g_minp.y*-1 --(not sure if I should've just y_fix=false)), which shows where ore is placed using hard stone? However I'm not sure if we should worry and work on this currently, especially because of what is below
If the 2nd idea doesn't work as you said maybe let's wait once again for your feature to be implemented, as it could remove the e.g. hardened stone so nodecore will use y_fix=false and mineclones could have rarer ores excluded at lower levels right? Except if there is some fix to the idea but I don't know, I tried a few tweaks to it but no
Well, i agree. I think it is ok for now.
If the requested feature is added to luanti, a rework can make sense, but maybe a new & better mountain might be a better choice then. And i'm a bit mountain-tired right now, i need a break.
But thank you very much for all the input & motivation, it helped.
Cheers
Having a humongous mountain in your world can be really cool, and I can recommend this mod if you would figure out how to get ores to spawn in there.
But I wish this mod could work with every game (e.g. NodeCore) by using the default mapgen blocks there and allow ore spawning by default (e.g. overwrite some variables by optionally depending on something that needs it). The default place for the mountain could also be right next to spawn instead of in the player (e.g. X:1000, Z:2000). Thank you!Edit: The developer is already realising my suggestions, as you can see in the comments below
Thanks, i changed the default spawning position as you suggested. The other wishes are also quite reasonable, i'll do my my best to make it compatible with more games, VoxelLibre seems possible, but Nodecore is quite confusing to me. And the ore-spawning is something i can add, but only globally.
So i'll do something about that, not neccessarily the right thing ;-)
Cheers
I removed the dependency from default. the mountain will be build in every game, but only from "mapgen_stone". Minetest_Game and VoxelLibre will produce the mountain with all features.
Thank you for doing my suggestions! Maybe I can help a bit:
For the mountain in every game, you can also take advantage of the v6 mapgen aliases, which from my testing in NodeCore should work with non-v6 mapgens too. However you should always check if the alias is even defined in the 1st place, as maybe some games wouldn't have e.g. mapgen_dirt, to fall back to stone. If a game doesn't have snow/isn't supported, maybe you could use such a mapgen alias instead like mapgen_dirt and mapgen_dirt_with_grass for the mountain top.
If you're confused about NodeCore, here's some info about it: it is a minimalistic game, with no biome-specific stone/grass/trees variants (except stained stone which hints at lode ore position, but isn't biome specific), and seems to look the same everywhere like if it had only 1 biome (but it does have beaches, sand and plants), and ice and snow are not a thing. While testing your mod now I saw that gravel, water and pumwater(lava) spawn normally on it, but stained stone and lode ore (metal/iron) don't. You can find more info on the NodeCore wiki if you need it (this link goes to in-game elements).
Lastly, for ore spawn height correction you could check if a specific ore does spawn in normal mountains (e.g. NodeCore lode is maxy=48, while MTG coal maxy=64 and extra coal maxy=0), and then increase the height accordingly if needed (check for maxy=0 or 10?), to work in sandbox games and with mods that aren't supported. You could also add a setting for the maxy height check (so it can be set e.g. to -10 or just completely disabled).
I removed all dependencies. Now v6 mapgen_aliases are used, with a fallback to the base mapgen_aliases. It test very nice in Minetest_Game, VoxelLibre & NodeCore. Thanks for the idea.
And i added a very basic ore-generator. It's a bit krude, but you get all the ores the game has defined that spawn above y:-1000.
Cheers
Right, I agree the ore-generator is a bit OP:
When you scream 'DIamonds!' like the achievement in M.M.M.Mineclone but they're everywhere so your throat gets destroyed (joke, not meant to be offensive)
Even in NodeCore it's a bit OP, lux and lode everywhere, even though lode shouldn't spawn outside, with no stained stone
As I said, you can add a setting to modify the variable that in this case is set to -1000 since some players may not want a super easy gameplay. After the check for an ore's spawn maxY you could just overwrite it, so the ore can spawn using its own rules, or somehow make it only spawn in the mountain (min/maxX and min/maxZ?) but still respecting its laws like earlier.
Edit 6 hours later: change minimum Y to lowest Y to avoid confusion
Yep, it's quite shiny right now. Your idea would work probably for nodecore, but minetest_game would get no ores then. The ore generation will always be a bit strange in the mountain, but i'll make the max amount of spawned ores adjustable, so you can turn it down.
Cheers
I mean that the minimum Y (or should've I called it 'lowest' or something instead?) could be adjusted so instead of the y:-1000 it could be adjusted to not spawn OP ores like diamonds. It would work in not only nodecore, but also minetest_game. I also said that they could spawn by just adjusting the maxY of the ore so they spawn correctly for sure (respecting e.g. specific mechanics of some games like e.g. NC or configuration in the ore definition like the shape).
I agree that adding a setting for adjusting ore spawn rate would be good with a custom ore generator.
ah, i see.
i can make that adjustable.i made that adjustable.Thank you! Now the only left thing I could think of is making the ores spawn more naturally instead of mountain ore-gen, adjusting the maxY of an ore to 1000 or similar. However, probably an ore gen for e.g. minetest_game would make more sense, while in games like nodecore or with certain mods it would be better with the maxY adjust instead. You could add a setting then to swap to this method (except if maybe there's another way to address this issue or this may make more problems? tell me what you think).
that is a great idea, but unfortunately,
i just tested it, changing the maxY (or the minY or any other value) in that table does not affect the ore generation.
it seems core.registered_ores ist just for reference, not for manipulating the registered ore definitions.
And i can't just cache all the ore temporarily, clear the ores & re-register them all with changed values,
because you can only do that at load-time, and at load-time i don't have the ore-definitions yet.
Yikes
Maybe you should not clear them, but instead register another version of the ore instead. Btw minetest_game does this below y=0 for extra coal and in high y for every ore in floatlands.
Yeah, but you can only do that at load-time as well, and at load-time i don't have the ore-definitions yet.
I would need to reintroduce dependencies. There would be supported games and unsupported games again,
And i am far to happy to have lost these dependencies, to go this route.
I'm going through the api-documentation right now to see if i have missed something useful,
but i kinda doubt it.
Oh, I thought you meant that only clearing all of the ores and such wasn't possible at load time. It seems like to use this method
the mod would need to load last. I saw a mod one day that had the same problem so it just has an optional dependency on every thing (Cozy Lights mod) but I'm not sure if there's a different approach.Edit: Wait, but how did you get the mountain ore-gen to work then in load time? How did you get the ores?
Ok, that is probably an option, but i really don't like it. Then i will be overwriting everything other mods added to the map. The mountain needs to be generated early to avoid that.
i use the 'core.register_on_mods_loaded' callback to get the ores after all mods have been loaded.
So you first generated the mountain before everything and then added ores after every mod loads, so it doesn't overwrite anything. Is that really required to not overwrite anything? If it would work with the biomes touching the mountain or other things, the mountain could spawn after everything else (via
core.register_on_mods_loaded) if we can't find another way for natural ore generation.But is it possible to use the
core.register_on_mods_loadedafter generating the mountain to let the natural generation continue? If not maybe there could be another ore-gen by the mod to replicate the effects of normal ore-gen by reading the ore table (basically mountain ore-gen upgraded), but I'm not sure if that would be a bit too big/advanced.The last thing I could think of right now is optionally depending on every ore mod, but that could be tedious and unnice (I agree that the Cozy Lights option is bad) if it would need to be done normally/manually (which may be the only way).
Ah, you got the wrong impression on how the mountain is generated. What happens in the mod right now is:
On Load-Time:
Besides some basic setup, there are only two callbacks registered
core.register_on_mods_loaded &
core.register_on_generated
After all Mods are loaded, the core.register_on_mods_loaded callback triggers.
Here we get all the node and ore data. The mapgen_aliases are present and all the ores are registered, so we can read them.
The building blocks for mountain and the ores for the internal ore-gen are defined here.
Everytime the engine creates a mapchunk, the core.register_on_generated callback triggers.
if the mapchunk is part of the mountain-area, we then generate one chunk of the mountain(, not the whole mountain in one go).
After the mapchunk is filled with mountain, the ores and decoration is handled.
First the internal ore-gen is run.
Then the natural ore generation is re-triggered for that mapchunk (core.generate_ores()) &
then the natural decoration generation is re-triggered (core.generate_decorations())
So i don't want to add and maintain a long list of dependencies. And i'm not competent enough to recreate the whole natural ore generation.
I'm still reading the api.docs looking for ideas, but right now i see only:
small tweaks to the internal ore-gen to make a bit better &
a second mini-mod that just registers some ores for a particular game. (e.g. Mountain-Ores for Nodecore)
I'm not an expert in modding (and especially in mapgen) yet, and I was trying to figure out here how the process goes, so thank you for clarifying it to me.
It seems like it would be perfect if it would be possible to get after the mods and ores registering, but before the map generation. There, it would be possible to register the new versions of ores and then make the generation happen. It seems possible by just defining the
core.register_on_generated()callback and doing the things in there.If it isn't possible to get in that frame without problems though, is it instead possible to, after generating the mountain, call the
core.generate_ores()function after defining the extra versions of ores to spawn in the mountain and disabling the other ones?it would be ideal if we could change or add the ores in the core.register_on_generated() callback,
that would solve all the problems, we could even change the ores back after the core.generate_ores()-call and only ever affect the mountain.
But we can't, core.register_ore is only ever allowed during mod load-time.
Right now, i'm reading up on the mapgen-environment, i didn't know that it existed, until now. Maybe the rules in there are different. And i made post on the forum asking for help on that issue: https://forum.luanti.org/viewtopic.php?t=31331 , not sure if something turns up there.
That's great that you've made a forum post, because you'll very likely get help from there (and already are).
Edit 10th Feb: Git feature request https://github.com/luanti-org/luanti/issues/15772
Quick status update: Something turned up :-) I got 3 solutions via the forum and the feature request. At least we can go back to your initial idea, and maybe we can even restrict the modified ore-definitions to just the mountain. But i need some time to process and test all the new information.
Maybe I could shorten BlockHead's hacks: Nevermind I think it would be copyright infringement, except something little like this:
but I recommend you shorten all for yourself to remove redundant words (and get really familiar with the text that way).
Out of the 2 I think I would pick the 1st as it is less hacky and risky (except if 3rd is better but I didn't check it). Then when your feature gets into minetest, you could make a check if version == e.g. 5.11.0 do the new thing (some can't already update to next version).
OK, i added the new "boosted" ore-generation. Eventually i used sfan5s method (which is like Blockheads 2nd idea, but "virtual"). Now ores are generated in an underground Voxelmanip-Object, that never gets actually written to map. Per default the y-level for the ore-gen is the negative of the y-level of the mountain-mapchunk, so at height 500 you get ores from -500. And i added a liquid-filter, lava & water will be removed on the mountain (for most games at least), to avoid spilling.
But i also had to add a couple of fixes for several games. besides 2 optional dependencies, there some limitations: all games with mcl_biomes-mod (the mineclone-type games) have ore-gen fixed to y= -90, as world ends on -100. mineclonia has decorations deactivated, because the whole area gets filled with trees otherwise. and exile does not get any "boosted"-ore-gen, because it uses ore-gen to place buildings & stairs even in the air.
It was quite an ordeal. And i'm not sure if you like how the mountain looks in nodecore now, but that's it for now.
Ok, thank you so much for the effort! In nodecore it looks like this now, with weird hardened stone everywhere (harder stones appear deep underground) and on other parts of terrain, so it would be great if the next Minetest/Luanti update brings your git requested feature so it can be removed (or keep the hard stone but somehow make it not spawn on other mountains, but not sure if that's possible), but it is still great that it works with other games.
For now though I agree that resting is a good idea.
Thank you!
Thanks. Just to clarify, all the weird hardened stone is generated by the ore-generator of nodecore, not by me. This is just the natural generation of ores in nodecore. It turns out, game-creators use the ore-generator for all kind of weird stuff,
in exile the ore-generator creates buildings, in mesecraft it makes caves.
But all the effects of the mod are limited to the mod-mountain-area, nothing will happen to other areas of the map. So there is no hard stone spawning on other mountains.
As a possible change for nodecore, i could either fix the y-level for the boosted-ore-gen to -90, like in Voxellibre, or deactivate it completely, like in exile.
Cheers
I meant that in the mountain area, the other parts of terrain get the extra ores too. You can see it in the 1st image I sent. However maybe it's not that much of an issue if a game gets the weird ores removed such as nodecore's hardened stone.
You could do the Voxelibre -90 y change for NodeCore (or even -120), as its hardened stone appears at ~-130. This way both lode and lux will spawn.
At the same time though you could later also make a change so e.g. mountain y 100 = ores at y -10 (
my/10*-1) and cap it at -90 (if my>900 y=-90orif y<-90 y=-90), so there aren't e.g. diamonds/lux right at the bottom and makes more sense to climb the mountain.I tested the 2nd idea: the overlapping of virtual and actual voxelmanip-objects caused the mountain to be sliced up vertically. so i now fixed the ore-gen to y= -120 for nodecore.
Cheers
Not sure what you mean... Oh nevermind I see, the mountain just gets sliced for some reason, but the fixed y=-120 seems to work good anyway in nodecore, as there aren't so many ores spawning in the mountain (atleast from outside) so lux is gonna be still rare anyway.
Edit: Lower amounts of ores may be because of the weird ore distribution as shown in previous images of hardened stone and this one (using 4bidden texture pack for easy stained stone vision and
g_minp.y=g_minp.y*-1 --(not sure if I should've just y_fix=false)), which shows where ore is placed using hard stone? However I'm not sure if we should worry and work on this currently, especially because of what is belowIf the 2nd idea doesn't work as you said maybe let's wait once again for your feature to be implemented, as it could remove the e.g. hardened stone so nodecore will use y_fix=false and mineclones could have rarer ores excluded at lower levels right? Except if there is some fix to the idea but I don't know, I tried a few tweaks to it but no
Well, i agree. I think it is ok for now.
If the requested feature is added to luanti, a rework can make sense, but maybe a new & better mountain might be a better choice then. And i'm a bit mountain-tired right now, i need a break.
But thank you very much for all the input & motivation, it helped. Cheers
Thank you very much too! Here is again git feature request: https://github.com/luanti-org/luanti/issues/15772
They just released 5.11.0 too, so I'm not sure if we're supposed to wait for next release.