Lord Vader

Hello @Draken401 I will only address two items in your post. 1- The original post was not closed. It was merged with another topic by another user who had the same issue with CZ. There was no need to create another topic, you could easily continue the conversation on the original one. But, that's ok. 2- We at ED can only commit to changes that are properly documented (and public) about the model of aircraft we're replicating. To create a product based on what we "feel" is ok, that would be "arrogant audacity". On the contrary we only want to replicate the real aircraft as accurately as we can. Regarding all else, it's already been explained what the correct behaviour is, by myself and other users. Indeed we are all listening. Happy flights.

Hey @VarZat If you are talking about broadcasting a SEAD target via datalink, by designating in the HTS page and then broadcasting via transmit switch, then, yes, it is correct that only the receiving aircraft get the data (target position slashed with threat ring on HSD). The logic is that the emitter doesn't transmit data to itself. However, you mentioned "TDOA" and that's a different thing. When you initiate a TDOA, you're not transmitting target positions to anyone, so no targets or threat rings are displayed on other aircraft. Regarding how SEAD targets broadcast over datalink and TDOA logics, we've reviewed the procedures internally and found them working as intended.

Hello @Bucic Thanks for bringing this to us. I've raised this internally for analysis.

Hey @Grodin These chimes we're earing in your video replay, aren't these Windows device connection/disconnection sounds? In any case, we've reviewed your tracks using our internal analysis and concluded the system is just correctly responding to an input. This means there could be an issue with your own control inputs. Please check the following: 1- Your assignments are correct and you don't have multiple axis or buttons assigned to rudder input, including other hardware devices, such as gamepads, you may have connected to your PC. 2- Your hardware is fully working, properly calibrated and not having axis spikes. If the above is ok, please try deleting all rudder axis assignments and even move the assignment lua file (you can move it back if you see no difference) to rebind your controls. After that, let us know if the problems persist.

Hello @amadeus Indeed your track isn't really helping your cause, here. Like @admiki suggested, this could very well be a mission issue (somehow). Can you try to reproduce this issue in a sigleplayer mission? I certainly couldn't, coop rockets seem to work ok for me each time I tried.

Hello @ivo For some time, the laser code is only available in Mission Editor and in Rearm/Refuel window using the ground crew. Regarding a customised mission, if you can't create one yourself, check the user files section on our website, there could be a mission with what you want there. You can even easily edit it to include any variant you wish.

No problem. But for a moment you made me think twice about my post...

Please read the DCS: F/A-18C manual in the page I cited.

Hello @Grodin Thank you for the track. Indeed I can see the induced rudder input in that track. However, I cannot reproduce this, even following your steps in a singleplayer or multiplayer session. Entering and leaving the LSO station back to the cockpit, no change was observed on a rudder. This was tested on a mission created from scratch with just a F/A-18C and a SuperCarrier. I created an aerial hot start above the carrier, initiated a left turn, trimmed it, then hit ALT+F9 for view the LSO station and back via F1. Did I miss a step? Also, can you reproduce this in a simple singleplayer mission?

@Capn kamikaze What I think you're trying to do is Force Correlate (F/C), but you are probably using centroid tracking. From our DCS: F/A-18C manual, page 397: Force Correlate. Cycles between centroid tracking and forced correlation. Centroid tracking attempts to track bright or dark shapes in the image and is more effective against moving vehicles. Forced correlation attempts to track part of an image and is more effective when pinpointing part of a larger structure. Try this to achieve the intended precision. If you feel there's still a problem, please create a track file and share it with us.

We will certainly review the hot/air start statuses for some minor needed corrections. For now, please clear the message by reviewing the BIT page to clear the advisory. It's not really a complex step, I'm sure you agree.

@dr_hippo I watched your track and see the issue your describe, of an induced roll on the aircraft cyclic to the left. However, analysing the event, it does seem this is a user input to roll left. I've seen this happening either with unintended axis assignment or actual hardware fault. So, again, follow the steps that users and myself suggested before and let us know if the problem persists. Trying the exact circumstances and actions with my hardware, I had no issues with the aircraft controls on my side.

Hello @Hippo Thanks for bringing this up. We are aware of the NAV status warning at start. This is something we are reviewing currently on the hot or air started aircraft. So, for now, we understand the annoyance it may cause but please do turn the knob to IFA manually. As for the BIT warning, it's just doing its job announcing the BIT page needs reviewing. The BIT system itself is still being worked on for now.

Like mentioned before, The DCS: F/A-18C manual is to be updated soon to better represent the current module content and status. We understand an outdated manual can sometimes confuse the users but we do need time to make it as accurate as possible.

