STKDirty

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!

I can confirm that this sequence works for me. I let DCS open WMR for me and wait until in cockpit to load XRNS and everything works. Dirty

As the title says. I have problems with the native OXR in DCS so I still use open composite. However, when I run MT, it seems to display a lot of the behavior that I had when I tried native OXR in the last patch. If I use ST on the latest open beta, I don't have any issues (aka it's using open composite). Can anyone confirm if MT is using native OXR by default? Thanks! STKDirty

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

Update, as Terry Dactil mentioned above, I had my GUI font size at 1.5, I set it back to 1.0 and it moved the messages up a bit as seen in the below screenshot, but to me it is still in the way. @BIGNEWY, I'm kind of new to reporting things like this, it seems like it was a design decision and not a bug. How do I submit a request for this to be looked at by the design team and perhaps reverted or made better for VR? Thanks!

Not sure where to put this so apologies if this is not the correct forum. Since 2.8 certain messages appear halfway down my screen instead of the upper right corner where they usually are. I don't even know where to begin to troubleshoot this. Attached are examples. First one is unsolicited messages like JTAC status. The second one is if I actually go into the comm menu and request JTAC status, that one works. Has anyone ever seen anything like this? Thanks!

Cool, fair enough. My shots were at night and with running vehicles so I just thought they might stand out a bit more. If I can get a small enough track together, I'll send it along. Thanks again! Chirp

@NineLine That's interesting. So, I'm really not trying to be a smarta-- here, but are you saying that if you have a mission in summer that the TGP is pretty much useless? If that's the case then so be it. I'm guessing that your summer screenie is probably what's happening with me. Like I said in my post, the explosions show up fine in black or white hot so it might not be a bug or a programming thing, but just a usability thing. If I may ask, how would you go about finding a target from 20 miles out on a hot summer night? Again, not trying to be smart, just trying to get clarification. I do have a track but it's 96MB and probably would only show you what you just showed in your post above. Anyway, thanks as always! Chirp

Don't mean to beat a dead horse here but is this really correct? I couldn't see these guys until I got really close, like within 10 miles. As someone else mentioned, it seems like the polarity of either the background or the vehicles is off. I will say that when they explode, the smoke is the correct color. I tried to get more screenshots but I must have kept hitting the wrong button (probably insert instead of print screen, I was going by feel). These vehicles are from an older mission, but they are running, they're not static, and they'll move if a nearby vehicle is popped. Maybe this is one of the vehicles not yet mapped in the new FLIR? Just seems a little worse since the last patch. Changing brightness and contrast on DDI doesn't help anymore. Thanks! Chirp

Yup, that was it for me. I thought it was random when I got that issue but realized that at some point I was releasing the parking brake early thinking the wheel chocks would keep me in place. I had no idea the PB was necessary for alignment. I now wait until after alignment to release PB and haven't had an issue since. Dirty

I think text should also turn black when in black hot. Can't read white text on white background when in black hot. Thanks!

+1 Thank you for posting this, I thought I was going crazy. But when an STT shot from inside 12 miles misses AI badly, I mean come on. Glad it's not just me.

Has anyone seen where your afterburner looks on to other people on a server, but to you it is off? I had a wingman saddled with me claim i was in AB and pulling away and my instruments showed i was not in AB as well as my external view showing no AB. Has anyone seen this? Thanks!