falconzx

Yep, it's a good thing, You can have different settings for different screens and modes, it's an awesome feature, use it

Steps to reproduce: -Set TWS. -Find a target, wich is a lot lower than you (that's very important!!). I just bumped 10/15 angels more than a 15/10miles bogey. -Lower the antenna and bug it in TWS. -Move the elevation axis DOWN and leave it there ( just the physical axis, it will not be affecting the symbology because the radar is scanning the bugged's elevation) -TMS down to unlock the target. -Now try to use the elevation, and tah dah, It's not centered anymore.

In the last patch, i experienced radar elevation freezes in TWS. Probably it doesn't happen to who is using buttons, i'm using analog axis so it could be only related to that. Anyway...it happens every time so it's very easy to reproduce. I just did it now in free flight mission. Steps to reproduce: -Set TWS. -Find a target, wich is a lot lower than you (that's very important!!). I just bumped 10/15 angels more than a 15/10miles bogey. -Lower the antenna and bug it in TWS. -Move the elevation axis DOWN and leave it there ( just the physical axis, it will not be affecting the symbology because the radar is scanning the bugged's elevation) -TMS down to unlock the target. -Now try to use the elevation, and tah dah, It's not centered anymore. Hope it will be fixed soon. It's a thing emerged recently, i'm pretty sure it was ok in the previous patches.

Squadron Name: 36° Stormo Virtuale Aircraft Selection: J-11, MiG-29, M-2000C, F-16C, F-15C, F-14B, F-18C Timezone : UTC+2 (+1 winter time) Pilot Roster: =36=Falcon =36=Drigo =36=Ghost =36=Merlin =36=Rabo =36=Darihawk(R) =36=Dankym =36=Redshark(R) =36=Eircog =36=Warhawk(R) =36=Mav =36=Tournament =36=Majo =36=Firo =36=Johnny =36=Devil =36=Falez(R)

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®