Project Orion 606

[gattispilot]

Confused even more.

The animation exist already in the Orion606sm vessel.

void ORION2NEWSM::DefineAnimations(void)

{
	anim_HGA_SM = CreateAnimation(0.0);
	static UINT HGAGrp[4] = { GRP_HGA1, GRP_HGA2, GRP_HGA3, GRP_HGA4 };
	static MGROUP_ROTATE HGA(5, HGAGrp, 4, _V(0, 1.948546, .2253037), _V(1, 0, 0), (float)(90 * RAD));
	AddAnimationComponent(anim_HGA_SM, 0, 1, &HGA);

It just needs to be told what animation values need to be.

Thought this did that:

		v->SetAnimation(anim_JOINT2, JOINT2_proc);
		v->SetAnimation(anim_JOINT1, JOINT1_proc);
		v->SetAnimation(anim_JOINT7, ARM3_proc);
		v->SetAnimation(anim_HGA, HGA_proc);

except new animation names

 

[Urwumpe]

Confused even more.

		v->SetAnimation(anim_JOINT2, JOINT2_proc);
		v->SetAnimation(anim_JOINT1, JOINT1_proc);
		v->SetAnimation(anim_JOINT7, ARM3_proc);
		v->SetAnimation(anim_HGA, HGA_proc);

except new animation names

Maybe you should remember my finger and your nose.

anim_JOINT2 is not the same as v->anim_JOINT2.

 

[gattispilot]

Ok if we had a clone of you it would be the same. ISn't the Sm a clone.

So do i need

v->SetAnimation(anim_JOINTnewsm7, ARM3newsm_proc);

 

[Urwumpe]

Ok if we had a clone of you it would be the same. ISn't the Sm a clone.

No, not at all. Where did you clone it? All you cloned was essentially the blueprint that orbiter uses for creating the vessel.

The same also applies to a clone of me. It might be my genotype, but my phenotype is already unique. And my personality is magic.

 

[gattispilot]

The clone is the copy of the Orion606 with all its animations,.... It is just renamed Orion606sm

 

[Urwumpe]

The clone is the copy of the Orion606 with all its animations,.... It is just renamed Orion606sm

:facepalm:

I must obviously be insane or something worse. Can you please point me to the Orbiter SDK which explains how cloning vessels like you expect is described as feature?

 

[gattispilot]

No your not insane. I might be:shrug:

I just figured if i had the same type vessel I got just tell the new vessel what to do.

 

[gattispilot]

Going with Francisdrake suggestion.
But because "mode" is not supported. I can tell the newly created vessel that the mode is now 99.

I have gotten this vessel from Launchpad to orbit. It is the jettison of the Sm that is the next hurdle

 

[francisdrake]

The question is: How can a newly created vessel is not just be of type VESSEL, but of a derived class (e.g. CEV)?

The way to create the vessel in-situ is here:
...
OBJHANDLE h;
VESSEL *v;
...

strcpy (name, GetName()); strcat (name, "-SM");
h = oapiCreateVessel (name, "Orion-MPCV\\Orion-MPCV", vs);
v = oapiGetVesselInterface(h);
...

The *v should actually be a "CEV" (which is a derived class of vessel).
Trying to typecast the oapiGetVesselInterfac() gives an error:

1> Cast from base to derived requires dynamic_cast or static_cast
1>.\MPCV.cpp(1274) : error C2440: '=' : cannot convert from 'VESSEL *' to 'CEV *'

Maybe there is an easy answer from a seasoned programmer?

 

[Urwumpe]

The *v should actually be a "CEV" (which is a derived class of vessel).
Trying to typecast the oapiGetVesselInterfac() gives an error:

1> Cast from base to derived requires dynamic_cast or static_cast
1>.\MPCV.cpp(1274) : error C2440: '=' : cannot convert from 'VESSEL *' to 'CEV *'

Maybe there is an easy answer from a seasoned programmer?

Easy answer: Exactly what it says there. :lol:

You have two different options for casting from a general class to a specialized class:

static_cast<CEV *>(v)

Works always, but does not check if v is pointing to an instance of the class CEV.

dynamic_cast<CEV *>(v)

if v is pointing to an instance of a CEV, it returns a cast pointer (same address in memory, but different meaning in C++, like static_cast). if v is not an instance of CEV, dynamic_cast returns a null pointer.

You notice the tiny difference, yes? Remember C++ is not C. In C, the compiler does not care as much about the types as in C++, in C++ in complains more often. That is because stronger typing is important for C++ to make sense. In C every cast is static, and thus works all the time.

And for the beginners about the strange choice of words: Whenever you call the constructor of a class, you create a new instance somewhere. That is what "instance of CEV" means. When you call "new CEV(handle, model)" you create an instance of this class. The class of this instance does never change, when you do a cast to it. Never. When you implicitly cast it to VESSEL* by giving it to Orbiter, it always remains an instance of CEV*. Even if Orbiter does not care about it being a more specialized kind of VESSEL. Its like driving a Volkswagen, but your drivers license only allowing you to drive a motor car, which is luckily a generalized class of a Volkswagen. Imagine the opposite: Having a Volkswagen license, but you want to drive any car....

 

[N_Molson]

The main vessel basically just shows/not shows meshes depending on conditions.

So when the cm and Sm are together they are really 1 vessel. That shows the cm and Sm meshes and animations.

But when the CM and SM separate there are 2 vessels. The CM vessel now doesn't show the Sm vessel mesh. The Sm veesl is just the Sm mesh and animation

There's no shame in having 2 separated vessels attached all the way long. With Orbiter 2016 you can even use docking on the ground, so it makes it a very simple option for multistage stacks. And it takes care of the center of mass, amongst other things.

And you can very well have RCS thrusters work in coordination on the 2 "vessels". All you have to do is to write into the "main" one (say the Command module) some sub-program that orders the other vessel-dll to fire its thrusters in a way that make the assembly maneuvrable.

I admit it, I've always been for that way of doing things, prefering Velcro over Multistage.

 

[gattispilot]

And you can very well have RCS thrusters work in coordination on the 2 "vessels". All you have to do is to write into the "main" one (say the Command module) some sub-program that orders the other vessel-dll to fire its thrusters in a way that make the assembly maneuvrable.

I admit it, I've always been for that way of doing things, prefering Velcro over Multistage.

I think so also. That is how it is in real life. For me that complicated. Telling other vessels to do something.

Like in the Command vessel you should be able to tell the Service Module to fire main thruster, rcs and animation rather than switching vessels.

 

[fred18]

There's no shame in having 2 separated vessels attached all the way long. With Orbiter 2016 you can even use docking on the ground, so it makes it a very simple option for multistage stacks. And it takes care of the center of mass, amongst other things.

And you can very well have RCS thrusters work in coordination on the 2 "vessels". All you have to do is to write into the "main" one (say the Command module) some sub-program that orders the other vessel-dll to fire its thrusters in a way that make the assembly maneuvrable.

I admit it, I've always been for that way of doing things, prefering Velcro over Multistage.

I agree with that. That's my idea for the next generation multistage some times from now.

 

[N_Molson]

For me that complicated. Telling other vessels to do something.

Not at all. You simply have to use vessel pointers. The only tricky thing is that any little mistake leads to a CTD. Computers don't like pointers that return NULL. Power of the Zero. And you have to be careful with the stars * too.

You can have a look to the Remote Vessel Control plugin code sample that comes with Orbiter, it might help.

That's my idea for the next generation multistage some times from now.

I fully agree. The more we can use built-in Orbiter features (ie Docking Ports), the simplest and user-friendliest it is.

 

[gattispilot]

Ok I will look at it.

My idea is make the SM the only vessel you would need to be in. But control the others (SM,...)

So from the CM you control the thrusters in the SM.
Then when time for jettison you dettach and fire away.

I guess you can control animations in another vessel?

 

[Urwumpe]

Computers don't like pointers that return NULL. Power of the Zero. And you have to be careful with the stars * too.

I tend to disagree there. First of all, zero is a perfectly valid value for a pointer. Just not the value that the programmer expects all the time. Same with stars. Don't be scared of them, they are useful.

The scare of pointers is actually worse than the danger imposed by them. Yes, when you use them, you should know what you are doing. But that applies to any line of code. There is no harmless code in C++. Scared programmers are so busy avoiding pointers, that they produce much worse code than by using pointers. Especially if you want to do testable code, you easily need pointers, because a reference is not enough.

Also: If you know, what you are doing and what kind of semantic you are intending to use, you can often find an alternative to a pointer, either in form of a reference or as a container class in the STL. Or you realize that an auto_ptr is not just safer, but also more fitting in the context, despite its limitations.

So please, stop scaring developers of language features. Its like scaring carpenters of the dangerous circular saw and the lack of fingers that it causes.

 

[N_Molson]

I tend to disagree there.

So please, stop scaring developers of language features.

But I was certain you would correct me. I was bit like "oh I'm going to lay a bait so Urwumpe is going to say it better than me (he is a software engineer after all)", I confess. :lol:

And after all, a CTD under Orbiter is very unlikely to do anything harmful to the computer. So it's not scaring people. Please go on the field and experiment things people. That's a proven way to learn stuff. And if correctly linked, the VS Debugger can really help you in finding why you get crashes. :yes:

But what I also want to say is : if you get a CTD, put the pointers high on the suspects list. My limited and profane experience learned me you save time that way. :stirpot:

 

[Urwumpe]

But I was certain you would correct me. I was bit like "oh I'm going to lay a bait so Urwumpe is going to say it better than me (he is a software engineer after all)", I confess. :lol:

Of course I would. Whenever somebody says something bad about pointers, you can be sure, I'll be watching you.... :ninja:

But what I also want to say is : if you get a CTD, put the pointers high on the suspects list. My limited and profane experience learned me you save time that way. :stirpot:

My rather humble recommendation: Look at the error first, before you start analysing. You can waste a lot of time checking all pointers, when you actually just have lost a handle.

Generally saying: Junior developers, with less than 1000 hours of experience in C++, will be more likely to cause bugs by pointer issues. The more experience you get, the more conservative your approach to pointers will be and the less likely this will cause any problem.

A good example from my paid work: You have a segmentation fault, which shouts "Null pointer error" in your face. But the real cause after more closely reading the log messages was actually an issue with a failed UTF-8 conversion deep inside a library.

 

[gattispilot]

Thanks.

So looking at the remote control:

So it looks like. You get all the vessels by index.

void CreateVesselList (HWND hDlg)
{
	char cbuf[128];
	DWORD i, n = oapiGetVesselCount();
	SendDlgItemMessage (hDlg, IDC_VESSELLIST, CB_RESETCONTENT, 0, 0);
	for (i = 0; i < n; i++) {
		OBJHANDLE hVessel = oapiGetVesselByIndex (i);
		oapiGetObjectName (hVessel, cbuf, 128);
		SendDlgItemMessage (hDlg, IDC_VESSELLIST, CB_ADDSTRING, 0, (LPARAM)cbuf);
	}
	g_Param.vessel = oapiGetFocusInterface();
	SendDlgItemMessage (hDlg, IDC_VESSELLIST, CB_SELECTSTRING, 0, (LPARAM)g_Param.vessel->GetName());
}

for me I think just get specific vessel like SM. g_Param.vessel = oapiGetFocusInterface(); this is the selected vessel, right?

hVessel = oapiGetVesselByName (cbuf);
				if (hVessel) g_Param.vessel = oapiGetVesselInterface (hVessel);

This gets the vessel you want to control

So it sounds like if I want to control the thrust on the Orion606_SM.

So I get the handle of the Orion606_SM
then
get the interface
g_Param.vessel = oapiGetVesselInterface (hVessel);
hVessel would be Orion606_SM
and then do something like:
g_Param.vessel->GetThrusterGroupLevel (THGROUP_MAIN) * 100.0 + 0.5);

I am sure I left a step or two out

 

[gattispilot]

So does this make sense?

From what I have been told the Orion that will go beyond the moon will have the Round arrays