Hi folks. I've created this thread to try and collate all of the various mods and requests that are spread about the forum in different threads and posts. I think a lot of great work and information has been lost or forgotten, so this thread is to try and act as an index and quick reference to where those are. I've personally got a long list of threads in my subscribed list that relate to previous features that either never got finished, or were never included in a release.
It should hopefully also act as a tracker for when things get added to EECH.
I'd like there to be some rules for what goes in here though.
1. Don't go off topic. By that I mean, don't get into drawn out conversations about what should/shouldn't be in EECH, or fixes that could be done etc. If posts are made that go that way, then they'll be deleted.
2. If you want to discuss a particular mod that is linked from this thread, then please do so in a new thread, or in the original thread for that mod.
3. Please don't use this as a place to raise bug reports.
4. If you'd like to request a feature, first do a search of the forum to see if it has been requested in the past and link to that thread. If it hasn't been discussed in the past, then post the feature you'd like to see.
5. As per 4, but for bug fixes. There are many bug reports in various release threads already on the forum. If your bug has been raised already, then link to that bug report thread.
6. If you want to raise a feature request or bug, please start a new thread and then post in this thread linking to the request. The first post will be edited to include this so it continues to work as an index. That way all discussion regarding the request can be kept in the separate thread.
Havoc gauges missing in v1.16[/url] -Fixed. Available in 1.16.1.
KA-52 Alligator drops shadow through the flight-deck of the carrier at the sea. This only happens with AI versions of the KA-52, not the one you fly yourself (theater was Georgia)
Fix status and warning lamps in Havoc cockpit - Fixed. Available in 1.16.1.
KA-50 External door animation doesn't work
Feature Requests - to be added with "official" releases
Found a small bug in 1.16.0 while testing my KA-50 model:
- KA-52 Alligator drops shadow through the flight-deck of the carrier at the sea. This only happens with AI versions of the KA-52, not the one you fly yourself (theater was Georgia)
While working at the KA-50 I noticed that the cockpit door animation for this helo isn't working. In the scene file the animation works but in the game neither alt + c (cockpit door) nor or shift + c (cargo door) does anything.
While working at the KA-50 I noticed that the cockpit door animation for this helo isn't working. In the scene file the animation works but in the game neither alt + c (cockpit door) nor or shift + c (cargo door) does anything.
1. Find a way to add new objects into BED editor (scenario/campaign editor). http://eech.robfox.net/utils.html Currently object list is closed and new added objects to game code can't be added with editor This can really improve quality of maps. I tried to contact BED maker years ago - no success.
2. Upgrade of existing tool to place trees on map. I'm not programmer and it's hard to me to uderstand how it works. It's included in source code pack at: http://chambcra.freeshell.org It was designed to work with grand canyon map but maybe will be possible to use it for any existing map. I tried many times to usethis tool - only thing I can acheive was trees floating in air.
I would like to Fix the Altitude Hold so it works properly.
Currently, terrain following using Altitude Hold doesn't work. You engage it and it over-corrects or under-corrects as you fly and your altitude varies all over the place. A real helicopter behaves differently. I'm a Mechanical Engineer. I've built and programmed simulators myself which were infinitely more stable than EECH is. EECH appears to use a defective proportional feedback loop. It should be using a full PID (Proportional-Integration-Differentiation) loop. I think the original programmers weren't versed in the physics and simply didn't know how to program it properly.
We can fix it. The input parameters are available within the program, you need three things: the current radar altitude, the current vertical velocity, and a time code for reference. The correction calculation is used to adjust the Cyclic to move the helicopter towards the correct altitude and keep it there without overshooting. That behavior is called Critical Damping. Currently there is very little damping at all, which is why it over corrects and hits the ground a lot.
Is there anyone on the team who can direct me in the code to the correct subroutines so I can dig in and take a look at it under the hood?
I would like to Fix the Altitude Hold so it works properly.
Currently, terrain following using Altitude Hold doesn't work. You engage it and it over-corrects or under-corrects as you fly and your altitude varies all over the place. A real helicopter behaves differently. I'm a Mechanical Engineer. I've built and programmed simulators myself which were infinitely more stable than EECH is. EECH appears to use a defective proportional feedback loop. It should be using a full PID (Proportional-Integration-Differentiation) loop. I think the original programmers weren't versed in the physics and simply didn't know how to program it properly.
We can fix it. The input parameters are available within the program, you need three things: the current radar altitude, the current vertical velocity, and a time code for reference. The correction calculation is used to adjust the Cyclic to move the helicopter towards the correct altitude and keep it there without overshooting. That behavior is called Critical Damping. Currently there is very little damping at all, which is why it over corrects and hits the ground a lot.
Sounds good, nice to have someone who has real world knowledge to add to the game. I'll PM you details of how to access the code.
Originally Posted by Javelin
Is there anyone on the team who can direct me in the code to the correct subroutines so I can dig in and take a look at it under the hood?
As to where the actual code for that is in the repo, I'm not entirely sure. You'd have to check it out and see what you can find.
Does anyone else find it annoying that when you start a mission, all of the comms channels play at the same time, and it's just a garbled message, or is it just me ?
I'm thinking I might add a rule that if you're landed, only the ATC plays, so you only hear that message at the beginning of missions.
I might also see if I can add a delay between messages if multiple channels are enabled so you don't get multiple messages playing at once.
I do not recommend to apply any artificial delays to the messages, as it done already and usually works properly. If this bug appear only when game is just started, original issue should be fixed instead. Fair solution will be mute radio transmissions if there no electricity power (Ctrl+K), but it can affect only the case, when manual engine start up is enabled. Or - like you said - decrease radio receiving radius when helicopter is landed, it may solve the issue but doesn't cause problems for the player, also add some realism.
Player receive not all messages on the map, but only from near units and aircrafts. Technically, this distance can be decreased 4 times for example if helicopter is landed, so there is good chance that only ATC and near helicopters will be heard.
right, where to start, I used to mod SH4 but don't know how to mod this game. I am also playing the 1996 Hind game, which is in my humble opinion, still superior to the hind in eech. There is a clever copilot aiming for you but what I really like is that you can fire the gun like the Apache's and Comanche's in EECH : look and shoot - could'nt someone clone the part from those helos and sport them over to the Hind ?
I also think that in RL they are really more durable/protected than ingame : you get shot down too easily even in novice mode I think
her's what it can carry :
Air-to-ground weapons - for use against ground targets
9M114 Shturm (AT-6 ‘Spiral’) air-to-ground missile S5 57mm rockets S8 80mm rockets FAB250 & FAB500 general purpose bomb OFAB500 blast fragmentation bomb FAE-500 fuel air bomb KMGU-2 area denial mine dispenser Yak-B four-barrelled 12.7mm turret-mounted machine gun UBK-23/250 cannon pod
Air-to-air weapons - for use against other aircraft
Hi all! I have a Feature Request: If someone can - fix joystick controls. I mean, setting up axis curves, Dead zones, joystick buttons mapping. At the moment, the controls in EECH remained in 1998, this greatly reduces the pleasure of the flight. I think the main thing in the simulator is the controls.
I think we should be able to do something about the controls. I don't think it's ever been really taken on. I remember seeing in the code some uncompleted work on key mapping.
Also, there was some work done on the deadzones, but never really finished.
It's good if we add new models to fly, and improve existing ones. But if the flying experience is no good, then there's no point.
A couple of comments. Customizable joystick response curves? Interesting idea, difficult to program. There are already apps out there to do that. Here's a free one:
I've also modded the automated controls in the sim so Altitude-Hold and Hover-Hold work now. I use Altitude-Hold all the time which takes over the collective making the helicopter very easy to fly, all you have to do is steer unless you go into radical moves to avoid weapons fire. I don't really notice the lack of an adjustable dead band in the joystick at all any more. You can download the mod here:
For remapping keyboard commands I have a copy of AutoHotKey, which is free, which remaps the keyboard and allows for remapping multiple key combinations and sequences to do anything you want. It does more than you want, though. There are simpler apps out there. I also have another app that maps joystick presses to keyboard combinations, JoyToKey. There are lots of ways to remap the game controls without resorting to reprogramming the sim. The in-game key commands are located in scattered sections of the code, they aren't all in one place. Joystick controls are also scattered around the code. With so many different controls possibilities, redoing that would take quite a bit of work. It can be done, but most avid players have already resorted to an external remapping app to get what they want. I've resorted to using a pair of Cougar MFD button frames (about $50). They easily remap any keyboard button command to a button on the MFD frame so I don't have to remember them. I've found that makes it infinitely easier for me to fly that way. I put all the important stuff on the Cougar MFD, I haven't even bothered to remap anything else with a keyboard app.
When I'm back from holiday, I'll look at the keymapping. I remember looking into it a few years ago, and had some thoughts on how it could work. If it's ok Javelin, I'll PM you with some ideas.
I get there are programs to allow this, but it would be good to have it as part of the sim.
I think the deadzone issue might need addressed though if it's more of an issue.
Customizable joystick response curves? Interesting idea, difficult to program.
response curves are optional, I can do it in the joystick software, but the main thing for me is to remove the dead zones and make mapping, if possible.
Quote
I've also modded the automated controls in the sim so Altitude-Hold and Hover-Hold work now. I use Altitude-Hold all the time which takes over the collective making the helicopter very easy to fly, all you have to do is steer unless you go into radical moves to avoid weapons fire. I don't really notice the lack of an adjustable dead band in the joystick at all any more. You can download the mod here
I use it, thanks)
Quote
For remapping keyboard commands I have a copy of AutoHotKey
I don't like to use external mapping programs.
Quote
You said a couple of buttons are hard-coded that you can't reassign. What buttons are those? We might be able to fix those ones.
Ah. You want to re-map the Joystick buttons. That's different.
I went searching for the commands and found then in the code, at least the joystick part of it anyway. There are duplicate keyboard functions. co_avevn.c assigns joystick_button 1,2,3 hm_avevn.c (and all the other helicopter type files) assigns joystick_button 4
Here's a thought I had the other day... Is anyone interested in flying the fixed wing aircraft in EECH? I could write a physics engine for them, generic and modular, so we could set up the physics via a text file like they've done for all of the helos. It wouldn't be too exacting, but close enough to be fun. Anyone want to donate a generic 3D cockpit for it? Or we could just steal one from one of the helicopters. Any interest there? Just curious.
It would be interesting to be able to fly the planes. However, personally, I think there's things with the helo sim that need worked on and improved first. The airplane sim could distract from those things.
The key to precise control is a high quality Joystick, or do you have a more specific problem?
my problem is large dead zones that can't be reduced to 0, and the lack of mapping buttons in the game, as third-party software does not always work with multiple devices. I have a VKB Gunfighter MCG + handmade throttle and KA-50 collective. This devises have a high quality, so I don't like that I can't realize their precision potential))
In all people steering work smooth,precisely and great. Never remember any complain about dead zone.Only you have problem. so,where is problem- in game, or with you hardware/software? The same about buttons. You not have good software for remapping, and you want change code in game.
Hi Bunik,. I can see in the code where some joystick types are assigned a deadzone of 20%. Does that sound about right for your setup? I might be able to fix that, I'll give it a shot this weekend.
The dzd setting is used in the code in the cyclic section, but the 20% setting is applied before that.
I don't think people should be restricted by the controller they choose. The code shouldn't dictate things like deadzones, in my opinion. These should be 100% configurable, probably from the eech.ini to suit whichever controller is being used.
Keymappings are a different story. It would be great if they could be 100% reassigned, but I think that would be a lot of work.
With such arguments the discussion is unfounded ,good luck.
What arguments do you need? dead zones can be seen when you adjust the axis of the joystick. I see a 15-20% dead zone in the center! or do you think I'm trying to joke?)) about buttons - I prefer to use a minimum of third-party software, and in order to reassign buttons I prefer to quickly go into the "options" and do it, rather than close the game and set up a remapper! And yes, I have been using remappers for 6 years now.
Hi Bunik, Go download the package under the "MFD Export Upgrades" thread, it contains cohokum_test_15.exe which has your joystick fix in it. Test it for me and let me know if it corrects the DeadZone problem you're having.
Excellent, that's great to hear! I tested it out on my joystick too, and it worked just fine and didn't affect anything. Mine was working before the change.
I'm just glad the fix worked, so now all the people who wandered away from EECH because their joystick didn't work can come back. Maybe I should set up a new thread on that, this thread isn't the one those people would see.
Found another bug in apache. with lighting, only occurs in midnight, all others are fine.I tried to make glare shield lighting, I made uvmap, I made a light texture, I set the luminosity to 100% and the highlight is visible. During the day, in the fog, in the evening, only completely dark in midnight. there is no proper lighting in midnight. on the screen how looks all day long.in midnight is completely black.
the RAH-66 was capable of internally carrying 6× AGM-114 Hellfire air-to-ground missiles, or 12× AIM-92 Stinger air-to-air missiles, or 24× 2.75 in (70 mm) Hydra 70 air-to-ground rockets, which would be evenly divided between a pair of retractable weapons pylons. Beyond storing munitions internally, the Comanche could also mount external stub wings to carry up to eight Hellfire missiles or sixteen Stinger missiles.
I would be great if we can get the regular RAH-66 we have now and this RAH-66 showing in the game as same model, no need to make modification to the way it looks, but with the bigger internal ordnance carry. but call it a RAH-66 B or something.
I'll start this by stating that I'm not any kind of Comanche expert. I just built a simpit cockpit for it.
As far as I'm aware there were only 3 launch rails on each side of the munitions storage doors. All others were carried on the detachable external hardpoints which basically destroyed your stealth capability.
I don't know where the Wiki got there information from though, so I may be wrong.
huh I thought about it. but with rendering engine we have now its pretty unrelistic. only option is rendering to texture but it reduce performance greately. like mirrors I have tried to make for Hind - fps drops twice.
Here goes my request, although I don't know how difficult it could be, even if it's feasible to implement....
I think it would be helpful to add more topographical detail in the planning map, I mean, more elevation contour lines at max zoom level. Don't you consider that right now the information it's very sparse even at max?. I think a typical topographical map could offer more information.
The maps in EECH are generated by the program. They are not outside rasters or pictures, but rather vectors and fill colors that are being drawn and easily zoomed in and out by the rendering engine. Bringing raster maps would be perhaps possible too, but then one needs to program and code all this in (as far as format goes) as well as the process of zooming moving, and maybe rotating.
The maps in EECH are generated by the program. They are not outside rasters or pictures, but rather vectors and fill colors that are being drawn and easily zoomed in and out by the rendering engine. Bringing raster maps would be perhaps possible too, but then one needs to program and code all this in (as far as format goes) as well as the process of zooming moving, and maybe rotating.
My request is more aimed to only add more vectorial elevation lines. I agree that adding a bitmap as background will be more complex.
Hi folks. I've created this thread to try and collate all of the various mods and requests that are spread about the forum in different threads and posts.
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.
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.
That's the master list I started building months ago when you asked me for a list, originally related to the FM. You did, after all, ask for this thread to be a master repository so stuff doesn't get lost.
I already found where the helo gun rounds are at in the code. I need to bring the Cobras and Comanches to 750 in it myself once I can fix my github captcha problems.
Originally Posted by bostar
My request is more aimed to only add more vectorial elevation lines. I agree that adding a bitmap as background will be more complex.
Make sure you guys use the normal map mode and not the paper version, I noticed the paper version was lousy.
campaign_map_mode=2 # campaign map resolution (1 = default resolution, 2 = high resolution) (def = 1) campaign_map_palette=1 # campaign map palette (1 = default shades, 2 = like paper map)
Anyone know what the GWUT values for rules_of_engagement (0, 1, 2) and engage_enemy (0, 1) values do?
Last edited by Reticuli; 05/28/2111:52 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.
Anyone know what the GWUT values for rules_of_engagement (0, 1, 2) and engage_enemy (0, 1) values do?
Rules of engagement is used for tasks, to determine whether or not the AI should destroy an entity or not. The types in the code are ROE_NONE (0), ROE_OBJECTIVE (1), ROE_ALL (2).
For None the rules are
Code
FALSE if aggressor is within target area (stop RECON missions from destroying objectives)
Retaliate if no-one else coming to assist, AND (mission complete OR aggressor in friendly territory)
For Objective, the rule is
Code
Retaliate if no-one else coming to assist, OR primary task completed
For All, it's always Retaliate.
I think engage enemy is used to determine whether or not a group is able to engage an enemy. It's used in the code for calling in strikes.
Thanks, but that's still a little confusing. Do you think that means if Recon is 2 and 1 for those values, respectively, that they will not destroy the objective and only engage specific enemies to defend themselves? I very frequently see Recon missions engage targets near the objective or en route and I'm wondering how necessary that is and whether different values in the GWUT for Recon would make them less likely to engage when not necessary. Obviously I don't want them shot down when attacked, though.
Last edited by Reticuli; 05/28/2110:11 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.
Thanks, but that's still a little confusing. Do you think that means if Recon is 2 and 1 for those values, respectively, that they will not destroy the objective and only engage specific enemies to defend themselves? I very frequently see Recon missions engage targets near the objective or en route and I'm wondering how necessary that is and whether different values in the GWUT for Recon would make them less likely to engage when not necessary. Obviously I don't want them shot down when attacked, though.
No, I think 2 and 1 would mean they always engaged an encountered enemy. Although it says Retaliate in the code comments, I think it actually means engage.
No, I think 2 and 1 would mean they always engaged an encountered enemy. Although it says Retaliate in the code comments, I think it actually means engage.
Now I'm even more confused.
Terms like "aggressor" and friendly units coming to "assist" all make me think it must differentiate between just encountering the enemy and being under attack by them. I also frequently hear over comms "x unit is under attack at such & such by so & so", that clearly the sim knows being under attack verses not being under attack rather than just detecting the enemy or not.
If engage_enemy isn't just a flag for whether or not you can call in artillery and air strikes (it may indeed be, I don't know), maybe that's instead the flag for offensive posture -- whether a unit actively seeks out the enemy to engage them regardless of whether that enemy is attacking that AI unit, which may include calling in strikes or attacking it themselves.
Anyway, I wonder how the AI determines if it will call in a strike or do the attack themselves independent of the above topics.
I assume available weapons and damage state also come into play as to whether they stay in the fight or evade/RTB.
Edit:
Seems to work. I will also include my latest ini again, but the recon fix is in this GWUT1162e.csv file.
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 think it would be helpful to add more topographical detail in the planning map, I mean, more elevation contour lines at max zoom level. Don't you consider that right now the information it's very sparse even at max?. I think a typical topographical map could offer more information.
Something that could be improved though based on data that exists in the sim already: water on the maps. They tend to show up as little discontinuous blotches instead of rivers.
I am curious as to what deficiencies you're seeing in the topology contours on the maps, though.
Last edited by Reticuli; 06/09/2103:25 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.
[quote=bostar] I am curious as to what deficiencies you're seeing in the topology contours on the maps, though.
Sorry for answering so late.
More than deficiencies I would say to add more information at max zoom level. An example:
I've taken this snapshots from the first SEAD mission in the Skirmish 1 of Lebanon:
The map:
I've done a fast mockup:
In my humble opinion, in this way your situational awarness increase a lot, particularly in this SEAD mission where the knowledge of the enviroment is the key to plan an attack. Recon missions is another case where this information is vital, having to stay so close to the enemy.
I think this would be necessary only at max zoom level for planning attacks or routes in hot zones. The other levels give you enough information for navigation with the actual settings.
But what does that actual topology look like in the sim for that spot? I notice the rivers are pretty uselessly represented on the coloration, but I've never noticed the topology contours being too sparse. Each line must represent a certain fixed elevation change, a kind of specific resolution of contours. It might be optimized for rugged terrain right now and not something like Libya, but off the top of my head I don't know what metric it uses.
Last edited by Reticuli; 06/12/2107:33 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.
Sorry for answering so late. In my humble opinion, in this way your situational awarness increase a lot, particularly in this SEAD mission where the knowledge of the enviroment is the key to plan an attack. Recon missions is another case where this information is vital, having to stay so close to the enemy.
I think this would be necessary only at max zoom level for planning attacks or routes in hot zones. The other levels give you enough information for navigation with the actual settings.
Have you tried setting the campaign_map_mode=2 in the eech.ini? This will give some more definition to the map, with smoother contour lines. I'm not sure it adds more though. I'm looking into the code for that area, to see how the contour lines are generated. But I'm not sure if there's much that can be done, as I think the contour data comes from the map files, and I don't think there's a way to edit them. There are some mapping tools, but I think they're for creating new maps rather than edit existing ones.
The attached screenshots are the same map (Georgia) at the same zoom level, the first is map_mode=1, the other is map_mode=2
Have you tried setting the campaign_map_mode=2 in the eech.ini? This will give some more definition to the map, with smoother contour lines. I'm not sure it adds more though. I'm looking into the code for that area, to see how the contour lines are generated. But I'm not sure if there's much that can be done, as I think the contour data comes from the map files, and I don't think there's a way to edit them. There are some mapping tools, but I think they're for creating new maps rather than edit existing ones.
The attached screenshots are the same map (Georgia) at the same zoom level, the first is map_mode=1, the other is map_mode=2
I vaguely remember read something about this feature years ago, but I didn't check it. I've had almost forgotten it. I'll test it tonight. Thank you!
Have you tried setting the campaign_map_mode=2 in the eech.ini? This will give some more definition to the map, with smoother contour lines. I'm not sure it adds more though. I'm looking into the code for that area, to see how the contour lines are generated. But I'm not sure if there's much that can be done, as I think the contour data comes from the map files, and I don't think there's a way to edit them. There are some mapping tools, but I think they're for creating new maps rather than edit existing ones.
The attached screenshots are the same map (Georgia) at the same zoom level, the first is map_mode=1, the other is map_mode=2
I vaguely remember read something about this feature years ago, but I didn't check it. I've had almost forgotten it. I'll test it tonight. Thank you!
It's such a slight difference I forgot about it, too, but I already had the higher res on. Better than nothing, but it just appears to increase the horizontal detail of the map, as it were, rather than increase the number of contour lines per elevation change.
Last edited by Reticuli; 06/15/2101:12 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.
It's such a slight difference I forgot about it, too, but I already had the higher res on. Better than nothing, but it just appears to increase the horizontal detail of the map, as it were, rather than increase the number of contour lines per elevation change.
You're right. After checking out this option, the difference is subtle, but I can live with it. I understand there are more important features to develop.