LastRifleRound

FTT and GMTT are the same mode, the only difference is from which format you made the designation. Any track initiated in GMT mode is a GMTT. Any track made in SEA, MAP, or any of MAP's submodes is an FTT. The names are misleading. They are the same, which means FTT can track moving targets. If you designate a moving ship in SEA, you get FTT tracking a moving target and get vectors and lead calculations in AUTO. If you happen to FTT something moving on MAP, it will track it in FTT and you will get vectors and lead calcs in AUTO. If you designate that some object in GMT mode, the behavior of the radar will be exactly the same except the format would be labeled "GMTT". If you designate something that is or isn't moving on MAP or its submodes, the radar will attempt for up to 5 seconds to discern a significant radar return in the area you commanded, if it finds one, it initiates a track. If it can't, it reverts back to the previous map mode. If that object happens to be moving, it follows it. If it's not, it stays fixed on that object. In this way, you would see the designation diamond move. It likely wouldn't just stay exactly where you put it if it achieved a track and if you commanded track on empty space with no significant radar returns, the track should fail. This is what Harli was talking about re. a bare patch of grass. The objects either need to be synthetic returns (SEA and GMT) or something the radar can discern in MAP. The beam operates at the resolution of RBM, NOT the expand modes, because the expand modes are not what the radar 'sees', rather the effect of post-processing techniques analyzing doppler shift and a whole bunch of other confusing magic that I do not understand.

I'm not familiar with exactly how ED's terrain works but this seems to suggest a location outside of the map was queried for its coordinates. HTS mode throws a designation on init and at the start of slew, so they could be related.

Just posted to bug reports for an official response. Do you think the ability to track moving targets in FTT is tied to tracking statics? After all, knowing how the sim determines a track for the TPOD there is really no difference whether the target is moving or not. Doubt it would be different for the radar.

I'm not sure where I should post this (as I'm not sure if it's a bug or WIP) but FTT is not working as it should. In the patch notes it is indicated that FTT'S ability to track moving targets was still work in progress, implying that its ability to track static objects should be functional. Currently, the mode isn't tracking fixed targets, either. The mode just keeps the same designation point and won't snap to radar significant features such as large isolated structures. I'm guessing the two things are tied together. Is FTT's ability to track static objects being worked on?

No it's not. FTT also tracks static targets. It should favor the largest return in the RBM cell width and track it, so in the presence of radar significant returns it should snap the designation to the target. In the presence of many returns in the cell width, it should jump around and eventually settle on the largest return (which may not be your intended target). If no discernible return is found, the track should fail. Right now the implementation is very simplistic and only cosmetic.

It's definitely not working at all. Should also "wander" between close objects since the beam resolution is the same as RBM. Right now it is functionally useless.

No, it's not. See post from gripes. Also, I have discovered FTT does nothing also. There is no difference in the sim from FTT and nav stabilized locks. FTT should need a radar return and should "wander" between buildings that are somewhat close to the area commanded. For now, it just says FTT and keeps the designation exactly where you had it. I'll make a separate thread about FTT to avoid derailing this one.

Yes, have used wpdesg, tpod, ag radar all to the same effect. For comparison, I've used the same points as JDAM TOO targets to eliminate the aimpoint and HOT as an issue. JDAMS were reliably able to score hits. Have you tried it yourself?

I know they said they fixed "Mk82's landing short", but now Mk83's are all over the place and Mk82's always land long. I had a pretty established method of accurately bombing level before the patch. I think AUTO's been made worse. The problem wasn't"MK82's landing short", it was a mis-calculation for all bombs of the release point depending on speed and altitude. You could reliably get Mk82's to land short OR long, depending on your speed or atltitude. Can anyone else corroborate this? I'll have time to make a more detailed analysis and corresponding track tomorrow.

I may have confused it but didn't they say this was going to happen temporaririly in the patch notes?

Ok just saw a video demonstraition of this, looks like it really does create an actual designation. Still not sure if this is a feature in the Lot 20 but super handy if it is. Can someone from ED comment if this is a thing in their Hornet?

Right, I saw this and it wasn't mentioned, that's why I raise the question. It's kind of like that. I'll need to find some of the posts that reference it. I think I even asked the question in the wishlist page and it got hit with the [LATER IN EA] tag. EDIT: Found one of the threads where this is mentioned: https://forums.eagle.ru/showthread.php?t=270906&highlight=agr

I've seen it said that the Hornet has a sort of auto acquisition mode called AGR Track, wherein if you hover a reticle over a radar discernible target, it will track it. I have documents on an early APG 65 that doesn't mention this at all, but that of course isn't this radar. 1. Does this capability actually exist for this Hornet? 2. If so, does anyone know how it's used? Perhaps if you're in AUTO with no designation with TDC to the HUD I could see this greatly improving the accuraxy of my visual runs using a workflow similar to the Harrier.

Can you post a track of this?

