STKDirty

Thank you all for the input. the GBU24s worked perfectly, ended up using the laser. Since we were so low the wind didnt affect it much. However, now I plan to do some more research on the different fuzes and uses. Not sure why ED decided not to document this, but I know the info is out there somewhere. Thanks!

Thank you! I'll give it a shot!

I selected tail in the stores page. Theres no DCS documentation regarding the fuzes so i have no idea what they do. usually when I change the default, the bombs are duds so i never bothered. im assuming I have to do something with the fuzes, lol. any guidance would be appreciated. Thanks!

Hello, Sorry if asked before. We're running a mission where GPS is jammed (wargamed), so we cannot use GPS weapons. Our target is the C3 bunker where the jammer is. It is a hardened target. Cannot user GBU31s since they are GPS and apparently do not support CCIP/CCRP (please correct me if i'm wrong here). Also, weather is terrible, so Walleyes are out too. Looking at other bombs in F18 inventory, I see Mk84s and GPU10s. Neither are penetrators. Tried using them anyway, but 2 Mk84s with tail fuse did not scratch the bunker. Does anyone have any data on how to kill a hardened bunker with unguided weapons in the F18? Thanks! Dirty

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

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