SDK Question How to attach only unattched vessels

[Hlynkacg]

Ok then.

I experimented with something similar while working on a project that involved in-orbit assembly of a Interplanetary vessel. I would dock a propulsion module and then have it rotate in to position.

I'm not sure how it'll work with UMMU's but here is how to do it.

Put a docking port and an attachment point at each interface point, in your case this would be the landing pad. Create a boollean for "Pad Occupied" or or some such.

Using clbkDockEvent, get the object handle of any vessel that docks with yours.

Using that handle get a vessel interface and determine if it is a compatible class. If it is, use the interface to undock it from the docking port and attach it to the attachment point. Use the boolean to flag the docking port as unavailable.

You can now manipulate everything using the attachment and object handles.

 

[gattispilot]

Thanks

So have a docking point and attachment point at the same location, right? Our start is inside the bay.
So I am not sure if the docking point should be there or outside?


Can you send me a code sample? You lost me

On the Ummu you must be docked to transfer. So you should be docked inside.

 

[gattispilot]

attaching and docking

OK. I made a dock on both the Discovery and a pod. The discovery is the Mother/parent for attachments.

Using the scenario editor I can dock and move the pod with attachments. The problem is when I exit the program and reload I am now orbiting the sun.
discovery dock info

BEGIN_DOCKLIST
0 1.2 13   0 0 -1  0 1 0    588
END_DOCKLIST

Pod dock info

BEGIN_DOCKLIST
0 -1.388 -.822   0 0 -1  0 1 0    588
END_DOCKLIST

 

[Donamy]

If you look in the scenario file after exit, does the vessel say it is both attached and docked ? You can't have that.

 

[Hlynkacg]

Thanks

So have a docking point and attachment point at the same location, right? Our start is inside the bay.
So I am not sure if the docking point should be there or outside?


Can you send me a code sample? You lost me

On the Ummu you must be docked to transfer. So you should be docked inside.

Sorry about the delay, I had to dig through some old back-ups to find it.

void imis::clbkDockEvent (int dock, OBJHANDLE mate)
{
  if ((dock > 1) && (mate != NULL)) // is there a vessel docked to a propulsion module slot?
  {
    VESSEL *ppm = oapiGetVesselInterface (ppm);  // get VESSEL interface for docked vessel
		
    if (ppm->GetClassName () == IMIS_PPM) // is the vessel a propulsion module?
    {
    ppm->Undock (0); // Undock the Propulsion module
    AttachChild (mate, GetAttachmentHandle (true, 0), GetAttachmentHandle (false, dock)); // attach it to appropriate attachment point
    PPM_attached[dock] = true; // flag PPM slot as occupied
    }
  }

for (int i = 0; i < ppmcount; i++) if (PPM_attached[i] == true) Undock (i); // Prevent vessels from docking with an occupied ppm slot

}

UpdateVesselState (); // Update CoG, propellant, and thruster values.   
}

"UpdateVesselState ()" would copy/paste the propulsion module's propellant and thrusters to the parent vessel.

I'm not as familiar with the UMMU sdk but so long as have a have a valid class interface you should be able to cut/paste crew from one vessel to another the same way you would copy/past thrusters and propellant.

 

[gattispilot]

So what does this do? Is mate the parent or child?

I think he need to be docked.

Ideally if Ramp_proc (start ) is 0 then be docked as the ramp moves out then undock but remain attached.

In reverse you get attached and then brought in. When Ramp_proc =0 (start) you get docked so you can use transfer to get in/out

Or if the Ummu info could be written into the pod when attached that would work

 

[Hlynkacg]

IMIS was a multi-stage interplanetary vessel that would have been assembled in orbit.

I simulated this by having a the service/crew module act as a core, and then docking additional modules, to it. The above function was part of the IMIS core vessel class, and handled [ame="http://www.orbithangar.com/searchid.php?ID=5339"]my propulsion modules[/ame].

When a vessel docks with one of the ports intended for a propulsion module it checks that vessel's class. If that vessel is a member of the IMIS propulsion module class it undocks it from the port and attaches it as a child of the IMIS core. It then flags that slot as being occupied and prevents any other vessels from docking with that port. From that point on all remaining interactions are handled via class interface.

In regards to your own project, the pods are the PPMs and Discovery is the IMIS Core.

Place a single docking port at each point of interface, AKA the location of the extended pad. You can use a simple boolean to prevent vessels from docking with that port if when the pad is not extended.

When a vessel docks with that port check to see if it is one of your pods. If it is, transfer the crew from the pod to Discovery and undock it from the port. Attach it as a child of Discovery and animate as you please.

To deploy the pod, simply write a function that performs the above procedure in reverse.

 

[gattispilot]

OK. What you show me what the H looks like?

the name of the attachments are PODA,PODB, and PODC

So can we undock at the start of the attachment when the pod would be inside?

void DISCOVERY::clbkDockEvent (int dock, OBJHANDLE mate)
{
  if ((dock > 1) && (mate != NULL)) // is there a vessel docked to a propulsion module slot?
  {
    VESSEL *pod = oapiGetVesselInterface (pod);  // get VESSEL interface for docked vessel
		
    if (pod->GetClassName () ==		POD2001) // is the vessel a propulsion module?
    {
    pod->Undock (0); // Undock the Propulsion module
    AttachChild (PODA, GetAttachmentHandle (true, 0), GetAttachmentHandle (false, dock)); // attach it to appropriate attachment point
    PPM_attached[dock] = true; // flag PPM slot as occupied
    }
  }

for (int i = 0; i < ppmcount; i++) if (PPM_attached[i] == true) Undock (i); // Prevent vessels from docking with an occupied ppm slot

}

UpdateVesselState (); // Update CoG, propellant, and thruster values.   
}

 

[Hlynkacg]

OK. What you show me what the H looks like?

the name of the attachments are PODA,PODB, and PODC

So can we undock at the start of the attachment when the pod would be inside?

No, other way around. The above function handles landing/retrieval of a pod not deployment.

If the pod is inside Discovery it is attached via attachment point. The docking port is only used for landing.

To deploy the pod. Simply write the appropriate UMMU data from Discovery to the Pod, animate it leaving the pod bay, and then release it.

 

[gattispilot]

To deploy the pod. Simply write the appropriate UMMU data from Discovery to the Pod, animate it leaving the pod bay, and then release it.

What do you mean by the Appropriate Ummu data? I think if that could be done then the docking point would be mute. Just use the docking as a beacon

 

[Hlynkacg]

I'm not sure what you mean by "using the docking port as a beacon".

