toilet2000

I think that would be something like that, but telling his pilot this is a PD-only contact. The workflow for a RIO would be to stay in RWS, if there are no contacts, you switch to PD Search, if you pick up something, then you know it's extremely far out, since RWS doesn't show anything. Then it's a matter of juggling between PD and RWS until the target shows up. Once the target is close enough, you then switch to TWS and so on. I think it's possible to lock the target up to STT using the DDD in PD Search too, if you don't mind the reduced SA (or if the target is confirmed to be alone).

It's already been said countless of times that they are aiming for a Summer 2019 early access release, and not 2 weeks ago they confirmed it was still on track. Seeing how they said: before Oct 1st pretty much confirms what we already knew anyway: released by the end of the month.

At around 15 km, the Viggen's afterburner flames out, so that explains the sudden decceleration you're experiencing.

Bumpy bump. This would be a pretty nice fix for VR. It's barely useable right now because of that.

Have you checked in with your MB manufacturer if there’s an updated BIOS available? Some 2nd and 3rd gen mobos are not compatible with Pascal and above cards without a BIOS update. That would explain why the card is in safe mode. I had to ditch my OEM HP mobo back when I had an i7-2600 and I had just bought my 1060-6GB because it would simply not boot. New mobo in, updated the BIOS and bam, worked like a charm.

That's what the "FD" autopilot mode is for. Same for FD bombing mode, which is an AUTO release mode coupled with the autopilot.

As far as what I've seen on the Discord and from other sources, it seems like the timeline was: Olivier was the lead artist on the Bo-105, and according to other Polychop members, there was a pretty big argument on what would have to be coded and how (I don't know why or about what). Some members decided to implement the code logic for the Bo-105 without Oliver's consent and in "secret", leading to an almost "ready for release" product (See this: ). At that point, for some reasons unbeknownst to us, a bigger argument lead to Oliver's departure from the company, maintaining is IP on the Bo-105 art and models, while the rest of Polychop kept their IP on the logic and code. Now Oliver (The_Fragger here on the forum) is working on the Bo-105 alone, but can't code, so another not-announced-yet third party was contracted to finish the code part. Disclaimer: what I just explained is based on my understanding of the situation and what was said both on Polychop's Discord and other places (such as this forums). Some parts may be inaccurate or wrong.

When your targets are insurgents hiding in villages with a high collateral damage chance, for sure you’re not gonna rely on radar imagery. Same for CAS, where the JTAC is basically guiding you in. In those cases, an AG radar seems useless. Given that’s the battlefield conditions the exact same Hornet we fly flew in, for sure pilots accounts will describe the AG radar as almost never used. But in a all-out war with night/adverse weather strikes and such, having an AG radar is a must, just like it was in Desert Storm.

That’s true for any Harpoon launch, with or without a designation. A designation with a Harpoon is basically a "look for ships around this point", just like the Viggen’s RB-15F Bx8 waypoint.

Nope, the Hornet's radar has full GMTT/GMTI (Ground Moving Targets Tracking, Ground Moving Targets Indication) with synthetic bricks using Doppler-based tracking. In fact, like Beamscanner said, most AG radar modes actually use the Doppler effect as a mean to produce an image.

AFAIK, it mostly uses the Doppler returns, but a much lower "rate" than typical a2a radars. Wiki has an interesting article on GMTIs. There's probably a bunch of other stuff going into that, as some radar systems are able to distinguish between several subtypes of targets (eg tracked or wheeled vehicles), such as the Longbow radar on the Apache. My guess is that it seeks specific return signatures. Target ID surely happen using EO/IR or on-the-field reports with sensor/data fusion accomplished by computers and/or operators in the Joint STARS or any C2 aircraft.

Can't wait for that! :)

Not at all. ELINT = ELectronic INTelligence. The Viggen ELINT pod simply infers RADAR EMITTERS positions from various sources (triangulation, strength or other), but the target has to be emitting radar energy. Currently, no module is able to track GMTIs. As for datalink, the A-10C can transmit SPIs or receive JTAC requests (hardly a form of ground target datalink) and the Ka-50s can share targets from 4 different types with up to 4 wingmen.

Yeah can confirm this issue on my end too, even after this last Wednesday's patch.

I understand the low refresh rate of the target's position and direction (because of RWS scan volume), but the HUD is absolutely useless right now when doing any kind of maneuver. If a target is detected, the HUD box for L&S target refreshes at the same time as the radar, which does not make any sense. The HUD should have a much faster refresh rate, since the attitude and velocity of our own aircraft updated much faster. This way, the target box should stay (or be extrapolated from the last velocity track) in a point in space, the HUD adjusting at the normal refresh rate for own aircraft maneuvers, but at a low (RWS) refresh rate for target aircraft maneuvers. Currently, the target box is static with respect to the HUD FOV (updated once per target measurement), whereas it should be static (or with a velocity extrapolated from measurement) with respect to the world's coordinates, with the target world coordinates updated at a lower refresh rate. Here's a quick drawing of what I'm trying to say:

