ShuRugal

"Count yourself lucky"? The Ka-50 is the original DCS module. without the Ka-50 module, there would have been no A-10C module, and without the insane popularity of those two together, there would never have been World.

You could probably also set the airport stock levels for munitions to 0 and put fuel and ammo trucks where you want players to actually refuel/arm.

It would work by ED dedicating the resources to add a 3D rendering capability to the mission editor. Or by ED adding a unit-placement capability to the "prepare mission" feature.

without a track or a video, it's hard to say for certain, but unless you are adjusting your cyclic to maintain the ROTOR DISK in the exact same attitude through your turn, i'd guess that you're bringing the edge of the disc up as you turn, and consequently gaining lift. Keep in mind that the rotor is mounted with a slight forward cant relative to the fuselage. This is to keep the helicopter at a comfortable attitude while in forward flight. if you yaw the helicopter through 180 while keeping level as indicated by the artificial horizon, the rotor disc will behave as if you had moved the cyclic in a 180 degree arc around center.

Cuts engine power to idle. Note that the manual says this is not implemented.

It's certainly proving to be one of the most read-proof documents i've ever heard of. Clearly there is one solution: we need the WarThunder community to get interested in the Mi-24P. the DCS Mi-24P manual will be leaked on the WT forums within days of that happening.

thanks, that answers my question!

In this image here, it shows a hair over 250 MPH IAS? Is that the speed you were flying with WEP engaged? I know that the Mustang will overheat at max power if you're below about 300 MPH for more than a few minutes. I haven't gone through your tracks, but is the failure rate of WEP usage in any way coupled with airspeed? You mentioned that opening the radiators full mitigates failure risk, which makes me suspect WEP is being used at too slow an airspeed for effective cooling.

I believe it's been stated that the APU in the real thing does not have the airflow output required to spool up both main engines to self-sustainment RPM simultaneously. If the simulation of that ever gets fixed, this would break the "start both engines at once" thing. It's been my experience that even starting one engine at a time, you can get the helicopter physically ready to fly faster than the INU alignment completes.

Is there a good admin guide on setting DCS up in linux? i'm getting tired of blowing the OS out of my Winserver VM every couple months when the license dies and RDP stops working....

I'll give that software a go. As far as the controllers just not appearing, check your "VR" tab in the system settings pages and ensure "hands" is selected. If that's not doing it, then I'm not sure where else to look.

That would most likely be because your faces are not the same shape as the faces of those of us having this problem. Short of getting plastic surgery, i don't see how you COULD reproduce an issue stemming from the fact that HMDs fit on people's faces differently.

As someone who is trying to get into making some more complex mission designs, specifically tutorial and training missions to help people practice their fundamental pilotage skills, it is incredibly frustrating that there is no officially supported reference material for these parameters to use in mission triggers. I am aware of the existence of such tools as DCS-BIOS to retrieve this information via API call, but I am not interested in them. This is a something that should either be included in a "mission designer's guide" for each aircraft, or should be baked into the game so that we can see these parameters while setting up mission triggers which rely on them.

Just had a go with that utility, i see that there are a bunch of Vive Hub layers. turned them all off as i am not using Vive Hub with this headset, but that did not change the behavior.

I'll check that out, but i'm not sure i can turn it off. I'm using a Pimax headset and the native OpenXR integration with that. That said, I also get the same behavior if i switch the Pimax software to use SteamVR and turn off all OpenXR integrations.

Bueller, Bueller, Bueller?

that is correct, the control options window only contains bindings. There is no way for us users to set where screenshots are saved, that's hard coded into the engine. Again, screenshots are saved to the "Saved games" folder in your user directory. I have attached an image of mine below. Yours will probably be in your "C:" drive and not "A:", unless you have moved your "users" directory, as I have done.

This is pretty much standard for all GPS navigators. When you use the "direct to" feature on almost any GPS nav unit, it shows the desired course line from the point where you initiated "direct to". The reason for this is to enable Course Deviation features to let the pilot know when the aircraft is wandering from the course. If the course line latched to the aicraft, then there would be no way to indicate to the pilot that the aircraft has drifted off the commanded line.

I really wish the IHADSS had an option to display TADS LOS as its own symbol at all times. I realize that the real thing does not have this, so ours never will either, but it would certainly make it easier for me to realize that George has latched onto something 20 miles away from where i told him to look while i'm working the FCR using a steerpoint or tgt point as ACQ to cue it. It's a PITA to ACQ to TADS to get George under control, then ACQ back to the steerpoint.

Check your control bindings, and unbind the pinky lever axis from the throttles.

check the control bindings under "UI Layer" and validate the screenshot binding is where you want it. They should be saving to "saved games\dcs\screenshots" (or some variation of that path) within your user home directory.

This really exposes something that has been touched on in the past on these fora as an issue: JTAC needs to take laser codes from the pilot, not tell the pilot what laser code to be using. Before the update to bomb fuzes, this was a procedural nitpick with minimal impact on gameplay. But now that laser codes CANNOT be changed in the air for most weapons, it's a game breaking issue. I realize this is going to immediately devolve into a flamewar about the DCS JTAC, but this puts us firmly into "past time for JTAC to be fixed" territory. The DCS JTAC has always been far too inflexible. That was tolerable when we, the players, could be flexible to make up for JTAC's inflexibility, but as mission designs in the community have become more complex and our aircraft systems have had some of their non-realistic flexibility removed, the flaws in the original implementation have become increasingly impossible to ignore.

I've been having an issue with the thumbstick and face button inputs on my Index controller not working recently. Palm grip for laser still works Clicking trigger while laser still works (though just touching the trigger clicks now, instead of clicking on trigger pull) thumstick tilt fore/aft no longer sends right/left clicks Thumbstick tilt left/right no longer sends scroll down/up I experience this error when using both SteamVR and OpenXR DCS.log is attached. It would be nice if we could have an interface to bind these hand controller interactions, instead of relying on baked-in bindings. it seems like those get broken every time there is a VR API update. dcs.log

I am able to replicate this as well: In back seat NVS to "Norm" Validate using PNVS Validate able to select ACQ->TADS NVS select TADS on collective Validate ACQ transitioned to FXD and unable to select ACQ-> TADS NVS select PNVS on collective UNABLE to select ACQ->TADS NVS to OFF NVS to NORM Validate able to select ACQ->TADS again tads-flir-acq-stuck.trk

I believe that you will get an "engine fail" alarm if the TGT sensor fails, which seems to be pretty common when taking damage. Usually when i see this alarm, i will notice that the TGT readout for the engine is showing 0 (which is obviously impossible, indicating sensor failure), but the fuel flow indicator for that engine still indicates full-power or close-to-full-power fuel flow. I will usually also see a non-zero torque value in this condition as well. Basically, to really be sure that an engine is dead, you need more than the engine-out alarm. If the engine is really dead, you will see abnormal indication on TGT, Np%, Torque %, and fuel flow for that engine. If you see a normal or near-normal value for any of those 4 categories, the engine is still producing power, and you probably have battle-damage to one or more sensors giving you faulty indication.