I assume that you want a UMMU to be inside the pod when it deploys. The Pod it will not be docked to Discovery it will be attached, so unless UMMU allows transfer via attachment point (i don't know if it does) you will need to perform the transfer manually.

Alternately you can simply animate the pod leaving the bay, and wait to transfer the UMMU until after the Pod is outside Discovery and docked with the landing pad.

 

[gattispilot]

My understanding is the only way to transfer Ummu is with a docked vessel. So I guess the docking port needs to be at the start inside. For navigation purposes to get close to the end of the animation a transponder will need to be there.

Not sure what these are defined as:
.\DISCOVERY.CPP(874) : error C2065: 'POD2001' : undeclared identifier
.\DISCOVERY.CPP(878) : error C2065: 'PPM_attached' : undeclared identifier
.\DISCOVERY.CPP(882) : error C2065: 'ppmcount' : undeclared identifier
.\DISCOVERY.CPP(882) : error C2065: 'PPM_attached' : undeclared identifier

  void DISCOVERY::clbkDockEvent (int dock, OBJHANDLE mate)
{
  if ((dock > 1) && (mate != NULL)) // is there a vessel docked to a propulsion module slot?
  {
    VESSEL *pod = oapiGetVesselInterface (pod);  // get VESSEL interface for docked vessel
		
    if (pod->GetClassName () ==		POD2001) // is the vessel a propulsion module?
    {
    pod->Undock (0); // Undock the Propulsion module
    AttachChild (PODA, GetAttachmentHandle (true, 0), GetAttachmentHandle (false, dock)); // attach it to appropriate attachment point
    PPM_attached[dock] = true; // flag PPM slot as occupied
    }
  }

for (int i = 0; i < ppmcount; i++) if (PPM_attached[i] == true) Undock (i); // Prevent vessels from docking with an occupied ppm slot



UpdateVesselState (); // Update CoG, propellant, and thruster values.   

}

And will I have to do this for each pod a,b,c?

 

[Hlynkacg]

My understanding is the only way to transfer Ummu is with a docked vessel. So I guess the docking port needs to be at the start inside. For navigation purposes to get close to the end of the animation a transponder will need to be there.

Not sure what these are defined as:
.\DISCOVERY.CPP(874) : error C2065: 'POD2001' : undeclared identifier
.\DISCOVERY.CPP(878) : error C2065: 'PPM_attached' : undeclared identifier
.\DISCOVERY.CPP(882) : error C2065: 'ppmcount' : undeclared identifier
.\DISCOVERY.CPP(882) : error C2065: 'PPM_attached' : undeclared identifier

  void DISCOVERY::clbkDockEvent (int dock, OBJHANDLE mate)
{
  if ((dock > 1) && (mate != NULL)) // is there a vessel docked to a propulsion module slot?
  {
    VESSEL *pod = oapiGetVesselInterface (pod);  // get VESSEL interface for docked vessel
		
    if (pod->GetClassName () ==		POD2001) // is the vessel a propulsion module?
    {
    pod->Undock (0); // Undock the Propulsion module
    AttachChild (PODA, GetAttachmentHandle (true, 0), GetAttachmentHandle (false, dock)); // attach it to appropriate attachment point
    PPM_attached[dock] = true; // flag PPM slot as occupied
    }
  }

for (int i = 0; i < ppmcount; i++) if (PPM_attached[i] == true) Undock (i); // Prevent vessels from docking with an occupied ppm slot



UpdateVesselState (); // Update CoG, propellant, and thruster values.   

}

And will I have to do this for each pod a,b,c?

The docking port does not need to be inside the Discovery if we transfer the UMMUs manually or wait until after the pad has been extended to perform the transfer.

The only thing we really NEED the docking port for is for landing, your beacon.

as for the variables.

POD2001 needs to be defined as character string containing the name of your pod vessel class. Alternately you need to add a custom variable who's presence can be detected by the Discovery vessel class, and then check for that.

"PPM_attached" is a boolean that flags a port as being occupied. Because there are 3 pods it's declaration should look like...

bool PPM_attached[3];

or rather

bool podbay_occupied[3];

ppmcount is a integer that stores the current number of ppm slots. There are three pod bays so "podcount" should equal 3.

You do not have to do this for each pod bay individually because my code should already do that. So long as your attachment, and docking port index numbers line up (docking port 0 corresponds to attachment point 0, 1 to 1, 2 to 2, and so forth) no further input should be required.

 

[gattispilot]

Thanks. ALmost

Still haven gotten this defined as yet. So Do I need to make the attach 3 times since the id is PODa,PODb, PodC? So when does it become undocked?

Not sure about this:

char POD2001[255];

and this:
UpdateVesselState ();

 

[Hlynkacg]

Thanks. ALmost

Still haven gotten this defined as yet. So Do I need to make the attach 3 times since the id is PODa,PODb, PodC? So when does it become undocked?

Not sure about this:

char POD2001[255];

and this:
UpdateVesselState ();

You need to declare three seperate, toparent = false, attachment points for Discovery either in clbkSetClassCaps or clbkPostCreation, you will also need to declare three docking ports (transponders as you called them). The handles you assign to them are neither here nor there as their id will always be will always be 0, 1, 2... etc based on the order in which they were defined.

The pod becomes undocked when it is docked, the docking port is only used for initial contact, we use the attachment points for everything else.

char POD2001 needs to be initialized to contain the name of your pod class, and used as a comparison. Look to the Load and Save scenario functions for examples of how to do this.

"UpdateVesselState ()" is a custom void created specifically for my IMIS vessel class. It does exactly what it says in the comment

 

[gattispilot]

You need to declare three seperate, toparent = false, attachment points for Discovery either in clbkSetClassCaps or clbkPostCreation, you will also need to declare three docking ports (transponders as you called them). The handles you assign to them are neither here nor there as their id will always be will always be 0, 1, 2... etc based on the order in which they were defined.

The pod becomes undocked when it is docked, the docking port is only used for initial contact, we use the attachment points for everything else.

char POD2001 needs to be initialized to contain the name of your pod class, and used as a comparison. Look to the Load and Save scenario functions for examples of how to do this.

"UpdateVesselState ()" is a custom void created specifically for my IMIS vessel class. It does exactly what it says in the comment

ok. So it becomes undocked when docked? Why. It needs to be docked to transfer?

I actually have found if I do NOT end or start docked and attached then no problems. So I have the pod docked at first. Then attach and rotate,... board the pod and Ctrl D undock.

Ok so how should the Update state is in the H?

 

[Hlynkacg]

"UpdateVesselState ()" is a custom void. It's declared in the class interface and then its body is in the .cpp with all the other functions.

It's contents don't really matter to you because they are IMIS Specific, though by all rights, if you are going to do subsystem and damage modeling Discovery will need a update vessel state function.

 

[gattispilot]

Thanks. We got it to work on one pod. Basically you are docked at the start then attach,... and the end undock.

Is there a way to dock to specific docks without Scenario editor?

 

[Hlynkacg]

Yes, refer to API documentation on Docking port management for more info.

 

[gattispilot]

I know this has gone off in a tangent.

But I have my docks here

DOCKHANDLE Dock0,Dock1,Dock2,Dock3;

	Dock0 = CreateDock(_V(-4.2,-4.778,92.940),_V(-.7,0,.7),_V(0,1,0));
	Dock1 = CreateDock(_V(0,-4.778,94.620),_V(0,0,1),_V(0,1,0));
	Dock2 = CreateDock(_V(4.2,-4.778,93.078),_V(.7,0,.7),_V(0,1,0));
	Dock3 = CreateDock(_V(0,-4.778,101.620),_V(0,0,1),_V(0,1,0));

EnableIDS(Dock0, true);
EnableIDS(Dock1, true);
EnableIDS(Dock2, true);
EnableIDS(Dock3, true);


SetIDSChannel(Dock0,6);
SetIDSChannel(Dock1,8);
SetIDSChannel(Dock2,10);
SetIDSChannel(Dock3,12);

But is there a way to undock if a parameter is set.

So if Ramp1>0 && Ramp1<1 then undock dock0