Portanto, este é um problema que encontrei no 1.6.1 e no 1.7. Se você definir um baricentro para um planeta binário (menor), Celestia dará aleatoriamente a este ponto de referência uma classe de objeto. Por exemplo, ao definir um baricentro para um TNO binário, Celestia o trata como se tivesse a classe "lua" de acordo com rótulos e órbitas. Isso não ocorre com todos os planetas menores definidos dessa forma e pode até mudar após reinicializações, de modo realmente imprevisível.
Recentemente, comecei a definir baricentros usando a classe "invisível" como no caso de Plutão-Caronte por padrão, mas esse problema também ocorria ao usar a definição de "Ponto de Referência".
Há também o problema da temperatura com planetas orbitando baricentros.
Há também o problema da temperatura com planetas orbitando baricentros.
Também existe o parâmetro TempDiscrepancy
que pode ser usado para corrigir isso.
Se 1.6.2 vai ter dados atualizados (# 699), este bug precisará ser corrigido para 1.6.2 também, caso contrário, o baricentro Orcus-Vanth será tratado como se fosse uma lua em vez de um asteróide.
@Panterstruck forneça dados de teste para este bug.
"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
}
}
Sim, isso vai servir. É realmente difícil se exibir em capturas de tela, assim como requer que você verifique a visibilidade das órbitas específicas da classe de objeto. E não é totalmente reproduzível, um lançamento pode funcionar como pretendido, outras vezes o baricentro pode contar como uma lua.
Estou me perguntando por que existe esse trecho de código mencionando o "Sistema Haumea":
BodyFrame { EclipticJ2000 { Center "Sol/Haumea System" } }
Isso é estranho. Acabei de copiar o código do Projeto Echoes, mas vi o mesmo problema com o código do Orcus-Vanth que não fazia referência a Haumea.
Sou eu copiando o sistema Orcus-Vanth do sistema Haumea e partindo daí. Mas sim, isso acontece literalmente com qualquer planeta menor que usa um baricentro. Quando respondi anteriormente, queria enviar uma captura de tela do sistema Manwë-Thorondor que verifiquei, não tem essa referência com defeito, mas a rejeitei porque as capturas de tela não ajudavam muito sem a captura de vídeo de terceiros.
Comentários muito úteis