Frederf

DC to AC electrical converters? I assume engine ignitors need high voltage AC for spark.

There have been improvements to the IIR seeker, e.g. the AGM-65D-2 although it only mentions faster seeker capability and not necessarily any clarity. Notably the "WGU-10" is the D seeker but so is the WGU-8 and WGU-22. This suggests that there have been at least three seekers for the "D" Maverick over the years. It's hard to believe the seeker section would be made identically from 1983 to 2022. Usually humid air has an issue with thermal-spectrum EM attenuation, not that "hot air" produces interference. Hot, dry air is essentially optically clear. Hot air will have more moisture in it (and thus more attenuation) for a given RH but it just being hot outside doesn't itself reduce contrast. We say "IR" like everything IR operates the same but an IR AA missile is tuned to a shorter wavelength than say the FLIR pod for night navigation. Different water droplet sizes mess with different IR sensors differently as when the size of the droplet approaches the wavelength the attenuation is high. In general longer wavelength has better "weather penetration" than shorter. I have read that Maverick is often seeker limited over kinematic limited but it was in reference to the target size for centroid tracking. Some objects have too small of an angular size at max kinematic range for tracking. Clearly there are reports of range reduction by attenuation by water-air condition. In DCS I have found that my ability to see the target distinctly is hampered by the video presentation but the actual missile lock ability is not. If the missile is pointed at something that I can't see at all with my human eye but I know it's on target (TGP or similar cueing) it will track far, far beyond what the video shows as a valid object. It would be nice for my human ability to see a distinct object and the simulation locking/not locking whatever's in the middle of the crosshairs to be roughly the same performance. Lastly while "in poor conditions" missile video may suffer but I haven't found a way to see reasonably a boat on an ocean at even half kinematic range. I could try different temperatures, seasons, weathers, etc. but I doubt there is any difference. Visually it looks like the video is worst case environment in all environments.

Parking brake

There is a value for angle of the left/right viewports. The default is -1 +1 radians which is about 57°. That might be a bit too much if it feels like the wings are swept forward. Try maybe +- 0.5.

