Scaley

I don't think people are asking for George to be constantly scanning AND finding every single target instantaneously as he does now. What would probably be sensible is if George (as the CPG with the TADS) was able to use the sensors he had to find things without the Pilot (who shouldn't have to be working to find distant targets) telling him where to look. I think most people are asking for a more realistic solution, not an "easy mode".

There is a ghosting issue currently since the CPG displays are rendered twice when exported. It can't recall exactly which render intents are rendered in which space (cockpit vs exported) but you can absolutely delete render settings such that the cockpit displayed shouldn't render and they still do, only at half the previous brightness. You can also see the double render/ ghosting on the TDU since the two renders aren't in exactly the same place.

Agree with a lot of what is written above. George at the moment is fairly useless in a lot of situations. I suspect he will get a lot better during the course of the module. Given the main problems now are design choices by the people that coded him (especially in the PCG role) rather than his actually not being "able" to do something. For example, given he can scan and find all targets, and put them in a list, there is no reason he couldn't be doing that automatically every few seconds, other than you need an external macro to make him do it right now. My guess is that once George's CPG brain is better anyone in SP will spend most of their time in the back seat directing George, and only swap to the front for exceptional circumstances. The AIMBOT stuff really just need a very basic AI change to introduce a much bigger random dispersion on the round of ground units. It would also help if the aim-point of all DCS AI wasn't the centre of the pilots head, and was instead the centre of the aircraft model, but that might need quite a significant code change.

This is common in all module with the new FLIR system, and with lots of objects. I would guess it's going to be a LONG time before all the DCS objects are updated to the new FLIR standard.

I think the Helios framerate issue is mainly due to GPU RAM being filled, and absolutely turning off the things that contribute to that (shadows, high res textures, etc) will help a lot. Have you got a situation where the Shadows specifically make a big difference?

So it seems the fix (user created) for this was discovered some years ago and involves the lua edit described in this post:

This has already been reported.

The link I posted was to the exact time where he starts explaining how the SAS works.

It's coming apparently, but it's not here yet.

SAS Saturation warning. There is a reasonable description of the system and how to re-centre it here:

Most people here have spring joysticks. If you choose the option that ED have called "FFB friendly" it is actually the normal trim method. If at any point you feel it is messed up just hit the trim re-set switch and you'll go back to the default position. I suspect you'll really struggle with the Apache if you never trim as ED add more systems that use the trim position for a reference.

The latest patch has introduced a function that imports any non-hidden anti-aircraft threats into the Apache targets and threats database. The threats populate points T01 to T50 and appear to be added in the order they are placed in the ME, so the first 50 placed by the mission designer are the ones that will be imported. While 50 threats sounds like a lot for a simple single player mission there are plenty of MP servers with far more than 50 threats added. In order for them to show up on other aircraft TSD/SA displays many of these threats will not be hidden. Unlike other aircraft, which can display many threat rings the Apache can only display 50, and any threats loaded automatically remove space from the targets/threats database which is also used extensively to store targets by the CPG during engagements. Further complicating matters the threats are added in the same order they were placed in the ME, so the 50 chosen may be of no relevance to the aircraft in question. Most designers of complex MP missions and campaign settings start by placing strategic assets such as long range SAMs. The objects placed much later, or randomly spawned, are likely to be the short range systems of more relevance to an Apache crew. Overall, while the idea of the threats being automatically imported from the ME is good in principle, there are a lot of multiplayer missions and servers where an Apache crew are likely to load in and find that their entire target database is full of SAM threats, most or all of which are outside their operational area. The first thing they would then have to do would be to delete some/all of these points by hand, or (assuming bugs are fixed) just use points 26 to 50 and waste half their database. Pending having a DTC (which I assume is several years away) would it be possible to have a checkbox added to the aircraft options in the ME alongside the flares/radar/control priority settings that disabled the auto-import of threats for that aircraft? Several other fixes are possible, including client side code, extra options for each threat, and ideally an actual mission planning/DTC system (either GUI or exposed lua). However, all seem relatively complex to implement and a simple checkbox to block to the ME>aircraft import seems like the easiest "quick fix"

Linked to the newly added threats being automatically imported from the ME. If the Target/Threat portion of the point database is full from pre-loaded threats populated from T01 all the way to T50 any further target points continuously overwrite only T51. Best available reference is that pre-loaded threats should only be protected from automatic overwrite up to T25, so the first store done in the aircraft (assuming 50+ threats loaded) should go into T26, and then following sequentially from there overwriting non-safe points (T26 to T50). Track file attached. Waypoint 51 store.trk

