# Idea2016 landing points from scenario

#### Donamy

Donator
Beta Tester
Ok, I have to completely close Orbiter, to get any changes in the attachment point. Also, getting different results from Dx7 and Dx9.

#### fred18

Donator
Ok, I have to completely close Orbiter, to get any changes in the attachment point. Also, getting different results from Dx7 and Dx9.
have you tried to move the vessel before checking the landend situation?

from my post yesterday:
1) this simple plugin allows to set Touchdown points via cfg file
2) it works for specific vessel's names or for specific vessel's classes. So if for example you want to have specific touchdown points for a Deltaglider that in your scenario will be called GL01, you'll have to create the GL01.cfg inside the config/TD_Pts_Updater/ folder while if you want all the Deltagliders to have your specific touchdown points you'll have to create the Deltaglider.cfg file in the same folder
3) it won't work properly for vessels who set Touchdown points during simulations by themselves (the DG for example changes its TD points while lowering and raising the gear), but there is nothing that can be don for that.
4) you probably will not see any changes for already landed vessels until you move them either by their engines or (suggested) via scenario editor. This is because in the scenario also the arot and alt parameters and saved and used to restore the state, so if it seems to you that nothing changed, try first to move the vessels.

#### Donamy

Donator
Beta Tester
Yes. It is working in Dx9, but if I move the vessel in Dx7, it's like it falls off a shelf and reverts to the default attachments,

#### 4throck

##### Enthusiast !
the plugin prints out the values it uses in orbiter.log, so users have a reference starting point
Yes it prints the values! :thumbup:

I tried some manual variations, they reduced bouncing but I was never able to get a landed state.

