No initial Frame of Reference when jumping from Sol to Sirius

[kennworl]

I don't know if this is a code bug, design flaw or meant to be like this, but when I jump from Sol system to Sirius system, I have no initial Frame of Reference set, yet I have heading, pitch and roll values around the reticule.

Happens every time. Using the Windows 28 Aug std build, start a new game in London. Launch, select Sirius in the sector map. Go back to World view, and hit the hyperspace icon. When you arrive in the middle of nowhere in the Sirius system, the reticule has no frame or nav target info.

I would expect there to always be frame of reference, being the biggest star in the system, given that you are never in interstellar space.

[bszlrd]

Just checked, I can confirm it on windows. Aug 28 build. It seems to happen for binary systems. For Epsilon Eridani it shows the star as frame, but for Toliman or Sirius it shows nothing. Ctrl+i info screen shows "System" as reference in all of them. The old HUD said "System" after jumps when you were still far out. Maybe because binary+ systems have a common gravitational center?

[fluffyfreak]

N-ary systems use a grav-point as their root. It doesn't have a name or anything since it's a notional/logical construct that we have in the code to organise systems. Does pose an interesting question of what we should actually display in this case!

[impaktor]

Does pose an interesting question of what we should actually display in this case!

"System centre of mass"?

[fluffyfreak]

Or disable the heading, pitch and roll display when it's a grav point

[kennworl]

Ok, so what is the consensus here? The reason I bring this up is that my hardware console I'm building expected there to always be an FoR. I like the idea of "System centre of mass" being displayed as we could assume it is a arbitrary body which would then allow h/p/r angles displayed to make sense. Just don't leave it blank. This would seem to be the easiest logical fix for this one.

[impaktor]

Those with understanding of c++ core would be the right ones to decide, so @jaj22 / @fluffyfreak or @ecraven / @laarmen I presume.

[jaj22]

There are (at least theoretically) gravpoints that are not the "system centre of mass". The game has a convention for gravpoint names already (eg. "Sirius A,B") but only uses it for child bodies at the moment. Original reason might just be to avoid drawing the labels on-screen.

[impaktor]

Original reason might just be to avoid drawing the labels on-screen.

Interesting, as we since a couple of weeks back only draw icons.

[jaj22]

Ok, here's how it works:

1. Gravpoints do have labels. The root sbody in Sirius is called "Sirius A,B".
2. Space::MakeFrameFor normally copies the sbody label to the frame (even for gravpoints), but it doesn't for the root frame. Hence the root frame retains the label Lang::SYSTEM.
3. The Lua UI reads the frame body label, not the frame label or the frame sbody label. Ctrl-i reads the frame label directly.
4. Gravpoints have frames but not bodies, so there is no frame body label to read for binary systems.

At the C++ level there's no issue, except for point 2 where the root frame should probably be given the sbody label. The Lua UI only works with bodies, not frames, so it's currently incapable of dealing with gravpoints.

[ecraven]

1. Gravpoints do have labels. The root sbody in Sirius is called "Sirius A,B".
2. Space::MakeFrameFor normally copies the sbody label to the frame (even for gravpoints), but it doesn't for the root frame. Hence the root frame retains the label Lang::SYSTEM.
3. The Lua UI reads the frame body label, not the frame label or the frame sbody label. Ctrl-i reads the frame label directly.
4. Gravpoints have frames but not bodies, so there is no frame body label to read for binary systems. At the C++ level there's no issue, except for point 2 where the root frame should probably be given the sbody label. The Lua UI only works with bodies, not frames, so it's currently incapable of dealing with gravpoints.

Thanks for the detailed explanation!

I think the main question is do we

a) want to display the data and the gravpoint name? b) not display anything until you enter the frame of an actual body?

either shouldn't be too hard to implement, really just a question of preference. I'd lean a bit toward not showing the data in question until closer than some distance (half an AU or so?) Are there cases where you need to see it far away from anything?

[kennworl]

