RedX

Exactly the same here. Autostart option is corrected but the crash is still there after PC restart. Is it possible that it has something to do with the installation option "Everyone" vs "Me only" ? I used the "Everyone" option.

It seems that the crash is reproducible. The "USB reconnect required" was a different issue, I don't know why that was needed at some point and I can't reproduce it. About the crash: If I click "quit", the simshaker starter stops. If I click "continue", the simshaker starter keeps running, but: - start simshaker via right-click-menu or the UI button does not do anything at all - if I quit the starter and restart it, everything works normally Required to reproduce: - start simshaker starter - click "start when windows starts" in settings - restart computer - starter is automatically started - start DCS --> crash (simshaker crashes as explained above; DCS runs normally) Test case: no autostart with windows, just manually start simshaker starter - works normally Test case: autostart with windows, quit simshakers starter, start simshaker starter - works normally Test case: any start of simshaker starter - open settings menu, the tick at "start when windows starts" is always missing - no touching of the tick: if simshaker started automatically at last PC restart, it starts automatically again when PC is restarted, and crashes again - no touching of the tick: if simshaker was not started automatically, it will not start automatically when PC is restarted; manual start of simshaker and DCS results in normal operation - touch the tick: turn it on and simshaker starts with windows when PC is restarted; regardless whether it started automaticall at last PC restart - touch the tick: turn it on and then off, and simshaker does not start when PC is restarted; manual start of simshaker and DCS results in normal operation - whenever simshaker starter is quit and started again, the "start when windows starts" tick *appears* always to be unticked in settings Hope this helps. Regards, RedX

Hi, I encountered now 3 times (randomly) the following. It might have something to do with recent windows restart or newly started simshaker but I cant confirm that yet. -simshaker is started automatically with windows -DCS is started up and when main loading screen shows up, i.e., when the "simshaker starter" is supposed to launch "simshaker for aviators" (SSA), an error occurs -SSA does not start but .NET error message is displayed -software version 2.1.3 beta -"simshaker starter" halts when error message is displayed and exits if I click "quit" -latest DCS version, Windows 10 Home FP 2004 I wonder what's wrong ("cannot find the file specified"). EDIT: The JetPad is not found by any software until USB cable is disconnected and re-connected after the error above. After that, it seems to work normally. Yours, RedX The full error message is below.

The same happened here. The cable is standard ethernet but has quite poor build quality.

Hi, the SimShaker (for Aviators beta v2.1.2) starter/settings window does not allow "start when windows starts" to be turned on. What's the best solution? Simply drag shortcut to Startup folder or adding registry key to ....\CurrentVersion\Run ? Thanks. :helpsmilie:

Just pulled the trigger on one of the seats at Andre's. As an engineer, I like the fact that the measures and even tolerances are given :thumbup:. Correct me if I'm wrong: it seems that the internals and electronics are identical for all three versions of the seatpad. Thanks to a spacious "controller's chair" and no need for a joystick cut-out, my choice was the regular model. DHL reported shipment pick-up within <12h of placing the order. I'm impressed! :notworthy:

ModManFX gives an error when trying to click "Install Mod" button. A small popup is displayed with title "AutoIt Error" and message: Line 27223 (File "C:\MODMAN\ModManFXv1276\ModManFX64.exe"): Error: Variable used without being declared. Weird thing is that it used to work a few weeks ago. I wonder what changed? *EDIT* Doh, my bad. The error occurs only if no mod is selected when trying to click the install button. :doh:

Getting dev time is *always* difficult. :-D we all know that, like when you phone a service number of almost any major company and hear the recording: "we are exceptionally busy at the moment, please wait or reach us through our website" or something along those lines. I've never heard them being exceptionally available to serve their customer at the moment. :-) Everything is a question of priorities. In personal life, business, relationships, etc. I personally would embrace that those priorities were publicly and honestly displayed, as it would mean less practical guesswork and more trust. My current view based on all I've read here and elsewhere is that the NS430 module is practically abandonware and I have no trouble with that, just moved on. Good to know. Obtained the Syria map, for example. While it currently is an FPS murderer, it's clearly actively developed and optimized - in contrast with e.g. the NS430 module. Sorry for the possibility of sounding like a rant here, not intended. Just tried to state the obvious.

Hmm I actually considered buying this module for C-101 but if it has major issues for 2 years it is an instant no-go. Well, world is not perfect... new modules are unfinished and old ones get little maintenance. I should've learned by now to stay away from any older modules... it's only that a lot of them would be fun and something new if originally missed at the time of their launch.

Hi, The F-14's ACLS or the automatic carrier landing system does not work properly. The guidance for the system has wrong height or something, resulting in the F-14 starting a dive and crashing into the sea when ACLS is activated in the final of the landing procedure. As if the carrier would be below sea surface. BR, RedX