Here's something we can all test.
You need my [ame="https://www.orbithangar.com/searchid.php?ID=7108"]Test Satellite (Vinka's Spacecraft4)[/ame]

Scenario
Code:
BEGIN_DESC

END_DESC

BEGIN_ENVIRONMENT
System Sol
Date MJD 53329.6270717623
Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
Ship minisat100
END_FOCUS

BEGIN_CAMERA
TARGET minisat100
MODE Cockpit
FOV 50.00
END_CAMERA

BEGIN_HUD
TYPE Surface
END_HUD

BEGIN_MFD Left
TYPE Orbit
PROJ Ship
FRAME Ecliptic
REF Earth
END_MFD

BEGIN_MFD Right
TYPE Surface
SPDMODE 1
END_MFD

BEGIN_SHIPS
minisat100:spacecraft/spacecraft4
STATUS Landed Earth
POS -80.5906239 28.5189627
ALT 0.825
AROT 150.385 -6.591 -114.644
AFCMODE 7
PRPLEVEL 0:0.968004
NAVFREQ 0 0
CONFIGURATION 1
END
END_SHIPS

BEGIN_TD_Pts_Updater
END

TD Points (minisat100.cfg)
Code:
N = 3
POINT_1 =  0 4 -1.2
POINT_2 =  4 -4 -1.2
POINT_3 = -4 -4 -1.2

Once it loads try to rotate the ship, just to take it off the landed state.
Then let it rest.
It remains stable, although it never reaches the landed state as it should...

Last edited:

#### Donamy

Donator
Beta Tester
Yes it prints the values! :thumbup:

I tried some manual variations, they reduced bouncing but I was never able to get a landed state.

Here's something we can all test.
You need my Test Satellite (Vinka's Spacecraft4)

Scenario
Code:
BEGIN_DESC

END_DESC

BEGIN_ENVIRONMENT
System Sol
Date MJD 53329.6270717623
Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
Ship minisat100
END_FOCUS

BEGIN_CAMERA
TARGET minisat100
MODE Cockpit
FOV 50.00
END_CAMERA

BEGIN_HUD
TYPE Surface
END_HUD

BEGIN_MFD Left
TYPE Orbit
PROJ Ship
FRAME Ecliptic
REF Earth
END_MFD

BEGIN_MFD Right
TYPE Surface
SPDMODE 1
END_MFD

BEGIN_SHIPS
minisat100:spacecraft/spacecraft4
STATUS Landed Earth
POS -80.5906239 28.5189627
ALT 0.825
AROT 150.385 -6.591 -114.644
AFCMODE 7
PRPLEVEL 0:0.968004
NAVFREQ 0 0
CONFIGURATION 1
END
END_SHIPS

BEGIN_TD_Pts_Updater
END
TD Points (minisat100.cfg)
Code:
N = 3
POINT_1 =  0 4 -1.2
POINT_2 =  4 -4 -1.2
POINT_3 = -4 -4 -1.2
Once it loads try to rotate the ship, just to take it off the landed state.
Then let it rest.
It remains stable, although it never reaches the landed state as it should...
In Dx9 it just sits there. In Dx7 it rolls over and bobs a little.

#### 4throck

##### Enthusiast !
No difference here, I get the same behavior on both graphic clients...

Some progress.
This makes the minisat settle into a landed position after a few seconds.

Code:
; N = number of points,
; POINT_X = x y z stiffness damping mu mu_lng
;see orbiter api guide for further details

;mass=100;
;xtx_target=-0.1;
;xtst=(-1)*(mass*9.80655)/(3*xtx_target);
; » xtst = 3269.85
;xtda=0.9*(2*sqrt(mass*xtst));
; » xtda= 1029.28684048714

N = 3
POINT_1 =  0  4 -1.2 3269 1029 1 1
POINT_2 =  4 -4 -1.2 3269 1029 1 1
POINT_3 = -4 -4 -1.2 3269 1029 1 1
The values for mu seem to be the trick.

Last edited:

#### fred18

Donator
Careful that the wind effect changes a lot the thing here, since the satellite is so light and seems that sc4 somehow define some airfoil for it.

so when it is landed it keeps being pushed from wind here and there and doesn't get to rest. I tried to turn the wind off and it stopped almost immediately.

Anyway you are surely right: the harmonic oscillator is very sensitive to changes in values, especially for such a light vessel. If you put a vessel like 20 tons there it works, but such a light vessel find very easily numerical instability.

#### 4throck

##### Enthusiast !
:thumbup:

Yes.
I'm also testing with the heavy .dll landers from World of Colliers.
But I have the same issue.

They only rest after a few seconds if I manually set mu and mu_lng to zero.
This prevent landing autopilots from working, because they never get the landed state.

Any chance you can add a parameter to force a landed status ?

#### fred18

Donator
:thumbup:

Yes.
I'm also testing with the heavy .dll landers from World of Colliers.
But I have the same issue.

They only rest after a few seconds if I manually set mu and mu_lng to zero.
This prevent landing autopilots from working, because they never get the landed state.
after a few seconds is ok (from my tests I found out that orbiter probably wait 5 seconds to see if a vessel is actually landed) but mu = 0 is counter intuitive. It is a friction coefficient so the higher it is the quicker the vessel should get to rest :hmm:

Any chance you can add a parameter to force a landed status ?
everything's possible but I think it would be better to better calibrate the damping and stiffness coefficients in order to let the orbiter core do his job properly.

#### Donamy

Donator
Beta Tester
A little OT, but a eureka moment for me. Maneuver any base to an position, rotation or height. Just attach it to this.

A BasePositioner :

Code:
[CONFIG]
FOCUS=1
Size = 50
Empty_Mass = 90
Fuel_Mass = 50
ATTITUDE_THRUST=5110
ISP=3200
Camera = (0,0,0)

[PARENT_ATTACH_0]
name= "object"
POS=(0.00,-2.04,-1.10)
DIR=(0,0,1)
ROT=(0,1,0)
LOOSE=0
ID=GS
RANGE=0.5

[CHILD_ATTACH_0]	; attachment to ground
NAME="Attach"
POS=(0.0,0.0,0)
DIR=(0,1,0)
ROT=(0,0,1)
LOOSE=0
RANGE =5

[ROBOTIC_ARM]
JOINT_0_NAME="left right"
JOINT_0_SEQ=0
JOINT_0_RANGE=(0,25)
JOINT_1_NAME="forward back"
JOINT_1_SEQ=1
JOINT_1_RANGE=(0,25)
JOINT_2_NAME="up down"
JOINT_2_SEQ=2
JOINT_2_RANGE=(0,25)
JOINT_3_NAME="pitch"
JOINT_3_SEQ=3
JOINT_3_RANGE=(-360,360)
JOINT_4_NAME="yaw"
JOINT_4_SEQ=4
JOINT_4_RANGE=(-360,360)
JOINT_5_NAME="roll"
JOINT_5_SEQ=5
JOINT_5_RANGE=(-360,360)
GRAP_SEQ=0
GRAP_ATTACH=0

[ANIM_SEQ_0]	;EVA_translate, left right
INIT_POS=0.5
DURATION=100

[ANIM_SEQ_1]	;EVA_translate, forward back
INIT_POS=0.5
DURATION=150

[ANIM_SEQ_2]	;EVA_translate, up down
INIT_POS=0.5
DURATION=100

[ANIM_SEQ_3]	;EVA_pitch
INIT_POS=0.5
DURATION=100

[ANIM_SEQ_4]	;EVA_yaw
INIT_POS=0.5
DURATION=100

[ANIM_SEQ_5]	;EVA_roll
INIT_POS=0.5
DURATION=100

[ANIM_COMP_0] 	;EVA_translate, left Right
SEQ=0
GROUPS=0
RANGE(0,1)
TYPE=TRANSLATE
SHIFT=(50,0,0)

[ANIM_COMP_1] 	;EVA_translate, forward back
SEQ=1
GROUPS=0
RANGE(0,1)
TYPE=TRANSLATE
SHIFT=(0,50,0)
PARENT=0

[ANIM_COMP_2] 	;EVA_up down
SEQ=2
GROUPS=0
RANGE(0,1)
TYPE=TRANSLATE
SHIFT=(0,0,50)
PARENT=1

[ANIM_COMP_3] 	;EVA_pitch
SEQ=3
GROUPS=1
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0,0,0)
ROT_AXIS=(1,0,0)
ANGLE=720
PARENT=2

[ANIM_COMP_4] 	;EVA_yaw
SEQ=4
GROUPS=1
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0,0,0)
ROT_AXIS=(0,1,0)
ANGLE=720
PARENT=3

