void68

Simple setting: You got a target coordinate as a waypoint. You go in lowest level, no chance for TGP to scan the area. You use a weapon in PRE mode. While you are close to the target you eyeball the target area and notice the target(s) are actually off around 1500' to the southsouthwest. With a scan zone of 500*1500ft² of the CBU105 no BLU/skeet will reach the target. What do yo do now? Do trigonometrics and add the coordinates to a new STPT? I don't know, but low level and doing calculations on a calculator may be a bad decision. Or just edit your already active WP to "offset 200° 1500'"? While I find VRP and VIP less useful a target offset input would be ideal.

New day, new chances. So, today I took your openvr_api.dll attachment file from the post (and not the one - to me identical(!) - version on my drive and amazingly it runs, too (the original .dll worked amazingly well)! I remember OpenComposite Switcher updated 2 weeks ago and the mess started and then I updated all other tools. As I neither get version info on the switcher nor the openvr_api.dll so I considered them being the same. How do you know that this is 0.6.3? I checked version history in the file's properties, no info at all. I'm back in the skies, guys!

From what I understood - but I am lost already - that native OpenXR support comes with the actual beta version of DCS only? The Openvr_api.dll does not run... error. So I use the old version like you, the Composite Switcher and the DCS original openvr_api.dll. Strange

I noticed the same problems with my 2076 model. Ran fine 1 month ago or so. Totally wrecked after any of the updates, I think it began with the OpenComposite update and then I switched through PimaxXR and OpenXR Toolkit like you. A question, do you use the OpenComposit openvr_api.dll or the DCS native one? With the native one I got no microstutters but all Texture setting above low lead to an OpenComposite error. With the OpenComposite .dll I get these stutters. Then: opencomposite 0.6.3 solved the issues I fail to locate this file, do you have a link? Do you mean the Open Composite Runtime Switcher? I just found one file without any versions. edit: error with the OC .dll (1,7MB), back to DCS .dll (580KB) and it runs. Didn't change the updated OC Runtime switcher. System runs again, thank you! Tried to get it back running for almost a week!

yes, amazingly the ingame OpenXR FPS counter tells me 40-50fps (before I accepted 30fps) but tearing effects and microstuttering leading to trail the image a fracture of a second behind my head movement leading to a seasick "experience". Also on Pimax8KX, but when I switch back to (<profanity>ty) SteamVR with less resolution it still runs good.

My Pimax8KX now gets tearing effects and microstuttering, but 15+fps than before patch. Unplayable!

Pimax8KX here, too. Where did you get that "DCS World (DCS.exe)" entry? I just have "OpenComposite_DCS(DCS.exe)". My HMD ran fine before these updates, now I face micro-stuttering.

Well, it ran almost perfect before either the latest DCS or OpenComposite patch 2 weeks ago.... over here Pimax8KX, newest Nvidia driver and Pitools update. DCS runs at around 45fps, PimaxXR runtime to "PimaxXR", OpenComposite... well, I just used it for switching Steam<->OpenXR, so I let it "stuck" to OpenXR and don't start it anymore, ok. Added "--force_enable_VR --force_OpenXR " to my exe. I get some tearing effects, the pic in flight is jumping a tiny bit, not in the lobby (the virtual hangar at start) and not in flight in map view, just in cockpit / outside view this sickening view latency at way above 30fps. I hadn't had this with even 20fps before. I changed MotionReprojection, SmartSmoothing, HiddenAreaMask... no change. Unplayable ATM. i12700, 64 GB, 3080 and M.2. I just checked, DCS update replaced the openvr_api.dll with the original one (god, I hate that!). So I put the OpenXR one back into the folder (1,77MB)but no change! Wrong or right, no damn change! So the big one for OpenComposite, the small one for "--force_enable_VR --force_OpenXR", right. I can do it either way, DCS runs and doesnt crash, it's just that bad flickering.

Do boresighting a target far away, the further, the better (Parallax errors!). Also, hitting Boresight Button a few times more than necessary (>1!) helped in my case a lot of times - no joke. Give it a try. Edit: no, doesn't work, sometimes it does, sometimes not. In active pause it worked after 3 times, all of a sudden.

Since when is it not possible to launch 4 HARMs from a single ship? I did so multiple times. HARMs might be inaccurate due to the targeted emitter shutting down or bad resolution bc of having a target modes not best suited for this situation. HARMs against SAMs with ABM is a bad idea as long as you don't overwhelm them with the shere amount (I don't remember exactly but they track like 30 targets or so and shoot 4x4 per site). HARMs or JSOWs are no choice against a (fully ammunitioned) SA10 site or SA15 (can attack 2 missiles at the same time with 2x4 racks). Low level attack or hiding behind terrain is the best thing to do. As long as there are no SHORAD. Hide behind trees, in a river bed, use every hill or building complex for terrain masking, set your dumb bombs for pop-up. Or locate one of the emitters with the TGP / HTS, MARK the point, have your Mavericks boresighted and set to PRE mode, go in lowest level, do a pop up 20s before reaching the target, lock the Maverick seeker, "Rifle!", hit the deck, throw chaff (and flares, you never now) and you should be safe from now on. The Maverick will reach its target before the SA10 gets a lock on it, even if it's not inside the min reaction range. HARMs are just for clearing a path through SAMs / AAA quickly. But everything with ABM isn't impressed at all and it just leads to waste of payload. SEAD (which means supression, not destruction) of course is possible... 4 times / aircraft exactly. Don't know if the AI crew in the Flap Lid / Command Unit counts your HARM attacks and just ignores you after having counterd four launches and look for other threats / targets, which means your SEAD mission ends exactly at that point as you got no A/G ordinance left. There are quite some vids on the tube how to kill SA-10. As I said, as long as there are no AAA and short range IR / MANPADS or even small arms fire if you are out of luck they are quite easy to take out. In a setting which reflects reality... single ship no way. With neither weapon. In neither situation.

