[API Question] Are Multiple Vessels Per Module Possible

[TCR_500]

If someone were to create a vessel pack that had several vessels all related to each other in some way (eg: stages), would it be possible to for the developer of such a set to put all of their vessels into a single module?

And if they did do that, would the scenario editor be able to spawn each type of vessel independently of the other types in the module, or would they all be spawned at once and have to be deleted one by one?

[orb]

Yes. Multiple vessel classes are possible in a single DLL.

You can spawn each of them separately in scenario editor.

[jedidia]

Quote:

Yes. Multiple vessel classes are possible in a single DLL.

How do you define the entry points if there's multiple vessels?

[Face]

Quote:

Originally Posted by jedidia

 How do you define the entry points if there's multiple vessels?

I'd say class name.

[fred18]

That's very interesting, i've never thought about that.

[Face]

Given that you can create vessel config A and B that point to the same module M, you can compile both classes cA and cB into M with a common ovcInit and ovcExit like so:

DLLCLBK VESSEL *ovcInit (OBJHANDLE hvessel, int flightmodel)
{
	VESSEL *vessel=new VESSEL(hvessel, flightmodel);
	char *className=new char[strlen(vessel->GetClassName())+1];
	strcpy(className, vessel->GetClassName());
	delete vessel;
	strlwr(className);
	if (strcmp(className, "a")==0) vessel=new cA (hvessel, flightmodel);
	else if (strcmp(className, "b")==0) vessel=new cB (hvessel, flightmodel);
	delete [] className;	
	return vessel;
}

DLLCLBK void ovcExit (VESSEL *vessel)
{
	if (vessel)
	{
		char *className=new char[strlen(vessel->GetClassName())+1];
		strcpy(className, vessel->GetClassName());
		strlwr(className);
		if (strcmp(className, "a")==0) delete (cA*)vessel;
		else if (strcmp(className, "b")==0) delete (cB*)vessel;
		delete [] className;
	}
}

This should work for the scenario editor, too. The new-VESSEL-trick from ye olde days is necessary, because at the time of the ovcInit-call, a oapiGetVesselInterface() on the handle returns NULL.

[TCR_500]

I did not know that the VESSEL class had a GetClassName() function. Though I was told that polymorphic objects don't need a (derived*) cast when delete is called. I was also told that objects always need delete[] to be called even if new (not new[]) is called. Since a class is technically an array.

[Face]

Quote:

Originally Posted by TCR_500

 Though I was told that polymorphic objects don't need a (derived*) cast when delete is called.

AFAIK, you have to explicitly declare a destructor of a base class virtual for that to work. I don't know who has told you otherwise, but here is a reference for that: http://www.studytonight.com/cpp/virtual-destructors.php

I must admit that I never tried it for myself, but I've learned to not trust C++ to do the right thing implicitly.

Quote:

Originally Posted by TCR_500

 I was also told that objects always need delete[] to be called even if new (not new[]) is called. Since a class is technically an array.

*sigh* Was it the same person as above that told you that? https://stackoverflow.com/questions/...lete-vs-delete

[martins]

Quote:

Originally Posted by TCR_500

 Since a class is technically an array.

A class is technically a struct. The only difference is that by default struct members are public, while class members are private.

Edit: Also I don't know if structs support virtual members or inheritance. Never tried that ...

[Zatnikitelman]

They do, I tried that out a while ago in a failed attempt at an Orbiter mission system. I know now a class would have been better, but I think in C++, there's no longer any meaningful difference between a class and struct. Just something about the default visibility of members I think.

[Face]

Quote:

Originally Posted by Zatnikitelman

 They do, I tried that out a while ago in a failed attempt at an Orbiter mission system. I know now a class would have been better, but I think in C++, there's no longer any meaningful difference between a class and struct. Just something about the default visibility of members I think.

I don't get that statement.
You know now that a class would have been better. You think that there is no meaningful difference between a class and a struct.
So.. if you know that a class would have been better, you'd know that there is a difference.
But.. if you know that there is a difference, why do you think there is none?

[jangofett287]

Quote:

Originally Posted by Face

 AFAIK, you have to explicitly declare a destructor of a base class virtual for that to work. I don't know who has told you otherwise, but here is a reference for that: http://www.studytonight.com/cpp/virtual-destructors.php

I learned that you HAD to make your destructor virtual if you were going to make derived classes.

Quote:

Originally Posted by TCR_500

 I was also told that objects always need delete[] to be called even if new (not new[]) is called. Since a class is technically an array.

As Face and martins have pointed out that's not true. Each new/new[]/malloc in a constructor should be paired with an equivalent delete/delete[]/free in the destructor. You should always make sure you delete things you put on the heap and in some cases you need to make sure it hasn't already been deleted.

[Zatnikitelman]

Quote:

Originally Posted by Face

 I don't get that statement.
You know now that a class would have been better. You think that there is no meaningful difference between a class and a struct.
So.. if you know that a class would have been better, you'd know that there is a difference.
But.. if you know that there is a difference, why do you think there is none?

Bad wording on my part. Better here refers more to standards and readability than a technical reason.

[jedidia]

Quote:

I must admit that I never tried it for myself, but I've learned to not trust C++ to do the right thing implicitly.

I need it in a few cases to clean up memory. In a tall inheritance tree it's quite a common requirement, actually, especially when working with abstract base classes and multiple inheritance.
I didn't realise that I needed virtual destructors until then, though, and the realisation was not very funny. C++ has quite a few questionable decisions in its syntax, but this one tops it all. Like, I can't imagine any situation where it would be a good thing not to call the destructor of an inheriting class...

Quote:

Better here refers more to standards and readability than a technical reason.

A struct knows neither access modifiers nor inheritance. If you consider those matters of "standards and readability", then you did not yet understand what object oriented programming is about

[TCR_500]

The virtual destructors I already knew about, but thanks anyways. I also already knew that structs and classes are basically identical except for default access (at least for C++). And it seems like the C++ community lied to me again.