Gordy

I think it was a rare edge case, not something that happens frequently. It might be easiest to reproduce with an SA-11 site with a smaller number of TELs - have a bandit get engaged but not empty the launcher, then stay close enough to be tracked but not fired upon, stay there until the reload starts, and then ingress. So this specific case may not justify a lot of time and effort to reproduce ... but if reloads in general could get interrupted and release a vehicle that has a valid target to fire on, that would solve a lot of gripes about SAMs with ammo ignoring targets.

I have a track file, but it seems to fail to load for me, with: ERROR Dispatcher (Main): Unexpected track event index track/net : idx = -31618807 Posting anyway, in case that's trivial to workaround for someone more knowledgeable than me. 20240815_reloading_SA11_not_engaging_a10.trk

I have generally accepted that units will enter a reload cycle and just be out of action until they are fully reloaded... but today I observed an entire SA-11 battery ignoring an in-range target, because it seems to have assigned that target to one of its units, which started reloading. That unit tracked but did not fire upon the target, and can be observed loading missiles. Meanwhile the battery had other fully-loaded launchers available, but they didn't track or fire on the target. The target continued to approach and received fire from an SA-19 and AAA as it got closer and continued to be tracked but not fired upon by the SA-11 group. It would be ideal if partially-loaded individual units would immediately stop reloading and engage in-range hostiles. SA-15 Tors with a reload source were famously useless after one engagement because reloads took so long. If a unit is part of a group, that group should be smart enough to (1) reassign current targets to launchers that are not busy reloading, (2) stop reloading and engage with ammo they already have if no launchers are fully loaded, and (3) prefer to empty a partially-loaded launcher, to maximize available launchers when reloading is necessary. Observed on "The Coop - Afghanistan 90s", running v2.9.7.59074

We are seeing similar behavior on The Coop multiplayer servers; we have incorporated a way for player to give corrections to the artillery units, but it's a pain in the neck. Corrections on the order of 500m - 1000m are common, though we see rounds falling long more often than short. When I test it in simple single-player missions in the mission editor, I can't reproduce it; rounds fall around the designated target in an appropriate amount of spread. But in the multiplayer missions, we always miss, it seems worse when the target is farther away, but isn't a simple enough value (range * X) that we can correct for. If the artillery unit is close and automatically firing directly on units it sees, this doesn't occur; in this case the AI brackets the target effectively. It affects mortars, self-propelled howitzers (Msta-S and Firtina), MLRS (M270, Grad, Uragan, Smerch)... every artillery unit I've tried that is performing indirect fire. Once we get the correction dialed in, fire is accurate... but like I said it's not consistent. It seems to vary with distance from the shooter, and possibly with variation in elevation between the shooter and the target.

If that text can be made to respect the "Geo names" map option, that should be cover it, but I won't complain if they add a separate toggle or remove it entirely.

Thanks, Don, for all your contributions to making everyone's experience here better. May you inspire others to do the same.

@plott1964Try the zoom in/zoom out controls (generally Rshift-numpad* and Rshift-numpad/), though those seem to be aircraft specific, so may vary. I replay VR tracks in 2d/pancake all the time, it's fine. Just don't change views, if you want to play back the head movements. Or if you want, you can take control of head movements yourself and look around with TrackIR or whatever during the replay - I'll do this sometimes if I'm playing back to record the flight, to make sure the right things are visible and the movement is smooth. The VR head movements can be too jerky.

@obious - I noticed a definite performance improvement in DCS when I increased the speed of my RAM, both on an intel 12900-KS and a 13900KS system, but I can't say for certain that it will improve your microstuttering. I'm running 32 GB DDR5 @ 6600 MHz, but if your bottleneck is elsewhere (cpu? gpu?), the faster memory may not help you. The easiest way to check is if you can tune your memory performance up and down in the bios, but that only helps you if you already have the fast memory. I think I saw a 20% boost in frames when I tuned my memory properly. I think I saw a 25% boost in frames when I moved from a 12900ks to a 13900k (same motherboard!) Try running in steamvr with fpsview and see where your bottleneck seems to be. If you seem to be cpu-bound, but you don't have cores that are 100% utilized, your memory might be holding you back. Your issue of stutters/fps drops as you pan past high detail scenery sounds similar to what I was experiencing.

Known and acknowledged ED bug, linking existing ED bug report:

echoing @phtate0830 - I can consistently reproduce this in the mi-24 border campaign (missions 2 and 3 at least), and it only affects me when running Multi-threaded and in VR in this campaign. It does not affect me when running multithreaded VR in multiplayer, instant action, etc.

Tested this in different modes, and this only affects Multithreaded/VR sessions for me: English cockpit is not honored mi-24 moving map in cockpit is broken mi-24 mirrors are broken But since these all work fine in Multithreaded/2D, Single-threaded/2D and Single-threaded/VR, it must be an ED bug, and not a problem with the mission or campaign. Weird that I don't have this issue when flying the mi-24 in other single or multiplayer environments, though.

This workaround (ask ground crew to change skins) didn't work for me - no other skins are available? I am flying in VR/multithreaded, but I fly the Mi-24 in VR/multithreaded all the time, so it's not just that.

I have some notes from the Radar mission (#2), when playing in English - There's a typo - one of the instructions to change the radio says to tune the R-862 to a certain channel, should be the R-863. I spent a long time looking for a R-862 dial. There's a message, "start descent" after I land at the hospital, which is either late, or mistranslated. The bearing given back to the base for RTB is incorrect - it seems to be the bearing to the hospital from the radar (head 163, 960 Khz). That is confusing, with respect to where you are intended to land. Which leads to... There is no information in the briefing that warns you that you will instant-fail the mission if you cross the border on the south. ...so if the player follows the given heading to look for a different base for landing, they fail the mission. I also have the Cyrillic cockpit issue, but will try the workaround from the other thread. The labels on the F10 map are also in Cyrillic when playing in English. Happy to assist with English translations if you like

@dureiken : https://github.com/mbucchia/Varjo-Foveated https://github.com/mbucchia/Varjo-Foveated/wiki

@dburneI just rolled back to Varjo Foveated from QVFR - eye tracking was inconsistent, leading to what looked like only getting the peripheral resolution half the time, though it could just be me. Everything looks sharper to me in Varjo Foveated... which is what had me digging into the eye tracking in the first place. Performance seems comparable, but that's hard to judge when I'm not sure I was getting my focus area properly. https://discord.com/channels/933220354401398785/947051902913376318/1141605552418455592 YMMV