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

Click-spots corruption at scenario start from VC #671

Open
jalexb88 opened this issue Jan 9, 2022 · 2 comments
Open

Click-spots corruption at scenario start from VC #671

jalexb88 opened this issue Jan 9, 2022 · 2 comments
Assignees
Labels
bug Orbiter's fault This is an issue with Orbiter that we can't fix virtual cockpit

Comments

@jalexb88
Copy link
Contributor

jalexb88 commented Jan 9, 2022

There is an issue right now in both CM and LM virtual cockpits. If you load a scenario that is already in the VC, the click-spots are not defined correctly, so all the controls/switches are unusable. The temporary fix for this is to simply use the CTRL-Arrow keys to change to a different viewpoint and back and it is fixed. Oddly, this issue does not happen on Apollo 5,7 & 8, so only on scenarios that have both CSM & LM present. There must be some interference somehow between the 2 vehicles but I have not yet found the culprit.

@jalexb88 jalexb88 added the bug label Jan 9, 2022
@jalexb88
Copy link
Contributor Author

jalexb88 commented Jan 11, 2022

So the plot thickens... I have been investigating this more and have discovered that the issue happens with the ShiftCG(CoGShift); call in UpdateMassAndCoG() function. This seems to be the case for that function in both vehicles (CSM&LM). As a test I commented the calls of that function and that makes the click-spots load fine when starting from the VC.

Its gets weirder... The click-spots seem to be getting messed up in the other vehicle then the one where the UpdateMassAndCoG() is called. IE. If I just comment out the UpdateMassAndCoG() in LM but leave the CSM one alone, then its the CSM VC that has the click-spots messed up at loading, and vice versa. @indy91 Any ideas about this?

@jalexb88
Copy link
Contributor Author

jalexb88 commented Jan 12, 2022

Ok I think this might be an Orbiter bug...

To put it simply I am seeing that ShiftCG seems to be changing the click-spot position of EVERY vessel's switches registered in the session...not just the switches of the vessel its called in. Its not until clbkLoadVC is passed again (such as with the ctrl-arrow keys), or called when switching from 2D panel to VC that the switch positions of the non-intended vessel are corrected.

Another way to see this issue in action: Take a session with both CSM & LM present, start the main engine of either one of them then switch to the other vessel's VC. You will notice that initially the click-spots are working, but after a few seconds when the ShiftCG() of the burning (other) vessel is called again, this vessel's click-spots stop working.

For further testing I added some code in the Deltaglider timestep, a very small ShiftCG done once to see if the issue happens there. I made a scenario with only 2 Deltaglider's and the issue does happen there too once the ShiftCG is called, I remove 1 of the Deltagliders from the scenario and the issue disappears.

Edit: here is a link to the Orbiter Forum post: https://www.orbiter-forum.com/threads/orbiter-beta-r90-suspected-bug-with-shiftcg-call-and-vc-click-spots.40308/

Edit 2: A possible Orbiter fix to this may be here: orbitersim/orbiter@40d6a63
Note: This has not been tested with NASSP yet

@jalexb88 jalexb88 added the Orbiter's fault This is an issue with Orbiter that we can't fix label Jan 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Orbiter's fault This is an issue with Orbiter that we can't fix virtual cockpit
Projects
None yet
Development

No branches or pull requests

3 participants