falconzx

Here a track to show the radar elevation position AXIS resets on the bugged contact in SAM mode. (I use an absolute axis rotary like in the RL Hotas) I've put a plane HIGH and another at my altitude circa, so after bumping up elevation to find the first one, i should see the second one just diving my antenna until i feel the center detent, this is not happening, so i dive my axis more deep down until i find the co-altitude plane. In the second track instead i managed to reproduce in a very similar situation the antenna not recentering on bugged contact, and working correctly allowing me to scan at the desidered elevation commanded by my rotary knob. I don't know how it happened but it happened twice in this track, i think you can easily debug and discover how i magically fixed the antenna . At the same time in this track i've put A1 to show how the antenna go back on the bugged contact at increased frequency, so fast that it's quite an inefficent scan(i think the narrower should be likely the only one capable to complete a scan in SAM). Seems the frequency of "going back to check the track" is not related to a time factor but to how much of the azimuth scan set has been sweeped, this leads frequency of "go back and check" to be coupled to the azimuth (A1/A3/A6) setting. Note: these strange behaviours (all of them) wasn't there on the first implementations of RWS/SAM/DTT. It worked very well in the past, and the intervals seemed to be more consistent and DTT was more efficient. Something in the last 6 months happened and messed this up. F-16_absolute axis_SAM_recenters.trk F-16_absolute axis_SAM_not_recenters.trk

It happened again two times in around 4 hours of multiplayer on the latest patch.

I bought a new network card trying to see if something changes. desync just happened again.

Why are you using FCR ON/OFF switch during a mission? To turn off your radar you have the RF switch on the upper left of the front panel, that's the switch you should use to turn on or off your radar emissions in combat.

64GB 3600mhz c16 T1 As i said it started happening recently, i never had this problem before.

It happened again today. Another server, in 1 hour of flying. One teammate with me, he told me he keep seeing me moving in F10 map and doing what i was doing, launching weapons, but my bombs didn't destroy any target in my pc, but he saw them destroyed. Again he was telling me a patriot launching on him, and i was watching that patriot, in my pc the patriot didn't launch, and no spikes on my RWR. Another symptom: he could read me in the chat, but i couldn't read him. My chat was dead, no events. And again before leaving the server i was trying as usual to go back to spectator or change slot and i was stuck on my slot. Only thing to do was to disconnect. I checked my router log and it's fine, no relevant events or disconnections. I checked dcs log and it's fine, i kept to receive ping messages until i disconnected.

It happened again today, on a completely different server. Here the description of the issue: I'm still in the server, i see other client actions, positions, the chat is frozen to the last message when the desyinc occurred so i don't see any new messages (log ins, log outs, events, clients messages). My weapons doesn't destroy any target, like all units are invulnerable, and i cannot change slot or return to spectator. In the past i was used to get a connection timeout, now you can stay in this limbo forever if you do not realize it happened.

Just happened two times to me, two different servers, two times in 3 hours, it's definitely an issue. Never happened to me before with previous patches. Something has changed. I've never installed mods, i just did a repair, cleaned temp folders. Let's see if it happens again.

Yea F16 experience now is really distorted in all operations, when i got painted suddenly by a search radar if an airborne, in a no AWACS situation or no intel situation if a SAM, i just can't know if i'm going to die in seconds or is just a 100nm thing which popped on. The decisionality of the leader on new threats can only be conservative to not risk the packet safety. It's all to be changed, even our wing procedures. I give ED a tip, an idea, for this matter and for all kind of. Change the name of the instrument. Call it An/alr-56ED Put "ED" suffix to the instruments you need to model with some flexibility in the sources, for sure unclassified but just to pick all what is public viewable and use a bit of common sense in modeling it. Then you can specify with a note on the bottom of the selling pages that ED instruments are fictional and just inspired to real versions. In this way you will be relaxed, no legal problems, the community will be relaxed, no modules getting distorted from real ones, happy ending. And also you make a good step for the future problematic implementations, speeding up the work and sleeping better. Think about it.

Lethality is a mix of things. Something out of range is not lethal, regardless of lock or not. USAF and F16 operators knows this because you know the range of the weapons a certain threat uses. The same we can say on this sim. An/Alr56m is programmable by crew operators, so it's safe to say you can also adjust the span of intensities associated to the range positions, a specific type of threat, have on the display. How do i know? It's mentioned in the public brochure on Baesystems official site. (I don't think i have to pm that) Anyway i also found a document which confirm an/alr56m is unclassified. So i don't think ED have to be so strict on some evidence interpretation. But i don't know, by the way i appreciated the Nineline explanation, many people maybe doesn't know the weight of some matters. Anyway, responding to Nineline, in this specific case i think there is nothing complicated, what the community here is asking is not a change with something new, maybe classified or maybe you cannot keep in this simulator or because some player asked without a precise evidence. The community is just asking to roll back on something you have sell for years and you still have in the stable release, because we're all convinced that the previous implementation was more correct from all the evidences we can find. And probably this convintion is the same ED had for YEARS since F-15 has been modeled, and then the F-16C, someone found wags video, someone ED manuals, you still have F-15C another USAF rwr in the sim which act in that way(so if it's a legal problem it would persist). I don't want to go offtopic but think about hotter topics like ECM or IFF. We all know that we are not getting those systems simulated high fidelity because of classified info and so on, but the sim has a simplified version of them. So given it's an instrument hard to see in function clearly, is being strict on interpretation of "we dont know which manual" the best approach? No. And this was your answer, you confirmed this with all the patches before this, for years. In fact we had for years an instrument which nobody complained about(specifically to this topic) because in-line with many, you can call "vague", info and evidence you can freely find.

I noticed that, on spikes there are differences, but they are static, the position of a spiking symbol is related to the type of radar, and not related to range. In fact i said because maybe the the signal intensity visualization has been removed from scanning radar/spiking radars by mistake following the intent to move symbols also by radar state (for example scaling the convergence to center factor by a multiplier which activates only on spiking symbols.)

@NineLine I know, it's a miracle i've found something, i will spend more days searching, but i don't think i will find a 4k resolution video showing that instrument functioning in a combat/exercise arena. And i don't even get paid for that lol So on some thing we need to use the flexible approach. What is the most probable behaviour of that instrument? Let's use some of common sense, all documents, even not exacltly specific (the one on ALE-43, mentions exactly the AN/ALR-56m, so it is specific) speak about ranging, so we can't have an implementation that ignore completely this evidence. All the "vague" evidences says we were closer before the latest patch. And i think a lot of users here think the same. In latest patch the ranging has been removed, this mean that your specific, public, an/alr56m manual says explicitly "the range of scanning radars is not visualized". That's a pragmatic and simple way of see this. And, after all my research is highly unprobable that your manual say that, it would say at least something vague that has been interpreted in a way that leaded the team to remove any type of visualization of the "scanning radar ranging", possibly even unintentionally. But now this is a problem, because, even without a precise evidence, it's obvious from a lot of sources that this is not accurate.

I sent to ED team PM with a lot of evidences, videos (both ALR-69, the one which was replaced, and ALR-56M) and public documents (a NATO unclassified one, and a publication) all speaking about AN/ALR-56m, all mentioning about signal intensity or "range". All videos shows more than one "nails" and very probably not spikes in the center or intermediate positions of the screen. They just answered those evidences are too vague to change the rwr from what is now, and they are just happy to leave it like that. I don't know what to do anymore guys. It's like they modeled a radar which you can find anywhere on web, that can measure range, azimuth, closure speed and altitude, and they just forget to represent one of the parameters, the closure speed for example. I have no words. Even the ALR-69 on blocks.30 could do that, even the ALR-69!

Talking about this a little deeply for example, now if a 80's F-15 locks me from 60nm or 5nm there is no difference in visualization, it will end to the center in both cases giving me a wrong lethality information. The same happens in a modern case, in which the F-15 is just nailing me in TWS, from 60nm or 5nm, the visualization is the same, he will stay in both cases on the outward ring, and again i have a lethality level not correctly represented, at 5nm if he launches i probably die, at 60nm he's out of range. Given what just said, the current "fix" does not display targets on RWR according to their lethality level. The current fix display targets on RWR according their radar state. Which is not the lethality level. To represent a real lethality level you have to consider ALSO the radar signal intensity. Is something that the sensor can take in account for sure, even the old Mig-29 berioza does it. what are the reference data for the ALR-56M about this point? If they are for example, just a manual lemma saying exactly this "display of targets on RWR according to their lethality level.", it's clearly something that can be interpreted in a lot of ways. Can we expect a further look on this?

