Galinette

I have tried setting the UHF ARC-159 Function Inc/Dec binds on an encoder. It doesn't work : one bind does nothing, the other one toggles between OFF and BOTH The UHF ARC-159 Mode Inc/Dec binds (Preset/Manual/Guard), on the other hand, work as it should.

The Mirage is definitely way behind against fox3 aircraft. However, it's super challenging and rewarding. You have to rely on discretion (radar off, low level terrain flying in the mountains), observation (contrail spotting, RWR, AWACS messages) to sneak below ennemy aircraft, fast climb and shoot your missiles from behind/below. And leave the place quickly before another patrol spots you. You won't have a very good kill/death ratio, but that's way more fun than firing fox3 from 40nm.

I can confirm the bug is still there. I can relight after a manual in-flight engine stop, or after a high altitude flameout, but not after inverted flight.

Hi, I have a i7 6800K. The multiplier for 3-6 active cores is 40x and for 1-2 active cores is 44x. Base frequency is 100MHz. Now, when running DCS or another single thread app, the reported active core count is 1 and sometimes 2, never more. However, the "Max Core Frequency" reported by XTU is 4.00GHz, not 4.40GHz. Do you know what could be the cause? Thanks!

You can bind them, but it requires a small hack to the mod. The file is attached (open for instructions). This gives an axis for the UHF/VHF channels, and binds for VHF keys. At each DCS update, the default.lua file will be overwritten, you need to insert the three lines again. galinette-m2k.lua

I can confirm the FPM now moves diagonally with rudder input at 90° bank angle, instead of laterally. The bug is still there.

I can confirm this works now in the OB. Only the mouse wheel support was removed, which is somewhat disappointing, but at least the offset is now usable.

I wanted to try VR cockpit clicking with my Virpil grip thumbstick & thumbwheel. In DCS, you can set joystick binds for left/right mouse buttons, and wheel up/down. But you can't use the ministick axis for moving the mouse. So I made a small autohotkeys script for moving the mouse cursor with two axis. Now the analog thumbstick moves the mouse, while clicking on it is left mouse button. The wheel acts as the mouse wheel, and clicking on wheel is right mouse button. This gives full mouse control with the grip hand thumb. I don't know if I will keep this, but I share the script here for anyone interested. Joymouse.ahk

I've played with the excellent DCS Menu Nav autohotkey script, but it wasn't fulfilling perfectly what I needed: - Sounds somewhat intrusive - The OSD wasn't visible in VR so I had to rely on sound only - The menu doesn't contain all the F keys so the OSD can't be placed properly in all cases I did some heavy modifications/tests and ended up with a very simple script which just moves the actual mouse cursor to one of the 12 menu entries, cycles through it, and allows mouse click. So now, I have a clickable encoder, which places the mouse over the menu entries, and clicks on it. The mouse placement is likely resolution dependent, so you may have to tweak OffsetX, OffsetY and LineSpacing variables. Mine are set for a Reverb G2 at 80% PD. Enjoy! ComMenuMouse.ahk

No, the alignment is wrong in FS2020 which has direct WMR support. What I believe, is that other environment make you look at infinity less often, and some divergence strain is compensated by looking to closer objects. In flight sims, you are most of the time looking at infinity for long periods, and slight image divergence causes high strain. This is well known in the stereo/VR industry, having objects at infinity is avoided whenever possible as it's super incomfortable with not perfectly aligned hardware.

Now I'm very happy with my custom DCS aligment, I can play 3 hours without significant eye strain. I just tested with FS2020... after 15 min it was hurting due to divergence. So it does not seem a DCS issue. But G2s seem to be calibrated like ass.

I have found an interesting workaround, I put my binds in a separate file. Then, in default.lua, I only have to add three lines which will include the other file. My separate file is not overwritten during updates, just the include lines, which I keep commented in the separate file. Attached, an example for M2000-C and F14B galinette-f14bp.luagalinette-m2k.lua

