Vortex225

This could be your HOTAS. With my previous sticks (Virpil WarBRD and VKB Gunfighter Mk 3), the Viper felt laggy and weird compared to the Hornet. I recently upgraded to a Realsimulator FSSB R3L, and now the Viper feels amazing and extremely responsive with force sensing. Ironically, now the Hornet feels mushy and laggy for me by comparison. I agree with BN; I think it's fine as it is now.

Actually, I did a quick test after 2.8 was released and found them to be working better. Both CCIP and toss bombing appeared to be reasonably accurate with the CBU-97. They definitely weren't working correctly before 2.8. Haven't tried them since the hotfix, so it's possible the changes were reverted.

Now that we have the correct ACM BORE HMCS behavior in the latest hotfix, which works just fine for me, I have two questions (not a bug report): 1) I'm noticing that I have no reference for when the ellipse is outside of the valid LOS range for the FCR. However, how are we supposed to know when we've moved the HMCS LOS too far to allow TMS Up (long press) to lock the target? Should the ellipse be dashed or crossed out or something to tell us the HMCS LOS is out of gimbal limits for the FCR? 2) Why does NO RAD show above the ACM BORE ellipse in the HMCS when we press and hold TMS up? Is this correct/intended? Thanks in advance!

Agree that VAICOM Pro is essential, especially for VR users. Came here looking for a solution. My wingman and I can't get it working either and we're not sure what to do at this point. I can't even get regular comms to work at this point either (even with VAICOM completely closed)

I have the RealSimulator FSSB R3L, which is similar to your stick and also force-sensing. You shouldn't have to set any curves with a good force-sensing solution. The response is naturally very smooth and precise, and the sensitivity should be adjustable outside of DCS. If you're encountering PIO, I recommend tuning your sensitivity downward so that the force required to reach max deflection is higher. As for the deadzone near the center, the RealSimulator software has a breakout force setting that controls how much force is required to overcome the center deadzone. My guess is that you probably have a software setting you could adjust to make it easier to breakout of the deadzone.

Edit: adding three short tracks on Caucasus to demonstrate the issue for CCIP, CCRP Loft (i.e., toss bomb), and a level CCRP drop from medium altitude. The CCIP and toss bomb attempts score zero hits and fall notably short. The level CCRP drop gets closer and scores 1 or 2 hits but the majority of submunitions fall short. This isn't a bug report per se, because the issue (or something related to it) has been reported here. However, the issue with CBU-97s falling short when using CCRP loft is making it hard to enjoy the new toss bombing symbology for the Viper. They even fall well short of the intended impact point when using CCIP. As I mentioned in the linked thread, it's almost as if they would be on-target if it weren't for the submunition separation and parachute phase, which modifies the normal trajectory below the burst altitude. Other bombs seem to be working great with CCIP and CCRP. CBU-105s also seem to be working as intended. This is frustrating because the CBU-97 is one of the most capable and entertaining munitions to use in DCS, and it's one of the things that really sets the Viper apart from its multirole peers in the sim. Accurate CBU-97 bombing with the Viper is pretty important in my humble opinion, and I hope this gets fixed soon. Any word on progress? Thanks in advance! cbu97_falls_short_CCRP_Loft.trk cbu97_falls_short_CCIP.trk cbu97_falls_short_CCRP_Level_Drop.trk

Can confirm this is happening for me as well (back seat in multiplayer with a human CPG). Works fine as backseat when in single player or in a multiplayer server with George as CPG. This only happens to me with a human CPG.

I've also noticed the upper and lower altitude search limits don't update when you enter Spotlight mode. Although it is nice now that Spotlight places you into SAM and not STT.

I think this has already been reported. It appears to affect the CBU-97 in any release orientation--that is, level, dive, or toss bombing. The submunitions are landing short no matter the situation.

This is the answer. I bound the roll trim wheel to a spare analog axis on my throttle, and it provides very fine control. Very satisfied with the result. As mentioned in the quote, the trim hat provides steps of trim level, which may or may not perfectly balance everything out.

I am also having the same issue with CBU-97s, both in CCIP and CCRP. It's almost as if they would be on-target if it weren't for the submunition separation and parachute phase, which modifies the normal trajectory below the burst altitude. Other bombs seem to be working great with CCIP and CCRP.

