zerO_crash

AviaStorm/SVK-version I have to admit though, it seems that the project is very much dependent on what AviaStorm ultimately decides on. I don't really see such a complex aircraft be produced to a higher standard than a mod by one person. Considering that in the ever updating virtual world, you'd have more bugs introduced with each update than you'd be able to fix. Then comes the actual coding. Consider that Leatherneck back in the day was an actual team (all the internal affairs aside), and MiG-21Bis still had to be rebuilt pre-launch, as graphics and certain systems turned out to be obsolete by the time the module was ready. Speculation aside, let's wait and see. However it would be a lucrative contract for AviaStorm for sure!

Nice! I remember seeing it as being a mod, but wasn't aware that this might turn into a full-fledged module! In that case, I suppose two different models of roughly the same aircraft are currently in production! For clarity: - OctopusG would appear to be making an earlier variant of a Su-17/-22 based on the cockpit images. - AviaStorm (if it takes on the project), seems to be making pretty much the last complete interation of a Su-17M4 (Su-22M4 for export). It would be most modern one. Good stuff!

Splendid stuff! Keep it going, definitely a piece of art!

Hi there, You are asking the wrong dev., it was "OctopusG", not Magnitude 3 LLC that posted pictures of a Su-17/-22 Considering that the module doesn't even have it's own subforum yet, I expect it to be a good couple of years away. Nothing to worry about though, once it's out, I'm sure that it'll be up to the standard. Cheers!

This exchange is irrelevant becuase your recommendation is completely off. It was "ME" who stated that the manuals do contain errors and poor wording, never claimed it came from you. If you´ve ever seen a real aircraft manual, you´d notice how much essential info is missing. Furthermore, in certain cases (subjects), the wording leaves a room for interpretation, which is not too good. One example here being simply the fact that a whole section on trimming alone is missing, which is a must in pretty much any aircraft. The topic is simply too important to convey it in simplified 2-3 page text. Read again what I wrote, those are not fluctuations due to maneuvering. I made it pretty clear! We derail, becuase you, recommend something against the manual and logic. You are "helping" by introducing a faulty recommendation. I´ll double check magnetic variance (due to nearby objects), however magnetic variance due to the helicopter itself has been, and is modelled. It has been there ever since BS2 - manual 6-52. By default, the helicopter has magnetic variance which will introduce fault into the INU-alignment. Case closed!

Well I´ve been on since LOMAC, so don´t worry. As to the manuals containing mistakes and poor wording (in certain places), there still is a logic to certain aspects of them. Typically, if a feature is not implemented, they state so. They also don´t typically mention effects, which are not implemented. Rather, I've seen the opposite - lack of description regarding dynamics/systems/features that have been implemented. I have personally seen compass go off at times in certain modules (MiG-21Bis, Mi-8MTV2/Mi-24P) (not due to heavy maneuvering). I´ll have to check it once I get my new PC, but I don´t see anywhere in the manual that this feature is not implemented. Again, notice, it states "can", not necessarily "will". That´s the simulator-side of things. As to IRL, depending on how you treat the simulator (makes little sense to treat it as a "game", but do yourself good...), it´s mostly logical to actually adhere to specific habits/norms/rules with regards to authenticity and actually learn what is proper. You could abuse current bugs/issues in DCS to your advantage, but then it makes very little sense then to run a simulated environment. Just because e.g. MiG-21Bis had an issue with the radar where flying upside-down made it not present any ground clutter, didn´t mean you should fly it like that either.

There don´t have to be any large metal objects, in fact, objects of any size that are metal will cause interference. Whether it is an APU-cart, a truck or a car for that matter, they all will potentially affect your readout. Manual section 9-20, read the "NOTE", hence, it IS an issue. Apparently, magnetic interference is indeed coded in and will indeed interfer with the compass/alignment. That´s why it´s important to get correct info out there.

