falconzx

We tested both F-18C and F-16C. In the past (like 1 year ago) the F-18 radar presented this issue, now it seems to be solved, in lookup situation, no clutter occurs, so the Clutter filter is automatically removed. In this patch the F-16C Radar seem to have the filter always ON, regardless the presence or not of clutter. I'm just bringing this up, i don't know how it should be or if it's just WIP, so i ask: which is the correct behaviour?

If you offset SPI from cursor zero position, that offset is applied to every STPT you eventually select as moving SPI of the same amount.

I don't know if happens to different modules but those could be steps to reproduce: We noticed that if you sit in a F-16C and change to the desired frequency before the other player joins the server, when he joins the server and put that frequency aswell you hear him but he doesn't hear you. It's likely his plane doesn't know you are on that freq because he wasn't there when you changed it. Workaround that fix the problem is change to a different frequency then put again the desired frequency back and your new joined friends will hear you. Hope that helps. Thanks.

That plane is you. It's your position sent by the awacs on your HSD screen. Probably a bug.

Question for ED Devs: Is the new spotting simulating an increase/reduction of the dot visualized when the LOD is the lowest ( for example HIGH FOV but close range) based on the actual target visible surface?

My feedback is: 3840x2160 No DLSS, MSAA4x= Perfect, smooth transition from imperceptible dot to a recognizable one from 30 to 10 nm 3840x2160 No DLSS, TAA or DLAA= tends to be too small 3840x2160 DLSS Quality, Balanced, Performance= slightly too small 3840x2160 DLSS Ultra Performance= blurry, and probably too big at medium/close range. 1920x1080 No DLSS, MSAA4x= Too big in general and dramatically increasing FOV 1920x1080 No DLSS, TAA and DLAA= maybe the size here is correct but lacks of smooth transition Tested on a 32 inch 4k display.

Sure it continues to happen but i'm just bored to report it again and again, and this thing actually made me get away from this sim a bit, so now it happens less just because i fly less. I live in Italy and my provider is TIM, it never happened before, it started since three/two patches. I'm connected to my router by wi-fi (usually 2.4, now trying 5ghz but it doesn't seem a factor). I monitored the connection while flying with constant pings to my router and to an external server (like google.com) just to see if i have some packet loss or slows. But nothing relevant, same on the router logs. I did changed my DNS just to see if something is changing. The configuration i'm describing is unchanged by 3-4 years and it never happened before something like that. Router: TP-link MR600 connected on LTE bands 3,7 aggregated. I connect to the router via: PCI-E1x Wifi adapter with Intel AX-210 chip EDIT: in the latest patch it happened more frequently on the server join, i mean i can observe the status described when i have just joined the server(like it happened while loading the mission), so i realize it very soon as i can't pick any slot and i need to reconnect the server.

Suggestion: the symbols seem to have too little radial movements inside their circles, this will not help to solve this issue. I think this effect can be intensified a bit allowing characters "touch" more the middle ring. This will help the general readability keeping still clear if a character is in the outer or inner circle, but making space for possible TGT sep in a lot of scenarios. Another helpful thing could be reducing a little bit the character size. Kindly regards.

I think symbology at the current openbeta is hardly broken, hope all this things are w.i.p. , we even lost all the link16->fcr tracks correlating symbols.

TMS up short to designate that point BEFORE pressing ICP7(mark) and you will have FCR by default mark input source.

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.