itn

If you mean the "T" column on TNDL STN DED page in Viper, it stands for "TDOA", and sets the TDOA participants.

Yes. In Hornet it's in TAC -> TGT DATA -> GROUP. O(wnship) line in TN column shows the STN, in this case 14223. With this you can add them as members in-flight in F-16.

@TobiasA what are your expected results here? Maybe there is a misunderstanding of CEP? Circular Error Probable (CEP) is a statistical measure, defined as the radius of a circle within which 50% of the impacts should land. 8 drops is not much statistics-wise but you did get four direct hits out of eight JDAMs, with the other four being maybe 7-9m out. I took the miz and tried it. Two runs, one without laser and with. Designated a bit lower than you, at the tank tracks/side. On both runs I got pretty much exact same results each: Two direct hits, two close misses, one of the close misses ended up killing a tank. So in two runs 6/8 tanks killed. For actual CEP calculations I think you need to do quite a bit more drops. You can do this with for example some creative usage of target range scripts, Unlimited Weapons, Active Pause, Joystick Gremlin and Excel... Most definitely this is not the old bug with the really inaccurate JDAMs.

No worries, and thanks for the clarification.

This is still a thing. Seems to show GS instead of CAS in FCR. FCR Ground Speed.trk

As a clarification to the or "return to the navigation mode to restore original waypoint data": Does this mean the delta should reset automatically when switching to NAV, or maybe the NAV mode somehow always use the original steerpoint data? Currently if you have slew delta in A-G DTOS or CCRP, and simply switch to NAV, the delta stays and is still used in NAV mode. It can be reset manually just the same as in other modes, but the question is should it reset automatically simply by switching to NAV and should I always have the original steerpoints in NAV? Thanks for your efforts

Reported same here. Correct as is according to Raptor9.

Oh allright then. I knew how slews and CZ work in general, but this is new to me that the slew in A-G/DTOS stayed after returning to NAV. I tried TMS down out of habit, which did nothing but CZ in either FCR or TGP did the trick.

nullSo, what happens using DTOS is that it offsets steerpoints, but only affects the HUD indications (the diamond and steering cue), not STPT data, HSD or e.g. autopilot. When you designate with DTOS, current STPT is set to the designation point. Other steerpoints are offset as you can see in the attached screenshot. In the screenshot is my original three steerpoints in green: 1 Senaki, 2 Kutaisi and 3 Kobuleti. I selected STPT 3, entered DTOS and designated somewhere randomly (by the river S-SW of Senaki). Then I flew through all three steerpoints using the steering cues in HUD. I put in a F10 label at every STPT I ended up following the HUD steering cues. You can see in red how they're perfectly offset by the DTOS designation I did in the start. And I could reverse this by again selecting e.g. STPT 3, selecting DTOS and designating at Kobuleti. Then flying to STPT 1 using HUD cues, I ended up at Senaki as I should. It seems only HUD is affected. HSD, STPT page and autopilot have and use the original steerpoint data. Did not test weapons. DTOS offset demonstration.trk

In addition to the bug with second TMS up, the steering indications are bugged on HUD after designating with DTOS. Steerpoints and steering indications are "moved" on HUD but not in HSD. Didn't test weapons (e.g. how does CCRP work in this situation..). I put in a bug report with track to the bug report subforum. Admins may merge these threads if they so wish.