[ANIM_COMP_5] 	;EVA_pitch
SEQ=5
GROUPS=1
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0,0,0)
ROT_AXIS=(0,0,1)
ANGLE=720
PARENT=4

[ANIM_COMP_6]	; tip
SEQ=0
RANGE=(0,1)
TIP_1=(0.0,0.0,0.0)
TIP_2=(0.0,1.0,0.0)
TIP_3=(0.0,0.0,1.0)
PARENT=5

#### 4throck

##### Enthusiast !
after a few seconds is ok (from my tests I found out that orbiter probably wait 5 seconds to see if a vessel is actually landed) but mu = 0 is counter intuitive. It is a friction coefficient so the higher it is the quicker the vessel should get to rest :hmm:

My tests show the opposite. Higher values create larger bounces (changes to mu only, the other parameters unchanged). That's odd I know...

let the orbiter core do his job properly.

Sure! That's what I'm trying to do, to find the right values.
Perhaps more testing is needed.

Anyway, thanks again for the plugin, I'm having fun flying World of Colliers on Orbiter 2016!

#### jacquesmomo

Hello Fred

I just begin to test your module.

For my test, I used my Tintin's DC6 addon for Orbiter 2010
.It's a SC4 vessel and there are 2 problems with Orbiter 2016 :
- taxiing is impossible (I can not turn, the plane continues straight ahead)
- and uncontrollable sliding on landing.

I had a hard time adjusting the touchpoints, but I finally I succeeded.

So, Here is my scn file :

Code:
BEGIN_SHIPS
DC-6:DC-6
STATUS Landed Earth
POS -80.6826101 28.5969478
RCSMODE 0
AFCMODE 7
PRPLEVEL 0:1.000000
NAVFREQ 94 481
CONFIGURATION 1
END
(I deleted the AROT and RVEL parametres)