Still present in 2.7.14.23966. Is there any chance of someone from ED maybe seeing if this bug is reported internally? It seems like quite a big deal when massive groups of objects inside your simulated world disappear.

What exactly are you trying to use them for? If it's a function inside DCS (like PTT to activate AI comms) then you can just bind multiple buttons to the PTT function inside DCS, so you could have a PTT on the cyclic and on a foot switch. Wrong aircraft...

Yeah, I thought the fully accepted answer (as per the SMEs comments) was that currently the crab value is doubled vs the real aircraft. If you do a conditions mimic of any AH-64 HDU video you find on YouTube you'll see that that rule of thumb is roughly correct.

When you say "reverts back" you mean the actual setting in the settings page changes back after you OK out of the settings window? If so then your opitions.lua file in \Saved Games\DCS\Config isn't saving for some reason. After you edit the setting exit DCS and look for this line: ["AH64PedalsTrimmingMethod"] = 2, Method 2 is the method for the setting swift mentioned.

I think Swift perhaps means "all the SMEs who have publicly commented so far". At the moment if you follow the procedure per the (real) manual the rotor RPM decays to the point where you have zero control authority and the generators drop offline. The rotor inertia may or may not be correct, but the current auto behaviour can't possibly be overall correct because the airspeeds listed as ideal in the real procedure result in guaranteed total aircraft loss. The minimum airspeed to keep control and the generators going right now is in the region of 100KTAS. I haven't exhaustively tested mainly because the actual AH-64 pilot in our online group immediately said it wasn't properly modelled so we kind of skipped past it as a technique on the assumption that we would get something better later in EA. Two ED SMEs I'm aware of have both also said it's work in progress and not to try to hard to learn it right now because the behaviour is grossly incorrect., The other thing, that may or may not be 100% related, is that currently the engine RPM is driven by the rotor RPM during autorotation, and engine RPM never falls below rotor RPM. Our best guess therefore is that the sprag clutches are either not yet modelled or for whatever reason don't disengage. That could explain (if the turbines have mechanical drag/friction modelled) why the rotor RPM decays so low in the recommended airspeed window. EDIT: P.S. Can someone move this to the Bugs sub-forum?

As title - ACM appears to be functioning all the time, regardless of the ACM switch position. Track - hot start aircraft, ACM switch in OFF (default position). ACM applied to FLIR video. Apache FLIR ACM.trk

Yep, indeed the bug that's being reported is that the Apache laser has it's "magic end" range set to 9999m (in common with the Combined Arms laser) instead of the usual DCS laser end range which I think is still 15,000m. I suppose "not sensible difference in physics" is more accurate than "bug" in the strictest sense of the word.

Yep, already bug reported in the bugs sub-forum.

So far the only times I'm really used it in DCS is rolling takeoff and hovering with a strong tailwind.

This has been one of the most requested ME features for over 5 years. I have never seen any evidence that anyone in the DCS team does ANYTHING in the ME because it's requested by the community. The ME development priorities appear to be solely internally driven. I never heard of anyone requesting the ability to draw lines, but we got that instead of loads of really basic functions like drag-to-select, a proper unit list that can be pinned, moveable toolbars, etc. I would hazard a guess there is a long term plan to have a new ME with data cartridge functionality as a new integrated system, and no one at ED is going to spend development time on updating the ancient ME code we currently have. This is probably a very sensible decision since the ME should be something that can be re-coded in it's entirety without affecting the rest of the sim. It would be great if someone from ED could give us some idea of where the ME is heading because from my POV a lot of people give up making/editing missions because the ME is simply so incredibly outdated.

Sure, attached is one example config that demonstrates the behaviour. Custom names of viewports have been used in the normal fashion. This post described the TDU ghosting being removed when switching to night mode, but what is actually happening is the 2nd rendered copy is made dark enough you don't notice/see it when mixed with the daylight brightness copy which remains permanently rendered. This Thread describes the same issue in places monitor_64CPG.lua

The odd thing is the Ka-50 has had a lua line you can edit to change the blend-in time for the trim for years (like 10 I think). The solution to this is known by ED, they just didn't implement it...