You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I can tell, the stock asteroid/comet model works as follows. When an asteroid/comet is spawned, it is assigned a size class. Asteroids can have classes A through E, while comets can have classes F through I (although can also be assigned asteroid size classes). Each size class has a fixed scale modifier that is applied to the asteroid/comet model, followed by some random variation, bounded by minRadiusMultiplier and maxRadiusMultiplier in ModuleAsteroid. A asteroid/comet of the desired scale is then generated by the game, and placed in orbit.
In order to increase the scale of asteroids to more realistic levels, RSS sets minRadiusMultiplier and maxRadiusMultiplier to 10 and 100, respectively. The issues with this system as it is configured for RSS are described below.
Asteroids can generate with a radius greater than 2250 meters, resulting in the player appearing under their surface when they load into physics range. Should be resolved by Greatly increase asteroid load and unpack distances #292 greatly increasing asteroid load ranges.
The asteroid/comet generation code doesn't create particularly accurate colliders. While a few percent misalignment may be acceptable for asteroids of a few meters, if kilometer-scale asteroids are created, they can have the colliders dozens of meters from the visible surface of the asteroid/comet. This seems to be a lesser issue for comets, as they were intended to be quite a bit larger in stock.
The scale of asteroid/comet classes appears to be fixed. The asteroid classes A through E have fixed scale modifiers, with a roughly 10x difference between the largest and smallest. This means that since the random variation (minRadiusMultiplier and maxRadiusMultiplier) also differ by ~10x, it is possible for the game to generate an A class and E class asteroid of the same size. Furthermore, it is almost impossible to represent the full size variation of asteroids (meter to kilometer scale) without setting an extremely wide random variation. Even as is, the random scale variation is enough that the asteroid size class tells the player almost completely nothing about the asteroid in question unless they visit it.
Comet size classes are not the same as asteroid size classes. Comets presumably have a much larger "base" size, and so need a much smaller size modifier in order to reach the same size as an asteroid. This means asteroids assigned to comet size classes (F through I) won't be much larger than asteroids assigned an E class, while comets assigned asteroid size classes (A through E) won't be much smaller than comets assigned an F class. Although there doesn't appear to be a way to make asteroids spawn in anything other than A through E, comets can be assigned any class range, and can also be assigned asteroid models, which is used by the RSS asteroid presets to spawn asteroids in comet size classes.
In conclusion, in the current state of RSS, asteroids/comets have no way for the player to know what size they really are, and almost exclusively generate at scales ranging from difficult to interact with (due to collider misalignment and sheer mass) to impossible to interact with (due to the player craft loading inside the asteroid and being immediately destroyed). This makes interacting with asteroids/comets a pretty un-fun experience for the player.
The text was updated successfully, but these errors were encountered:
RSS 20.1.2.0 - KSP 1.12.5; There seem to be more funky issues with (what I can only assume is caused by) asteroid collision. Being near a 9bn tonne asteroid seems to cause it to move, rotate wildly, or disappear when there's something attached to it, even if that object appears to be attached to the surface of the asteroid. In one case it went into a very different orbit.
(this could also be a base-KSP bug, but I figure add it here since I can't find any reference to the same issue for stock KSP 1.12)
As far as I can tell, the stock asteroid/comet model works as follows. When an asteroid/comet is spawned, it is assigned a size class. Asteroids can have classes A through E, while comets can have classes F through I (although can also be assigned asteroid size classes). Each size class has a fixed scale modifier that is applied to the asteroid/comet model, followed by some random variation, bounded by
minRadiusMultiplier
andmaxRadiusMultiplier
inModuleAsteroid
. A asteroid/comet of the desired scale is then generated by the game, and placed in orbit.In order to increase the scale of asteroids to more realistic levels, RSS sets
minRadiusMultiplier
andmaxRadiusMultiplier
to 10 and 100, respectively. The issues with this system as it is configured for RSS are described below.minRadiusMultiplier
andmaxRadiusMultiplier
) also differ by ~10x, it is possible for the game to generate an A class and E class asteroid of the same size. Furthermore, it is almost impossible to represent the full size variation of asteroids (meter to kilometer scale) without setting an extremely wide random variation. Even as is, the random scale variation is enough that the asteroid size class tells the player almost completely nothing about the asteroid in question unless they visit it.In conclusion, in the current state of RSS, asteroids/comets have no way for the player to know what size they really are, and almost exclusively generate at scales ranging from difficult to interact with (due to collider misalignment and sheer mass) to impossible to interact with (due to the player craft loading inside the asteroid and being immediately destroyed). This makes interacting with asteroids/comets a pretty un-fun experience for the player.
The text was updated successfully, but these errors were encountered: