FalcoGer

Amazing. I hope we'll get the modern ships, particularly the anti aircraft destroyers and cruisers. Frankly they should just include it all. I hope you get some compensation for this, too.

When flying as CPG in multicrew, the camera often gets obstructed, especially when looking to the up and right. In the images below you can see that the camera is looking ahead, where it shouldn't be obstructed. This happens on multiple zoom levels. TV is usually fine.

Currently when the pilot uses the LINK feature to link the TADS to the FCR NTS track, the TADS will snap to it and if the CPG had TADS as sight, it will be reset to C-HMD. This is expected. When the CPG then selects TADS as sight while the pilot still has it linked to the FCR, I would expect for the TADS to stay relatively near that slaved to radar contact, similar to how a tank's gunner sight would stay in place if the commander slaved it to himself and then let go of it. But instead the tads snaps back to the position it was in before LINK was selected by the pilot. Is this the correct behavior?

Can confirm.

You can not tab to the next data field for data entry in the mission editor in the AH-64D SMDL Settings To reproduce Open mission editor Place AH-64D Blk. II Open properties -> Datalinks -> Settings Place cursor into Preset 1 Unit ID data entry field Press TAB Actual behavior: Nothing happens. Expected Behavior: Cursor moved to next field for data entry If next field is a text field, all text gets selected for overwriting on first keystroke When next field is Primary Freq, the drop down list gets highlighted to be navigated with arrow keys When next field is DL Net checkbox, it gets highlighted for toggling with spacebar This makes it a pain to enter data because you have to grab your mouse every time, even though you are just typing.

The list is ordered by seemingly no reasonable criteria, neither by name alphabetically, nor by DL C/S, nor by DL ID, nor by distance. This makes it a pain to add them in any sane order.

When copying an AH64 in the mission editor, it does copy the preset frequencies, but does not copy the preset unit ids and callsigns and primary frequency settings. To reproduce: Open mission editor Place AH-64D Blk. II Apache Open Properties -> Datalinks -> Settings Enter valid names, callsigns and primary freq Copy unit Paste unit Open Properties -> Datalinks -> Settings on the pasted unit It's the default PRESET 1/PRE 1, etc Expected results: Since the frequencies for the presets were copied (Radio Settings), the names for those presets should be copied as well.

I have a system that inputs the DL information into the helicopter. Same tool. Either way, you still have to communicate with people. It's not just the DL ID, but also the radio and frequency to use. And of course there is more to communication that aircraft sending digital messages between each other.

Thanks for clarifying. But it was quite clear that the topic wasn't about selecting the rocket type from the cockpit, but actually the question was to provide an update on individualized mixing and matching of rockets in the rocket pods and into zones - aside from the preset options that already exist. Rocket zones are the 5 zones in the actual hardware under the pylons, Not one person mentioned the word "selecting" or asking about how to switch types from the cockpit. Since I assumed you wouldn't just answer a question that wasn't asked - how to select rocket types from the cockpit - , I took your answer as though it was an answer to the question that was actually asked, which is about those extra rocket types and arming rocket pods with a custom zoning. And since your answer was "It's already possible", I got confused. So please excuse my confusion. But that's really not on me or trying to twist your words or anything. The problem here isn't that it's not possible or that the rocket types don't exist. The problem is that people ask questions for 6 months, get ignored for 6 months, then get an answer that doesn't answer the question but a question that wasn't ever asked, and then the topic gets locked. Frankly, I don't see how you can't see how this is frustrating. "I can't tell you", "Maybe in 2 or 3 years", "It's low priority but it will be there", "the feature has been dropped, because...", or perhaps an actual answer would go a long way - sure it's not satisfying, but at least we don't feel like you think we are morons. The way this kind of stuff gets handled is frankly appalling. And your - or rather bignewy's - default response to dissatisfied users isn't to address the issues or to communicate, but to lock the topic. Wags stated in his QA video that the people at ED need to improve communication with the community. Maybe you should do that.

