Rongor

While noticing that apparently few people do mess around with Harpoons at all, I now reported this in the bug section

I wanna add, that there is still a workaround for TOO. Which is cycling through targets and designate them before each drop, all while "in the zone". Basically by designating different targets quickly between succeeding drops you can achieve a ripple like effect.

This is basically the same content as provided in this English tutorial by Redkite. Nachtfalke correctly noticed this doesn't work anymore. Below the Grim Reapers tutorial its mentioned that this doesn't work as of July 2021 Just tried it with TGP designation. Here the coordinates are kept in the TOO mission, yet the most recent TGP designation seems to overwite both TOO missions. I guess rippling JDAMs in TOO isn't possible right now. You would currently have to go PP. Nachtfalke, man kann bestätigen, dass es derzeit nicht funktioniert. Habe es eben mit dem TGP probiert, auch da merkt er sich für beide TOO missions lediglich den letzten TDC depress. Wenn Du mehrere JDAMs gleichzeitig auf verschieden targets werfen willst, bleibt derzeit nur die Option, Pre-Programmed Ziele einzuprogrammieren. Das ist natürlich "etwas" umständlicher.

Nachtfalke is referring to a German tutorial video on youtube addressing TOO mode für JDAMs. In this tutorial from November 2020, it's explained how you transfer waypoint coords into a selected TOO program of a specific station. The transfer of the coords is initiated by WPDSG in the HSI. Following this, the tutorial advises to deselect TGT in the HSI, which should leave the transferred data in the TOO program shown in the left DDI. Nachtfalke (Nightfalcon) now tried this but noticed that deselecting TGT in the right DDI then lets the coords vanish in the left DDI and therefore the transfer of the coords is lost.

As already found in this thread, different HPTP aren't displayed in the HSI. If all programmed Harpoons received different waypoints as HPTP, the HSI will still only display the most recent waypoint assignment on the HSI for all the Harpoons. This lead to my assumption in this thread that every new HPTP designation for another Harpoon seems to overwrite the HPTP for all the other Harpoons on board which have HPTP activated at this moment. I have attached a short track file showing the assignment of 2 different waypoints for 2 later 4 different Harpoons. Eventually, all show the same HPTP on the HSI, only their target BRG (from the HPTP) is kept correctly in the display. After launching, all 4 Harpoons correctly steer towards their individual HPTPs. Verification of correct distribution of different HPTP (for example pincer-attack or any other off-angle tactic) to specific Harpoons is impossible right now. Only the correct BRG can be verified, as it is displayed correctly in the HSI and of course in the stores>HPD programs... dcs.log debrief.log Harpoon.trk

What I am actually hating about AAR is "return pre-contact" right when I just got so perfectly close to the basket...

TL, DR, it's not consistent, especially not in regard to the manual. I did RTFM and maybe you guys should do so too, before handing out half baked assumptions. The manual claims otherwise on page 349: After assigning the TDC to the respective DDI, the SCS only handles entering AACQ and the ACM submodes in A/A radar. In the A/G radar, the SCS is responsible for acquisition+track. The TDC only comes into play on page 202, considering the designation of an Offset Aim Point to a target. So regarding the manual - SCS does acquisition+track in A/G - TDC does acquisition+track in A/A If you wanna argue this situation is consistent (at all), then TFM doesn't really support the lesson you tried to teach me.

could at least anybody confirm it's working like this on his end? Afterwards we could discuss if this is the way it should work...

Yeah, did so back then 10 years ago with the A10C and despite year long breaks, I still know all the stuff (well, most of it)

Could we get legs please? People have to eject to be able to walk around. Why not give us a simple way to temporarily exit our aircraft? Would be great for before flight inspections, walking around our aircraft. Some people just want to walk around on a supercarrier or enjoy your beautiful map sceneries or aircraft liveries. The walking feature after ejecting is evidence, it's all in the game already. Just give us a keybind to exit without ejecting and get back aboard... Thank you!

Thanks man! I got Chuck's guide but it's intimidating, more pages than in the manual

This would only make sense if switching it to on from standby unstows it. Which it doesn't.

Whenever I put my FLIR page up for the first time after getting airborne, I sort of have to try out all the buttons until it finally leaves the stow position. No, I am not in the cool down / time out phase and there is also no masking. It's stowed. And I can't find a way to simply unstow it to some kind of caged or bore sight position, coming from the stow position. It only gets lured out by being slaved to a designation of the radar, after this, I can retake command over the FLIR. Also is there a way to intentionally stow? ALso, is there a way to unslave the Litening from radar? Whenever I have found something nice in the TGP in the vicinity of my radar lock. I sometimes don't need the radar lock anymore, so I undesignate. Then, not only the radar undesignates, but the FLIR also returns into bore sight. Not funny.

Continuing my original post: 6. Trying to use the HPTP function to designate waypoints as turnpoints for off-angle attacks of Harpoons, I had to wonder why all the Harpoons with an active HPTP received the same waypoint data, despite the manual claiming only the selected Harpoon would receive the currently selected waypoint data. So I had to switch the HPTP again after each Harpoon launch to have them steer to different HPTPs, instead of simply defining different WP for each of them (like the manual offers). Btw I posted my bug suspicion in a designated thread