Tested yesterday, 2.5.5 -> 2.5.6 is 45fps -> 15fps on most multiplayer servers, i.e., servers with more than a couple of people and AI units. And this is with overclocked 9700k + 2080Ti. Not great, guys. I've bought 2 other VR games so far because of this, spending less and less time flying. Why not just to revert any performance-related changes since 2.5.5 and redo from scratch with performance in mind? This is about to be the route of lesser pain than trying to stitch up whatever was developed for 2.5.6 as it clearly does not work performance-wise. In general, there are complete reversals of beta branches in the history of software development with succesful results.

Uh oh. Still can't see the ground with landing light from 30 meters away while there's a great dancing party in the back when flying at night. The Argo campaign is impossible.

I have tried and my subjective experience is that the ghosting is reduced when fps reaches 60 compared to 45 fps. Probably thanks to shorter prediction time interval. However, fps value jumps around from 60 to lower values and back dynamically and drops on average to lower values. Perhaps the dynamic switching takes some computation time. Also, I found that it was more steady and comfortable to have 45fps most of the time using "force half frame rate" option with 90hz setting than suffering highly variable 40fps-60fps as half or one-third of 120hz. This is subjective and with my detail settings..

Hi all, Here are my experiences on the misalignment issue. Short version: Launch DCS so that the alignment debug tool window shows up and swap the TOP and BOTTOM values for each side; don't mix left and right side values or make any other changes. Try it out and if it works you're good to go. --------------------- Long version: There may be some errors or inaccuracies in the explanations below. Feel free to correct. Each headset is calibrated at factory to some standard viewing position i.e. nominal eye position and the calibration values are saved. This is performed using a fixture with machine vision cameras, I believe. Essentially, the measured calibration values tell how to shift the image on the headset in order to compensate for the inaccuracy of mechanical placement of the displays during manufacturing. SteamVR and other software read these values and use them to shift the drawn 2D images in the early phase of image creation. If the image was shifted at the headset, some margin at the edges of the displays would be required and that margin would mean either black edges or extra computation time needed to generate image on areas that will not be displayed. Now, some cross-eye effect may result if a person has slight variation in his eyes from the nominal. For example, the height of the eyes may not be the same in real life but the headset calibration must assume that. The option to freely adjust all of the calibration values for DCS may allow one to correct for this. I'm not sure since I didn't have the need for that. However, DCS seems to have an additional issue with image alignment but it is difficult to tell precisely what it is, since we all have different subjective ways to react and tolerate visual imperfections. My experience is that the cross-eye effect is mainly due to vertical misalignment. My method to verify differences and eye misalignment in particular is first to check that the steamVR basic screens and lobby seem ok by moving around and grabbing or touching immobile objects near the edges of the play area so that I can "feel" whether the steamVR "chaperone" boundaries move/stay in place in sync with my muscle memory / motorics. I've done this with 4 Rift headsets, VivePro headset, and 2 Index headsets. With IPD correct it was pretty ok for all the headsets I've tried. If this step is ok for you then any remaining misalignment issues are most likely with DCS. I have tried the DCS misalignment tool ("force_cross_eye_recovery_tool = true" in autoexec.cfg) using only two Index headsets since I've returned or sold all the others. Both Index headsets are corrected for the cross-eye effect in DCS in exactly the same manner despite them having entirely different factory-calibration values. By sitting in the cockpit, headset on, steamVR chaperone permanently on, and moving and tilting my head around, it is possible to check whether the artificial lines and patterns generated by steamVR software match the cockpit knobs, dials, panel corners etc. in the 3D visual world. The chaperone lines either seem to stay put or seem to drift / move as I move my head around. Head roll (like roll with airplane) while looking down at cockpit instruments seems to be very good motion to reveal mismatches of the 3D worlds between steamVR and DCS. By default they don't match for my headset and therefore produce the feel of the cross-eyed effect. On both Index headsets the match between SteamVR and DCS 3D worlds happens if I just swap the top and bottom numbers of the calibration for each eye in the DCS tool. Each headset has it's own set of values and therefore using someone elses numbers usually won't help. All in all, this suggests that there is a tiny bug somewhere in the software where it reads the calibration values for the headset but I can't tell for sure. There may also be the same issue with left and right values, but that is trickier to observe. Our eyes are quite efficient at self-adjusting for sideways misalignment automatically without us noticing it. For world scale adjustment I use the steamVR option IPDoffset instead of the adjustment in DCS VR options screen but that is basically another topic (Steam\config\steamvr.vrsettings, option "ipdOffset" : <number>, <number> = 0.063 - <your real-life IPD in meters>, e.g. my IPD is ~69mm --> "ipdOffset" : -0.006 ). The reason is that it applies to other games, too, in addition to DCS. I hope this was not too confusing and helps you out.

I have no idea, sorry. I dont have access to Pimax gear.

Jester menus are not constant. It would help if only the first menu would be situation-dependent and the rest would have just placeholders if a function is inactive instead of shifting the positions around (the deeper menus). Same goes for radio menus. They are inconsistent across different airframes. This makes it a pain to program my own custom VoiceAttack sequences either replacing or in addition to Viacom.

