DroptheHammer

sssooooo... Why would the Air to air radar make a SPI where the last bandit I splashed crashed in? And why would that point now be where the A2G Pod wants to reset to? Also, I practically never use the A2G radar to mark anything... Does this mean if I want to go back to waypoints, I always need to clear both the pod and the A2G radar even if I only marked with the pod?? In the past I never needed to do this. just SPI designate with the pod, and clear it with undesignate.

I would argue this is less advanced. as now a user still has 40th Livery Pack - phoenix _ 1.9.0512.zip installed and had no idea it should be gone. How would OMM know to remove that one and replace with 40th Livery Pack - phoenix _ 2.0.0529.zip if I removed all prior entries from the repo? With OVGME it flags all versions older than a certain version code (in metadata, not file name) and works great for this. Maybe i'm missing something? Metapackages might be a better answer, but how will I not end up with junk on the end user side? do I tell them to just clear their own local repo first? I dont want to replace from 1.9 to 2.0 on some subpackage and they still have 1.9 hanging around on their system.

Brief introduction In Slave mode, The WMD7 pod used to give up it's current orientation, SPI or otherwise and point at the currently selected waypoint if the "Undesignate" button was pressed (same button as ending a radar lock). Detailed description After an A2A kill, or some area track is established.. the pod no longer returns to waypoints like it used to when a SPI is cleared / undesignated this used to be great, because if I had say a... Pre Planned 1 (WPT36) in my computer.. I could slew the pod to that with undesignate and then check that area for targets.. shoot at something, and then put the pod back on WPT36 by pressing undesignate again. How to reproduce Fly to a waypoint, slave the pod to it... attack something not at exactly that waypoint (air or ground) and try to get the pod back to exactly the waypoint you had before via undesignate. The pod will end up putting itself where your last area track was and not your waypoint. Attach dcs.log and trk All of my track files for this are larger than 5MB. Not sure how to get such a small one.

Hello @sedenion I'm a mod manager for my squadron. We currently host an OVGME Repository with some 35 mods (mostly curated from the DCS Forums but many of our own livery packs, assets etc). Currently with OVGME, we will have a mod named something like this... 40th Livery Pack - Phoenix.zip This is compiled with OVGME and has metadata like the version number (1.8.403) and description embedded into the archive using OVGME's archive builder. We upload to our repo and update the MODS.XML in the online folder to change the version number to the latest. Then when users sync their repo, they get the orange checkbox saying (you already have this, but it's an older version). From there they can sync up and download the latest ones. With OMM, the best I can see.. the version number is now forced into the file name, and this makes the repo potentially a mess as you would have the following. 40th Livery Pack - phoenix _ 1.8.403.zip 40th Livery Pack - phoenix _ 1.9.0512.zip 40th Livery Pack - phoenix _ 2.0.0529.zip Personally I would prefer not to have all these versions in the file names. It means someone can accidentally download and install 2 over each other. How should I handle this in OMM? What steps do I need to take to manage this? Thanks, DTH

I think he covered it in this paragraph.. “The chaperone can be forced on at: SteamVR menu - Developer - Debug Commands - collision_bounds_toggle. Now, if the configuration is correct, the chaperone lines crossing the cockpit dial remain accurately fixed on top of each other in any position, rotation or tilt of head while wearing the headset. Even a small miscalibration can be perceived by looking e.g. at a cockpit dial down and to the side and turning and tilting the head around as in some head orientations the relative positions of the cockpit dial and chaperone lines appear to be different from other head orientations or positions. When config is good, changing head orientation causes no shift in the apparent relative positions of cockpit dials and chaperone lines.” makes me a little disappointed because I’m using OpenXR and don’t have this feature to use.. maybe if I set the alignment in steamVR it’ll carry over? I don’t know of a similar OpenXR function.

Taz... legend mate...

@Taz1004 If i'm looking to cut the DCS Haze down.. which sub section/file do I need to alter? in VR it's just too much, I can barely see things co-alt at 12 NM. I know the dot is there becasue I can see it higher or lower, but just not co-alt with the factory haze.

So after I purge shaders you’re saying on the first run it’s better to compile everything in 2d? Then run VR later? Is this better long term for frame times or jitters or something? or is this only to avoid being stuck in the helmet while it flashes and jitters a bit on first load. reason I ask is I’ve been religiously compiling in VR first after making changes and wondering if I’ve been screwing myself over :)

+1 this drives me mad especially at night.

So far, the new patch it seems to be pretty reliable. However we haven't seen what happens on mission night with 40-60 players. Will provide an update later in the week.

Alright, I forgot to come on earlier but I figured out why this is. It's all planes and not the Jeff. Simplex and other shader mods dont have entries for the new flir... so flir = instacrash. Please consider this thread answered although it isnt JF17 specific.

Very excited for the new FLIR textures etc. However I loaded the Laser Guided bombs SP mission and the moment I switch the POD to IR mode I get a hard crash. Repeated 3x. this is from A-G master mode and using the pod on the left MFD.

Reverse ground effect might be magnifying the fairly stable descent rate in the final moments. Combined with lag it might be a contributing factor. I also agree the plane feels stuck to the ground on takeoff compared to before. hopefully we get a pass on takeoff and landing characteristics as well as gear strength. Obviously it shouldn’t take carrier landing styles like it used to… but it’s way too fragile now.

Thanks! That’s helpful to get that confirmed in 2022

Anyone know what the current list of items covered in testing features and icing on the cake is? Last thread I saw was from 2020.

