Spacecraft3 attachment/docking

[n0mad23]

I'm having problems with creating a docking port on a mesh that is attached to another mesh via parent/child attachments.

The parent/child attachments work fine, and my payload appears in docked status, but it's no where close to the mesh with the dock.

Any ideas?

 

[Eagle]

If a ship is both docked and attached the attachment takes precedence (The ship will appear where it is attached) When you deattach it should snap back to the docked location.

EDIT: if the problem is that the attachment is in the wrong place, then just move the attachment on either the parent or child.

 

[n0mad23]

Here's some more information:

The scenario I'm using:

BEGIN_DESC
Draft Prototype.
END_DESC

BEGIN_ENVIRONMENT
System Sol
Date MJD 78994.3739534509
END_ENVIRONMENT

BEGIN_FOCUS
Ship ZTC-t1
END_FOCUS

BEGIN_CAMERA
TARGET ZTC-t1
MODE Extern
POS 8.80 55.66 -1.06
TRACKMODE GlobalFrame
FOV 50.00
END_CAMERA


BEGIN_SHIPS
Ananke:SpacecraftSpacecraft3
STATUS Orbiting Earth
RPOS 2608406.93 50499.01 -6332938.02
RVEL 8877.00 -738.532 4370.103
AROT -12.27 -67.23 101.15
VROT -0.967 -0.00 0.00
PRPLEVEL 0:1.000
IDS 0:260 100 1:491 10
NAVFREQ 440 0
XPDR 60
END
ztc-CableA:SpacecraftSpacecraft3
STATUS Orbiting Earth
RPOS 2608406.93 50499.01 -6332938.02
RVEL 8877.00 -738.532 4370.103
AROT -12.27 -67.23 101.15
ATTACHED 0:0,Ananke
END
ztc-catcher:SpacecraftSpacecraft3
STATUS Orbiting Earth
RPOS 2608406.93 50499.01 -6332938.02
RVEL 8877.00 -738.532 4370.103
AROT -12.27 -67.23 101.15
DOCKINFO 0:0,ZTC-t1
ATTACHED 0:0,ztc-CableA
END
ZTC-t1eltaGlider
STATUS Orbiting Earth
RPOS 2608406.93 50499.01 -6332938.02
RVEL 8877.00 -738.532 4370.103
AROT -12.27 -67.23 101.15
PRPLEVEL 0:1.000 1:1.000
DOCKINFO 0:0,ztc-catcher
NAVFREQ 0 0 0 0
XPDR 0
NOSECONE 1 1.0000
RADIATOR 1 1.0000
PSNGR 1 2 3 4
END
END_SHIPS

Note: there really are slashes separating the Spacecraft\Spacecraft3 in the above scenario (they don't appear in the paste).

And the ztc-catcher.ini:

[CONFIG]
MESHNAME="ztc-catcher"
FOCUS=1
SIZE=147.02
EMPTY_MASS=2600

[DOCK_0]
POS=(-3.47, 0.02, -73.32)
DIR=(0,1,0)
ROT=(-1,0,0)

[CHILD_ATTACH_0]
POS=(3.492, 0.641, 73.48)
DIR=(0,1,0)
ROT=(-1,0,0)
LOOSE=0
ID="XS"

When I fire up the scenario, the Delta-G appears off the side of CableA mesh and not the catcher mesh. When I pull up the scenario editor and undock, then redock on the catcher, the Delta-G appears about 3 meters to the side and not attached (though it claims to be docked).

However, it's really not docked, as the catcher mechanism pulls away leaving the Delta-G behind.

 

[Eagle]

I don't see anything incorrect, but docking to an attached child is always buggy.

I think the reason is that two docked vessels will both effect each other's velocities, while there is generally no exchange in a parent/child attachment.

So when the delta-G is expecting the catcher along with it, its getting nothing. If you keep the delta-G docked and detach the catcher, either A:the catcher moves instantly to the delta-G or B: the delta-G moves. I think A happens.

EDIT: What is happening is that the catcher is not receiving any information regarding forces from the parent(though it is receiving the new position information, which is why you see it move). So the catcher is not able to share with the Delta-G where to go.

 

[n0mad23]

"A" seems to be the correct answer.

Hmmm. If I attach the Delta-G as a child instead of docking, will this eliminate the problem? Of course this requires changing the Delta-G's docking port to a child attachment, correct?

 

[n0mad23]

If this isn't resolvable with Spacecraft3, is it possible to achieve with API functions instead?

In other words, is it possible to pass along information about forces to objects attached using SDK?

I've been browsing the M6 SDK threads and have found no solution in the first 14 pages. But I've not abandoned hope.

 

[Eagle]

I think your best solution is going to be changing things so the delta-G isn't docking with an attached child.

Two ways to achieve this. Make the catcher a parent, or use docking ports.

 

[tblaxland]

If this isn't resolvable with Spacecraft3, is it possible to achieve with API functions instead?

In other words, is it possible to pass along information about forces to objects attached using SDK?

I've been browsing the M6 SDK threads and have found no solution in the first 14 pages. But I've not abandoned hope.

I believe this is what Kulch's Payload Manager SDK does.

One other option using spacecraft3 - can you define the docking port as part of Ananke (the parent) and just locate it so that occurs coincident with the docking port mesh on the catcher? In other words, the docking port location will be well remote from the parent mesh. I don't think this would be an issue since I can't think of a scenario where we would want to detach the cable/catcher from the parent with DG still docked to the catcher. With this scheme, the catcher/cable mass will not affect the centre of mass of the superstructure but the DG mass will. I guess that is OK if you assume the the catcher/cable to be lightweight.

@n0mad23, it is time for me to fire up the vessel code for Ananke, I think. Even without using Payload Manager, we can handle this by adding the catcher and cable mesh to the Ananke mesh and defining the docking port in the correct location. We'll have some dynamic mass calculations to do as we have discussed previously, but nothing we can't handle. If we have our own vessel dll I don't see any reason why the catcher and cable mesh need to be child attachments.

 

[tblaxland]

Make the catcher a parent...

I don't think this would be acceptable since most of the superstructure mass is in Ananke. If the catcher was the parent, Ananke's mass would be ignored as far as the behaviour of the superstructure is concerned.

or use docking ports.

Good idea, see my post above.

 

[n0mad23]

Eagle,

That docking solution is about the UGLIEST kludge I've ever heard of. It offends so many personal aesthetics, I can hardly begin to count.

It's also completely successful.

Thank you!

 

[Eagle]

Eagle,

That docking solution is about the UGLIEST kludge I've ever heard of. It offends so many personal aesthetics, I can hardly begin to count.

It's also completely successful.

Thank you!

(Emphasis mine)

Well, that's my specialty!:thumbup: