New Release Interplanetary Modular Spacecraft RC9

[Hlynkacg]

Well, I'm not sure it's not connected with IMS because I've never seen such things before. See, when I save a scenario and change vertical axis numbers of TPs into anything less than 8 it starts landed when launching the scenario. If I make it 8 or more it appears as if it's landed on these TPs, but it starts to fall to the ground until the moment it touches the ground somewhere around the default TPs altitude (2 meters). At this point the vessel gets kicked up with a decent acceleration (not as big as the one that sends you into interstellar flight) and makes the vessel to jump around abit. It needs further testing since it was tried with a simple IMS vessel consisting of two modules only. I'll try to assemble a functional lunar lander and perform landing with it.

Let me guess, 8 is your vessel's mean radius.

I encountered a similar issue while working on the staging sequence of my lunar lander, in the end I had to inhibit the CG calculation function when GroundContact() == true to prevent myself from being flung into NaN-space.

 

[jedidia]

You say, I can use the code fixing AP coordinates in respect of shifting COG?

I don't know whether Orbiter shifts them, that is the problem. If it doesn't, you have to store their absolute position towards the CM (best in cmparams), and set them in IMS CoG-shifting function.

What this does to a landed vessel I can only imagine. Hlynkacg's suggestion to prohibit CoG shifting in landed state might be a good idea...

 

[PeterRoss]

I don't know whether Orbiter shifts them, that is the problem. If it doesn't, you have to store their absolute position towards the CM (best in cmparams), and set them in IMS CoG-shifting function.

It doesn't shift them with ShiftCG, which seems rather strange for me, but this is specified in API_Reference. So, I declared

    vector<VECTOR3> ttdFwd;                   //stores absolute position of touchdown points
    vector<VECTOR3> ttdLeft;
    vector<VECTOR3> ttdRight;

in IMS.h where all the CM parameters are being declared, then changed loading and saving blocks into these:

else if (s.compare(0, 7, "TDPOINT") == 0) {
            VECTOR3 tdFwd, tdLeft, tdRight;    
            sscanf(s.substr(8).data(), "%lf,%lf,%lf %lf,%lf,%lf %lf,%lf,%lf", 
                &(tdFwd.x), &(tdFwd.y), &(tdFwd.z), 
                &(tdLeft.x), &(tdLeft.y), &(tdLeft.z),
                &(tdRight.x), &(tdRight.y), &(tdRight.z));
            SetTouchdownPoints(tdFwd, tdLeft, tdRight);
[COLOR=Red]            cmParams.ttdFwd = tdFwd;
            cmParams.ttdLeft = tdLeft;
            cmParams.ttdRight = tdRight;[/COLOR]
        }

        //Touchdown Points

        VECTOR3 tdFwd, tdLeft, tdRight;
[COLOR=Red]        tdFwd = cmParams.ttdFwd;
        tdLeft = cmParams.ttdLeft;
        tdRight = cmParams.ttdRight;[/COLOR]
        
        ss.str("");
        ss << tdFwd.x << "," << tdFwd.y << "," << tdFwd.z << " ";
        ss << tdLeft.x << "," << tdLeft.y << "," << tdLeft.z << " ";
        ss << tdRight.x << "," << tdRight.y << "," << tdRight.z;
        sprintf(buf, ss.str().data());

        sprintf(buf, ss.str().data());
        oapiWriteScenario_string(scn, "TDPOINT", buf);

and added this code block into SetCenterOfGravity after NewCOG gets calculated:

    VECTOR3 tdFwd, tdLeft, tdRight;    
[COLOR=Red]    tdFwd = cmParams.ttdFwd;
    tdLeft = cmParams.ttdLeft;
    tdRight = cmParams.ttdRight;[/COLOR]
    tdFwd += NewCOG;
    tdLeft += NewCOG;
    tdRight += NewCOG;
    SetTouchdownPoints (tdFwd, tdLeft, tdRight);

:hide:
Obviously, I messed it up somehow since the strings shown in red cause errors when compiling. I don't know very much about C++ syntax, all of this was made from other blocks of your code which seemed somehow similair to my needs. What should I do to make it work?:embarrassed:

 

[jedidia]

 vector<VECTOR3> ttdFwd;                   //stores absolute position of touchdown points
    vector<VECTOR3> ttdLeft;
    vector<VECTOR3> ttdRight;

To start out with, you are declaring three vectors of type VECTOR3. You need either three variables of VECTOR3 type, or one vector of them where you can store them at [0], [1], [2].

cmParams.ttdFwd = tdFwd;
            cmParams.ttdLeft = tdLeft;
            cmParams.ttdRight = tdRight;

You then go on and try to copy a VECTOR3 to a vector of VECTOR3s which of course doesn't work.

Say you defined

vector<VECTOR3> touchdownPoints

in cmParams, you fill the vector when loading with:

cmParams.touchdownPoint.push_back(tdFwd);
            cmParams.touchdownPoint.push_back(tdLeft);
            cmParams.touchdownPoint.push_back(tdRight);

retrieve the information like this:

tdFwd = cmParams.touchdownPoints[0];
        tdLeft = cmParams.touchdownPoints[1];
        tdRight = cmParams.touchdownPoints[2];

Just to clarify in case you didn't notice: a vector<> is a class used for data managment. It's basically a managed array that brings its own functions for memory allocation and iterators with it so you can easily insert variables wherever.
a VECTOR3 is an Orbiter class that stores and manages actual force vectors in 3-dimensional space.

 

[Hlynkacg]

I should warn you that the above will cause issues if it is called at every time step. Orbiter really hates it when you manipulate the TD points of a landed vessel because you're forcing it to recalculate the vessel's position attitude and velocity at every time step as opposed to simply fixing it relative to reference body.

This isn't a big deal at lower time accelerations but at a 100+ rounding errors make the vessel's position unstable and at 1000 or more the NaN-space catapult will activate. :lol:

 

[jedidia]

I should warn you that the above will cause issues if it is called at every time step.

It's only every 10 seconds actually, but yes, I would expect trouble in landed state...

 

[PeterRoss]

I do remember about landed state safeguard, I didn't made it yet because of testing reasons. Vessel doesn't gets catapulted into the sky when changing TDPs, at least in normal time mode, even if you change its propellant tank state from full to empty and vice versa. That's why it's much easier to test the feature in landed state.
Thanks for clarifications, gyus. Sorry for my incompetence, I've never meant to be a coder or whatever. Will fix the code when able.

---------- Post added at 08:31 ---------- Previous post was at 07:05 ----------

It's working, guys, it's working!:woohoo:

Here is the first IMS lander with functional touchdown points:

I changed vector declaration like this:

VECTOR3 ttdFwd;

and changed TD modifications in SetCenterOfGravity like this:

    tdFwd -= NewCOG;

It behaves funny when I empty its prop tank - COG gets shifted down and it appears hanging in the, err, vacuum(?) for a moment then slowly falls down on its TPs. When filling the tank it goes down smoothly. In any case, when CG shift is done, landing legs age standing right on the ground. It will not matter when landed safeguard implemented of course.

 

[jedidia]

I should warn you that the above will cause issues if it is called at every time step.

So in other words, the global position when landed does not actually get updated... how interesting. Can you place a reference object nearby to test if the vessel also moves in the other axes?

Sorry for my incompetence, I've never meant to be a coder or whatever.

Oh, you'll get hooked soon enough.

I'm kinda thinking, with the current state of affairs, we'll need a VCS repository. Problem is, of course, managing that would kinda eat up my time again.

 

[PeterRoss]

Here's the landed state safeguard code:

	VESSELSTATUS2 stat;
	memset (&stat, 0, sizeof(stat));
	stat.version = 2;
	GetStatusEx(&stat);
	if (stat.status == 1) 
		return;

Seems to work fine when placed right in the beginnig of SetCenterOfGravity. No CG shift when landed whatever I do, except of the very first shift when starting a scenario. When I take off the ground the shift happens lol withing ten seconds. After landing CG stops shifting again.

So in other words, the global position when landed does not actually get updated... how interesting. Can you place a reference object nearby to test if the vessel also moves in the other axes?

Here comes the problem. IMS lander appears moved by CG shift relative to a reference object. When you do a few SQLs it gets moved more and more.
Maybe I should place landed state safeguard into initial ShiftCG too?

---------- Post added at 08:21 ---------- Previous post was at 07:03 ----------

This shift occuring at the scenario start - it's camera shift after vessel coordinates gets recalculated from CM CG position to assembly CG position? So, when we save the vessel's state, do we save assembly CG coordinates? This explains why the vessel gets shifted with each SQL - Orbiter place CM at loaded coordinates. We should rewrite saveState in the way it moves vessel's CG to CM default point right before saving then.

 

[BruceJohnJennerLawso]

Here's the landed state safeguard code:

	VESSELSTATUS2 stat;
	memset (&stat, 0, sizeof(stat));
	stat.version = 2;
	GetStatusEx(&stat);
	if (stat.status == 1) 
		return;

Seems to work fine when placed right in the beginnig of SetCenterOfGravity. No CG shift when landed whatever I do, except of the very first shift when starting a scenario. When I take off the ground the shift happens lol withing ten seconds. After landing CG stops shifting again.



Here comes the problem. IMS lander appears moved by CG shift relative to a reference object. When you do a few SQLs it gets moved more and more.
Maybe I should place landed state safeguard into initial ShiftCG too?

---------- Post added at 08:21 ---------- Previous post was at 07:03 ----------

This shift occuring at the scenario start - it's camera shift after vessel coordinates gets recalculated from CM CG position to assembly CG position? So, when we save the vessel's state, do we save assembly CG coordinates? This explains why the vessel gets shifted with each SQL - Orbiter place CM at loaded coordinates. We should rewrite saveState in the way it moves vessel's CG to CM default point right before saving then.

I havent been following this discussion really closely, but its good to hear that touchdown points are progressing. If I remember correctly, Martins designed ShiftCG to drag along docking ports, attachments, & touchdown points with it, hence leading to our current struggles with internal IMS CG shifts?

While youre busy with that, I am proud to announce that I have found a stopgap for all of the centrifuge issues we had been experiencing. As I suspected, centrifuges can be built much easier when the first modules can be attached directly to the arm (as opposed to being attached to a node at its end)

The TC-02 part included in the latest Dauntless package can show you this. I also removed the Bullet-style command module since I royally screwed up meshing the aft part of it. I should have that fixed for 0.3

View attachment Dauntless_Industries 0.2.zip

 

[PeterRoss]

I havent been following this discussion really closely, but its good to hear that touchdown points are progressing. If I remember correctly, Martins designed ShiftCG to drag along docking ports, attachments, & touchdown points with it, hence leading to our current struggles with internal IMS CG shifts?

On the contrary, Orbiter ShiftCG applies to everything EXCEPT of touchdouwn points. Why is it goes this way remains a mystery for me. Maybe because they're meant to be changed by request (like retracting gears) which makes it unreasonable to automatically shift them. If touchdown points were affected too, it would have saved us from all the troubles. Judging by commented-out strings of the code IMS were using its own CG shift program in some older versions, but then it was switched into Orbiter's ShiftCG. And while all the coordinates' corrections are being made by Orbiter itself now, it doesn't work for touchdown points. And here I am inventing a bicycle.

While youre busy with that, I am proud to announce that I have found a stopgap for all of the centrifuge issues we had been experiencing. As I suspected, centrifuges can be built much easier when the first modules can be attached directly to the arm (as opposed to being attached to a node at its end)

Well, it drastically decreases the amount od docks/APs in the centrifuge, hence less chances for a bug to appear.

The TC-02 part included in the latest Dauntless package can show you this. I also removed the Bullet-style command module since I royally screwed up meshing the aft part of it. I should have that fixed for 0.3

Will take a look :yes:

 

[jedidia]

Here comes the problem. IMS lander appears moved by CG shift relative to a reference object.

Yes, that matches with the previous observation. Just wanted to make sure.

When you do a few SQLs it gets moved more and more.

And this is related to how you solved the problem. In your current code, ShiftCG doesn't get executed ever if the vessel is landed. However, the CoG has to be reset to the origin of the CM before saving, or you'll get all kinds of troubles with attachment and docking port positions. So while blocking the mass-related CoG shifts in landed state is fine, your current solution makes it impossible for IMS to reset the CoG for saving purposes, resulting not only in your current position shifting, but should also result in Dockport and attachment point offsets.

I would put the code you wrote there into clbkPostStep, where shiftCG is executed every 10 seconds (at least I think it was there). Just make not being landed an additional condition with the time interval, and see how that works out.

 

[PeterRoss]

Yes, that matches with the previous observation. Just wanted to make sure.



And this is related to how you solved the problem. In your current code, ShiftCG doesn't get executed ever if the vessel is landed. However, the CoG has to be reset to the origin of the CM before saving, or you'll get all kinds of troubles with attachment and docking port positions. So while blocking the mass-related CoG shifts in landed state is fine, your current solution makes it impossible for IMS to reset the CoG for saving purposes, resulting not only in your current position shifting, but should also result in Dockport and attachment point offsets.

I would put the code you wrote there into clbkPostStep, where shiftCG is executed every 10 seconds (at least I think it was there). Just make not being landed an additional condition with the time interval, and see how that works out.

It's in clbkPreStep actually.

I'll try it.


I tried to make it this way:

void IMS::SetCenterOfGravity(bool SetToZero) 
{

if (SetToZero)
    {
        ShiftCG(centerOfGravity * -1);
        centerOfGravity = _V(0,0,0);
        massCenter = _V(0,0,0);

        return;
    }

    VESSELSTATUS2 stat;
    memset (&stat, 0, sizeof(stat));
    stat.version = 2;
    GetStatusEx(&stat);
    if (stat.status == 1)
        return;

    ShiftCG(centerOfGravity * -1);

It's not working, although I don't understand why. SetCenterOfGravity(true) is being called right before calling VESSEL3::clbkSaveState(scn), it have to work:shrug:

Need more time to find it out.

---------- Post added at 07:19 ---------- Previous post was at 07:12 ----------

I tried it in your way:

	lifeSupportCalcDT += simdt;
    VESSELSTATUS2 stat;
    memset (&stat, 0, sizeof(stat));
    stat.version = 2;
    GetStatusEx(&stat);

    if (lifeSupportCalcDT > LIFE_SUPPORT_CALC_STEP && !newModuleAdded && stat.status == 0) 
    {
        SetCenterOfGravity();
    }

Not working. Or am I doing something wrong?

 

[jedidia]

The first version doesn't work because the CoG doesn't get reset after saving.

Can't quite make out what's wrong with the second one, maybe you could describe the symptoms a bit more clearly?

Also, You can optimise a bit by first checking if it is time to reset the center of gravity, and if it is, check if the vessel is landed. This way you do operations every frame that are only really necessary if the interval is up, and checking for the interval is a lot faster than checking out the vessel state.

 

[PeterRoss]

The first version doesn't work because the CoG doesn't get reset after saving.

Indeed :hmm: Although it should manifest itself in other way.

Can't quite make out what's wrong with the second one, maybe you could describe the symptoms a bit more clearly?

Also, You can optimise a bit by first checking if it is time to reset the center of gravity, and if it is, check if the vessel is landed. This way you do operations every frame that are only really necessary if the interval is up, and checking for the interval is a lot faster than checking out the vessel state.

Like this?

    if (lifeSupportCalcDT > LIFE_SUPPORT_CALC_STEP && !newModuleAdded) 
    {
        VESSELSTATUS2 stat;
        memset (&stat, 0, sizeof(stat));
        stat.version = 2;
        GetStatusEx(&stat);
        if (stat.status ==0)
        SetCenterOfGravity();
    }

Symptoms are the same: it is the whole vessel's CG coordinates are being saved into .scn and these coordinates are being used to spawn a CM when starting a scenario, which results in vessel's shift at the simulation start.
I have the feeling that CG isn't being shifted before saving at all.

---------- Post added at 23:04 ---------- Previous post was at 21:40 ----------

Symptoms are confirmed with original IMS RC2. I'm not telling it's your bug though.
Maybe I'm going to tell a stupid thing, but I have the feeling that Orbiter process ShiftCG during simulation state update. Hence, the shift has no time to occur between calling of ShiftCG and clbkSaveState. Am I wrong or am I wrong?

---------- Post added 21-03-13 at 00:26 ---------- Previous post was 20-03-13 at 23:04 ----------

I solved one problem, but spawned another one. Here's what I've changed in the very end of SetCenterOfGravity right after NewCOG is being calculated:

    RoundVector(NewCOG);
    centerOfGravity = NewCOG;
    massCenter = NewCOG;    

    if (COGInit) {
    ShiftCG(NewCOG);
    } else {
    ShiftMeshes (NewCOG * -1);
    ResetPointsToCOG();
    }

    VECTOR3 tdFwd, tdLeft, tdRight;    
    tdFwd = cmParams.ttdFwd;
    tdLeft = cmParams.ttdLeft;
    tdRight = cmParams.ttdRight;
    tdFwd -= NewCOG;
    tdLeft -= NewCOG;
    tdRight -= NewCOG;
    SetTouchdownPoints (tdFwd, tdLeft, tdRight);
    RedefineAirlockParams(SelectedAirlock);
    AdjustThrusters();
}

