falconzx

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?

I am completely agree about parallax errors, they should be taken in consideration especially in ground align cases. Anyway i am used to do in-flight MAV aligns so the parallax at 7-9nm is neglegible, but i noticed a little vertical inaccuracy when i try to hit something with the Force Correlate mode (in F-16 WPN page is called AREA on H/K versions). In my tests the groundpoint locked by my mavs was a little long. I also noticed a random little slide of the crossair in the exact moment of MAV lock (TMS up). I'm not at home this week so i can't post my tracks, but i suggest people to try testing Force Correlate mode and try to be accurate and consistent with the point you targeted on Litening POD.

During the previous patch i opened a bug report about the inconsistency of coordinates between INS(i guess) and TGP coord visualization. That topic has been merged with CZ problems, but i don't think this inconsistency has actually addressed as issue. So, before opening a new bug report, i just wanna ask: which is the correct behaviour? When i move TGP on the ground i see some coordinates, which is the system that is providing them? if it's the Nav system, why if i put a mark the coordinates appearing on DED are different from coordinates i see on TGP? And why if i make it steerpoint and i CZ i will never get again that point? My guesses are that the nav system (INS+GPS) is constantly correcting, every frame. So when i move the TGP my alignment is different from the moment i create the mark. Is this the real airframe behaviour?

Put TGP, initialize it and use a bit. If you put it in POINT (TMS up), default Mark mode will be TGP (that's awesome). But, if you put it in AREA, then the default mark is HUD, but it's stuck, you can't see the point inside the FPM and it doesn't react to TMSup or down(to reset). Even if i exit MARK mode and i put HUD SOI, it's stuck again, the only workaround is cycle with SEQ all the Mark input modes, until i land again on HUD, there it will work again. Short track included. F-16_TGP mark_hud_stuck.trk

For me and my squadron this feature implementation is one of the most desired. I hope ED Team would make progress on this soon.