This and other obvious thoughts are the reason why i don't really like Bignewy's answer this time. I'm always, and i will always be the guy of: "If it's like the real thing, i'm happy", but: what's obvious for me is that we are talking about an advanced/not so old defensive system that someone have to sell and someone have to buy to try to save pilot's lives. The pilot safety relies on this system, and i can't simply believe it works so bad. If it's truly this, someone, and i mean in the real world, would have updated this thing to make it work better. I don't have public evidences to say that it's not like this, but i have common sense, and it says: "nope". ED have public evidences it works like that? It's ok, so why the version before this patch was mantained, updated, implemented so accurately, but so different from this? Maybe the evidences they had before this patch weren't so accurate? Explaining this better would help us to understand. At this point why should i have to believe that new evidences are more reliable now? The only thing i'm sure of is that the risk level of my flight is plummeted, and because of an instrument that should be built to reduce my risks only.

let's feedback the latest one. -Signal intensity interpolation, which was the most useful thing, is lost. -Major threat is so close to the center that you can't determine a precise relative bearing (so notching become hard) -Often the missile indication merge on top of the priority threat locking you, so you can't read anything, it's all piled up into the center. I hope there's data supporting these PRECISE changes because it is very inefficient compared to the previous update.

yes Brightness and contrast setting are associated to the pages and to the master modes. So you can configure at best your screen for a night mission (ex. having very dim pages in A/G when you use NVG and bright pages in NAV when you turn off your goggle)

Nope, if it's more correct like this i will love it. :) Thank you.

What about the decreased precision to the green circles with the latest big patch? In Furballs is unusable. Is intended to be like that or is it a bug?

happened during tests trying to reproduce the bug, so before the bug occurs i turned on and off RWR and changed settings several times. Then it became blank except for A/A threats. track attacched. RWR stopped working on SAMS.trk

It's correct and it's supposed to work as it is. The fact that's being not considered is the RL axis. That's why I use an absolute axis like in the RL F-16. If you have a rotary under your fingers you feel the physical position of it, you feel the detents, so on the F-16 you dont need any hint or symbology to know where the antenna is commanded to look, i understand SAM stage of RWS can be tricky with buttons, because you have to look what the antenna is doing after you commanded the change and not while you are changing it.

why looking at 2.5 table when there are newer tables? go to this link. https://github.com/Quaggles/dcs-charts/tree/master/Aircraft RCS and IR Values

I just replayed your track and I took a couple of screenshot from it to show what i mean Here is when you just created the mark: TGP shows 4150521 - 4147877 DED shows 4150527 - 4147882 My question was: even if little, why this difference? which is the correct one? From where TGP take the datas if the DED shows another number? It's not a huge difference but is anyway more than .001 Here is after you recalled the steerpoint, so it's like asking our TGP: hey go on the coordinate stored, so i'm expecting it should be the second one, the one is showing on DED. And this is not happening, the TGP shows a new fresh coordinate.(in this case moved by the first one by .001 but this difference it's not constant if you do more tests) TGP shows 4150520 4147876 DED shows 4150527 - 4147882 (the same as before) Anyway the point you recalled is not anymore on the vehicle, but is on top of it. So this way of marking point is definitely unsuitable for precision bombing. I'm not saying this is wrong, i'm just asking how it works, and if this is how it works in real Litening and Mark function.

I think they just forgot to add the word: - possible- before "radar scan volume" . So the equivalent of that is the 60+- elev and 60+- azimuth, so the MFD display. In RL the only limitation here should be the range. The fact it's not correlated with the radar, the radar can also be turned off, It make sense the IFF continues to work regardless to radar state and settings.

Yes that was true in the past. Now with the latest patch you don't have accuracy increases if you are aiming a point in the ground! Lasing allow you to update coordinates and elevation only if you are aiming to a building or on top of a vehicle. It's like TGP without laser "knows" the exact elevation of every point of the land mesh of the scenery without considering 3D object, but if you lase you can take in consideration the 3D object bounding boxes. So what i noticed is: TGP coordinates display are the true coordinates of that land point, it's perfect, what is not perfect is our INS, so when you make a markpoint, the coordinates passed on DED are completely off! So if you want to save a precise coordinate of a point in a RECON activity, it's impossible through markpoints. You can only write down on paper what you read on tgp. That's why i'm asking, what is supposed to be the origin of coordinates displayed by TGP? How can they be so perfect, and how the plane knows the exact point if the INS is so much inaccurate and instable?