Lol. The point trying to be made was not some users love of 'game' orientated flight sims, it was that some of us come to forums to find information about the modules only to find the same few people constantly at odds with the developers citing 'google' documents and 'handbook such and such says this'. I think some of the limitations of the DCS software are being found with each and every different module that comes out and it would be cool if a few of the regulars here could wrap their heads around that. DCS is marketed to gearheads and nerds in a very gearhead-ish and nerdy way. Gearheads and nerds at ED made DCS out of the same passion for 'getting it right' that this community by and large has. That you don't require them to meet this standard to enjoy it, or that the same people find themselves having to repeat themselves, does not mean we are wrong for holding up this standard. Much of the information you are here looking for is there because the very people you criticize care about this product enough to be nerdy about it. They're the same people I see in thread after thread answering questions for people new to the community and making campaigns and liveries and the like. It's cool you have a different standard and I mean that. But that means it's cool if we have a different standard, too. More than that, our standard is the one to which DCS's mission statement aspires. We just want to see it get there just like all of the devs do.

Did you slew and TDC depress with the TPOD the active sensor before switching waypoints? If you did, then changed waypoint, the waypoint is no longer a designation source and the TPOD would not follow and this is expected behavior. You would NWS/Undesignate, then press designate on the HSI/SA page for the new waypoint. If this isn't the case, I suggest posting a track so we can examine the sequence of events.

Right, Fred was comparing to the GBU-12, not the GBU-38, as that is the comparison OP was making.

I was only reporting that no action slew does not behave as according to the tacman. I was asked to provide a track, so I provided one showing the current behavior and explained what the difference was. I didn't post the references because Chicken already did so earlier in the thread. Chicken's right, I have no idea if this is a bug or missing feature. That requires knowledge of the developer's intent, which I do not have. If there is some other way I'm supposed to report things let me know. I'm going to hold off reporting until after the patch.

Since I was asked to provide a track, here it is. CURRENT BEHAVIOR: Shown in track. Using TDC slew stabilizes DMT immediately regardless of TDC depress. TDC depress does nothing. Essentially works as TDC Action slew all the time with the slow speed of no-action. EXPECTED BEHAVIOR: Slewing DMT without TDC depressed should not stabilize the DMT. DMT should remain in same position on HUD with respect to the velocity vector until TDC is depressed. Once TDC is depressed, no-action slewing would behave as emulated currently in the sim. Holding TDC depress should result in a faster slew speed than exists in the sim. harrier slew.trk

They mentioned SVG changes because many of the reported bugs were display-related. I think Ron was trying to say they were in the middle of the SVG rework when this all happened. Many of the fixes were going to be in the SVG re-work. When they say they're doing double-work, what they're saying is they'll now incorporate the changes in the raster-based current iteration so the bug fixes don't have to wait for SVG re-work. As someone who has done a lot of web development, SVG is ubiquitous, but that is because we have built-in support for them. I put an SVG on a page (usually a logo or other graphic that can be drawn mathematically) and your browser just knows what to do with it. This is likely much more complex in DCS. Deka has also come out and said their next module will be one without a glass cockpit because it was so difficult for them to do, so it does sound like the re-work would be quite time-consuming. Not weighing on one side or another. I may not be a Harrier SME, but I am a software SME.

Tacman Vol 1 1-386 CURRENT BEHAVIOR: Slewing in HTS updates designation currently. The behavior is odd, but if you stop slewing, then start again, every time you START slew the designation position is updated. Using TDC depress causes undesignation. EXPECTED BEHAVIOR: HTS shouldn't effect designation position at all. TDC depress in HTS should do nothing. You must be in TDC mode to do this (which currently functions to spec) according to the above reference. harrier hts.trk

There is a current bug another user and I reported (it was acknowledged by the team) for all bombing with AUTO mode. If you are not at a specific airspeed for the altitude you were at for release, the release point is wrong and you will miss. Falling short indicates you were faster than the algorithm calculated for. Use CCIP only for now if you're going to attack in a dive. EDIT: Have you tried this same thing with Mk20's? That's what I usually use, maybe they are different in the sim for some reason.

I'm not sure how it could be a crude ARBS implementation. RCIP by definition ignores ARBS. ARBS "ANGLE RATE bombing system" uses angular rates, therefore requires lock. Having no lock with CCIP should use RADALT. In fact, if RCIP is manually selected, EVEN WITH ARBS lock, the ARBS slant range will be ignored for HOT. There are SME's on RAZ's discord who have outlined this in detail, as well as it being detailed just as Luke and Chicken describe it in the TACMAN (one of which is also an SME). This kind of contradicts what I heard earlier. Saying if it's in the sim, it can't be a missing feature thus feature complete. Now we're saying though it's in the sim, it's not a bug but a missing feature. All these semantics are killing us. Perhaps we shouldn't use these vague notions of "bug" vs "feature" to denote priority since no one from the devs to mods to us can keep it straight? I mean it's even possible that a missing feature could be a bug. Did the developers INTEND for RCIP to not function according to the TACMAN? Then I suppose it is a missing feature and not a bug. If they did not, it's a bug. Either way it requires me to know what's in their mind, and they're saying missing feature, so not intended to be operational. It's something in the sim that when you click it it doesn't have the expected effect to those of us who know how it's actually supposed to work. Whatever you want to call that is what we have here.

Yeah I'm going to chime in $10 is an amazing value. The A10C is already tremendous.

8 bombs to 5 hits is very low. Were these delivered in a dive or level? the pattern seems to close up when delivered in a dive as per the tutorial with the recommended 1200ft HOB