togosh
commented
8 years ago +1 On Sep 17, 2015 5:19 AM, "zrisher" notifications@github.com wrote:
Currently, prefab asteroids added to a world have their full Octree voxel data saved. Depending on the physical size of the asteroid itself, this can be only a few kb for moons or 200-700+kb for larger asteroids. Even a few large prefab asteroids will make up the majority of a world's save file size, dwarfing its Sector data. This causes delays when joining worlds (or even timeouts with a poor internet connection), large bandwidth use on servers, and periods of low SIM when a few people join the server at the same time (or when someone constantly leaves and rejoins).
There are two standard workarounds for this:
This first is to generate custom prefabs that have very high ore density, basically spheres of solid ore, so a world can remain playable with just a few asteroids on the map. This is an insufficient solution for people that need more asteroids to support their intended game style, want more realistic roids, or simply don't have the time or expertise to generate the ore balls.
The second standard workaround for this is to use procedural worlds and avoid prefabs altogether. Procedural roids are nice in that their Octree save data starts very small (~2kb even for large roids) and grows only as it's changed (mined). With a lot of deformation, they can grow to be just as large as the prefabs, but when this happens an admin can simply delete the file and they will be regenerated in their untouched, very small state. (Said admin should of course ensure no grids or other objects are in the area of regeneration to avoid placing intersecting objects into the world, which can cause tremendous lag as we see with the encounters bug.) The disadvantage here is that you still lose control over the placement of asteroids in your map. Want to confine them to a 100km sphere around the center but still have a 500km map? Too bad. Want to make cool patterns, or carve out strategically interesting sectors? Out of luck.
My solution to this issue has been to create procedural asteroids in a procedural world, save them, and then manually import, duplicate, and place them into a non-procedural world in the pattern I'd like. When they grow too large, I delete and re-import them using backups of the files. This works well but is very manual and can currently only be accomplished by using external tools to alter save files.
Thus I opened up this issue with the intention of adding functions that support:
- adding procedural-type asteroids at specific coordinates from a seed int
- regenerating asteroids that have enough space to regen without intersecting objects
— Reply to this email directly or view it on GitHub https://github.com/zrisher/GardenPerformance/issues/26.
Currently, prefab asteroids added to a world have their full Octree voxel data saved. Depending on the physical size of the asteroid itself, this can be only a few kb for moons or 200-700+kb for larger asteroids. Even a few large prefab asteroids will make up the majority of a world's save file size, dwarfing its Sector data. This causes delays when joining worlds (or even timeouts with a poor internet connection), large bandwidth use on servers, and periods of low SIM when a few people join the server at the same time (or when someone constantly leaves and rejoins).
There are two standard workarounds for this:
This first is to generate custom prefabs that have very high ore density, basically spheres of solid ore, so a world can remain playable with just a few asteroids on the map. This is an insufficient solution for people that need more asteroids to support their intended game style, want more realistic roids, or simply don't have the time or expertise to generate the ore balls.
The second standard workaround for this is to use procedural worlds and avoid prefabs altogether. Procedural roids are nice in that their Octree save data starts very small (~2kb even for large roids) and grows only as it's changed (mined). With a lot of deformation, they can grow to be just as large as the prefabs, but when this happens an admin can simply delete the file and they will be regenerated in their untouched, very small state. (Said admin should of course ensure no grids or other objects are in the area of regeneration to avoid placing intersecting objects into the world, which can cause tremendous lag as we see with the encounters bug.) The disadvantage here is that you still lose control over the placement of asteroids in your map. Want to confine them to a 100km sphere around the center but still have a 500km map? Too bad. Want to make cool patterns, or carve out strategically interesting sectors? Out of luck.
My solution to this issue has been to create procedural asteroids in a procedural world, save them, and then manually import, duplicate, and place them into a non-procedural world in the pattern I'd like. When they grow too large, I delete and re-import them using backups of the files. This works well but is very manual and can currently only be accomplished by using external tools to alter save files.
Thus I opened up this issue with the intention of adding functions that support: