falconzx

it's a work in progress feature.

After some rapid tests on new openbeta in multiplayer, it's clear that the new modeled FCR do not consider Targets RCS (all aircraft types appear at 40nm but this is a detail) and the target does not receive any radar signal on his RWR from our radar farther than exactly 40nm! A very stealthy radar... i hope this simplification is a step of a wip radar modeling. Same identical thing happens on F-18C. Hope this was useful Cheers.

I have done more tests, it's more simple than that i described. Put the Radar Azimuth to A1 (just to make the problem more evident), put the scan to the full left or right, climb or dive 40° degree(it's enough), then roll the plane (it happens on certain bank angles) Look at the scan while doing this, you'll see it moving towards the center... And if you try to correct it, you can't. The radar should be gyro leveled, if something odd happens when you just roll the plane, it's definitely a bug. I hope this helped investigation. Cheers

When i'm in cockpit, Map only setting, i can't read data about an airport. I understand the choice to hide Warehouse data in MP. But it should be like a filter for that tab only. Now in maps without charts, like Persian Gulf or Syria, if you want to check ATC frequencies, ILS frequencies, while flying, you just can't.

Mfd are ok like they are now for me.

With the last patch i found a new bug. If you put radar azimuth scan narrow (+/- 20°) after creating a track file on a radar contact and bugging him, if you return to scan, while climbing or descending with an high pitch angle, the scan try itself to move to the center in a weird and uncontrollable way. Then after a while (probably when the trackfile fades) all returns to normal, and you can control azimuth under all pitch conditions like before. It's problematic when you re-engage after defending, because it's the classic search you perform in an interrupted f-pole tactic. This bug was introduced with the latest patches, i'm sure it wasn't there before, it started to happen in some combat manouvers i perform in the same way by ages. f-16_scan_azimuth_weird.trk

Exactly, "aspect" in closure speed mean, it's the vector you are moving and not where your nose is pointing, and as you said it's considered, so if you are drifting, your aspect is not what you think it is. So as i said, posting random server tacviews without paying attention to the environment variables it's a mistake. Even if not so relevant, "the number of chaff in the FoV" is another factor influenced by weather conditions, btw, expecially at close ranges. Something moving with your plane is in the fov more than something flying away your plane.

Do not SAY things you don't know, it's possible that someone here in the forums is going to actually trust your free words. Here a video i Just did 10 mins ago to demonstrate what i say. Just make your own tests if you don't believe it, and look at tacviews.

who are you to say what is correct and what is not? Nobody has such data to say what is possible to happen and what it's not. In the real world you have a lot of factors to take in account in the simulation: like packet loss in the missle-plane transmissions, degradation of signal by weather, various malfunctions, ground moving objects in the clutter that emerge from the doppler filter appearing as chaff, time of the dispersion of every chaff can't be equal, it depends by wind, speed of the aircraft at release. In DCS chaffs should move in the wind, that's mean that all your tacviews are not very useful if you don't specify the wind conditions. In short words, a hot moving chaff will emerge from the clutter filter differently and permits a notching aircraft to disappear in favor of a well visible chaff. A flanking moving chaff change completely the scenario. So, i hope guys who fly both MP and SP knows very well how an AI can notch much more precisely than a human. If you go on a MP server you will see how this kind of AIM120 close range fails will not happen so easily. I think ED did a great job in the latest patches to improve and get closer to a much more realistic missile. The probability coefficient way it's the only way at the moment to implement all the possible causes of missile guidance errors. People who whine and scream about a perfect missile, remember we are not in Ace Combat, and here you will find other likewise people who will scream and ask for a less perfect missile.

Let us know if you need further tracks to report this bug, thanks :)

I confirm, there is a problem on the right side of the scan pattern. The radar head get stuck there.

As stated in the title. Seems something changed in Link16 compatibility between F-16 and F-18. I red some posts on f18's bug section about some issues they have between them. Nobody posted anything here about what happened on F-16C Link16 in relation of their issue. Seems we see F-18s for just one second on HSD when they spool up the plane, then NOTHING. Other clients F-18s are invisible and we do not receive anymore informations from them. Hoping it helps, Thanks.

You are right, so the problem is that i'm used to doubleclick the central button of mouse, to make appear/disappear the cursor. In fact with FC3 planes i don't have the issue. Before was possible to unassign "mouse 3" from "camera transpose mode", and now even if you disassign it everywhere, clicking mouse 3 activate that behaviour instead of zoom. So the Fix would be Eagle Dynamics to remove that mouse 3 hidden assignation, like it was before this patch.

I'm providing another little track showing the bug happening 4 times! I'm just moving left and right the scanning area. Sorry for the size of the first track, even if short it came up from the Free Flight of instant action mission, i realized now that mission is a little dense. f-16_scan_pattern_stuck2.trk

Noticed that in the last OB "Camera transpose mode" is by default in the opposite function by before: BEFORE 23rd sept. patch: You enter the cockpit, scrolling mouse affect zoom. AFTER 23rd sept. patch: You enter the cockpit and scrolling mouse affect pilot head Z-Position. For me and for all the users that are used to zoom with the scroll (like Saitek throttle scrolls), it's a very annoying change. Just to say, i used to de-assign camera transpose mode to do not press it accidentally when making cursor appear. Expecially because i use trackir to move my Z-position!