This is from the options file in the AG_Grom.miz mission: ["MiG-21Bis"] = { ["Pitot"] = false, ["Engine"] = false, ["Experimental"] = false, ["Shake"] = 100, ["CPLocalList"] = "default", ["Reticle"] = false, ["Freeze"] = false, That's causing the following special option to be overridden to the unrealistic behavior. Oddly other options like changing the cockpit livery to Chinese isn't overridden. Notice how my "REALISTIC ASP IR A-A MISSILE RETICLE" is checked true? Well, in that particular .miz it's set to false which is causing unrealistic pipper behavior. I know it says "A-A missile" but it's applying to the Kh-66 as well. The mission setting overrides the user special options setting (Force GAMEPLAY & MISC. options for All Missions and Campaigns button has no effect here). That option was in my opinion a mistake. In an earlier version of the software the pipper behaved in the unrealistic setting. It was later pointed out that this behavior was unrealistic so developer "fix" was to make realistic behavior an option which had to be enabled specially. We are now living with the consequences of that decision. In a similar way a multiplayer mission can force this unrealistic behavior Pipper ain't supposed to stay on target. The ASP cannot drive the pipper laterally in the sight glass except to electromagnetically dampen or cage it to center. It is a completely fictional capability to have the pipper driven equal to missile seeker or radar LOS. Firing of Kh-66 with this RP-22 radar is complete fictional capability anyway. I would be interested to see weapons manual from MiG-21bis/RP-21/ASP-PFD which can deliver Ghrom what was sight procedure. In DCS practice I always set sight to CC fixed and MAN manual to set -1.5° pipper angle manually. Here is that one mission with that false changed to true so the reticle acts realistically. And here is a track of flying that mission. And lastly we notice that the Kh-66 isn't acting like a beam riding missile realistically at all. Instead it's acting like a homing missile. AG_Grom.miz_12022022_21-24.trk AG_Grom.miz

TWS can have more than 10 as well. The TWS limit is 10 system tracks. The tank tracks have a much higher limit. I don't know what the RWS contact limit is, if any, but it would be higher still. RWS has benefit over TWS in terms of track quality when in the SAM/twoSAM submodes. AIM-120s employed against a SAM bugged target will have a higher Pk as the radar has a more accurate understand of the target(s). TWS as described to me by an active pilot is "so bad we don't use it." TWS is the only mode which 3 or more simultaneous targets can be engaged by AIM-120. There are other details like SAM has continuously-variable azimuth limits (up to the 60/30/10 limits) depending on the situation. TWS is simply 60/25/10 static. In some versions of the radar TWS is unable to select 160nm range suggesting its performance was poor. The biggest practical difference is that TWS shows maximum tracks and RWS dwells on tracks of interest. Dwelling improves track quality of the targets the radar dwells on at the risk of alerting those targets they are more than painted.

The INS keeps track of a quantity known as steering error which has nothing to do with heading. It's what drives the "W" symbol on the MFD, GCSC-FPM relative positioning, and lateral autopilot. In short, zeroing out the relative bearing is incorrect behavior. Zeroing out steering error is correct behavior.

Turning the CRS knob on the HSI will provide crosstrack deviation relative to the entered course by CDI position in a similar way to say the A-10 or any civil VOR instrument. There's nothing specific on the HUD about steering for a particular selected course to approach.

DCS uses wind state to determine which ILS (or PRMG or 2NDB) systems are on and off for a given runway. DCS always picks an approach direction for radio landing aids, turning them on for one direction and off from the other regardless of if either system exist. Last I checked there are edge cases where ATC directed runway and ILS operating runway are not the same but 90% of the time they agree. Primary method of identifying a localizer in real life is by the Morse identification code. That let's you know identity at least. Dual NMSP TACAN/ILS selection is perfectly normal and useful. With both selected the TACAN drives a bearing needle and the distance readout while the ILS controls the CDI and GS needles. TACAN or simply visual or any means of knowing you are in the rough localizer corridor is a good start. Within +-15 degrees of the runway centerline and 10-30mi at 1-3 thousand feet should be fine. When the ILS is NMSP selected and the CDI is not flagged you're receiving valid localizer. The next step is to check if it's forward sensing or reverse sensing. By flying left and right of the centerline verify that the needle shows the correct direction to return (set inbound course on OBS to make this easier to see clearly). If you're unsure fly low over the runway along the centerline picking up the glide path as it centers, it will only work on the front side of the pattern.

SAM should have a much better track quality than TWS. That is reality. Of course tracks are extrapolated. That's what tracks are, persistent modeled object which exist distinct from their data points. That's why they have timeout lives when the updates no longer support them. Tracks are the same concept in any mode. TWS generally has less detailed information because it merely sweeps over the target instead of dwelling like SAM does (which gets a few in a burst approaching a mini STT). The introduction of DTT has completely obliterated the concept of SAM AUTO and SAM MANUAL which existed briefly after SAM introduction but before DTT. The nature of the extrapolation may be in question. The level III, IV, V EEGS pipper for example are progression through the understanding of target motion from position to velocity to acceleration (more and more derivatives of position). RWS "hits" are position. Tracks are at least dx/dt minimum if not d^2x/dt^2 (say with STT levels of updates). Unsure if radar ever attempts the third derivative and certainly not beyond that. Track quality goes from TWS to SAM (two tracks) to SAM (one tracks) to STT in order of worst to best. Be aware that even in RWS with no tracks displayed the radar is always constructing tracks in the background. It doesn't suddenly remember to do its homework when a track might show up on screen. It tirelessly builds track files from hits at all times which is why switching from AGR to TWS takes a while to build tracks while switching from RWS to TWS already has those tracks ready to go.

All the challenges with the other sensors aside, the missile video itself is impossible to distinguish the boat from beyond 3mi IIR 5mi CCD.

As far as I'm aware the AIM-120 has such a feature but the APG-68 does not. Best you could do is a maddog launch along the azimuth.

No, in visual attack modes the TGP backs up slant ranging.

It used to in a previous version.

Just put it in the center of the MFD. There might be some advanced techniques not having it centered. I have noticed in DCS that I got wrong steering when target was going away so maybe it's not working perfectly.

The ideal would be a radar to TGP progression and then an automatic handoff to missile. But that's not fully developed. My attempt would be TGP area slightly ahead and SOI WPN for a manual slew and track. I see the frustration. First the radar is slewing in an odd way that makes it harder to use, then it's not FTT/MTT instead just freezing on designate. TGP isn't coordinately well with SPI. Lastly the AGM-65D video does not highlight the boat at reasonable ranges. Can you find the speedboat at 7 miles? At 3 miles? And this is with the BRT/CON rockers adjusted well. The default values are much worse. Here's AGM-65H at 5 miles: That's significantly easier to see and still not that great. You can get TGP video (again, BRT/CON rockers and MGC and adjust LVL GAIN) and barely see the boat at 8 miles or so in either low zoom EXPor high zoom NORM. From there I just kept with the boat in area track until I was within missile range (5-7mi) and then timed my SOI change and TMS forward to command track based on where TGP was pointed (practically impossible to aim using missile video at that range). Usually it works and missile tracks even though I can barely see anything. Example track: F16 Mav Speedboat.trk

Runway lighting will work (at least at night) but you have to follow the ATC procedure exactly which can be tricky. I believe the same works for standard carrier. I don't know about super carrier.

It is not required for IFF to function to fly together. It happens in reality where some participants don't have compatible equipment or any at all. Framing of IFF as a go/no-go item is lacking substance. It sounds more like a video game fan railing against removal of fast travel in an MMORPG than anything else. I think IFF would be passed in net code as all the info including what system type it is. There are many types of IFF and IFF-like systems in history that DCS might be called upon to model. There is 1943 Mark II, pre-SIF Mark X, Soviet tactical, SOD-57, even light signals like the P-51 has underwing, a flag held out of a WWI biplane, plus plenty I don't know about. Shared info of objects shared over network is a powerful tool and it would be a mistake for the underlying structure to not be scalable beyond the narrow example of 50-90s NATO mk xii.

Famously the "other sim" didn't have IFF at all until recently. Imagine DCS but none of the IFF equipment worked, ever. That's how that sim was for about 20 years and not only did people use it successfully, most weren't even aware there was something missing. The users of that software went decades without any IFF returns, magical or otherwise. While it took more awareness and reliance on other means to ID targets, most users got plenty adept at doing a full spectrum of operations without it. Only in the last few years when IFF was introduced has it even been possible to get any IFF information. There was a learning period but it was learned pretty quickly that there was a provided IFF plan and cooperating AI. Most modules have Mode 4 capability which is dead simple to use. Developers will have to fix some silly default panel states like the zeroize setting on the knob being set by default (which I think isn't even possible IRL). People will learn. People will complain and gnash teeth but they will learn. A simple coalition-wide policy is a good, easy to use starting point and most will not venture beyond without some automated help or sophisticated need. The first thing to do is to enable transponder coded replies in the netcode based on user cockpit settings. Leave it that way for a year maybe with some AI ATC validation check in the radio menu. There will be lots of little bugs to work out. After all that data is around for a while and everyone's used to the idea then you one-by-one changeover the interrogating modules to use the actual codes present in the netcode and away from the coalition-based returns. Some modules may never switch over to real IFF and that's fine. At first you just have a mission-editor default code policy. Most most most missions will just use that. @Ross If you leave the MiG-21 transponding equipment off you will still show up as friendly to interrogations from others, only the interrogating abilities are dependent on turning on the interrogators. This applies to the Mirage and every single other DCS module with one exception. The only true IFF is JF-17 to JF-17 interactions in DCS.

