Tholozor

Realistically speaking, the entire JTAC system is a bit antiquated by this point, as normally the ground unit providing the lase would be able to set their designator to the code provided by the pilot, not the other way around. There's ways in the scripting environment to change JTAC laser codes via commands, but none that currently exist natively to the normal radio command menu. I personally don't know the commands myself, only that it's possible (and again, would require scripting). For the time being I think you're right to presume that your client slots should expect to utilize the same code, or have multiple JTACs available to split the load (assuming they don't end up cross-targeting the same unit at the same time and wasting ordnance).

More info on this subject here:

You can use it to adjust the TGP zoom level (independent of the FOV setting).

If the HARM is going after EWRs, that's a bug.

There is none. The FPS-117 operates at too low a frequency to be detected by the HTS or engaged with the HARM. The full ALIC table can be found in the Early Access Guide, Appendix B, starting on page 568.

Seems to be a correction of this specific issue: Personally I prefer it the way it is now, as I can turn the HMD brightness knob down to reduce the glow, whereas previously it wasn't bright enough.

Is making an accurate LANTIRN no longer the case after the addition of Sniper?

This has also been reported here:

Is there wind?

I still see it listed as 'Toggle helmet visor' under the Sensors category, so I'd recommend removing any mods and do a repair.

Those pages are hard-set in the mission computer for the Hornet, and are not not DTC-loadable like in the F-16.

The first JDAM to enter service (GBU-31) was circa 1998, first combat usage in '99 during Operation Allied Force. The GBU-32 was added to DCS much later than the -31 and -38, so it's likely they didn't have the historical filter date set (my sources put it's IOC timeframe circa 2002). Paveway III (GBU-24 in this case) entered service circa 1983.

You're free to have your opinion, but the flight manual is very clear about it. The only AR check for either model is to open the AR door and verify the RDY light is on and DISC light is off (if both lights are on then a relay has failed). D models then perform the DISC button check. Final check is for either model is to close the door and verify the RDY light goes out.

That also matches documentation I've read that specifies the INU is updated "continuously" by the MMC Kalman filter through GPS data. Curious. Too bad we don't have INSM implemented yet as a sort-of "debug" we could use to monitor simulated data.

My understanding of real-world documentation that I've read (outside of the DCS manual) is that the system nav solution is raw INS info, plus master nav filter delta. If the delta exceeds 300 feet, it will then apply an update to the INS position. Based on this, I would assume that position errors should never exceed 300 feet provided SYS ACCUR and GPS ACCUR are both listed as HIGH on the NAV STATUS page. If GPS ACCUR is HIGH, estimated horizontal error for Precise Positioning Service or Standard Positioning Service for the GPS satellites should be less than 300 feet (if at least four satellites are tracked).

It's in the -1 manual. The A/R DISC button check is noted as only being applicable to D models.

Not at this time.

The Hornet doesn't use the MXU-648, they use the CNU-188 baggage pod.

I haven't seen the circle mentioned in the M4.2+ tape guide regarding the Sniper pod's functions.

Already reported:

You could always set the CMDS programs manually in the DED, the DTC just makes it easier to set it up ahead of time.

Pressing FCS RESET in combination with the Paddle Switch is supposed to clear BLIN codes from the FCS display, AFAIK the full functionality of BLIN codes is not implemented. Disengaging NWS should only require the Paddle Switch.

MGRS coordinates can only be used on steerpoints 21 through 25.

Please provide a track replay we can look at so your issue can be diagnosed.