gospadin

Awesome, I'm glad you're on the right track. Fundamentally, it breaks down to this (from what I can tell): 1) accelerate for takeoff (full AB) 2) apply light rudder with pedals 3) plane yaws (~1-2 degrees/second was my goal) 4) center rudder by centering pedals Once #4 occurs and the rudder is centered, the yaw of the airplane should cease. Any yaw moment built up from #3 should be almost instantly halted by the straight rudder. The tail on this plane is HUGE. Instead, I see that even after the rudder is centered, the plane continues to yaw for several seconds, causing swerving to start. I can confirm rudder is centered by watching the animation of the rudder. Anyway, i'm psyched you could reproduce it. Thanks for the module!

It's not just the compiled lua. Fundamentally, to lock and launch a missile you need support from the systems code. Their code (like the real jet) isn't setup to trigger a missile launch from the center pylon, so there's really no possibility to do that without RAZBAM's assistance.

local birth = LockOn_Options.init_conditions.birth_place Not sure it meets your criteria, but technically it's not "from the cockpit" per say. Test for "GROUND_HOT" "AIR_HOT" or "GROUND_COLD" --gos

Can someone explain why the plane continues to turn on the ground after the rudder has been centered? I don't understand the physics behind that.

I'd recommend you create a single thread in the Gazelle livery forum, and update your thread there as you make each update. That will bump it to the top, and that way your updates are all in one place.

Agreed. if nothing else you should be able to modify the knobs and listen, even in easy comms mode.

sweet

I agree with what you feel. There's definitely some physics oddities.

Depends on where the Helo CG is.

the purpose of a beta test is to find the bugs and report them, so RAZBAM can fix them if we don't report them, they'll never get fixed

have you posted this in the M-2000C bug section?

Grey like the tail? Or russian blue?

Count me i for sure. I fly all helos, order of preference would be Mi-8 > Huey > Gazelle.

I'm genuinely surprised the current behaviors were confirmed. They would appear to defy the basic physics of helicopter flight, specifically attempts to reach an equilibrium with various amounts of cyclic input.

What's the name of the autopilot that's trying to kill you every time Yevgeni takes his eyes off the controls?

FYI, sensor_data.getBarometricAltitude() always returns 0 when I ground start in NTTR. If I air-start, my altitude is correctly returned from my sensors. --gos

This is what I find odd (been thinking of how to phrase it for a while...) and this is my understanding of what "should" happen: When I apply cyclic in any direction, what the controls should be doing is increasing the effective lifting force on the opposite side of the rotor disc. (ignore precession for now). If I push forward, the swashplate tilts causing the blades in the rear (yes, 90 degrees before the rear with precession) of the disc to increase pitch, to provide more lift on the rear of the disc relative to the front. Assuming I start from a hover, where the lifting force is balanced with the force of gravity through the CG, the above increase in lift at the rear of the disc will apply torque to the body of the helicopter into a nose-down attitude through the rotor mast. This torque will start to tilt the body of the helicopter nose-down, until the movement of the CG to the aft relative to the input vector cancels the asymmetric lifting force, and the body stabilizes at a new nose-down attitude. If I apply more cyclic in the same direction, the force increases, and the balance point of the helicopter's CG relative to the rotor mast should be further away. However, this balance point should still exist. Note that as I pitch over further, I should have to add collective (increase the lift of the entire disc) to stay at the same altitude, because the vertical component of my lift vector is being moved to the horizontal component. For most any input (prior to achieving translational lift), I should have a pretty clear relationship between cyclic input and rotor disc pitch. So I guess the question is, does the gazelle have a FBW system that interprets control input to actually move the mechanical linkages? Is the CG too high (thus making the balance point very hard to find)? On 1.5.3, flying at about 2000m of altitude with 2/3 fuel and only two HOT missiles, the helo was incredibly unstable in the pitch axis, constantly rolling forward and back seemingly independent of my inputs. What I feel in the Gazelle is that a specific amount of cyclic input does NOT correspond to a consistent amount of swashplate movement. I don't know how they model their blade sections and the forces on each piece, but yea, definitely wierd. --gos btw, if my understanding of helicopter physics is wrong, please correct me. My IRL flight experience is limited to fixed wing aircraft.

You can use those oscillations too: [ame] [/ame]

Might want to make a thread in the SA342 skin folder. Nice work though uboats!

I don't believe that's new.

If that's the case, there must be some kind of rotor clutch we can disengage, though shouldn't it auto-disengage below 29,000 RPM?

Yup, I have 3 copies and typically create a 4th on patch day. Is the manifest something that only ED/official partners can generate?

Oh yea, it works just fine. Sith: My productive "feature request" is to allow server admins to have a way to decide which mods are mandated for their servers, and which mods are not. I should be able to allow the missile mod, and allow new aircraft, without allowing changes in visibility if I choose. Some kind of specification language: default: unmodified modified: file c - hash: 098abd4356da0 unrestricted: directory Mods/aircraft/<new> or similar...

I agree you're correct. I've never heard of an aircraft where pushing "forward" on the trim hat will move your nose up.