Ka-50 doesn't have it either. Anyhow, I rather think that it's especially useful for self centering pedals. To answer your question though, just set it to "No spring" in the apache special options and it will simply ignore your pedal position when you trim, always taking the raw value. If push pedal and trim and then release, it will go back to center. Of course it's meant to be used for when you removed the springs, but nothing is stopping you from choosing that option. The SCAS heading hold assist thing will still do it's logic, but you can turn that off in the A/C Utility mode by disabling the SCAS yaw channel.

Some rearm options (FCR and IFAS) make no sense to be done hot. Require the engines to be off for those. The Su-25 already requires engine off for rearming, because the jet exhaust is dangerous. How are spinning blades not dangerous when you install an FCR on the rotor hub?

The current solution with the kneeboard looks rather unprofessional and also feels out of place. Requiring engines off is also a bit weird. From what i understand, the flare program is set on an external panel. Unless that panel is in a dangerous spot, it should be able to be accessed even with spinning blades. I propose that the flare setting be put in the rearm screen instead. That way it can only be changed on the ground by ground crew and without the weird kneeboard page.

Some aircraft in dcs already require to be shut down for rearm. And in the apache you need power off for setting the flare progam. It's inconsistent. Personally I think there should be some rearm slots that require engine off to change. Not talking hours to install, just shutting down for a minute. And how often do you un- or reinstall ifas or radar anyway? Maybe once a mission at the start where you are shut down anyway?

You can read the display. Of course, you will need to press the comm button for that, but that can also be automated. Or you could repeatedly check if the user is on the comm page, and update the value if it is so. Check out this function for my tool that reads the displays. I adapted it from SRS. https://github.com/FalcoGer/CoordinateConverter/blob/26477e4a7899c7d9069fbc8e362afb655b4e9b8d/CoordinateConverter/DCS/Communication/CoordinateConverter.lua#L32 Display IDs seem relatively stable, but ED won't tell you when they do change in an update. You find them here. https://github.com/FalcoGer/CoordinateConverter/blob/26477e4a7899c7d9069fbc8e362afb655b4e9b8d/CoordinateConverter/DCS/Aircraft/AH64/AH64.cs#L107 The lua api documentation is attrociously terrible. Maybe there is a better way. But even srs relies on reading the eufd for finding the selected radio and reading the comm page for iff codes. Edit: it seems I misread. I don't think you can get that data from other apaches. You could export the unit list, filter for apache units, read the display while stepping through the comm net dl phonebook and compare unit names. Might not work with dynamic slots. Perhaps some experimentation on how dcs assigns these IDs instead and then try to emulate that to predict what the id of a specific unit should be? All of that seems way too jank and fragile though. Any change and you'd have to redo everything. Another option still would be to have a script that reads the apache id as described on every client, if you can control that, and then collect them centrally by having those clients connect somewhere to send that info. Then everyone can connect to the same api and querry those ids by sending the units export. Obviously that requires more infrastructure. Maybe srs can be extended to provide dl ids, and a way to querry the server for a specific unit's id. Probably needs a PR from you though.

According to Vader it is possible. But all I see are a few presets. How do you do arbitrary zoning then? Because I would like to mix the 17lbs rockets with some rc delay fuze rockets on one pylon. Or fine tune the amount of illumination rockets by putting then into zones other than E, or waste a full pylon on them (Say A and B, and have the rest of the zones with explosive rockets). Since this is apparently already possible, it would be nice to know how to do that. The manual doesn't say. Also thanks for asking for the status of MPSM and flachette, but the point of asking for us was that you would also tell us their answer? "Okay, I asked.", and then locking the topic for no reason after the issue wasn't addressed doesn't really help anything.

If you click the generator buttons on the system page, that trips it offline, causing the failure. You don't click it to check the status, just check if it has a solid dot to see if it is on. To reset you need to use the gen rst hard switch on the center console in the pilot station. Turning the generators off with those buttons is not a bug. Also what do you mean it "failed" when you pull collective?

