Swift.

When going into the WPN subformat of the DL13 DSPLY, if you have no MITL weapon loaded you will become stuck in the WPN page, unable to come back out. This failure mode happens whilst entering the page on a clean jet, but also when entering the page on a jet that has just fired its last MITL weapon. DL13WPN.trk

Its not isolated to VR though, it stutters in all modes of headtracking

CV natops

The verbatim answer from the book is Case 2 is above 1000ft ceiling, case is above 3000ft ceiling. Interpret that how you will

Case 1: will not encounter IMC, weather inside CCZ >3000-5 Case 2: May encounter IMC, weather in CCZ >1000-5 Case 3: Will encounter IMC, weather in CCZ <1000-5. Or nighttime from 30 mins before last light to 30 mins after first light. Not sure where you got your Under 3000 OR less than 5NM thing from. If the Vis is less than 5, it's case 3

It never did anything before, I doubt it does something now

I don't think it has any effect in DCS, because the tracking mechanic in DCS is more entity detection, than actual contrast track modelling.

Did you check in with the ATC? Was 'ACLS' turned on in the ME?

It hasnt worked for the longest time, if you've tested it in the latest update and the E M C O N text remains on the UFC for longer than a couple of seconds then yeah it looks like they might have updated it.

The parking brake state doesn't show in the controls indicator in any aircraft. What test conditions are you using to demonstrate this parking brake not releasing? Supplying a track would help identify what we are seeing.

I can only hope that a more detailed implementation of the rearm menu is imminent to allow us to populate specific zones, rather than picking from a selection. But in lieu of that feature being imminent then what you suggested seems like a really simple and straightforward thing for ED to add. Hopefully they are keeping track of these threads.

I haven't tested but I'm hoping night time will drive case 3 aswell

Because you landed.

This looks like the FCS bug that has been driving the ever persistent reverse ground effect bug is also driving this. It seems in general: Airframe pushed down = nose goes up Airframe pushed up = nose goes down So we see the nose go up then down during a carrier approach as the airframe falls in close and is pushed back up at the ramp. Similarly, we see the nose get pulled down at a shore landing because the airframe is being pushed up by the ground effect of the runway. So to conclude, it is now obvious that EDs priority needs to be correcting the 'nose suck' bug, to resolve both the burble issues and the revers ground effect issues.

Another request for the ACL logic to be untied from the AI Comms. I guess people must really want this ED (hint hint) https://forum.dcs.world/topic/299507-added-multiplayer-functionalityflexability

Shame, I guess we've got to start nagging again then lol

Does anyone know if this extends to all the covered HOCAS functions? Chop, Jettison, BUCS trigger?

Certainly, thanks for that tip. I have used (and still do use) mods like that for hornet commands. But I figured I'd throw this up anyway because I remember 9L saying how they were always receptive of binding suggestions like this.

Can we have a "ON else OFF" and "STOW else OFF" binding for the collective so we can bind this to an actual toggle switch?

This is IMO a very important concession that needs to be made to allow this feature to be properly used throughout the MP environment. However I would suggest even better than having to check in with the AI. Having it auto detect aircraft within the ACLS lock on window, and provide them with ACLS instructions regardless of AI radio status. Similar to how the cat crew can detect and aircraft taxiing into a certain box and will guide it onto the cat. So with this method the flow would be: Tune link 4 frequency as demonstrated in Wags video. CMD A/S + ALT + ROD are all blank. Marshal and commence as you would for ICLS approach with a human controller. Link 4 format remains unchanged. Approach to the 8mile mark. At this point the AI will 'detect' you as described above, CMD AS 140 + CMD ALT 1200 + CMD ROD 0, LND CHK Approach to 6mile mark. By this point the AI has already detected you, so it would proceed silently and show the same symbology as demonstrated in wags' video. So to effectively, the player inputs the link freq, flies the approach as normal (without AI ATC), and the ACLS auto detects at 8 miles and provides the correct data messages without the radio comms from this point in.

I wonder if you might have hit the nail on the head. Perhaps there is some coded delay to the start of the motion, like 0.1 seconds from static to motion when commanded. And what we are seeing is as you described, the sensor catches up and then has to wait for this delay (if such thing exists) again.

I'll check that tonight, thanks!

That's good to hear. Is the stutter visible in the clip I posted or is it all in my head?

Thanks Nineline, as a final thought, do we know yet whether this kind of detailed programming will be available as part of the DTU? It seems like the kind of place where this stuff would be coded IRL.

I assumed that based on what you said about this topic being hard to find info about, that what we had now was a best guess. So I was imagining that we might try to use what information we know the aircraft is being provided (look at the way the missile alert stops at the right time) and attempt to 'code our own logic' so to say. As Scaley wrote above, there is a way to effectively code a threat defeat system based on information we already have in DCS. We know missile TOF, we know what the aircraft sensors are seeing, we know the countermeasure efficacy. So all we need to do is put it together in a way that reliably and efficiently defeats threats. ie. 6 flares for a single missile warning, aka a single program run per launch warning. Basically what I'm trying to get at, is that if we don't have the info on the way the RL CMWS is coded, then we need to use the intention behind the real CMWS. And I'm sure the intent behind the system wasn't to waste countermeasures on programs being run after the threat is known to be a none factor. So our ideal solution, is for the above issue to be corrected in vanilla DCS. But if we cant have that, then it would be similarly ideal to be able to code our own behaviours into the CMWS, I imagine (and hope) the eventual mission planner/data card implementation will allow this, but I appreciate that is not quite ready yet. So in the interim, a simple lua file that would allow us to code this specific behaviour would help fix the immediate issue: That the AUTO mode of the CMWS is unusable.