Not quite how DBS works. The "dead spots" are due to a weak relationship between Doppler information and angle. "Cross range resolution" means resolution in the azimuthal direction. For a given Doppler color precision there is a certain range of azimuths which correspond. This window is narrowest at 45 degrees relative to the motion and vanishes to zero at 0 and 90. The sharpening is only occurring in the "beam width" dimension which is why the technique is called beam sharpening. Range resolution is unaffected plus anything that's moving over the ground gets sharpened the wrong way thus blurred.

Cool I messed with it before but didn't know if it worked.

"FTT" and "MTT" are for ground locks but yes, no motion prediction for aiming. Same for any senor.

I think there is some issue with frozen radar where the displacement is doubled.

Combined Radar Modes (CRM) is the term for the group of AA radar modes which are presented "top down". The alternative is ACM which is the group of all visual radar modes. All AA radar falls into one of those two categories. CRM includes: RWS, TWS, VSR, LRS Range while scan (RWS) is the baseline radar that shows targets as contacts which is positional information. This is in contrast to track while scan (TWS) which produces tracks which are positional plus motion. SAM/DTT are simply RWS with one or two tracks one of which is the target of interest "bug". SAM/DTS doesn't really apply to TWS. TWS with a bug would be similar to SAM and dual-target-track doesn't apply because TWS can have 10 tracks so having "bug plus one" isn't a feature.

DTC load or manual menu entry very similar to A-10C.