Previous Thread
Next Thread
Print Thread
Rate This Thread
Hop To
Page 3 of 3 1 2 3
#4546151 - 11/26/20 04:03 PM Re: FLIGHT MODEL or where is it ? [Re: Haukka81]  
Joined: Mar 2010
Posts: 763
BANITA Offline
Member
BANITA  Offline
Member

Joined: Mar 2010
Posts: 763
do something for this simulator or quit.complain can any loser. eot

#4546167 - 11/26/20 06:10 PM Re: FLIGHT MODEL or where is it ? [Re: Haukka81]  
Joined: Dec 2010
Posts: 1,738
messyhead Offline
messyhead  Offline

Member

Joined: Dec 2010
Posts: 1,738
Let's keep it civil people.

#4546261 - 11/27/20 12:46 PM Re: FLIGHT MODEL or where is it ? [Re: Haukka81]  
Joined: Dec 2009
Posts: 643
AndyB Offline
Member
AndyB  Offline
Member

Joined: Dec 2009
Posts: 643
Ayrshire, Scotland
Hi Reticuli,

I understand that you have an opinion on the quality of things in EECH. As an individual you have that right. We all have that same right.

I for one want to say that I don't find the stuff in EECH "crap" and in fact It really surprises me what the modders here have gotten out of an antiquated and discarded game. Yes, there are niggly issues with it but nothing I'd call major.

If you don't like the game then don't play it - it's that simple. If you bought the game and feel you've were miss-lead then complain to the seller.

If you feel that things in the game could be improved then chip in and have a try at fixing it. There is a wishlist somewhere on the forum. Why not put CONSTRUCTIVE comments on there. That's what I did.

If you just want to argue with someone then go elsewhere because that's not what this forum is about.

Have a lovely day and stay safe in these uncertain times,

Andy


Andy's simpit: http://www.simpit.me.uk
#4546318 - 11/27/20 09:25 PM Re: FLIGHT MODEL or where is it ? [Re: Haukka81]  
Joined: Apr 2018
Posts: 289
Javelin Offline
Member
Javelin  Offline
Member

Joined: Apr 2018
Posts: 289
Idaho Falls, Idaho USA
Hi Guys. One of the problems is you're using version 1.15, not the latest version 1.16.2. I did some work last year on the physics engine which is integrated into the 1.16.2 release. And I'm not just a modder, I'm also a senior mechanical engineer. I do know physics. I fixed the auto hover and ground-following controls as well as the basic physics using proper feed back control loops. The EECH engine isn't perfect, but it's a darn sight better than it used to be. Maybe a simple upgrade would cure some of your issues.
Javelin

#4550703 - 01/04/21 09:14 PM Re: FLIGHT MODEL or where is it ? [Re: Haukka81]  
Joined: Jun 2005
Posts: 2,014
Reticuli Online tunes
Member
Reticuli  Online Tunes
Member

Joined: Jun 2005
Posts: 2,014
Dayton, OH, USA
I've been more constructive talking about the FMs than all of you combined. You guys have literally said zero constructive and beneficial on the topic at all other than 'it doesn't work right' or pretending everything is fine. Then earlier in one of these threads biting someone's head off when they were actually being polite. Some of you deserve some actual rudeness.

One of the problems with the flight model is a lack of yaw damper clearly. The sim is trying to do it using the inherent drag on the tail. That's not how aircraft yaw works. In a hover you ought to get at least a full rotation after releasing max yaw without a damper. The tail forward flight drag setting in the ini is also very weird. Did any version of the alternative pseudo real advanced flight model ever NOT have anemic yaw on the Ka-50/52? With half yaw authority through PPJoy/GlovePIE and some nonlinearity stuff both in the script and in EECH optionally, and also sometimes optionally just assigning the pedals direct in EECH options when I need full authority, the hokums are at least useable in FM 0 & 1. FM 2 also seems to be mostly coded into either the sim or the GWUT as the dyn files do nothing to it and I think the only ini line that did anything to improve it (or change it for that matter) was slightly increasing main rotor lift. Any explanation of the GWUT categories?

BTW, THE TRANSLATIONAL LIFT SETTING IS REVERSED WHEN FM 2 IS IN USE. ETL and ground effect are way too anemic on it, but people with ETL On in the options with even less lift... that's the explanation.

In order to get the proper Apache D service ceiling on the non-alternative FMs you need to put the ini air density setting at 3.0 with GWUT1.6.1.

I'm using PPJoy virtual joystick as an intermediary between my HOTAS and EECH, and assigning the virtual joystick in the sim and ini. Then I use GlovePIE running a script as a programming intermediary to roughly and 'dummly' (it doesn't know the sim aircraft's attitude) do auto trimming, as well as limit the ranges of auto trimming and limit the range available for yaw, to add yaw trim, etc.

Here is my latest GlovePIE EECH script:

var.nlzrots = sign(Joystick1.zrot) //Nonlinear pedals. Can be combined with sim nonlinear setting.
var.nlzrotm = abs(Joystick1.zrot)^(1.3) //Usually 1.3 but 1 will make it linear.
var.nlzrot = var.nlzrotm * var.nlzrots

if var.nlzrot = 0 then { //Better pedal fix.
var.pedalfix = -0.999999
else
var.pedalfix = var.nlzrot // pedals
}

var.dial = smooth(deadzone(joystick2.dial, 0.008), 10)

