Hello,

When i am on stable hover hold (SHIFT H) for using the FLIR / DTV, the view on the MFD is not stabilized because the chopper still turn to the left or the right (very slow rotation). So it's hard to lock a target with the mouse.

I try to use the trim (T key) but it seems not to work in this case.

I see on the keys map that CTRL-H allows to use "heading correction" : what is this function ? Do you know how to use it ?

Thanks for your advices !

What flight model are you using? I noticed this when I was using FM0, it would rotate when hovering.

I am using the 1.16.1 update with the GWUT1161.CSV file.

And my flight model in the game's options are :

- blade stall : ON
- Cross couple : ON
- Ground effect : ON
- Keyboard assist : ON
- Over-torque : ON
- Vortex ring : OFF
- Wind : ON

What do you mean when you refers to "FM0" ?

In the eech.ini in the cohokum game folder on your drive, you can change the flight model.

T does not trim the pedals, that I know of, and force trimming the yaw is not particularly a good option to have, I've found, anyway.

You might want a secondary mild yaw trim axis, which can easily be done with PPJoy & GlovePIE.

One issue with the yaw right now is the lack of legit separate damping, rather it's based on the yaw drag value, which must double as both, hence it's easy to get yaw either induced by wind, inertia, or the constant coordinated turning at any velocity, even zero KIAS when you bank. Still, don't neglect the EECH.ini FM values. I'm surprised you hadn't yet gone into the ini yet. It's essential to adjust stuff in there.

The new Crtl H for heading hold is low authority. It was recently added, but is not very effective. It also only works when you have the EO system locked on something, at least the ground. It may be better than nothing and useful enough for your purpose in some situations, though.

Ground stability option in the ini also does not seem to be working anymore that I can tell, which should be preventing such EO system drift relative to the ground when you are not locked. (edit: this was wrong)

If I were you I wouldn't often bother much with manually moving of the FLIR, but if you want to do it, you can always assign it to a stick or throttle hat instead of or in addition to the mouse. You should be able to rather just flip through targets instead of manual designation, but both Previous and Next go in the same direction on both the EO system and radar, so go slow as you cycle through them since if you pass the one you want you have to cycle back through all.

Regardless of whether you manually lock a target or cycle through them, it will unlock pretty easily right now from an actual discrete sim target, which is another bug. This is especially bothersome when using laser-guided missiles. If you're firing on a small, static target, you may want to lock to the ground right now near what you're firing on, as for some reason it doesn't unlock from the ground frequently. If it's infantry, just lock to the ground manually near them. If it's something bigger, you can always move onto the object at the last moment.

As for which FM you should use in the EECH.ini, I suggest reading this:

https://SimHQ.com/forum/ubbthreads.php/topics/4567898/re-whats-the-best-version#Post4567898

Thanks for you advices !

Do you know what is the "heading correction" (CTRL-H) : what is this function ? Do you know how to use it ?

See above.

Hi Guys,

I don't understand how these things are getting broken.

I've looked through the work listed in the 1.16.1 release and I don't see anything that would cause things like the stable hover hold or FLIR ground stabilisation to stop working, Were they working before that point ?

Is the original code so badly written that changes made to one part are causing problems in a totally unrelated part ?

Very strange.

Andy

Oops, sorry ! :-)

No order, discipline, cooperation, formal organization, or management really in the EECH modding community. Sort of a textbook case of a coding free for all. Too many cooks in the kitchen... and in this case it's kind of a post-apocalyptic kitchen where various squatters have roamed through as it fancied them. But hey, when you're dealing with the desolation of the abandonware wasteland, having any kitchen at all standing is kind of amazing... as is that any of the modifications have ever gotten shared at all.

Crtl H (heading hold or turn to target) is new and it never had significant yaw authority to begin with. I think TheAlx added it (correction: Javelin did it), but it's just not strong enough to be that useful. Neat idea, but to be highly effective it would need to work all the time when the EO is the active sensor after that H is showing, not just when the EO is locked, and it needs more yaw authority. It might be just enough to noticeably counter some of the yaw you're experiencing, though.

