FalcoGer

Distribution notice doesn't mean classification. I am not an US citizen, I am not exporting it from the US. Someone wasn't supposed to give it to me doesn't mean I am not allowed to have it. If it were classified it would state it's classification. Confidential, secret or top secret. But it does not.

Maybe they should add function to the AVR switch and create a trackfile when on so we can report all the bugs more easily.

There should also be a warning and master caution if SMS disagrees with CAT I/III switch position. If I remember correctly CAT III also only protects the pylons by limiting max G, not the weapon, so you can still get hung stores.

I wish for a north indicator on the HSD. There should be a little arrow or flag pointing north on the inside ring. There should also be tickmarks for E, S and W. As it is now it's hard to use as a compass.

Don't forget the IFF audio/audio+light warnings you can set on the IFF page.

Did I miss something? I did a quick search and found nothing. Can you provide a link or something?

Pre planned threats are steerpoints and as such they should be selectable. In particular this is useful if you wish to engage a sam system without HTS or without HARMs period.

If you apply some basic software engineering principles then it should not be a problem. I understand that there are different requirements. That is fine. If you look at another network protocol you will see why it is fine. TCP/IP is used for a lot of traffic on the interwebs and elsewhere, despite there being a myriad of requirements. If you design the protocol to be extensible then there is no issue, although DL would be more akin to ICMP with message types rather than encapsulating more protocols. If you require datalink then there is some commonalities between the systems, in particular most if not all solutions have the positions of your group on some sort of HSD. That F16 doing CAP doesn't need to know where the tanks are. Fine, just don't show them even though it can understand the message because it inherently understands position messages. The abrams doesn't need to know who that F16 locked up on the FCR and it doesn't need the software to decode that ever. Ignore the message. If you have an addition to the protocol then any platform that is not updated will simply not understand the new message. I think it's a lot cheaper to have a single software update distributed than it is to develop and maintain 20 different solutions altogether and save costs on distributing them only to subsets, which you could still do with an extensible protocol. I can come up from the top of my head with a dozen or two message types that would probably cover 80% of applications for datalink for all services. I believe it has more to do with politics, bureaucracy and capitalism and not working together than it has to do with cost saving and requirements.

Well since we're on it might as well include a true and magnetic switch option.

I wonder why they mix the systems up so much. Wouldn't it be better to integrate everything into link 16 or any other datalink format just to keep software development costs, parts compatibility and platform interoperability good? If you have 20 different datalinks then you have 20 different softwares to write and maintan, 20 different radio protocols, 20 different networks that can't talk to one another. It seems downright stupid. Pick one, upgrade everything to it and stick to it. It's cheaper and better. If that MBT at the front wants to send targeting data to some F16 they have to talk through several people and relay information verbally. Instead they could just ask one person, get affirmation and then send a 9 line via link. Or the E-8 picks up a column of tanks over the next ridge and the blue tanks can just see them on some screen and plan for it. Or the apache sees the enemy fighters flying their way on the TSD and they can hide. Instead it's segregated. Why?

My issue is the reasoning why they chose to mix in the first place. I know. I was also talking about the cockpit temperatures though. My other issue is that I can imagine an EGT of 900 °C is probably a bit on the high side while 840°F has no meaning to me. It was more meant as a joke. But that aside it does seem to be a more general issue. Take the F18 for example, showing L/L in degrees, minutes and seconds on one page (HSD), but degrees, minutes and decimal minutes on another (weapon target information) It seems odd to me to mix measurement units where they don't need to be mixed, especially on the same platform. I was asking for the reason. I was just given my thoughts on what the reason might be. If you have a better explanation, please go ahead.

I'm a little confused by the usage of temperature units in the bird. FAT is in °C, cockpit temperature (set and measured) is in °F on the same MFD page. Then NGB temp and transmission oil temperature is in °C but ECS temperature is in °F again. What gives?! Couldn't they decide? Did they want to use sane units for things that mattered but have the pilots use this nonsense for their aircon? You would think in the same software that they stick to one or the other, but no, american as they are, they refuse reason. Can we get an international software with °C only please? Doesn't seem that far of a stretch if we get left eye HMDs, which seems way more unrealistic. On the other hand you can switch between km and nm (nanometers, xD) just fine on the TSD. Seems odd.

From what I have read you can use any radio for the IDM. Does that include the HF radio? Would be awesome for that non LOS datalink, although I wonder if you can do voice and data on the same radio.

Which engines do we get?

I leave that experiment up to you. I'll stay away from that thing.

What i meant was if the pilot presses chop, can the cpl press his chop button to undo it or is it like the fire switches where the crew that pressed them has to press them again to undo it?

