Floyd1212

When you spawn into your aircraft, despite what the ME says, do you have 60 flares and 30 chaff? That is the default setting, and should be present when you spawn, and when you rearm. At least, that is the way it seems to work for me.

You should have chaff.

We are also getting this a lot. If the CPG joins into an aircraft that is already running, the CPG will get a CTD. If they join a cold aircraft with the PLT, then they start up, it is fine.

I’m away from my computer for two weeks, but if you post the mission someone might be able to look at it and see if they experience the problem as well.

As I mentioned in that other thread, we have been flying nightly with multiple cold-start Apaches using DL (typically on VHF) without issue. Sharing waypoints, routes, targets, PP, RFHO, etc. Maybe it's mission-related? Maybe it's setup-related? It does work for us (if you ignore the NAK messages).

For clarification, boresighting and setting range to "auto" is applicable when using the HMD as your sight, i.e. shooting the gun at what you see out the window. Using the TADS with laser ranging will use its own calculations.

Okay, so I take back what I said above. Bumping the torque up to 91% does not solve the problem and allow you to maintain an OGE hover. I actually took over the controls and tried to hover it myself and George was actually able to do a better job than I could. He apparently knows the magic number not to exceed before you end up with diminishing returns and get yourself into a faster descent. At 87% he manages to flutter to the ground with grace, but if you pull even 88% you will start to drop faster, and then eventually VRS. Agreed, not a George problem. It just seemed he wasn't putting in the effort to maintain the hover by nudging the collective a tiny bit more, but in reality, he was so well trained that he knew it would be futile. We need a recording for George saying. "I'm losing it! I can't maintain a hover in these conditions!"

Wags has other videos on DataLink usage and sharing targets, but this is the video on setting it up.

Are you saying that it isn't possible to maintain a hover in those conditions, or was that a reply to someone else? It would seem to me that in the above screenshot, there isn't anything preventing George from giving it a little more collective from 87% up to 91% to maintain the altitude, no?

I also experienced this. I'm using an analog thumbstick on a Virpil Alpha to slew the MMS. It seems that if you are slewing hard left/right, for example, and accidentally give it a tiny bit of up/down on the stick, it just comes to a stop. Obviously, you can slew the MMS diagonally just fine under other conditions, so I'm not sure why this is an issue. I currently have a deadzone of 3 and a curve of 20 set for the thumbstick, so maybe messing with these values may help.

I feel like the AI's ability to hold a perfect hover in an aircraft that doesn't have hold modes is a bit unrealistic. It would be cool if he would drift around within a box of some reasonable size, and within a reasonable altitude band. Not sure what these numbers would be, but the way it is now it's like you enabled Active Pause.

That's not what is going on here. In these conditions the helo should maintain an OGE hover at 91%. George won't pull anything higher than 87% in that track file. (Sorry for cross-pointing this info in 2 threads. After seeing it is a George problem, it really belongs here.)

It looks like George will never pull more than 87% torque. If you require 91% to maintain an OGE hover, he will happily sit at 87% and settle to the ground. If you tell him to increase altitude, he will confirm the command, but then never increase the collective above 87% to even try and climb. EDIT: I should clarify, he seemed to be capped at 87% when playing back the track posted by Homelander where the temp is 50C. In other scenarios he seems to be capped at some other value. In 30C temps I could get him to hover by maintaining 107%, but in a 3rd test where the temp was 40C, he wouldn't go above 100%.

This appears to be a George issue. The PERF page says you will require 91% torque to maintain an OGE hover in the current conditions and weight. George seems to only want to pull 87%. Edit: Forgot to insert my screenshot.

Ah, you didn't mention George in your previous statement. You may just have a "George" problem. There are reported issues with George not being able to hold a hover in situations where a human pilot can. You may be better off commenting in one of those threads; the OP in this current thread was talking about losing the aircraft when coming in to land with a human pilot. Maybe try this one: https://forum.dcs.world/topic/350096-george-hovering-skills/ Yes, but the Ka-50 has twice as many rotors, yes? I'm half kidding, but the point is that the two aircraft are hard to compare because of their very different rotor designs.

That is likely the problem. If the player is used to Easy Comms being enabled, “\“ by itself works on the ground, and in the air. When Easy Comms is off, either in the player’s local settings, or if the setting is enforced in ME for the mission, then “\” only works on the ground, and “RALT+\” is needed in the air.

I'm not sure we need BIGNEWY in here to tell us that helos do not operate well in extreme heat or at high altitudes.

It's hard to say if this is just VRS, or if something else is going on. Can you fly an Instant Action mission and do a couple landings and see if you can capture it with a track file?

Last night we found ourselves in a good situation to do some buddy-lasing with the help of two Kiowas. They were each lasing on different codes from roughly 14km away from the target area. We were down in the valley, masked by a small hill, roughly 6.5km from the target area. We setup PRI and ALT channels on our missiles to match their codes, and set MODE to RIPL, and TRAJ to LO. (In Ripple Fire mode, your missiles come off the rail alternating codes between the PRI and ALT channels, so you can rifle two missiles back-to-back, and they each go to their separate targets.) We only had 4 missiles left at the time, so we rifled x2, delayed, then rifled 2 more. It took a bit of coordination to get everything setup, and work out who was going to lase which targets, but in the end it was worth it.

I opened this .miz in the latest version 2.9.5.55918 and re-saved it, then tested again, and the problem is still present. Here is the newly saved version, if it makes a difference. Data Link MBR DIR Test.miz

It very well could be an issue with cold starts in a multi-ship group. I always setup my missions with single units for clients, and we haven't seen issues of DL flat-out not working at all since the last patch.

So if you do load up with both chaff and flares, how do you dispense the chaff?

We were flying last night with 4 Apaches, all cold start, and weren't having issues with DL. This is with a single aircraft per "group" in the ME, and adding members manually with a C/S and ID at startup. @markturner1960 Was your mission setup with two-ship flights like the OP has setup?

You've got 8 aircraft in that mission with IDs 1-8. But some of them have Preset 1 setup with 4 members, and some with only 2 members. For example, these two aircraft have 4 members defined. But these two aircraft are 7 & 8, and they only have each other defined. You would need to go into the COM page and add the missing members manually if you want to communicate with them as part of your team.

LMC is useful when searching for targets in a general area while you are on the move, especially off to one side or the other of your aircraft. Get a good laser range to the area you want to work in, and then enable LMC. From there you can nudge it around with short blips. Before IAT was functioning in the module, LMC was your only option for tracking a moving target while your missile was in the air, or while tracking a stationary target while your aircraft was moving. Once you get the hang of it, it is quite powerful. And don't forget to update your range with the laser before enabling it, otherwise it tries to compensate for something at the wrong distance from the TADS sensor.