Will do. I'll test it on my next flight. Thanks! @Furiz That would suggest there is a bug. I wasn't aware it wouldn't fill once the correct procedure was followed (i.e., AAR door open).

@Furiz Appreciate the assist with the additional trackfile on the Caucasus map. That is exactly the issue; the STP diamond is repositioned to the SPI produced by the HTS/HAD system. I don't understand why this would happen, as the diamond should always be associated with the active steerpoint. While it's possible to use CZ to force the SPI to return to the STP diamond location, I don't understand why it would make sense for a target designation to force the reverse behavior (save for markpoints, which are a different story). @Frederf Thanks for your input. I think most of your comments go beyond the scope of the bug report, but I may have misunderstood your line of thinking (which is probably more advanced than mine). I chose a simple test with HARMs in EOM mode using the HTS/HAD system to produce a SPI. The bug, or what I think is a bug, is that the STP diamond changes to the position of the SPI as set by the HTS/HAD system. Hopefully this better explains what I perceive as the problem or allows you to see the flaw in my reasoning.

I just noticed the missing evidence tag. Thank you for taking a look. However, I'm not sure exactly what this means. Could a moderator explain so I could make another attempt? I thought the trackfile did a good job of showing the HTS/HAD designation action changing the Steerpoint diamond, which doesn't make any sense. It should create or move the SPI, just like the TGP or FCR --not update the steerpoint diamond. Please let me know how I can improve the bug report. Thanks again for your consideration.

I believe I found a bug with the HTS/HAD and how it changes the steerpoint diamond location in the HMCS after producing a SPI with the HAD as SOI. A trackfile is provided to demonstrate the incorrect behavior against an SA-2 site on the Syria map. 2x Harms are loaded on stations 3 and 7. After slewing the HAD cursor to a surface radar-emitter on the HAD, TMS Forward/Up will designate the emitter (e.g., an SA-2 in the trackfile) and perform a handoff to a HARM. This all works as intended, including the creation of a SPI; however, the trackfile also shows how this process currently changes the location of the steerpoint diamond in the HMCS as well. This is demonstrated in the trackfile by the steerpoint diamond symbol switching positions to the location of the new SPI (i.e., the box) set by the HTS/HAD. I believe the correct behavior would keep the steerpoint diamond at the location of the current steerpoint as indicated on the DED. To further demonstrate the bug, I cycle the current steerpoint from STP 1 up to STP 2 and back to STP 1 to show how the steerpoint diamond in the HMCS should be in a different location than the SPI set by the HTS/HAD. Doing this in the trackfile resets the steerpoint diamond to the correct location (i.e., the current steerpoint) with the SPI remaining in place based on the data from the HTS/HAD. I then repeat the process again after cycling the current steerpoint, at which point TMS Forward/UP on an emitter causes the steerpoint diamond to again change to the location of the SPI. Thank you in advance! hts_stp_spi_bug.trk

Bogey Dope has a great video on this. He's a former Viper Crew Chief. tl;dr: You have to open the refueling door on the ground. It's working correctly and as intended in DCS. My $0.02: it would be nice to have the option to add empty tanks in the editor, as others have already mentioned.

Excited to hear there is solid progress on a revised and improved manual. Appreciate the update!

Completely agree. The DCS Viper is in a great spot now and is probably my favorite module in DCS. Can't wait for additional updates to flesh it out a bit more. I am especially pleased with ED's recent efforts with the flight model and FLCS.

Great explanation. I also completely agree on the capability offered by a force-sensing stick. I recently purchased the RealSimulator FSSB R3L and I absolutely love it with the DCS Viper. It's incredibly agile and athletic now after the recent FM and FLCS updates. I'm a big fan of ED's recent work with the Viper.

Wow, wasn't expecting to find that kind of outrage here. Unfortunately, didn't have time for a longer response. I thought his video did a good job of describing pitch and roll control schemes. My deepest apologies for not meeting your expectations. Perhaps try to be more civil in your future online interactions.

Agree, this would be helpful.

This video should have everything you need. https://youtu.be/l9NOHSWK-Q4

Just out of curiosity, does TMS down (pressed twice) provide the same CZ functionality, or do we have to press the CZ PB for the indicated SOI? Thanks!

No worries, BN. Thanks for looking into it!

Just following up due to a lack of engagement. I've noticed some newer reports received responses from the team. Did I make a mistake with my bug report?