When the chop button is pressed, engine power is set to idle until pressed again. Is this per crew station or can both pilot and cpg activate/deactivate independently? What is this button used for? It seems like a good way to die unnecessarily. Why is it on the collective? Is it important enough to warrant the space on the HOTAS (HOCAC?)? The only real reason I can think of is that if there is some sort of malfunction with both engines you could press it and take maybe a few seconds to figure out which one while on idle power to close the throttle. But then again you could just pull the throttle back. The immediate fire actions include closing the throttle, not pressing chop. It's just confusing to me.

This is why we can't have nice things.

I want to have a good time with in depth systems modeling and learning how to fly an aircraft as close to the real deal as possible and use real procedures. Isn't that what a simulator is about? If ED is going to skimp out on features that the real bird has then that needs to be fixed. I am making my requests now so they can work on it early. Or I'm making requests about features that were optional for the real apache and could be optional or missing from ED, such as the emergency checklists being displayed. If not in the DTC they wouldn't be there, but I would like them to be. ED has been taking shortcuts for IFF. I want real IFF, not magic IFF. Even if the protocol itself is classified, you can find out from unclassified sources how it's supposed to work and look, so model that. The JF17 did it just fine although I wouldn't have minded if they called it mode 4 instead of 6 despite not being a "real" mode 4. If people don't want canopy fogging then they will skip on it. I am saying I want the FULL experience. That includes adverse weather operation and procedures and the consequences if they are not followed properly. They did promise anti ice, so I assume that includes winter ops procedures, so I will not ask for it unless it's incomplete. I wonder why you have to argue with me on every turn. I'm not asking for anything impossible or illegal.

+1 The comms equipment on the apache is really complex and in depth. I would like to see it modeled in it's completion, and that includes this. From what I have seen the apache can set artillery laser codes. So laser guided munitions would be neat, too.

Since we're here. Implement the wire cutters on the bird. Right now if we fly choppers into the landlines they loose rotors or die no matter what. The apache, like a lot of helicopters, is equipped with a wire strike protection system (wsps), that in case of a wire strike will cut the wire. They are located on top of the canopy before the rotor axle on the nose of the TADS, facing down on the fuselage just in front of the gun on both main landing gears I would like that if hit in the right place, there will be no catastrophic damage to the helicopter but instead the power lines disappear.

ED's manual will be incomplete, simplified and possibly faulty. How am I supposed to make feature requests and bug reports of things that are based on the real thing only in the third instance (ie. real apache - apache module - manual for the apache module)? I have nothing to compare it to otherwise. If they're going to skip on things, I could only find out through the real deal. Besides all that I want to be semi proficient and knowing what's going on by the time they release.

Of course I am. You should too. It's a good read anyhow. Also that's the first semi nice thing you said to me. Thank you.

I would like an option, particularly for dynamic multiplayer, for a mission planner that is available when the aircraft is cold. It should allow for editing waypoints, threat/hazard points for aircraft that support them (F16, AH64), fix points, target points, update points, (multiple) flight plans, etc, (personal, but shareable) map drawings (with the option to save and restore/delete them from hard drive) - potentially loaded into cockpits that support them (F16, AH64), area markers, laser codes, comm settings (with the option to save them to disk and load later as presets). This would fix the issue of having threat rings magically populate for example in the F16 but then unable to target them as PPT. I heard real pilots also use custom PPT with 0 range to mark airfields on their HSD, which could be handy. Instead you can place a limited number of PPT (according to the real capacity for them in the aircraft) manually or automatically (along the flight plan as priority if there are too many) if units are visible on the map, but in the end the player has a say in it and more importantly it's not magic. Mission planning is important, but it can't be done in dynamic missions. This would fix that. All data there should be able to be saved to disk (so you don't have to redo the whole thing if DCS decides that it is time for you to suddenly have 1 FPM (1 frame per minute) for a while, or you die in a horrific accident) with the option to delete it if outdated.

Whenever I join a multiplayer server the settings for my F10 map are all different, and different between each time I first open the map. Sometimes sensor rings are shown by default, sometimes not, sometimes threat rings are shown, sometimes not, sometimes labels are shown, sometimes not. And all the time I have to click on the range/bearing tool icon, it is never on. It's confusing and unnecessary. I would like an option to change the setting in the options so that it defaults the buttons to a specific state and I would furthermore like the option to have the coordinate system displayed in a specific format on an per aircraft basis. For example MGRS for A10C or F18 but L/L Dec for KA50. I would also like buttons or a drop down list to change the coordinate format more easily without having to remember such obscure key bindings like left alt + z, which is a bit hard to do on a german keyboard anyhow. The range/bearing tool should be always on, the button can be removed, there is literally no point in having it disabled, the right mouse button does nothing with it off, so it might as well just have that function by default.