My "DC-6.cfg" file (in the \Config\vessels folder)
Code:
ClassName = DC-6
Module = Spacecraft4
And of course my "DC-6.ini" file is in the \Spacecraft folder.
;LAND_PT1=(0,-2.35,10.338)
;LAND_PT2=(-3.691,-2.30,-1)
;LAND_PT3=(3.691,-2.30,-1)

So, i created a cfg file in the " \Config\TD_Pts_Updater" folder named "DC-6.cfg" with inside :
Code:
N = 3
POINT_1 =  0  -2.45 10.34  2000000  100000 1.0  0.01
POINT_2 =  -3.5 -2.45   -2.3  2000000  100000 1.0  0.1
POINT_3 = 3.5  -2.45   -2.3  2000000  100000 1.0  0.1
But.... with this values, my aircraft turn right !!!

And if we look at the "orbiter.log" file, we have this :
Code:
TD Points Updater: Vessel Definition found for name DC-6
point1 : 0.000 -2.450 10.340 2000000.000 100000.000 1.000 0.100 ;<<<<< this is ok
point2 : -3.500 -2.450 -2.300 2000000.000 100000.000 1.000 0.100 ;<<<<< this is ok
point3 : 3.500 -2.450 -2.300 2000000.000 100000.000 1.000 1.000 ;<<<<< should be 0.1

Then I modified the last values :
Code:
N = 3
POINT_1 =  0  -2.45 10.34  2000000  100000 1.0  0.01
POINT_2 =  -3.5 -2.45   -2.3  2000000  100000 1.0  0.1
POINT_3 = 3.5  -2.45   -2.3  2000000  100000 1.0  0.1
Now it's ok my aircraft goes straight ahead !!!

And if we look at the "orbiter.log" file, we have this :
Code:
TD Points Updater: Vessel Definition found for name DC-6
point1 : 0.000 -2.450 10.340 2000000.000 100000.000 0.100 0.010 ;<<<<< this is ok
point2 : -3.500 -2.450 -2.300 2000000.000 100000.000 0.100 0.100 ;<<<<< this is ok
point3 : 3.500 -2.450 -2.300 2000000.000 100000.000 0.100 0.100 ;<<<<< this is ok

Third test with other values :
Code:
N = 3
POINT_1 =  0  -2.45 10.34  2000000  100000 1.0  0.1
POINT_2 =  -3.5 -2.45   -2.3  2000000  100000 1.0  0.2
POINT_3 = 3.5  -2.45   -2.3  2000000  100000 1.0  0.2
Now my aircraft my aircraft turn left !!! ???

And if we look at the "orbiter.log" file, we have this :
Code:
TD Points Updater: Vessel Definition found for name DC-6
point1 : 0.000 -2.450 10.340 2000000.000 100000.000 0.100 0.100 ;<<<<< this is ok
point2 : -3.500 -2.450 -2.300 2000000.000 100000.000 0.100 0.200 ;<<<<< this is ok
point3 : 3.500 -2.450 -2.300 2000000.000 100000.000 0.100 0.100 ;<<<<< should be 0.2
Strange, no ???

Last thing, can you explain to me what is the fonction of :
- stiffness
-damping

And... if I set a value for the "mu longitudinal coefficient" to hight (3 for exemple) my aircraft does'nt move ahead... (but turns left !!)
and the "orbiter.log" file write this :
Code:
TD Points Updater: Vessel Definition found for name DC-6
point1 : 0.000 -2.450 10.340 2000000.000 100000.000 0.100 3.000 ;<<<<< this is ok
point2 : -3.500 -2.450 -2.300 2000000.000 100000.000 0.100 3.000 ;<<<<< this is ok
point3 : 3.500 -2.450 -2.300 2000000.000 100000.000 0.100 0.100 ;<<<<< should be 3
:facepalm:

So, I continue my tests.....

