Idea Merging Vessels

[Kaito]

Before people go "its impossible!", just hear me out.
The big problem with making a space station in Orbiter is that each separate vessel is selectable via ctrl+f3, which makes selecting the vessels very hard if there are a lot.

Heres my idea: have a control dialog (ctrl+f4) in which you can select a "core" vessel and give it a name, then when a button or something is clicked, it will "merge" all vessels either docked or attached to it in a cascading effect. Core is docked to 1 is docked to 2 is docked to 3, etc, etc. The idea would be that the "used" docking ports would be deleted, thus producing an "irreversible" effect. There would be some limitations I imagine, such as any RCS or engines would become inoperable, and any fuel would be gone.

Now, before people direct me to the "vessel stack", that's not what I'm looking for. I'm looking to reduce the amount of vessels in a scenario, not control them as one.

If someone could make this, I'm sure it'd help many people.

~Kaito

 

[DarkWanderer]

Maybe just "SetEnableFocus" on all the ships recursively?

 

[Salamander]

fuel wouldn't be a problem, just add it to the core vessel
same goes for RCS, the core vessel's RCS will move it all. probably even better than a docked stack.

 

[Tommy]

I've had the same idea. My thought was to have a "master core" module with a custom DLL. You would dock a new module to it and then switch focus to the core. On the panel would be a way to "merge" the module. the second module would be deleted and it's mesh added to the core. The core's docking port would be deleted, and new ports created in the correct location. Mass and COG would be accounted for, and any propellent rescources and storage capacity added to the core. Modules could be detached in a similar fashion. Other modules would add thrusters for staion keeping, etc. Yet others could increase life support capacity allowing more UMMU passengers, etc.

Most modules could be based on a more generic DLL/config system - it may be possible to use SC3 for this but I think a custom generic module would allow add-on modules to add specific abilities that couldn't be supported by SC3. i wouldn't be suprised if Greg Burch would be willing to work with you on this - and save you the trouble of creating all the meshes since SSBB already has several very good ones.

 

[Donamy]

Would you still be able to do the animations of the vessels ?

 

[Tommy]

The generic module could support animations the same way SC3 does, and since the animations are all contained in the ini file, the core module could read them, import them, and rotate/translate them appropriately. It would require a good knoweledge of vector math and meshes, but should be possible.

I don't think this is something that should be handled by the Orbiter core, and should be handled by the core module's dll. Extra modules would be best if using a custom generic dll with an ini file that contains all the info the core module needs - propellent resources, capacity, O2 supply, etc. The core module could be made to also work with extra modules that are based on SC3 so existing modules could be used, but SC3 modules wouldn't have as many "extra" abilities like increasing life support, etc, since SC3's ini doesn't support this. A workaround for that would be to have a seperate file for for each SC3 vessel that contained this info that the core module could read it. Then importing a SC3 module would require only creating a simple text file containing a few variables.

 

[escapetomsfate]

Something like this?

I've had a go at writing some code, but there are problems:

#define ORBITER_MODULE

#include "orbitersdk.h"
#include <vector>
using namespace std;

vector<OBJHANDLE> GetAttachments(OBJHANDLE oVessel) {
//Get all attached and docked vessels, and group into a vector.
vector<OBJHANDLE> AtVessels;

if(oapiIsVessel(oVessel)){

//Get a VESSEL pointer to oVessels
VESSEL* hVessel = oapiGetVesselInterface(oVessel);

//Add all docked vessels to the vector.
for(int i = 0; i < (int)hVessel->DockCount(); ++i) {
	OBJHANDLE docked = hVessel->GetDockStatus(hVessel->GetDockHandle((UINT)i));
	if(docked != NULL) {
		AtVessels.push_back(docked);
	}
}

//Add all attached vessels to the vector.
for(int i = 0; i < (int)hVessel->AttachmentCount(false); ++i) {
	OBJHANDLE docked = hVessel->GetAttachmentStatus(hVessel->GetAttachmentHandle(false, i));
	if(docked != NULL) {
		AtVessels.push_back(docked);
	}
}

}
return AtVessels;
}

void MergeVessel(OBJHANDLE oVessel, OBJHANDLE Exception = NULL){
//Set focus to oVessel
oapiSetFocusObject(oVessel);

//Get all docked and attached vessels
vector<OBJHANDLE> AtVessels = GetAttachments(oVessel);

VESSEL* hVessel = oapiGetVesselInterface(oVessel);

//Iterate through each vessel in the vector
for(vector<OBJHANDLE>::iterator it = AtVessels.begin(); it < AtVessels.end(); ++ it) {
     //Merge any vessels docked to that
     MergeVessel(*it, oVessel);

	//Get an interface to the vessel
	VESSEL* docked = oapiGetVesselInterface(*it);
	
	//find relative position
	VECTOR3 rpos;
oapiGetRelativePos(oVessel, docked, &rpos);

	//Add the mass of the vessel to the 'core' vessel
	hVessel->SetEmptyMass(hVessel->GetEmptyMass() + docked->GetEmptyMass());

	//Add the child vessel's meshes to the parent
	for(int i = 0; i > -1; ++i){

	//There is no way to get the VISHANDLE out of a vessel, and how do you get the relative position of a mesh?
		
		if(docked->GetMesh(/* What here? */,i) != NULL){

			hVessel->AddMesh(docked->GetMesh(/* What here? */,i),rpos + /* What here? */);
	} else { break; }
	
	}

	//Add the child's docking ports to parent
	for(int i = 0; i < docked->DockCount(); ++i){
		if(docked->GetDockStatus(docked->GetDockHandle((int)i)) != hVessel) {
		VECTOR3 pos, dir, rot;
		//get the dock parameters
		docked->GetDockParams(docked->GetDockHandle((int)i), pos, dir, rot);
		//add a new docking port
		hVessel->CreateDock(rpos + pos, dir, rot);
		}
	}

	//Add the child's attachment points to parent
	for(int i = 0; i < docked->AttachmentCount(); ++i){
		if(docked->GetAttachmentStatus(docked->GetAttachmentHandle(false,(int)i)) != hVessel) {
		VECTOR3 pos, dir, rot;
		//get the dock parameters
		docked->GetAttachmentParams(docked->GetDockHandle((int)i), pos, dir, rot);
		//add a new docking port
		hVessel->CreateAttachment(rpos + pos, dir, rot);
		}
	}

	//Delete the vessel
	oapiDeleteVessel(*it);
}
}