It depends, @raus, lengthy multiplayer tracks often can't be used for debugging, unfortunately, especially if servers use scripts or mods. If there is an actual problem with the aircraft response, then it's probably reproducing in a shorter scenario. If so, let us know. So many issues can happen, from damage on the aircraft, to wake turbulence, there could be a problem but it depends a lot on the circumstances. That's why we need a track.

Just from @matumomatumodescription, I can't say it is a bug or not. If you understand that each weapon needs to be setup independently, if you do not step to the next station, it makes sense that next weapon remains default.

Hello @ShermanTank We need to see what you are doing. I was able to reselect the same waypoint as target. Please supply a track file of what you're experiencing so we can analyse it.

Hello @Capn kamikaze Like @rob10 said, the IR seeker locks to contrasting objects. So what you are describing sounds correct.

Again, the Cursor Zero logic has been refined to replicate real world data from the F-16C Block 50 CCIP to our DCS: F-16C. If you think this isn't working as the real aircraft would, please supply publicly available non-classified documentation to prove otherwise via private message to @BIGNEWYand we will look into it. Unfortunately, we cannot commit to changes based on personal opinions.

Thanks for this @admiki I've raised this internally for analysis.

Hello @dr_hippo Just from your description and your images, we can't come to a conclusion. This looks like an issue with your controls but that's just speculation as we can't see what's happening. Make sure to follow the suggestions already given, such as deleting the axis assignments completely and start over, just in case one of those axis is wrong or switched. If none of that works, try to start over by moving your assignment .lua file to another location to reset controls (you can move it back if you see no difference). Another suggestion is to look into your HOTAS/HOCAS axis calibration just in case you have a hardware issue. Or make sure you don't have another idle controller connected to your PC interfering with these axis. Finally, it would be interesting to share a trackfile of this event and even a video capture as well, if you can. Be aware that increasing or reducing collective will always introduce side-effects to the aircraft's attitude, including yaw that you need compensate with pedal input. The same will happen with firing Hellfire missiles or the cannon, that will also introduce some movement or rotation, especially to a hovering aircraft. If this is what you're experiencing, this is correct as is, demanding some level of coordination with your controls.

That's a good question and I hope this explains why we often request tracks: Tracks act like "flight recorders" of events and helps us, above all, reproduce the issue. It won't just create a new session, it will replay yours, including possible issues. So, ideally, in this situation if you can send us both your track and your CPG, it can be a excellent demonstration of what you are doing (procedures) and what the system is doing in response. Sometimes, we are just unable to reproduce the bugs people claim and we want to make sure we have the very same conditions the players have to observe the bug. I hope you and all others with the same question understand better why tracks are so important for this debugging process.

Hello @Draken401 This is correct behaviour. Every time you move your cursor to a point or area track you're adding a delta to the sensor cursor. In order to remove these deltas, you'll need to TMS aft or select the MFD "CZ" option to Cursor Zero.

Again, the TPOD is slewable in NAV mode without weapons on board, for sure. The limitation is only in AG mode which I'm sure the aircraft maintainers wouldn't require to engage while performing tests.

Hello @Moonshine Unlike other aircraft, such as the A-10C, the F-16C logic follows a single line-of-sight to a single SPI, so it's not possible to move sensors independently to obtain different POI and then make them SPI. The only time this can be done is in NAV mode while the TPOD or any other sensor can be tracking different points. You said so yourself. Now, the question is why is the TPOD stuck as if the delivery mode is CCIP when there are no AG weapons on board? Well, if no air-to-ground munitions are loaded, then no air-to-ground SMS profiles are available to provide the weapon delivery sub-mode selection. So it "defaults" to a CCIP behaviour since it's the first mode in that list. In the future, this may be mitigated with the DTC system allowing us to predefine a weapon profile, but that's not available right now. I believe what you'd want was to engage a snowplow mode when switching to AG, however, this is only available if the weapon to employ is set to a pre-planned mode, like CCRP/LADD/PRE. As we said in the past when this particular question was raised, we always ask why enter AG mode if this is an "Air to Ground weapon employment mode", while there are no weapons to employ at all? If you have a full implementation of the TGP (FCR and HTS) modes in NAV master mode, allowing you to operate all sensor logics, there's no actual reason to switch to AG at all. Unless you want to use guns for strafing but that mode, again, requires the FCR in AGR mode. In a future update (very soon) we will have a new version of the DCS: F-16C Viper manual that will have an excellent explanation of all these logics. Rest assured we're replicating this module as close to reality as possible.