What is practical is highly dependant on the situation. On the ground, you should use the manual method, rather than the magnetic one, as different metal objects nearby as well as visual obstructions will indeed alter the magnetic reading as seen from your position. It is therefore something that you have to chose on a case-by-case basis. Manual can only be performed on the ground, however it gives you a correct readout. Magnetic, can both be performed on the ground as well as in the air, though on the ground, as stated before, it will be subject to interference from primarily metal objects around, resulting in erroneous readout.

What VR-headset do you have?

I don't fly the others, physics is a prime aspect for me, thus I cannot settle for the lack of "inertia" in the other sims. I hear that MSFS2020 has its problems as well. I cannot compare it to the others. Still, I am not comparing DCS to other simulators, as that's an invalid comparison at best. DCS has much old code, as such, you cannot really compare it to something that came out in 2020. What I am getting at, is the decreased performance in DCS from one version, to the next. I know ex-SithSpawn has mentioned that there were some changed introduced in 2.8. which will worsen performance, and that is to stay (I assume it's essential to the core). ED will have to respond properly to the issue of optimization, that's why I give them time. However, it's important to make it clear that currently, the performance is not where it should be. Vulcan isn't the easy answer either, as there are currently severe issues with proper allocations of threads, tasking and the general coordination between CPU-cores. Some have no issues (consider it a bonus), but the attention will have to fall on those that have problems. A simple thesis which will support the above, is as follows: "There is currently no hardware, which will bear with the lack of optimization or load of DCS currently, at an acceptable framerate." (VR). That alone, is undeniable, and we know that getting a beefier GPU for example, is no solution at all. Especially since there are people here with i9-13900KS (6GHz out of the box) and 4090TI, who are getting subpar performance. Again, it's a basic example, but it proves the point. I'll wait and see what they'll figure out, but the fact that the simulator remains so inconsistent in terms of performance, is not really something they can blame on "other software". The sim is way too delicate in its current configuration. When we get this solved, it's already going to be the best commercial military aviation simulator out there.

"Its normal for people not to like things they don't understand." - (*It's - It is) That statement is not pointed at me. You clearly misunderstood what I wrote. I am fully aware of how different VR-software correlates. I have never mentioned OpenXR Toolkit as a standalone. Re-read what I wrote; "OpenXR" (as a whole component). The reference to OpenXR Toolkit, was because a member mentioned that "Turbo Mode" could help. The problem is that after DCS started forcing OpenXR (it was there before, but for example DCS MT, will not start natively in SteamVR, even if you set that runtime in Steam. You need to add the shortcut suffix in order to force it in SteamVR), it simply doesn't present any good results. There is lag, there is stutter, etc... The problem with DCS, is really that atm., it is too "delicate" on the system. You can run other software (applications) on your pc, which won't have any problems with performance, regardless of the magnitude of other software you might have installed. You mention it yourself, you have two computers, which with some similarity, still have to be configured completely different (settings-wise), in order for DCS to run properly. There is neither any logical explaination, nor a systematic to what you should enable/disable for it to run well. That is precisely the problem that I am describing above. If your Office worked like that, no one would use it. If your games worked like that, you wouldn't waste time on them. The question is; why is DCS so sensitive to systems versus other software in general? Mind you, I reinstalled windows 10 and 11 two times (once each), and with no other apps than in the windows 10/11 "Pro"-version, it still didn't run properly. No amount of tweaking made it work anywhere close to what it used to back in 2.6./2.7. I am talking about ST/MT, not only one. Worse yet, while it performs well in 2D, switching to VR becomes instantly PowerPoint. If synthetic benchmarks are anything to go by (which they are), as well as other software, my current pc is as healthy as it get's, so is my system (software). Everything that I currently have on my pc, works even faster than before, yet DCS has taken an inversly-proportional course over the last couple of updates. For analytical-me, that is a proof that it's DCS that has issues, and not my system. I am in general very careful with making decisive interpretations, however here, it is clear as day. I have tried anything between physically changing RAM (again, everything else works splendid), to going through different BIOS-settings and finishing off with reinstallation of OS, topping the cherry with different settings (system + DCS). Nothing. Same performance as before. The fact that I get around 60 fps stable, with absolutely everything on lowest settings (every single setting you can choose, except pixel-density in DCS (tried it at anything between 0.5-1.0), is ridiculous. Running the headset through SteamVR with native VR resolution (tried lower as well); 1.0 in DCS and 50% in SteamVR (that corresponds to native image resolution for HP G2, no upscaling involved), it still yields 60 fps maximum. This is just completely wrong. The issue is with DCS VR, that much I know for sure.

I am not too fond of OpenXR. Whilst SteamVR might have cost a couple of frames earlier, it was overall a smooth drive without artifacts. OpenXR, is more about testing, than actually having it work. I personally cannot understand the point of settings like "Turbo Mode", which while theoretically giving you better FPS., don't alleviate the issue of frametime (more, does not mean fluent). Furthermore, the glitching it introduces is astounding, seeing artifacts that resemble multiple magnifying glasses around the screen... There are options which are cosmetic, and at user discretion, however this is not one of them. Overall, it's a weak software in my mind. Whilst HP G2 seems to be a good VR-headset, the software on the other hand, falls short. I never had any of these issues with Vive, it simply worked out of the box. Granted, DCS has severe issues with performance right now. Still, it's a complete mess with the software. It doesn't help either that Windows 10/11 has had its fair share of performance-issues related to VR, I won't even mention WMR... As to DCS, I give them time. This is afterall a beta-build. The problem isn't really that there is such a wide margin between performance increase/decrease that users report. I can understand that optimization is needed, as such, certain hardware will underperform until it get's optimized. The problem is really that there is no logic with regards to whether DCS will perform or not. You might as well throw dice as to DCS. People with the same operating systems (clean ones), and the same hardware are reporting widely different results. As such, getting a top-of-the-line pc doesn't even guarantee you the desireable outcome. That is the main issue. Why is the software so unpredictable in its current configuration?! It used to be better before. I, for one, am not a fan for changing system-wide settings because of one app. I am firm a believer, that if other apps work without issues with default settings/setups (given that your power options are set for performance), then DCS should too. The moment you need to edit your registry, or change other peculiar settings, is the moment I'll state that the software is bugged, end of discussion! I have gone through a complete Windows-reinstall (ED got more from me than Microsoft-support could ever get), and nada. Same lack of performance. "Turbo Mode" is not going to fix that. The devs need to do it! I am a very patient man, I give ED the benfit of time.

The new update causes even more performance loss (HP G2): Empty mission, only a Ka-50 BSIII with loadout hotstarted (for testing) on the ground: Before (DCS 2.8.3.38090 Open Beta): ST: 30-34 fps (F2-view - 48-60 fps) MT: 28-32 fps (F2-view - 38-45 fps) Now (DCS 2.8.4.38947 Open Beta): ST: 28-30 fps (39-45 fps) MT: 18-22 fps (31-38 fps) I still get "CPU Thread Bound" flickering in the performance monitor. DCS has gone from unplayable (cannot fly like this), to PowerPoint. That is very mildly said. Furthermore, like the last update, with anything vanilla (fresh installation - never used any mods), multiple complete repairs ("slow" & "delete all unnecessary files"), DCS ST still starts by default in SteamVR, whilst DCS MT starts in OpenXR... Why is there even a difference?! dcs.log dcs.log.old DxDiag.txt

I am pretty sure that cockpits are all up to scale, if anything, it’s the pilot models. If the cockpits would be out of proportion, so would the module. If the modules would be of incorrect size, then you’d see it very clearly with regards to other modules (given that the misproportion was big enough). Besides, when it comes to modules, both in- and out-side, developers adhere to metrics obtained from IRL aircraft (3D scans mostly). It’s not impossible, but highly unlikely. As such, I assume it’s the pilots themselves.

Definitely, it would of course be better if they at least had randomized body-features and metrics. Again, that is assuming this is intentional.

It would almost be too generic to have them the same size. Actually, it does make up for some realism to have different heights, bodies and proportions, whether intentional or not. I'm not sure how big the margins were for pilot sizes though. However, back in those days, the absence of comfort was the norm. As such, as long as you could fly and reached all controls, I imagine that there were no objections to letting either a "kid" or a well-fed joker fly.

The size seems a bit off, however it isn’t complete wrong. Due to multiple reasons, one of the major being that people had to work hard physically from an early age (carry heavy items), most had impeded physical growth. Another being genes. It sure seems like a correct aspect to model. Less access to food being yet another one. A perfect place to visit here, is a museum of arms & warfare, or history of clothing & apparel (textile art). The earlier back you go, to smaller clothes you find. I have on many occasions looked at preserved officer uniforms from e.g. baroque-era, and was surprised at how small people used to be. In many cases, the size of the aforementioned chest, would be a bit thicker than a man’s upper hand nowadays. Granted, WWII has more similarities, however still, differences can be seen.

No problem brother, sometimes it might be difficult to find the culprit of a longstanding issue. It´s my pleasure to help. Take your time, figure out the F-14, see how it goes. Join Discord on this channel: https://discord.gg/szqaJE7 There is a Brunner section lower, there is actually a guy talking about pulling out his Brunner and having issues with F-14 (I imagine it´s you?). When I get my new pc, I´ll be getting my clan ready and invite people from Brunner as well. One does join a family when owning a Brunner. Tell me if you get it figured out, until then, good luck, and fly high! )

Everything works correct, the "Force Feedback Tune Panel" essentialy let´s you tune two things, the "Trimmer Force" (the force that is required to hold the stick in place - thus "Trimmer Force", and "Shake" (Shaking which occurs during high AOA-flight and other regimes of flight, in certain cases, weapon firing (guns)). The other three things it lets you adjust, is axis swapping and inverting. It´s logical that when you turn down the "Trimmer Force", get no stick movement and lack of force of the stick, as you pretty much disable the general force of the stick. I always put my forces at 100% "Trimmer Force" and 100% "Shake" to have maximum effects and a stick that replicates a real one (in terms of force needed to move it). As to the FFB, it seems that everything is working on your side. I cannot check it right now, as I have framerate issues (and general performance) since 2.8. Besides, I´ll be getting myself a new workstation-level computer soon. With that said, while I have all the modules, I (being partly Russian), fly practically only Russian aircraft, only a few western ones (Ah-64D and Mirage 2000C-5. I have flown UH-1H, F-16, F-18C, and some other before, but not anymore). Thus, I cannot really give you any specific feedback on what it might be, however, your stick seems to work properly. With that said, I have jumped a couple of times into the cockpit of F-14A and B to have a look at it and some new features, and my stick was perfectly center (hot-started on the ground). I will voice this, go through your DCS-settings and make sure of the following: - No curves are set up, you should have pure linear input. - DCS is setup with "Simulation" settings, physics specifically. - "Special" settings of each module that you fly (make sure automatic trim is not engaged for example). Also, make a copy of your "saved games" folder, then delete it. Let DCS create a new one. See if it persists. Finally, go to the specific module forums, and start a thread with regards to this. As said, it sounds like it is working properly for you, I am 100% sure of it. If anything, it´s most likely a system in the module or mechanic, that displaces the stick. When you spawn with a module in air, it will be trimmed for that flight level and speed. Hotstarted on the ground however, it will be neutral with controls (trims, etc...). I know for a fact that Mirage F1 has had some initial trim faults (cold aircraft had wrong trim setup), however other than that, it has been correct with pretty much any other module. If you still don´t get it to work, tell me, and I´ll get you over to a Discord channel specifically for HOTAS and Brunner CLS, where I´m sure that you´ll find other Brunner owners who actually fly western aircraft. They will give you input on what it might be. However, I´ll state it again, your setup is working. This is most likely a system/mechanic or setup-thing with the aircraft. If FFB works with one module, it works across with other ones. Thus, focus on the module, rather than your FFB. Aircraft will react differently with/without AP, thus you will see different behaviours with different systems engaged. That´s how real aircraft work, obviously. A Ka-50 flies completely differently with Flight Director engaged, vs. without. You can even trim it differently, because heading hold won´t be engaged (angular stabilization still "on"). This, just to give you an idea. That´s what´s so great about it. Realism for life! One last thing, zero out the trim in your aircraft (set all trim-tabs to neutral), use your in-cockpit instruments to verify that they are neutral. If the stick is centered, you know that it’s a aircraft mechanic.

Brunner USB Tool is only for changing stick mode, FFB-customization, and some other utilities. Brunner is self-calibrating though. Reset the custom calibration that you set to "default". Then, power-cycle the stick. As it recieves power, it will auto-calibrate on each axis (don´t touch it, or shake the base/table during the calibration, it needs to be perfectly still). As soon as that is done, all works as desired. I didn´t have to custom-calibrate mine, and all modules work splendid (I have all modules in DCS). I imagine that your custom-calibration is the root of the problem.

It´s really to make sure that nothing else interferes with the Brunner (in theory, as long as you don´t run BrunnerDX, it shouldn´t interefere). So the only thing remaining then, is your stick changing its centre when you join a module, correct? If so, are you joining hot-started modules, or cold? Also, the default spring-centre of the stick (desktop, DCS main menu, etc...) is in the middle, however, it´s when you join an aircraft, that the centre displaces forward, correct? You don´t use any curves, or? Can you still trim to each maximum without peoblem? (You let the stick calibrate itself, without touching it, correct? You are not using the Windows calibration tool, or?) I will also add; make sure that there are no other conflicting bindings on the given function. Check pretty much everything. If this doesn´t work, delete your DCS-folder under "Savedgames". That will reset all your keybindings (a new folder will be automatically created when you start DCS), but it´s worth a shot.

We are practically there: - Did you use uninstall BrunnerDX? - Did you use the USB-tool (second download) to set the stick in in DirectX-mode? In DCS, all modules have reverted FFB-axis. You have to find out which ones though. First, trim up and down (find correct setting), then trim left and right (same here). You should at that point be good to go with correct-working FFB.

It doesn´t find a valid firmware-file to update, which is somewhat weird, but no problem. It does detect your stick obviously, thus I´d get right to opening a ticket. Go to Brunner´s website, and at the bottom-right of your screen, you´ll see a blue support icon. Through that, open a ticket. Brunner is usually quick at responding, so I imagine that they´ll solve it quickly. Attach the log_(date).txt file from the "log" folder (The one you posted a screenshot of) when you create the ticket. I imagine they might send you an updated firmware. https://forum.brunner-innovation.swiss/forums/topic/firmware-yoke-joystick-rudder/ EDIT: Reconnect the stick to a different USB (and power-cycle it - disconnect/reconnect). If that doesn´t work, then I imagine it´s the units library not recognizing any valid firmware. In that case, Brunner will send you the proper files to deal with that.

No worries, all good brother. Not all the issues are listed in that thread. I did help a couple forum members with setting up their Brunner-hardware outside (email correspondence) and not all had the same issues. First and foremost, the "official" software worked splendid, absolutely carefree. You installed CLS2Sim, made the tuning that you so desireed and off you went. However, there were no FFB-effects in the sim and trimming of the actual stick was handled by CLS2Sim. As such, there was a discrepancy between the trimmed aircraft and its autopilot vs. the actual physical position of the stick. Those two would simply not overlay properly. Furthermore, there were no FFB-effects such as rumble, increasing control stiffness relative to speed (WWII prop, and other non articulated aircraft (Hydraulics/FBW). The obvious solution then, was to somehow get a software that would translate DCS's DirectX FFB-output to the stick by the use of CLS2Sim (only interface to the stick and it did not support DirectX). Therefore, the solution with Arduino (thanks to Chuls), acting as a translator to get those effects, and correct trimming with regards to the simulator output of each specific module. Digression - because of lacking native interface (back then) between Brunner's CLS2Sim and DCS, using the trim in DCS (without the Arduino-solution), you would trim the aircraft in DCS, however the stick wouldn't move. If you used CLS2Sim, then you also had to use its keybindings for so-called "physical trimming". That meant that CLS2Sim would actually move the center of the stick, instead of DCS. Now, even if you bound the same buttons inside DCS and CLS2Sim to the same trimming-scheme, CLS2Sim would either move too fast or too slow, depending on the aircraft. Furthermore, aircraft with heavy autopilot reliance did not recieve proper autopilot input, and as such, excessive amounts of trimming-errors were accumulated (unacceptable). Arduino, came and fixed that by, as mentioned; allowing DCS's DirectX to interface with, and affect, Brunner through the CLS2Sim (For the record, the sheer amount of software and basic understanding of why you needed it, is what threw most people off - esp. considering the price of the product. When you pay a melon for hardware, you expect it to work plug-and-play.). While the solution was perfect in essence, some minor imperfections remained: - You couldn't let go of the stick quickly, or touch it accidentally (bump into it), as that would bring a perfectly trimmed stick into an ever expanding oscillation, resulting in violent pendulum-like motion hitting the opposite walls of the base. Not everyone seemed to have this problem, but some, me included, had it. As such, you always had to "delicately" (by my standards, that is hairline-fine) let go of the stick, so as not to induce the oscillation. - Upon ejection or crash-landing, the stick could lock up in a maximum force condition. This was not serious though as typically going back to main menu or even selecting a new aircraft (from my testing), would fix it. There were some other smaller ones, however they mostly got fixed with later iterations of the BrunnerDX-build. To be quite honest, Chuls is the man! The fact that he managed to build such a universal and well working app (nevermind the small quirks), is insane. It was simple in use, it was simple in maintenance and generally simple in installation, with the only "if" being reserved to windows and its buggy nature. Now however, you don't need the Arduino and BrunnerDX anymore. As Brunner has recognized, DCS-community is generally a dedicated community which is willing to shell out for hardware in the name of science, and aviation. As such, DirectX is now natively supported by Brunner-hardware. It fixes all of the aforementioned issues, also those not mentioned (due to their inconsistent nature), and makes the Brunner the ultimate base. If you are serious about flying, this is the way. Now, you use a Brunner tool which is called "Brunner USB Config" to put the base either in a DirectX-compliant mode, or CLS2Sim one (XPForce, etc...) (This changes the HID-number of the device; keybindings and settings of it will have to be reassigned). Once the base is set in either mode, the onboard controller "remembers" it, as such, you only have to put in the specific mode once, and you are done. No need for the tool anymore per se, unless you fly other sims than DCS. For DCS, you don't need the CLS2Sim anymore either. It's complementary at most, but you won't use it. In the tool, you can alter different FFB values, however from my experience, it's plug-and-play. It gives splendid results right "out of the box". No need for any tweaking, its cosmetic as such. Here is the page for both the newest firmware, as well as the tool (use the hyperlinks): https://forum.brunner-innovation.swiss 1. Update the firmware of your device. 2. Use the USB-tool to set it in the desired mode. 3. Enjoy proper trimming and FFB in DCS.

I’ll try it, although I already lowered the OpenXR resolution to 50% to accommodate the 1.0 Pixel Density in DCS. Essentially, I did it in the app, instead of DCS. The problem persisted. I’ll reverse it, and see if it helps.