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
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.
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.
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.
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.
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.
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 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.
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.
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.
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 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.
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.
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 ;-)
Hi,
i couldn't find a forum thread for this mod, so i'm posting here.
This mod is a great idea.
In games like Rust, an incoming airdrop is a sure bet for some tense PvP. This mod could achieve something similar, but it's not there yet.
So please allow me to suggest some things:
Documentation:
There is no documentation. An explanation on what the mod actually does, how to use the chatcommands & how to use the API would be nice.
Spawn-Area:
Having more than one spawning area (preferably each with its own loot-configuration) will be useful.
Aditionally a dynamic spawning area would be nice. Similar to Casimirs Spawnarea-mod ( https://content.luanti.org/packages/Casimir/spawnarea/ ), the airdrop could spawn within an area around the center of active players.
Automatic Spawning:
The admin should be able to make the airdrops spawn automatically on a randomized timer (preferably each area with its own timer).
Presentation:
The presentation right now is minimal, one chat-message and a simple spawn in of the airdrop-block.
Players can easily miss the message. And even if they don't miss it, they don't see (or hear) anything dropping.
A multi-staged announcement and some ambient audio would draw more attention.
For instance:
: Chatmessage: "An airdrop is incoming!" &
Play loud airplane-sounds at a point above the future airdrop-location.
: Wait some time (maybe 60 seconds)
: Chatmessage: "Airdrop has be released at X:<x>, Z:<z>"
: Spawn a helper-block with an ABM that slowly moves it down above the airdrop-location.
: When the helper-block reaches the ground, replace it with the airdrop-block &
Chatmessage: "Airdrop has landed at X:<x>, Y:<y>, Z:<z>" &
Play a loud impact/landing-sound at the airdrop-location.
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
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
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
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.
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.
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.
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)
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.
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.
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
ah, i see.
i can make that adjustable.i made that adjustable.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 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
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.
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
Nice to hear
Hi, i couldn't find a forum thread for this mod, so i'm posting here.
This mod is a great idea.
In games like Rust, an incoming airdrop is a sure bet for some tense PvP. This mod could achieve something similar, but it's not there yet. So please allow me to suggest some things:
Documentation:
There is no documentation. An explanation on what the mod actually does, how to use the chatcommands & how to use the API would be nice.
Spawn-Area:
Having more than one spawning area (preferably each with its own loot-configuration) will be useful.
Aditionally a dynamic spawning area would be nice. Similar to Casimirs Spawnarea-mod ( https://content.luanti.org/packages/Casimir/spawnarea/ ), the airdrop could spawn within an area around the center of active players.
Automatic Spawning:
The admin should be able to make the airdrops spawn automatically on a randomized timer (preferably each area with its own timer).
Presentation:
The presentation right now is minimal, one chat-message and a simple spawn in of the airdrop-block. Players can easily miss the message. And even if they don't miss it, they don't see (or hear) anything dropping.
A multi-staged announcement and some ambient audio would draw more attention.
For instance:
: Chatmessage: "An airdrop is incoming!" &
Play loud airplane-sounds at a point above the future airdrop-location.
: Wait some time (maybe 60 seconds)
: Chatmessage: "Airdrop has be released at X:<x>, Z:<z>"
: Spawn a helper-block with an ABM that slowly moves it down above the airdrop-location.
: When the helper-block reaches the ground, replace it with the airdrop-block &
Chatmessage: "Airdrop has landed at X:<x>, Y:<y>, Z:<z>" &
Play a loud impact/landing-sound at the airdrop-location.
Thanks & Cheers