I noticed that rearming with ground override and master arm has the missiles safed regardless. Simply cycle after rearm, or rearm with master arm safe.

If you just want to resume the route, go to RTE, DIR and pick the point in the route on the right side that you want to resume from.

also TADS Link with TADS as ACQ or viewing the TADS video also goes bananas in the rear seat, jumping between two every other frame targets.

Sometimes on one of the cameras it appears that the TADS picture becomes obscured by something, even though the TADS is looking only at a slight angle ahead. Switching cameras or yawing the helicopter slightly makes it work again. Maybe there is some model geometry that isn't properly culled from the camera's view? In game it just looks like the camera completely blanks out for seemingly no reason, turning all gray/green, depending on the mode switch. Sometimes, when the helicopter is very slowly yawing into that specific angle you can see the edge of whatever is obscuring the TADS sliding over the view. This only happens at very specific angles, so it's hard to reproduce, but it's really annoying when it does happen. I'll try to get a track.

The CPG/Pilot Cursor option on the TSD/Show page is shared between navigation phase and attack phase. I believe they should be separate as all the other options that are the same between the two phases are (Like Inactive Zones, Wind, HSI or Endurance). To reproduce Go to TSD/Show page with TSD -> T2 (Show) Take note of the CURSOR option being enabled or disabled on L5 Switch to other phase with B2 The setting will be the same for CURSOR (L5) Toggle the setting for CURSOR with L5 Switch to the original phase with B2 Expected result: The setting will be what it was when you left the original phase (as seen in step 2. above) Actual result: The setting for cursor is always the same between attack and navigation phase, toggling it for both phases when selected. Track attached. cursorShowOptionSharedNavAtk.trk

TL;DR Implementing FFD or using the existing F10 alt map as an overlay on the AH-64D’s digital map would significantly enhance situational awareness with minimal development effort. The problem The current digital map lacks contextual information beyond elevation data, making it less useful than other map modes (e.g., SAT or chart). Charts lose detail at higher zoom levels or disappear altogether, and satellite maps disappear when zooming out. This limits their utility for route planning and situational awareness during missions. This makes people ignore the digital map mode altogether, when in the real Apache it provides enhanced situational awareness through features like VIS shading, contour lines and most importantly the FFD. The solution Full FFD implementation Add FFD data to the AH-64D’s digital map, enhancing its situational awareness capabilities by correlating terrain features (roads, rivers, urban areas, etc.) with what you see outside or through the TADS. This matches real-world functionality and improves usability for route planning and battlefield analysis. This is the realistic approach. As shown below, much of the FFD data is already present in the terrain files used to generate the F10 map and could be reused to compile the overlays necessary for the DCS Apache implementation of FFD. The FFD data that is present in the real Apache, but not explicitly included in the terrain data could be ignored (defaulting back to moonscape), or considered the closes equivalent (Rock -> Ground, Industrial -> Urban) - with the option to include that data later/never in the terrain files. F10 Alt Map Overlay as a Simplified Solution As a more immediate and less resource-intensive option, allow the F10 alt map to display on the MFD when FFD is activated, similar to the KA-50's ABRIS moving map. VIS shading could still be possible, as seen on the KA-50's ABRIS moving map. The overlay could serve as an interim solution or a permanent feature, ensuring pilots have access to better digital maps sooner. Simply add the existing terrain elevation and shading of the digital map as an alpha channel onto the flat colors of the F10 alt map. This would: Utilize existing terrain data (e.g., forests, roads, urban areas) with minimal development effort. Provide many of the benefits of FFD without requiring extensive new overlays or terrain file updates. Allow incremental implementation of FFD Allow modded overlays The FFD data comes from the data cartridge in the real Apache. Implement the display of this data and provide the specifications for file paths and file formats and outsource the creation of these overlays to modders and users. Obviously the disadvantage is that this places your burden on your customers, who do not have the same resources (raw terrain file data and specifications for that data). Advantages of this approach: Minimal work for developers, only the display and reading files need to be implemented No need to compile terrain data into multiple map formats (F10 altitude, F10 satellite, Apache FFD) Outsource expensive hand crafting of map data to users Comparative analysis between FFD and F10 Alt map Much of the data that is present in the real Apache's FFD is already present in the terrain data files for DCS world, and used to generate the F10 map. This very same data can be used to generate the FFD overlays (area and line) for the Apache. Reusing the same data has multiple benefits, the most important are Accuracy: the FFD data will match the terrain file, even if changes to the terrain files are made Lower workload: No need to draw the overlays by hand Reusable: Once implemented, the same procedure can be used for all maps, including new ones Line data, all available from whatever data is used to generate the F10 map: Single Trees Road/Path/Bridge Political Boundary Runway Railroad Fence/Wall/Barrier Water FFD line data not available in terrain data: Cliff (Possibly from elevation data?) Gully (DCS doesn't have this?) Pipeline (Possibly from object position?) Tower (Possibly from object position?) Ford (Shallow river crossing, not a thing in DCS?) Area data, also available from map data used to generate F10 map: Forests (shown as dark green on F10) Sand/Beach (Shown as tan on F10) Ground (Shown as light green on F10) Urban (Shown as yellow on F10) Building (Shown as dark gray on F10) Water (shown as blue on F10) Area data, not available from map data used to generate F10 map: Marsh/Swamp (maybe that is actually in? I seem to recall something like that on the west end of the Caucasus terrain) Rock (unsure?) Snow (just call it ground?) Industrial (just call it urban?)

