falconzx

The simple reason of that is: in real life you have just ONE life. Amraams like any other human artifact is imperfect but still dangerous for someone who have just ONE life. Here we have infinite lives, so don't blame ED if they make missiles more realistic. Just understand that here people don't have to go back to base to live another day, you can try and try to die more and more, and learn, until you find a way to survive even in a complex storm of imperfect missiles. Here you will have the opportunity to learn this. And this is something that nobody in real life will never do. So if you act in a "non realistic way" is not necessarily a simulator problem in this case, but a people's choice. So guys, just stop to speak about real life in an amraam topic pretending to know how an amraam would behave and how much hard should be evading it. Fortunately the real world never saw an half of what we see in a single hour of combat in this simulator. Someone speaks about "gameplay" like this environment should be "balanced", or even palatable to a fair "competition". Oh my.. this is not a moba game, this is a simulator, and the reality doesn't pretend to be balanced. And we are speaking about a BETA version, remember it.

It happened to me too when my wingman with pdlt active on him just passed in front of me while i got TWS active. The track file on him was created (and maybe i bugged him switching targets with TMS right on FCR) and PDLT octagon freezed in that position. When this happens if i make HSD SOI and i try to TMS right to cycle, the cycling action stops on the bugged one and do not step more foward.

At the moment i think this issue is the priority, it makes the missile quite useless. For the notching angle window, from what i tested personally it seems a little bit reduced, but i'm not here to say if it is easy or not, and I'm not interested to discuss if it should or not. At least until we speak through subjective statements. In DCS i think the intent is to reproduce a missile with all his flaws and limitations, how big they are and how they impact is not my business, i trust ED choices and its sources. For sure i would not love this simulator, and i wouldn't even call it simulator, if the missiles were a launch=kill weapon.

They still aren't automatically synced. Press 3 times TMS right (OA1->OA2->back to TGT) is a workaround for now.

Ok yesterday night i've made some tests with my squadron mates in MP. What emerged is a problem with the inversion of closure speed. Seems that the missile loses the target easily when the hot target just turn cold. No CM involved, just an extending turn. On the other side in some pure "notching" test the missile was pretty good, you need to be very precise on angles to get a lock loss, and it is quite fast to reacquire you like before. So what we suggest to the team to find the issue is to test the hot to cold target maneuvering cases.

Thanks for the dogfight workaround. ED please, we posted a lot of tracks, a lot of evidence of people reporting this issue in multiple threads. I can't believe it's still marked as "can not reproduce". The recipe is: use the axis for elevation, fight against a target with an huge difference of altitude from you.

In this track you can see two issues: -First, when i roll 180° degree, and i want for example scan the same area the contact is, what you can see from the carets is that radar is struggling to move out of the area i want to scan to retreive data of my bugged contact, this should happen when i search in a different portion of the airspace, and not when i'm searching in the same area. On the other side, when i scan a different area, the radar position is very close to the target... The same happens to the elevation but it's less evident in this example. -At the end of the track i make some rolls keeping my heading quite steady on 360°. Look at the Intercept course, it moves following my rolls, it's something that shouldn't happen. Actually seems that in RWS bugging the Carets visualization and the calculation subdued to that datas (apparently the SAM patterns too), are considering the antenna position before it gets gyro stabilized to match the MFD visualization. f-16_RWS_carets_scannedarea_and_InterceptCross.trk

Before posting in Bugs section i wanna ask how this instrument logic is supposed to work. I noticed that in RWS, more exactly in SAM mode or DTT, when we have at least one track bugged, the Azimuth and Elevation Carets are following a strange logic when they stop to the contact position to update the tracking informations. If you try it leveled it's all ok and seems normal, the strange logic is noticeable when you start banking, and it's quite evident when you are up side down, i mean 180° of bank. The intercept cue cross, seems following the same logic, i imagine you have to center it to the radar screen to have a computer calculated lead intercept course, well, it seems to be correct only when your wings are leveled, if you go, in the extreme case, upside down, 180° of bank, it's completely reversed. Someone have noticed that, yet? Best regards.

confirmed by experiences of mine and of my squadron, fuel leaks seems has been implemented recently but no vfx associated to it.

Ok, as i see this topic was marked as "cannot reproduce" i feel we need to dig more into this. Actually what i found is that TWS recenter the axis value after every unlock/unbug. This means that this bug can be reproduced without doing something odd or out of normal procedures. What i did in this video was simply entering in free flight, bumping up to reproduce a look-down situation, and bug a target then unbug. What i did after was just move my axis from 0 to 100% some times to show my elevation is not centered anymore and i can't move my antenna up more than a certain angle. Here i attach a track, in which i do the same thing. If it can help i use X-56 Rotary axis for elevation the marked with "G" one, labeled JOY_RZ in "controls". I have edited it with 25 of curvature, but i tested without it, and it happens in the same way, so that's not the cause. EDIT: you can also notice in the video that without moving the antenna, in the exact moment i unlock, the elevation instantly pops down. f-16_elevation_recentered.trk

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.