I'm encountering this bug even in the previous OB release, so it's here since the middle of august. In this track i'm trying to reproduce doing fast, little random antenna azimuth movements, with the smallest azimuth it's more frequent, probably there's something odd when the scanned area is moved in certain moments of the bar pattern. As you can see, when it got stuck the azimuth is completely blocked, the bars instead continue to loop between two, despite every bar setting. I ensure you, i accidentally have the scan blocked 3-4 times during an A/A CAP mission. It's very annoying. Thanks for the help. f-16_scan_pattern_problem.part1.rar f-16_scan_pattern_problem.part2.rar f-16_scan_pattern_problem.part3.rar

What you miss here is a simple reality: The code of DCS is an old mess, to improve something, you have to break something. You and more complaining guys have just to understand this simple thing.

What you asking for is exactly what the Open Beta is. And, it's called Open Beta for a reason. People are used to play everyday on OpenBeta asking for quality but they confuse what they are actually doing: TESTING, and help ED to find bugs. I don't think ED should do different like this, they have a large community playing OpenBeta and they help them to find issues through their forums. Who is bored of this job can just install Stable and play. Who plays OpenBeta should be warned and should behave constructively. :smilewink:

We're encountering another BIG issue with new 120s in MP, in terms of De-sync and inconsistency of events observed between CLIENTS. If you use those new missiles in a private server and you observe from 5-6 different clients what that 120 does, you will face 5-6 different trajectories, and endings. (in ext views, but it's easier comparing Tacviews) Even some of them observe the missile exploding on target, the target doesn't die. In other different cases, the target tacview shows the missile as defeated doing loops and he suddenly explode without reasons (for him) because the server and the launching client tacview shows a direct hit. Against Chaffs same story, on TACVIEWS of some clients you see that missile turning on chaffs, on some other client's TACVIEWS you see the same missile keep tracking target correctly! This is completely ruining our MP experience, the fake explosion with F-16C's GBU12 was the first symptom of this netcode problems, and we urgently need a fix about it... Another bad story about this NETCODE is the fact you cannot do fast manouvers like High-G barrel rolls, because it generates LAG and because of that you do a missile successful evasion. That's a big problem in terms of realism and MP balance and fairplay.

I confirm those bugs RDR Elev knob STUCK on middle position. :( It was working like a charm before :(

36° Stormo Virtuale Team League: Diamond Squadron Name: 36° Stormo Virtuale Teamspeak/Discord: https://discord.gg/xBJuwVX Contact person: =36=Falcon, =36=Drigo Aircraft Selection: F-16C, F/A-18C, F-14B, M-2000C, JF-17, J-11A Pilot Roster: -ALL PILOTS are from ITALY GMT+2 Falcon Pit Truthkeeper Drigo Evil Dirty Arawindor Witcher® Eircog Majo Rabo Caronte® Wolf® Airwolf® Rafiki® Led® Cisco®

New RWR sounds in 2.5.6 seems very odd, i personally don't like them, preferred the previous, much more efficient, because of a greater variations of sounds. Despite personal opinions, maybe i found a bug, with some slow locking sam stations like SA-8 i found out that the sound of spike is like stopping playing. The launch in the silence could be the thing, or maybe i'm missing some tws or optical tecnology of SA-8 in that case nevermind. If i point straight on, hot on the SAM it doesn't happen, because he's going to launch faster. Here the video of that: https://streamable.com/uihpo

any chance by ED to fix this rotary to absolute rotation knob, like all the others planes (except the f18 )?

Guys, as i reported on a different topic ( https://forums.eagle.ru/showpost.php?p=4040263&postcount=8 ) the radar has huge bugs. To fix this you have to turn STANDBY and ON the Radar to reset the BUG. The ranging on special modes remains broken, no way to obtain a lock on a target in optimal condition at the max specified range. (a big fast su27 hot up in the sky with no cluttering) I wud expect to acquire it at 20nm on SVI and 10nm on Boresight. The theory is: as the radar is able to catch and lock a contact at 25nm on normal scan>lock mode, i assume it see the contact on special modes as well, as you have an hidden scan mode that automatically locks a contact whenever it finds one. So there is no reason to limitate the range like that, special modes are just different radar pattern movements, but its the same radar with the same emission you have when you acquire a PIC lockable target on tws.

I noticed the big bugs on the Radar too, i just didn't reported all the bugs i found because i red RAZBAM declaration about the radar that's not what they intended to release ( i wonder about how they don't TRY things before releasing ..) So i'm confident they will fix in the next patch all the problems we have now like: -Negative Antenna Elevation doesn't react to rising axis command, it waits bars to complete before rising. -BFR completely broken, or non-existing anymore. -Loss of contacts, even if the elevation is correct, parameters correct. Temporary fix: turn STANDBY/ON the RADAR to reset and avoid the bug. -Top bar spotting contact indication is barely invisible, i don't think real one is like that...You need a lens to see the little segments on the tails of the contact symbol. -The number of the bars near the antenna elevation indicator on VTB is often un-aligned, expecially when negative. - Special Modes (CCMs) are completely uneffective, if this radar is capable to STT lock an hot target at 30miles, i don't understand why a boresight mode is not capable to find a target more than 4-5 miles. It has a 10miles max range, so il should work from that range in optimal condition. Same story about the SVI mode, 20miles, and you can't find anything over 5 miles in optimal conditions. What's the sense to have 20miles limit then? -Remanence switch and functionality (do we will have it sooner or later?) A radar rework could be a nice occasion to fix it. Probably there's more but i don't remember now.