+1 TOViper has solid ground in his arguments. He's got all my votes on this. Jester menu should be possible to absorb in muscle memory. The changes required are basically choice of display order logic only. Constant menu choices would also allow things like VoiceAttack commands to be programmed in.

I tested vive pro long while ago for a month and my direct suggestion to everyone is that do not buy it, unless the price is somewhere between laughable and ridiculous (very low). Better alternatives have become available in both bang-per-buck and high performance.

Trying to solve the misaligned eyes -issue by using the debug tool provided gave rather good results but not perfect when simply copying the settings of one eye over to the other and saving the conf file. I think that I found the solution / bug (?) at least in my case after trying to figure out what exactly to tune in order to make things truly match. Now I have minimal eye strain and practically no need to adjust the IPD setting in DCS VR options menu. The best values I found by experimenting are reached simply by just resetting to defaults and swapping the top/bottom screen edge values for both eyes. After that the DCS display matches perfectly with the SteamVR and overlay displays. Note that the perfect matching requires for me that the forced IPD adjustment is clicked off in DCS VR options. See attached screenshot. Note that this is for Valve Index. Apparently the calibration values carried by the headset are reported with vertical limits in reversed order (or DCS reads them reversed). This might vary from headset model to another, as many people have no issues with misalignment. Alternatively, maybe only some of the headsets have sufficiently asymmetric calibration that it gets messed up noticeably. (I'm just speculating here.) In case of remaining IPD mismatch, further tweaking may be possible by changing both DCS IPD setting and the screen edge values synchronously (or maybe not). Or perhaps something in steamvr. I did not pursue this further as I'm within 1mm of the DCS default IPD of 70mm. My current good configuration was found and verified by turning on the steamvr boundary (i.e. chaperone) and setting the view centerpoint / seat position so that the chaperone seems to be sitting on some detailed feature of the cockpit. 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. Hope this helps. EDIT: Late note for anyone who found this post by googling etc. The short version is below: All I'm doing nowadays is the following. First, I use the cross-eye tool (add the line in the above post to autoexec.cfg in Saved Games\DCS\Config), then click "SWAP TOP AND BTM" on both left and right, and then click to save the config file. Now DCS will not ask for it again. Second, I've adjusted the IPD to match my eye distance in real life in SteamVR's settings in C:\Program Files (x86)\Steam\config\steamvr.settings (default location). Of course this second part does not work if you don't use SteamVR. In any case, the line to change is near bottom: "ipdOffset" : -0.0064999999999999997, The value is difference of your IPD to 63mm in units of meters. E.g., in my case my real IPD is 69.5mm which is 6.5mm = 0.0065m more than the default (63mm = 0.0063m) so I enter the figure -0.0065 (larger -> negative value) here. Someone with 61mm real life IPD would enter the number 0.002. Steam automatically rounds the value to some multiple of something, it does not matter (that's why so many figures "9" in there). At least in my case everything matches after that and I can keep the custom IPD option in DCS options off.

Oh great, that one seems to work for Index, too.

I decided to put up a separate thread for this issue as it seems that it should be fixed for the Reverb (latest Open Beta patch notes mention the fix). Unfortunately, the issue is still there for Valve Index, at least in my case. I tried clearing the fxo and metashaders2 cache folders and a lot of other settings but it doesn't help. I believe it causes additional eyestrain that is quite uncomfortable. It goes away if I switch to another title, e.g. Onward. It is of course difficult to rule out eyestrain due to lower FPS in DCS (45-60) compared to other VR titles, but I get a feeling that there is extra fatigue due to difficulty for the brain to try to adapt to the vertical misalignment of DCS view. The issue is well described here: https://forums.eagle.ru/showpost.php?p=4010656&postcount=6

The weirdest thing. I could replicate exactly the same in multiplayer. However, at one point, I was able to eject with a sequence [jettison canopy - F2 view - eject] in both MP and SP and after a couple of other tests later that no longer succeeded in ejecting the pilot. The difference was that if canopy was no longer there in F2 view, the eject was succesful. In the unsuccesful attempt, the canopy was again in place despite the jettison a couple seconds earlier in F1 view. Track files attached. Multiplayer.zip

Ok after testing with Instant Action mission, I concluded the following: - ejection using eject button x 3 does not work - ejection with canopy jettison + eject button x 3 works, provided that: * eject button is not clicked before ejecting canopy * other views than F1 cockpit view are not used at all (going back to F1 does not help) - canopy jettison works in F1 view - in outside view e.g. F2 there is ejection animation but canopy stays on the plane; when returning to F1 view the canopy shows as jettisoned I did not test ground take off or cold start. Track files attached. This should help in pinpointing the bug. Tracks.zip

Sometimes I am able to eject by jettisoning the canopy first. And it seems to make a difference whether I'm using F2 or F1 display (outside or in cockpit) regarding both the animations and whether ejection actually takes place. (I'd actually prefer single click ejection, i'm too slow to repeatedly click 3xeject. But that's due to ED, I guess.)

RedX UH-1H