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.