One of the things I do in the soon to be released lib_materials update, is to hack the lava cooling. Originally I only meant to pull the code in house, but then had a little fun with it.
Lava no longer cools down to default:stone. Because I have stone and ore types to work with in lib_mat, I do have the lava cool to an intermediate state, where one can begin to see the stone cooling on the surface of the lava. This "cooling lava" then further cools into a variety of relevant stone types, basalt, andesite or other.
This could be modified to spawn certain ore types, as this makes an interesting mechanic, without increasing processing. There is no specific placement code, simply relying on the lava cool feature.
Be aware, in lib_mat, I no longer depend on default, and have pulled in most of the behaviors to act natively on the lib_mat nodes. Lava cooling is still done via ABM, however, but uses the internal modified lib_mat copy of defaults own builtin lava cooling ABM. As such, there is no extra processing.
This actually works as a game mechanic, where some ores could easily be generated only when the lava cools, and only at certain elevations.
Shad
Ores are waste of HDD
-
- Member
- Posts: 1118
- Joined: Mon Dec 29, 2014 08:07
- Location: USA
Re: Ores are waste of HDD
A general solution to what problem? Ore generation that lowers the compression rate? I think people here stated that it is a non-problem! :-D ;-)duane wrote:Well, if you want a general solution, it needs to work for the default game.Astrobe wrote:The problem is that game mechanics and features don't work in isolation. They form a network of interactions. That's why they might make no sense in your game despite the fact they work (as far as I can tell) in my game.
Thinking about it, wouldn't a better compression rate affect favorably network bandwidth usage for servers? Also, some types of solution could double as an "X-ray" ore detection anti-cheat.
- Hume2
- Member
- Posts: 709
- Joined: Tue Jun 19, 2018 08:24
- GitHub: Hume2
- In-game: Hume2
- Location: Czech Republic
Re: Ores are waste of HDD
Well, a different compression method might be also a way. However, the information might not be present at all when nobody would use it.
For time efficiency: The cave walls will be generated during mapgen, so the mapgen might just take a little more time. Or maybe even less because all ores will be unregistered and only the walls will be generated. When someone digs a node from the cave wall, the worst thing which can happen is that 5 more nodes will have to be generated. Well, maybe the caves flooded by water might cause a few issues.
For ores being dropped from stone randomly: I think, this will ruin spelunking totally.
For time efficiency: The cave walls will be generated during mapgen, so the mapgen might just take a little more time. Or maybe even less because all ores will be unregistered and only the walls will be generated. When someone digs a node from the cave wall, the worst thing which can happen is that 5 more nodes will have to be generated. Well, maybe the caves flooded by water might cause a few issues.
For ores being dropped from stone randomly: I think, this will ruin spelunking totally.
If you lack the reality, go on a trip or find a job.
- Hume2
- Member
- Posts: 709
- Joined: Tue Jun 19, 2018 08:24
- GitHub: Hume2
- In-game: Hume2
- Location: Czech Republic
Re: Ores are waste of HDD
These are only default ores:
I made a modification in which only the cave walls are generated and the rest is generated after it gets visible. And the result is: World size is 3 times smaller, lag is approximately the same.
I made a modification in which only the cave walls are generated and the rest is generated after it gets visible. And the result is: World size is 3 times smaller, lag is approximately the same.
- Attachments
-
- screenshot_20190910_101216.jpg (179.1 KiB) Viewed 223 times
If you lack the reality, go on a trip or find a job.
Who is online
Users browsing this forum: No registered users and 3 guests