Nealius

Most of it is a texture size issue. I reduced all external textures from 2k to 4k and the cockpit texture loading time/stutters were markedly decreased, despite not touching the internal textures other than the "external" cargo hold texture.

Around the 8-minute mark on the second video that Cat107 posted (Flight Characteristics) does an excellent job at clearly and concretely defining when you need to start watching that ball and using the rudder to coordinate your roll: "...but, once you reach 15 units AoA, you need to start applying rudder in order to coordinate your roll." Also at 10:09: "...up to 15 units, you can fly without using your rudders" followed by reinforcing the importance of rudders above 15 units. Rudder usage is a lot easier than online discussions and airframe mythos make it out to be once clearly defined like this. The challenge from my perspective is location of the Phantom's AoA and slip indicators, and translating that heads-down information into heads-up muscle memory, which just takes time and practice.

DLSS is on, but SSS is off. Again, this texture loading issue only happens with Tomcats, and not with any other game objects. Long after the carrier, world, and other object textures load, the Tomcat's textures sit like this for nearly a minute on mission start. At some point during the mission, they get unloaded, so then when I return to the deck they're reloaded and causing a stutter right as I cross the ramp.

Good to know it's accurate. I would still like to know which public document was used for our avionics so I have a more reliable manual source, given the incomplete nature of the DCS documentation and the invalidity of the old CJ -34 (the only -34 I can find) on hand.

Bodo ILS is offset and acts a bit funny compared to ILS on other airbases. I'd troubleshoot on a normal airbase/map first.

Which public document for our particular Viper indicates this? I'd like to research why it departs from common logic in other airframes using the same pod in having an auto-off for the laser, which has specific firing time and cooldown time limits to prevent damaging the pod; also why the functionality was removed in the CJ>CM upgrade. Since it is correct, I request that the manual be updated to include laser switch off in the auto-lase GBU implementation procedure, as it does not accurately reflect actual required procedure in DCS.

I noticed this yesterday as well. 2x Mk83 with 75ft spacing, first bomb impacted the target instead of the two bombs bracketing the targets as they should.

Using Quest 2 + LINK cable, currently locked 72fps (refresh rate) up high in most missions, I still get a 1-2 second stutter every 20-30 minutes. Sometimes it's minor and only shows up in the headset. Sometimes it's major and shows up both in the headset and in DCS. It is always accompanied by the sound of my PC fans spooling up and then spooling back down once the stutter stops; as if there's a sudden PC load for 1-2 seconds that then disappears. It only happens in VR. Running a track of the same missions for screenshots and videos, this never happens. It has happened on two different GPUs. It has happened on three different LINK cables. It happens on 5 USB ports, including a powered USB hub. It happens on multiple headset settings (resolution, refresh rate). It happens on multiple DCS graphics settings, from low to medium. It happens with and without core priority/affinity tweaks. It happens with and without NVIDIA CP tweaks. It happens with and without clearing fxo/metashaders. Oculus debug tool settings are default. At this point I don't know where to look or how to fix. Current pc specs are: i5-9600k at 4.8Ghz RTX 4070Ti Super 16GB 48GB DDR4 SSD with 32GB allocated to pagefile

Real pilots feel the yaw happening in the seat before they see it happen visually. All we have is a visual cue. Once the brain realizes there's movement, the movement is already established. That's why they fight it less than we do. For us it takes repetitions to predict what the aircaft will do and proactively counter things before they happen. I just tested slamming throttle IDLE to MAX in the Spit. She did a 90-degree roll to the left (would have done more if I didn't stop it) with the slip indicator pegged full right. So I don't know what this lack of torque claim is about. Maybe it's not strong enough, but it certainly is there and something that needs to be dealt with by the player.

No. These are instantaneous movements caused by throttle and/or RPM changes. Speed changes have longer dwell time, and in formation flying we're talking speed changes of +/- 1mph or less. They're extremely noticeable in the Spit. Less so in something heavier like the Mustang or Jug.

I believe this one may be backwards. Testing today, TMS LEFT cycles threat tables (implemented), but TMS RIGHT cycles selected threat (missing).

That's true in DCS, though. Are you sure you don't have game mode or something turned on? Every power change I make in the warbirds requires rudder and aileron adjustment to deal with the change in torque. Formation flying in particular.

Evidence PM'ed, though a chat would SMEs would be great as well, since evidence alone provided by users often gets dismissed for arbitrary reasons.

The Spit has never given me too much trouble in terms of torque, but the K4 and A8 have gotten me into trouble on numerous occasions with a stall/torque-roll to the left on takeoff.

I'm surprised Isoko hasn't started on a GSDF livery yet. I suppose most are waiting for the official template.

The M60 struck me an odd choice as this isn't a Vietnam-era bird. Did the US Army use the M60 at all post-2000? Wikipedia says the M60D has been replaced by the 240H in US service.

The torque is certainly there, it's particularly noticeable on lighter modules like the Spit and K4. Is it not modeled strongly enough?

Is it meant to simplify that action? Currently you could (or should, haven't tried recently) achieve the same by telling the group to expend x-rounds then switch to next waypoint.

Pop-in affects the targeting pods as well, making things a bit too easy. If you're 30nm away or so, you can find vehicles and infantry easily because the trees and buildings aren't rendered until you get closer.

In my experience, part of the performance problem is from the absurdly huge 4k textures on some modules eating up more VRAM than they should. Reducing them to 2k via paint.net and repacking them into DCS has solved some of my issues, but not all of them.

A couple updates ago we got four "Light Rain" presets which are nice, with better visibility and small pockets of rain, but the cloud coverage is still too dense for sunshowers and squalls.

Don't know what to say other than during the winter period when I was exclusively flying the Viper, I messed with XMIT 1 and 2 in MAN mode to see what they did and they came on just as XMIT 3 did. But feel free to continue gaslighting me into thinking I'm imagining that experience.

I haven't found the Spit to be bouncy at all in 3-pointers or 2-pointers. The only time I've gotten bounces has typically been 3-pointers where I misjudged my flare.

False. Back in February XMIT 1 and 2 worked in MAN mode. Now they do not. They only work in SEMI and AUTO. That's what changed.

I understand CASE III starts "30 minutes before sunset," but either the carrier doesn't seem to follow this, or the Navy definition of sunset is different than the civil definition. E.g. sunset for Marianas on 25AUG2024 is 18:37, so I would expect CASE III to start at 18:07. However it does not. When flying, I got CASE I instructions when calling in at 18:15. Trapped at 18:20 and had NC grade because it apparently switched to CASE III while I was in the pattern. Testing without aircraft in the pattern and time acceleration, the carrier lights--which I assume in DCS signals CASE III--came on at 18:32. I couldn't find anything about a nautical sunset time, only a nautical twilight, which doesn't seem to apply here. When does the module make the switch to CASE III, and how do I figure out what time this occurs via the mission editor when it doesn't seem to follow the 30 minutes prior rule, nor appears to be consistent when testing same date on the same map. EDIT: Doesn't seem to help that official documentation disagrees on CASE III timing as well. CNATRA says "between 30 minutes prior to sunset to 30 minutes after sunset." DCS-focused comunity documentation written by former Charlie drivers and former/current Rhino drivers agrees with CNATRA. CVNATOPS says "one-half hour after sunset and one-half hour before sunrise." The latter sounds odd for CASE I considering the low light conditions.