Nodding donkey, Seesaw, bounce, oscillation

[alexis99 124]

Sometimes you get a third party aircraft where the nose moves up and down when you get in the cockpit. It sort of oscillates, and gradually settles. Then you power up and it noses down again. I couldn't find any information on how to fix this. My search terms above, gave me nothing of use. So I decided to investigate.

I wondered if the front wheel was too low, so I increased the RollingRadius of the Nose Gear in the aircraft data.ini. This just visually raised the wheel a couple of feet off the tarmac, and still the aircraft seesawed.

So then I remembered how we used to fix things in other Sims, and I sought out the Center of Gravity.  CGPosition comes under Aircraft Data  in the Data.ini. There are three numbers which relate to left/right, forward/backward, up/down. The centre number is the important one. Plus numbers push the CG forward, which is what I needed. Minus numbers push it backwards.

I adjusted the number until I got a stable aircraft. Then I looked at the outside view, and the wheel was now buried in the tarmac. So I went back to the Rolling Radius, and increased that number until I got the wheel resting on the tarmac. Sorted.

So is there a better way to do this, or is this the technique?

[+yakarov79 11,003]

It is possible that moving CG in data.ini screws up all other coordinates? (weapon stations, effects, pilot seats, etc)

[+Cliff7600 1,148]

For the rolling radius of the wheel it should be the number issued of the 3D model. It needs to be calculated from the coordinates of the wheel.
But the ShockStroke value will affect the visual result if the shock animation (if used) has a more little displacement on the 3D model.
As far as I know it won't solve poor behaviours on ground. But it needs to be set.

