Swift.

I've been wanting this for a while actually. But instead of averaged flight controls, I'm thinking additive would be more suitable. With average controls, if I give 100% left cyclic input, and the copilot leaves his stick neutral, the aircraft would only output 50% left cyclic. With additive, if I give 100% left cyclic input, and CP give 0%, the aircraft outputs 100%. To admiki's point, yes in the real world its not suited, but in DCS if its your only module its what you are going to use... And besides, its not like a more 'trainee friendly' helicopter has these cooperative control laws implemented either.. The thing I can envisage this helping more than just the trainee-trainer inputs, is smoother control handover. Instead of: 'You have control' 'I have control' Pilot releases, CP takes over, aircraft jumps around a bit It can be: 'You have control' 'I have control' Pilot slowly starts easing to a neutral position, CP adds his controls as required to stabilise the helicopter, until CP is fully flying and Pilot is fully off the controls. Now, this idea of cooperative control law only really works with those using centre sprung sticks. So I would also agree with admiki that we need the 'preview' indicator, so that in the control indicator we can have an indication of: Aircraft control position (red diamond) Pilot control position (eg yellow X) Copilot control position (eg yellow O) This would hopefully allow a more smoother transition for all control setups. ps. as an interesting thought experiment, I wonder if there's any provision for force feedback controls. ie, can the non-flying pilot's controls be 'driven' by the flying pilot.

Do the head movements not match what your copilot is actually doing? In which case, if the copilot is actually moving his head, then the model will match. Unless you mean something else?

On the M261 example alone, its more than just adding the external model. Think about the rocket zones, KW would normally be using just two zones for the 7 shot pods. How would you have the extra zone for the 19 shot pod modelled? I doubt there are any manuals or examples around of how that works, so would you just make it up? Hopefully that highlights how some of these things are more complicated than just sticking an extra CLSID into the lua.

You mean in VR? I run 2D but Im surprised to hear its not bino in VR.

The head position was updated in the same update that gave us the pilot models. So I suspect that adding the model to the cockpit revealed that the default view position was too far down and aft. The current position certainly seems correct, anecdotally the TDU should stick way out and really be in your face, as it is in DCS now. If you dont already have some form of headtracking, ie VR or TrackIR, then yes I very much recommend something like that. It completely changes the DCS experience IMO.

I think what Scaley is saying is that whatever we have in DCS is the design intent of DCS. Obviously the way it works IRL is different to DCS. But there is no intent to dig into the accuracy of the CMWS system against real world, because its a very sensitive area. So instead of feeling bad that the DCS system delays more than you think it should, we would be much better served by understanding the behaviours and limitations of the DCS system and building our tactics based on that. Namely, that it has a slight delay, that it can't discriminate between missiles fired at the aircraft and other missiles, etc. What we have is a rudimentary system to detect any launch within X amount of time, and that's all we have.

I suspect what you are seeing is the FARP. Especially considering the symbol shown on the TSD is that of an airfield.

C89 is just the number of the point. Meaning its the 39th control measure entered into the system. How do you know thats the bullseye location, afaik apache doesnt have a way to show any kind of bullseye.

The stabilator wont appear to move in DCS if you arent the pilot on the controls (a bug). Could it be that the other pilot has the controls when you are testing?

Are those RCEFS thoug or just those monster tanks we have been in dcs? Because there are combat fuel tanks that are smaller and are actually crashworthy WAH64s have been flying with them for a while. I think it's a relatively recent thing for the US Apaches though.

Well put. I've noticed this with a lot of the multicrew systems in the apache. It all seems to be input synced rather than status synced. Which means its tremendously prone to desyncing. It feels like every multicrew bug that arises is as a result of this kind of desync. There appears to be no way to resynchronise once someone drops for a bit, unless its through an input with only a single possible outcome, ie slaving the TADS to FXD.

That wont apply to those using springless cyclics.

Doesnt Huey have something where it shows both pilots control inputs independently on the controls indicator? I havent flown it, just heard stories. In any case, that would be a good solution. If you had a preview of your control inputs for example. You could match yours with the currently flying pilot and prevent any issues.

With helicopter performance there is this concept of having a 'bucket speed' what that effectively means if that as you speed up from stationary the torque required to fly will reduce, until a certain airspeed at which point it will start to increase again. For apache you can estimate that certain airspeed (the bucket speed) as about 70 kts ish. So if you are stuggling for lift, you need to get moving forwards to about 70 kts. If you are able to hover IGE then you can accelerate whilst still in IGE. If you cant even lift into IGE, you can roll along the runway until you hit that speed.

To be fair, 2 fuel tanks on its own is a hefty load and not something you'd be lugging around into combat. Add another 1000lbs on top of that, and you can understand the issue. Do you have the FCR fitted too? Because that'll be another 700lbs ish. If you want to be impressed by it's capabilities, note how you can load 16 hellfires and still takeoff fine and have enough fuel to endure for 3 hours or so.

Do you have a track for everyone to have a look at?

Sure, but there's no way to not have the TADS symbology on the IHADSS so you may aswell just remove the whole lot. Because the TADS symbols are useless without the video.

The risk with what VKing said, is you lose the ability to use the PNVS if you need it in a hurry. The best advice I can give is don't use the IHADSS as CPG. If it's night, having one guy on NVG and the other on PNVS can be a help of it's own.

I mean you can, I don't have any more say about what happens than you do. So there's not much I can do other than sympathise, I'm afraid.

By CAS do you mean the rate dampening? ie the sleeves just act to remove errant wiggles and don't try to hold position. Just trying to figure out if my previous understanding was mistaken.

The way those secondary comms work is its the last entered comm. PRI=B SEC=A I enter C via the Man or via a preset. PRI=C SEC=B I enter D via the Man or via a preset PRI=D SEC=C As for it defaulting to 127.5 I've heard that mentioned before, but never experienced it myself. Maybe try out what I said above and see if it still presents that failure mode. If it stops that'll be an interesting thing to report. Maybe there is some hidden pri/sec thing going, worth a go I think.

Interesting, I'll have to give that a try.

Hmm so the interesting bit is in the crash log you have this line as the last non-crash action. The other strange thing about comparing my logs to yours is you seem to have a lot of corrupt damage models, whereas my log doesnt show any. I'm still trying to figure out what is causing the crash because there isnt a consistent trend of 'X thing happens then it crashes' Edit: FWIW I run exported displays too and havent seen an issue, so I not sure its as simple as exports=crash

Couldn't the same thing be said about being able to edit waypoints in the jets as we already can? It's not like people aren't routinely using 3rd party programs to act as a DTC of their own. To the OP though, these look like really slick renders, thanks for sharing. The one thing I will continue to stress whenever this kind of thing is brought up, is that no matter how good or bad the GUI is, the MOST important feature is having all this data stored in a plain text lua. Because if we can't save load and share these loads around, then it's completely useless.

Idk if it would cause issues, but you got scripts called DCS_to_FLYPT_Mover, and SimTools_DCS_Exp_Hook that are throwing some errors too.