ShuRugal

I think a better way to phrase it would be that the FCR is what gives the Apache the greatest advantage over the Ka-50, in DCS. without the FCR, the Ka-50 is an objectively better platform for killing things in DCS. It's easier to learn to fly, its very rapid to engage targets with, and the pilot automation systems are very simple and easy to learn. When I used to fly the DCS Ka-50 every day, it was not uncommon for me to rack up kills twice as fast as the guys in A-10s, and the A-10 is an undisputed beast at killing tanks. the AH-64 IRL is way better than the Ka-50, because crew coordination with trained pilots who fly together every day is always going to be better than using your thumbs to give an AI gunner or pilot orders, but in DCS that's not a feature most people get to take advantage of, simply due to the fact that most of us have real lives and can't coordinate to fly with the same people day in and day out in multiplayer. The FCR will give the solo-pilot with an AI gunner a dramatic edge over the solo Ka-50 pilot, none of the other systems as implemented offer that. (maybe that will change when we get a "george, kill anything you see, don't wait for me to tell you about it" button.)

Another important distinction here, just to complicate things further... a LITENING pod am board a jet 10km above the target is shooting through considerably less atmosphere than one on a helicopters 10km laterally from a target at 100m altitude... The average density of the air between surface and 10km is less than half the density of air at sea level. Thicker air means more atmospheric scattering which means less energy reaches the target and less of the reflected energy makes it back. it may well be realistic for a Hornet at 30km altitude and 30 km lateral range to pick up a laser fired by a Predator orbiting at a 5k radius and 10km altitude, just because there is so much less AIR in the way of the laser. That doesn't mean that an Apache at 100m altitude would be able to pick up that same laser from 30km range, even with a perfectly clean LoS

Average would work fine if both players have FFB controls. Without it, the scenario you describe would definitely cause problems. No reason it couldn't be implemented to work either way, though. Give players the option to choose which mode is correct for their use cases.

Just wanted to bump and add my observations. It appears that on multiplayer when George has the gun, he will not fire the laser ranger and TADS always displays a range of +9999 This results in the "ballistic limits" warning flag and george does not fire, even though he says "firing" Can we fix this by having george lase continuously when gun is selected? Not a realistic procedure, but if his decisionmaking is preventing him from lasing, that will solve the issue until his decisionmaking can be debugged.

