falconzx

Just tested in current patch: If you act as you described with no target bugged, just in scan, the radar will stop working, and even if you go MUSIC OFF the radar will be frozen and unoperable (probable bug, and not intended behaviour). You can fix the radar only going back to mode3 and cycling the MUSIC ON/OFF. But, reproducing your steps while having on FCR a bugged target, then the radar will continue to work and the ECM will continue to transmit ( another bug as i said before the patch, probably it should stop transmitting)

to me, sounds like a bug.

For me this issue was persistent every time i enter a server, i do a sortie with other modules, usually Su-25T, then if i sit in a F-16C i have problems with the HMCS alignment, i do it correctly and all the references are offsetted (not only the SPI box, but also PDLT). When the bug is much more severe it's hard to complete alignment because the real cross is not where you see it, so you get ALIGN FAIL if you try to do it correctly. After a lot of attempts aligning with the head around the hud you can also get the ALIGN OK then try to correct with second and third phase, but also like this you will not get a proper functioning HMCS. So to avoid that nightmare before sitting in an F-16C i quit the server and rejoin it. This worked for me everytime.

do you exit the MARK page after creating marks?

Decide with your friend a STN table with arbitrary number. Like 1 - 00023 2 - 00024 You both populate in your DED the table identically. When done the leader put #1 in "Own" position, the wingman will put #2. It will work. If not probably some of you messe up something. Also the DLNK time is important to be syncronized. If in a pre 1993 mission check time in Page1 and syncronize with your mates manually. In a current date mission you can Just put GPS Time On and all ll be ok. Inviato dal mio 24069PC21G utilizzando Tapatalk

