Banshee 7, 2 ship out of Yechon intercepted by Hawkeye 7-1 from Kunsan for a quick human ATC practice @ Yechon. Thanks Osprey & Seal of the 101st VFS Desperados

I think I took the wrong offramp…

<p><img class=“ql-image” src=“https://i.imgur.com/3M2cEeU.png” /><img class=“ql-image” src=“https://i.imgur.com/tqXncuS.png” /><br /></p>

https://www.mediafire.com/folder/llkq6rj9f4w8u/Documents

Since 4.35 was released, Maverick missile infrared seekers have a difficult time tracking when even the slightest wisp of fog or cloud obscures the target. This usually prevents a target handoff from the TGP. Consequently, one of Training 14’s original goals – acquiring and attacking two antiaircraft units with Mavericks in a single low level pass - is no longer feasible in it’s original configuration. In this “spinoff” of training 14, I’ve shifted focus to learning how to judge when conditions favor an attack, what to do in the mean time, and avoiding target fixation which can put pilots within range of enemy fire. I wanted to make a more strategy-oriented mission than the original, and I hope I’ve provided thorough guidance on how to accomplish the goals.

The targets are now definitely mobile but can halt their movement, necessitating the use of the FCR in both GMT GM mode. Countermeasures should be used including a mixed chaff/ flare program. The SA-10 nearby now has actual launchers, so it can’t be ignored anymore. This training also includes a likely encounter with enemy air patrols too risky to engage in a ground-attack configured F-16 – but help isn’t far off. Fuel quantity is still an issue, but there is enough for the mission if used efficiently, and refueling options are added for egress.

This mission isn’t meant to replace #14, as there is no bridge attack or TFR used here, but is meant to train effective use of the AGM-65D & G against dispersed, moving vehicles in poor conditions.

Hope it’s fun and helpful to maverick users.

For those who don’t know, unzip the TE files to your BMS\data\campaign folder and the training should show up along with the other saved TEs in the 2D menu.

I like those inky clouds

@Reaperdog1

Loving those textures!

@CheckPoint Yes thanks, I deleted everything in my user CFG file and it’s fixed.

@airtex2019
@Frederf
@CheckPoint

it seems like it was probably one of the lines in my user file - maybe:
set g_nButtonsPerDevice 128// SETUP OVERRIDE
set g_nHotasPinkyShiftMagnitude 768// SETUP OVERRIDE

no idea when or how this changed! but whatever.

@CheckPoint
I always use the alt launcher
heres my settings:
from config:
set g_nHotasPinkyShiftMagnitude 256 // Enable DirectX Shifting and specify button offset
set g_nHotasPinkyShiftMagnitude 640 // SETUP OVERRIDE

and from user:
set g_nButtonsPerDevice 128// SETUP OVERRIDE
set g_nHotasPinkyShiftMagnitude 768// SETUP OVERRIDE

and the key file:
SimPinkySwitch -1 0 0x2F 0 0 0 1 “STICK: PINKY SWITCH”
SimHotasPinkyShift -1 0 0XFFFFFFFF 0 0 0 1 “STICK: PINKY SWITCH (DX SHIFT)”

@airtex2019
Will check that. I’ve had a number of weird problems recently and haven’t been flying for a long time, but anytime I try and get in a quick practice I have a new problem.
I think the sim is against me because it knows I’ve been unfaithful…

I’ve had crashes happen on ENTERING SETUP (not when changing rez) a couple times in the last few years and I had to backup all my config files and reinstall BMS, then replace my important files. after that I was able to enter setup no prob

I’m not sure what happened, but now using this button - regardless of which DX button on my hotas it’s assigned to - breaks all other hotas buttons. Axes still work tho. I’ve tried deleting my setup.v.100 files and reassigning dx shift with only one other button assigned to test the shift layer, and it still breaks!

**breaks meaning all other non-shifted buttons stop working until restarting BMS. Then as soon as DX shift is used it happens again.
@airtex2019

@danster I think so

• what really sucks is that there are such a range of conditions you might be flying in and it’s not rare to be at the most hardware-intensive end of the range. If it’s early in a campaign with lots of units, stormy weather, flying near Seoul (looking at Seoul) and following another aircraft through the clouds it’s a pretty bad experience - in general settings have to be very low so you can make at least continue the mission here, and you get all the ghosting wile in ASW so following a maneuvering aircraft is weird as it flickers a lot. Since settings are low, you don’t get to use much antialiasing or enjoy higher quality settings in the much more common less hardware-intensive scenarios you’ll be in during the campaign.