Followup on my DIY alignment bench (I have improved it a bit, by letting the headset still, while translating the camera, on my glass desk, with some teflon pads for easy slide, and some wood blocks with strong double sided stops for the 67mm stop). The slight horizontal residual misalignment was, as the picture shows, about 75% of the diameter of the mirage 2000 FPM circle, in divergence. Divergence is quite bad, so I shifted slightly in/out symmetrically for right and left eyes, until I get repeatable results. We will see if I get less eye strain like this. I had to increase L_OUT and R_OUT by 0.005 and decrease L_IN and R_IN by 0.005. However, I'm afraid these values are very headset dependent. Little tip for fine tuning : by resizing the debug tool window horizontally, you have much larger sliders, and can reach 0.001 adjustment steps, which was about the size of a HUD line in my tests. However, there is still a problem with the debug tool for values below 1.0 like the G2 has. For adjusting these, you need to edit the lua file and restart.

HSI offset knob changes rho by 15nm steps (instead of 0.1nm) and theta by something like 6° Also, when changing one of those parameters (theta or rho) by some amount, then going to the other parameter, and changing it by a single step, the values jumps by a large amount. As if both values were changed at the same time when turning the knob, but updated on the HSI when changing it by one step. TRK attached hsi-bug.trk

Hi Razbam, Now, the HSI knob works both directions. But, it changes rho by 15nm steps (instead of 0.1nm...) and theta by somthing like 6° And, that's not the worst : when changing one of those parameters (theta or rho) by some amount, then going to the other parameter, and changing it by a single step, the values jumps out like crazy. As if both values were changed at the same time when turning the knob, but updated on the HSI when changing it by one step. In short: Before last update : HSI offset was usable, but if you needed to decrease rho or theta, you had to increase up to 999nm or 359° and it would cycle back to zero. Not ideal but worked. After last update : even if you are OK with not being able to adjust with more precision than 15nm or 6°, it's basically impossible to set a theta/rho offset due to the coupling between values. TRK attached... hsi-bug.trk

Same for any mod customization (such as new binds, etc...). Use OVGME to add/remove your customizations:: https://wiki.hoggitworld.com/view/OVGME

You could dim the lightmaps. This would not solve the difference between 0 and first crank being too large, but still allow for lower brightness. The brightest setting being useless anyway.

It has a bind, "Engines STOP" in "Engine & Fuel". I use it and just checked it's there and works. Unfortunately, only in the core folders. DCS stores modified file in a "Backup" folder when overwriting during an update, but you still have to restore it.

I don't give a s*#t the price, if they release a 2000-5 I pay it 80€ even if I have the 2000-C already

Dear Eagle Dynamics, My default IN values slightly below 1 and your sliders start at 1, so I can't adjust them, only by editing the LUA and restarting, thus making the process nearly impossible. Would it be possible to decrease the minimum slider value? Also, they are not super precise. Some +/- buttons for 0.001 fine tuning would be perfect. Cheers

After playing with the settings, I wanted to investigate a little more and do it more scientifically. So I did a quick & dirty bench, where I could translate the headset by 67mm without any rotation, and placed a fixed camera looking at the center of one eye. By translating the headset by 67mm (my IPD) the camera ends up on the other eye. I set up the camera to take two exposures with a 15s delay inbetween and merge them in a single picture. This way I don't touch the camera between successive shots. This is the first result with default alignment: And after inverting top-bottom: The repeatability is good, you get results consistent by about the thickness of 1 hud line. To me it seems clear that there was a vertical misalignment issue, and that inverting top-bottom fixed it. It seems there still is a slight horizontal convergence or divergence (the hud symbols should be at infinity, and thus matching) I will spend more time tomorrow trying to fix that convergence issue perfectly.

Hi, I fly at 1.0 pixel density, 4x MSAA

This probably means your headset is not properly adjusted. If the rings do not look correct at the center, but when looking on the sides, adjust your IPD until they look correct on the center. If they look correct when looking from up or down, move your headset vertically and adjust straps. The sweet spot looks small because the sharpness is awesome at the center. For a given lens, if the definition is poor, the sweet spot will look large, and if the definition is very good, it will look small. They have upgraded panels a lot, and not much lenses.

Basically, this tool allows compensating the panel alignment, by tuning the frustum for each eye in DCS. I believe the default values are retrieved by DCS from the VR API (Steam or Oculus) and have been factory calibrated. Misalignment, which causes eye strain, can be due: - To the factory calibration which wasn't done properly. In that case the DCS tool might be theoritically used for fixing this, but getting good values is extremely difficult without proper measurement tools. You might do more bad than good. - To DCS swapping some values because headsets/APIs have different conventions. In that case, the swap buttons might help I switched from a Quest, which was very comfortable, to a G2, and clearly the strain is much more present. HP might have some slight alignment issues.

Ah thanks!