Captain Slow

If it is of any help diagnosing it: * Pausing the game will remove the stutters. * Ingame graphics settings has no effect * CPU affinity has no effect or improvement (tried forcing cores 0, 0+2, 0+2+4+6, 0+1, 1+3+5, and a few other combinations without any improvements)

Same issue present in single player. The following is from instant action f-18 amraam mission Conditions for the stuttering to activate: * At least a couple of targets visible on SA page. * If you are in an empty mission by yourself and no targets on SA page => no stutter.

Reproducible: 100% on my computer Date: 2018-03-01 2200Z Sim version: 2.5.4.28090 Open Beta Mission: Any mission where there are targets on the network (donating yourself is enough to trigger the issue), First discovered on Caucasus Blue Flag Server MP server Steps to reproduce: 1. Enter mission 2. Start up F-18 3. Everything works works fine (about 70 fps) on ground... until 4. Turn on DL + Open SA page. 5. Microstutter from hell :(. Unplayable. See attached frame time graph. 6. Exit SA page and microstutter totally disappears (see frame time graph) Problem: I cannot play in missions that my squad mates play in if I turn on SA page with DL. I get massive microstuttering. My friends dont have this issue, so I dont really know what to do Later also had a squad mate measure frame time and he does not have the issue (verified with measurement) tried repairing my DCS installation but it didnt help. The green "Normal Behavior" part of the graph below is when I do not show the SA page. The red part of the graph below is when I show the SA page. Track: MP track too big to attach. Attaching single player track instead Screenshots: Screenshot with frame times attached Screenshot with ingame graphics settings attached (but later discovered graphics settings dont affect the issue) Desired solution: Figure out why I cannot use SA page :( SP/MP: I first discovered this in Multiplayer, but later measured and exactly the same issue is present in single player. System spec: 9900k 32 GB ram @ 3466 MHz 2080Ti dxdiag attached DxDiag.txt microstutter with sa page.trk

Reproducible: 100% Date: 2018-03-01 1800 Z Sim version: 2.5.4.28090 Open Beta Mission: Any with air target (Track recorded in F18 instant action aim120 training mission) Steps to reproduce: 1. Put cursor over target so that info and track appears 2. Turn aircraft and keep tdc on contact 3. Original contact moves, but information does not, so track appears in wrong position on radar screen Problem: Track and contact information appears on wrong position on radar screen if you turn your aircraft with cursor over target Track: attached. Screenshots: attached. Desired solution: Contact and contact info should appear in correct place cursor-over-info-not-following.trk

I have the same problem as of today

I have tested now in today's open beta release and the issue is till present

How will this play out in a multiplayer mission with 2 player controlled F18s and no other dlink donors (i.e. no ewr or awacs). Will the F-18s only see each other as PPLIs and not each other's radar contacts, or will MIDS run in parallel with Link16?

I am wondering if it would be possible to get an API for data export (and possibly also import) to the in-game Link16 datalink network. The API/Data model does not have to be super stable, we can adapt to changes between sim versions. But perhaps a lua callback available server side? Tbh just dumping whatever global state is available into a lua table could be a good start ;). Or if your implementation is message based you could just provide an interface to a readable queue, or array of new messages on the callback, or a separate message callback, or whatever you prefer :P. That way each server admin can allow/disallow whatever they find reasonable. Having such an api would allow us to integrate with ATC/GCI programs etc, and making it server side would allow the community and server admins to turn it on/off as designed, as well as implement whatever authentication methods are deemed necessary, without any risk of cheating debate.

This. And would still be good to know if there was any way in the real plane to center

I was the other player in the 1v1 session(s) and was also able to reproduce this on my side. We have been seeing this issue in our squad for a while. Now is the first time we could reproduce it reliably. Theory: Some radar scan parameters may be uninitialized/initialized with random junk during certain conditions. Changing to the 5 nm scale triggers a unique bar scan pattern (see dcs f18 manual for detailed explanation), forcing a re-initialization of these variables (again, just a theory for why this workaround works)

Re-read your message and I get what you mean now. This implies even the real thing cannot center the scan? Even if your inputs return to zero (for example spring loaded) the in-game elevation will stay at whatever offset it was at when you let go of the axis. This is because the in game axis is relative.

This isn't really any better (been using this method as well). You still have to check your alt and then fiddle around with up/down elevation. I think the most important thing is the fact that no current consumer joystick hardware has the ability to center it, axis or buttons. Absolute axis mapping would solve this (as implemented in the FC aircraft for example, and BMS for that matter as well). Preferably also provide a centering button so that people without axis can play reasonably well. But right now no sliders or fixed range rotators do the trick

This issue affects the looks of HUD and MFD vector/stroke/line graphics when displaying at below 100% brightness. Issue present at: 2019-02-24 1800Z Version: Open Beta 2.5.4.27314 Problem: When lines intersect and where lines change direction (same thing if you understand how this is programmed) colors are blended and added. This creates irritating and distracting artifacts in the displays when running at sub 100% brightness (at 100% brightness it is fully saturated, so more color addition doesn't do anything). Solution: 1. Change blend mode from transparency based -> 'replace' for rendering the vector layer. 2. Render the vector layer of the display to an off screen surface/fbo/whatever it is called in d3d (I dont know what it's called in modern graphics APIs, was a few years since I worked with this stuff) 3. Change back blend mode to transparency based 4. Overlay the vector graphics as a single texture draw Had the same issue when I was programming raster HUDs back in the day/7ish years ago.

Not sure where to post this, but I find it to be quite a problematic situation. Right now it is not possible to in any reliable way center your radar antenna elevation. I'll let you decide if this should be a feature request or not. For me it is an actual problem since the aircraft currently lacks means to center elevation. (The only way right now to get close to it is to set 1B scan and use the elevation angle caret, but this procedure slow and unreliable) Issue present at: 2019-02-24 1740Z Version: Open Beta 2.5.4.27314 Problem 1: You cannot bind a joystick/throttle axis (like a fixed range rotator or slider) to it because the sim treats the antenna elevation input as a relative input - and therefor you cannot center it. (any position of physical axis off center will yield continous elevation change in the sim). Problem 2: Using buttons for up down isn't much better either, because there is no button available for antenna centering. Proposed solution: step 1: Replace the existing elevation axis implementation OR add an additional axis for absolute input control step 2: Add centering button for us that use buttons for elevation control

Exactly

Sorry! I must somehow have removed it. Re-attached now.

Strange. Both modes are still available and work. It's only vacq that takes one extra step to enter. Vacq may be unnecessary but wacq certainly is useful to reacquire targets after being on defensive. Is the intention to remove both entirely in a future patch? I suppose if that is what the real thing does then so be it :(

Reproducible: 100% Date: 2018-02-19 0000Z Sim version: 2.5.4.27314 Open Beta Mission: Any Steps to reproduce: 1. Enter HACQ mode 2. Press Sensor ctrl aft 3. Nothing happens 4. Enter any other ACM mode (such as WACQ) 5. press sensor ctrl aft 6. Now you are in Vertical scan mode Problem: It is not possible to enter vertical scan from HACQ mode, and HACQ mode being the default ACM mode if HMD is on, this causes some frustration Track: Track attached Desired solution: Pressing sensor ctl aft in HACQ mode should take you to Vertical Scan mode SP/MP: Affects both. System spec: Tested on multiple systems with same result. Controllers: Tested on multiple systems with same result. cannot enter vertical scan from hacq.trk

Reproducible: 100% Date: 2018-02-18 1940Z Sim version: 2.5.4.27314 Open Beta Mission: Any Steps to reproduce: 1. Enter ACM:Gun scan mode 2. Press undesignate => radar goes into a mixed bvr/acm mode 3. Press Set 4. Now you cannot get into ACM:Gun scan (the dashed circle on the hud). No amount of reset or any other mechanisms resurrects ACM:Gun scan mode. It no longer is available in the plane :P Problem: It's possible to remove ACM:Gun scan mode from available modes Track: Track attached Desired solution: undesignate while in ACM:Gun scan should not exit the mode into a hybrid acm/bvr mode, or at least SET should not remove ACM:Gun from available modes :). SP/MP: Affects both. System spec: Tested on multiple systems with same result. Controllers: Tested on multiple systems with same result. gun mode removed.trk

Reproducible: 100% Date: 2018-02-18 2300Z Sim version: 2.5.4.27314 Open Beta Mission: Any Steps to reproduce: 1. Set radar to bvr/rws scan 2. angle the radar elevation to the highest or lowest 3. Enter WACQ or Vertical Scan. You will not achieve a lock against any target in your hud. 4. Go back to bvr mode and center antenna elevation 5. Go back to WACQ och Vertical Scan - now you can lock targets again. Problem: BVR antenna elevation affects ACM WACQ and Vertical Scan modes. Track: Track attached showing the issue in Vertical Scan. Doing the same in WACQ has a similar effect. Desired solution: Antenna elevation in BVR modes should be separate from ACM modes SP/MP: Affects both. System spec: Tested on multiple systems with same result. Controllers: Tested on multiple systems with same result. bvr elevation breaks acm modes.trk

I can confirm the behavior is the same regardless if bar scan pattern setting (see attachment), i.e. bar scan centerlines encapsulated scan volume is displayed as altitude coverage. In the attached pdf: bars: the bar scan setting of radar alt coverage kft: total number of 1000s of feet covered at TDC distance (scan centered around horizon) dist nmi: TDC distance in nautical miles zones: number of encapsulated "scan zones" corresponding to bar count pm coverage kft: half of alt coverage kft pm coverage nmi: same as above but in nmi pm coverage degs: corresponding vertical scan angles around horizon (i.e. 5.95 means +- 5.95 degrees coverage around horizon vertically) degs per zone: calculation of covered degrees per zone (to evaluate if bar width or not is taken into account) degs per par: calculation of covered degrees per zone (to evaluate if bar width or not is taken into account) since degs per zone is relatively constant, but degs per bar is not => only bar centerline is taken into account in the current attack radar page implementation Scan angles - Sheet1 (2).pdf

Question: Intended behavior or not? Reproducible: 100% Date: 2018-02-18 1940Z Sim version: 2.5.4.27314 Open Beta Mission: Any Steps to reproduce: 1. Set radar to bvr/rws scan 2. Set 1B scan pattern Problem: Indicated vertical coverage altitudes at TDC distance correspond to bar scan centerline. Track: Screenshot only attached Desired solution: coverage altitudes should take into account width of bar. SP/MP: Affects both. System spec: Tested on multiple systems with same result. Controllers: Tested on multiple systems with same result.

Reproducible: 100% Date: 2018-02-18 1940Z Sim version: 2.5.4.27314 Open Beta Mission: Any Steps to reproduce: 1. Set radar to bvr/rws scan 2. Set display scale to 5 nm to make radar bar scan pattern vertically large 3. Designate empty space 4. * radar scans for STT target with bar scan pattern corresponding to display scale > 5 nm * Problem: radar scans for STT target with bar scan pattern corresponding to display scale > 5 nm Track: attached. Desired solution: Bar scan pattern should remain large when looking for STT target in empty space with 5 nm display scale SP/MP: Affects both. System spec: Tested on multiple systems with same result. Controllers: Tested on multiple systems with same result.

Reproducible: 100% Date: 2018-02-18 1940Z Sim version: 2.5.4.27314 Open Beta Mission: Any with air target (Track recorded in F18 instant action aim120 training mission) Steps to reproduce: 1. Set radar to bvr/rws scan 2. Set display scale to 5 nm to make radar bar scan pattern vertically large 3. Enter AACQ mode and ensure there is a target available at > 5 nm distance 4. * radar auto locks target * 5. * radar switches to longer display scale, i.e. 40 nm * 6. Undesignate target 7. * radar stays at the longer 40 nm display scale * 8. * radar incorrectly stays at bar scan pattern corresponding to 5 nm scale * Problem: * radar incorrectly stays at bar scan pattern corresponding to 5 nm scale * Bonus bug: If reproducing steps with target within 5 nm, then the radar will incorrectly switch bar scan pattern corresponding to > 5 nm scale, while the display scale actually stays at 5 nm Track: attached. Desired solution: Correct bar scan pattern should commence when undesignating STT target SP/MP: Affects both. System spec: Tested on multiple systems with same result. Controllers: Tested on multiple systems with same result. incorrect bar scan pattern.trk

Reproducible: 100% Date: 2018-02-18 1840 Z Sim version: 2.5.4.27314 Open Beta Mission: Any with air target (Track recorded in F18 instant action aim120 training mission) Steps to reproduce: 1. Designate empty space from bvr/rws scan mode 2. Press OSB 6 to change bar scan 3. Undesignate Problem: * Radar still stuck in "looking for target". * MFD osb text reverts to regular scan representation. Track: attached. Desired solution: Either remove bar scan setting while radar is STT or looking for STT, or make sure radar resets properly SP/MP: Affects both. System spec: Tested on multiple systems with same result. Controllers: Tested on multiple systems with same result. stuck in designated mode.trk