Looking at this another way, would you want to navigate to a non--body gravpoint for any reason? If not, then there is no point exposing the concept to the pilot via navPoint or FoR, and that is the question answered. So, why would you want to there? Well, given the newtonian physics model, I assume it is a gravitationally stable (lagrange?) point in a binary+ system (presumably one of very few), and if you ever wanted a place to set up a station in system (X3 style) that wasn't on or in orbit of an actual body, that would be a candidate, assuming it was habitable. Given that type of gameplay is not going to happen soon, then I tend to agree with ecraven and hide it (along with the h/p/r) values.

[fluffyfreak]

The gravpoint isn't a physical location per-se, it's not a lagrange point or null gravity area. Notionally it might be the point where two or more Stars commonly orbit but only if those Stars are in the same orbit and have the same mass with exactly opposite phase etc.

Really it is best to just treat it as the games internal, best not to be exposed, way of organising systems with multiple stars given that we require a single common root.

If it comes up then best to hide it and related info.

"Grav point" really strikes me as the wrong name for it.

[laarmen]

Wasn't there a way to specify the reference start when jumping? If so, then perhaps when jumping in binary systems we could arbitrarily pick the first star as the reference one (which, I assume, would make the jump arrive into its frame) ?

On Mon, Sep 25, 2017 at 11:13 AM Andrew Copland notifications@github.com wrote:

The gravpoint isn't a physical location per-se, it's not a lagrange point or null gravity area. Notionally it might be the point where two or more Stars commonly orbit but only if those Stars are in the same orbit and have the same mass with exactly opposite phase etc.

Really it is best to just treat it as the games internal, best not to be exposed, way of organising systems with multiple stars given that we require a single common root.

If it comes up then best to hide it and related info.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/pioneerspacesim/pioneer/issues/4164#issuecomment-331823222, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkONe7srLWbABsxVNniAo7wA8r39Ppeks5sl263gaJpZM4PfNAk .

[kennworl]

FluffyFreak is correct. It is the Centre of Mass of the system, and has no real bearing on gravity. There is no need to expose it. So just have a FoR come up when you are being significantly affected by a gravitational source (or the strongest one if multiple). This is seemingly what happens now.

The FoR is to allow navigation around a spherical surface. However, once you leave orbit, the FoR heading, pitch, and roll figures start losing significance and certainly should be hidden if there is no FoR displayed.

So I vote we just hide the h/p/r figures once the FoR blanks.

The other related issue is that of how single star and multi-star systems are treated differently. I jumped into the Sirius system, and autopiloted the 14AU to Fan colony (moon). The first FoR I picked up was Sirius A,B a at 0.1AU distance, Then Fan Colony itself at roughly 15.5 Mm. On the way back out, it did roughly the same thing as you would expect, including blanking out the FoR once I got past Sirius A,B a.

All good, but then I tried that from Earth and my FoR had still locked on to Sol at 200AU. Not very useful. Can we make the behaviour consistent with multi-star systems? (I think I read somewhere that single star systems are actually in the minority)

laarmen's suggestion about picking hyperspace destinations by FoR only works if the FoR has a limited area. So if you picked anywhere in Sirius, it would get you there with respectable accuracy. Same for the Sol system, unless you picked Sol itself, in which case you might get dumped 200AU away :-(

Bottom line. Request 1: don't display h/p/r values without a FoR (doesn't make any sense to do so) Request 2: limit FoR range in single-star systems the way it happens in multi-star systems.

Opinions?

[jaj22]

It is the Centre of Mass of the system, and has no real bearing on gravity.

This is the biggest navigational inconsistency. You cannot orbit on the same path as Sirius A,B a, because gravpoints have no gravitational effect on dynamic bodies. They probably should, although the effects may get a bit weird near the binary pair.

BTW, I accidentally broke kennworl's post. I think I put it back correctly.

[kennworl]

BTW, I accidentally broke kennworl's post. I think I put it back correctly.

jaj22, if you hadn't have told me, I wouldn't have noticed, so well done. :-)

You have to draw the line on the simulation somewhere. Pioneer is marketed as a game, not a simulator. I think we should be focussing more on the game aspects than this stuff. I just want the simulation shortcuts to not be advertised (hence my 2 requests which are hopefully easy to do in Lua)

[Bodasey]

fixed

Choose the right component in the sector map, hyperjump there, you get the belonging Frame of reference on arrival.