I did. They moved it here so they don't need to look at it ever again.

Compare You ask for inbound you ask for ADF heading you ask for landing if you are lucky they respond and let you land, even if there is currently a column of tanks, a burning wreckage or some holes on/in the runway with You tune approach You ask approach for a radar vector approach They give you a runway, qfe and then progressive vectors, altitudes and speeds - which results in you getting separation from other traffic and terrain They line you up perfectly on the runway heading and on the runway centerline, and at the correct altitude for a descend They tell you to switch to tower and give you a new frequency (it should probably be in your radio presets) You ask tower to land Tower gives you clearance, wind and qfe, or tell you to go around if anything is wrong you land and taxi off, tower tells you to contact ground you contact ground and they give you the taxiways to parking, including hold short instructions to make way for other traffic (or tell them to hold short) or compare ask for engine start (or just do it, which confuses the hell out of atc) ask for taxi be given taxi clearance (no instructions though) start to taxi, and be told "hold position" every 3 seconds get to the start of the runway, ask for takeoff clearance. be denied, then granted, even if there is traffic on final or someone else on the runway with ask for taxi clearance be given taxiways and hold short points, and also traffic is ordered by planned departure time contact tower ask for takeoff clearance, or takeoff clearance for formation takeoff be given runway, wind and clearance if safe take off contact departure be given a heading based on your flight plan be handed off to awacs readbacks are automatic, so you don't have to screw around with the comms menu. at any point can you ask for additional information (wind, which runway, qfe, qnh), emergency, or for them to retransmit. if at any point it becomes unsafe they tell you to abort and give you new vectors.

They don't use it because it's terrible. Everybody I ever flew with when a decent ATC was available in the sim would actually use it, and even follow instructions, because it gets everybody down faster and they line you up nicely and with plenty of time and spacing. It also takes navigation and spacing off your hands. Or you can just ask for the "let me land and shut up" landing where they basically just give you clearance a mile in front of the runway and don't bother you with anything else. And you got it backwards. dynamic campaign requires a working ATC as a prerequisite. And I don't anticipate dynamic campaign as much as a working ATC system, because dynamic campaign is a new feature. Working ATC is a bug fix, it's a broken mess, the workaround for which is to tune a different frequency (impossible in FC3 aircraft) or mute the radio altogether.