ARM505

OK, that is hilarious Gives new meaning to 'co-operative rockets' "Hold still buddy, WAS-ing rockets!"

I'm not sure of the TBO's on these engines, but on commercial airliners, with the typical requirement to achieve the highest possible cycles/hours on wing before servicing, there is a requirement to alternate the starting engine - given that engines are serviced based on hour spent running, and no attention is given to what kind of running (except limit exceedences), we have to 'spread the joy' otherwise over time, a significant hour buildup will occur on one engine. Our company starts the downwind engine first during pushback, which randomly spread the time over both (in theory). I can understand that the military might just keep things the same though, the difference is indeed almost insignificant (especially with such a short startup cycle in the Apache - an airliner start cycle can be a lot longer: even only one days operation might result in 5-6 minutes difference in engine running times......multiply that over 365 days of operation, and one year means ~33 hours of time difference).

Yeah, using the CPG's head as a sight might mean you're doing it wrong. Sorry, this might work, but....no. The guys head is going to be animated at some point, I'd rather focus on learning to use the system as best you can. It's not staggeringly hard to be honest.

There is a way to do it in game as well - I'm not at home right now, so this is from memory, but you can right click (I think) on a controller heading while having the CPG profile up, and select 'load profile' (or something like that) and then find the PLT profile for your controller and just load it - the controls are then imported into the CPG controller profile. Sorry for the vagueness, but it's quite simple to figure out if you play around - no need to rename files etc, although that is easy enough. Just thought I'd mention that they did allow for this in the sim.

You can also change the zoom FOV with (I think) R CTRL and the normal zoom keys (* and / on the KP) - if memory serves me right. This can give zome very nice close ups.

There is also IAT (Image Auto Track), which is not yet implemented at this stage of early access.

Unlike the pilots seat with it's rotary controllers, the front seaters IHADSS brightness is adjusted via the SYM rocker switch on the upper right side of the TDU (the center display, sorry if this is obvious already).

Yes, like a little piece of cloth, at the nose/throat area, visible if you look down.

I think this is the first module with an actual difference between VR and flat screen? Specifically, the IHADSS/NVG's - for those who haven't seen it in VR, the IHADSS is actually rendered and animated in front of your right eye (it animates only when moved away from your eye, it appears instantly when selected I think?), unlike the flat screen with it's little tranparent impression of the monocle, which appears and disappears instantly. Also in VR, you can see the NVG's on your helmet above your head when they're flipped up. It looks very cool. Again, I'm blown away by how good things look in VR. I have to turn just about everything down to nothing on my poor little 1080, but at least getting a solid 40fps (don't laugh, it actually does work ok). That front cockpit feels small! Also, the top strap of the harness on the seat vibrates (while we're talking about little bits that move).

Well, I for one am shocked at this early access, the total unrealism of the M4 selector - everybody knows that you cannot put it into 'Safe' when the hammer is down, after the trigger is pulled! My goodness, they're just playing with us now! I expect an immediate hotfix. /sarcasm I was really surprised to find the trigger and safety was clickable, awaiting the negligent discharge simulation in a future patch - I too would like to put a 5.56 round into the canopy

Hover, Bob-up (one of the IHADSS modes as well I think) As in , 'bobbing up' from behind cover, ie. rising a short distance to clear an obstacle.

Perhaps I should clarify - what is there, is generally as the manual states. Parts that are missing, are missing in their entirety, and don't really detract in the modelling of the parts that are there - put another way, the manual is useful in that it is applicable to those bits that are actually in the sim. It's a generalisation, but....

To second what Raptor9 says, I will comment on the sometimes ridiculously useless nature of real manuals - I literally just helped a friend with a technical exam, and despite us both puzzling over the Flight Crew Operating Manual (in this case, FCOM2 for the B738), neither of us could find the answer, because it simply didn't go into the level of detail required. The FCTM (Flight Crew Training Manual) elaborates a bit on recommended techniques, but the bottom line is that these are meant to be used in conjuction with actual, real world training by experienced instructors following company/unit SOP's and standards. The books are references, and often blunt to the point of being quite superficial. That being said, DCS actually does an excellent job for a PC sim in modelling the real thing - I remember when the F18 came out, sans manual, and the comment was 'just use the NATOPS manual' - which, to their credit, was actually close enough to be of genuine use.

The AI gunner has built in 'delays' to simulate a human switching to the next missile, getting on the scope and being able to find targets again. I don't know if these delays are fixed, dependant on other variables, or random. I'm not aware of the physical weapon system limitations.

Are you using VR or not? Most people who fly in VR instantly notice that it looks terrible and unrealistic because they don't move like real reflections, and they don't look like real reflections. Again, it's especially noticeable in VR. I have both VR and (obviously) flat screen, and VR is markedly worse. I also fly for a living IRL, and IRL you just move you head, or focus past the reflection, or change the lighting conditions with cockpit shade screens, or something like that. The baked in reflections are much worse than in real life.