Amicalement :cheers::tiphat:
Jacques

#### 4throck

##### Enthusiast !
My understanding is that mu and mu longitudinal control forward/back and left/right friction.

---------- Post added at 19:41 ---------- Previous post was at 18:46 ----------

Ok, this works for the DC-6:

Lower values for the landing gear
Code:
[LANDING_GEAR]
WHEEL_FRICTION=0.001
BELLY_FRICTION=10
BRAKE_FORCE=200
SEQ=14

Used the values computed by the plugin (check orbiter.ini) and increased mu.
Code:
N = 3
POINT_1 = 0.0  -2.45   10.34  314488.980 190776.347 300.000 300.000
POINT_2 =-3.5  -2.45   -2.3   314488.980 190776.347 300.000 300.000
POINT_3 = 3.5  -2.45   -2.3   314488.980 190776.347 300.000 300.000

Needs tweaking to get correct acceleration on runway, ground taxi radius, etc.
But it's good enough to take-off.

#### fred18

Donator
Ok, first of all thanks jacques, I think you found a small bug in the module: while writing the code that reads the values from the cfg file I was thinking in a "0 based" world, so 0, 1, 2... but for being user friendly I had set the points to be "1 based" so 1, 2, 3 and the value of mu longitudinal of the third point got caught in this. I corrected this and at the same LINK you can download the corrected version of the plugin!

Now I would like to share all my understanding of the touchdown points of Orbiter 2016 so everybody can have a comprehensive understanding of the matter.

- in orbiter 2010 only 3 points could be set for TD points, and they were thought to simulate a landing gear, but with no terrain-ship collision detection at all. In orbiter2016 there is the possibility to define a larger set of touchdown points that can describe the shape of the hull of your vessel. This means that in orbiter 2010 the Deltaglider could fly with its wing underneath the surface of the terrain, while in orbiter2016 if the wing touches the terrain it bounces back.
- in order to achieve this Martin suggested in the documentation and on the forum to select a set of the key touchdown points for the vessel (not too many or the performances impact could be too high). I attach here the touchdown points base definitions in the code for Deltaglider and the Atlantis (note that the points would change if landing gear is extended or retracted)
Code:
//DELTAGLIDER
static const DWORD ntdvtx_gearup = 13;
static TOUCHDOWNVTX tdvtx_gearup[ntdvtx_gearup] = {
{_V( 0   ,-1.5 ,9),     1e7, 1e5, 3.0, 3.0},
{_V(-6   ,-0.8 ,-5),    1e7, 1e5, 3.0, 3.0},
{_V( 3   ,-1.2 ,-5),    1e7, 1e5, 3.0, 3.0},
{_V(-8.5 ,-0.3 ,-7.05), 1e7, 1e5, 3.0},
{_V( 8.5 ,-0.3 ,-7.05), 1e7, 1e5, 3.0},
{_V(-8.5 ,-0.4 ,-3   ), 1e7, 1e5, 3.0},
{_V( 8.5 ,-0.4 ,-3   ), 1e7, 1e5, 3.0},
{_V(-8.85, 2.3 ,-5.05), 1e7, 1e5, 3.0},
{_V( 8.85, 2.3 ,-5.05), 1e7, 1e5, 3.0},
{_V(-8.85, 2.3 ,-7.05), 1e7, 1e5, 3.0},
{_V( 8.85, 2.3 ,-7.05), 1e7, 1e5, 3.0},
{_V( 0   , 2   , 6.2 ), 1e7, 1e5, 3.0},
{_V( 0   ,-0.6 ,10.65), 1e7, 1e5, 3.0}
};

