STKDirty

They would never take out tanks or anything that I'm aware of. However, I use them a lot to DEAD SA-11s. Need alphas because the launchers are tracked and as soon as one hits, they move a little, so cant use charlies. After a patch a few patches ago when they adjusted CBUs, the JSOW As stopped working as you say. I found that changing the burst height from 1500 to 300 does the job. Enough spread to get any moving launchers and enough concentration to inflict enough damage. This was trial and error, so I cannot correlate this as to how it's "supposed" to work, but it works for me at least.

Hello, I know this thread is old, but does this still work? It doesn't seem to work for me. custom arg [509] doesn't do anything whether it's set yo 1.0 or -1.0. Thanks! Chirp

I have similar/same issue in VR MT. When my wingmates land and I am watching in external view, I cannot see the wire. I need to look up at the 4 wires and see which one is missing across the deck to determine which wire they snagged. Reverb G2/WMR/OpenXR, i7 14gen, 3080ti, 64GB ram. I'll try to gather track/logs and post. Chirp.

Thanks! That got me on the right track. For those who want to know, the hornet BORT number arguments are as follows: scene.m:setArgument(442, .4); -- First BORT number scene.m:setArgument(31, 0); -- Second BORT number scene.m:setArgument(32, .8); -- Third BORT number The number after the decimal seems to represent which number you want. The example above is for 408. Chirp

Hi, great thread! I read through the whole thing but did not see a way to change the BORT/Board numbers on the hornet livery. The setting in Model Viewer is under the arguments section but it isn't clear what command that translates into for the scenevr.lua. Any help is appreciated. Thanks! Chirp

If I may ask, how much better? What was your FPS before and after? I have a similar system, so just curious. Thanks! STKDirty

Hi, just wanted to get opinions if this looks ok or not. I don't really have any issues, but wondering if the constant oscillating of the frame and simulation lines looks right or if it should be a straight line. The frame time seems to jump between 11 and 20 really fast. Thanks! System: i7 14th OCed to 5.6 64GB RAM OCed to 6400 (2x32 sticks) 3080ti proc affinity FFFF STKDirty

For those who are in VR and the full screen setting is not working, I got it to work by modifying the below blue words in \Bazar\shaders\PostEffects\NVD_HDR.fx. OLD: technique10 Compose { pass P0 { SetPixelShader(CompileShader(ps_5_0, PS(false, false))); COMMON_PART } pass P1 { SetPixelShader(CompileShader(ps_5_0, PS(true, false))); COMMON_PART } pass P2 { SetPixelShader(CompileShader(ps_5_0, PS(true, true))); COMMON_PART } } NEW: technique10 Compose { pass P0 { SetPixelShader(CompileShader(ps_5_0, PS(false, false))); COMMON_PART } pass P1 { SetPixelShader(CompileShader(ps_5_0, PS(false, false))); COMMON_PART } pass P2 { SetPixelShader(CompileShader(ps_5_0, PS(false, true))); COMMON_PART } } The 2 booleans that are changed from true to false represent whether or not to use the mask or not. Not sure why VR uses a different one than 2D, but I just changed them all to false and it worked for me in VR.

I didn't see LRLLS fix for MT, is that being looked at? Thanks!

See attached @Flappie Thanks! STKDirty dcs.zip

Thanks. Mystery solved. The latest version of XRNeckSafer is the culprit. Dirty

Has anyone seen this? I was running OpenXR with open composite. Even centering the display within DCS does not fix it. Not sure what happened. Any help is appreciated. Thanks! Dirty

Same here. for me, in the F18, my JHMCS would work, but the rest of the plane wouldn't. I'll try the fix, thanks!

@FlappieOk, I did a few tests. One thing to clarify, it is not the scale gui setting, it is the message font size setting. So I created a test mission with a trigger zone that would create a message once the plane left the zone. I've attached the miz file. I did 4 tests. 1. MFS at 1.0/did not open comms menu until after the message appeared. Result: message was halfway down the screen 2. MFS at 1.0/opened comms menu before the message appeared. Result: message was in correct spot in upper right 3. MFS at 1.5/did not open comms menu until after the message appeared. Result: message was down in the cockpit over the right DDI 4. MFS at 1.5/opened comms menu before the message appeared. Result: message was in correct spot in upper right I attached a 5th track where I was doing one of the tests and the message appeared in the correct position in the upper right, then all of a sudden it moved down to half way down the screen. I cannot reproduce this so I don't know what happened here. Let me know if you need anything else. Thanks! STKDirty tracks.zip TEST.miz options.lua

Thanks Flappie, I'll work on a track. To clarify my issue, I'm in VR. I was using a scale GUI of 1.5. When at 1.5, the messages were down in the cockpit of the F18 right over the right DDI. This was regardless of whether the comms menu was open or not. By changing the scale back to 1, the messages moved up to about the middle of the right side. This is "ok" since they don't interfere with the cockpit instruments anymore. However, before 2.8, as far as I can remember, these messages were always in the upper right corner. I never noticed them being pushed down because I also use Viacomm and had disabled the comms menu for most things. So I guess the main thing here is that the message box is pushed down whether the comms menu is open or not. That's probably what I'm noticing. I'll post what you asked for as soon as I can. Thanks! STKDirty