Everythings seems fine (no initial shift relatively to reference deltaglider, docking ports and thrusters are fine too) except that now my lander is being catapulted at the start of the scenario. Can't see why, to be honest. Maybe I'll have better luck finding it tomorrow

 

[jedidia]

Symptoms are the same:

I would expect so. As I said, it's merely optimisation.

I have the feeling that CG isn't being shifted before saving at all.

It is shifted, otherwise the docking ports would be messed up. I have a suspicion... could you please post your whole ShiftCenterOfGravity() function the way it currently looks?

Also, that last code snipet you posted above... It has a check to COGInit, which only shows false in the first frame (indeed it is used to identify whether the simulation is in the first frame), a call to both ShiftCG and ShiftMeshes (which gets executed automatically when ShiftCG is called, ergo you're shifting the meshes twice), as well as a call of ResetPointsToZero() which is deprecated and will cause all kinds of mayhem (should have commented out the function, my bad).

All in all, I'm not at all surprised that little piece of code leads to catapulting. You should never call an other function than IMS' own SetCenterOfGravity() to manipulate the CoG. There's too much stuff involved, so there's that one function to handle it all. Any and all things that have to be shifted manually have to be called in there, and it's got to be the only function ever called if the CoG needs modifying, otherwise we'll end up in one hell of a mess. That also means that messing up that function will lead to one hell of a mess, of course...

I know most of those lines are commented out in the current code, but they are commented out for a reason. They're left over from experimentation, and I really should have cleaned up that code better. Oh well.

 

[PeterRoss]

void IMS::SetCenterOfGravity(bool SetToZero) 
{

	ShiftCG(centerOfGravity * -1);
//	ShiftCentreOfMass(centerOfGravity * -1);
//	ShiftMeshes(centerOfGravity);
//	ResetPointsToZero();

	if (SetToZero)
	{
//		ShiftCG(centerOfGravity * -1);
		centerOfGravity = _V(0,0,0);
		massCenter = _V(0,0,0);

		return;
	}
 
//    VESSELSTATUS2 stat;
//    memset (&stat, 0, sizeof(stat));
//    stat.version = 2;
//    GetStatusEx(&stat);
//	if (stat.status ==1)
//		return;


//	ShiftCG(centerOfGravity * -1);

	VECTOR3 NewCOG = _V(0,0,0);
	vector<int> ignoreX;
	vector<int> ignoreY;

	RefreshLoadedMass();
	for (UINT i = 0; i < modules.size(); ++i)
	//sieves through the modules and marks up modules that are in symetrical position on at least one axis with equal mass
	{
		//ignore modules close to 0,0,x for x+y axes
		if (IsNear(modules[i]->pos.x, 0.0, 0.1))
		{
			ignoreX.push_back(i);
		}
		if (IsNear(modules[i]->pos.y, 0.0, 0.1))
		{
			ignoreY.push_back(i);
		}

		//check for symmetry in x+y axes
		for (UINT j = i + 1; j < modules.size(); ++j)
		{
			if (IsNear(modules[i]->config.mass + modules[i]->loadedMass, modules[j]->config.mass + modules[j]->loadedMass, 0.01))
			{
				if (IsNear(modules[i]->pos.x * -1, modules[j]->pos.x, 0.5) &&
					IsNear(modules[i]->pos.y * -1, modules[j]->pos.y, 0.5))
				{
					ignoreX.push_back(i);
					ignoreX.push_back(j);
					ignoreY.push_back(i);
					ignoreY.push_back(j);
				}
			}
		}
	}

	double runningMass = cmParams.config.mass + cmParams.loadedMass;
	for (UINT i = 0; i < modules.size(); ++i)
	{
		bool _ignoreX = false;
		bool _ignoreY = false;
		VECTOR3 modPos = modules[i]->pos;
		RoundVector(modPos);
//		modPos -= NewCOG;
		for (UINT j = 0; j < ignoreX.size(); ++j)
		{
			if (ignoreX[j] == i)
			{
				_ignoreX = true;
				break;
			}
		}
		for (UINT j = 0; j < ignoreY.size(); ++j)
		{
			if (ignoreY[j] == i)
			{
				_ignoreY = true;
				break;
			}
		}
		if (!_ignoreX)
		{
			NewCOG.x = ((NewCOG.x * runningMass) + (modPos.x * (modules[i]->config.mass + modules[i]->loadedMass))) / (runningMass + modules[i]->config.mass + modules[i]->loadedMass);
		}
		if (!_ignoreY)
		{
			NewCOG.y = ((NewCOG.y * runningMass) + (modPos.y * (modules[i]->config.mass + modules[i]->loadedMass))) / (runningMass + modules[i]->config.mass + modules[i]->loadedMass);
		}
		if (!IsNear(NewCOG.z, modPos.z, 0.1))
		{
			NewCOG.z = ((NewCOG.z * runningMass) + (modPos.z * (modules[i]->config.mass + modules[i]->loadedMass))) / (runningMass + modules[i]->config.mass + modules[i]->loadedMass);
		}
//		RoundVector(NewCOG, 100);
		runningMass += modules[i]->config.mass + modules[i]->loadedMass;
	}
//	
	RoundVector(NewCOG);
	centerOfGravity = NewCOG;
	massCenter = NewCOG;	

	if (COGInit) {
//	AdjustStoredDocks(newCOG - centerOfGravity);
//	ShiftCG(centerOfGravity - oldCoG);
	ShiftCG(NewCOG);

//	ShiftCentreOfMass(centerOfGravity);
//	ShiftMeshes(centerOfGravity * -1);
//	ResetPointsToCOG();
	} else {
	ShiftMeshes (NewCOG * -1);
//	AdjustStoredDocks (shiftBack);
	ResetPointsToCOG();
	}

	VECTOR3 tdFwd, tdLeft, tdRight;	
	tdFwd = cmParams.ttdFwd;
	tdLeft = cmParams.ttdLeft;
	tdRight = cmParams.ttdRight;
	tdFwd -= NewCOG;
	tdLeft -= NewCOG;
	tdRight -= NewCOG;
	SetTouchdownPoints (tdFwd, tdLeft, tdRight);
	RedefineAirlockParams(SelectedAirlock);
	AdjustThrusters();
}

---------- Post added at 01:47 ---------- Previous post was at 01:22 ----------

Also, that last code snipet you posted above... It has a check to COGInit, which only shows false in the first frame (indeed it is used to identify whether the simulation is in the first frame), a call to both ShiftCG and ShiftMeshes (which gets executed automatically when ShiftCG is called, ergo you're shifting the meshes twice),

I know about it, and I know it's not very smart, but I wanted to find workaround and I found it. I assume there are better options than this, but I'm still learning, you know
EDIT: By the way, although it calls both functions, it never calls them in one frame. What's wrong with it? In fact, I'm shifting the vessel's mesh so the loaded CM CG would be at the place of the vessel's CG, there were no ShiftCG called before it, only after.

as well as a call of ResetPointsToZero() which is deprecated and will cause all kinds of mayhem (should have commented out the function, my bad).

Well, it helped me to partially outgame the initial CG shift...

All in all, I'm not at all surprised that little piece of code leads to catapulting. You should never call an other function than IMS' own SetCenterOfGravity() to manipulate the CoG. There's too much stuff involved, so there's that one function to handle it all. Any and all things that have to be shifted manually have to be called in there, and it's got to be the only function ever called if the CoG needs modifying, otherwise we'll end up in one hell of a mess.

Okaaaaaay...

I know most of those lines are commented out in the current code, but they are commented out for a reason. They're left over from experimentation, and I really should have cleaned up that code better. Oh well.

Why, it's quite interesting to read commented out strings. New information and stuff. Just gotta be careful with them, OK.

 

[jedidia]

Right, let's go through this:

void IMS::SetCenterOfGravity(bool SetToZero) 
{

	ShiftCG(centerOfGravity * -1);
//	ShiftCentreOfMass(centerOfGravity * -1);
//	ShiftMeshes(centerOfGravity);
//	ResetPointsToZero();

	if (SetToZero)
	{
//		ShiftCG(centerOfGravity * -1);
		centerOfGravity = _V(0,0,0);
		massCenter = _V(0,0,0);

		return;
	}

If the CoG is set to origin of CM (which is always done before saving, so all points are saved relative to origin of CM) it exits the function here. Note that you didn't modify the touchdown points here. That means that before saving all points get reset to origin, but not the touchdown points. You have to reset them to origin before the return. That's what I suspected, and that's certainly one part of the trouble we're dealing with.

//yadayada calculate new CoG yada yada
//	
[COLOR="Red"]	RoundVector(NewCOG);               //not needed[/COLOR]
	centerOfGravity = NewCOG;
	massCenter = NewCOG;	

[COLOR="red"]	if (COGInit) {                  //flag used to check [I]initial initialisation[/I] of CoG. Will show false only in first frame of simulation! Also, no check is needed here. If the CoG was merely set to origin, the function has already terminated above[/COLOR]
//	AdjustStoredDocks(newCOG - centerOfGravity);
//	ShiftCG(centerOfGravity - oldCoG);
	ShiftCG(NewCOG);

//	ShiftCentreOfMass(centerOfGravity);
//	ShiftMeshes(centerOfGravity * -1);
//	ResetPointsToCOG();
	} else {
[COLOR="red"]	ShiftMeshes (NewCOG * -1);      //ShiftCG already calls ShiftMeshes. Calling it again will shift Meshes twice![/COLOR]
//	AdjustStoredDocks (shiftBack);
[COLOR="red"]	ResetPointsToCOG();     //deprecated function, will lead to all kinds of catastrophes. Should have cleaned it out, sorry[/COLOR]
	}

reset this whole block to what it was, it's a pretty awesome bugfest the way it currently is

original code (deleted the commented stuff as I should have done long ago):

	centerOfGravity = NewCOG;
	massCenter = NewCOG;
	ShiftCG(NewCOG);

	RedefineAirlockParams(SelectedAirlock);
	AdjustThrusters();

And finally, set touchdown points to new position:

	VECTOR3 tdFwd, tdLeft, tdRight;	
	tdFwd = cmParams.ttdFwd;
	tdLeft = cmParams.ttdLeft;
	tdRight = cmParams.ttdRight;
[COLOR="red"]	tdFwd -= NewCOG;     //I think this should be +, not -, but not 100% sure...
	tdLeft -= NewCOG;
	tdRight -= NewCOG;[/COLOR]
	SetTouchdownPoints (tdFwd, tdLeft, tdRight);
	RedefineAirlockParams(SelectedAirlock);
	AdjustThrusters();
}

I think this should work, with the touchdown points being correctly reset to zero with the CoG before saving, and setting them to the correct relative positions again with all the rest of the vessel. Also, for a bit more elegance, you can write:

	tdFwd = cmParams.ttdFwd +  NewCoG;  //aso, spares you the other three lines where you do the operation seperately and is easier to read

I know about it, and I know it's not very smart, but I wanted to find workaround and I found it. I assume there are better options than this, but I'm still learning, you know

Sure thing. Hope I didn't come over too strong.

 

[PeterRoss]

ShiftCG already calls ShiftMeshes. Calling it again will shift Meshes twice!

Nope. ShiftCG is only being called when COGInit==true while ShiftMeshes is being called when it's false, i.e. in the first frame.

If the CoG is set to origin of CM (which is always done before saving, so all points are saved relative to origin of CM) it exits the function here. Note that you didn't modify the touchdown points here. That means that before saving all points get reset to origin, but not the touchdown points. You have to reset them to origin before the return. That's what I suspected, and that's certainly one part of the trouble we're dealing with.

Well, I'm saving not the dynamic value of touchdown points but the same numbers which were loaded at the beginning, i.e. taken from cmParams.

---------- Post added at 02:19 ---------- Previous post was at 02:16 ----------

deprecated function, will lead to all kinds of catastrophes. Should have cleaned it out, sorry

Well, I've noticed no wrong influence from this part. Commenting it out doesn't stops the catapult.

Sure thing. Hope I didn't come over too strong.

Hah! Man, I'm working with clients at my job too. You juct CAN'T be too strong for me. :lol:

---------- Post added at 02:22 ---------- Previous post was at 02:19 ----------

I think this should be +, not -, but not 100% sure...

Well, when it finally falls down on the surface it stands on its legs perfectly, no matter how much its CG was sifted during flight.

---------- Post added at 02:28 ---------- Previous post was at 02:22 ----------

if (COGInit) { //flag used to check initial initialisation of CoG. Will show false only in first frame of simulation! Also, no check is needed here. If the CoG was merely set to origin, the function has already terminated above

The termination which occurs at the beginning of the function is only happens when saving, not at the first frame, and I need the first frame to shift the mesh.

---------- Post added at 02:30 ---------- Previous post was at 02:28 ----------

Gotta go sleep. I hope tomorrow will bring better results. :goodnight:

 

[jedidia]

Well, I'm saving not the dynamic value of touchdown points but the same numbers which were loaded at the beginning, i.e. taken from cmParams.

Uh hu... didn't think of that. Will have to think this through a bit.

The termination which occurs at the beginning of the function is only happens when saving, not at the first frame, and I need the first frame to shift the mesh.

Ok, now I see what you did there... I think putting that shift directly in this function wouldn't be quite the right place. very confusing. But I'll have to think this whole think through to see why the discreppancy happens in the first place...