There are some problems -
1. How do you get the relative position of each mesh?
2. How do you get the VISHANDLE of the mesh without getting it from clbkVisualCreated?

Nice idea, though. I need to find a way of saving the vessels before they are merged and a way of undocking.

 

[Salamander]

add relative positions of docking ports from both vessels

 

[Kaito]

Would there be a way to do a sort of "cascading effect" for this? Like, 1 is docked to 2, so they merge, but 2 was docked to 3, so 3 is also merged.

 

[escapetomsfate]

Would there be a way to do a sort of "cascading effect" for this? Like, 1 is docked to 2, so they merge, but 2 was docked to 3, so 3 is also merged.

Added to the code, no idea if it works

add relative positions of docking ports from both vessels

What do you mean? If you mean the "domino effect" that Kaito mentioned, that's in there.

 

[Salamander]

i mean to position the different meshes, you have to calculate the positions of the docking ports, and add the directional vectors as well.

 

[2552]

Couldn't you just use [ame="http://www.orbithangar.com/searchid.php?ID=3262"]UniversalCargoDeck[/ame] for this? It allows to near-effortlessly attach a vessel to another vessel, control the position/rotation, and it stays attached until you want to detach it. I don't see how that couldn't work for attaching space station modules to a core vessel in orbit.

Edit: It doesn't remove attached vessels from the F3 menu though. Perhaps escapetomsfate's addon, or an update to UCD, could have an EnableFocus option for individual vessels that is saved to quicksaves, as suggested above.

 

[escapetomsfate]

i mean to position the different meshes, you have to calculate the positions of the docking ports, and add the directional vectors as well.

Ah, I see. Done.

IS the whole point of this limiting the amount of vessels in a scenario? How much of a gain in performance would there be?

 

[Tommy]

1. How do you get the relative position of each mesh?

The ini for the added module (AM) should contain the position of it's docking port relative to the modules origin, and you know the position of the dock it's attacked to. These positions would be stored for all attached AMs for use later. From there you can math out the location of the AM, if for some reason calling oapiGetRelativePos before deleteing the AM doesn't work.

2. How do you get the VISHANDLE of the mesh without getting it from clbkVisualCreated?

Do you really need to? I don't honestly know, but my idea was to use oapiLoadMeshGlobal to load the AM's mesh (the path and name of mesh is in the modules ini), then use addmesh (2) to add the mesh to be displayed. I'm not sure what you would use clbkVisualCreated for in this instance unless it's needed to set animation states? I haven't gotten that far into coding modules yet, but my understanding is that clbkCreate Visual isn't required for a mesh to be displayed. I could well be wrong.

 

[Zatnikitelman]

Not every vessel is ini derived.

 

[Tommy]

Not every vessel is ini derived

No, my idea was to create a generic module that was like modified SC3 purpose built for station building. SC3 vessels could also be used with some limits. It was never intended to work on all vessels - only station modules and they are pretty much all SC3 at this time.

 

[Andy44]

No, but vessels built under this system will likely have some sort of ini file, right? You don't plan on being able to do this with any vessel, do you?

 

[Zatnikitelman]

Actually, it might be possible to make it work with any vessel. Conceivably, every vessel is a subclass of VESSEL2 (or atleast VESSEL) which means there are more than likely standardized stuff. When a ship that's maybe been flagged in the scenario file docks to this mega-vessel, its docking ports get copied over, its attachments get copied over etc. then the vessel is deleted, but the mesh is added to this mega-vessel. If something grabs the attachment points, or docks, then undocks the module, the vessel is re-created in the same position as before. Thrusters and animations I'm not sure about, but I'm sure something could be done.

 

[Kaito]

Ah, I see. Done.

IS the whole point of this limiting the amount of vessels in a scenario? How much of a gain in performance would there be?

There are two points I had in mind:
1 is that if Orbiter has a limited number of vessels, this would reduce it, so you could, in theory, have an unlimited number of vessels in a scenario, just merge them when you come close to the limit.
2 is so that people building a station (such as myself) dont have to search through 70+ "useless" modules to get to the one they want. And it will clean up the scenario editor

So, i'm assuming this will allow "exposed" docking ports to be docked to.

Also, what kind of interface will this be? A ctrl+f4 one, like the scenario editor, or something else?

 

[Jake]

Nice, I wanted for a long time something like this. I made a thread a while back about something like this, but with a different scope in mind, nesting the modules in the display box or something, but this is quite better. Can't wait for it

As a side note, in the "To The Moon in 24 hrs" add-on, once you docked the small manned module to the LANTR, focus switched from the selected vessel to the entire assembly (module+LANTR), and both dissapeared from the scenario, being replaced by a single ship you could control as one. Can't similar scripting be used here?

Also, what kind of interface will this be? A ctrl+f4 one, like the scenario editor, or something else?

Probably a MFD?