I had some trouble designating targets with FCR GM (nav master mode) nearby SAMs. Attempts to designate someting (to retreive coordinates for example or performing a nav fix or putting a markpoint), on the same bearing of the SAM station but at slightly different range result in a SPI shift on the exact position/range of the SAM (way more precise than a HTS PGM2 solution... that's the funny part :P) This is pretty annoying when trying to use FCR to create a fast markpoint in order to POS HARM launch (closer than the target to enlarge the search area of the HARM over the target zone) because of this shift. Here the track. SPI_moves_FCR_close_sam_emission_FCRdesignation.trk

I apologize about my track, the LOS vertical angle between me and the contact was not so big(~20°) to see the bug clearly. In this second and shorter track i prepared a situation where the case is very clear. Steps to reproduce: stay high, wing level, command STT on a plane flying on the deck, hot. When he pass under you it will break the lock as he passes the 60degree gimbal. FCR returns to search and the ANT ELEV Axis will be broken. Detailed issue observed: As you reproduce the steps the axis center (50% of the potentiometer range) instead of centering the antenna on the horizon (0 degree angle) it remains where the contact has dropped, so in this case -60° degree. As this in effect you are no longer able to put your antenna upper than 0 degree, because you reach 0 degree as the potentiometer is at its 100%. I supposed you developers can see whats my pheriperals input status is in the tracks, if not, its very hard to check this from a track file. You should repeat the steps with an absolute axis assigned to ANT ELEV knob. I'm pretty sure you will not see the bug if the controller is a relative axis (like F-18 one) or buttons. F-16_ANT_ELEV_AXIS_RECENTERs_2.trk

In this track i intentionally drop contact by gimbal limits, after a couple of try my radar elevation is not anymore centered to 0 pitch angle as it should with physical axis in the center position. Thank you PS: workaround to momentarily fix is to cycle radar modes. F-16_ANT_ELEV_AXIS_RECENTERs.trk

Squadron Name: 36° Stormo Virtuale & SIG A101 Aircraft Selection: F-16C, F/A-18C, J-11A, F-15C Pilot Roster Falcon Wasp Merlin Knight Duriel Wildcat Iron MTSection Varmo Tralif Stockman

In the past i also used to put in NAV the FCR in GM mode (AG). It's done via OSB buttons, but it's still not retaining in the current patch. After switching master mode it resets to CRM RWS.

As a lot of manuals describe (i can send it to you if needed), the Hotas function TMS-right depressed more than 1sec should transition from any CRM RWS mode with or without a track target to TWS retaining eventually bugged targets. In the current patch, if i do it i get VSR, (locking the bugged target to a VSR STT... not very stealthy) then from VSR i get the TWS.

SPI is constantly updated (and sent to bomb) by the Sensor Of Interest.

Not realistic in VR. Too big. On screen they are fine.

Yep and as i tested, if your video would been longer we would have seen the fix's corrected position moving towards the original position in a number of further updates.

Absolutely no need, I described enough to reproduce. Maybe someone else could help providing what you asked. Just my two cents: Track target is a simple and basic state, it's telling you: hey pilot now i have built vector data on this contact, now you can use it to track and eventually select it for engaging. (bugged target) On the other side bugged target is the selection of a contact so it's just plain that a symbology very obvious like the dashed line is related to an engaging phase, underlining what's the target someone is engaging. You also implemented the flashing of the dashed line, in single player, when your wingman launches a missile on a given target. (not working on Multiplayer, another bug reported ages ago) Whats the meaning of it then? If it's correct having a random dashed line on a random guy and not the one i'm engaging, whats the point to spend your time to implement a flashing dashed line for launches if they are not directed on the right guy? Best regards

It's really appreciated the introduction of the new logic for sending contacts over TNDL. Now instead of Bugged Target, the Track Targets are sent, it has a solid logic: if you have vector data its possible to share it. Good job! Now let'see the bug: Multiplayer: if your mate uses TWS, the HSD dashed line is applied to the last Track Target created and not to the Bugged Target.

we've had this bug all summer, at least...

Speaking about common sense: think about a case where you have an enemy helicopter, you find it with FCR, you lock it with PointTrack, then he lands, you lose him on FCR but not on TGP, if there is a mode (NAV if i understood correctly) that allows you to obtain a slew of the SPI there then you can easily switch A/G master mode and engage that landed target with any type of ordnance. That's a nice swing-role capability.

I still don't understand how an aircraft so well modeled around pilot's needs has a radar that translates target speed into CAS. For intercepting slow aircraft? In combat it's quite tricky to read, when TAS was a lot better. Good old times. It's odd not having a setting to change it in CNTL All other fighters have TAS or Mach readings, that's the energy state in combat.

Squadron: 36° Stormo Virtuale & SIG A101 Timezone: 1900z-2100z Aircraft: F-16C, F/A-18C Maps: Cauc

Nice, i didn't find it on changelog, we will test it soon.

Well, today I had time to do it, and I'm trying to report another bug in the F-16's FCR. I had already mentioned the problem in another topic, but it's more appropriate to create a new one. Steps to reproduce: Place two aircraft facing you, both at the same altitude, in spread formation. Bring your own aircraft to the same altitude as the targets. Set RWS A1(optional) and B1 (this also to make the test easier to understand). TMS up on one of the two targets to switch to SAM mode, then return to A1(optional) because SAM has its default in A3. Now try to scan the second target. There shouldn't be major problems, although only in B1 can you get a fairly frequent illumination of the second target; leaving it in B4 is still very difficult because the scan periods are divided between the bars. Using B1 is also a way to make this test more reliable, at least we have the mathematical certainty that the second target will definitely be in the scan volume, always and in any case. Up to this point, the bug in question is not present. Now, bring the aircraft to a fairly steep pitch, +30/40 degrees. This is to better observe the problem, which is always present even with different attitudes, although less annoying. We will never be able to find the second target. Conclusions: In my track, second test, in the final part, I couldn't see the second target. I noticed, observing the elevation blue caret, that when switching to SAM, the elevation scale symbology changes its reference point. That is, if in SCAN the symbology has the horizon as a reference, in SAM it has the longitudinal axis of the aircraft as a reference. This is a choice, and not knowing the real aircraft, I assume it was made because it's correct this way. But the problem is not the symbology, but the movement that the antenna tries to make. In short, the antenna seems to try, starting from the target's elevation on a scale relative to the aircraft's pitch, with its movement to put itself at the point requested by the ANT ELEV KNOB in reference to the previous symbology (i.e., stabilized to the horizon). All of this is absolutely unnecessary, the antenna is already in the correct position, it just needs to stay there and continue sweeping, right and left! I hope I've been clear... If further explanations are needed, don't hesitate to ask, I'll try to describe the problem in other words. The track is attached. Thank you. F-16_DTT_Symbology change lead to incorrect radar dish position.trk

If it can help: I suggest focusing on the symbology at the bottom of the MFD, the blue caret. Looking at it, it will be evident that in A3/6 it moves freely until it touches the edge of the screen, while in A1 the scan is forcibly shifted, forcing the blue caret to a limited movement. If in A3/A6 the blue caret was able to scan at that angle, there is no logical reason why in A1 it cannot move the scan to that point. Thankyou and take care guys.

Hi Yaga, thank you very much for the support. Since 2021, when I reported this bug, I have been living with this problem. It's a very serious bug for highly experienced pilots like us who use the F-16 in tournaments and competitions. Perhaps casual users who don't push the limits don't realize how severe it is. But unfortunately, it seems that despite clear tracks accompanied by all the explanations I could give to describe the problem, it's still not admitted that there's a bug. In my opinion, there's a comprehension issue on Eagle Dynamics' side. I clearly wrote that a case is visible where the radar dish sweep is limited to 40°, and I listed the steps to reproduce the phenomenon. If, faced with this, I'm told that "it always seems like a gimbal limitation in a turn," then I give up. I give up because we all know that the F-16 has a gimbal limitation of 60°. I even created a 3D model to understand, in a +30° pitch, how much the horizontal azimuth reduction is, and I recorded a video to show it. From my readings, it results in very few degrees, far from the 20° degrees lost in DCS. here is the tacview of the track I recorded. Tacview-20240817-122221-DCS-F-16_azimuth_scan_volume_incoerency.trk.zip.acmi

no need to go in TIME page. Just go in DLNK page: in P1 you have the GPS time, press any number to switch it to ON. When done, you should see the SYNC on the bottom going from COARSE to FINE. Then you can go in P3 and set your TNDL table as your preference with your team mates. Remember to CONFIRM the OWN number, even if it's correct you have to digit it again and press ENTER. (This is still a bug in current version!)