BlackPixxel

The radio correction antennas on the R-27R/ER are mounted on the section with the wings, but their signal wires go into the radar seeker section (propably through that housing on the bottom that is only present on R/ER). The T/ET variants lack the antennas and also the radar/radio receiver to demodulate such signal. So no DL for them.

This is what is happening, extrapolation/memory mode sometimes does not enter, the lock instantly breaks: And for some reason in any of the close combat modes there is no extrapolation at all. Lock immediately breaks there. Even though vertical scan HUD footage of real Mig-29 shows that even there is some extrapolation happening. https://youtu.be/UaDBOiYq0r4?t=12 Note how after the shot he turns away, putting the target way below the gimbal limits of the IRST. But the lock does not instantly break, you can even see how the steering cue is moving as the IRST appears to scan the area at the gimbal edge in order to reacquire the target.

The change is that the Su-27 radar does not continue target illumination if you reacquire the target after STT lock was broken. So if you fire an R-27R/ER, lose STT lock and reacquire the target, the missiles will be trashed and won't continue tracking. Problem is that the Su-27 radar has a bug that causes instant loss of STT lock. In combination with that missile change it means that a missile that was fired before losing lock to the bug will be trashed, quickly relocking the target will not allow it to continue guiding.

Do you have a number for the total impulse? I would like to see how it compares to R-33 (in DCS: 37953 Kgs) The recent change with R-27R/ER behaviour sure is nice, but it would be better if the bugs with the radar extrapolation mode were fixed that frequently cause an instant loss of lock under normal condition. Now relocking after lock was broken due to the bug results in the missile being trashed. So Su-27 pilots get punished for the radar being buggy even more.

It looks like the other FC3 forum is not visited by the ED personel, so I try it here again. Some of these bugs got introduced a few month ago. I am pretty sure it has something to do with separating/rewriting the code when F-15C radar ranges got fixed. #1 Radar extrapolation mode sometimes does not initiate, instant loss of lock: #2 Home on Jam mode is broken when target is detected by OLS -> shooting R-27 in HOJ becomes impossible. #3 Launch authorisation for infrared missiles is given when the target is not even in seeker range, causing them to miss. A fix for these issues would be desperately needed, and also for the datalink that is totally broken in larger multiplayer missions. Thank you!

Bug is still present.

Bug is still present.

[100☭] BlackPixxel MiG-29A

Any update on this? Thread is marked with track needed, but a track was posted by okopanja a few posts above on March 24. This bug totally messes up the HDD of the Su-27 on populated servers.

Bug is definetly still there. But it could be that it is more likely to appear on high playercount servers. In small 4v4 scenarios it did not occur. Meanwhile on Growling Sidewinder with 64 players the datalink screen is all over the place. It is also not limited to the multithreaded version of DCS. I run singlethreaded and have this issue. From yesterday:

Yes, Datalink is totally broken right now and desperately needs an overhaul. Someone stole my scanzone + DLZ indication!! Here I stand on the ground but get the icon of a S-300 that just got launched missile Here I turn into AWACS He stole my DLZ + jamm strobe indication and is getting away with it! Targets that are detected or locked by the own radar don't show at the correct position on the datalink screen, they jump around to totally incorrect location. A good opportunity to also fix Su-27 plane to plane datalink not working in multiplayer while the datalink code is being worked on!

Todays update broke datalink even more, it now has massive issues even in singlethreaded mode. When radar is turned on, detected targets show at completely different positions than they really are. And the scan zone + DLZ indications on the datalink get fixed onto random aircraft. The own symbol also randomly changes to those of enemy aircraft or even AWACS. Seems like it needs a bigger rework. Would be a good opportunity to fix plane to plane datalink in Multiplayer while you are digging through the code!

Hi, here is another example from singleplayer. I hope it works: HOJ_bug2.trk I lock the bomber with radar. He starts jamming. Instead of keeping a radar HOJ lock, it turns into an EO lock. When I am in kinematic range for the R-27ER, Launch Authorisation blinks but never becomes solid. Holding down the trigger does nothing, the missile cannot be launched. Forcing EO off does not switch the lock to a radar lock, it will just stay in extrapolation mode for 4 seconds and EO will switch back on. Extending elevation gimbal limits of IRST causes loss of lock, even though the target is still within radar gimbals. Only by locking the target outside of the IRST gimbal limit I get a proper radar HOJ lock and can fire the missile. Hope it helps!

Looks good, did not encounter it yesterday!

Henlo! In the following track I present a bug that happens from time to time, where I am unable to lock anything in most modes. Here I was only able to lock any of the 4 targets in vertical scan. BVR mode with radar/OLS failed, optical mode failed and helmet sight also failed. But I am not able to reproduce it reliably. everything_is_broken.trk