the behavior of the control position indicator leads me to believe this is already how it should behave. I have been helping a friend learn to fly by watching the control indicator while he has it and coaching him on his overcorrections that way. it looks like my thread has been merged into this one, even though the method I suggested was different. My suggestion covers this problem: Ideally, I would like to see this set up so that there are 3 ways to control an aircraft, which can be switched between at will by the players: pilot only control (only pilot's inputs are read for aircraft control) dual control (both pilot and copilot controls are averaged) copilot only control (only copilot controls are read) If "average mode" would not work well due to network latency, perhaps that mode could be replaced with a mode which provides real-time control from one pilot or the other (As selected by the players) while reading the value to average against at one second intervals from the other. So then we get: pilot only pilot priority, read copilot once per second (or faster, depending on how much load this is) to use for mixing copilot priority, read pilot once per second (or faster, depending on how much load this is) to use for mixing, copilot only With this model, when operating in "mixed" mode, either pilot should be able to take priority with a single button command without a consent box being required, but a consent box would still be used to enter mixed mode or to give exclusive control to the copilot. Additive would probably work as well as average, better if both pilots do not have FFB controls.

Second attempt to post this, last attempt ended up in mission editor wishlist somehow... PEBCAK. Could we get a flight control mode for multicrew modules which allows pilot and copilot controls to be mixed, rather than only one or the other? Average them out, Airbus style? Would be a really nice way to bring new pilots into the game, or even to just have a way to smoothly transfer controls without the "jump" caused by the fact that controls will never be aligned when the "give control" button is pushed. Ideally, I would like to see this set up so that there are 3 ways to control an aircraft, which can be switched between at will by the players: pilot only control (only pilot's inputs are read for aircraft control) dual control (both pilot and copilot controls are averaged) copilot only control (only copilot controls are read) If "average mode" would not work well due to network latency, perhaps that mode could be replaced with a mode which provides real-time control from one pilot or the other (As selected by the players) while reading the value to average against at one second intervals from the other. So then we get: pilot only pilot priority, read copilot once per second (or faster, depending on how much load this is) to use for mixing copilot priority, read pilot once per second (or faster, depending on how much load this is) to use for mixing, copilot only With this model, when operating in "mixed" mode, either pilot should be able to take priority with a single button command without a consent box being required, but a consent box would still be used to enter mixed mode or to give exclusive control to the copilot.

The way my VR HMD sits on my face, the center of the IHADSS ends up about 15 degrees above my natural line of sight, which makes the thing pretty headache inducing to use. i've found myself mostly flying with it off except when i need to prosecute targets to reduce my eyestrain from always looking up to see it. Can we get a setting to offset the IHADSS rendering height? bonus points if it can be bound to key commands so i can adjust in the cockpit.

Just spent a couple hours playing with the CPG seat while George flew me around the target range mission. My solution to this is to bind a button on my throttle base to "show/hide" IHADSS. If I am using the TADS as a sight during the day, I hide the IHADS. When I want to use the IHADSS as a sight, i unhide it and select it as a sight. Haven't played with it at night, but i suspect that using the TADS either in NVS Norm mode, or set as a sight slaved to the CPG HMD, is very convenient to have it in the monocle.

Laser-guided rockets are unlikely for the Ka-50. As previous posters have noted, the only proposed system for that never entered service, and this is a study simulator, which means we are limited to real-world loadouts. It's probably helpful to keep in mind that, in the real world, aerial rockets are not considered precision-attack weapons. They come in pods and fire in salvos for a reason. You shouldn't look at a 20-rocket pod and think "i'll kill 20 tanks with this". full pod of S8s is good for 1-2 tanks, maybe 3 if you're a real surgeon or the tank isn't shooting back so you can get inside 500m to shoot. If you want rockets to supplement your vikhrs, you need to know what you will be shooting at. Infantry? take S-8 OFP (HE Frag), fire "medium" salvos from 2-3 km. Trucks or armor? S-8 KOM (HEAT), fire medium salvos from 0.5-1 km. General purpose? s-13, fire singles from 1-5 km. Generally, the s-13 is the best rocket to take. nice big blast radius for trucks and infantry, and you get 5 shots vs 4 "medium" salvos of the S-8. good for clearing manpads out of treelines where you can't see them to use the gun and dont want to waste vikhrs.

Was linked to a thread from the beginning of this year about this issue which is now locked. Playing in multiplayer with the F/A-18, every time i die and respawn, i spawn on the catapult with wheel chocks in place unless i change slots, in which case i spawn cold on the elevator. the F-14B does NOT suffer from this problem. In my experience, the bug is 100% reproduceable: 1: be on multiplayer 2: start a cold F/A-18 on the supercarrier, launch 3: die 4: without changing slots, respawn. upon respawn, you will be engine hot on the catapult with wheel chocks in place, and crew chief saying "unable" to all commands apart from "rearm"

@XPACT @Flappie Just for shits and giggles, I ran the game with Procmon capturing activity, just to see if anything interesting happened. Lemme know if you want the procmon dump, it's about 4 GB, and aside from just over a million NAME NOT FOUND events, is pretty dry. Top level counts for event results: For shits and giggles, I also threw a paging file on my 1TB platter drive at 32GB (which is pretty fucking pointless, because that drive would take 10 minutes to swap 32 GB into RAM... faster to read it off the SSDs it actually lives on) just to see how memory allocation behaved. Even with all this swap space to play with, DCS never requested a commit greater than 17 GB, and that my total commit never exceeded 28GB. Wasn't able to reproduce crash conditions (with the Hornet, it's pretty sporadic, only about 1 crash to desktop every 10-15 hours of gameplay on average) I'm not asking for help bandaging the bad behavior in the application, I am reporting the bad behavior and providing as much data on it as I can so that ED can identify the internal engine cause of it and correct it (or not, memory allocation problems have never seemed high on their radar in the past).

Commit charge is a meaningless number by itself. how much RAM is actually in-use? That's the important figure. if I have 32GB of RAM, and only 16 is in use, and DCS is throwing fits about RAM while it still has 16 billion bytes available, that's a DCS problem.

which makes this a problem with DCS. If DCS is coded to be intolerant of no swap file, that's bad code.

I have recently gone from 16 to 32 GB of RAM. you can see from my procmon capture that while DCS had requested commit for 98% of my total ram, it was only using 16GB at the time of the crash. There are also virtual no hard faults ocurring, the game is not even requesting swap access, this cannot be a swap issue. I have the swap file completely disabled on all my hard drives except for the drive I have windows OS loaded on, and the swap size there is the minimum to allow windows to save crash data in the event of a BSoD. If DCS is having memory issues when i have 16GB of RAM unused, that's a problem with DCS, not my system.

two more crashes this evening. Both flying the F/A-18C in multiplayer. One a bit after a firing a string of HARMS, possibly at the same time a group of T-90s spawned in. Second crash occurred during handover to tower on the way back to the carrier. Logs.zip DxDiag.txt

I have the page file disabled deliberately, I should have more than adequate actual RAM and don't care to have windows thrashing my drives. If you are seeing memory errors, I will look into acquiring more RAM.

I've been having a problem on Multiplayer with being unable to launch after I die or return to the carrier. First launch is always good, second launch always refuses to pop, crew just stands their holding their thumbs up. Shooter puts his arm out, but does not complete the signal to shoot (does not touch the deck and lift). If I go into AB, the aircraft breaks the launch bar after a couple seconds and tumbles off the deck. attached track shows this happening three times. First launch is cool, then i die, and when i spawn back in, all subsequent launch attempts result in this condition. Caucasus_Dynamic_Conflict_v1.3.0_BW-20210423-180357.trk

Adding my name to the crash list. For me, the crashes in DCS are so hard that they impact other Windows applications. Steam VR has modules begin to fail, any open browser windows I have in the background will freeze, and Discord goes blank and must be task-killed to get running again. For me, the crashes happen most often when connected to any multiplayer server, though crashes in SP missions happen as well. DxDiag.txt crash.zip

Yeah, it's pretty frustrating. the Steam VR mirror doesn't include an audio feed, and Discord doesn't let me select what my stream audio source is. I have to choose between having good picture or audio. I've played around with a few products which let me mix the game output and my microphone input into a virtual microphone, and set that as my mic in Discord, but that has its own set of problems.

I have no idea, as I'm not using WMR, i'm running in Steam VR with a Valve Index. The sound going to my headset is also not the problem. The problem is that when I tell Discord to stream the Steam VR mirror (which reprojects the VR image from my headset to 16:9), it does not include audio from the game. Steam VR has an audio mirror function, but it can only direct sound to physical devices. Discord lacks the ability to select specific audio sources for streaming, if the app you are streaming the video from doesn't have audio, then you don't get audio in the stream.

Ah, the old "perfect is the enemy of good enough" issue.

I realize that this is pretty low priority for the DCS team, but it really aught to also be pretty low-hanging fruit to fix as well: I am running into a serious problem with the way the desktop mirror in DCS works. When streaming DCS in Discord, viewer complain about the 9:16 aspect ratio. If I use alt-enter to force fullscreen, it doesn't actually crop the top/bottom off the mirror, and I end up with a an ugly stretched view that some people are reporting actually makes them nauseas to watch. While i can set SteamVR to mirror the VR view and stream that, no audio is forwarded to discord this way. Can we please get an option to have the VR Desktop mirror cropped and centered to a 16:9 aspect ratio so that it is practical to stream this thing in Discord?

bump. seems there is no axis and no key binding for the yellow handle. this really hurts in vr..............................................................................................

i want the opposite - i want AB to not engage in flight without detent. too easy to punch by accident

I'm not sure if this is a DCS F-14 bug, or a DCS World bug, but I've only encountered it in the F-14. I also posted this thread in the DCS F-14 bug reporting forum, in case it is an F14 module issue. It seems that with the update that added the F-14, we got "touch to toggle" switches. Which is fantastic, it really is. The problem is that some switches require the grip trigger to be held to interact (so you get the "finger laser") and others do not. The problem I am having is the ones which do not require the grip trigger to be squeezed. It seems to be switches on the right side of the cockpit which are more likely to be a problem with this: I cannot interact with any left-panel switches unless I squeeze the grip. The right panel, however, appears to be open-season: If the VR hand passes through a switch, it will activate it, regardless of whether I am using the grip trigger. This causes problems when I interact with menus or put my touch controller down so i can grip the stick. So far, I have managed to: Jettison the canopy (about 75% of the missions flown so far) Turn off the generators (50% of the time when I set hand controller down) Toggle the hydraulic transfer pump (the other 50% of the time when I set hand controller down) toggle bleed air source (25% of the time) reconfigure my HUD and MFDs (about 10% of the time) All in all, it's fairly annoying. I have started keeping my hand controller on my lap (rather than its hook on my chair side), but i still end up starting many missions with no canopy, because the canopy jettison lever is exactly where the "start mission" button is after loading in. In fact, the first two times I tried to run a cold start training, I thought I was experiencing a bug with the canopy failing to render, because I jettisoned it before I could even get past the briefing pause screen.