In the current manual on page 304: I found out that in fact whenever I do that, I overwrite the HPTP of all other Harpoons too. If I interpret the manual correctly, this should copy the currently selected WP into the selected Harpoon delivery program. But, instead it in fact copies the currently selected WP into all Harpoon delivery programs, which already have a stored HPTP. So it's impossible to specify different WPs to different Harpoons aboard. All the Harpoons with activated HPTP will receive the last WP copied into any of your Harpoon delivery programs. So is this bugged or is the manual misleading? I intended to do a nice pincer attack with 2 Harpoons closing in to the target from 90° different directions. For this I pre programmed 2 waypoints at 6 NM distance from the target, but the one E and the other S of the target, intending to use each of them as a HPTP for a single Harpoon Now I could only pull it off by changing the HPTP for the second Harpoon after the first one was launched. I tried to launch at approximately the same distance from both intended HPTPs, so the TOT would be about the same. Needless to say, it was pretty annoying to have to manually switch WP for a new HPTP designation in the few seconds between both launches...

I guess these are mostly noob issues - if not, feel free to comment... Currently I am learning all the A/G stuff and it gets surprisingly confusing quickly. 1. Preparing JDAM runs, I got coordinates from the F10 map. Created a waypoint to store these coordinates. Format was DEG°MM.MMM'. - Unfortunately there doesn't seem to be a possibility to directly "copy" waypoint data to the JDAM mission data or even just assign a waypoint to a mission. - So I had to put up the waypoint data into one DDI, the stores/JDAM mission editor into the other DDI and write those data of the waypoint into the PP mission. - sadly the PP mission data seems to accept only DEG°MM'SS", so I had to recalculate it on the fly -.- - Yes I could have slaved the TGP to the waypoint and "copied" the TGP target into a TOO mission but that isn't the point of PP right? Let's assume there was no TGP available. Yes, I hear you, maybe entering PP data during a flight is also not the point of PP? I don't know. Let's assume I received target data from a JTAC or the command center. 2. After preparing everything, the correct target coordinates were way off the game world coordinates. Maybe caused by starting in a slot already in the air. Alignment update was all set ok though, maybe there is some bug as I was at max 1 hour flying and this probably shouldn't put an GNS/INS off for 3 miles... 3. At another time I slaved my TGP to the current waypoint by boxing the waypoint in my HSI DDI page. It's still inconclusive to me if I really have to WPDSG that waypoint also. When I did, I then had the TGP where I wanted it and started to slew around the TGP view. This way I found a location worth to be a new waypoint. - So I intended to select a new (clean) waypoint in the HSI data page. Of course, the moment I cycled the waypoints ahead, the TGP broke LOS to my desired point of interest and it was gone with the wind... 4. In the A/G radar DDI page, you designate targets with an additional push of the sensor switch towards that DDI, in A/A mode, you use press the TDC for this. While pressing the TDC designates EXP areas in the A/G mode. Why not keeping the same meaning of the TDC in both modes? Being a retired aviator, I am used to avionics always trying to avoid confusion for the pilot. Mixing up the meaning of a rather important button press seems entirely unnecessary (why not also using the sensor switch for targeting in the A/A modes, moving the AACQ elsewhere of course, or using the TDC press as designator in the A/G mode?) 5. speaking of confusing avionics, when we are used to return to main menus by pressing RET OSBs, how can one come up with the idea to name the CBU in the stores page "RET"? I wondered why my JDAM wasn't released (Auto release/CCRP) and was surprised to realize I had selected a CBU instead of RETurning from the JDAM data in that very same stores page. That's all for this afternoon...

Time codes in the track file: 13:01:00 around this time the bars are gone in the following minutes I become increasingly busy trying to find any connections to TGP, waypoints management or else, which could be responsible 13:07:15 cycling to A/A and back to A/G mode, TDC bars are back situation during the problem...

Yes, the diamond was in that DDI and therefore the TDC slaved to it.

Unfortunately not. It happened by surprise and I can't reproduce it. If you manage to fast forward to the latest 3 minutes, you will see the situation on the right DDI. SEA mode, no designated target, no TDC bars...until i cycled A/A and A/G

I was trying out stuff and learning use of TGP and the A/G radar modes. After some time I didn't regain the yellow TDC bars after undesignating a tracked sea target. The bars only came back after cycling to A/A and then back to A/G mode. It's in the last few minutes of a rather boring attached track file... OpenBeta 2.7.3.8494 SEA TDC.trk

If this problem occurs on the other maps too, this sub-forum might be the correct one. Otherwise I suggest putting this up in the Mariana Islands section...

It's most certainly a typo. Even if we had such ridiculous speeds, there are no drives to handle these

Rather petition the russian government lawmakers to allow a return of the Crimea map...

If I had a stick extension mounted to the floor, I might agree with you. But we people without a fine stick extension setup simply can't achieve the same controls sensitivity as you are enjoying. We are allowed way less applied moving force to move the stick than you with your stick extension to effectively adjust the stick by the same degrees of angle. The top of your stick moving an inch might mean fractions of a milimeter for us. It's outright impossible for us to enjoy the same sensitivity, let alone with linear response. Curves are our only chance to achieve a remotely similar steering efficiency. Trading off sensitivity at the other end of the curve is a major downside, true. Yet a good trim might help to prevent to get into these ranges in many cases.

I think we also should mention loudness values in decibels nowadays for graphics cards...