Scaley

There is a bug with the radio selection where DCS actually remembers two selections, the one you chose with the rocker and the one you chose with the button on the cyclic. If you start with radio 1 selected, then cycle to radio 3 with the rocker you would expect the cyclic button to then progress to 4 on the next press, but it doesn't. Instead it will go to 2 (because the last thing you selected with the button was 1). If you then press rocker down instead of going 2>3 as expected it will go to 4 (since the last thing you selected with the rocker was 3). Essentially DCS is maintaining 2 versions of which radio you are using. Only the most recent one is displayed and transmitted on, but the pre-set button always access the one that was selected by the RTS rocker, regardless of what is displayed. The fix is to map the physical button you are using on your stick to the RTS down button. That keeps everything in sync and working as expected and as displayed. This has been a bug since initial release and has been reported but not acknowledged the last time I checked.

The M229 is just a bigger-bang version of the M151. There is also a penetrator version in DCS, but since most of DCS's objects don't model armour or penetration I'm not sure it has any use. Basically the way damage works in DCS is just based on a sort of health bar for the vehicle, which is depleted by various incoming hits in an simple arithmetic fashion. Fragmentation is not modelled in any way at all, meaning whatever rocket you choose it will perform much worse than you expect if you land a lot of very-near misses and never actually directly hit the target. Essentially the only use for rockets in DCS is against infantry (where a near-miss will be effective) or buildings (where you can actually score direct hits). For infantry the 151 is more than enough. For buildings the 229 is probably a better choice since a high proportion of the rocket is payload, so you get a better "payload to overall weight" ratio. Either way the main doctrinal use of rockets (as an area suppression/neutralisation system) doesn't work at all in DCS, so most of the time you are better off either carrying a few for infantry groups, or none at all.

Indeed cycling the CMWS power a few times normally fixes the desync. Same with the ASE warnings from the RLWR - having the pilot switch it on then off, and then the CPG do the same, sometimes a few times, will normally make it so both people can hear the audio. Importantly, remember the RLWR volume is controlled by it's own knob, but the CMWS uses the ADF audio channel, and so is on the ADF volume control.

Yes, indeed a simple key command that cleared the database (and ideally synced between both crew in multiplayer) would be good enough to get round the issue.

So after some more testing it looks like the previous version only worked in calm#(ish winds), so I've had to back off the heading hold some more to stop it entering an oscillation mode with a crosswind.

Re-tested, and you're correct, heading hold was dialled down too far. Here's another version! EDIT: Removed

And this feature is still in the latest patch. Every online mission still has to start with deleting over a hundred points from the aircraft, and worse, since deleting a point doesn't sync in MP on a DS, both pilots have to delete them all. We might be starting to sound like a broken record but no one I have flown with online (which probably numbers over 100 different people) like or wants this feature. Maybe it's useful in single player, but it really really really needs to either be an option that can be set client side.

See this thread: If you search that Lua file for anything with "scaley" you'll find all the edits I've made tagged.

1) The yaw heading hold should function exactly the same with or without ATT HOLD engaged, and that's the behaviour I'm seeing with the updated config. (also using springless pedals) Are you saying you need to do more work on the pedal with ATT HOLD engaged vs without? If so, that's definitely not intentional. 2) ALT HOLD - yes, you will get associations. The vertical velocity damping is controlled by one number in the lua file, and this number is used for vertical velocity damping both with and without ALT HOLD engaged. Like Swift say, this essentially means the code has been set up in a way that it's impossible to get the correct behaviour. If you tune that number for normal flight, you don't get enough damping with ALT HOLD on. If you tune it for ALT HOLD engaged you get way too much damping in normal flight. The collective SCS channel needs at least 2 more variables, one for vyDamp with ALT HOLD on, and one for maximum sleeve authority. Ideally each vyDamp would be broken out into a more complete control logic descriptor set (e.g. ControlDeflectionMax, ControlDeflectionTarget, ControlDeflectionRampRate, etc) but there just aren't enough variables to solve the presented problem.

Removed.

This looks like it's tail rotor VRS. Some new lines of code relating to tail rotor VRS have been added to the flight model config.lua. If you set the tail rotor VRS effect to zero in this file the observed behaviour goes away.

