falconzx

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!)

@Lord Vader sorry if i bring this up again, but i think the last track is quite interesting in response of your latest answer. Gimbal limits should apply to the radar dish angle. In the track is clear shown what i claim: the dish in A3/A6 go where in A1 cannot go. Can we have an answer on this? Thanks. Take care.

My tests went pretty good. I used a runway number just to have something very detailed to look at and on a plain surface. I used TGP to fine check and doublechecked the behaviour on HUD/HMCS. Mastermode NAV, so only diamond on hud. My results: GPS is fixing correctly the drift, the errors caused by the GPS CEP leads to a mis-aligning of the correct STPT by a CEP of maximum 20m. I've seen fluctuations between 5m and 20m, on average it's most of the time off by 10m. I don't know if this is the desired behaviour but that's what it is now. At the end i also did a different test, i tried to perform a bad manual fix, by around 0.25nm of delta off. Then putting back the autofix, just to see how it was going to behave fixing a big error. The system in around 3-4 min (probably because of the kalman filter) gently moved the point on the correct spot(~10m) again. That was very good. Another thing i didn't like so much is the graphical drifting of the diamond on HUD. Initially i thought it was a bad aligning on HMCS (even if i aligned it almost perfectly using max zoom). But no, that happens on the HUD also. The point seems to be on the same spot where the TGP is pointing ONLY at very close distances(less than 100ft). When you increase the distance (very visibile already at 4nm) the diamond shifts, like the point where is centered is not at the center of it. Because of this issue when the TGP is off by around 10m, the diamond is off by 20-50m at 3-4nm and if you go even further away it's even worse.

yep I'll do it soon too, i'll post my results.

This is not what @bladewalker just showed in his tests and supplied images. That was not the correct way to report a bug, but if what we all see there is the current GPS->INS fixing implementation, then there is presumably a bug and someone should do a proper report. From what is my understanding the GPS CEP is that noise you're referring to. As the acronym says it's a circular error probability, so it's constant, under the same conditions it's something shouldn't increase overtime. What he experienced is an error increasing overtime. (typical INS behaviour) That error was visibly greater than GPS CEP. My deduction then is that GPS is not fixing the drift there.

Just for adding more clarifications, just because i read you are pointing out in the images the fact the coordinates are not changing on TGP: If your INS is DRIFTING, it's absolutely normal that your TGP is showing the same coordinates you preplanned but the point in the real world is "drifting" to a different location. The FIX procedure commonly adopted to fix the drift, it's exaclty done to resolve this. So you are telling the INS wich is the correct position in the real world for that specific steerpoint. And indirectly you are telling the INS which is your correct position in the world space. What i ask at this point is, why the coupling with GPS is not doing anything to correct this? what would have happened if you have waited more and traveled even more? is that drift going to increase, more and more? Shouldn't be any type of warning or notice? At least in the NAV DED page where the accuracy is rated with HIGH/MED/LOW words? At a certain point our INS pos is going to differ a lot from the GPS readings, is it correct that the GPS is doing anything to fix that, and if yes why? why is needed a manual fix then? By common sense the system could have a delta threshold to establish how much drift is tolerated before applying a fix(around the GPS CEP maybe?).

Given the number of weapons in development is increasing, i suggest in parallel to work on more variety of VFX and maybe associate them to the color/type of terrain or object hit. Some tips: -Create more types of explosions with increased duration per type/size of warhead and type of weapon, in general DCS explosions and their relative smoke or dust raised have a very short duration. -Change slightly the colour of the explosion smoke based on type of terrain/texture hit. Green/brown for soil and grass, Yellow/orange for sand, Grey for urban areas, with increased debris, white for snow. -Based on slope data(if accessible) or height data, add the number of debris/rocks relative to some type of explosions for mountain rocky/sloped areas. -More smoke/dust duration, means bending the smoke produced by explosions in the wind. I would add this influence not immediatly but after the first blast. -More variety of fires for "set on fire" things, like vehicles buildings, etc. All the current types of fire have different sizes that produce proportional amount of smoke. But the fire shape or the smoke shape and color they are very similar if not identical. I suggest to increase variation in these, like making the fire more irregular in intensity and shape, like having sometimes longer flames or irregular blazes, on random basis, to reproduce the variety of materials burning in a real vehicle. Same applies to smoke, just add some random to the colour and intensity, the amount and colour of smoke can be associated to a random basis per object at the start of the effect, and it can mutate randomly across the duration of burning. You can parent the values of randomicity to a coefficient linked (or even originated by item data or class) to items data to have some controllability per size or type of vehicle or object. If this system works good it can be applied with a more fast time evolution to the burning of aerial objects. The decrease in intensity introduced in the last years it's very appreciated but i think adding some bit of variations and unpredictability it's a key point that can make appear the sim core hugely more realistic with a minimal effort in terms of work for the team. Most of these i suggested are achievable just adding more instances to the effects with some variation in each instance. In general what make the current fires and smoke "fake" it's the lack of detail/variation.