//ATLANTIS
static TOUCHDOWNVTX tdvtx[14] = {
{_V( 0,    -3.3,18.75), 1e8, 1e6, 1.6, 0.1},
{_V(-3.96, -5.5, -3.2), 1e8, 1e6, 3, 0.2},
{_V( 3.96, -5.5, -3.2), 1e8, 1e6, 3, 0.2},
{_V(-11.9, -2.1, -10),  1e8, 1e6, 3},
{_V( 11.9, -2.1, -10),  1e8, 1e6, 3},
{_V(-11.3, -2.1, -6),   1e8, 1e6, 3},
{_V( 11.3, -2.1, -6),   1e8, 1e6, 3},
{_V(-2.95, -2.0,-14.35),1e8, 1e6, 3},
{_V( 2.95, -2.0,-14.35),1e8, 1e6, 3},
{_V(-1.9,  -1.0,-14.8), 1e8, 1e6, 3},
{_V( 1.9,  -1.0,-14.8), 1e8, 1e6, 3},
{_V( 0,    11.2,-16.4), 1e8, 1e6, 3},
{_V( 0,    11.3,-14.0), 1e8, 1e6, 3},
{_V( 0,    -0.9, 20.6), 1e8, 1e6, 3}
};
let's analyse the values of touchdownvtx definition:
touchdownvtx = position.x, position.y, position.z, stiffness, damping, mu, mu_lng;

what is each one of these?
the first 3 values (position x,y and z) are the easiest to understand: they represent the position of the touchdown point in the local vessel frame. So, not much to say about this.

After that there is the couple of values that are called stiffness and daming. What are these? well, in order to have a realistic behaviour orbiter models each point as a damped harmonic oscillator, please see here: https://en.wikipedia.org/wiki/Harmonic_oscillator#Damped_harmonic_oscillator.
To make it very short just think about the suspension of a car: it has a spring to counter act forces, and a damper to soften the oscillations, right? well in orbiter each touchdown point is a small suspension, with its own spring, whose force is defined by the stiffness coefficient, and its own damper, whose behaviour is defined by the damping coefficient.

So when your vessel hits the ground at one of those points the behaviour simulated is that the pointl is compressed by the force of impact, and then the spring pushes back while the damper softens the oscillations. The higher the stiffness, the stronger the spring will push back and your vessel will jump back strongly, the higher the damping, the more your vessel will behave unnaturaly.

Now this is a huge improvement on the path of realism but also a bit of headache for developers because finding the right values for those coefficient is not so easy.

The temptation that one can have could be to set those number to a ridicoulosly high or low number to avoid issues, but it won't work at all and that is because another thing to keep in mind while looking for the right values is what is called the numerical instability. Why is it an issue? now think about this: orbiter is not of course reality and render the simulations at discrete time steps. Now imagine that you're looking for an equilibrium of your vessel on the ground but a small force produces a compression of the spring that in the next time steps produces a force in reply that is higher than the first, and then again and again... what happens? that a sort of resonance will begin and the resultant force will be so high that instead of finding an equilibrium on ground your ship will be plunged into space at light speed...

So my suggestion for finding those values is to use the equation of the harmonic oscillator, set a target displacement, choose values so it will be around the critical damping and see what happens. That is what the plugin is doing to find the default points: it has a target displacement of 1 meter (that is a lot, but in the end it works), and a damping ratio of 0.95 and sets the default values. Then users can play around from there.

that was the hardest concept of the all thing

Now the mu coefficients, mu and mu_lng, the last two.

They are the friction coefficient of the touchdown point against the ground, plain and simple: https://www.engineeringtoolbox.com/friction-coefficients-d_778.html

now, before explaining the difference between mu and mu_lng there is an important point:

the first 3 touchdown points defined are still treated by orbiter as if they represent the landing gear! they are treated "specially" because depending on the order in which they are set, they define the UP direction of the vehicle. I don't have a sure rule for this, I'm also not sure if orbiter makes the convex hull implementation, and honestly for this particular aspect I have just been going by trial and error, but it seems to me that the UP direction is the one from which you see the points defined clockwise. Again I could be wrong about this last point anyway.

