Harker

Updated for clarity and new tracks.

Yeah, I had misunderstood some functionality. The overall logic is still kinda weird though, so I'm looking into refining my other bug reports. Mainly there is inconsistency between how sensors and release cues work after using the Offset function.

After looking into it more, the current behavior is actually correct. The confusion came from the fact that the O/S option was available even after manually slewing the designation, but given new information that @Jak525 shared with me, it is normal that the offset will be applied to any existing designation, not just the one from WPDSG. I am going to change the title and OP to reflect that the current implementation (on this front) seems to be correct.

IMO, you should have the warning set to something relevant to the mission or the approach. And since you know where it's set, you don't need to look at the instrument. I agree that if you leave it to a random setting and ignore it, it'll develop into a bad habit. I don't know, I think even worse to not have the radalt operating altogether, since you can't see radar altitude at all and it cannot be used for backup targeting. If you don't want warnings, just set it to 10 ft, so you don't need to ignore the warning, but you get to use the altimeter data.

It could be as simple as "aircraft with the same F/F 1 channel are on the same flight" and F/F 2 can be from 1 to 4, do determine position within the flight (A, B, C, D). Or maybe even better, the two first digits of F/F 1 (01 - 12) are the same flight and the last one needs to be 1-4, to determine position. They will also share MSI tracks. And aircraft with the same F/F 2 will share F/F MSI tracks, like they now automatically do. And the AWACS can have an AIC channel that you need to be on, to get SURV tracks. So, we'd have a reason to actually interact with the D/L menu and It doesn't have to be realistic, it just has to work within the sim.

lol. It's more that it's good to have the radalt working, even if you don't use the warning.

With the TDC assigned to the FLIR page, zoom (including moving between WFOV, MFOV, NFOV) can be controlled by the radar antenna elevation controls. Make sure that you are not accidentally using that. Check both the Axis bindings and the key bindings.

No idea, as I use Beta, but see if you have Game Flight mode or Game Avionics mode checked, in Options. Apparently they get enabled for no reason, for some users.

Same, it looks quite nice and detailed. I'm very looking forward to see how they handle explosions, sensor saturation and gain/level adjustment, terrain, trees, textures, dust etc

Better to set it to 10 ft or something, moving the knob all the way to zero will turn off the radar altimeter altogether.

I haven't used it in years, but look for "padlock", in Controls and try it when you're near a target, in visual range. IIRC, it won't work if you have any sort of headtracking running.

Please correct me if I'm wrong, but doesn't the "padlock" command do exactly that? Maybe without the correct limitations, but IIRC, you can padlock an air or ground target.

Check the AZ/EL page, you'll see what @Hulkbust44 is talking about.

+1 Having a selection similar to CAM, in the vanilla game would be most welcome.

2.7.5.10869 Open Beta 1. Set up an Offset to a WP (I chose WP1). 2. WPDSG. Designation moves to WP1. 3. O/S. Designation moves to the offset. 4. Select GBU-12 (or another weapon in AUTO) 5. Bug = Slew the designation around with the FLIR. The diamond will move on the HUD and the HSI, but the firing solution will keep pointing to the offset. FA-18C_AUTO release cues do not move after Offset designation.trk 6. Bug = Observe the behavior of the FLIR, the A/G radar and the HUD (INS) as designating sensors. There is inconsistency in the way the designation logic behaves and the sensors often do not match the designation diamond position and vice-versa. A difference between sensor pointing and designation should occur, but it should be consistent. FA-18C_Cannot correctly slew the FLIR after Offset.trkFA-18C_Offset does not allow to slew the designation.trk Also, the A/G radar cannot be used to slew the designation around, while maintaining the offset. FA-18C_Cannot use RDR to move designation after using Offset.trk Expected behavior for Radar: O/S should not move the A/G Radar stabilization cue (cross), but it should allow the radar to designate something new, maintaining the offset between the stab cue and the actual A/G designation. This is not an exhaustive investigation, but should give the dev team a good idea of where to start looking. Edit: Tested with LITENING as well, same behavior.

2.7.5.10869 Open Beta 1. Set up an Offset to a WP (I chose WP1). 2. WPDSG. Designation moves to WP1. 3. O/S. Designation moves to the offset. 4. From A/G mode, uncage a Maverick. 5. Bug = The Maverick seeker will slave to the WP position, not to the Offset position, even though the target diamond is at the Offset. It seems like the notions of waypoint and designation are not clearly separated, in the code. Expected behavior: Maverick seeker will slave to the designation. Edit: Same behavior observed for JDAM TOO as well. FA-18C_JDAM TOO does not slave to Offset.trk FA-18C_Maverick does not slave to Offset.trk

