SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

Status
Not open for further replies.
Payload mass and vessel mass don't seem to affect this bug.
I still haven't compared the RMS and SSRMS code.... I'm kinda of lethargic at the moment... :tumbleweed:
 
Hope you're feeling better.
 
I looked at the code and the RMS and SSRMS seem to operate the same way... :shrug:
I'll now look at the default Atlantis code, maybe we are doing something wrong and the problem doesn't show in the SSRMS because of some other factor.
 
I looked at the code and the RMS and SSRMS seem to operate the same way... :shrug:
I'll now look at the default Atlantis code, maybe we are doing something wrong and the problem doesn't show in the SSRMS because of some other factor.

what about you temporarily override the SetAttachmentParams method and log all changes to the vectors (only changes and simt) into the Orbiter.log for being sure, all runs well.

I would not even be surprised, if we actually observe rounding errors and just need to reorganise the code to eliminate them. But don't ask me about where they are now...
 
I played with it last week and I didn't notice any problems...
I checked the Atlantis code and it does things pretty much in the same way, although some calls made at different times, but if it has the same problem then I'd say those differences aren't the source of the problem.

what about you temporarily override the SetAttachmentParams method and log all changes to the vectors (only changes and simt) into the Orbiter.log for being sure, all runs well.

I would not even be surprised, if we actually observe rounding errors and just need to reorganise the code to eliminate them. But don't ask me about where they are now...
I checked to see we weren't feeding INFs and NANs to SetAttachmentParams() and nothing was detected.
If the problem is rounding errors, then I'd say it's inside Orbiter, as we just move the joints by SetAnimation(), and then take the MAKEGROUPARRAY data (updated by Orbiter based on the joint animation) and send it to SetAttachmentParams().
 
If the problem is rounding errors, then I'd say it's inside Orbiter, as we just move the joints by SetAnimation(), and then take the MAKEGROUPARRAY data (updated by Orbiter based on the joint animation) and send it to SetAttachmentParams().

I agree there. And if it can be reproduced in Vanilla Atlantis, it is very likely not just a problem on our side.
 
Well DaveS, you found the problem in the default Atlantis, you write the bug report for this. :P

A bug report I'd like to write is about click areas not working... any ideas on that one?
 
Well DaveS, you found the problem in the default Atlantis, you write the bug report for this.
Official bug report has been filed.

---------- Post added at 09:18 PM ---------- Previous post was at 08:30 PM ----------

Official bug report has been filed.
And now jgrillo2002 has reported that the same problem exists even with the Shuttle Fleet, so this is most likely a problem with Orbiter. Why the SSRMS doesn't have it, is still a mystery though.
 
Official bug report has been filed.

---------- Post added at 09:18 PM ---------- Previous post was at 08:30 PM ----------


And now jgrillo2002 has reported that the same problem exists even with the Shuttle Fleet, so this is most likely a problem with Orbiter. Why the SSRMS doesn't have it, is still a mystery though.

Maybe it is a matter of coordinate system / task frame?
 
And now jgrillo2002 has reported that the same problem exists even with the Shuttle Fleet, so this is most likely a problem with Orbiter. Why the SSRMS doesn't have it, is still a mystery though.

5 animations vs 7 animations, and/or the attachment isn't being placed in the correct (or in this case wrong) attitude? :shrug:
 
Has anyone called the Doctor ?
 
Can I get a tutorial on using the CRT ? Which MFD does it work with and do I still need to check the CRT on in the modules ?
 
Can I get a tutorial on using the CRT ? Which MFD does it work with and do I still need to check the CRT on in the modules ?
If you're using the beta 2016 modules, then CRTMFD is obsolete and no longer necessary. All of the functionality of CRTMFD is now integrated into the main SpaceShuttleUltra module.
 
... and the first question ?
 
... and the first question ?

Well... what kind of tutorial do you need there? The various modes of a MEDS MDU? How to enter commands or data in CRT mode?
 
If I want to set up an attitude for station keeping on the R-bar.
 
If I want to set up an attitude for station keeping on the R-bar.

So, you just need to translate your desired task into the tools of the Space Shuttle:

Keep any attitude ==> UNIV PTG, G201 "Universal pointing"

So, you need an IDP/CRT combination which is connected to a GPC using the GNC major function software in OPS2. You select this by the switches on the central pedestral. If you select another major function by the switches, the IDP will select another GPC which is running the software you want.

Now, you can enter OPS 201 PRO in your keyboard, if you need to switch the major function. In Orbit, you usually don't need that, it should be in 201 most of the time.

Now when you see this rather overcrowded display, the important question is: What kind of attitude do you need? By answering this question, can be mentally start to ignore many options, because you don't need them.
 
Status
Not open for further replies.
Back
Top