Floyd1212

I just checked for myself and also see the issue.
Rocker down works fine.
Rocker up slowly and it seems to be reliable, but click it too fast, and it jumps to Preset 1.

Sometimes DCS will remap controls after an update, often for devices with axis that you never even intended to use that way.
You can see in this screenshot just after you "lose power" your throttles have been pulled back to idle.  That's when George starts complaining and tries to repeatedly arm the aircraft.

This is now how the IHADSS works, which is more akin to the real thing.  It does not have a "roll correction" component keep the symbology aligned with the horizon.
There was some discussion about it when it was "corrected" in a patch last year.  We had been spoiled with the incorrect behavior since the module launched.
As mentioned here:
https://forum.dcs.world/topic/353798-pnvs-and-tads-in-ihadss-are-roll-stabilized-again/
 

Page 254 of the AH-64D Early Access Guide talks about setting DIR routes.
Select RTE, then DIR, then POINT>? and type in the point "W44" in the KU.
 

In your Special Options for the AH-64D, what setting are you using for "Detent in LOCKOUT position"?
What do your "Tune Combo Axis" settings look like for your throttle, for both PLT and CPG?
After watching the track, it looks like you are using the mouse to bring up the throttles.  It definitely looks like the "detent" option has been changed so that you can take them straight to full LOCKOUT mode instead of stopping at FLY.

You will need to provide some screenshots or something of what you are doing for us to evaluate what the problem might be.
Are you truncating the MGRS coordinates so they are 4-digit precision, which is what the Apache is looking for?
So parking pad 29 at Senaki

Goes in as 38TKM 5593 8109

Which is right where it should be.

 

You need to drop the 5th digit as the Apache can only handle 4-digit precision for MGRS.
Your waypoint should be 51884 23287

Is that the nomex balaclava you are wearing under your helmet?
I don't fly in VR, but I have seen others have issues with where the camera is positioned in relation to the helmet to where you see too much of the player model.  Almost like if your eyes were pushed back another 2 inches into their sockets.
You can either mess with your VR settings to reposition things correctly, or there is an option in the Special Settings to remove the balaclava from the player models.

They are implemented in the Apache, and work well.
You can read up on them in the Early Access Guide found in the Docs folder of the installed mod.

The DOWN function on the hat would disengage both Attitude Hold and Altitude Hold, if either were enabled.  Is it not doing this anymore, or were you expecting it to do something different?

Keep in mind that while in a continuous scan, the FCR will maintain the same heading, regardless of what direction you turn, or what you tell it to do.
I don’t use the manual slew controls on the top of the FCR page, but normally use the TADS as ACQ, or PHS. (This is assuming you are using it from the back seat.).
If ACQ is set to TADS, I have George slave to my LOS and then do a single scan. Or, if you have a human CPG using the TADS to search for targets, I use the FCR with my PHS so I can scan independently from my CPG.
To get the FCR to stay forward, I think you might be able to set FIXED for the ACQ?

I replayed your track and saw what you were describing.
I then replayed it again, and took control before you lifted off, and was unable to reproduce the issue with my setup.
I would double-check your binds and make sure you don't have something silly bound to your Weapons Trigger Switch - Second Detent, like maybe your left mouse button? 😉

I think you will get a little push back on this statement...
Raptor9 had a great post a few days ago:
 

I’m not seeing any new behavior with the collective not syncing on startup.
My guess is you have another axis bound to the collective and there is “competition” for what position it should start in, then nudging your physical collective sets it back to zero.
Having controllers get auto-assigned an axis is something we have seen after patching. 

With no binds for the throttle axis at all, and using the mouse to raise the throttles in the cockpit, the problem still occurs?
Check that axis across all your controls. DCS likes to auto assign axis to controllers that you never intend to use for those functions. 

I think what you are seeing is normal.
I hopped into a cold aircraft and yanked on the collective from 0-100% and the in-game animation of the controls is delayed some.
I guess I never noticed it because it is a non-issue when actually flying the aircraft around.  Your goal is to be smooth with the collective, so you don't over/under-speed the rotor system, so keep your adjustments small and slow.

You are talking about getting target data for a Lima prior to launch?
Do you see the TARGET DATA? prompt at the bottom left?  If not, de-WAS missiles and WAS again to start over.  You may have data stored from a previous spot you were lasing.
Your ACQ source doesn't matter in this situation.  And whether they hit or not is a totally different question.

You don't have rockets WASed.
This indicates your CPG has rockets WASed:

This also indicates you don't have rockets WASed:

When properly WASed, as shown in the snip from the manual below, notice the differences in the areas I boxed in blue above:

You must use the binds on the cyclic or HOCAS to WAS weapons, not by pressing buttons on the MPDs.

Agreed.  An option to automate the process would be helpful.
In the meantime, the saved Snap View is the best answer.
Bring up WPN page Press Boresight Press IHADSS Hold down Snap View button Press BS NOW Release Snap View button Yes, it takes a few minutes to set it up the first time, but then you avoid the hassle for each cold start going forward.

Maybe post a screenshot of all your analog axis bindings for the CPG seat?  It is probably double assigned with your pedals or some other controller.

This seems to be working for the rest of us.
Don't forget, you need to assign the show/hide button for both the PLT and CPG seat.  Then the U/D/L/R functions of the hat are assigned in the George AI Helper list.

This appears to be a known bug, mentioned in the Bugs and Problems forum:
https://forum.dcs.world/topic/332503-external-fuel-tanks-and-hot-vs-cold-starts/#comment-5280033
 

Page 240 of the new manual describes the procedure.
Before you can type in a point using the KU you need to press L1 for "POINT>?".

Page 74 of the (new) manual does a good job of explaining this.

 
8. SYM Rocker Switch. Controls the brightness level of displayed symbology on the TDU or within the CPG’s HDU. When the CPG’s selected sight is HMD, the symbology within the CPG’s HDU will be adjusted. When the CPG’s selected sight is TADS or FCR, the symbology brightness on the TDU will be adjusted. The symbology brightness may be incrementally adjusted using short presses, or continually adjusted using continuous presses.

9. BRT Rocker Switch. Controls the overall brightness level of the TDU or CPG’s HDU. When the CPG’s selected sight is HMD, the overall brightness level of the CPG’s HDU will be adjusted. When the CPG’s selected sight is TADS or FCR, the overall brightness level of the TDU will be adjusted. The brightness level may be incrementally adjusted using short presses, or continually adjusted using continuous presses.

10. CON Rocker Switch. Controls the contrast level of the TDU or CPG’s HDU. When the CPG’s selected sight is HMD, the contrast level of the CPG’s HDU will be adjusted. When the CPG’s selected sight is TADS or FCR, the contrast level of the TDU will be adjusted. The contrast level may be incrementally adjusted using short presses, or continually adjusted using continuous presses.

11. Asterisk Button. Resets the overall brightness and contrast levels to their default settings. When the CPG’s selected sight is HMD, the overall brightness and contrast of the CPG’s HDUwill be reset. When the CPG’s selected sight is TADS or FCR, the overall brightness and contrast of the TDU will be reset.

Here is a thread with a SME discussing the tail rotor thrust after the changes made in OB ver 2.7.18.30348.