Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zenith indicator pointing somewhere wrong #4587

CylonicRaider opened this issue May 12, 2019 · 4 comments


None yet
3 participants
Copy link

commented May 12, 2019

Observed behavior

The zenith indicator does not always point away from the current reference body. The deviation varies from nearly none to rather extreme, with a sample leaning towards the latter seen in the following screenshot:

Zenith indicator pointing the wrong way

(observe how the indicator is some mere (estimated) 30° away from the nadir).

Expected behavior

The zenith indicator should always point away from the current reference body.

Steps to reproduce

As noted in #4583 (comment),

  1. Start a new game on Mars.
  2. Blast off and use the autopilot to enter a low orbit around Mars (time acceleration may be used to reduce your wait).
  3. Point the ship's bow at the zenith indicator: Ensure you are looking forward (w.r.t. the ship); holding the right mouse button, move the mouse until the yellow double circle [and the forward direction indicator] coincides with the zenith indicator.
  4. Look backward (w.r.t. the ship; in a default install, this is bound to the Down arrow key).
  5. Observe how the icon representing Mars (a dot with the text “Mars” besides it) is not in the center of the reticule.

Remark that this does not lead to as extreme an instance of this bug as the screenshot above. (Perhaps, entering and leaving the frame of an in-orbit starport might “help”.)

My Pioneer version

Observed on the current commit of #4583, i.e. be341d4, (where the screenshot was taken) and on current master, i.e. ea01264. If my memory serves me right, this bug is, however, much older than either commit.


This comment has been minimized.

Copy link

commented May 13, 2019

Fairly straightforward error. displayFrameIndicators in game.lua calls the function:

local awayFromFrame = player:GetPositionRelTo(frame) * 1.01

A->GetPositionRelTo(B) returns the relative position in B's frame. In this case, B is the planet, and planets are placed in the rotating frame. As the camera is outside the rotating frame, that's not what you want. Semi-correct version is:

local awayFromFrame = -frame:GetPositionRelTo(player)

I'm not sure what the reason was for the 1.01, but it's probably not a good one.

I say "semi-correct" because UI code should be using interpolated rather than physics positions and orientations to avoid jitter, but I'm not sure whether that functionality has been exposed to lua.

Edit: Forgot minus sign.


This comment has been minimized.

Copy link
Contributor Author

commented May 13, 2019

The incorrect local awayFromFrame = ... was introduced in commit 3fe0836 as part of #3868, with — apparently — no equivalent having existed before.


This comment has been minimized.

Copy link
Contributor Author

commented May 13, 2019

@jaj22's “semi-correct version” works well for me; in which way is it only semi-correct?


This comment has been minimized.

Copy link

commented May 15, 2019

I'm just guessing @jaj22 refers to these functions:


Lines 91 to 104 in d4c1ba4

const matrix3x3d &GetInterpOrient() const { return m_interpOrient; }
vector3d GetInterpPosition() const { return m_interpPos; }
vector3d GetInterpPositionRelTo(const Frame *relTo) const;
vector3d GetInterpPositionRelTo(const Body *relTo) const;
matrix3x3d GetInterpOrientRelTo(const Frame *relTo) const;
// should set m_interpolatedTransform to the smoothly interpolated value
// (interpolated by 0 <= alpha <=1) between the previous and current physics tick
virtual void UpdateInterpTransform(double alpha)
m_interpOrient = GetOrient();
m_interpPos = GetPosition();

And to the fact that these functions should be used during render calls
because rendering isn't in sync with physics updates. Thus when render
happens these functions should be used instead of the "physical"


void Camera::Update()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.