dcs_updater 2.16.0.10.exe starts with little white window "checking for updates", then loads into DCS (I think) and blackscreens. DCS.exe 2.7.18.30765 works without problems, game runs smooth.

So any idea on how to set curves in SimAppPro? VirtualDevice, adjust curves and then just "start mapping" leads to a 2s run and then stops. Mapping is saved, curve adjustment profile green. No change in the curves however. Never thought I would like to have T.A.R.G.E.T. back one day...

nice, that looks promising for 2.8

97's are messed up since August 22 or so. Still they are not able to fix it. CBU87 should work however. It's a problem with the container opening and the chutes almost instantly stop the bomblets to zero horizontal speed while the targeting computer thinks they fly towards the target on the unretarded trajectory. A shame it still exists in 2.8, I was hoping for a proper F16 update! And the devs haven't lost a word about it. Aim around 300-400m ahead, depending on your current airspeed and leave BA at 900ft. There are lots of posts about it. Do a similiar test with MK dumb bombs and you will see that the toss calculation for these work (at least <2.7, dont know about the actual patch, perhaps they messed it up, too).

Also enable Parking Brake if on any inclined / sloped taxiway - and even if not, just do it! Even minimum, hardly noticable movement may ruin your INS' day. You not even can deselect classes, you even can go for individual SAM sites' codes (ALIC tables) to refine your search time to a 20s or so.

From what I recall... I am at the office and can't check the trk nor do a test: TMS up 2 times, first to ground stabilize, second to enter the data - or was this the condition just for HUD marking? I think there's a reason why this module still is in EA, lots of bugs in the logic - or it's a feature. But I think I remember once on a pure recon mission I had no AG ordnance, too, just the HTS and the TGP and I was able to set markpoints.

You still can define the DF switch to smoke (usually not with a single use DX key, but a keyboard press instead) . And just exchange smokewinders with "no sidewinders loaded, smoke pods loaded" and you are good to go.

In that case, as both situations do not occur at the same time, just stay with the usual programs and just disable chaff or flares on the CMD console. So in case the program 1 usually fires 5 chaff, 5 flares and you set flares to "off" to save them.. program 1 will only fire 5 chaff. Then, in dogfight, switch chaff to off and flares to on.

In Norm you have to confirm the Lat and the Lon line, in STOR you must not! Also if you are on a somewhat sloped parking slot with minimal movement, hardly noticeable...hit the Parking Brake and then do the alignment. Also I noticed that on multiplayer servers the alignment sometimes fail!

