void68

Ground alignment works with intense flaws as last time I checked Snowplow on ground wasn't possible, so the TGP is always linked to waypoints which usually are miles away and way off your nose.

Danke für die groben Einstellungen. Ich konnte bisher die aktuelle MT Version auch mit dem OpenXR Toolkit gut fliegen, mit der 4090 kam ich zumeist auf 60fps bei 1.0 Auflösung. Seit ich aber die PiTools auf den PimaxClient umgestellt habe ("better compatibility with 4090"), habe ich wieder dieses Mikroschlieren und leichte Zittern. Zur Lösung musste ich OpenXR Toolkit abschalten, aber irgendwie möchte ich das nicht missen, weil es gefühlt mehr FPS bringt und man solch nette Postprocess Funktionen wie "Sonnenbrille" hat, gerade in der F16 von Vorteil. Ich habe das Gefühl (!), dass der PimaxClient die Grafik noch mal leicht aufpeppt, aber irgendwie habe ich mich auch in dem Rabbithole Pimax, OpenXR, DCS in -zig Versionen verlaufen. Gibt es irgendwelche neuen Erkenntnisse?

Thanks, but I don't understand how that thread may be of any help. Last entry by user Yoyo says "Only ST version works with OXR or OVR (SteamVR), MT only OXR. ". The post you relate to says "With OpenXR supported in the game, you do not need OpenComposite anymore, regardless of what headset you use.". I use OpenXR standalone, no OpenComposite anymore. What I did (after I flushed MT out of my PC): installed the new PimaxRuntime 0.3.4 and the Toolkit 1.3.2 and it seems to work now. I was very cautious and hesitating to "just update it" as the previous updates on the previous stable release of DCS broke VR. Had to go back to older XR releases. Thanks for giving me the kick to dig into it again!

No change. I corrected the start parameters to "\...\DCS.exe" --force_enable_VR, program stalls in loading screen at 38%. With --force_enable_VR --force_openxr it at least finishes the loading screen but mouse cursor (that dot) isn't responding and program seems to have frozen (kill process in task manager). Loading DCS MT in (prior to this I had to --force_disable_vr) 2D, then tagging "VR headset" in VR, hitting ok -> restart gets me to 2D but with VR headset tagged. Shutdown and launch DCS.exe without any parameters stalls at 82%. "Hot plug" is disabled. dcs.log throws this out "VISUALIZER (Main): OpenXR xrWaitFrame failed with error: XR_ERROR_RUNTIME_FAILURE" edit: I disabled OpenXR Toolkit, too. No change, program just freezes after loading to main screen.

I keep the NWS on as long as I need it. With asymmetrical loadout and crosswinds it's better to have too much input than too little. Also in rare occasions of tailwind landings (or takeoffs) the rudder's force is down too zero far too early. Put a curve on your rudder and you can gently steer the F16 even with 120kts GS with the NWS. That's better than not enough steering! Saw lots of F16 got trashed due to too little input than to too much input.

Thanks, I'll check this evening and report back.

Can confirm to the fullest with actual stable release! On ground, trying to boresight Mavericks. TGP is facing dead forward in external view as it should. Internal it's facing to steerpoint 1 and in my case it was around 130° to the back. Hitting SP once, twice, 100.000x in rage, no change. Switching steerpoints, TGP moves to actual steerpoint as it should, slewing it, then CZ to zero it back to steerpoint works. But you just can "unlock" the TGP from the steerpoints. In external view, as you cycle throught the steerpoints, the TGP head doesn't move at all. In air, SP mode works as before, boresighting works at last! So, as you are not able to "zero" the TGP dead ahead, Maverick boresighting is messed up again, just at a different level! Now how do I find my humblest, kindest words for this? Please, boresighting is wrecked for half a year now, Mavericks since then no choice for any loadout anymore. How can it be that this version was released and no one checked if boresighting works at last? How can it be that we have to provide track files (which is quite some work) for what the devs can check within 10mins by climbing into the F16 and try to do a boresight process? If it works for them, please explain how and then you get my sincerest apologies and utmost gratefulness for lighten me up on what I did wrong. Please, hotfix this ASAP, I think most players don't want to wait another 6 months for an update (which hopefully won't wreck another system).

I don't get it: Shouldn't MT DCS (not Steam version, actual stable version) start in SteamVR if not forced by "-- force_openxr" argument? I tried "--force_vr --force_openxr" and either it stalls while in loading screen (sometimes 11%, sometimes 87%) or it enters the game but the image in my Pimax8KX headset is frozen (still headtracking the scene, not in the scene, but like a movie screen) and no mouse input possible. Starting with --force_disable_vr works, but puts me into 2D, of course. Starting with "--force_openxr" either set or not set doesn't change anything, not even SteamVR comes up. ST works in both VR and 2D.