if shift+t then begin { //Auto trim clear
var.xhold = 0
var.yhold = 0
PPJoy1.Analog0 = var.xhold + deadzone(joystick2.x, 0.075)
PPJoy1.Analog1 = var.yhold + deadzone(joystick2.y, 0.075)
PPJoy1.Analog5 = var.pedalfix / 2 - var.dial /2 //For pedals. Usually bypassed unless FM 0 or 1 with coaxials.

else

var.xhold = EnsureRange(deadzone(joystick2.x, 0.075) / 30 + var.xhold, -.4, .4) //Roll auto trimming. Over -.5/.5 causes continuous roll, but -.75/.75 is nicely responsive.
PPJoy1.Analog0 = var.xhold + deadzone(joystick2.x, 0.075) //Roll
var.yhold = EnsureRange(deadzone(joystick2.y, 0.075)/ 30 + var.yhold, -.75, .75) //Pitch auto trimming
PPJoy1.Analog1 = var.yhold + deadzone(joystick2.y, 0.075) //Pitch
PPJoy1.Analog2 = Joystick2.z //Collective that I'm currently bypassing and going direct
PPJoy1.Analog5 = var.pedalfix / 2 - var.dial /2 //For pedals. Dividers 1 or 2 for non-hokums, Higher for hokum B. Can be bypassed and assign pedals directly in sim for FM 2.


}

var.bank = PPJoy1.Analog0
var.pitch = PPJoy1.Analog1
var.collective = PPJoy1.Analog2
var.GPyaw = PPJoy1.Analog5
var.rawpedals = Joystick1.zrot
var.throttle2 = Joystick2.zrot
var.bottomwheel = Joystick2.slider
var.rawtopdial = Joystick2.dial

Last edited by Reticuli; 01/06/21 06:18 PM.

The term "necroposting" was invented by a person with no social memory beyond a year. People with a similar hangup are those o.k. with the internet being transient vapor.

http://www.openfuelstandard.org/2011/12/methanol-wins-open-wager.html

Saitek X65 and X52, Glide, Winx3D, and GlovePIE Profiles http://library.avsim.net/search.php?SearchTerm=reticuli&CatID=miscmisc

http://library.avsim.net/register.php

X52 + Silicone Grease = JOY stick
#4550766 - 01/05/21 11:01 AM Re: FLIGHT MODEL or where is it ? [Re: Haukka81]  
Joined: Dec 2010
Posts: 1,738
messyhead Offline
messyhead  Offline

Member

Joined: Dec 2010
Posts: 1,738
Thanks for you comments and investigation on the flight model. I'm sure if someone decides to work on it, they can use your comments for improvements.

#4550861 - 01/05/21 08:35 PM Re: FLIGHT MODEL or where is it ? [Re: Haukka81]  
Joined: Jun 2005
Posts: 2,014
Reticuli Online tunes
Member
Reticuli  Online Tunes
Member