Yes, I can confirm as I do this on a regular basis for SEAD / Wild Weasel: Stay in the outer 10-20% of the max engagement range of a known SAM with ECM off. SAM gets a lock on you and fires a missile. Get the ECM active to break the lock together with beaming or notching to get a moment to breath while looking for that smoke trail to reveal the launcher. Lure the SAM to fire at max engagement range and shake it off with the ECM. If it's active the SAM won't shoot till you are at burnthrough range. As with most things.. all the modes got their pros and cons.

Yes, of course I set the mission with zero wind. Furthermore they always fall short, no matter what direction (in case of any wind at least in downwind attack run the bomblets should fall long). They always fall short. The skeets perform as advertised. If the skeets / bomblets are close to the target they do shoot the molten "rod". It's just that the bomblets are not over the target - while the canister hits the target. Exactly, the higher the BA and the speed, the worse the deviation. 0 ft BA is a direct hit! But a dud, of course. What I do: CCIP "just" aim 200-400ft behind it, it's a matter of training, of course and not really satisfying. CCRP... well, do an evaluation of the situation and then plan from where you will attack. Do a (outside the engagement parameters of the SAM) short simulated attack run and place the SPI a few 100ft behind the target (3D on a 2D screen...), turn away, do a re-run and use the HSI steering setting for the exact radial for the attack run (a bit over-complicated, I admit). Usually it hadn't to be so exact, you can place the SPI behind the target from every direction with a bit of evaluation training or even do it while on the attack run if you do a short pop-up (and instant down) with the backdraw that fine tuning the SPI from low alt into "depth" of field is tricky as each pixel represents a few 10ft or so. Yeah, the CBU97 is IMHO the best against single type SAMs. You can carry up to 10 and take out everything, from high alt through the cloud layer to low level pop-up / lobbing and the bombs can't be shot down by the SA-15 or SA-10. Windy conditions can be a problem, though. But don't forget how adrenaline pumping and satisfying a 10-50ft alt attack run is in comparison to a boring "Magnum" employment... It's the most important part that needs fixing, ASAP!

So... putting the waypoint AGL+BA and setting the BA to near zero result in a dud, cause no matter at what altitude the waypoint is set, the bomb always refers to ground level, I forgot that. So, burst characteristics / flight path of the CBU-97 vs CBU-87: While the 87 behaves mostly like a non-burst - it falls like a normal bomb, rotates, bursts open at the BA and as the bomblets are not retarded they follow mostly on their predicted path - the 97 is totally different to that: it falls like a normal bomb, bursts open at the BA and the subammunition is almost instantly retarded, so it does not follow the normal bomb path but remains somewhere between the calculated impact point (of a normal bomb) and where it bursts open. The higher the initial bomb speed the bigger the deviation (as the computer calculates a faster bomb for the remaining distance after the BA). While I noticed around 200ft at 250kts it was around 400ft at 450kts. High speed pull up attacks where with less deviation of course as you tend to lose a lot of speed during a hard PU. So... they have to develop a totally new calculation scheme for the CBU-97 while all other dumb bombs (including the 87) follow the same glide path while the 97's is abruptly cut-off at BA. Anybody noticed they changed the bomb mode cylce? From CCIP->CCRP->DTOS to CCIP->DTOS->CCRP... why that?

hmm, it tells me "Grabing config ...DCSBHap started", Sim: DCS, IP 127.0.0.1, Port 4125, status green, Preset: DCS_F18. Log says "no fresh telemetry data". When I hit "Stop", bhaptics tells me "Client disconnected", when I hit "Run", bhaptics player tells me upon connection "client disconnected"... "DCS_To_bHap.lua" is in ...\Saved Games\DCS\Scripts\Hooks\ of course.

it can be me, but... yes, they fall short, so I aim ahead 200m. Sometimes they hit the 200m offset point exactly. Sometimes they fall 200m short and hit the target. I did not notice an overall constancy! However perhaps you noticed it too, the CBU97 container hits the target on spot! It's like the bomb's calculation is to reach AGL 0ft on the target, not to open the canister at burst altitude over the target. The higher the BA the worse the offset. What I will test, set the waypoint at BA exactly over the target and see what happens then. A shame they aren't able to correct this bug for over 2 months, makes low level SEAD almost pointless in CCRP / DTOS mode.

thank you, I'll test it. Late evening, all failed and settings gone... left me very frustrated. Did an integrety check and all is back again working. Second iteration now... Sorry for that idiot fault... I lost track.