How much does nostalgia cost?

Just tried Virtual Desktop and OpenTrack in EECH. It works, but I think you have to adjust OpenTrack in the pitch axis.

EECH doesn’t do 1:1 head tracking with TrackIR, I think. It felt like the pitch axis was dampened considerably. So, I adjusted OpenTrack to 4:1 in pitch (Tilting my head back 10 degrees resulted in 40 degrees of OpenTrack movement. This resulted in much closer to 1:1 in EECH. Still tweaking to find the right settings. I also felt a bit of dampening with EECH TrackIR movement in general. I would turn my head and it took a quarter second to catch up. not unplayable, just annoying.

Now I just need to map some buttons. I’ve become spoiled with sims that let you map your buttons in the game!


That alligator pit looked so much better in my memory…

Bought it. For $5.99 and that mod pack, who could miss out on a killer helo sim. Thanks!

Any ideas on why my sound wont work. I’ve selected my Realtek Audio blah blah… No joy.

Hmm…no, I don’t know what could be causing that.

Lots of niggling issues in EECH still. I have a long list of them and my wish list for other stuff in the simhq “FLIGHT MODEL or where is it ?” thread. Speaking of flight models, much of the modeling and values are not in the dyn files as we’d been told but rather mods had hard-coded some of it into the source code itself. You can mess with the aircraft dyn files until you’re blue in the face and you’ll only make minor improvements. Quite a bit can be done in the EECH.ini even with this limitation, though.

Probably most relevant quirks are that FM0’s auto-tail-mixing ‘crosscoupling’ OFF breaks the lift modeling, FM1 absurdly has no yaw streamlining at all, and FM2 reverses its translational lift and breaks the yaw on the coaxial helos. Coordinated turning (i.e. yaw when you apply bank) also happens at every speed and even in reverse except in FM1, which has none ever. Yikes. And the yaw authority is all over the place, too much, too little. You need very nonlinear pedals and some way of adjusting the range available on-the-fly. Then the viper has about the same top speed as the Kiowa and the EECH m197 20mm has way more than 750 rounds.

source code for Comanche, SupCobra, SeaCobra, and Viper: #define NUM_CANNON_ROUNDS (1345)

Also some persistent issues with SAM envelopes when you’re NOE, helos landing on top of helos, rotors disengaging when you jump in a helo that’s already in flight, and really weak weapons on the lower range. Comanche was too dominant. Damage modeling is simplistic. Etc. Etc. It’s come a long way, though, and the flight model can arguably be tweaked currently to better than anything from Microsoft or Flight Gear, and is reasonably-close to X-Plane’s AFCS helos with the proper tweaks and additional outside software. Quite a few of the helos still unfortunately use the stock Apache A pit, but a few mods are apparently working on cockpits.

3D stereoscopic is not possible in EECH1 currently. In fact, a recent slight revamping of graphics system has resulted in even the buildings, airports, sea ports, and cockpits no longer rendering in stereoscopic if you try it. Previously you could hypothetically build one giant map of ports and buildings and potentially get full 3D. Stereoscopic is fine in EECH2 but the source code for that is not released.

VRS never worked right in LB2, and it was hard to tell if it was intended as VRS or was just badly-coded low-RPM stall from over-pitching the main rotors that was doing weird stuff at different frame rates or vice versa. On modern Windows, 30hz V-sync prevents all stalls it seems. At 60hz V-sync if you get into a VRS-like stall, you’re toast, unlike on Windows 95 as I recall. At 120hz or unlocked FPS, Janes LB2 seems to run as if it’s at like 2 or 3X time accel, with 60hz’s inescapable pseudo-VRS.

EECH’s VRS is only easier to get into than it should be from the standpoint of it being so easy to decelerate in the sim with the default collective range that you can trigger it rather quickly. This coincides, though, with it being easier to get out of than it should be, with no reduction of cyclic authority/effectiveness and no asymmetry of escape techniques. Lowering the collective isn’t needed to regain cyclic in the ineffective directions and one side of the cyclic won’t work any better than another in a tail rotor helo. You just add any lateral movement and you’re immediately sliding out of it. With the default collective range you also have the option of simply powering out of it with 120% torque even if you don’t induce much airflow horizontally over the main rotors. Given the unrealistic ability to decelerate at minimum collective, the fact the foot of the torque curve is so weak, and the shoulder of the torque curve is too strong without a diminishing of return as in real life, the best solution I’ve come upon for both VRS and the collective in EECH 1.16.2 is just set the collective range from about 10% at minimum with engines spooled up and about 100% max with only slight overtorque with cyclic. That way you can’t decelerate and stop on a dime so much, your take-off collective is lower, and you can’t power out of VRS usually without a lot of lateral movement. This results in more methodical landing approaches, and while you’re always on your toes for VRS still appropriately, they’re slightly less likely to occur and harder to get out of. I have also generally just ran out of torque when getting reckless on decel and settled with power into the ground hard without a VRS happening. That’s good. This is the * 0.7 - 0.15 in the GlovePIE script below that I use with PPJoy:

var.nlzs = sign(Joystick2.z) // Collective nonlinearity that can be made more gradual near center.
var.nlzm = abs(Joystick2.z)^(1.0) // Previous Exponent of 2.0 for true nonlinear with large gradation in the middle, but 1.0 is linear.
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.

var.nlzrots = sign(Joystick1.zrot) //Nonlinear pedals.
var.nlzrotm = abs(Joystick1.zrot)^(2.0) //1 will make it linear. Higher, less linear.
var.nlzrot = var.nlzrotm * var.nlzrots

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

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

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 / 20 ) / var.yawrange //For pedals. Usually bypassed unless FM 0 or 1 with coaxials.


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 * 0.7 - 0.15 //Collective currently reducing/adjusting range to prevent overpowering VRS and to reduce decel
PPJoy1.Analog5 = (var.pedalfix / 1 - var.dial / 20 ) / var.yawrange //For pedals. Now with yawrange on thumb dial.

} = 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