The non-stable hover hold seems broken because of weird stuff it does with torque now... at least with the default generated dyn files in 1.16.2. Not sure when that started. Stable hover hold, in contrast, always simply stabilized the altitude and did nothing to the yaw, and this is the only one of the two auto hover modes I use since non-stable will over-torque you. On a positive note, both stable hover and altitude hold do work well now (thanks to Javelin); the latter, in particular, originally had very serious problems. The yaw weirdness you're getting is partly new due to FM 0 now having a massive variation in yaw pedal authority from helo to helo but is also partly as a result of the old poor yaw damping and the old constant coordinated turn at any speed, even zero KIAS. Auto coordinated turning is supposed to only happen well past ETL speed... often double or triple ETL speed. So like 50KIAS isn't a bad spot to start transitioning to some gentle auto coordinated turn yaw when you bank. FM 2 also has this ubiquitous turn coordination, as this aggressive turn coordination appears to date back to the original source code and is present in EECH2.

Why did they do it that way? Maybe as a means to let people yaw who didn't want to mess with a separate yaw axis, or maybe the original coders just didn't know what they were doing. By the way, the later FM 1 optional mod in the ini gets rid of the turn coordination completely by just eliminating all aerodynamic streamlining & weathervaning in the yaw, throwing out the baby with the bathwater accidentally, probably because this turn coordination was originally coded as part of the aerodynamics. Sound familiar? It should, because the yaw damping (no relation to the turn coordination, by the way) is also basically having to be done as just part of the aerodynamic yaw rotational drag. It's like the EECH helo flight control systems and aerodynamics don't seem programmed separately, but rather as one unified goofy whole. In real life, you have the aerodynamics happening, and then you have the flight control system, and the turn coordination and yaw damping are not supposed to be modeled as aerodynamic effects but rather part of the flight control system.

I'm guessing now, but it's almost like the original coders didn't know much about actual aerodynamics or flight control systems, but rather were just attempting to duplicate crudely the observed performance of a complete aerodynamic simulation flying an SAS/AFCS helo... like laymen coders ran X-Plane 7 and Longbow 2 a few times and then tried to mimic without knowing how either was programmed. EECH has VRS, RBS, and loss of tail rotor effectiveness, though, and neither of those other sims had that back then (XP 11 helo stuff has all of it now). So maybe they had access to some high-end sim like GenHel, the Boeing Apache sim, or maybe the legit Comanche sim for a couple hours or something. Who knows. It's a curious technique to just superficially mimic the combined results of aerodynamics and SAS/AFCS, and I'm surprised they got it as close as they did... or at least they have the raw ingredients to get it to something pretty close. Some of the mods have also added flight model & 'feel' nuance, even if they've broken other things or made it weird. If you do the ini tweaks as I've stated, there are ways of mitigating most of this and making it quite usable, even better in some ways than it was originally, especially if you use PPJoy & GlovePIE, too, though it's not going to rid you of yaw when you bank in a hover on FM 0 or 2, and FM 1's complete lack of aerodynamic streamlining & weathervaning in the yaw is obviously not the answer.

I think the original code was as good as it got at that time, or as good as it got given the timescales and resources available. If Star Citizen levels of money had been available, I'm sure we'd have had DCS 2000 . DirectX was primitive to what it is now, and EECH still uses primitive model for physics. It doesn't use any of the DirectX physics model, as it would need to be updated to DX10 at least to start getting something of it.




I agree. Many years ago, I tried to start a discussion to coordinate the modders in working in one direction, and to pool our efforts. But I was pretty much shot down in flames, and accused of trying to take control. I've worked in software development since 2005ish, on projects for large organisations. Individual developers never got very far in that environment, and projects only got completed by everyone working together. But EECH has never had a "development team" so to speak. It's always been talented, individual modders working on their own thing, or trying to fix things that were raised. Maybe in the very early days of modding EECH, there was some coordination. But as time went on, and people moved away, it got less so.

However, in defence of all the modders that have come and gone, the codebase isn't easy to get to grips with. It's written in C, not C++, so it not modular like C++, and can be difficult to work out how things work if you're not familiar with it. I also feel as though there's not a huge community playing it. So when test releases are made, they're not extensively tested to find issues before the main release is made.

