I've tried to start campaign (random map), select random side, start mission, exit campaign, start new one - about 10 times in a row, no crashes. Does not mean issue does not exists, but it may happen in very special conditions, or you have some buggy mod installed.
I remember in 1.15 overTQ would cause some damage fairy shortly after the overTQ alert.
No, it's not fair. Any helicopter can spent several minutes in maximum engine RPM mode without damage, especially US developed. Currently, overtorque state is taken not really from RPM value but from engines temperature. Higher temperature - more chance that engine will be damaged or get on fire (random modifier applied). In normal forward direction flight you may damage them in about 5-10 minutes. I've made some aerobatics on Ka-50 and get right engine damage notice after about 1.5 minutes of flight, then temperature of left engine raised dramatically - after 10 sec I've got it's fire notice.
So, it's not the same as in 1.15.0 but enabled overtorque dynamics option still cause some problems, sometime in a very bad moment.
My apologies. Tested this yesterday. Did a 5 min run, 120% TQ, one of the engines just died so I am well pleased with this. Thanks.
Hi thealx, it happens with both COHOKUM1161 and COHOKUM.EXE, i really don't know why. This happened with 1.16.0 also.
Can you please set debug_log=1 in INI file, next time when you will have such freeze - check /cohokum/debug_log.txt file, maybe it will contain some errors.
Ka-50 -when I trim forward the ciclick and I go navigating when I pull the ciclick bak for avoid trees or mountains, seem dont raise like ka-52 or other helos. Same happends if I take the ciclick out, dont raise toó much, not like other helos.
Tried it myself - it's true that coaxial helicopters are heavy on controls, especially Ka-50, but can't say it so critical. You may try to replace \common\data\dynamics\ka50.dyn with hokum.dyn from same folder (so Ka-50 will have same dynamics attributes as Ka-52). Another option is copy ka50.dyn file from 1.16.0 dynamics pack, as helicopters there much more maneuverable.
hmm I never seen he made it, at least nothing in the code. if it was really included in one of his builds, such change was not pushed into source code repository. I have seen your request and made it my way - you can try to set unbind_jbuttons=1 in INI file button #4 will be removed as well
I've just tried cockpit lighting for the first time, and it's pretty cool.
I think I've found an issue with it though, could someone else verify?
When in cockpit view (e.g. F1/F2), and I switch off the cockpit HUD (CTRL + K), then the lighting switches off. If you keep pressing CTRL + V it cycles through from being on to a few "off states" then on again. But it doesn't show the lighting in the same way as when the HUD is on.
It happens in all 3D cockpits on blue and red sides (except for Hind).
The attached images show HUD on in the left, and off in the right.
1. lights was migrated from clickable Hind which has advanced electrics calculation - so there is no light when no power source available, or overload happen. In key guide Ctrl-K calls HUD on/off, but in the code this function toggles "electrics" variable, so I have used it for lights as well. So it's not a bug when light goes off after Ctrl-K pressed, at lest for now.
2. I remember that someone complained that cockpit is too dark in the midnight on mission start (while electrics turned off), so I've added artificial dim light when cockpit light is turned off. and looks like I missed situation when cockpit light is selected but not enabled because electrics turned off, will fix it.
1. lights was migrated from clickable Hind which has advanced electrics calculation - so there is no light when no power source available, or overload happen. In key guide Ctrl-K calls HUD on/off, but in the code this function toggles "electrics" variable, so I have used it for lights as well. So it's not a bug when light goes off after Ctrl-K pressed, at lest for now.
That explains it, as I saw it had different behaviour in the Hind. I suppose it also explains why the upfront display goes off in the Apache.
does file update timestamp same as crash time? because this error may happen in the past without any crash. and which helicopter you was inside at the moment?
Originally Posted by BANITA
of course it's me and please don't change anything with the power of lighting, now it's good.
No, don't worry - dim light will stay the same, in any electrics/light switch state.
"error opening file for reading: e:\comanche vs hokum\common\graphics\ui\cohokum\map\payvid.psd"
Followed instructions as per post (GOG version, no additional patches then 1.6.0, etc.).
Also tried tried installing 1.15.0 first as I read one report of this same error with response being that that file was in 1.15, however I still receive same error
Also tried installing EEAH, then EECH then 1.15 - same error
sounds familiar, but can't remember solution. try to disable Windows compatibly option from cohokum.exe, run it as administrator. payvid.psd should not exist in latest version, maybe antivirus blocking updated EXE during installation and you're running older version?
We'll need to start a troubleshooting page on the wiki for these things. My antivirus blocks so much stuff. When something doesn't work, it's the first thing I check.
I have not used antivirus for 18 years, I have never had problems.imo anti-viruses are unnecessary and useless. they work after infecting a computer. Good firewall and thinking is enough.
Originally Posted by messyhead
We'll need to start a troubleshooting page on the wiki for these things. My antivirus blocks so much stuff. When something doesn't work, it's the first thing I check.
good idea.
Last edited by BANITA; 04/22/2005:42 PM.
#4517628 - 04/22/2006:06 PMRe: Issue tracker for v1.16.1
[Re: ]
I have not used antivirus for 18 years, I have never had problems.imo anti-viruses are unnecessary and useless. they work after infecting a computer. Good firewall and thinking is enough.
Everytime I visit this site, my virus checker freaks out about malware from all the adverts. I usually use a Linux system though, so don't have problems. It's only when I'm doing EECH dev work that I use Windows.
cant download anything from eech online. when click get files scroll down to screenshots and nothing happen. Checked on phone and pc. All adblocks disabled. I can only download allmods instaler , if i want download 1160 or 1 nothing happen, cant download. I suspect it should be like that(?), but it is a bit confusing to me.
1. on "Get latest version" click you should be navigated to download links (near to "Manual extraction archive"), so this is correct behavior. in all cases except allMods installer, you shouldn't download files manually, but using installer application 2. is drive.google.com works for you, as app using google server as primary storage? what happen when you press "Download from Google Drive" link on the website? 3. when you start to install mods in application, is progress bar starting to change at least somhow?
the first point explained all. confusing to me was that there are counters downloaded mods, and I thought it could be manually downloaded without the installer.
it CAN be, but SHOULD NOT because when mods unpacked manually, dependency checks will not happen - main reason why this application was created download links appear on the website in case if application does not work, google server not available for the user or anything like that.
Hi! The game crashes when I click the Tasks button with debug log ASSERT 'paths[path].from >= 0 && paths[path].from < number_of_nodes' (J:\EECH\git\eech-master\modules\3d\terrain\terrmap.c:1692) or even without it even when I enable "debug_log=1" It is a quite a stable crash for me. Here is a video I managed to record http s://youtu.be/lW2KaXu9a3Q
Win7 x64, "Run as admin" checked The game installed from the original disc (ru), then upgraded to 1.16.0 and then up to 1.16.1 via allMODs
Hi, I don't know if it's a bug in the game or something else, but in the glass cockpit in Mi-28 Havoc , in the bottom left corner, I cannot turn on the radar preview. I see only some strange vertical lines. Is it only my issue with my graphic card (AMD Radeon HD5770)? EECH 1.16.1
I have a Radeon HD7700 card in my machine and tried what you have.
I get the same as your picture. The coloured lines are the data from the engine monitoring ie, Trq, Ng etc
Looks like a bug to me. You can see the background changing as you switch between DTV, FLIR and radar.
Sorry I couldn't be of more help.
Andy
PS I know it's not and consolation but when I fly the Comanche I have two of these screens bottom right and left. I can switch any of the MFDs on to them and they work properly.
Hi, I don't know if it's a bug in the game or something else, but in the glass cockpit in Mi-28 Havoc , in the bottom left corner, I cannot turn on the radar preview. I see only some strange vertical lines. Is it only my issue with my graphic card (AMD Radeon HD5770)? EECH 1.16.1
I think this might be a bug. The Havoc engine bars were added back into the 3D cockpit, and the way they were drawn was updated for this to work. So I think it might be a case that the glass cockpit wasn't updated in the same way. The Havoc doesn't have MFDs like the Apache etc, it uses the cockpit texture for the gauges, and then draws the bars.
As for the radar, it's probably just not been implemented in the glass cockpit.
Hi everyone, I have EECH 1.16.0 and when I start a Free Flight session the gunship is slowly and randomly rotating on the pad. This occurs for most gunships. I have spent hours trying to fix this but no joy. Once I get the bird in the air all is well and they fly just fine, So as long as collision remain OFF I can get it flying. Can someone please suggest a fix for this EECH 1.15.2 does not have this bug.
I have got the helos to stop spinning on the pad at the opening of free flight. By accident I found that these conditions stopped the spinning: Windows 7 Home Premium 64bit
1) if I had Chrome open and 4 tabs active (of the right type??) 2) If I have JoyToStick running and Suspend joystick processing was enabled.
So I have a FIX but it is ugly and it makes no sense and I found it by accident.
So I think some critical timing bug is right on the edge and other things running. Any help to actually address this bug is appreciated. (bouncing helos related??) ***** Has anyone else found and fixed this??
I have got the helos to stop spinning on the pad at the opening of free flight. By accident I found that these conditions stopped the spinning: Windows 7 Home Premium 64bit
1) if I had Chrome open and 4 tabs active (of the right type??) 2) If I have JoyToStick running and Suspend joystick processing was enabled.
So I have a FIX but it is ugly and it makes no sense and I found it by accident.
So I think some critical timing bug is right on the edge and other things running. Any help to actually address this bug is appreciated. (bouncing helos related??) ***** Has anyone else found and fixed this??
This sounds more like a driver issue with your controller than anything to do with EECH. If you're using a 3rd party app to change the input behaviour. I don't know why having Chrome open would make any difference.
Originally Posted by diesel
I tried the VSynch: Adaptive in my NVidia settings- no go. NVidia settings almost don't work at at all, what incompetence is this??
Hi everyone, I have EECH 1.16.0 and when I start a Free Flight session the gunship is slowly and randomly rotating on the pad. This occurs for most gunships. I have spent hours trying to fix this but no joy. Once I get the bird in the air all is well and they fly just fine, So as long as collision remain OFF I can get it flying. Can someone please suggest a fix for this EECH 1.15.2 does not have this bug.
Have you tried using 1.16.1 to see if it still happens? A lot changed between 1.15.2 and 1.16.1.
Curious as to why EECH always with crosscoupling on when you disengage autopilot takes a split second for the crosscoupling to actually engage, causing a yaw. If you turn crosscoupling off, you'll notice what's going on in the former.
WOW! Translational Lift value is reversed when FM 2 is in use -- on is off, off is on and explains some of the FM 2 lift issues since at least 1.15.2 -- not to mention way too weak in FM 2 now even when you activate it with OFF. Just as notable, though, is that ground effect has always been too weak in all the EECH FMs.
You already know the Hokum yaw is too weak in FM 2 and about twice what it should be in FM 0 & 1.
In FM 2 I'm also getting bizarre yaw and rolls when trying to taxi in a Comanche with the wheel brakes off that's basically making it impossible to do a proper taxi... maybe an issue with this wheel suspension mod stuff.
1.16.1 has some crashes, but not the repeatable one that happens in 1.16.2 when I roll inverted in a Comanche on some maps.
The previous/next target both cycling in the same direction bug is also present in 1.16.1, so might be quite old.
Edit:
Putting the main rotor lift to at least dmrl=1.1 in the EECH.ini when FM 2 is in use seems to have met the minimum single-engine lift requirements for many of the helos just barely with an average loadout, without wildly increasing ceiling and top speed. In fact, it seems to approximate published Comanche dash speeds when briefly at 100% torque on two engines in level flight now. At dmrl=1.1 even the Hind can just barely make it back to base on one engine without starting on fire most of the time, which is a pretty good litmus test, I think. It's still a problem with max gross weight situations, though, and we'd need a jettison stores function for this alone to be sufficient. I suppose next is further dealing with the taxi wheel rolling problem, fixing the still-anemic translational & ground lifts and coaxial yaw rates, and raising the speed for when turn coordination begins kicking in remains on FM 2 to be at least as good as FM 0 & 1, but with the added nifty new RPM effects and proper turning at speed. I am also curious about what the global air density modifier does, as adjusting that solely before made zero difference on the IGE + ETL problem during failure of one of two engines that I could tell.
Edit:
The dyn files are not increasing the coaxial yaw rate except on the helix, which seems to be just an Apache A with a cosmetics job. While on FM 0 & 1 the EECH.ini dynamics stuff does something, nothing except the main rotor lift line seems to do much on FM 2. Regarding FM 0 & 1, the tail-related dynamics stuff in the ini is having some bizzare effects on lift that's completely unrelated to the tail, and the drag one oddly increases coaxial rotation rates on the Hokum and Shark. I believe some of the problem with all the FMs is the result of an attempt in the code to do a yaw damper with inherent tail drag, but obviously if tail values are also weirdly affecting lift then there are some bigger problems at play.
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)
2.1 Ground Effect actually seems to increase in the sim, at least in FM 0, the faster you go. I believe this is related to the main rotor pivot drag being decreased to 0.1 and the tail rotor drag in forward motion being at 10.0 in my ini, which is necessary for a variety of other reasons. You should actually get more GE the slower you go (and the lower you go, of course, with no significant GE with the rotor disc one rotor disc diameter from the ground), such that at RBS speed you get no significant benefit from GE. ETL does eventually slightly decrease if you go extremely fast, but this is mostly drag overtaking the effect, and by then you're close to RBS again, anyway.
3. Muted yaw on coaxials in FM2 needs fixing next. Makes them and much of FM 2 basically unusable right now.
4. Fix rotor brake engaging when you jump into an aircraft already in flight. 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. *Another method: https://SimHQ.com/forum/ubbthreads.php/topics/4555477/re-crosscoupling-poll#Post4555477
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. *This can be replicated by going into a Comanche in 1.16.2 in a campaign (Cuba, Afognak, so far), ASE page showing, turning on the helmet mounted sight, cycling to padlock targets with prev/next target, and rolling.
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 currently 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. Like to have random oscillations and vibration when near and behind other aircraft, based on front aircraft's size (total weight as proxy).
15.93. At highest altitudes, low density, and/or high temperatures, the engine compressor stages should reach their limits before you overtorque. Compressor stage performance is the limiting factor of max cruise altitude, not torque. Obviously at lower altitudes and temperatures, the current method of over torquing first is appropriate.
15.94. The Kiowa may have its RBS happening slightly too soon but definitely has way too much power such that it's very easy to reach the never exceed speed. Some of its analog dials are also giving wrong quantities..
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 wish list 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 or air strikes don’t seem to be working. Not sure if that’s actually a bug or just a misperception on my part. *Correction: Artillery calls requests work sometimes in Taiwan! Any other campaigns? Air strikes?
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. *Correction: Yes, bug from the beginning it looks like.
26. Escorts are 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. *Seems to work. I will also include my latest ini again, but the recon fix is in this GWUT1162e.csv file.
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.
source code for Comanche, SupCobra, SeaCobra, and Viper: #define NUM_CANNON_ROUNDS (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. Turn to target with H in EO display and target locked should work even when there is no target locked, even when not in hover, and needs more yaw authority.
48. Damaged hydraulics could gradually degrade based on how much change occurs in the flight controls, from one extreme of that axis to another as the above added vibration characteristics would be tracking. More gradual and slight control changes, such as slower banks, would cause less reduction of hydraulic pressure over time. A hydraulics page could show pressure. As pressure decreases there could be more control delay. As controls are moved, pressure gradually reduces. Damaged hydraulics can cause a tendency for the pilot to try to overcompensate which can cause pressure to drop even faster. When hydraulics are damaged, it is essential to be gentle with the controls and patient with the response of the aircraft to preserve control authority until RTB and landing.
49. A pilot roster and search & rescue operations.
50. Smarter overall AI with AI pilot skill that improves over time with experience.
51. Be nice if AI didn't fly through trees, even though they are invulnerable to them.
52. EO system keeps randomly unlocking targets, also seems low-capability on some helos.
53. Ground stabilization doesn't seem to be working well even when set to 1 in the ini. *Correction: you need to use Ctrl+S, though it isn't as strong an effect as locking to the ground.
54. SAMs have an infinite magazine. That's a problem. Perhaps have a finite number, a reload of that number at an interval dependent on distance from nearest large base, and the frequency that missiles are launched determined by how many the unit has.
55. A finite number of persons, especially infantry, and medevac missions to nearest big bases is a long shot wish. Seems appropriate with many bodies around FARPs sometimes. Maybe remaining infantry should be doing something... running or attending to them.
56. The more times you've over-torqued or rolled or looped inverted in a flight, the longer the maintenance turnaround time is for the helo after RTB and ending flight.
57. Ctrl+J appears to cause eject in Hokum B right now in F12 viewer.
58. The launch HUD symbology on the Hokum B should not be shifting when you look down to see the whole cockpit.
59. Radio menu to set NDB frequency required to change for FARPs and airfield communication.
60. Some trees don't show up in NVG/FLIR, but obviously you can still crash into them.
61. Make the Comanche in FLIR when still living or freshly wrecked gray instead of fully white.
***
The lopsided power-curve on all FMs, weak translational lift on FM 2 (even set to off to activate it), and broken taxiing on FM 2 continue to make it difficult to recommend as the default flight model, which is why I continue to recommend crosscoupling on and using FM 0.
I have determined the ini setting of drv = 0.2 allows FM 0 with Hokum B to be used without a yaw divider or additional source code changes (reduce yaw authority inversely with speed or allow it directly proportional to speed), but unfortunately this makes the Blackshark useless until it's changed back. It also doesn't seem to help the Hind. The coaxials in FM 0 appear to use the drag 'rudder' value as a kind of coaxial differential that governs max available yaw rotation, and the Hokum B in FM 0 is tuned too high and the Blackshark is tuned too low. Keeping this low for the Hokum B isn't that terrible for the tail rotor helos, except that it's as if they have no yaw damping channel. A 0.3 or 0.4 might be a good compromise, but still breaks the shark. 0.5 for FM 2 isn't so bad and only makes the Comanche a little touchy, but still does nothing for the Hokum B.
The dyn files seem to have no significant effect on the actual flight dynamics that I can tell. The ones in the dynamics folder are supposedly for FM 0 & 1 and the ones outside it are for FM 2, but I see little to no indication they are actually used. FM 1 is obviously also ceasing to include yaw weathervaning at all and this is hard coded into the sim, so there's precedent for thinking other flight dynamics are currently hard coded now instead of largely using the dyn files.
One other interesting aspect of FM 2, though, is that it does have better yaw weathervaning for tail rotor helos than FM 0 does. FM 0 only exhibits this on the Hokum B at all speeds. FM 0 tail rotor helos actually tune this effect mostly out once you're going above about 60 KIAS, which is weird. That tune-out effect is what should actually be happening for the coordinated turning below about 60 KIAS. Anyway, FM0 tail rotor helos above 60 KIAS do this weird thing where using the pedals sluggishly just yaws you and you mostly stay at that new heading without much wobble back at all towards the direction you were in. I suppose we could just chalk that up to the faux AFCS system at work, but the fact FM 2 tail rotor helos do it more accurately (for the most part) is very interesting. FM 2's weathervaning in the yaw is also very dependent on the helo, with the Comanche having the least and allowing substantially more side slip flight... even if the auto turn coordination makes it difficult to do well.
Last edited by Reticuli; 06/11/2109:59 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.
NVidia incompetence - I have never got the settings per game to have any effect, specifically AA override. Also cannot edit or remove any games on the list, real buggy.
NVidia incompetence - I have never got the settings per game to have any effect, specifically AA override. Also cannot edit or remove any games on the list, real buggy.
In Windows 10, there's a notice on the control panel that it's now managed by Windows graphics settings, so seems like they ditched support for it.
Hi all, I've been playing EECH since it was released back in the day.
After rebuilding my gaming PC right before the hit of COVID last spring, I've been trying to get this game playing reliably/correctly. I just picked up a X52 Pro, and installed the game.
I'm running into several confusing issues. I did a clean install and followed the installation directions HERE.
#1 My wingmen just explode randomly. This happens EVERY MISSION during a campaign (Taiwan, War of Independence).
#2 Waypoints are reset to W and W only mid-mission. This is EXTREMELY FRUSTRATIING. This happens EVERY MISSION during a campaign (Taiwan, War of Independence). Once on the way back to base, after the waypoints re-set to W - I tried cycling the waypoints again, and found the original waypoints had been reinstated as mysteriously as they had disappeared in the first place. That one time has not been repeatable. Is there anything that can be done to prevent this??
#3 I have a 35" widescreen monitor - 3440x1440 native resolution. Under Display Options 3440x1440 IS selectable - but selecting it will cause an immediate CTD. The game will play at 2560x1080.
#3a While playing in 2560x1080 textures and models look fuzzy and heavily aliased. Could there be an issue with the mods, or is it just an issue of an aging game engine? (With my old 1080p display, I remember EECH being much 'crisper' with the newer versions of EECH+mods). I have an RTX 2060 Super, and in the Nvidia Control Panel I have all Anti-aliasing settings and Ansiotropic Filtering set to maximum quality, overriding any appliaction settings.
#4 When I first installed the game my X52 Pro worked perfectly after running through the basic contoller set up in EECH. For some reason out of the blue, now the Z-rotation on the stick mimicing/replaceing the rudder now pegs all the way left. In Windows all flight stick/HOTAS calibration/test settings work perfectly. I've had to disable the controllers using rudder entirely and am using the keyboard for rudder control.
Any help would be greatly appreciated.
Please let me know if debug logs, etc. would be of help!
Invalid list type (entity type = ENTITY_TYPE_SOUND_EFFECT, index = 14144, list type = LIST_TYPE_GUIDE, file = J:\EECH\git\eech-master\aphavoc\source\entity\system\en_funcs\en_list.c, line = 334)
#1 My wingmen just explode randomly. This happens EVERY MISSION during a campaign (Taiwan, War of Independence).
You need the 1.16.2 update. There was an issue with them running out of fuel
Originally Posted by ORCRiST
#3 I have a 35" widescreen monitor - 3440x1440 native resolution. Under Display Options 3440x1440 IS selectable - but selecting it will cause an immediate CTD. The game will play at 2560x1080.
It's a really old game, and probably not playable at that resolution. You could switch on debug log in the eech.ini and see if it gives an error when it crashes, or run the debug.exe.
Invalid list type (entity type = ENTITY_TYPE_SOUND_EFFECT, index = 14144, list type = LIST_TYPE_GUIDE, file = J:\EECH\git\eech-master\aphavoc\source\entity\system\en_funcs\en_list.c, line = 334)
Invalid list type (entity type = ENTITY_TYPE_SOUND_EFFECT, index = 14144, list type = LIST_TYPE_GUIDE, file = J:\EECH\git\eech-master\aphavoc\source\entity\system\en_funcs\en_list.c, line = 334)
I got this error while firing cannon in Comanche.
Does it happen every time?
************************************ FATAL *********************************** Invalid list type (entity type = ENTITY_TYPE_SOUND_EFFECT, index = 14144, list type = LIST_TYPE_GUIDE, file = J:\EECH\git\eech-master\aphavoc\source\entity\system\en_funcs\en_list.c, line = 334) ************************************ FATAL *********************************** Invalid list type (entity type = ENTITY_TYPE_SMOKE_LIST, index = 21218, list type = LIST_TYPE_TASK_DEPENDENT, file = J:\EECH\git\eech-master\aphavoc\source\entity\system\en_funcs\en_list.c, line = 334)
Yes. I repeatly get these two errors in the exact same situation : Firing 20mm cannons at multiple vehicles and infantries at Enemy FARPs as comanche. but it doesnt happen always, just sometimes. Do you have any clue what these errors mean ?
I didnt install any mods other than 1.16.1 patch and 1.16.2 patch.
Invalid list type (entity type = ENTITY_TYPE_SOUND_EFFECT, index = 14144, list type = LIST_TYPE_GUIDE, file = J:\EECH\git\eech-master\aphavoc\source\entity\system\en_funcs\en_list.c, line = 334)
I got this error while firing cannon in Comanche.
Does it happen every time?
************************************ FATAL *********************************** Invalid list type (entity type = ENTITY_TYPE_SOUND_EFFECT, index = 14144, list type = LIST_TYPE_GUIDE, file = J:\EECH\git\eech-master\aphavoc\source\entity\system\en_funcs\en_list.c, line = 334) ************************************ FATAL *********************************** Invalid list type (entity type = ENTITY_TYPE_SMOKE_LIST, index = 21218, list type = LIST_TYPE_TASK_DEPENDENT, file = J:\EECH\git\eech-master\aphavoc\source\entity\system\en_funcs\en_list.c, line = 334)
Yes. I repeatly get these two errors in the exactly same situation : Firing 20mm cannons at multiple vehicles and infantries at Enemy FARPs as comanche. but it doesnt happen always, just sometimes. Do you have any clue what these errors mean ?
I didnt install any mods other than 1.16.1 patch and 1.16.2 patch.
Which map is it on?
Does it happen on other maps?
Does it happen when you fire the cannon, or when the shots hit the target?
Invalid list type (entity type = ENTITY_TYPE_SOUND_EFFECT, index = 14144, list type = LIST_TYPE_GUIDE, file = J:\EECH\git\eech-master\aphavoc\source\entity\system\en_funcs\en_list.c, line = 334)
I got this error while firing cannon in Comanche.
Does it happen every time?
************************************ FATAL *********************************** Invalid list type (entity type = ENTITY_TYPE_SOUND_EFFECT, index = 14144, list type = LIST_TYPE_GUIDE, file = J:\EECH\git\eech-master\aphavoc\source\entity\system\en_funcs\en_list.c, line = 334) ************************************ FATAL *********************************** Invalid list type (entity type = ENTITY_TYPE_SMOKE_LIST, index = 21218, list type = LIST_TYPE_TASK_DEPENDENT, file = J:\EECH\git\eech-master\aphavoc\source\entity\system\en_funcs\en_list.c, line = 334)
Yes. I repeatly get these two errors in the exactly same situation : Firing 20mm cannons at multiple vehicles and infantries at Enemy FARPs as comanche. but it doesnt happen always, just sometimes. Do you have any clue what these errors mean ?
I didnt install any mods other than 1.16.1 patch and 1.16.2 patch.
Which map is it on?
Does it happen on other maps?
Does it happen when you fire the cannon, or when the shots hit the target?
I was playing Alexander archipelago FJORD WAR campaign. the error both happened while firing or after firing so it might be happening when the target is hit.
I'll see is it happening in other maps as well, but if this error is not related to maps it might happen in same way.
I didnt installed new voice MODs before, but when I included it when reinstalling the game this issue didnt happen anymore when I repeatly playing FJORD WAR campaign.
I think the modders modified the game to be worked with their new voice mods and it caused the game to be broken with default voices.
Sorry, but you won't get any further help from Messyhead as he has stopped working on the game and has actually left the forum due to the attitudes and comments of some of the members. In particular Banita who, in my opinion, was really offensive to him.
All I can think of is - do you have OpenAL installed ? I know that is required for the new sounds. I think it is automatically installed with the 1.16.0 upgrade.
#4 When I first installed the game my X52 Pro worked perfectly after running through the basic contoller set up in EECH. For some reason out of the blue, now the Z-rotation on the stick mimicing/replaceing the rudder now pegs all the way left. In Windows all flight stick/HOTAS calibration/test settings work perfectly. I've had to disable the controllers using rudder entirely and am using the keyboard for rudder control.
You can't select the axis you want, say, like the X52's stick twist, in the Controls screen? You previously had to mess with the ini for that, but now you should be able to assign in-sim. You can even test it on-screen.
Originally Posted by Hijongpark
I didnt install any mods other than 1.16.1 patch and 1.16.2 patch.
You realize you need to install 1.16.0 first after the stock version, right? I skipped that step after reinstalling recently and had a bunch of errors until I re-installed properly. The only consistent CTD/freeze I get now is Comanche + ASE page + HMD padlocking + rolling, which incidentally is a pretty common set of conditions when flying a CAP in a Comanche, but if I just flip away from the ASE when dog-fighting in the Comanche or don't use the HMD at all in that same bird then it won't happen and 1.16.2 is fairly stable now.
Last edited by Reticuli; 05/29/2101:47 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.
I found that some trackIR axes are not working in each helicopters.
Only comanche has all moveable axes,
Apache has no roll, Viper and other helicopters have no x,y,z.
I've just started using TrackIR, having finally bought a IR clip and converted my PS3 camera. It's works really well.
I'll check out the axes in those helos, I tried a few and thought it was ok. One thing I did find is the pitch up and down seems to be limited, so I'll see if I can fix that.
Finally get a consistent crash again every time trying to enter any Cuba campaigns using DEBUG1162.exe. Disabling the current game.cfg, EECH.ini, GWUT, and playersv.bin with appending bck to their names had no effect on this. I was briefly able to get into these campaigns with the COHOKUM1162.exe but then it froze and wouldn't let me back in.
deleted
Last edited by Reticuli; 06/01/2104:58 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.
Can you just attach the debug log instead of copying/pasting?
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.
Finally get a consistent crash again every time trying to enter any Cuba campaigns using DEBUG1162.exe. Disabling the current game.cfg, EECH.ini, GWUT, and playersv.bin with appending bck to their names had no effect on this. I was briefly able to get into these campaigns with the COHOKUM1162.exe but then it froze and wouldn't let me back in.
deleted
This is only happening in the Debug exe (I tried it too). Does it happen with the cohokum1162.exe for you? I tried it with cohokum1162 and it didn't crash.
If it's only the debug exe, then I don't think it's too big a deal, as that is only for testing.
Finally get a consistent crash again every time trying to enter any Cuba campaigns using DEBUG1162.exe. Disabling the current game.cfg, EECH.ini, GWUT, and playersv.bin with appending bck to their names had no effect on this. I was briefly able to get into these campaigns with the COHOKUM1162.exe but then it froze and wouldn't let me back in.
deleted
This is only happening in the Debug exe (I tried it too). Does it happen with the cohokum1162.exe for you? I tried it with cohokum1162 and it didn't crash.
If it's only the debug exe, then I don't think it's too big a deal, as that is only for testing.
Eventually it crashes in Cuba in the non-debug version, which is why I was trying to run the debug version to find out why.
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.
Is it the same error in the main exe? You can enabled debug_log in the ini file
Looks like it.
Edit:
Yep. Just got another freeze/CTD with the non-debug version. Definitely the same thing. Happened on a recon mission right before getting to the X way point with enemy choppers in the distance. Flying a Comanche in Cuba. This time, this is all that's inside the debug_log.txt:
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.
Is it the same error in the main exe? You can enabled debug_log in the ini file
Looks like it.
Edit:
Yep. Just got another freeze/CTD with the non-debug version. Definitely the same thing. Happened on a recon mission right before getting to the X way point with enemy choppers in the distance. Flying a Comanche in Cuba. This time, this is all that's inside the debug_log.txt:
Ok, thanks. I'm not sure how the terrain code all works, so I'll see if I can figure out what's going.
Also, just fyi, the file path is a red herring as that just comes from the project map that's made when the code is compiled, and uses local paths when it's compiling. This is the relevant bit \modules\3d\terrain\terrmap.c:1692
Is it the same error in the main exe? You can enabled debug_log in the ini file
Looks like it.
Edit:
Yep. Just got another freeze/CTD with the non-debug version. Definitely the same thing. Happened on a recon mission right before getting to the X way point with enemy choppers in the distance. Flying a Comanche in Cuba. This time, this is all that's inside the debug_log.txt:
Ok, thanks. I'm not sure how the terrain code all works, so I'll see if I can figure out what's going.
Also, just fyi, the file path is a red herring as that just comes from the project map that's made when the code is compiled, and uses local paths when it's compiling. This is the relevant bit \modules\3d\terrain\terrmap.c:1692
Hah hah, even our debug loggers have bugs.
Last edited by Reticuli; 06/03/2101:37 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.
Overflow unsigned float value type: FLOAT_TYPE_AMPLIFICATION, width 6, int value: -2147483648, float value: -55383967303831262107000000000000.000000 Overflow unsigned float value type: FLOAT_TYPE_AMPLIFICATION, width 6, int value: -2147483648, float value: 10357831077597636877000000000000000000.000000 Overflow unsigned float value type: FLOAT_TYPE_AMPLIFICATION, width 6, int value: -2147483648, float value: 34828591921517165334000000000000.000000
Right now, though, it keeps freezing at the end of a P.R. campaign mission, also in a Comanche, but after sinking a ship in a very long stealthy mission as I was coming into land just as I pass the middle of the airfield. No debug error logs for this one, though. Happens at exactly the same spot when I bank just slightly over the field. I got no freezes for hours, though, flying as just a Hokum A and B on the red side.
Edit: If I just stay at the outside of the airfield and I land like just outside the taxiways I'm fine and it doesn't freeze. The biggest issue seems to be flying over the middle of the runways. Also if I back out of the helicopter and I in the mission, it will just fly around a circuit above the helicopter area and then land and it's still fine.
Last edited by Reticuli; 06/07/2102:13 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.
guys please help. I can't change anything in the options menu except graphics. When i click "options", all the other settings are missing and only the graphics menu shows up. also, the mouse cursor leaves a trail when i move it and i can't exit the menu. i've tried changing graphics drivers and graphics settings in my crontrol panel but nothing works. i've also tried different compatibility settings and running as administrator. please help
I have issue with latest version, throttle is always reverse, I tried correct EECH.ini and Control in game options not helped, I have Logitech Extreme 3D pro. Can Somebody help me?
Game crashes for me in campaigns after flying on missons say for 30m it simply freezes then CTD. This is 161.1. I wish this could get fixed,frustrating.