null

This will be due to the tuning of the SCAS Collective channel which provides vertical velocity damping. When I did some flight model edits I produced this behaviour. If you reduce the SCAS channel authority (which controlled vertical velocity damping) but don't also reduce the ALT HOLD mode authority (which seeks an altitude) you get this overshooting behaviour. It's called "divergent hunting" in control system theory. Cause and solution are well described in any basic engineering textbook on the subject. I'll post a use-mod to fix it and try to remember to put it here.

Yep, been like that since release, but it's pretty standard across all DCS aircraft

0.2 (defaults are listed after the ** in all my edits) Absolutely no idea, I don't even own the F-16. Sorry.

DCS World\Mods\aircraft\AH-64D\FM\config.lua backup your original or you will need to do a repair to go back. Also bear in mind this will be overwritten when DCS updates.

Removed. Sorry.

That's super interesting, and seems to support the behaviour we are seeing where it looks like some parts of the aircraft avionics are cueing to one location, and other parts are going somewhere different. Maybe there are two coordinates systems/references in use, and some systems using one and some the other.

Just done some more tests and can't reproduce it reliably. One attempt to slave back to a stored point resulted in an offset between the TADS LOS and the acq source cueing cross, but most of the attempts were very close. What seems odd is the TADS never quite lines up with the acq source when you slave it back (when the acq source is a point). Even in the TADS video it shows the acq source slightly off centre while it's slaved. We also observed a possibly related event, where the TADS got stuck slaved to one source (in our case PHS) and the only way to get it to not follow PHS was to select another acq source. De-slave didn't work. More oddly that bug only showed up for the pilot, while on the CPG side the de-slave worked correctly and the TADS stopped following the PHS. In another related bug we got the TADS into a condition where it was showing as slaved to the GHS and panning around, but this wasn't showing on the PLT side, who saw the TADS as fixed forward. In this case the external model was showing the pilot's version of events with the TADS turret not moving even in the CPGs DCS external view. To summarise, it seems like there are many and varied ways to get the TADS to de-sync between the CPG and PLT, and between the TSD and TADS. The bugs layer up in a way it may be very hard to isolate one problem. One note is that from all this testing it looks like DCS net code is pushing inputs not states, so once the TADS gets out of sync it will stay out of sync indefinitely unless there is some user interaction. If we can get a clean track file with any of the TADS bugs showing we'll post it, but it's proving hard to track down.

The Tactical DCS community might well be a good place to start. https://discord.gg/5mTPF2Wz9a

Yes, indeed there never has been any kind of frag modelling in DCS. In days of old some weapons had bigger blast values that sort-of compensated for this. For several years now the blast values have been more sensible, but this now means that weapons that reply heavily of frag against soft targets (GP bombs, rockets, HE gun rounds, etc) massively under-perform compared to things that directly hit the target. There are a few mods which attempt to rectify this, but the main one I know of is very script intensive in that it basically detects every weapon impact and then triggers another set of explosions around the initial impact to replicate a frag pattern. I would guess this should be fixed as part of the ongoing damage model work by ED, but the timeframe for that is going to be LONG given the amount of work it's going to be across all the many many modules and objects in the game.

Replicated again online today, and track equally huge and likely not useful. We tested it by lasing and storing a point 1000m directly in front of the aircraft. The stored point was fine, but when commanded to slave the TADS slaved to a location that was NOT the point shown on either the pilot and CPG TSD. Error seemed to be around 200m. One observation was that all the errors for multiple stored points appears to be the same vector, so it's possible it's a coordinate system issue somewhere. (This was NTTR map for reference) nullThe screen grab shows the result of slaving the TADS to T03. TSD is panned and centred over T03, North up, and aircraft is 1.5km north of T03.

OK, that's interesting and may have changed. The last time I did extensive testing was pretty much straight after the Apache launched and there was (based on just repeating the same scenario over and over and tracking hit stats) a difference. I guess another run of tests is in order. If it is ONKY reaction time that seems worse than previously.

Apache and Huey recruitment both currently open.