I also feel that the last few releases have been focused on adding things, some of which were needed, rather than fixing issues or improving fundamental flaws. I'm only familiar with a small area of the code, around how the cockpits and instruments work. Beyond that, there's the scary world of the AI code, the terrain and graphics rendering, and the mathematical behemoth of the flight model.

Part of me feels like going back a few versions to see how things were. 1.15.2 added Flight Model 2, and things to do with EO stabilisation. 1.16.0 was mainly visual, but changed to use Direct3D9. 1.16.1 had more flight model changes, and hover mod.

1.16.2 added this, which might be smoking gun for EO problems now?



I might go all the way back to 1.15.0 and see what it's like.

I stickied all the release posts back to 1.15 so they could be easily found again.

I am always peeking with great interest what is happening in EECH community because in many aspects it reminds me very much of Falcon BMS development.

And yes the biggest difference here and there is that all changes to code and data are supervised and approved by one responsible (and perhaps one of the most talented) individual and no update or full version are approved unless the team's beta testers would not try to squash and eliminate all or most of the bugs resulted from the introduction of the latest update or version.

About trying to bring Flight Model to the latest and greatest standards, I think the biggest impediment may be the DX physics. I am not sure here though as I have no experience in this field at all.

What I am sure though, cause I have some experience and exposure, is that any terrain update and other graphics aspects are totally dependant on upgrading to possibly the latest DX12 or at least DX11.

Otherwise, any attempt at improving visuals is like trying to squeeze water out of the stone. Sorry!

DX12 is not even remotely necessary. There's nothing wrong with EECH 2's graphics engine.

Yeah, It needs a DirectX upgrade. Firebird did a lot of work to upgrade from using DirectDraw in DirectX7 to D3D9 in DirectX9. There was a lot needing changed and fixed just for that. But it didn't update all the DirectX APIs to use DX9. But... the step from D3D9 to D3D10 isn't as big, and I've been reading about it recently.

However, even just changing to a newer DX version, doesn't immediately bring graphics improvements. Models and effects need redone to take advantage of the newer DX APIs. The terrain code is all hardcoded and custom EECH C code. So the terrain would need to be changed to render using DX10 (or even DX9 to start with).

Falcon BMS had the advantage of never really being open to the community. It was still under the control of the dev team who imposed their standards. Once Razorworks and Empire released the EECH code, it was a free for all.

Agree with the former, disagree with the latter.

They just updated to DX9 from DX7, but they had a full dev team with the no-how, time, and money to do it. Yeah, it looks shinier, but the terrain rendering is still done in proprietary EECH code. Rumour has it, they used one of the releases from the mod community as the start point for EE2 (probably around v1.10), as they technically still owned the code back then.

I'd love to pick the brains of the Falcon BMS devs to find out how they updated Falcon 4 to Falcon BMS. It's not an impossible task, but at this point for EECH, it's like standing at the foot of Everest in your underwear, and all your clothes and food are on the summit.

Recently, I have made some googling about helicopter flight models. So far I came with only 2 serious finds. Here is the 1st one:

Is this FM at the 1st place? Is this FM any good? How does it compare with EECH?
https://community.bistudio.com/wiki/Helicopter_Flight_Model_Config_(XML)

Here is the 2nd one from NASA:

A Flight-Dynamic Helicopter Mathematical Model with a Single Flap-Lag-Torsion Main Rotor
https://ntrs.nasa.gov/api/citations/19910009728/downloads/19910009728.pdf

Obviously serious (maybe too serious ) mat and physics stuff. Anyone?

Are there any other examples known by you Guys?

I actually remember looking into this quite a while ago, and asking about it on the forums. But I'm not sure how it can be used. I don't know if you need to use their fill system to build your simulation, or if you can just plug their flight model APIs into an existing simulation. Arma 3 used it in one of their DLCs

I might try contacting them to ask, but it's probably not free to use.

http://www.rtdynamics.com/products-services/simulation-and-training/rotorlib-fdm-for-c/

The EECH 2 graphics engine is crisp, effective, very high framerate for what you get, and it can run in complete stereoscopic. EECH 1 originally did partial non-terrain sterescopic, and that now is broken, and EECH 1's framerate is inferior considering the detail level, the blah dynamic range you get, and that nasty bright haze always on the horizon even in the middle of the night.