I’m curious how much the Quest Link cable contributes to this - I don’t really know how to interpret everything I see in the oculus link detail option of the debug performance HUD tool… I need to search out someone local who has a G2 or some other headset I can try out.

The Kuject charger is perfect - maintains/ builds a charge in my quest 2 as advertised, and I get the same USB bandwidth as the USB-C on the back of my motherboard. Even got 0.1 Gbps faster in this test. And the connection isn’t flimsy at the motherboard compared to the USB-C.
The performance HUD in the oculus debug tool shows no difference in Link connection speeds between the Kuject and the regular Oculus Link cable.

@Rainmaker I tried this very same PCIE card and had horrible problems - audio while in VR was in and out, there was some stutter. Bandwidth was reduced by 1Ghz compared to the USB-C link on my motherboard. But true, this card DID provide a charge. Now I just need to return it and by a card that has more bandwidth I suppose.

@obsidianuk
I’ve adjusted things a lot more now after more testing on DAY 1 in a campaign and learning a bit more about VR. I’m going for:
-Acceptable playability on the RAMP for a multiplayer cold start, which then performs great in the air (even though it’s not nearly as beautiful as my 1440p 27" Apple monitor that has better color than any PC monitor I’ve ever seen)
-Max rez/ readability of cockpit /MFDs
-Max draw distance
-Max FPS/ frame timing needed - I’m used to a 60Hz monitor, and as so many people say, you don’t need huge FPS for a flight sim especially with synthetic frames.
-Acceptable aliasing
…
New Oculus device settings:

–prev. I had 90Hz - but performance in ASW at 45Hz seemed really poor in situations where many frames were synthesized - especially with parallel render in the BMS config file left at “1” - large lagging black bars in my peripheral vision when looking around. This isn’t bad at all at 36Hz ASW.
…
Oculus debug tool settings:

Here I also reduced the vertical FOV by 10% to 0.9. Helps FPS, and the slightly smaller vertical FOV is barely noticeable.

I noticed the encode resolution gave me stutter / artifact problems when I increased or decreased it much from this 3664 value. Not sure how this works.

I’ve selected auto for some settings like ASW and dynamic bitrate - hoping Oculus software knows when it’s best to adjust quality.

Enabling the performance HUD for my HMD has been critical for testing along with this guy’s work:
https://smartglasseshub.com/oculus-debug-tool/

Oc debug HUD doesn’t have all the same info of Steam’s FPSVR, but FPSVR gives me a warning its API is incompatible with Oculus software and to close it to save PC resources. Still I’ve used it a little to help visualize CPU and GPU usage. I suppose taskbar reveals similar info - like my RTX3070 having it’s 8GB of VRAM maxed out all the time in BMS VR
-edit: I now understand that while VRAM shown being used in FPSVR is “allocated”, it is not necessarily all being used.
–

…
In BMS menu I have antialiasing at 2 - seems like a big improvement over 1, but haven’t tested 4 recently. 8 caused lag.

Object detail (draw distance) at 6 or maybe 7 is fine. I have smart scaling threshold set at 4 miles, and don’t really understand the relationship between smart scaling and object detail.

…
BMS Config file:

Importantly I’ve further boosted fVRresolution here to 1.1 since my Oculus is maxed out in it’s menu. Previously I had 1.4 in BMS and no adjustment to oculus native rez - I’ve changed this per general recommendations online.

“set g_bVRParallelRenderThread 1” increases FPS as v.s. “0” - but the tradeoff is peripheral black bars that lag especially when in ASW - but it’s no biggie for me with all my other settings.

But now I’ve turned shadows, environment, and environment water mapping all to ZERO - OFF. While busy in the cockpit you’ll probably never notice shadows missing after a short adjustment.

I haven’t messed with all these settings and have many questions:
Does reducePSFires help save frames when lots of vehicles are burning? And is this the same as “Reduce particle system” in the config menu available in the BMS Launcher?

Does default FOV affect VR?
HDR lighting?
How much do contrails /smoke affect VR when viewed up close?
…
I keep seeing that the NVIDIA control panel doesn’t affect much, so I’ve stopped messing with it.
…
All in all, damn VR is cool and doesn’t make me sick like it used to. Thanks BMS devs!
System:
RTX3070
Ryzen 5600X
Quest 2 - Link USB cable tested to 2.7-2.9Ghz in Oculus app