I experimented lately that the CG value can improve the handling when taxiing, by increasing the weight on the wheel, as you said.
But it won't solve the bounces.
And Yakarov is right, at least moving the CG values will change the cockpit position. You'll have to adjust it to have it back where it was, like an offset setting of the cockpit.
(And there's also a "Cockpit set CG position" or something like that...)

First, the wheels must be symmetrical between left and right. It's a 3D model matter, and if the model has this issue you can stop trying to fix it by ini (or maybe creating fake wheels by ini only ?)
Then there's many parts involved : EmptyMass, MassFraction, Reference values, Min/MaxExtentPosition, ShockStroke / SpringFactor / DampingFactor for each wheel, center of the 3D model (3D related), CGposition as you did, and some lift values of components if not set as they should (TW flight models are not optimised for taxiing, just take-off and landing runs), fuel tanks position and weight, and probably other things I forget.

As an ini guy the worst for me is the 3D model because I cannot move it.
And most of the time there's some Min/MaxExtentPosition values that are correct for the 3D model but makes the ini model touches the ground because of the angle of rotation or the stance on the ground.
If the box made from the Min/MaxExtentPosition values touches the ground it can produce bounces.

So I would say, check all structural entries using the famous Mue's LOD viewer and then all the FM values that has an effect on the ground
(at 0 speed there shouldn't be any lift or drag but that will affects the FM - take-off / landing / stalling / departing / maneuvring and TW's FMs are not optimised for being realistic when not flying)

I mentioned TW FM's because they should be taken as a model for third party aircraft, as a starting point at least.

In the end, you have no certitude of solving the problem, but that's the deal ^^

[bazillius 1,258]

everything in this simulator you will fix by iterating over numbers. Unfortunately, there are no universal values. It is difficult to predict how the plane will behave. Well, you will fix something in each plane every day. These will have to be dealt with. I dont recomend to play with CGP so it can influence on Floight Model in general as it was told above. Fix in Gears section. But for experiment sure check and change everything :D

Looka at this section in Gears section ao a data ini file:

ShockStroke=
SpringFactor=
DampingFactor=

I fix dancing aircrafts here usualy. try to add weight to aircraft itself. Real EmptyMass not works sometomes and aircraft sometimes less realistic in flying with it  real EmptyMass. so dificult to say what need specific aircraft to be realistic and playable

Edited January 3, 2023 by bazillius

[alexis99 124]

Yes, that's what worried me, I thought that moving the CG would be bound to affect the flight performance a little. It actually hasn't in any noticeable way. Presumably it all depends on what scale the numbers refer to. In my case I changed it by 1.5 somethings forward. I looked in a few other aircraft to see what their CGs were, and 1.5 was a normal figure.

There's no mention of CG in the A-6 cockpit.ini. I did a spot check, so will have to go through other planes to see if they have an entry. But I don't see why changing the CG would alter the cockpit position. All you are doing is moving the balance point of the aircraft.

As we know from the knowledge base you can use any cockpit you like and whack it into another aircraft by replacing the cockpit folder, the cockpit.ini and the avionics.ini. Changing the CG has never been mentioned. They say don't change the cockpit position, but you often have to if you're now using the Phantom cockpit in the B-57, for instance. So I cannot see the connection betweeen CG and cockpit position.

I have considered

ShockStroke=
SpringFactor=
DampingFactor=

But the ones on the aircraft I am having problems with don't seem widely different to most other aircraft. The parameters are not that wide.

Thanks everyone for your input. This gives me ideas for further tinkering,

[+Cliff7600 1,148]

1 hour ago, alexis99 said:

you can use any cockpit you like

That's true.
You can even use no cockpit at all, as long as there's a cockpit.ini file.
A 3D model of a cockpit is not necessary to make an aircraft flyable. The cockpit.ini file is.

1 hour ago, alexis99 said:

They say don't change the cockpit position

I almost always change the cockpit position. It's very rare to have it exactly where it should be "straight from the box".

1 hour ago, alexis99 said:

So I cannot see the connection betweeen CG and cockpit position

If the cockpit has a position there should be a 0,0,0 point to refer to.

 

[alexis99 124]

Yes, I admit that I almost always change the cockpit position for the reason you state. Then I fix Offset and View angle to get the flight path marker showing in the HUD when I come in to land. And I re-arrange and upgrade the HUD discretes to my liking, and tune-up the Radar, RWR and EO displays. I love the fact you can have them at 512 size.

There's the confession: I love a new aircraft so I can tinker with it.

There is a position reference for the cockpit in the model and it's exactly that set of three numbers in the Cockpit.ini under [CockpitSeat001] called Position, sandwiched between Offset and ViewAngles:

Offset=-0.003,-0.2,0.08
Position=-0.35,2.55,0.74
ViewAngles=0.0,-5.0,0.0

I claim that it has no bearing on CG, just on where you sit in the aircraft.

[+Cliff7600 1,148]

On 03/01/2023 at 10:23 AM, alexis99 said:

CGPosition comes under Aircraft Data  in the Data.ini

I am talking about changing this set of values, in the data.ini file.

The position values in the cockpit.ini file has no effect on the center of gravity indeed.
But changing the CGPosition in the data.ini file changes also where you sit in the aircraft :

TW's Hunter :

After adding a
"CGPosition=0.0,2.0,0.0"
line in the [AircraftData] part in the data.ini file :

You're sitting 2 meters forward and I didn't change the position values in the cockpit.ini file.

[alexis99 124]

Well that's fascinating. 

The CG is nominally the point in the aircraft where if you stuck it on a pin it would be balanced perfectly.  

In SF, it's a reference point to which the cockpit ties itself through the aforementioned Position entry, and also should be the point to which the visual exterior, the skin, ties itself.

So what you are saying is that by moving the CG point, not only are you moving the aircraft into perfect balance on the pin, you are also moving the cockpit position. But shouldn't that also be moving the skin too, since that is also tied to the CG reference? If so, the view out of the cockpit would not change, because the skin would move too. 

But you have proved that to be untrue. The skin is not tied to the CG but must have another reference point. This is good news. Because if you do alter the CG to get the aircraft in balance, the only compensation you have to make is to shift the cockpit back to where it should be in relation to the skin, the visual exterior. And since we have both admitted that we adjust the cockpit position a lot to get what we think is a better fit, it's no biggie.

Thanks for sticking with this. Much appreciated.

 

[bazillius 1,258]

5 hours ago, alexis99 said:

Yes, I admit that I almost always change the cockpit position

 

As to me I almost always change these settings. This is because the missile hit marker is usually either above or below the missile's actual explosion point.

 

ALL NUMBERS JUSY EXAMPLE!!!! Not correct value.

to work for lead computing mode.

in DATA ini

setting ironsight

[FlightControl]
GunBoresightAngle=-2
RocketBoresightAngle=-3

a smaller number is lower than the sight, for example -7 is lower than -3 but it is the missiles themselves that will also move behind the sight. how to fix the sight separately from missiles, see below

 

for AI

Rockets

[RocketAttackAI]
AimPitchOffset=-3.3

Gun
[StrafeAI]
AimPitchOffset=-1.6

less number of undershoots more number of overshoots -3 will cause the missiles to explode closer than -1 and +1 may even overshoot the target.

 

And this is in Avionics ini LESS NUMBER LOWER SIGHT if the missiles fall below the sight, reduce the number. -0.7 is lower than -0.2

[HUD]
HUDMaterial=HUDMaterial
HUDColor=0.0,1.0,0.0,0.7
BoresightOffset=0.0,0.0
ViewportTopLeft=-0.125,-0.155
ViewportBottomRight=0.125,0.135
GunBoresightAngle=0.0
RocketBoresightAngle=-2

......

 

Without computing ironsight

[CockpitSeat001]
....
ViewAngles=0.0,-0.2,0.0

Less number of sight together with the cockpit tilts lower more sight higher

 

Edited January 6, 2023 by bazillius

[bazillius 1,258]

2 hours ago, alexis99 said:

Well that's fascinating. 

The CG is nominally the point in the aircraft........

The skin is not tied to the CG but must have another reference point. ...... CG to get the aircraft in balance, t

 

No No... The aircraft model is one object, the cockpit is another object. They do not intersect in any way in the flight model. As for the aircraft's center of gravity. You set the center of gravity in the aircraft model and it is included in the LOD file. It is set by the person who makes the model itself. in the polygons. Often, the aircraft is made by a team of 3 or more people. The flight model is made by another person. Well, for example. He takes the number purely guided by some kind of internal sensations, often from numbers generated in his mind under beer. He writes a flight model and sees if the plane flies well or not. The texture is drawn by a third person. Then someone finds the mistakes. Rewrites all scripts for himself. After someone repacks and uploads again. This is why planes often behave unpredictably. Everything is configured individually. Often a situation arises that it is impossible to fix the model only by digging ini files, and the person who made the model in polygons has already died several centuries ago. So we have what we have

[bazillius 1,258]

For example iL-38 here. Center of gravity is set faaaaaar from its real position. And you have no any chance to fix it in ini. so you fly as is. This is me describing the center of gravity from the polygon model maker's point of view. Maybe you have some other center of gravity meaning. 

the texture is also not tied to the center of gravity in any way. The texture coordinates are set by the person who makes the model in polygons. These coordinates are firmly nailed into the LOD file, fastened with screws and glued with molecular superglue. They cannot be changed by editing ini files. There is, however, a trick with decals, but that's another story.

[Wrench 9,801]

the world center (0,0,0) of model is NOT the CG for the flight model.They can differ by a large number (several meters at times) I'm sure there are times when the DO coincide, but that's probably rare as hen's teeth.

[alexis99 124]

World center of model. Now we're talking. So the skin of the model is tied to the skeleton of the model by the World center? So if you move the CG, nothing changes. But since the cockpit is not tied to the World Center (Big mistake) but tied to the CG, it moves if the CG moves. Like I say, no biggie if you know it happens.

Back in Microsoft's Pacific Fighter days we had to reverse Engineer the aircraft model entries to figure out what they did. One really curious one was a figure that behaved like CG. You moved it one way and the nose went up, you moved it the other and the nose went down. Trouble was it worked the wrong direction. Move it forward and the nose went down when it should have come up. We finally realised it was a bag of sand. Move it forward and the nose went down. I think they call it ballast. Fixed a lot of aircraft with that bag of sand.

Anyway, as regards the RollingRadius: If I increase the RollingRadius, the visual model shows the nose wheel off the ground. Floating in the air, actually. If I decrease the rolling radius, the visual model shows the nose wheel buried in the tarmac. But if I adjust the rolling radius correctly, the wheel stands on the tarmac. But in each case, the size of the RollingRadius has no bearing on the visual size of the wheel, nor does it stop the gear stowing in the aircraft. So maybe that's what it's there for, to help get your wheels on the tarmac.

In fact it reminds me a bit of Wrench's Banshee. He said he just couldn't get it to trap on a straight-deck1950s carrier.  I used to trap by nosing up as I cut power and forcing the hook lower into the deck. Then someone came along and increased the length of the hook, by quite a distance, in the data.ini. It made no difference to what the hook looked like in the visual model, but it now dug deep enough in the deck to catch a wire.

[Wrench 9,801]

gimmie them numbers for the Banshee!!!!   That has bothered me for like, forever!!! Needs to fixes!!!

the "collison mesh" for the tailhook is a vitural item. That's how we made aircraft, without hooks land successfully on carriers.

[alexis99 124]

Sorry man, I never bothered to write down those numbers. Since I had developed a good landing technique, which is pretty close to what the Pilot's flight manual shows, I could trap anyway, so I never followed it up. I believe the guy who fixed it, posted it in the Banshee download section. I'll havea look.