Dies ist also ein Problem, auf das ich sowohl in 1.6.1 als auch in 1.7 gestoßen bin. Wenn Sie einen Schwerpunkt für einen binären (kleinen) Planeten definieren, weist Celestia diesem Referenzpunkt zufällig eine Objektklasse zu. Zum Beispiel behandelt Celestia beim Definieren eines Schwerpunkts für eine binäre TNO diese so, als ob sie die Klasse "Mond" gemäß den Bezeichnungen und Bahnen hätte. Dies tritt nicht bei jedem so definierten Kleinplaneten auf und kann sich sogar nach Neustarts ändern, also wirklich unvorhersehbar.
Vor kurzem habe ich begonnen, Schwerpunkte mit der Klasse "unsichtbar" zu definieren, wie es bei Pluto-Charon standardmäßig der Fall ist, aber dieses Problem trat auch bei der Verwendung der "ReferencePoint"-Definition auf.
Es gibt auch das Temperaturproblem bei Planeten, die Schwerpunkte umkreisen.
Es gibt auch das Temperaturproblem bei Planeten, die Schwerpunkte umkreisen.
Es gibt auch den Parameter TempDiscrepancy
, der verwendet werden kann, um dies zu korrigieren.
Wenn 1.6.2 aktualisierte Daten haben soll (#699), muss dieser Fehler auch für 1.6.2 behoben werden, ansonsten wird das Orcus-Vanth-Schwerpunktzentrum wie ein Mond statt eines Asteroiden behandelt.
@Panterstruck bitte geben Sie Testdaten für diesen Fehler an.
"Orcus-Vanth" "Sol"
{
Class "invisible"
Visible true
Clickable true
OrbitFrame { EclipticJ2000 { Center "SSB" } }
EllipticalOrbit
{
Epoch 2457388.5 # 1.1.2016
Period 247.185 # 246.0163 at epoch, plutino
SemiMajorAxis 39.279
Eccentricity 0.223855
Inclination 20.5675
AscendingNode 268.584
ArgOfPericenter 73.020
MeanAnomaly 174.476
}
}
"Orcus:90482 Orcus:2004 DW" "Sol"
{
Class "asteroid"
Radius 455
Texture "asteroid.*"
Color [ 0.835 0.839 0.831 ]
BlendTexture true
GeomAlbedo 0.231
LunarLambert 0.5
BodyFrame { EclipticJ2000 { Center "Sol/Haumea System" } }
UniformRotation
{
Period 10.4 # high uncertainty
Inclination 90.2 # assuming spin axis matches Vanth's orbit
AscendingNode 50.0
}
OrbitFrame { EclipticJ2000 { Center "Sol/Orcus-Vanth" } }
EllipticalOrbit
{
Period 9.5393
SemiMajorAxis 740 # assuming mass ratio Vanth:Orcus 0.09
Eccentricity 0.007
Inclination 90.2
AscendingNode 50.0
ArgOfPericenter 185.5
MeanAnomaly 143.1
Epoch 2454439.2807
}
}
"Vanth:(90482) Orcus I Vanth:S/2005 (90482) 1" "Sol/Orcus"
{
Class "moon"
Radius 220
Mesh "roughsphere.cms"
Texture "asteroid.*"
Color [ 0.62 0.56 0.50 ] # "slightly red", assuming similar color to Quaoar
BlendTexture true
Albedo 0.10 # estimate
LunarLambert 0.5
BodyFrame { EclipticJ2000 { Center "Sol/Haumea System" } }
UniformRotation
{
Inclination 90.2 # assuming spin axis matches Vanth's orbit
AscendingNode 50.0
}
OrbitFrame { EclipticJ2000 { Center "Sol/Orcus-Vanth" } }
EllipticalOrbit
{
Period 9.5393
SemiMajorAxis 8240
Eccentricity 0.007
Inclination 90.2
AscendingNode 50.0
ArgOfPericenter 5.5
MeanAnomaly 143.1
Epoch 2454439.2807
}
}
Ja, das wird reichen. Es ist wirklich schwer, in Screenshots anzugeben, und es erfordert, dass Sie die Sichtbarkeit von objektklassenspezifischen Umlaufbahnen ändern. Und es ist nicht vollständig reproduzierbar, bei einem Start könnte es wie beabsichtigt funktionieren, manchmal kann das Baryzentrum als Mond gelten.
Ich frage mich, warum es diesen Code gibt, der das "Haumea-System" erwähnt:
BodyFrame { EclipticJ2000 { Center "Sol/Haumea System" } }
Das ist seltsam. Ich habe gerade den Code von Project Echoes kopiert, aber ich habe das gleiche Problem mit Code für Orcus-Vanth gesehen, der sich nicht auf Haumea bezieht.
Ich kopiere das Orcus-Vanth-System vom Haumea-System und gehe von dort aus. Aber ja, es passiert buchstäblich bei jedem kleinen Planeten, der ein Schwerpunktzentrum verwendet. Als ich vorhin geantwortet habe, wollte ich einen Screenshot vom Manwë-Thorondor-System einreichen, das ich überprüft habe, dieser fehlerhafte Verweis nicht enthält, ihn jedoch verwarf, da Screenshots ohne Videoaufnahme von Drittanbietern nicht hilfreich waren.
Hilfreichster Kommentar