New Release Crew Dragon 2022

Hi,
@General_Mile_1 pointed out that the bug "orbit changes when docking ring is retracted/extended while docked" was still happening ( I thought I had fixed it) .

The "crewdragon2022_patch_250925.zip" attached below should really fix it (I hope).
It contains a new dm2_capsule.dll .

If anyone gives it a try, do let me know if it works for you.
Many thanks!

Cheers,
BrianJ
 

Attachments

Sorry, but I get orbit lowering when the docking ring was extended or retracted and Dragon was docked to another vessel.
Dragon orientation was retrograde. Both extending or retracting the ring lowered the orbit.

I also tested the version from Orbiter Downloads (241113). Same result. Both actions lowered the orbit.
 
Sorry, but I get orbit lowering when the docking ring was extended or retracted and Dragon was docked to another vessel.
Dragon orientation was retrograde. Both extending or retracting the ring lowered the orbit.

I also tested the version from Orbiter Downloads (241113). Same result. Both actions lowered the orbit.
Thanks very much for testing! (y)
I had a feeling the fix was too easy.
I think the severity of the effect depends on orientation, relative vessel masses, frame rate.
One more idea I can try, if that doesn't work then I guess I'll go with spawning an attach point on the other vessel etc. but that has its drawbacks 🤷‍♂️

If anyone has a good solution for the "moving docking port" problem that I have missed, please do let me know.

Thanks,
BrianJ
 
Could you leave the docking ring in place all the time (in relation to the vessel mass center), and just gradually shift the z-offset of the capsule mesh, so the capsule is 'moving' relative to the ring?
 
Thanks very much for testing! (y)
I had a feeling the fix was too easy.
I think the severity of the effect depends on orientation, relative vessel masses, frame rate.
One more idea I can try, if that doesn't work then I guess I'll go with spawning an attach point on the other vessel etc. but that has its drawbacks 🤷‍♂️

If anyone has a good solution for the "moving docking port" problem that I have missed, please do let me know.

Thanks,
BrianJ
Hey, it's the method of undocking, changing the docking port location and docking right? I ran into that issue too, IIRC it was a GetElements (on the target) before Undock and SetElements after Dock that fixed it, so that the orbital elements are kept. Otherwise all the teleporting of one vessel to another with the fact Undock creates a separation rate means the orbital velocity is technically changing every frame and it adds up quick.
 
Thanks very much for the ideas! (y)
Could you leave the docking ring in place all the time (in relation to the vessel mass center), and just gradually shift the z-offset of the capsule mesh, so the capsule is 'moving' relative to the ring?
I might give that a try - but I have a feeling that the VC "switchable" areas and possibly other stuff may not be included in the ShiftMesh or ShiftCG methods - which will be an almighty pain to fix! But I'll keep that idea in mind. Thanks.

Hey, it's the method of undocking, changing the docking port location and docking right? I ran into that issue too, IIRC it was a GetElements (on the target) before Undock and SetElements after Dock that fixed it, so that the orbital elements are kept.
I have been using that method but with GetStatus() and DefSetState(), rather than using Elements.
I have tried initiatlng docking/undocking from Dragon, and from the target vessel.
I have tried modifying the Dragon RelativePosition after Undocking so that the docking ports always coincide.

Using Elements instead is pretty easy anyway. I'll give it a try.

I do wonder whether it depends on the order of vessels in the scenario (which vessel gets its state updated first).

And it's not so easy to get an accurate picture of whats going on - I'm using the "DM2 Undocking" scenario, with non-spherical gravity disabled - and it doesn't show much effect on ISS unless you do it repeatedly at >10x time accel.
Keeps fooling me into thinking its fixed.

Otherwise all the teleporting of one vessel to another with the fact Undock creates a separation rate means the orbital velocity is technically changing every frame and it adds up quick.
Yep, thats the issue, together with the fact that Orbiter calculates the resultant momentum for the docked "SuperVessel" (I believe).

I shall try some more experiments and report back.
Many thanks for the input.
Cheers,
Brian
 
Would it make any difference if the ISS was set to "free drift" ?
 
Would it make any difference if the ISS was set to "free drift" ?
Hi Don,
I don't think so. I use the stock ISS anyway, which doesn't have any attitude functions like that.
Do you see this "orbit change" effect when using the Crew Dragon? Its only very minimal for me using the stock ISS.
I can't remember if we encountered this effect before, or whether we decided it wasn't worth bothering about, or what the resolution was!
Cheers,
Brian
 