So what is the difference between mu and mu_lng? that is quite simple: for all the points except the first three mu is the friction coefficient in every direction. Let's think about the wing of the Deltaglider: it will have a friction with the terrain if it touches that (for obvious simplicity needs) will be the same in every direction. That is why for all the points except the first three just mu is required.
And the first three points? As said they are considered like a landing gear, so to simulate wheels behaviour the vessel should have much less friction in the longitudinal direction than in the lateral, so if it wants to slide laterally the friction will be higher than longitudinally and it will go straight forward or almost, and that is why you have two definitions for the first 3 points: mu is the lateral friction coefficient, while mu_lng is the longitudinal friction coefficient. If you want to simulate a ship with wheels I strongly recommend to use a lower value for mu_lng because otherwise you will probably see your ship drift laterally instead of going straight!

That's it, I hope that was clear and useful for everybody
:cheers:

Fred

#### Donamy

Donator
Beta Tester
Sounds alot clearer to me, but I have a couple questions. Can the plugin use more than 3 TDPs and how are they read ? Say the fouth was the belly, just need to be placed higher, and also the wings ?

#### fred18

Donator
Sounds alot clearer to me, but I have a couple questions. Can the plugin use more than 3 TDPs and how are they read ? Say the fouth was the belly, just need to be placed higher, and also the wings ?
In the plugin you can define as many as you want, just change the N parameter and therefore the POINT_ definitions accordingly, from the fourth point onward the mu_lng definition will just be ignored and can be avoided since only the mu parameter will be considered.

However, since you mentioned the belly I wouldn't define specifically that and here's why:
Vessels done with the c++ code can change their touchdown points during sim. Atlantis and Deltaglider do that when you lower or raise the landing gear. They have two sets of touchdown points ready, one defines the belly, the other the landing gear and they switch from one to the other depending on gear status, so if the gear is up you will end up landing on the belly while if the gear is down you will properly land on the wheels. This thing will be dramatically difficult to code from outside the vessel code itself, like from this plugin. This means two things:
1) only one set of touchdown points can be defined via the plugin and has to remain the same
2) as mentioned in the notes on the plugin, if the ship changes its own touchdown points by itself (like Deltaglider or Atlantis when they lower or raise their gear for example) the plugin will be overridden by the vessel and nothing can be done for that.

So if you define the belly point within the same set of touchdown points of the gear it will never be used since the gear points will always be lower than the belly.
In particular the touchdown point definitions should form a convex shape.

This is mentioned also in martins notes for the new definitions of touchdown points, I don't know if it is particularly required, but surely it is advised since points inside the shape will never be used. So I would define the 3 landing gear points, the wings, the back, the top, the nose etc. But not the belly

Last edited:

#### jacquesmomo

Bonjour Fred

Ok, first of all thanks jacques, I think you found a small bug in the module
You're welcome, your module really interests me a lot. So I restarted my tests, so this problem is fixed.:hail:

Thank you for your long and detailed explanations which are very clear ....

But I noticed another thing that intrigues me ....
For my test, I still used my Tintin's DC6 addon...

My starting scenario is always this one :
Code:
BEGIN_SHIPS
DC-6:DC-6
STATUS [B][COLOR="Red"]Landed Earth[/COLOR][/B]
POS -80.6826101 28.5969478
RCSMODE 0
AFCMODE 7
PRPLEVEL 0:1.000000
NAVFREQ 94 481
CONFIGURATION 1
END
But if I save this scenario again (without moving), I have this:
Code:
BEGIN_SHIPS
DC-6:DC-6
STATUS [B][COLOR="Red"]Orbiting Earth[/COLOR][/B]
RPOS -5437352.229 3320274.825 28671.092
RVEL 94.3776 157.6978 -364.1880
AROT 27.574 -15.049 -62.615
(...) <===== SC4 animations and others lines statuts
END
To have this, I just have to move a little forward and stop, and wait few seconds...
Code:
BEGIN_SHIPS
DC-6:DC-6
STATUS [COLOR="red"]Landed Earth[/COLOR]
POS -80.6827195 28.5971095
ALT 2.105
AROT 68.167 35.995 10.767
(...) <===== SC4 animations statuts
END
But all this does not matter I think ...