Hey, Following the discussion in the thread, decided to test this out. DCS 2.9.0.47168 Open Beta. Per the discussion, using JHMCS and DTOS, the second TMS up after ground-stabilizing the TD moves the TD to the location JHMCS is looking at the moment you press TMS up for the second time. Also steerpoint/steering indications in HUD are moved. Seems like STPT 1 (or maybe the currently selected steerpoint (EDIT: see next post) is set at the TD and STPT 2 indication might be just offset from that the same amount the original STPT 2 was from the original STPT 1. On HSD they are shown at the original locations. Track attached. DTOS bugs.trk

Short video demonstrating the bug.

Hi, Running DCS 2.9.0.46801 Open Beta DLNK DED page and datalink feature are bugged when using STNs with first digit over 0 (i.e. 1xxxx-7xxxx). Working range is 00000-07777, seems to work correctly as long as first digit is 0. Did not test every combination... Seems related to the previously reported Hornet CTD when ownship STN first digit is over 0. Symptoms are: STN representation is incorrect on the DED page. First two numbers of the five-digit octal STN are incorrectly represented: For example 70xxx becomes 1Sxxx. STNs change when cursor is on them, and back again when cursor is moved off (the aforementioned 70xxx becomes 45xxx when cursor is on it). And most critically: Adding members higher than 07777 does not work on DED page. They can be entered to the list, but do not become members on HSD. If you edit an incorrectly shown member STN on DED page to "correct" it, you lose the member. Datalink members added in ME work even if the number representation in DED is incorrect, and as long as you don't try to correct them as stated previously. So you can add members like 10202 and 50123 in ME and it will work. See the track attached, me flying STN 70201 with 10202 on my right and 00203 on my left. The track should have everything necessary for reproduction: 00203 works, 10202 doesn't, and the demonstration on DED page. F-16C STN ID bug.trk

And IIRC this started, or maybe only became an issue, after the patch where they upped the TGP view range limit.

Any news? Still happens in current OB. F16 TGP downward travel.trk

This is an educated guess based on trying around, but it seems to switch from B to F when there is no LOS and the nearest LOS obstacle is within 10.0 NM. And back to B when outbound and reaching 10.0 NM. See my attached track. The track has a simple LOS test using https://wiki.hoggitworld.com/view/DCS_func_isVisible. It's not really relevant for my track (it's clear there's no LOS in my track), but I left it in in case others are interested to test with it. It's pretty much the example script from the Hoggit wiki put in a repetitive trigger. F-16 slant range and LOS.trk

Hi, Using DCS 2.8.7.42583 Open Beta There are erroneous extra ACM SLEW mode indicators when returning to DGFT mode with no locked target, and having previously used ACM SLEW mode. Steps to reproduce: Enter DGFT override (radar enters ACM and NO RAD is indicated) Enter ACM SLEW mode by slewing CURSOR/ENABLE switch Lock a target Return from DGFT override (to e.g. NAV and RWS) TMS down to reject the target (so you don't have a target locked when you return to DGFT override in next step) Enter DGFT override, and note the following - On HUD, there is "NO RAD" indication (correct) but also SLEW cues with the circle and elevation values (incorrect) - On FCR page, "SLEW" is indicated (incorrect) - You can slew around, radar will not radiate and lock a target (incorrect; it should enter slew mode when slewing) You can enter any other ACM mode to lock a target, e.g. TMS up for BORE, after which you can also enter SLEW as usual. Track attached. Best regards, itn F-16 ACM SLEW NO RAD.trk

Yes, have had it happen. Only with last digit so far.

Thanks for the clarification!

Hi, Not entering a bug report as maybe this is correct as is. Will do a bug report with track if needed. F-15E with 4xMk84 (four stations). Program PROG1: Select four stations with Mk84s AUTO (doesn't matter) RP MPL (ripple multiple) Quantity 2 When pickling, it drops from all four stations, exceeding the selected quantity of two. Is this how it should work? Literally that's pretty much what the manual says, but it doesn't address this case explicitly. So I was just surprised to see it drop more than selected quantity. If it's correct as is, I guess RP SQL with interval 0 and quantity 2, or two programs (two stations each) are better ways to drop pairs.

For Viper VSR it's sort of "search + confirm". So basically it should do normal Velocity Search using HPRF, and when it gets hits, it "verifies" them with some sort of MPRF scan. My understanding is that unless you get hits, it just keeps scanning in HPRF, unlike the interleaved mode(s) in Hornet. See for example Introduction to Airborne Radar and Principles of Modern Radar Vol. III: Radar Applications. Nothing classified about the overall strengths, weaknesses and features of L/M/H PRF, even if details and actual frequencies and patterns are classified. I don't know much about radars or radar theory, and am not trying to portray an expert here, but it's laid out pretty clearly.

In leasurely cruise the drift is about under 1 NM/hr. My understanding is heavy maneuvering should cause more drift, but haven't tested it in DCS. Let us know if you test this with GPS disabled, heavy maneuvering, and say 1 hour of flight time. My guess is it's still around 0.8-1.0 NM/hr. The GPS cutoff is in 1994 (March 28 1994 per some older forum post). So basically pre-1994 missions have no GPS available, unless "Unrestrictd SATNAV" is on. You could also just turn GPS off in plane. If you have GPS available in mission and enabled in Viper, in practice it doesn't drift because of the constant GPS correction.

Hey, Thread tagged " null nullpm documented evidence". You have the doc I referred to, see sensor volume explanation in HSD section around p. 1-83 (and the figure on p. 1-82). Now contrast with the track I provided and see if it seems like it's correct. Clearly, currently in STT the sensor volume symbology on HSD follows neither actual nor commanded scan volume because it's fixed straight from nose (azimuth 0) in STT. After stepping back from STT with TMS down, sensor volume symbology on HSD snaps to the actual azimuth setting and actual azimuth (i.e. pointed at the bandit, which the radar was whole this time). There's not much more I can argue to say this is incorrect. The only evidence I've seen says it should show actual scan volume, not a scan volume you "might scan if you return from STT, break current lock and center the radar to 0 azimuth instead" which is pretty much what it currently does. Best regards, itn PS. Thread tags don't trigger notifications. I think replying with a message to a bug report is a good idea, so the notification gets sent. Also if the discussion gets longer, replies stay in the thread unlike tags.

Hi, DCS 2.8.3.38090 Open Beta Currently when you enter STT, the sensor volume symbology on HSD is fixed to 0 degrees azimuth, i.e. it points straight from nose. When maneuvering, it stays pointed straight ahead and not at the bandit. I believe the HSD sensor volume should stay centered on bandit when in STT. Refer to for example F-16CJ -34 (HSD description). Steps to reproduce: 1. Approach a bandit on your nose 2. FCR SOI, TMS up to enter STT 3. Maneuver, turn away for example 50 degrees. Note the following: HSD sensor volume stays centered on 0 degrees from your nose, not centered at the bandit. You can switch azimuth setting (10/30/60) which is then reflected on the HSD. You can stay in STT while at the same HSD sensor volume indicates the bandit is outside your scan volume. For example when in STT, AZ setting +-10 and 50 degrees crank, the bandit is 40 degrees outside the indicated sensor volume. 4. TMS down to return to previous mode (RWS/TWS). Note the HSD sensor volume snaps to bandit and stays centered on the bandit. Attached is a track showing first how it works in RWS SAM bugged target and then in STT. F-16 HSD sensor volume in STT.trk

Apparently this has been implemented. User Files pages now have only the relevant og tags. This makes the previews much nicer when pasting links to social media. Thanks -itn