Greyman

As I hadn't originally adjusted the CPG collective mapping from when I'd imported a user mapping file from downloads\users, that might have been mapped as a slider, I'd have to check, but at least at one point, I'd had my Pilot's collective mapped as a slider. Either way, I'll switch them both to sliders, although they're both not sliders at the moment and that still seems to work as it should. I guess it must be something to do with non-slider axes having a white line that moves from the centre, rather than from one end of the indicator, when moving the control in the binding screen? I guess that DCS is normally able to make sense of the readings from a non-slider throttle/collective binding, but this seat switching is throwing it a bit of a curve ball? It's as though the code is somehow "remembering" the axis mapping from when I am in the CPG seat and still using it for the pilot's seat. Thanks.

I think I might be getting a little slower on the uptake, with my advancing age, as I'm finding learning the Apache more of a challenge than I remember the A10C and Hornet being, for example. Please tell me it is just a more complicated aircraft to fly.

sorry if I've missed this above, but I'd heard, possibly a rumour, that with the release of DLSS 4 at the end of this month, the Nvidia app would at least make the DLSS Swapper app unnecessary and possibly DLSS tweaks as well. We've now not got too long to wait to see if that turns out to be accurate.

So, and sorry for the repeated posts, but it looks like this odd behaviour is happening because I'd never inverted my CPG collective mapping, as I'd never planned on flying the helicopter from the front seat. However, there is still something odd going on, as for the pilot seat, for some reason, the helicopter is using the mapping for the CPG as well as that of the Pilot. Am I missing something somewhere? On the bright side, I've now inverted both collective mappings, so it won't really matter. The asymmetric bindings was perhaps a bit of an edge case that was never tested for? Trust me.

Well, it would appear that the final word of my previous post was more important than I'd thought when typing it. Looking at the collective, it would appear that for some reason, the virtual collective can't make its mind up whether to treat the axis as inverted or not, with it switching between the two, apparently at random. The problem goes away when I remove the inversion from the mapping, so it looks like part of the code at least, is looking at both the raw position of the physical lever and part is using the inverted value. Very odd, especially as this issue only appears after switching from the CPG seat.

I've just started flying the Apache again, fairly recently, and although my relative inexperience may be causing some of the problem, the transition from the CPG to Pilot seat is definitely not as seamless as the other way round. I even got George to land and when I got into the pilot seat and reset the trims, the helicopter still span out of control when I took off again. I can take off perfectly, normally by the way, so there must be some carry-over from George's time in the pilot's seat that shouldn't be there. As the CPG would never be able to move to the pilot seat IRL, there is absolutely no reason for the simulation to be way harder than it needs to be, in order to maintain realism. For me, this either needs to be corrected in the code or clear instructions provided as to how users are supposed to move to the pilot seat without the helicopter spinning out of control. I'm guessing that as this appears to have been an issue from the start and it still exists, I might need to wait a fair while or just find some way of working around, for me, what is an obvious flaw in the code? After a little more testing, there would appear to be something odd going on with the collective, as I'll describe below:- Using the instant mission, starting on the runway at Kutaisi, I switch to the CPG seat, before taking off. I then instruct George to climb to 50ft, in the hover, and then descend back to the ground. When he's landed and is "safe and sound" on the deck, I switch to the pilot seat. I then reset all trims, before trying to take off again. As soon as I move the collective away from the minimum position, even slightly, it jumps wildly upwards, apparently possessed, causing the aircraft to climb rapidly and spin out of control. By the way, I always fly in VR and have a TM Warthog HOTAS, with the Collective axis mapped to one of my throttle levers, inverted.

I've had this behaviour when I'd just set up the bindings and forgotten that I hadn't reversed my collective axis. When the flight first loads, the virtual collective is correctly sitting in the down position, but as soon as I move the throttle lever back, just slightly from what would effectively be the max position, the control synchronises and instantly goes from zero collective to almost max collective. That causes a fairly "exciting" few moments, which may not be recoverable. Whether your throttle lever/collective axis is reversed or not, just make sure that the physical lever is where it should be for zero collective, when loading the flight. Just out of interest, I use the throttle friction slider on my Warthog throttle for the engine power, so that I can leave the two throttle levers together, making all of the controls on the throttle handles more easily accessible. At engine startup, I just use the keyboard shortcuts or mouse to move the two virtual power levers into idle, as necessary, and then push the slider fully forward. Once it is in fly, I can just largely forget about it.

I use my Quest 3, like a lot of people, via Virtual Desktop, and had succeeded in getting my virtual hands to follow my actual hands in the cockpit. However, I could not get DCS to recognise me trying to press buttons or flipping switches and that was either caused by me simply not pinching or flipping correctly, or I've missed a step somewhere in the setup. Any ideas on what I might be doing wrong, so I can give it another try? I'd changed the internal game settings, VD streamer settings and in headset VD settings, but have now disabled the feature, as I don't really want my hands being shown if they're not going to be of any use.

It is slower to react than I'd expected, so maybe I just didn't hold the keys/buttons for long enough? All's good now though.

