FalcoGer

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?