FalcoGer

or you could have 8 guys lasing and switching out laser codes really fast. Not really realistic, but possible. If you have a special forces team they may have 1 or 2 laser designators, perhaps a drone with a laser if they're really fancy. so you could maybe get 3 or 4 lasers on targets at a time (including your own), plus however many wingman you bring. So maybe it wouldn't be too far fetched to shoot on 5 different laser codes after all.

What about the CPG then? His BRU is offset from the centerline. Surely he doesn't load in with his head position offset. Or is the BRU angled towards the natural head position (which would be the default when loading in without a head tracking that does translation(?))

The technical manual, chapter 9 (page 955, and following) have the checklists. Also the apache has a feature of optionally (which makes me think dcs might not have this) loading checklists into the data cartridge. These checklists would be displayed on the engine page (which would autopage on the left MFD unless flight instrumentation is displayed there (which would then make it autopage on the right)). The bottom section would be replaced with the checklist items. If that feature is available then we don't need a kneeboard QRH. Engine fire (Inflight) checklist is 1. Power lever, affected engine - off 2. Illuminated engine fire button - push 3. Fire Disch Button(s) - press 4. Land as soon as possible

Another question: If such an object is placed, will it be picked up by the radar and marked? How reliable is that? Is that marking permanent, as in will it generate a hazard point? How does that work in general? I didn't see anything about that in the TM, but wags mentioned that in his videos. Also there are power line hazard points. Will those be placed automatically? There are a great many power lines in the maps we have, it would be nice if the hazard points would be placed automatically near the flight route until the cap is reached (maybe leave a few slots open for user placed points). Manually placed points should have priority.

I have a 3 axis (rotation only) head tracking device. How can I boresight the HMD? Will it be perfectly fine to skip that step if you can't do it due to hardware reason and the option to is just for realism or is it strictly required for an accurate helmet? This is especially a concern with the front seat where it seems like the HMD bore sight optics are offset from the centerline. If there were some option to adjust the seat height in the back seat it would probably be doable with just 3 axis, but with the offset it's just impossible. How do I and others in my situation deal with that?

Any chance of non normal checklists, too? In case we don't get the automatic checklist popup on the engine page?

The better question would be: can I open up the canopy and shoot out of it, or hop out quickly and shoot some place up.

Okay what's with the engine indications then? 101% rotor/engine RPM is normal? what is 100% a reference to? Why 101%, shouldn't 100% be normal? What's the design limit (aka rapid unplanned disassembly point)? why isn't that 100%? Anything else would make more sense.

What is the refresh rate on that camera/HMU/MPD? seeing flying bullets might not even be possible.

I am noticing some really confusing and nonsense design decisions in this aircraft. For example there is an audio knob on the CMWS but the audio is actually being controlled by the ADF knob. Why? That just sounds ridiculous. Just don't install the knob, save yourself 2 bucks of hardware and tape over the hole/don't drill it in the first place. Or there is an A/A switch or two, but A/A has been phased out for years. I understand that they reuse the hardware and manufacturing processes, but couldn't they at least scratch the labels off/not print them on? No bullseye support? I mean there is all this amazing navigation hardware and software, but they couldn't program that in? I'm sure there are plenty of other whack things that are just plain counter intuitive or make no sense. Why is that?

