The RMS (actually the OV) has to be the parent, so it can move the child around.so if the MMU is parent to the Stinger, the RMS cant grapple to be parent to the Stinger as well? could the Stinger be the parent object instead?
The RMS (actually the OV) has to be the parent, so it can move the child around.so if the MMU is parent to the Stinger, the RMS cant grapple to be parent to the Stinger as well? could the Stinger be the parent object instead?
Thinking about it, I'd say no...so is this kind of setup just not possible with how Orbiter attachment points function?
My guess is yes... but maybe a small test to confirm it works isn't a bad idea.would docked vessels with attachment points work instead or is it just not viable any way its done?
Hmm, in the sills or keel? The existing positions were fixed, and the payloads had to adapt to them.Can we define custom payload latch positions like the cameras, or could that be implemented in the future?
What is the attachment configuration: is it attached to anything else? Parent, child?any idea why a payload vessel would spawn in with NaNs for the position in the scenario when its installed in the payload bay?
nope. just setup as an active payload in the mission editor. attached to the keel with 1 latch (for testing right now). i can spawn the vessel in just fine with scenario editor.What is the attachment configuration: is it attached to anything else? Parent, child?
Is the attachment ID in the PL edit dialog valid? Are the attachments "manipulated" by the vessel, i.e., created or deleted other than at the vessel creation?nope. just setup as an active payload in the mission editor. attached to the keel with 1 latch (for testing right now). i can spawn the vessel in just fine with scenario editor.
User error smh. I accidentally left the rotation vector as all zeros...Is the attachment ID in the PL edit dialog valid? Are the attachments "manipulated" by the vessel, i.e., created or deleted other than at the vessel creation?
Without the GPC, SCA, etc, it comes down to this:does anyone have a good source for PAM deploy procedures? I'm aware flights that used them had checklists, but none are available online from my looking.
If only it were as simple as making the displays... there's at least one process behind each of those SPECs, that needs to get data from and send command to a box connected to bus PL-1 and/or 2, and that is where the payload interfaces. Plus, you might also have the Standard Switch Panel for certain commands, and backups.whenever the time is right for the DPS Pages for payloads, this looks like a good reference for them: https://edan.si.edu/slideshow/viewer/?eadrefid=NASM.2014.0025_ref156
configure as in how to determine when it is allowed to display what DPS pages depending on the payloads?If only it were as simple as making the displays... there's at least one process behind each of those SPECs, that needs to get data from and send command to a box connected to bus PL-1 and/or 2, and that is where the payload interfaces. Plus, you might also have the Standard Switch Panel for certain commands, and backups.
The PAMs will need most of this, so that will open the way. Not that this is easy, but the thing I'm most concerned about is: how to configure all of this???
Yes, plus which code to run, connected to where, which SSP to show, where, connected to where... the Shuttle had so many options, that it's like lego for engineers.configure as in how to determine when it is allowed to display what DPS pages depending on the payloads?