@Captain Orso Never thought it'd be that hard to understand... And you should really change that attitude. Someone else noted the Dunning-Kruger effect and I found it harsh, but to be honest with that attitude it does seem to be pointing this way. Again : CIP (computed impact point) is independent from the CCIP cross CIP: The computed point where the weapon would hit on the ground if the selected weapon was released at this instant CCIP cross: The cross symbology which can mean several things: - If CIP is within HUD FOV (as in, can be seen through the HUD) --> CCIP cross is exactly on top of the CIP - If CIP is outside of HUD FOV (as in, cannot be seen through the HUD) --> CCIP cross stays at the limit of the HUD FOV, becomes dashed. The CCIP dashed cross is then used to designate an AUTO point if Weapon Release is held down, just like the Balls and Chain of the Hornet. You can read on that procedure in the NATOPS, here's a snippet: The reflected CIP cue (i.e. the thick horizontal line on the BFL) is shown if CIP is outside HUD FOV, as is shown on this image: * Note how the symbology is NOT like the Hornet, meaning the CCIP cross is NOT used as the reflected CIP cue. A different symbol (thick horizontal line) appears and the CCIP cross (now dashed) stays on the HUD too, now used as a designation symbol. P.374 (at the bottom) of the A-10C manual describes 3/9 and 5 mils CCIP Consent to Release modes, which is exactly what CCIP-to-AUTO conversion is, albeit with a different symbology.

With the TGP coming at one point to the F/A-18C and the fact that all other modules using the Litening TGP suffers from that, I wonder if ED will change the range limitation of the Laser Designator. Currently, the range sits at around 8 NM in-game, while it should be much more than that. According to Global Security, the requirements for the LANTIRN 40k' pod was 17.3 NM in combat lasing mode, which it exceeded. Considering the LANTIRN is an older generation TGP than the Litening (and even more so the ATFLIR), the Litening should surely be able to designate above the 17 NM range in good weather conditions. On top of that, the current range limitation effect makes the designated point move in 3D space instead of simply scattering and returning no designation, see this video for more info:

Again, wrong. The reflected cue for CCIP is the thick horizontal line shown below the velocity vector (if within 4.3 degrees of the velocity vector). Figure 2-59, left side, at page 2-59 perfectly illustrates this. Citing page 2-69: If you read the NATOPS carefully, you'll learn that: - The CCIP cross becomes dashed when limited (solution outside of parameters or outside of FOV). - When the solution is outside of HUD FOV (such as in the top right side of Figure 2-58), a reflected (about the lower end of the BFL) CCIP cue appears (thick line below the VV). - When the solution is outside of HUD FOV, immediate weapon release is inhibited. - CCIP-to-AUTO release happen when the CIP solution is outside of HUD FOV, but the Weapon Release button is held down. Symbology switches from CCIP to AUTO with the designated point at the dashed cross position when Weapon Release was first depressed (and held down). - CCIP-to-AUTO is aborted (or reverted) when Weapon Release is released. Figure 2-61 perfectly shows the attack profile of a CCIP-to-AUTO conversion attack. TL;DR: CCIP cross is always shown on HUD. When CIP solution is outside of HUD FOV, the cross becomes dashed and stays at the bottom. Holding down Weapon Release designates the target under the dashed cross for an AUTO release, as long as you continue to hold down the Weapon Release.

Computed Impact Point =/= CCIP cross The CIP is just the point of impact of the weapon, whether or not it’s in the HUD FOV. The cross is always in the HUD FOV, switching to a dashed symbology when the CIP does not match the cross. To the opposite of what you said, the NATOPS goes into detail (even with figures) about how the cross always stays in the HUD FOV. _________ The usefulness is pretty obvious: it allows for a fast, visual designation using a dive bombing approach (often more precise than level releases) without having to dive so deep as to actually make the CIP appear in the HUD FOV. It is often seen being used by British Harrier (HUD footage videos available on Youtube). Again, this is the same thing as the A-10C CCIP Consent Release, a most useful feature.

If you don't know something, don't claim it doesn't make sense. OP was right, you were wrong. That's it. Just an extremely quick google search would have given you what you were looking for: https://forums.eagle.ru/showthread.php?p=3380639 Page 2-70 of the TAC-000. Not only does it make sense, but it's even already in another DCS module (named CCIP Consent Release in the A-10C). So, as you say: "go home and redo your training".

Have you guys at least tried deleting the fxo and metashaders/metashaders2 folders in Saved Games?

Yeah, I’m having the same problem here!

That's weird, just came back from TAW N/A server 2, Stennis is on 50X, got no signal on 50X, switching to 50Y I get a tone. If I ask JESTER to switch to 50X, he gets a tone. Are you sure you dialed your TACAN in the front cockpit, and that the PILOT/NFO TACAN switch is set to pilot?

The singleplayer version of the Iran Nuclear powerplant strike mission is missing the IP waypoint and the Surface Target waypoint (they are not in the nav computer nor in the kneeboard, nor in the F10 flight plan).

I couldn't understand why my TACAN wouldn't pickup, but if I asked JESTER to set his to 50X, it worked. Turns out, the X/Y switch logic is inverted in the pilot cockpit, meaning setting the switch to 50Y tunes to 50X.