I meant to add this part, but didn't want to confuse the issue - I should have been more clear, that the yaw channel, when I last used it (I confess to not using it much at all) seems to progressively use up more and more of the available travel, unlike the SPUU which just limits a certain amount under certain conditions. And, the SPUU indication is clear on the control indicator (small arrow/chevron creeping in from the right on the pedal scale, unlike a potential problem with pedal travel where the position indicator just won't reach the maximum on the scale). In response to something else somebody said, double tapping the trimmer to reset trim to nil no longer works (it worked in initial release, but was removed) Edit to add more: Something is definitely still 'off' with the A/P yaw channel. If it is used, and ends up with an input during straight and level flight, and is then switched off, this input will be held in, essentially being a new 'neutral' position - I just did a flight, and ended up with some right pedal input, even though my physical pedals were centered. This then caused the inability to reach full pedal input to the left (the input mark stopped short of full deflection by the same amount the new center had been deflected by), and pedal input to the right to beyond the SPUU chevron limit.

Some suggestions: - Submit a track of the event if possible if you want other people to attempt to replicate the situation. - Secondly, open your controls indicator (R CTRL & ENTER) and see if you're actually getting full pedal input at the time - I've personally found the Mi24 to be very odd in this regard. I don't want to say 'bug', but for some reason, especially with the yaw channel engaged, something tends to 'eat up' the full pedal travel, and you'll see that the pedal deflection is either massively reduced from its maximum (despite you having full physical pedal input in), as well as a totally off center neutral position. My understanding of something may well be off, but that's been my experience (it has improved since initial release). - Thirdly, attempt to replicate the issue with the A/P yaw channel off and see if that isolates the problem (just a hunch) - Finally, do you have the rudder trim option enabled in the special menu for the Mi24? I'm not sure if this is bugged or not, but there have been some discussions of weirdness in this option, if I remember correctly.

No, but that's the point - this 'baked in' technology (fixed textures applied as 'reflections' on reflective materials like the canopy) doesn't work very well at all in night lighting conditions when illuminated with the flashlight, and other cockpit lights. Other modules (like the F16 and F18 for example) have the option under 'Special' to simply turn those reflections off, other modules use newer tech to not do that (Hind for example). The Yak, L39 etc would greatly benefit with options to turn them off.

I'm sure somebody will correct me, but I seem to remember reading that they'd pretty much wrung all the power they were going to get out of that powerplant, so it was taking quite a bit of strain at max power output, and engine reliability wasn't wonderful.

I actually dug up a post of mine on this very forum from 2009: I'm both pleased at the progress that has been made, but still fundamentally concerned that the detailed interaction between troops and attack helicopters like the Apache is still a very long distance off. Was quite a trip down memory lane reading all the old stuff. But I'm still worried about the interaction with an AI copilot, and ground troops complete lack of ability to act like actual troops.

Not using the yaw channel still results in off centre rudder pedal input over time. I'm not sure what contributes to it (yaw channel on makes it happen for sure, faster too), but even with it off it still happens.

I remember that thread (and the original problem), it was an excellent example of finding and researching a problem in the sim, and coming up with a solution/theory about why it works the way it does in the sim. This sentence of yours - "Obviously as the sim uses a static number it means that as the aircraft slows the tyres are probably gripping less than they should, but this is less detrimental to the handling than being far too sticky on initial touchdown, IMHO anyway. I'll happily take the Viper sliding a bit more then it should at 50 knots instead of firing itself at the scenery at 140 knots." - might be a good summary of the compromise that seems to have been made. Perhaps we can't expect a racing sim tyre model, but ultimately a slightly better tyre model, with more data points (coefficient of static and dynamic friction for a couple of tyre speeds, interpolated, combined with normal force for example - I'm not sure what's currently considered). Put it on the million item 'to do' list

Seconded - (14K flying hours IRL, currently on B738's) - it feels like the tyres are too prone to sliding laterally, or something like that (ie. they don't keep rolling straight, and don't provide enough grip to stop a sideways slide developing). Or something. Hard to pin down, but results in a lot of wiggling and sliding. I also think it's a global issue. The F16's narrow track and tiny tyres, plus FLCS weirdness on touchdown (control law changes) proabably don't help too much in pinning it down to one factor.

I've isolated the problem (for me at least) - long story, but I'm using a mish-mash setup: A Virpil base, TM Cougar Grip, and the old TM Cougar throttle. The throttle won't work without being connected to the old TM Cougar base. So it is still connected, albeit minus it's grip (which is of course sitting on the Virpil base, and being used successfully). What happened however, is that in DCS, all the devices of course show - so I have the VPC base (with the Cougar grip, whose buttons I must rebind to exactly what they were before on the Cougar), but the Cougar still shows - I'm still using the throttle, so buttons are mapped to it. BUT, I did not delete the OLD Cougar Stick bindings - so for some reason, even though it is sitting at the back of my desk, headless, some or all of its buttons initially register as pressed. Boom, fail. Deleting the *Stick* mappings on the *Cougar* device solved it. tl/dr - don't leave buttons mapped to sticks which aren't really physically connected properly anymore.