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.

EE2 uses DirectX 9 shaders . EECH still uses DirectX 7, but has been pushed as far as it can. That's what causes some fps drops. EE2 hasn't had the graphics pushed as much as EECH has.

If EECH used DirectX 9 shaders, then it would look a lot better.

I started trying to reverse engineer EE2 last year to see if I could decode the source and bring it into EECH, but it was too difficult for me to get into.

http://eechcentral.SimHQ.com/index.php?title=Enemy_Engaged_2

If I remember correctly this question was asked time ago, but let me ask it again: As individual with non programing experience in projects like this, I can't avoid ask myself why only focus on DirectX instead of Vulkan?

Sorry if it's a non sense question. I repeat my programing skills are very far from the minum requirements that a project like EECH code demands.

Regards

It's not a nonsense question. In fact, Firebird had implemented using Ogre to do the graphics work instead of DirectX, and there is a version that can be run using Ogre. But it's incomplete work.

The only blocker to using any other engine, is the no-how in how to port everything across into it. I suppose DX is mentioned most as the game already uses DX, so might be easier upgrading, than starting again in a new engine.

However, just updating the game to run in a new engine won't bring immediate benefits and make the graphics look better. Models, textures, terrain etc would all need reworked to use the updated engine capabilities. It's a 2 stage process really, 1 - get the game running reliably in a new engine, then, 2 - update the graphics assets to use the new engines capabilities.

I see more clearly now, thank you!

I thought TheAlx said he'd already superficially ported something in EECH to DX9 but that nothing new was being used in it, like DX7 code running in some kind of superficial DX9 framework. I was assuming that's why the stereo effect is now completely nonfunctional... something in the porting process busted it. I'm uncertain what he claims he did exactly or why he did it.

Maybe, but I'm not sure. A lot of the old cockpits, like the Havoc, used direct draw from DX7. That's why the instruments stopped working in D3D9, and might also be why stereoscopic stopped working.

Which again begs the question "Why?" since it doesn't appear to have added any capability and all it did apparently is break more things and remove compatibility with some old mods. Maybe some future plans he (or whoever did it) had for something, but now he (at least) is apparently hard into MSFS 2020 instead. I'm curious as to when this superficial porting happened.

Back to the EO stabilization, all that ground stabilization is supposed to do is that once you have locked and unlocked it is supposed to remain stationary with the ground even if the helicopter moves and there is no target. The closest we seem to get to that now in 1.16 is locking to the ground without unlocking, but then it's very slow to move.

When I say a lot of the old cockpits, that's not really accurate, as it's only really the Apache A (which had already had 3D needles added in previous mods), and the Havoc. The Comanche and Hokum were all "digital" in that they used MFDs for the displays.

Direct Draw is primarily for 2D, Direct3D is for full 3D, which is why the 2D cockpits stopped working. Moving to Direct3D was a step towards updating the engine. But as I've said, noone has since updated anything else to start using more of the DirectX APIs to add other effects. The game code can now be compiled using DirectX9 libraries instead of DirectX7.

This was the reason I proposed to improve EECH based on 1.15.4, cause some of cockpits did not working anymore since 1.16.0. Fortunately this was all fixed by messyhead, who did most of the work to get things running again in 1.16.X and also the most work on the whole EECH project since 2016.

I already had that fear in 2016, that all those promised improvements will never come true and that it is mostly needless to update the engine to DX9, if all those things never will happen.

It was already foreseeable in 2016, that a lot of the modders left EECH for ever and all those things which needed the version upgrade will never be implemented, cause no one else is able to do it. But instead it broke more things that it has improved and a lot of work had to be done to only get already working things functional again.

Imagine how much could be improved in 1.15.X with all those work, which was only necessary for 1.16.X to get things running again. And the graphics aren't much more worse in 1.15.4, than in 1.16.X. But we could have some more flyable choppers instead and other improvements.

Just my two cents.

And to be honest, this was also the reason, for me personally, why I lost the interest in EECH Allmods and only finished my KA-50 cockpit as promised.

I agree.