Edit: After looking into it more and discussing with more people, seems like the current behavior is correct. @BIGNEWY, I took the liberty to change the tag and I'm pinging you to let you know to stop working on this. Sorry for the confusion. 2.7.5.10869 Open Beta 1. Set up an Offset to a WP (I chose WP1). 2. WPDSG. Designation moves to WP1. 3. Slew the designation around (example, 1,000 ft North). (Delta = 1,000 ft North). 4. Bug = Press O/S. The designation moves to the offset point, plus the previous delta from the WP. Expected behavior: Once O/S is pressed, the designation should simply reset to the Offset coordinates. FA-18C_Offset is applied to the designation.trk

2.7.5.10869 Open Beta 1. Set up an Offset to a WP (I chose WP1). 2. WPDSG. Designation moves to WP1. The WP symbol on the HSI is replaced by a diamond. 3. O/S. Designation moves to the offset. The WP re-appears as a circle, the offset symbol is replaced by a diamond on the HSI. 4. TDC to HUD, slew the designation. 5. Bug = Observe that the WP symbol (circle) moves on the HSI, alongside the designation. The two symbols appear to be diverging as you move the designation further away and converging when you move the designation closer. It seems that the designation logic with WPDSG was to "move the waypoint" or something like that, whereas the waypoint has nothing to do with the designation, its coordinates are merely used as a source. Expected behavior: WP symbol does not move on the HSI. The designation diamond and the WP are different symbols and should not be tied together, when both are visible. FA-18C_Slew from Offset_moves WP.trk

Ehhhhhh. Infantry shows up better, explosion kinda better. But everything else is the same. Trees stand out way too much, terrain looks like a color overlay, like now, perfect crisp clear picture with perfect contrast between different objects, FLIR not really affected by the bright explosion. Looks like the current shader, with some minor tweaks. Hopefully...

Not really. The trees still stand out way too much, the terrain still appears to have just a color-based overlay, the effects of the explosion on the FLIR are not shown, the picture is too crisp. The soldiers look OK and the explosion kinda OK, but that's just it. I'd say that it's either an extremely early version of the new shader or simply the old one, maybe tweaked a bit.

You should be able to configure several net related options, as well as F/F channels in MIDS. It's just that all network related options do nothing in the DCS Hornet, right now. Whether that will change in the future, we don't know.

Seeing the gif the OP uploaded, it looks like the radar attempts to go STT at a much higher elevation than the correct one. You can see the elevation caret starting very high initially and then going lower with every attempt at STT, probably until the target is inside the elevation limits of the radar again. By the time it actually succeeds to go STT, the elevation caret is just a little higher than the horizon. I've seen the crazy high Mach number and I think it shows when the radar is supposed to have resolved the target's range, but not the velocity, which might require more than one return. The radar currently builds a trackfile after only one return, whereas it should probably display just a brick until it resolves the velocity and builds a proper trackfile. I don't think it's related to jamming, as it can occur on targets without jammers and velocity jamming is not modeled in DCS anyway. *Random thought*: I'm thinking that these two issues *might* be connected. The radar is trying to go STT at the predicted target location. A target that's a little above the horizon at 40 NM, will be significantly higher than the horizon, extremely quickly, if it's going with a speed of Mach 14,000+ (like in OP's gif). So, the radar is "predicting" that the target will be closer and way above the horizon in the next frame and trying to go STT there, hence the higher elevation. So, it could be the case where fixing the issue of building tracks before the velocity is resolved might solve this problem as well. Just an idle thought on my part.

I assume that your first SLAM-ER was in TOO mode, since you fired at a designated target. PP and TOO are selected per station, did you make sure the second station was also changed to TOO before firing? Although if I think about it, without a valid PP target, the second missile's release should perhaps be inhibited?

If the intention is to show that the Maverick cannot be manually slewed when an AG designation is present, there is no need to get tracks etc, this is how it's implemented in DCS. As such, it's not a bug, as it is working as intended. The point is that the implementation is different from the real one (at least according to the -300, it's my only source on that matter), not that it's buggy.

It's not. HOJ shots home on the emitter source and they're mostly applicable to noise jammers. They work based on angle and angle rate, but range is unknown. The guidance scheme is probably not unlike an IR missile that's fired without initial radar data. There is no range involved. If you have velocity and range, you don't need to do a HOJ shot to begin with. Plus, if the much larger, powerful and sophisticated radar of a fighter cannot resolve the range with its ECCM techniques, the small radar of the missile (assuming same tech level) will not do so either, at least not in time to alter the trajectory in any major significant way. This becomes even clearer if we consider the fact that we're talking about optimal lofting trajectory, which is a maneuver dependent on the target's range and velocity and is initiated immediately after launch.