falconzx

I've noticed that the symbology around the contact is changing when bugging a contact, is it a choice or is just a bug/wip thing? I mean: - sorting number disappearing - altitude changing format At this current state it's not very practical to deconflict errors in sorting; if my wingman bug/commit on the same contact i bugged i can't know because the number on top of it it's not showing. It's showing only if i un-bug that contact. Video and track for better explaining and visualizing. Best regards and thankyou. F-16_sorting_symbology change.trk

Loadout 4xGBU12, Litening. Steps to reproduce: -Set DTOS mode -Designate a point with TMS up (i did it via HMCS) -DMS down for TGP SOI. -TMS right (area track) to ground stabilize -ICP 7(Mark) -TMS UP x2 to create mark. -press 0(M-SEL) to select that mark as active STPT -dobber RTN to exit Mark mode. -NWS to switch to CCRP -TMS down to CZ Here the TGP will CZ to the previous waypoint and not to the active one. Workaround: Make SOI a different sensor (FCR, HSD) change waypoint then CZ should behave correctly again.

Hello, thanks for reviewing but maybe i'm misunderstanding how the antenna gimbals works. F-16s as i know, and tested in DCS is a +-60° in all directions(try STT for example). If this is true the limits should be equal, regardless the roll state of the airplane. If roll influences the gimbals the causes could be two: gimbals are irregular(so there's something wrong in STT), or, there are problems to the gyro stabilization of the antenna. In the track you can see this irregular behaviour, same pitch, same radar settings, different roll states = different results. If it can help i've made a video to better explain what i mean, and what's the behaviour expected versus the sent track behaviour on rolls. In this case i modeled the plane have a +30° pitch and the scan is horizon centered (simulating an ANT elev left to zero) and i've lost 4/5° degree circa over a 60° degree gimbal. In DCS: F-16C values are way more big. So i suggest to check the math behind this, and also check why results are not even during rolls. Thanks. gimbal_and_roll.mp4

Very short and simple track. As you'll see from my inputs in the track, i'm not touching any radar controls while performing rolls at +-30/+-40 degree of pitch. Bank towards the scan only cause the problem when pitch is positive. Bank opposite of the scan only cause the problem when pitch is negative. F-16_A1_SCAN_MOVING_BY_ITSELF_ON_ROLLS.trk

2.9, years passed, the bug is still present. Bank angles towards the turn in a climb move the A1 scan volume from the inside of the turn, towards the center. If you roll/bank outside the turn it stops happening. If you dive the behaviour is inverted: bank angles opposite of the scan volume push the scan azimuth towards the center. Any news?

You can fix it syncronizing the GPS clock manually with your mates, if you do the same procedure you need to do in the 80's with no GPS, you will fix this as well. DED -> DLNK -> Put GPS TIME OFF then sync the time, in the 80's you need to decide who is the NTR, in modern you can put GPS time ON again. We also synced the clock in TIME page accordingly, but i don't think this specific does take any effects. Tested in my squadron and working. With GPS and without it.

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.