For a long while the modding has been pushed towards the "eye candy" updates by people like Banita. I only know of TheAlx and Messyhead who have worked on fixing things.

Don't get me wrong, I just LOVE the Poland map and play there most of the time, but do we REALLY need animated grass ?

Maybe I'm biased as I play within a real cockpit and only really see the outside view, so the instruments, cockpit and exterior views mean nothing to me.


Problem is, we have so few modders these days. Because they are giving up their time to mod the game, they decide what to do.

I know from experience that it's hard to follow someone else's code especially the way EECH was written, so I can understand if they don't want to give themselves that headache.

The alternative is to learn to code (as Messyhead has) and get stuck in yourself. I did try that, but couldn't follow the program flow in EECH. It seems to jump about a lot, and even finding where a variable was used was difficult. Maybe it was just the way I was trying to do it, I don't know.


I believe that The Alx moved it over to DX9 in the hope that some of the other modders of that time would pick up on the advantages of the new framework and produce upgrades based on it. Unfortunately, that never happened and a lot of the modders dissapeared.

How we go forward from here I do not know, maybe Viper is right and we have to go back to a previous working version and come forward again.

Just my "humble" opinion guys.

Andy

PS it's nice to see these discussions going on without all the emotion.

It was FireBird that moved to Direct3d9, then thealx helped fix and reports issues.

I agree it's good to have a discussion on this subject, but it needs a new thread as this was has been hijacked and off topic. I don't want to get into some things here, so I'm going to PM you all about some things to do with 1.15.4, then we can come up with a plan.

Turns out ground stabilization in 1.16.2 itself is not actually broken, it just requires Ctrl S first to bring the "S" onto the EO and it's also a bit weak, as it still moves a little as your helo moves, but stabilizes somewhat. It does not require a prior lock and unlock to stabilize, just the "S" active. EECH 2's is exactly the same. It needs to be allowed with 1 in the EECH.ini. Oddly enough, when the EO is zoomed-in then locking to the ground is actually faster moving than ground stab is, but if you are zoomed out the unlocked ground stab mode is the faster movement. Anyway, this is obviously only a part of Phenixfulcrum2's issues, though. Try turning that new Crtl H auto turn to target, even if it's weak, and try not to bank when hovering as that's going to add the unwanted auto turn coordination yaw. I just bound Ctrl H and Ctrl S to the same button for the heck of it and it's not too terrible in combination. Don't neglect the EECH.ini settings, go over my FM tweaks and adhere to them, and consider PPJoy & GlovePIE for auto trimming and/or for a trim axis.

Sorry, english is not my native language, so i have difficulties to understand what you write. Can you tell me if it's good :
1) i have to modify eech.ini with the parameter grstab=1
2) before using CTRL H, i must do CTRL S

Thx !

Yes, you allow it to be activated with that value set to 1 in the ini, but you still need Ctrl S in the sim. Since you're in the ini, make sure you check other stuff and do the FM tweaks for having crosscoupling ON and/or flying coaxials:

flight_model=0
drv=1.0
dra=1.0
drd=0.1
dmrl=0.9
dtrd=10.0
dyal=2.5
dyad=3.0



The order doesn't make any difference. You just might want to utilize them both, though they don't work at the same time. They work independently, and both are weak effects.

Ctrl H gives a little turn to target lock from the yaw when you're auto stable hovering (Shift H) and locked (Numpad Enter), showing an "H" in the bottom right of the EO display.

Ctrl S provides a little ground stab to the EO when you are unlocked and shows an "S".

However, when you are zoomed far in, you might want to just lock to the ground for targets in the dirt, because you can slew the EO around faster for some reason and it's also better stabilized than ground stab. If you're zoomed out, ground stab without a lock is faster-slewing even though it's not as stabilized as a lock to ground. For air targets, you're kind of screwed either way, since the ground stab understandably can't do much, obviously, and you can't just lock to the ground when pointed at the sky, either. So the EO system still wants to unlock air targets pretty easily, and it's too early for me to even say "S" has resolved most of the issue with it auto unlocking ground targets or the inability to acquire targets automatically at any but the closest ranges with the EO on some helos, like on the Kiowa and Viper.