I may be wrong but I doubt that the boresight procedure / necessety doesn't differ from gun convergence. Once you have boresighted the Maverick the system knows the offset. With this error defined the Maverick's head knows how many degrees it must "azimuth travel" for each degree of the TGP. In ß I don't have any problems with auto handoff in neither ranges, yes. with boresighting zoomed-in Mavericks. In stable release you can simply forget about the Mavericks.

Check wind over target area, in top DED page, dubber right for wind dir and speed. Check your ingress course and adjust CCRP resp. SP windwards for wind correction, 100' or 200' for medium wind. BA of 900' AGL (you noticed the cap on the nose of the CBUs? That's the laser altitude meter measuring AGL) will make the CBU pop open at almost minimum altitude with almost no wind drift, minimum time on the chute with almost instant deploy of the skeets. 800' may result in a dud. The BLU 107 submunition (in the CBU97 and 105) is dropped out of the container in a fix manner and there is no spread at all, you just expose the submun to longer winddrift and they all drift the same. So higher BA result just in higher drift and not wider spread like the CBU87 which spread is more of a funnel type. BLU107 spread is always 1500x1000ft² if I recall it right. The buggy WCMDs isn't wind corrected at all, and it's already being reported to the devs.

just out of rationality: Landing lights shine a long and narrow cone, taxi lights short, but broad. While taxiing you like to see more of the surroundings / exits / interjunctions and don't need to know what's 1000ft ahead of you. Like in the automobile: high beam and low beam. Landing lights... usually you go straigth in (and out) and need to know if someone's blocking your runway, you don't care what's left or right of it. So, on taxiway: taxi lights, on or on approach runway: landing lights.

ahem... my bad. There was an old, unknown to me, installation of the beta on my stable DCS drive g: ... so there was that registry entry pointing to that drive. So, ofc the beta automatically wanted to update / install to the given path. I did not remember I installed the beta ever, damn, I'm getting old, too many drives to maintain order. Deinstalled the beta, installed the beta to another drive with the usual "install to" option given and all is fine. I'm sorry. Thanks to all.

From what I understand: once the HARM gathered enough information with triangulation in EOM mode it should have gotten pinpoint accuracy to the target more or less when it's inactive. If the radar is emitting it just rides down the beam to the target. A tracking radar constantly painting you should always result in a 100% hit if you set it to target in the HAS page. A Flap Lid painting you and you've set and launched the HARM against a "10" should result in a hit. But it does not, perhaps once in three tries it succeeds without one single HARM got shot down. HARMs are BS, far too unreliable.

No, it isn't. I already have the stable release installed, and I just want to parallel install the beta. But I noticed the beta installation doesn't want to go to C, but to the installation drive of the stable release (what is G drive). So I think there's already some "installation path".txt or .ini somewhere. We are getting closer, I think.

I just want to use the most basic installation option implemented in every other software: define where the game will be installed. DCS doesn't give me the option. What to do? I can't let DCS decide to install on c : and then move / clone it to another drive simply because I don't have 150GB free on my c :. And as I refuse to accept that I can't choose the drive/directory of my liking. Also I fear the mess up my installation of the stable version. What am I missing?

Can't help with nothing else but guessing... from thinking I have understood why it's needed at all: Even a minimum inaccuracy of a fracture of a degree while mounting the launching racks will lead to a huge deviation at 10nm or so. Trigonometry tells me that at about 1° at 18km deviation is 320m. Still I wonder why there's no tolerance in the mounting of the Mavericks to the launcher as you always just boresight each launcher. So, if the launchers kept mounted and just the Maverick are added then following my "logic" there's no BS needed. If the launchers are refitted BS needed. However... perhaps it's a matter of factory / storage precision. Perhaps they got precise instruments in attaching the Mavericks to the rail so they are always perfect aligned in the shed. And then the ... somewhat crude ground crew with big paws, greasy fingers and a worn out wrench attach the rails somehow to the wing resulting in perfect aligned Maves in a misaligned rail. Just a guess.

Each screen has to be fed with approx 1,4 times (depends on the model) oversampling of the native resolution to neutralize barrel / pin cushion effect due to the lenses' distortion.

That should be read "if you use beta I think boresighting does work and you have to re-boresight like before", sorry for that. As I haven't tested neither beta yet and thought it behaves like before where as far as I remember you have to re-boresight in the previous stable release(s) when you get a new bunch of Mavericks loaded. Can't actually test it, as with current stable it's broken.