Let's try again with a more clear track, now i've used active pause. Data to reproduce the incoerency: Aircraft state: Pitch: +30 Roll: + or - 90° Radar and Antenna settings: Azimuth: A1 and A3 Mode: CRM. RWS or TWS (not relevant) RDR CURSOR position: just put it close to the MFD lateral edges, without touching them (it will cause an azimuth change) Use Active PAUSE to mantain this aircraft attitude while doing the tests. Observations: In A1 the scan volume determined by the azimuth blue caret (bottom of the screen) is not following the RDR CURSOR on the entirety of its gimbals. More precisely as you can determine by the graduated scale on the bottom, the scan volume is limited by 20° degree on one side, so the gimbal is like 60° on the side not affected by the issue and 40° on the other side. Putting A3/A6 the azimuth caret will go and scan where the A1 just couldn't go. More precisely the antenna is going back to it's original +/-60. This happens on the left if you have left wing down. This happens on the right if you have right wing down. If you repeat the test with -30 pitch: This happens on the right if you have left wing down. This happens on the left if you have right wing down. If you repeat the test with 0 pitch: No issue is observed. Little offtopic(sorry), but i've no time to follow now to a different bug report: in the second part of the track i played with elevation to see how in SAM mode the elevation caret is not showing anymore the angle relative to the horizon (gyro stabilized) only, but seems it's alternating a nose relative angle while tracking the target. Considering that SAM it's alternating between tracking and scanning, that's theorically ok, what it's not ok it's the "delay" between the two visualizations. Seems like the antenna has to travel in elevation between the two phases, while it's only a change about relativity of the angle visualized by symbology. That's not correct, if i've not moved my ANT ELEV axis on my control, the antenna should be very close to the bugged contact, so there should be no delay or transition stealing time to scan phase. Considering the VERY limited time to scan in SAM mode it's important to "unlink" what's the symbology "speed" from what's the antenna actual position and moving speed. F-16_azimuth_scan_volume_incoerency.trk

I actually appreciated the efforts ED is doing to re-make systems that were working good enough for the sim standards, like the choice to implement a INS+GPS more deeply. Instead, this radar false returns, seems a step back to an ancient, well known, philosophy: all hat and no cattle. Seeing how much is WIP, it's a feature force pushed into the update in a state that can be titled only with: "fake returns", further explanations are quite fancy given that the user can't be convinced in any way this is not a fake graphical effect on the radar screen. You move the radar, nothing changes, you turn off the radar, nothing changes. I just give my two cents: we don't need candies and fancies, just pay more attention to the DEEP details that can make this sim good. Start checking the gimbals of the antenna on the scan pattern when azimuth is set to A1 and the aircraft is maneuvering with medium pitch angles, scan volume positioned on the gimbal limit and you roll the aircraft. If someone in the team only have the patience to do proper tests they will notice something wrong. A problem that only the F-16C has, but a lot of people just don't care because most of pilots don't use A1 and use the radar while leveled. This... months are passing and still we don't have a proper functioning AUTO MLC Filter. At the current patch its forced on, so it filter all even in lookup(no clutter) scenarios. I think going on with decorations while these and more core radar issues are still there its a waste of time.

I can confirm. I usually fly in quiet and i saw them.

In my squadron many pilots reported this crash related to the laser arm, they experienced it with ATFLIR only, expecially if starting cold from an airfield and mounting atflir via rearming. But they still not have exact steps to reproduce, it's like happening 50% of times.

UPDATE: Using template the STN can be specified to a correct number, this resolve the DCS crash issue. However all planes will have the same STN of the template. On F-16C you can edit it in cockpit and solve the issue. On F-18C you can't so the TNDL between dynamic spawned Hornets will not work! (Someone should report this in F-18C section)

Yesterday evening we tested dynamic slots in my squadron. I just enabled some airfields in ME. Then after startup, as usually we go to TNDL Page3 to configure our STNs/own numbers. Default for F-16 is only a strange number containing an "X" on 1st line, dobber down to select it and DCS freezes (you need to kill process to exit). It happened to all my squadron pilots. Maybe i can try to put F-16s under a template with a manual STN. Today i will test if it's a viable workaround.

After a short test, the issue in current patch remains, but now i think it's affecting F-18C also. In the previous patch i could add a F-18 to my team asking him to tell me his STN. Now it doesn't work anymore. Maybe because the F-18 also have to confirm his "position" in his team. Unfortunately i'm not aware about a way to do it.

I Confirm. And still not the AG modes like GM or GMT also.