Joined: Jun 2005
Posts: 2,014
Dayton, OH, USA
Besides the lack of yaw damper, the use of 'rudder acceleration' as an adjustable parameter is completely wrong and useless, especially as some easily-accessible ini parameter. All that does is change how long it takes to reach maximum yaw rate given a certain drag setting and continuous pedal input, and of course you have that yaw drag setting doubling equally wrongly as a yaw damper. The yaw drag actually increases the Hokum maximum yaw rate, too, so you can imagine the nightmare of attempting to balance maximum yaw rate on the Hokum, non-Hokums, a general universal proper yaw acceleration, yaw damper effect or not, and yaw drag or not. It's a no win situation left to itself. The closest you can get to an actual proper helicopter yaw for all the helos in EECH, regardless of whether you want digital FBW or old style, is to limit maximum available pedal input with a divider that you adjust for each helo type, which isn't the worst idea... heck, I could assign a rotary just for that purpose of magnitude authority, and then to basically have something like GlovePIE (which I'm already using for the former) pump the yaw like you'd pump car brakes so that a continuous pedal amount just initially accelerates to a given modest yaw rate and then stays there instead of ramping up forever. In fact, I had an errant script in some other sim the other day that was doing just that, so I might be able to duplicate that if I kept a copy of the glitchy script and intentionally move the effect over to the EECH script.

That said, after working on this for the last few days, last night I made a breakthrough achieving something resembling a faithful digital FBW helicopter when using GWUT 1.16.1. Granted, this is not a real aerodynamics simulation of a helicopter flying through the air and then an actual AFCS program acting as an intermediary between the pilot and the aircraft sensing the aircraft performance and sensors or pilot inputs. However, between this weird canned thing EECH does and the PPJoy/GlovePIE stuff, an approximation seems to be congealing of some of the former's results. The yaw drag and yaw acceleration sections, however, are obviously a work in progress with no easy answer when just adjusting the ini. You can do 30 for drag and 0.2 for accel, or 2 and 2, or 0.3 and 0.3, but when this all 'clicked' I just had them at 1.0 and 1.0 when I felt the butterflies happen and knew the rest of the parameters were right, so the yaw mitigation I just did through GlovePIE combined with nonlinear settings both there and in EECH on a helo-to-helo basis. I also put my Head G-Forces and Cockpit Vibration settings at 1.5, though the Head G-Forces effect responds too slowly & adversely affects the ability to see HUDs. Cockpit Vibrations also do not occur during strong sudden collective/cyclic changes or when passing the ETL threshold like they should, but at least vibrations coincide with bank angle and IAS. Head G-Forces thing further incentivizes gentle maneuvering and use of the gauges or MFDs for flight indicators.

I haven't tried the GWUTs other than 1.16.1 much lately and when I did it was prior to discovering the translational lift setting bug for FM 2, which invalidates most of my efforts back then. So I guess make sure GWUT1.16.1 is listed in the EECH.ini. Yes, I'm using the latest 1.16.2 test patch/exe, though.

Lets call this Reticuli's AFCS Mimic EECH.ini FM Tweaks for use with GWUT1.16.1:

[Dynamics]
flight_model=0 # 0 is the default flight model with coordinated turning that the dyn and ini setting affect. 1 is werewolf's adjustments of this default FM which is similar to FM 0 but without some yaw aerodynamic streamlining or any auto coordinated turning, 2 - alternative pseudoreal FM (def = 2) has IAS affecting RPM slightly with rotor disengaged and RPM supposedly affects lift with rotor engaged, though RPM does not fluctuate enough with fast collective changes with rotor engaged and increasing IAS takes too long to increase RPM with rotor disengaged. Taxiing does is not safe with FM 2 due to strange yaw and roll moments possibly due to FM interaction with suspension mods. FM 2 is not affected by any dyn files or most ini lines. FM 2 adversely lowered both translational lift and ground effect, the latter of which was prior to these ini changes already too low in the sim on FM 0 and 1. FM 0 and 1 Hokum B max yaw is always too high, while FM 2's is too low. FM 2 also reverses the EECH Translational Lift menu option such that on is off, so if using FM 2 you must set that to off to get any ETL at all. FM 2 has more realistic auto rotation. FM 0 and 1 are slightly too lite and high thrust. FM 2 is too heavy and low thrust. Hence differences in dmrl. FM 0 and 2 turn coordination mixes in yaw when banking at too low a speed still. FM 0 (optionally, obviously, you can use FM 1 with these settings if you don't want turn coordination or yaw streamlining, but it's a mystery how FM 2 is affected by these settings if at all other than dmrl and dyad) with Reticuli's 1-5-2021 ini values in combination with PPJoy and GlovePIE causes EECH to most closely mimic a FBW helicopter like especially the Comanche and also somewhat like the Zulu Viper, Apache D, or Hokum similar to the work Penn State's rotorcraft research lab and the Army ADOCs program have done.
enginerealism=1 # realistic engine workload simulation model (0 = off, 1 = on) (def = 1)
enginestartup=0 # manual engine start up, off by default (0 = off, 1 = on) (def = 0)
drbs=1.0 # retreating blade stall, floating point scaling factor for RBS effect (default = 1.0). Most helos should have this happening sooner and benefit from 1.1 or even 1.2, but some like the Zulu Viper are the reverse, so might as well just leave it at the default.
drv=1.0 # rudder value, scaling factor for drag on tail rotation (Default = 1.0.) Undesirable parameter to be adjusting since this must work as the tail drag, max Hokum B yaw rate, and as an inappropriate yaw damper that should be separate from drag. Very high like 30 is possible with very low fractional dra below. Even higher drv produces counter effects when banking opposite during yaw.
dra=1.0 # rudder acceleration, scaling factor for tail rotation acceleration (default = 0.8). Undesirable value to be adjusting, as maximum yaw rate would be more useful. If set low enough and the tail drag high enough, non-Hokums will not continually ramp up yaw rate, but then the Hokum with such a high tail drag gets further insane max yaw rates.
drd=0.1 # main rotor drag, scaling factor for drag caused by main rotor (default = 1.0). It's uncertain if this affects parallel aerodynamic streamlining drag of the rotor disc, but it is definitely perpendicular drag that affects angular rotational rates for a given X and Y input and at higher settings causes the helicopter to bleed speed with X and Y axis maneuvering. Ground effect may noticeably increase at 0.1 over higher values, and since ground effect, aerodynamic streamlining, and aerobatic capabilities are problematic in EECH, this value at 0.1 seems essential. Joystick sensitivity on your end may need adjustment to compensate for this increased pitch and roll authority.
dmrl=0.9 # main rotor lift, scaling factor for lift of main rotor (default = 1.0). With FM 0 or 1, dmrl of 0.9 is most accurate. With FM 2, dmrl of 1.1 is most accurate.
dtrd=10.0 # tail rotor drag, scaling factor for drag caused by tail in forward flight (default = 1.0). It is difficult to say exactly how this is affecting flight, but lower than 10.0 seems to have an adverse effect on aerobatics, and at 10.0 something magical seemed to happen both with aerobatics and in just the normal flight envelope maneuvering NOE with collective and banking flying between buildings seat-of-the-pants. The ability to do a proper forward speed landing on a runway and taxi in FM 0 with all the above (whatever your chosen yaw setting and other mitigation methods) made it apparent something had snapped into place with these non-yaw ini values.
dyal=2.5 # yaw altitude loss (default = 5.0). This is the only yaw ini value I have some confidence about. If you have crosscoupling off, you might want a value of 5.0. This is perhaps excessive for AFCS aircraft and with crosscoupling 2.5 feels better and is less prone to crashing with large pedal inputs while still having a noticeable affect. YMMV.
dyad=3.0 # global air density modifier (0.5 - increase dynamics ceiling, 2.0 - decrease) (default = 1.0) A value of about 3.0 appears required with FM 0 to get an Apache D up to just over 20,000ft but not much higher at 100kts for a realistic ceiling.

Last edited by Reticuli; 01/08/21 02:33 AM.

The term "necroposting" was invented by a person with no social memory beyond a year. People with a similar hangup are those o.k. with the internet being transient vapor.

http://www.openfuelstandard.org/2011/12/methanol-wins-open-wager.html

Saitek X65 and X52, Glide, Winx3D, and GlovePIE Profiles http://library.avsim.net/search.php?SearchTerm=reticuli&CatID=miscmisc

http://library.avsim.net/register.php

X52 + Silicone Grease = JOY stick
#4550862 - 01/05/21 08:55 PM Re: FLIGHT MODEL or where is it ? [Re: Haukka81]  
Joined: Nov 2020
Posts: 87
SippyCup Offline
Junior Member
SippyCup  Offline
Junior Member

Joined: Nov 2020
Posts: 87
Perhaps try the psychological approach: Play KA-52 Team Alligator for ~12 seconds and you'll feel much better about everything else.

#4550869 - 01/05/21 09:34 PM Re: FLIGHT MODEL or where is it ? [Re: Haukka81]  
Joined: Jun 2005
Posts: 2,014
Reticuli Online tunes
Member
Reticuli  Online Tunes
Member

Joined: Jun 2005
Posts: 2,014
Dayton, OH, USA
Hah hah. I am actually a bit of a Melanie Martinez fan, myself. The music bar/lounge I used to DJ at introduced me to it. Not sure if your name is a reference to that.

I think Team Alligator is probably one of 3 or 4 combat helo sims I haven't used. I'm well aware of the dearth of good flight models with historic helo sims, but let's look at the highlights of flight performance fidelity:

https://forums.x-plane.org/index.php?/files/file/42145-comanche-enhanced-apache-v10/

https://forums.x-plane.org/index.ph...r/&do=findComment&comment=324740

I also have a bunch of other X-Plane and FSX helos heavily tweaked into AFCS goodness, including a passable Blackshark, Blackhawk, Gazelle, Huey, and JetRanger 206 that all just basically require manual trimming of the roll axis. In fact, the KA-50 requires you to go into the X-Plane joystick sensitivity and cut the yaw authority way down, so there's precedent for at least the extreme yaw authority, if not the ramp up and other yaw parameter issues. Other than the fact you have to bump some slight opposite deflection when you roll inverted in EECH due to the goofy auto wings leveling that's always in not only Y but X, I think what I have now in EECH with these ini tweaks and GlovePIE is now arguably getting quite a bit of truthiness for a digital FBW helo sim, if I may be so bold. And we get to blow stuff up and use stealth. I think this combined aggregate flight modeling & pilatage is now at least rivaling Longbow Anthology, and I think we're very close to getting RPM overpitching effects in EECH somehow... actually think I did that very crudely with a GlovePIE script at a one time based on the speed of collective changes if I can find it. There is, however, a fascinating X-Plane Bell 222 auto trim project going on right now at Cowan Simulations. I think I've already tweaked someone's Airwolf, though.

Edit:

BTW, for collective nonlinearity I'm using these settings, but I'm sure that's very dependent on your individual throttle model:

nonlinear-collective-zone1=0.4 # non-linear control value for throttle (n = % throttle position joystick to represents 60% collective) (10% = 0.1) (0.0 = off (linear control), 1.0 = max) (def = 0.3)

nonlinear-collective-zone2=1.0 # non-linear control value for throttle (n = % throttle position joystick to represents 100% collective) (10% = 0.1) (0.0 = off (linear control), 1.2 = max) (def = 0.7)

nonlinear-collective-percentage-at-zone1=50.0 # collective percentage at zone1. Valid values are in range from 1.0 to 99.0, default is 60.0.

Edit:

What I think drd at 0.1 might be doing at low altitude is causing the rotor disc to deviate upward away from the ground effect, which, while more likely to occur with lighter helicopters in real life, is a wonderful effect to be having in EECH at all, and is evidence, I believe, of that parameter being responsible to some degree for an aerodynamic streamlining effect of the main rotor disc. It also is a larger effect with the turbulence of landing gear.

New GlovePIE script with yaw range knob. I'm still working on a pumping yaw script that does more pumping during hovering and less when laterally moving, but it's proving to be slightly more buggy than I expected even though it mostly seems to work.


var.yawrange = (smooth(deadzone(joystick2.slider, 0.008), 10) + 2 ) ^ 2 // Bottom throttle thumb rotary assigned as a yaw range.
var.nlzrots = sign(Joystick1.zrot) //Nonlinear pedals.
var.nlzrotm = abs(Joystick1.zrot)^(1.3) //Usually 1.3 but 1 will make it linear.
var.nlzrot = var.nlzrotm * var.nlzrots
if var.nlzrot = 0 then { //Better pedal fix.
var.pedalfix = -0.999999
else
var.pedalfix = var.nlzrot // pedals
}
var.dial = smooth(deadzone(joystick2.dial, 0.008), 10)
if shift+t then begin { //Auto trim clear
var.xhold = 0
var.yhold = 0
PPJoy1.Analog0 = var.xhold + deadzone(joystick2.x, 0.075)
PPJoy1.Analog1 = var.yhold + deadzone(joystick2.y, 0.075)
PPJoy1.Analog5 = (var.pedalfix / 1 - var.dial / 2 ) / var.yawrange //For pedals. Usually bypassed unless FM 0 or 1 with coaxials.
else
var.xhold = EnsureRange(deadzone(joystick2.x, 0.075) / 30 + var.xhold, -.4, .4) //Roll auto trimming. Over -.5/.5 causes continuous roll, but -.75/.75 is nicely responsive.
PPJoy1.Analog0 = var.xhold + deadzone(joystick2.x, 0.075) //Roll
var.yhold = EnsureRange(deadzone(joystick2.y, 0.075)/ 30 + var.yhold, -.75, .75) //Pitch auto trimming
PPJoy1.Analog1 = var.yhold + deadzone(joystick2.y, 0.075) //Pitch
PPJoy1.Analog2 = Joystick2.z //Collective that I'm currently bypassing and going direct
PPJoy1.Analog5 = (var.pedalfix / 1 - var.dial / 2 ) / var.yawrange //For pedals. Usually bypassed unless FM 0 or 1 with coaxials. Now with yawrange on thumb dial.
}
var.bank = PPJoy1.Analog0
var.pitch = PPJoy1.Analog1
var.collective = PPJoy1.Analog2
var.GPyaw = PPJoy1.Analog5
var.rawpedals = Joystick1.zrot
var.throttle2 = Joystick2.zrot
var.bottomwheel = Joystick2.slider
var.rawtopdial = Joystick2.dial

Edit:

Maybe preferring a little more ease of authority on the pitch than on the roll, at least on the Apache D, which is quite a bit different than not only the classic fixed-wing aircraft 1:2:4 ratio, but even how I used to run joysticks with EECH. Many of the other helos are feeling pretty close to 1:1.

Last edited by Reticuli; 01/11/21 04:42 PM.

The term "necroposting" was invented by a person with no social memory beyond a year. People with a similar hangup are those o.k. with the internet being transient vapor.

http://www.openfuelstandard.org/2011/12/methanol-wins-open-wager.html

Saitek X65 and X52, Glide, Winx3D, and GlovePIE Profiles http://library.avsim.net/search.php?SearchTerm=reticuli&CatID=miscmisc

http://library.avsim.net/register.php

X52 + Silicone Grease = JOY stick
#4551698 - 01/10/21 10:11 PM Re: FLIGHT MODEL or where is it ? [Re: Haukka81]  
Joined: Jun 2005
Posts: 2,014
Reticuli Online tunes
Member
Reticuli  Online Tunes
Member

Joined: Jun 2005
Posts: 2,014
Dayton, OH, USA
You must use FM 2 to have crosscoupling OFF. FM 0 & 1 have an issue with yaw and lift in forward flight with CC OFF under the sim's Options Menu in Dynamics. I always have it on and use FM 0 now with the above tweaks, but if you use FM 2 obviously coaxials are problematic with their weak yaw in a hover right now. So if you want to do all the pedal mixing yourself with your feet old-school, then use FM 2 and don't plan on flying coaxials expecting much yaw rate.

***

I've been testing GWUT 1.16.2 with EECH v1.16.2 and so far have not noticed much difference in the FMs over GWUT 1.16.1. May be fine to use the newer GWUT after all.

***

More organized recommended to-do list posted at-request

FM Stuff:

1. Make my ini Dynamics tweaks the default... including the comments, like dmrl at 0.9 for FM0/1 and 1.1 for FM2. Obviously when some of the below stuff is done, some of the explanatory text will go.

2. Fix Translational Lift option when FM2 is in use. Currently, on is off and off is on. Some people may choose to use FM2 with its bizarrely-weak Ground effect and Translational Lift even when it’s properly on, so might as well get that option setting working correctly. It’s also possible that in the long run this model might have more potential, such as with more stable yaw pedal performance, but only time will tell. (Edit: the ETL coding for FM 2 is very broken, as it's actually altering lift while in a hover)

3. Muted yaw on coaxials in FM2 needs fixing next. Makes them and much of FM 2 basically unusable right now.

4. Fix rotor clutch/brake disengaging when you jump into an aircraft with it already on. Autopilot also sometimes is off. Falling out of the sky abruptly could be categorized as a FM problem.

5. Vibration from extreme cyclic and also on extreme coaxial yaw changes, so like from -1 to 1 of the roll axis in a split second would apply most vibration, and that same amount slower or a less amount just as fast would be less vibration induced briefly. Have it IAS-compensated, too, like the current banking angle vibration is, which is a good thing, by the way. Coning effects from just holding a bank causes some vibration, so don’t get rid of that. Edit: On the vibration, I forgot to add to the list the part about it needing to happen additionally moving in and out of ETL.

6. Main rotor damage from the more extreme #5 for longer lengths of time. Less length of time means less chance of damage. More extreme handling requires less time to cause damage. First instance causes some damage and main rotor oscillations, continued extreme handling after a few seconds of oscillations or another instance causes loss of main rotor. The damage and vibration threshold could lower when you are already damaged. Obviously the vibration and noise will be a warning this might occur before the first instance occurs.

7. Try to put RPM effects from FM2 into FM0/1, or at least make similar RPM response effects in FM0/1. The RPM effects in general need be greater even in FM2, so more sluggish RPM response and opposite effect even with very large and fast collective changes. Excessive RPM and eventually damage with rotor disengaged is already occurring with FM2. Rotor engaged effects are too slight right now, though. In general, RPM and lift needs to also increase sooner when you lower collective and nose down with rotor disengaged. During autorotation you manage RPM that way immediately, while currently there’s a lag for the first few seconds and you require a ridiculous amount of IAS and altitude loss to get the RPM to start increasing.

8. Add an axis in-sim for yaw scaling for people that don’t want to use PPJoy/GlovePIE. All the way to one end and you get normal full yaw available on the yaw axis, other end of axis and you get some fraction. Probably bringing the axis that’s been smoothed and added 2 then to the power of 1 is sufficient rather than a power of 2, which gives you a divider of 1 at minimum (the original axis), around 2 on the center of the axis, and a divider of 3 at max attenuation. A power of 2 for 1 of the axis itself plus 2 at max gives a divider of 9, which is excessive unless you’re doing crazy stuff with the ini yaw drag and acceleration Dynamics.

9. Yaw is too fast and ramping up on coaxials on FM0/1. The most extreme yaw rates in a hover are related to an acceleration or ramp up and increases dramatically after extended continuous pedal. It appears worse with higher altitude or collective. While yaw drag should not be mimicking yaw damping and yaw acceleration is really the wrong value to be adjusting, I don’t know how much of max yaw is dictated by the GWUT. A separate yaw damper parameter may be necessary. The only current damping reference in the source code is on wheel suspension.

10. In FM 0 and 2, auto coordinated turning mixes in too much yaw at low an IAS. Turn coordination needs to not occur until well into translational lift, and then only more slightly at low speed and to keep FPM centered during bank at higher speeds. 50-60kts is usually a good threshold. Right now on FM 0 and 2 it seems almost completely proportional to banking regardless of IAS or direction as if it's an inherent part of the roll physics independent of the aircraft's own yaw capability, making side slipping in a hover impossible without counter yaw, which is difficult to do predictably, as well as adding to yaw capability. So, for instance, on FM2 with coaxial helos, you clearly get more yaw by rolling than you do with the pedals. There should also be no turn coordination when going backward ever. Of course FM 1 doesn’t have a lack of ease of side slipping when in a hover...

11. FM 1 should really just be FM 0 without coordinated turns. The yaw streamlining when in forward flight is too weak right now to be remotely realistic in FM 1, though its current lack of coordinated turning is slightly useful considering the current ways it mixes in too soon in FM 0 and 2. Hypothetically, FM 1 could simply be removed completely if Auto Turn Coordination became an in-sim options setting like Translational Lift and Ground Effect are… assuming #10 can be done. In contrast, the only reason ETL, GE, and RBS are in-sim settings were so people could turn them off and see how deep the EECH flight model was. It is not easier to fly without ETL and GE, as should be glaringly obvious to anyone trying the current FM 2 with Translational Lift set to "ON" (actually off).

12. Zulu Cobra needs its max IAS and RBS threshold raised. Most other helos need it slightly lowered, but for the meantime I’d probably leave the others where they are.

13. Taxi yawing in FM 2 is not working right, as there seems to be weird force moments occurring, possibly related to the suspension mod interacting with the ‘alternative’ FM coding mod.

14. Ensure wind is part of IAS calculations when there is a headwind or tailwind. Not sure if it is.

15. G-forces head movement is too slow to move, especially on returning back to center.

15.1. Also, if G-forces are monitored on the aircraft, this would be useful for better affecting the sound of the rotors and vibration currently, as some of the ebbing of the sound is reminiscent of the rotors unloading at the top or beginning downward portion of a parabolic ascent, but the timing currently seems somewhat off.

15.2. Crosscoupling is momentarily off when disengaging autopilot.

15.3. There's still a bug where rolling in a, especially a Comanche, will cause a freeze in 1.16.2 while you're inverted.

15.4. Engine power (or I suppose collective pitch or lift calculations themselves) needs to be exponential or log, such that at 30% torque you're getting the equivalent of about 50 or 60% torque that we're currently getting without increasing the maximum available power. It shouldn't take so much torque to taxi (30% torque should be enough) or lift off with the combination of IGE & ETL (more than 30% torque but less than currently), but obviously we don't want to increase total max available lift or power beyond what we're currently getting with dmrl at 0.9 to 1.1 and the global drag at 3.0.

15.5. Hover hold with no altitude hold (where you manually control altitude) is causing collective, torque, or lift calculation issues (or maybe it's only including one engine) compared to 'stable' hover hold with altitude hold that agrees with full manual hovering.

15.6. Translational lift is still too weak in FM 0 & 1, though other values like global air density will have to be changed from 3.0 when it is fixed. Something like a fully loaded Hind should not be able to lift off without ETL, but ETL is too weak currently to provide enough benefit to fully compensate. Obviously FM 2 has ETL and ground lift even weaker than FM 0 & 1.

15.7. While it's too easy to get into VRS right now without tweaks, it's also too simple to get out of. Going to 120% torque should not get you out of a VRS if you still haven't gotten lateral movement, and you shouldn't be able to regain all cyclic authority until either you've at least reduced collective a little or already gotten out of the VRS somehow (wind, moved the cyclic in the direction opposite of the pedal required to keep a heading when adding power, etc). Going to 120% torque briefly is not the solution to VRS, in fact it should make it worse if that's all you do.

15.8. FM 0 & 1 have broken crosscoupling OFF behavior.

15.9. Nose pitch changes when in a stable hover hold and you switch FLIR on and off.

15.91. RBS should shift lower below Vne with added weight and higher G-forces.

15.92. Random oscillations and vibration when near and behind other aircraft, based on front aircraft's size (total weight as proxy).

16. Later on we can figure out a way to add my GlovePIE scripts into EECH so people have to do less setup. I will work on having three control modes where you double tap the trimmer button to change to each with a voice telling you the mode. First will be the current default pitch and roll wings level mode with manual trimmer. Second mode will be same as first but with auto trimming of pitch. Third will be full dynamic auto trim like the above posted scripts.

17. As for FM stuff off the top of my head, the final step before a complete rewrite of the FM code of EECH would be simply to find a way to stop the continuous roll that occurs past a certain roll angle. That way you could roll inverted, stop applying X axis, and it will stay. Right now, past about 0.40/-0.40 on X, you get this continuous roll. So when you are finally inverted, you have to deflect a bit back in the opposite direction to hold the attitude rather than just release stick pressure. This appears to be part of this artificial wings leveling it’s doing.

Non-FM stuff:

18. I would like a view mode that keeps the FPM in the center of the view as you maneuver.

19. Calling in artillery doesn’t seem to be working. Not sure if that’s actually a bug or just a misperception on my part.

20. AI helos landing on top of helos.

21. Carriers don’t seem to be protected by CAPs or the rest of their group ships very well.

22. The game’s low-level foot of its contrast curve or gamma seems off, like you’d need a pro-quality CRT or an OLED to see any detail in shadows. I don’t mean just at night, which by the way I turn down to 0.3 darkness usually in the ini to make the NVG necessary. The gamma just seems oddly skewed. I can sort of adjust for this with my monitor or with NVidia settings, but it might be worth checking out.

23. The ability to change the amount of dust or have the dust change depending on environment. Deserts should have the most, obviously, and are fine where they are, but most other environments have too much dustout effect. Maybe use the same flag as clouds not being in deserts to have them get the full dust out and everywhere else get 50% of that amount.

24. Add jettison stores. Ctrl + J. Useful for increasing lift after engine failure.

25. Previous/next target both cycling in the same direction bug is also present in 1.16.1, so might be quite old.

26. Escorts being assigned way too late.

27. Recon mission transmission allowance needs to be much further away from X. For that matter, any helo should be able to transmit recon data whenever you want to update the campaign map.

28. Jumping into a landed helo at a FARP to start a mission that you have to activate the rotor and its gear is retracted with ongoing multi systems failures.

29. Swap the payload menu Hellfire L and R designations back from their technical designations to the original designations (L for laser, R for radar) the game used that are still used on the HMD and MFDs.

30. New issue in 1.16.2 where the sound stops working until restarting EECH.

31. In some campaigns you irreparably become immortal, with infinite weapons and fuel, and must restart the campaign.

32. The horizon is too bright at night when it's not just before dawn or just after dusk.

33. Wingmen need to employ weapons using their longest-range weapon at standoff range when told to hold position and then are ordered to attack a target.

34. FLIR targets need to be saved.

35. All detected targets should be shared between your flight as if there is an automatic data link, at the very least for the heads-down situational display, which should be able to be utilized for at least targeting Hellfires and aiming an aircraft's own FLIR.

36. SAM engagement envelope should decrease probability of acquisition at very low altitudes and/or at low altitudes when you're directly in front of a hill or objects. Currently you can get shot down by radars meant for airborne targets even when you're landed and even when you're landed right in front of a building. The only radars that should be capable of discriminating such a landed target is a radar meant for ground targets.

37. Ground and object temperature values for FLIR and IR missile homing. Include burning objects and sun angle in IR homing.

38. Vikhrs sometimes just fire into the ground repeatedly even though a target is properly lased.

39. Comanche can damage its tail on ground contact too easily.

40. Besides the Zulu Cobra 'Viper' needing higher top speed, its gun should only be holding 750 rounds, not 1345.

41. Comanche radar mast is too short.

42. The same message should not be sent by one AI unit more than once in a row. If it's the same message that unit previously said, that comms should not be sent again, such as "Python 1 seeking firing position" over and over.

43. Flight path marker and horizon line on HMD does not adjust with changing HMD pitch.

44. Allow us to choose NVG color (green, orange, original different ones for sides, or grayscale) and IR mode.

45. Hind vertical speed needle disappearing.

46. Be nice to have a marker on the situational display of where your EO/FLIR system is currently locked.

47. Be nice if heading turn to EO/FLIR lock point wasn't just when in hover mode and was more yaw authority used.


***

The previously-mentioned ini Dynamics tweaks have repeatedly borne out to be the best I can get for FM0 even after repeatedly trying to deviate from them.

***

Current collective settings to mitigate some of the unrealistically-excessive deceleration capability at 0% torque and ease of getting into VRS (keeps the min 10% as previously) and unrealistic overly-gradual bottom of collective (you should get more pitch and torque at lower collective setting), and to allow the Saitek mil-power detent to be first stage of over-torque (this Zone2 setting may need tweaking based on throttle model). In this case I reach mil-power detent accidentally and back it off slightly. Allows full collective for temporary max torque. Combined with the GlovePIE script, the middle of collective becomes more nuanced. The EECH nonlinear collective code is not really nonlinear but rather only changes the min and max.

nonlinear-collective-zone1=0.4 # non-linear control value for throttle (n = % throttle position joystick to represents 60% collective) (10% = 0.1) (0.0 = off (linear control), 1.0 = max) (def = 0.3)
nonlinear-collective-zone2=0.9 # non-linear control value for throttle (n = % throttle position joystick to represents 100% collective) (10% = 0.1) (0.0 = off (linear control), 1.2 = max) (def = 0.7)
nonlinear-collective-percentage-at-zone1=50.0 # collective percentage at zone1. Valid values are in range from 1.0 to 99.0, default is 60.0.

***

Latest GlovePIE script for use with PPJoy. I have stopped dev on the pulsing yaw. I believe just leaving yaw divider as an axis assignment and putting it at 50% or slightly below (for US helos) is usually sufficient combined with some gentleness. This script also works for Comanche Gold, particularly the nonlinear collective for Vertical Stabilization, but I have many other scripts for that sim, too.


var.nlzs = sign(Joystick2.z) // Proper nonlinear collective that's very gradual around the center and more compressed/abrupt on the ends.
var.nlzm = abs(Joystick2.z)^(2.0)
var.nlz = var.nlzm * var.nlzs

var.yawrange = (smooth(deadzone(joystick2.slider, 0.008), 10) + 2 ) ^ 1 // Bottom throttle thumb rotary assigned as a yaw range divider.

var.nlzrots = sign(Joystick1.zrot) //Nonlinear pedals.
var.nlzrotm = abs(Joystick1.zrot)^(1.3) //Usually 1.3 but 1 will make it linear. Usually combined with sim's own nonlinear yaw setting.
var.nlzrot = var.nlzrotm * var.nlzrots

if var.nlzrot = 0 then { //Better pedal fix to prevent full left from being seen by GlovePIE as zero and center.
var.pedalfix = -0.999999
else
var.pedalfix = var.nlzrot // pedals
}

var.dial = smooth(deadzone(joystick2.dial, 0.008), 10)

if shift+t then begin { //Auto trim clear
var.xhold = 0
var.yhold = 0
PPJoy1.Analog0 = var.xhold + deadzone(joystick2.x, 0.075)
PPJoy1.Analog1 = var.yhold + deadzone(joystick2.y, 0.075)
PPJoy1.Analog5 = (var.pedalfix / 1 - var.dial / 2 ) / var.yawrange //For pedals. Usually bypassed unless FM 0 or 1 with coaxials.

else

var.xhold = EnsureRange(deadzone(joystick2.x, 0.075) / 30 + var.xhold, -.4, .4) //Roll auto trimming. Over -.5/.5 causes continuous roll, but -.75/.75 is nicely responsive.
PPJoy1.Analog0 = var.xhold + deadzone(joystick2.x, 0.075) //Roll
var.yhold = EnsureRange(deadzone(joystick2.y, 0.075)/ 30 + var.yhold, -.75, .75) //Pitch auto trimming
PPJoy1.Analog1 = var.yhold + deadzone(joystick2.y, 0.075) //Pitch
PPJoy1.Analog2 = var.nlz //Collective that I'm currently bypassing and going direct
PPJoy1.Analog5 = (var.pedalfix / 1 - var.dial / 2 ) / var.yawrange //For pedals. Usually bypassed unless FM 0 or 1 with coaxials. Now with yawrange on thumb dial.

}

var.bank = PPJoy1.Analog0
var.pitch = PPJoy1.Analog1
var.rawcollective = Joystick2.z
var.GPcollective = PPJoy1.Analog2
var.rawpedals = Joystick1.zrot
var.GPyaw = PPJoy1.Analog5
var.throttle2 = Joystick2.zrot
var.bottomwheel = Joystick2.slider
var.rawtopdial = Joystick2.dial

//These buttons below are not used in EECH, but do not appear harmful. For other sims.

PPJoy1.Digital0 = Joystick2.Button1
PPJoy1.Digital1 = Joystick2.Button2
PPJoy1.Digital2 = Joystick2.Button3
PPJoy1.Digital3 = Joystick2.Button4
PPJoy1.Digital4 = Joystick2.Button5
PPJoy1.Digital5 = Joystick2.Button6
PPJoy1.Digital6 = Joystick2.Button7
PPJoy1.Digital7 = Joystick2.Button8
PPJoy1.Digital8 = Joystick2.Button9
PPJoy1.Digital9 = Joystick2.Button10
PPJoy1.Digital10 = Joystick2.Button11
PPJoy1.Digital11 = Joystick2.Button12
PPJoy1.Digital12 = Joystick2.Button13
PPJoy1.Digital13 = Joystick2.Button14
PPJoy1.Digital14 = Joystick2.Button15
PPJoy1.Digital15 = Joystick2.Button16
PPJoy1.Digital16 = Joystick2.Button17
PPJoy1.Digital17 = Joystick2.Button18
PPJoy1.Digital18 = Joystick2.Button19
PPJoy1.Digital19 = Joystick2.Button20
PPJoy1.Digital20 = Joystick2.Button21
PPJoy1.Digital21 = Joystick2.Button22
PPJoy1.Digital22 = Joystick2.Button23
PPJoy1.Digital23 = Joystick2.Button24
PPJoy1.Digital24 = Joystick2.Button25
PPJoy1.Digital25 = Joystick2.Button26
PPJoy1.Digital26 = Joystick2.Button27
PPJoy1.Digital27 = Joystick2.Button28
PPJoy1.Digital28 = Joystick2.Button29
PPJoy1.Digital29 = Joystick2.Button30
PPJoy1.Digital30 = Joystick2.Button31


***

If we want to get really technical, the Apache minimum torque with rotor fully to speed when on the ground while collective is completely lowered is 6%. Something like this will give you that, though I still think perhaps the 10% minimum may be better for reducing capacity to unrealistically quickly decelerate.

nonlinear-collective-zone1=0.4 # non-linear control value for throttle (n = % throttle position joystick to represents 60% collective) (10% = 0.1) (0.0 = off (linear control), 1.0 = max) (def = 0.3)
nonlinear-collective-zone2=0.9 # non-linear control value for throttle (n = % throttle position joystick to represents 100% collective) (10% = 0.1) (0.0 = off (linear control), 1.2 = max) (def = 0.7)
nonlinear-collective-percentage-at-zone1=54.0 # collective percentage at zone1. Valid values are in range from 1.0 to 99.0, default is 60.0.

***

See this related thread:

https://SimHQ.com/forum/ubbthreads.php/topics/4554183/all/crosscoupling-poll

***

[your collective axis] * 0.7 - 0.15.

I've been trying to mitigate lately both EECH's excessive tendency to decelerate rapidly and more importantly the crazy amount of overtorque power we can get. The diminishing return of very high engine torque is not properly being modeled, and therefore we can not only slow down too fast or VRS too easily, but then are able to just power out of VRS. Adding this math to the collective axis is one way of dealing with both on the Saitek throttle with EECH's internal collective option set to linear. This returns the minimum collective torque with engine spooled up completely at about 10%, first rearward detent at 90% with no cyclic or trim applied, and 97% fully rearward with no cyclic or trim applied. Applying cyclic or trim will obviously add slight overtorque. With this, I cannot decelerate too rapidly and I cannot simply power through a VRS by yanking to 120% torque. With VRS, I must really try to get lateral movement.

Last edited by Reticuli; 02/22/21 06:04 PM.

The term "necroposting" was invented by a person with no social memory beyond a year. People with a similar hangup are those o.k. with the internet being transient vapor.

http://www.openfuelstandard.org/2011/12/methanol-wins-open-wager.html

Saitek X65 and X52, Glide, Winx3D, and GlovePIE Profiles http://library.avsim.net/search.php?SearchTerm=reticuli&CatID=miscmisc

http://library.avsim.net/register.php

X52 + Silicone Grease = JOY stick
Page 3 of 3 1 2 3

Moderated by  messyhead, RacerGT 

Quick Search
Recent Articles
Support SimHQ

If you shop on Amazon use this Amazon link to support SimHQ
.
Social


Recent Topics
The bank robber
by Bill_Grant. 03/03/21 09:14 PM
Boca Chica Shiny Express...
by Nixer. 03/03/21 05:53 PM
Where are you from? test
by NoFlyBoy. 02/28/21 03:51 AM
British Army cooks 1960
by PanzerMeyer. 02/28/21 12:47 AM
Join me my brothers and sisters.
by NoFlyBoy. 02/26/21 02:34 PM
The Battle of Verdun Lego style
by PanzerMeyer. 02/25/21 07:53 PM
Copyright 1997-2016, SimHQ Inc. All Rights Reserved.

Powered by UBB.threads™ PHP Forum Software 7.6.0