Well, I've tried every different variation I can think of and I'm not getting anywhere with this.

My method is basically:
Get vessel status/elements
Undock
Move dock port
Set vessel status/elements
Dock
Set vessel status/elements

I tried doing everything in clbkPreStep{...}, tried setting the VESSELSTATUS or ELEMENTS in clbkPostStep{...} and clbkDockEvent{...}, tried initiating the Dock/Undock from Dragon or target vessel, tried different Dock modes.

Nothing improves the situation (although some things make it worse).

@diogom would it be possible to have a look at the code you used to fix this problem?

Many thanks,
BrianJ
 
Hi,
after banging my head on a brick wall for hours with variations on the method I outlined above, I thought I would at least try @francisdrake's suggestion - and I think it may well be the way to go (or did everyone except me already know that? :LOL: )

Attached below is another patch with a new dm2_capsule.dll.

It uses ShiftCentreOfMass(...) when docked - seems to work very well - I can't see any change in orbit when extending/retracting docking ring.

VC, thrusters, animations, lights all seem to work fine.
I haven't tested to see if there are any bad effects on trunk jettison or aerodynamics yet.

But... I have no idea why it works! So...there may be bugs lurking!

As ever, if you care to try it, do let me know how it works for you.

Many thanks (especially to @francisdrake),
BrianJ
 

Attachments

Last edited:
Thanks for your endurance to find a way!

Tested the new dll, retracting the docking ring both in docked and undocked situation. No more orbit change.
Virtual cockpit clickability of buttons works fine.
Trunk separation (with ring extended or retracted) also fine, no jump of the separated mesh.

Reentry flames look good and in place. Splashdown was within visible range of GoSearcher vessel. Bobbling on water looks ok. (y)
 
@francisdrake Thanks so much for the report - and suggestion! (y)
Deorbit, trunk jettison, reentry, splashdown and retrieval all working here too.
And using ShiftCentreOfMass() replaces about 30 lines of code with just one.
I'm think I'm going to call that fixed :) I'll update the main add-on soon.
Cheers,
BrianJ
 
@diogom would it be possible to have a look at the code you used to fix this problem?
Hey, sorry was away from the code, great you found a way!

In any case here goes, pretty much just changed this I think:

C++:
ELEMENTS el_v;
ORBITPARAM orbparam_v;
...
v->GetElements(NULL, el_v, &orbparam_v, 0, FRAME_EQU);
Undock(0);
VECTOR3 new_dock_pos = S7K_DOCK_POS;
new_dock_pos.z = new_dock_pos.z + (dock_probe_proc * new_dock_factor) + DOCKOFFSET;
SetDockParams(hDock, new_dock_pos, _V(0, 0, 1), _V(0, 1, 0));
Dock(hMother, 0, j, 2);
v->SetElements(NULL, el_v, &orbparam_v, 0, FRAME_EQU);

Just confirmed it to be sure, orbit didn't really move through the whole thing, at least as far as the available decimal places in OrbitMFD show. This is in PreStep.
 
Hey, sorry was away from the code, great you found a way!
In any case here goes, pretty much just changed this I think:
Many, many thanks! Much appreciated. (y)
I did give that method a try, but results were comparable to using vessel Status.

Just confirmed it to be sure, orbit didn't really move through the whole thing, at least as far as the available decimal places in OrbitMFD show.
I resorted to having a debug string showing PeR and ApR to millimeter accuracy, to get a handle on what was going on.
The best result I got using Undock/Move-Port/Dock method with Dragon/ISS was a total change of ~40m across PeR and ApR. Time acceleration and higher vessel rotation rates made it much worse.

Thanks again,
BrianJ
 
I know this would be boring to some but since the real crew dragon can autonomously rendezvous and dock with the ISS, it would be cool if this could be added to this addon.
 
I know this would be boring to some but since the real crew dragon can autonomously rendezvous and dock with the ISS, it would be cool if this could be added to this addon.
It would be a fairly extensive project! No plans for this at the moment.

However, I can recommend:
"Rendezvous MFD" for rendezvous:

"PursuitMFD" for docking ops:

:cheers:
 
Ok thanks. I recently figured out how to use PursuitMFD to dock. I'll give the rendezvous mfd a try.
 
Back
Top