EGI is only in part GPS (that's the G part). It stands for embedded GPS/INS. INS is the other big part of it, being the inertial navigation system, which is the part that actually needs the alignment. In the AH-64D the EGI is a dual redundant system, the INS consisting of 3 laser ring gyros each (one for each axis of rotation). While mechanical INS systems (using actual spinning gyros) drift over time, the laser ring gyros are very precise in measuring acceleration and rotation. Alignment time is 6 minutes. I can't remember the specifics about stored alignment, alignment after moving the chopper with power off, no GPS alignment, etc. They're all different though. Physically alignment is done by measuring acceleration forces that the earth exerts on the unit. GPS greatly aids in the process but is not strictly required. Acceleration is measured by a split laser beam moving in two different directions around the gyro and recombining. If the gyro moves, then the path while the light travels around the gyro will change in length differently. The resulting interference pattern will shift, which is measured by a sensor. From this acceleration is inferred. Putting the thing on a ship (or even bumping it) would really mess the process up and probably requires special hardware. That is why EGI alignment on commercial aircraft is done before boarding and engine start.

Wags' new video ("Setting up controls") confirmed today you have several options for both the cyclic and the rudders. Force feedback joysticks will get stuck in their new center position. You have an option for spring-less sticks that doesn't do anything (?) and you get the new center position option like we have in the ka-50 where you press the force trim release and then move the stick back to center and the position where you set it is the new center position.

PWR: Off - System is off On - System is on Test - Perform BIT CMWS/NAV: CMWS - ADF volume control controls CMWS and ASE volume, ADF is muted NAV - ADF volume control controls ADF volume, CMWS warnings are muted Audio - No function (audio volume controlled by ADF volume control) Lamp - Display brightness Arm/Safe: Arm - Dispensers are powered Safe - Dispensers are not powered Bypass/Auto: Bypass - Flares are dispensed manually, pressing the flare button dispenses the selected program Auto - Flares are dispensed automatically when the CMWS detects a missile launch. Will also launch flares when missile is no threat (for example if wingman firing hellfire) Jettison - Jettison all flares Display: F : NN - Number of remaining flares in inventory (not necessarily equal to the actual amount of flares) C : NN - Number of chaff in inventory (dito) Circle: Displays which sector a missile launch has been detected in, up being the direction of the aircraft's nose. Only displays 8 directions and no hemisphere (up/down) information. Displays R when system ready, D when flares are being dispensed. A countdown timer is displayed for the BIT and the BIT results briefly after it concluded.

who needs an MI-24 with such useless baggage like "seats" when you can bring 2 infantry into battle with your apache? Actually... with a flight of 4 you could bring a small fireteam, which is feasible. but if you only need a small fireteam then 4 apaches are probably way overkill... I guess. I guess the UH-60 does have a place. At least it's not a pretend attack helicopter.

What the heck? They have early early access or what? Not fair!

Even then you should get a laser warning. The A10-C (shows up as L on rwr) and the ka-50 have laser warning receivers, not sure about other airframes.

it's probably noscript but this is really funny. Also if it is noscript then why the heck do you need javascript to put a number there?! Buy this thing and waste 30 minutes of your life (presumably unpacking not included) to get 0 extra fuel!

Couldn't they use some kind of contrast lock to steer the missile without radar? Why would you manually guide the missile with optics when you can have automation be more reliable and accurate? Especially in this day and age. Manpads in DCS are really easily spoofed by the flares. They always seem to go out for those in 95% of the cases and their range really sucks, too. You can snipe them with guns from 4km away in the kamov and not get shot at. of course your accuracy sucks and you have to put 20-50 rounds downrange, but it's still better than wasting a missile that is better served for a real threat (like a tunguska) or even a tank or ifv with guided missiles. We need some more modern stuff for manpads.

any updates on this? the new A-4 kneeboard has colored tabs on the side that help you know which section you are in, they're the same on all images with the section you are in highlighted. Also page numbers and an index page. There is a cockpit layout page with references to the pages that the systems are explained in. It's really handy.

I don't mind delays. But really, no one expected it to release in december, or january. And yet they STILL said they would. That is the problem I'm having with this whole thing. Again my issue isn't with the apache development, the apache module, the thing being delayed or even the development team, because I'm sure they do the best they can. My issue is with the policies and politics of ED and their marketing. Of course I can wait, and again, this was expected. I never once wavered in my belief that the apache would be delayed at least trice. Of course I had the vague hope of it being done this month and I would've liked it very much. But I'm not loosing my sleep over it. All I ask is reasonable estimates and no PR nonsense. And of course if you're gonna give people <insert name of imaginary money substitute here> as an apology for the delay, then give it to everyone.

Disappointing: Yes Expected: Yes Acceptable: No, because it was expected Release dates have never been met. Why don't they just take their "release dates" and add half a year and then everybody will be happy with only a few weeks of delays instead of months. I don't expect this till the end of march when they are legally bound to release due to their stunt on steam, putting their release date in December. The delay was expected by everyone here, nobody believed that the release date would be met. And that is the unacceptable part. People who aren't even involved are fully confident in your failure to deliver on time. I don't mind complications coming up and things being delayed, everybody has been there, I'm sure. But by now everybody knows, and that includes the developers, that none of the release dates you promised have held up so far. So why do you keep saying them without a healthy margin based on previous setbacks and delays? You push it back by a few weeks, then again, then again, then again. Why not just tell us when you are actually ready? What would be real nice is if you said releases in june, and then you release... in june. Is this all some kind of big marketing stunt to reel in the cash by pretending that things are almost done or what? Because clearly it wasn't unexpected that things would take longer. Also thank you for increasing the miles for the module because of the delay. And then not giving any to those who used miles for the purchase. Because not only makes that total sense, it's also very fair. (sarcasm)

When looking at the destroyed model of the ZU-23 Ural truck black squares appear around certain areas.

Rearming complete. Also can not repair. Ground crew replies with "Copy", but timer does not appear.

@BIGNEWYCan you clarify what "working" means? We have "working" wipers in the ka50, in that the models move. but rain is not actually removed from the canopy. Do we get the same "working" or will they actually work? Will this feature then be extended to the other models that have anti rain/ice for their canopies? Be it wipers or bleed air?