Same here, but with all devices, depends on your motherboard and / or the behaviour of your USB Hub (no signal->turn off power), I think. Soft shutting down your PC doesn't mean it's off. There might be a BIOS setting if USB ports are still powered when in soft off. "Once upon a time" we had big red levers on the side of the case, just a flip and the PC was off. Totally OFF! Physically disconnected from the grid. There's a tiny little reminiscence on these golden times: Your power supply block usually got a tiny switch with almost the same function. Just turn it off after shutdown and your USB devices (not powered through a hub) should turn off too.

Beta? You have to re-boresight. Stable release? Boresighting is broken.

You a) lost part of your lift on your left wing and b) your loadout is asymmetric with the right wing being heavier. The faster you fly the more lift is generated on the right, intact wing so you have to trim right. When you slow down for landing your starboard wing doesn't generate so much lift anymore so the weight has far more impact on your trim causing the right wing to come down and you have to trim left. Without any speed and so without any lift the right wing would be 90° downwards (like in a 90° bank angle) taking into account the less mass on the damaged port wing and the additional ordnance on the right wing, so constant trimming is needed and perfectly (?) simulated. To counter this you might switch your fuel->engine feed on the left console, in this case I would turn the switch from "NORM" to "FORWARD", sucking the right wing tanks empty first. You can observe how much is already pumped by checking the two hands dial ("F" and "A") on your right console "Fuel". Beware that might shift your center of gravity, as these are combined "forward and right" and "after and left" tanks! If the left wing wasn't damaged you would just have to check for the remaining dummy Sidewinder's weight and suck that amount from the standard left/right fuel tanks difference but usually any A2A ordnance is no factor for trim adjustments. I do this when I got a few heavyweights left on one side of the wing. An asymmetric landing can be quite demanding...

Just faced it myself yesterday. With Release Angle of >0° it works better, with RA 0° it's a below 50% chance. Several straight and level attack runs on a site, enought time for INS and TGP to stabilize on target. Perfect view, no obstacles or clouds, no hard banking and even managed to maintain a constant TGP fix on the target most of the time. GBU-12 and CCRP, what else. While in the attack run (straigt and level), the Dynamic Launch Zone bracket appeared, disappeared. Turning around (with sight on the target), the DLZ was suddenly there, then vanished without any reason and did not come back in time. If the DLZ was shown in the HUD, the bomb released almost 100%. Without DLZ it does not, of course. I was in the right parameters for the attack on the static ground target. I did 10 attack runs with perfect parameters and was able to release 2 GBU-12 which hit the target. Interesting fact and in contrary to the above said: Once there is a DLZ bracket you can release your GBU as long as the marker is in the bracket, no need for pressing and holding prior to the drop circle flashing but I have to investigate that a bit further so don't take my observation all too valid. No track recorded cause it was on a restricted multiplayer server and... I already did so much testing on the bugged CBU-97(fixed), bugged Maverick boresighting, bugged CBU-105 and now the GBU-12 that I am kind of fed up. Just fire up a GBU-12 mission in Mission Editor and check.

In 2D: In the cockpit, Cockpit Panel View (CPV) toggles between normal FOV and a closer panel view. There are some strange behavious if switching between external views and Cockpit and CPV, but ok. In 3D: Works the same as long as you aren't switching to external view. Once back in the cockpit (F1) view there is no CPV anymore. I don't recall if thes setting stays with the extended "zoomed out" view or the more narrow view closer to the panels. The CPV toggle / key doesn't do anything anymore. From what I think how it should be used apart from that it's broken: Normal view -> CPV -> Zoom -> Spyglass and you get 4 zoom levels. Current stable version used.

VR surrounding - so how do I map my mouse view in external to the mouse XY axis on my FLCS analog joystick? While the throttle grip's radar cursor joystick works as expected I can't find a DCS' input entry possibility for "Camera left/right", "up/down" and "zoom" for any controller other than the mouse (routed to MouseX, Y and Z). I tried to edit the .lua, but I just find keyboard.lua and joystick.lua, but I need to take a peek into a mouse.lua for the correct syntax. In "controller settings" in DCS the approbiate cells in the table are "greyed out", well, in fact they are in a different blue than in the mouse controller column meaning they can't be activated for any joystick device. What's the use of not letting the user decide what analog input they want for camera movement? How do you force DCS to accept the joystick's mouse as a system mouse? I don't want to use workarounds like "define controller's analog stick as mouse" etc like it was possible with the Warthog a century ago. Also I don't want to turn the analog stick into a simple 5 way hat with digital output. I want to benefit from the analog output.

Thanks, but Maverick thread was already there, CBU-105 also. CBU-97 was corrected with last stable patch. Maverick is corrected with beta before the current beta but there hasn't been a stable release for months.