Hello! Last patch added another bug to the growing list of FC3 radar issues: In multiplayer you can lock anything from anywhere - even with radar off from NAV mode. Pressing lock button will simply cycle through all aircrafts on the server, doesn't matter where they are. I attached a track: Server_1_Operation_Urban_Thunder_V7.2.9-20230126-215940.trk These screenshots show me on Growling Sidewinder server on the parking area. I am casually locking some enemy aircraft 280 km away. Note the missing HUD symbology that would be there for a real target lock. null

That is not what is written in that document. The document says that the kill radius (damage from warhead) is 50 ft.

The radar extrapolation mode in BVR STT has a bug. Under some conditions there will simply be no extrapolation. Lock will then instantly break. When that happens, exceeding gimbal limits will instantly break the lock, and the target changing aspects and crossing the notch for a fraction of a second will instantly break the lock. I don't fully understand when this happens, in one of my test missions it almost always happened when the target was locked with radar scanzone slewed in azimuth and the target locked far off boresight. In another mission it seemed as if it will not happen in lookdown. But I am not sure. I hope these two tracks will help to find the circumstances that cause this bug to appear, In the first track the bug causes the lock to instantly break when the target crosses the notch angle by simply flying a circle: bug_test-20230105-210727_memory_bug.trk In the second track the bug causes the lock to instantly break when gimbal limits are exceeded for a splitsecond: radar extrapolation bug.trk This is a very annoying bug as it does appear from time to time in multiplayer and causes loss of lock under situations where it should not happen.

There is a bug in the HOJ logic: Under some conditions, the HOJ lock will turn into an IRST lock, which makes it impossible to launch R-27 in HOJ and also means that the target tracking will break when the target exceeds the gimbal limits of the IRST. Following steps to reproduce, target needs to have high IR signature (e.g. Su-27, F-15C) 1. Non-jamming target is locked at long range. 2. Target turns on ECM, lock transitions to HOJ 3. Target turns on Afterburner before burnthrough range 4. If target is within parameters for IRST detection, the lock will switch from radar HOJ into an IR lock. Radar cannot be enforced by turning IRST off. It will just turn to memory mode and switch back to IRST. Exceeding the gimbal limits from IRST causes loss of lock. Even tough at less than 15° elevation the target would still be within the gimbal limits of the radar. Launching an R-27ER in HOJ is impossible, because for that the radar HOJ mode would be required, but the lock is stuck in IRST. Still the jamstrobe will be shown on the HDD. Only within burnthrough range can the lock turned back into a radar lock from this unwanted IRST lock. What should happen instead at step 4: Lock should simply stay radar HOJ unless manually transfered to IRST by the pilot. The following trackfile showcases the issue. Lock turns into IRST lock when HOJ target gets within IRST parameters, I cannot enforce a radar HOJ lock and when I exceed vertical EO gimbal limit by putting the target below my nose I lose lock. bug_test-20230105-212204_ecm_bug.trk

There is the following bug in Su-27, Su-33 and MiG-29 that makes it likely for IR missiles to not track the target after launch: When the target is directly along the boresight of the aircraft, LA (Launch authorisation) is correctly given when the missile seeker is within range to acquire the target and when the target is within kinematic range of the missile. But the further the target is off-boresight, the earlier the aircraft will give LA before the missile seeker is actually able to pick up the heat signature. This is very problematic, as it gives the player the impression that the missile is locked and allows him to shoot the missile in longer range off-boresight scenarios. But in the end, the missile will just fly straight and not track the target if the range at which LA was given is beyond the seeker range of the missile. The attached trackfile showcases the issue. The off boresight target is acquired, and the ET is launched as soon as LA is given. But due to the bug LA is given before the missile seeker actually sees the target. So the missile just leaves the rail and flies straight and unguided. ET_off_boresight.trk Meanwhile, in the head on example LA is given at the range where the seeker actually sees the target and it correctly tracks. ET_head_on.trk Hope it can be solved, as it frequently causes missile to miss. Thank you!

Thanks, will take a look at the flightpanel stuff!

Hi! Is there already a way to get Blackshark 3 to work with DCS BIOS? I would like to use my existing Panel from Blackshark 2 for it, but it seems that there is no module yet for it. Should it work with the default Ka-50 plugin, or would I have to wait until a dedicated plugin gets added? Maybe it is as simple as changing some name inside of the existing plugin and it would work?

There is a minor discrepancy with the UV-26 reset button. It used to reset the flare program to 110 and the tooltip when hovering above it with the cursor also says that it resets to 110. But somehow it actually sets the program to 317.

Seems to be fixed now!

I don't think anyone said that HPRF/MPRF ambiguity cannot be solved for most conditions. For a target only the range bins that correspond to its doppler frequency need to be checked, and there will only be a few peaks. So solving the ambiguity will be simple. But when the target is in the notch, the range bins that corrensponds to its doppler will also be full of ground return. So you cannot just search for single peaks and compare their positions over multiple PRFs unless the target really stands out due to favourable geometry of the setup.