Over the last few weeks, it seems the Jeff gear is now made of tissue paper. We've got 3-4 pilots in the squad with 500+ hours in the JF17 who are pretty smooth sticks. We've been landing over and over in situations with light loads , within the e-bracket in the center for speed & angle and sink rate of 100-300FPM descent rates at 1-3Deg angle. Almost 50% of our landings end in broken gear struts. I think this needs to be checked and tested in multiplayer. Maybe there's some sort of lag desync going on? Also doesn't seem to matter if there's a crosswind component or not, we landed from 0 knots up to 30 kt crosswind and had the same breakage percentages around 40-50% of all landings. Stores and fuel weight dont seem to matter either. We're typically a multiplayer squad operating with 25-35 players per mission in mixed airframes. It's gotten to the point where we just realize half our Jeff flight will need to replane at the end of every sortie. Very different from the typical quick refuel/rearm we're able to execute with this amazing light fighter in prior patch-states. Is any other squad having this issue? I don't want to open a bug report if there's already a fix or a technique other than the obvious... fly the procedure and the e-bracket. Regards, DTH

Just wanted to re-affirm that after the network fixes I still see this issue in SP and MP in similar scenarios (fire at 40-80NM and shortly after these weird fresh contacts fly off to the left and right of the prior track that was launched on... trashing the track...). I've been changing my tactics to just shoot much closer in and try to separate bandits by maneuvering in random ways as I close distance (also to avoid the sneaky ET).

1.0. I never use the ingame settings to change PD because they are too coarse and with the same equivalent PD...

I concur with speed of heat. when I make changes I do 700% zoom in on HMDs, instruments, ground targets and aircraft. In the cases mentioned above, I see no difference in the Reverb G2 HMD,.

As long as total pixels are the it doesn't matter if you use the global or per-game slider, the pixels rendered are the same. But for reference I have global set to 100% (default) and the DCS Per Game @ 200%. These are 2 different Git Repos https://github.com/fholger/vrperfkit and https://github.com/fholger/reshade The VRPerfKit I have configured to use the above settings, but under the NIS Sharpening in VRPerfKit I have it set to 0, mainly because using NIS sharpening causes colors, especially bright yellows and greens to look weak and sickly. Instead, I apply the sharpening pass in reshade (using FHolger/Reshade), which gives that nice crisp look for a similar frame time and does not degrade the colors. To be fair, FHolder/Reshade and "Sharper Eye Reshade" both work for this, but I just wanted to unify all my mods under FHolder to ensure their compatibility. Reverb G2

This plugin hasn't been updated and frankly gives a very jerky stream. Sure it's at full res, but it stutters constantly... What I'm doing instead, is using the new DLDSR option on Nvidia cards to render my desktop (not DCS) at 6K resolution (roughly) which allows my DCS Mirror to be a full 4K tall without touching the edges. Using the standard DCS Window capture, OBS is now getting a perfectly smooth, full 2160x2160 resolution to look at. When I crop to 1080, it's super crisp and fluid. Works great and while streaming i'm only seeing around a 3FPS average hit over my normal FPS in each scenario. with a 12900K OC'd to 5.4 and 3090 OC'd to 2025mhz and 11000mhz ram... I'm seeing my stream constantly at a smooth 60fps with my Reverb G2, even in very intensive multiplayer scenarios. I'm also using NIS upscaling with FHolgers mods. it looks great, at 700% Zoom, looking at HSDs, switches and tomcat textures in lightroom screencaps I cannot tell the difference (and my squad can't either using a blind test of 5 mixed images) between NIS @ 0.59 with 200%PD and 60-90FPS vs Native Res at 150%PD with 45FPS. If you look at some of my most recent twitch vids.. you can see for yourself.

So I found someone else's github that hacked the fixed foveated to work and I do see it working when enabled (you get block 1/16th resolution around the outside edges... However, if NIS is already enabled i'm seeing no meaningful additional gains on my 3090. Maybe 1FPS at best.. Sure it helps if NIS or FSR is disabled (like 5-10FPS over native res/scaling), but frankly the overall picture quality, overall FPS, especially on my stream is much better with the upscalers than the fixed foveated. So I've returned to having it disabled. My current settings are.. NIS at 0.59 NIS Sharpness at 0 FHoldger Reshade at default (this is where I apply sharpening) SteamVR SS@200%. Works great, I see a constant 90FPS in SP or light MP with high settings and ultra clouds I get 45FPS - 60FPS on Hoggit PGAW/Syria etc. and 45FPS on our mission night events (which have 500+ Statics, 40 players and tons of triggers) while streaming 1080Px30@6000KBPS. @speed-of-heat I've also got pretty much all of your normal 3090 settings applied too.. for those who care, except what's mentioned above.

I guess in this case, when mid course guidance is improved i guess things will improve. At the moment, even for established tracks I see the missile overshoot targets accelerating hot on known tracks, or not turning during the boost or initial glide phases. But tweaks here will mean more targets are still in the "pitbull basket" even if the tracks are lost late in the missile's travel time. Keep fighting the good fight HeatBlur! Things are always getting better and I just want it to be the best it can be.

While I think it still does this (guide the missile towards the X'd track since that is the best estimate it has).. that missile never seems to get the "go-active" command. and just flies off as a dud. never using it's own radar to try and find anything. I've verified this on many targets that were on a stable vector, flying straight (like a mig-29 AI that just dumps it's entire chaff load and spoofs a track at 70NM).

ok so I treat "Multi Attack" as mandatory attack for the time being.