I'm really sorry, as it would appear that I have wasted your time and mine. As the cockpit camera is fully functional in VR for me, when in the FA-18C or the F-16C, it would appear that the A10C II might just be an odd one out. In my defence, I've been away from DCS for a couple of years and maybe there have been changes to the A10C, that I hadn't been aware of, making it very tough to adjust the pilot's position. Either way, I've managed to get the pilots head to an acceptable place, using the Alt+numpad 0 combination, whilst my VR headset adorned head was in said position. Whether that messes up things like the HMCS in the A10C II when in VR, remains to be seen. Thanks again. EDIT: Oh, and now the A10C II works too. I can only think that something on my PC was getting in the way of this and it has now somehow corrected itself. I'll go with that explanation, as otherwise I would have to have just messed up. I'm apparently getting way too old for all of this PC stuff.

Just to eliminate the A10C II as being a little odd, if you have that module, are you able to use these controls? As it is based on one of, if not the, oldest modules in DCS, there might be some things that have been optimised in subsequent modules, to allow the VR position to be moved. I did notice that the rctrl&rshift 5 (on the numeric keypad) did move the screen very slightly, so maybe that is the limit of the allowed movement in the A10C II? In the meantime, I'll try it in the Hornet or Viper and see if it works there. That'd probably prove the same thing. Thanks for your help by the way.

No. Even controller bindings won't move the cockpit camera position for me, so my keyboard doubts appear to have been a bit of a red herring. When in the bindings screen, the key and controller combinations are recognised, but not in the cockpit itself, with active pause on or off, so it just looks like I must have a setting, or something else, going on somewhere in my setup. Oh, the cockpit camera movements appear to work fine in 2d mode, so it would appear that my VR is somehow causing the issue.

Thanks for that. I was wondering if the lack of movement on my cockpit cameras, with the default mappings to the Numeric Keypad (with Rctrl & Rshift) might be something to do with either the openXR toolkit, which should use the arrow keys, and/or my keyboard maybe treating the numeric keyboard as arrow keys, whether the num lock button is down or not. I'd tried mapping other keyboard combinations to the function, but I have a TM Warthog HOTAS, so could use the joystick pinky switch modifier along with one of the other hat switches, on the throttle or joystick, to manipulate the views. I will give that a go later, to see if I can get the cockpit cameras to move. Do you need to be in active pause to move the cockpit camera or does it work for you while fully active, when sat on the tarmac of course?

Thanks anyway. In short, when in VR, the whole of the HUD information cannot be seen when in the current default seating position, in the A10C II, but when you move closer, to where you can see it all, your neck needs to be a lot younger than mine to see the controls on the side consoles, which are then behind you. I'm trying to find a compromise position, but cannot figure out how to set it, without these cockpit camera controls. The current default position seems like a bit of a compromise, but not the one I would have chosen. I have vague recollections of a few years ago, when I was last flying DCS regularly, of a utility that would allow you to move your head position and it would provide a readout of the x,y and z coordinates that you could copy into the appropriate lua file, once you had found the ideal spot. Maybe I'll just need to mess around with the numbers in that lua file, until I find some that work for me. Thanks again.

Do you know if this should also work in VR, as it doesn't for me and it's driving me spare? I hate the hit and miss of having to stand up further back than I'm sitting and then pressing the VR camera recentre key(s) and can't think why the cockpit camera keys don't work, at least for me.

Well I've just updated DCS, to the latest version, and both aircraft seem to be working OK, despite me having real-time AV scanning activated, so maybe that's sorted it. A full scan of my system takes and age, so if I can't figure out how to just point a scan at the DCS folder and as they are/were very likely to be false positives anyway, I'll probably not repeat the scan just yet.

I've just received what are probably false positive reports on AV8B_FM.dll and M2KC_FM.dll, from a full scan of my system. If they are false positives however, maybe someone at RAZBAM or ED ought to check why these reports are suddenly occurring, when there's not been a sniff of any issues for years?

That's the one :P

I'm probably not using the correct terminology, but my Crosswinds came with 2-3 different interchangeable "inserts", the thing that the big bolt-head on the arm attached to the spring moves along as you move the pedals. If you have these also, maybe drop the one in that has the deepest dip in the middle, as that should give a bigger impression of a "centre detent".

if it's working from the pilot seat, but not from the CPG seat, then maybe check that you haven't inadvertently cleared those mappings from the keyboard, in the AH64 CPG category.

..for an official response

I'm a very satisfied wheelstand pro user also and currently use a 20cm extension, which is just about as long as i could use, with the joystick mounting tube, on the stand, dropped as low as it can go.

but can George choose his own targets, especially if there is more than one? I thought that the non-artificial intelligence in the aircraft has to make the ultimate decision as to which target is selected?

"by George, I think he/she's got it" I wonder if that could that be where the AI CPG got his name?

Maybe check this out. It would appear that the throttle might implement a reverse thrust, which from a certain point, makes DCS think the throttle is increasing the more you pull it back.