@ 4throck :
I Used the values computed by the plugin (check orbiter.ini) and increased mu.
N = 3
POINT_1 = 0.0 -2.45 10.34 314488.980 190776.347 300.000 300.000
POINT_2 =-3.5 -2.45 -2.3 314488.980 190776.347 300.000 300.000
POINT_3 = 3.5 -2.45 -2.3 314488.980 190776.347 300.000 300.000
I tried theses values, but (for me) :
- when I start the scn, the aircarft is under the ground and stays below the ground even if I move or wait...
(I also tried these values given by the pluggin in the "orbiter.log" file)
I tried some different values for dd (stiffness ) and ee (damping) and I find these values :
dd=300000 ee=45000
If I set higher values, the aircraft is (and stays) under the ground.....
- for ff and gg values, with 300.000 (done by the pluggin in "orbiter.log" file) the aircraft can't move...
The highter values I found are ff=5.0 and gg=0.01.
Else if higher the plane can't move.

So, the best values I found (for now) are :
Code:
N = 3
POINT_1 =  0  -2.45 10.34  300000  45000 5 0.01
POINT_2 =  -3.5 -2.5   -2.3  300000  45000 4 0.01
POINT_3 = 3.5  -2.5   -2.3  300000  45000 4 0.01
And with this values, it still slides.... but less as with only SC3/4 alone. (I hope you understand, my english is not perfect...) :lol:
So, it is enough for take off (we can ajust the heading) but taxiing is impossible, the aircraft can't turn enough on the ground.

@ Fred :
it's too bad that it does not work as well as your "General_vehicle" module... (which is really great !!! ) I try with it, but (logical !) it's impossible to take off....

a solution could be this one:
to use a "general_vehicle" for towing the aircraft on taxiway to the runway, then detach it and take off.

I also had another idea, but I did not have time to test it :
1) a invisible "general_vehicle" car docked (and not "attached") with the plane to move on the taxiways
2) then set to "aircaft" (F3) for take off. (with the invisible car still docked).
I don't know yet if it is possible, but I'll try this.....

Of course the better way should to have a new "Spacecraft" module for Orbiter 2016, but I am not sure Vinka has enough time for this....

I continue my tests.....:tiphat:

Amicalement:hello:
Jacques

Last edited:

#### 4throck

##### Enthusiast !
I understand perfectly

Taxing is a special case, where SC4 defines extra parameters for landing gear.
You might need to change those values to match the new landing points.
Perhaps you can turn with brakes ?

Anyway, more testing is needed...

#### fred18

Donator
To have this, I just have to move a little forward and stop, and wait few seconds...

But all this does not matter I think ...
it can happen for many reasons. I noticed that orbiter itself waits 5 seconds to establish that the vessels are landed when a scenario is open. So if you don't wait for 5 seconds the vessels will be orbiting instead of landed. Moreover, also if the vessels is not in a perfect flat terrain and the friction is not enough it will start to slide, even very slowly and this will prevent the landed status to be reached. It's a mix of things to keep controlled.

@ Fred :
it's too bad that it does not work as well as your "General_vehicle" module... (which is really great !!! ) I try with it, but (logical !) it's impossible to take off....

a solution could be this one:
to use a "general_vehicle" for towing the aircraft on taxiway to the runway, then detach it and take off.

I also had another idea, but I did not have time to test it :
1) a invisible "general_vehicle" car docked (and not "attached") with the plane to move on the taxiways
2) then set to "aircaft" (F3) for take off. (with the invisible car still docked).
I don't know yet if it is possible, but I'll try this.....

Of course the better way should to have a new "Spacecraft" module for Orbiter 2016, but I am not sure Vinka has enough time for this....

I continue my tests.....:tiphat:

Amicalement:hello:
Jacques
I thought about this many times. One option to try could be to implement the GV so it transmits velocity to attached vessels, so basically you can use a ghost GV to taxi and then for take off, like a catapult of an aircraft carrier.

Anyway if you can't turn while taxiing, try to press the "." and the "-" keys on the keyboard (or the correspondant in the french layout), they apply differential braking and allows to turn while taxiing.