Hypothetical EECH source code for the yaw divider automation using a combination of arbitrary and guessed names for the values, though I suspect the relationship between IAS and the yaw input divider should probably be nonlinear with nearly full available yaw input at substantially less than Vne, but this simple linear relationship is a good first start:

If FM=2 or Blackshark=yes, then YawPart = 0, else If Hokum=no and FM=/=2, then YawPart = 1
If (Hokum=yes or Hind=yes) and FM=/=2, then YawPart = 2
YawDiv = YawPart + 1 – IAS / Vne * YawPart
NewYawInput = OldYawInput / YawDiv

The recommended EECH.ini automation:

If Crosscoupling ON or flying a coaxial:


Plus Translational Lift Options-Dynamics setting to ON (probably should not be changeable by users in such automation).

If NOT flying a coaxial and you have crosscoupling OFF:


Plus Translational Lift Options-Dynamics setting to OFF not changeable by user (probably should not be changeable by users in such automation).

This is my current GWUT I’ve been using to tweak the gameplay balance. Rename it your current GWUT or edit the EECH.ini file appropriately to use it. If you want to edit the GWUT itself, use a text editor. YMMV, of course in terms of whether you like these changes or not. I tweak it weekly, it seems. I wanted stronger weak weapons, more variety, and an RAH-66 that isn’t so dominant on the battlefield, among other things. The RAH-66 was getting overweight with all its increasing systems requirements prior to cancelation, so removing some armor or re-imagining its composite resistance to rounds as absorption durability and redundancy, but not outright deflection is not totally implausible. Coaxials are a hand full to fight with, particularly their weapons compared to the American stuff, so I allowed them more armor as if all that reserve power lets them keep slapping that stuff on. The 20mm gun is also more precise than before, creating a greater contrast compared to some of the others like the Apache’s.

Oh and I highly recommend turning G head movements and vibration up in the ini. I put them at 1.5. Lots of options in there.

1 Like