GregP

Yes it is. Are you in the US? PM me as I don't check the forums very often anymore.

Bought new in 2020 for $800 total. Perfect condition with no problems. This combo goes for $600 shipped new from VKB right now, but I'm selling for $450 plus shipping (within the US only). Also throwing in Virpil joystick cover for free. Package Includes: - MCG Ultimate Grip - Gunfighter MkIII base - 200mm curved stick extension - 50mm straight stick extension - Small base plate - All included optional springs and cams MCG Ultimate Grip: Right-hand grip design 24-32 programmable buttons, based on module installed 5 analog axes (2x slew control mini stick axes / 2x trimmer mini stick axes / 1x brake lever axis) Dual-stage trigger (trigger 1) Metal folding trigger (trigger 2) with two-position sensor (flipped up/down) Mini stick module Hat switch module Button caps (black color) Screwdriver Set of grip fasteners Gunfighter Mk.III Base: Hardware Built to Last All-metal gimbal w/ adjustable axis dampers Swappable cams and springs “Avia” cams with progressive loading (soft and hard center) “Space” cams with linear loading (soft and hard center) Cams made of hardened stainless steel alloy Blackbox w/ 32-bit ARM MCU active USB 2.0 controller Set of springs Spring installation tool 50 cm (1.6′) interface cable 180 cm (6′) USB 2.0 cable Features Works with all flight simulations No drivers required Digital Hi-resolution contactless sensors Save and load custom profiles Software tunable axes Upgradeable firmware via USB interface Gunfighter Pro-L(ong) comes with a 200 mm Stick Extension 200 mm (8″) curved extension Set of #50 springs – extra strong Grip fastener https://vkbcontrollers.com/?product=gunfighter-mk-iii-modern-combat-edition-ultimate

I believe it's 'WAS Up', in other words press up on the Weapon Action Switch to arm/select the guns.

After scouring the forum I didn't see this anywhere, so I had to figure it out on my own, but now that I did, I thought it was worth sharing: The Jester/Iceman AI menu can be resized. For me this is helpful as I play on a 65" 4K TV and sit quite close to it, which is ideal (in my opinion) for cockpit readability, but the Jester AI menu being so large by default felt unwieldy to me. I've now shrunk it down to half size and it's so much better. All that needs to be changed is a single value in your main DCS folder: \Mods\aircraft\F14\Cockpit\Scripts\JesterAI\JesterAI_page.lua, line 26: Change 'scale = 1.0' to whatever you desire, 0.5 in my case. Note that this may not work for VR; I've no way to test it as I don't have a VR headset.

Still available, price dropped.

We should probably caveat that the 9% number came from AeriaGloria's tests and have never been actually quoted by anyone from ED, right? So that may not be the actual number. Either way, your point stands, that -- at least following their presumed logic for implementing it in the first place -- the 'deadzone' chosen should've been smaller.

Just wanted to note that I recently did the Neogel lubing process as shown by TellerJohn above, and it has indeed significantly improved the feeling of my collective. Nearly no stiction anymore! Thanks.

Right, and so this again highlights the inadequacy of either pedal position or movement being the determining factor that triggers the yaw AP to move out of heading hold mode and into stabilization mode. Instead, what is needed is some signal of pilot intent, which in the real thing is handled by the pedal microswitches: when feet are on, the pilot desires to control the yaw angle; when feet are off, the pilot desires the yaw AP to hold the yaw angle. Thus it seems like some kind of simulation of the microswitches themselves is needed in order to get the yaw AP behavior right for both spring-centered and springless pedals.

Well there is already the 'rudder trimmer' option that presumably is intended to be used with springed pedals, where the user would want to return them to center when pressing the trim button. The question is (and which I posed in my thread in the bugs section) whether this 'rudder trimmer' option has any effect on the way the yaw AP works, i.e. is the yaw AP designed to mostly work acceptably for normal center-spring pedals only? Or does leaving that option unchecked (for users of springless pedals) somehow adjust the yaw AP to recognize that the at-rest position of the pedals is not always near the center?

8 months after early access began, multiple discussions in both the English and Russian forums still haven’t clarified the intended behavior and use of the autopilot yaw channel. The current behavior appears to be bugged in that the yaw AP seems to occasionally remain in 'heading hold' mode when it should be switching to 'stabilization mode'. This is important because in these cases it appears that the yaw AP is resisting players’ pedal inputs when in fact it should be assisting them. Unfortunately our conjecture about this will continue without any resolution until ED comments on the following: How is the yaw channel behavior modeled in the DCS Hind? What yaw channel behavior should users be experiencing for both: ‘Rudder Trimmer’ checked, presumably for users of spring-centering pedals? ‘Rudder Trimmer’ unchecked, presumably for users of pedals without a centering spring? Most of us seem to agree that in the real Hind: The yaw AP channel is intended to be used throughout the entire flight, from takeoff to landing. When the pilot intends to take control of the yaw angle, he puts his feet on the pedals, which press the microswitches, which places the yaw AP into ‘stabilization mode’ and deactivates ‘heading hold mode’. When the pilot intends the yaw AP to maintain the set yaw angle, he pulls his feet off the pedals, releasing the microswitches, which places the yaw AP into either ‘heading hold mode’ (where the yaw AP only uses its 18% separate control authority) or ‘displacement mode’ (where the yaw AP physically moves the pedals so that it can make use of more than its 18% separate control authority). But since the pressing and releasing of the microswitches does not appear to be currently modeled in the DCS Hind, the yaw AP has no foolproof way of ‘knowing’ what the pilot wants it to do, and thus in some situations users believe they are experiencing the yaw AP fighting their inputs – in other words, that the yaw AP is remaining in ‘heading hold mode’ rather than switching to the ‘stabilization mode’. So can someone from ED clarify these points for us and confirm whether or not this is a bug?

Great discussion here, but as always, we'll continue to go around in circles until ED clarifies how the yaw AP is supposed to work. Given that what we're observing with the current implementation is basically a bug -- yaw AP occasionally stays in heading hold mode when it should be switching to stabilization mode -- I think I'm going to post a bug report and ask for ED's clarification. OK done:

Now that I'm thinking about this some more, this isn't ideal, is it? Because turning off yaw AP in that region is thereby deactivating both 'preset yaw angle'/displacement/heading hold mode and stabilization mode, when really what you want is to have the yaw AP change mode depending on your intent, as I detail below. That's a great point and I stand corrected -- basing the change in mode off of movement alone wouldn't be sufficient. Instead, the criteria really needs to be 'what is the pilot's intent right now?' Given that all sources seem to agree that the yaw AP should always be on, the question then becomes 'what should it be doing while it's on, and what is it actually doing in DCS right now?' In order to perform the way it appears to work on the real Hind, what we need is a simple way for the yaw AP to differentiate between a) times when the pilot is manually holding a yaw angle or moving the pedals to a new yaw angle, and b) times when the pilot wants the AP to take over and hold the yaw angle he's selected. Which again comes back to the microswitches and why they make so much sense, as this is the only way for the yaw AP to 'understand' what is being asked of it, and how (I'm getting it now!) you're right in saying that having this feature on the Hind is absolutely critical. Well now it makes me wonder whether someone at ED read the real-life manual and saw that 18% number and mistakenly applied it to this effectively deadzone around the center of the pedals. Because as I outlined above, I think overall the current implementation (aside from the actual 18% number) makes sense for users with spinged pedals. Unfortunately for users with unsprung pedals, it does not (and nor would it on the real helicopter); so, if true, users who are attempting to more accurately simulate a real helicopter pedal movement actually get penalized with a behavior that is unrealistic. I now absolutely agree. But I guess we should add the caveat that microswitch implementation is only critical for those of us using unsprung pedals -- which I assume you are? I thought I recalled seeing someone, or several people, mention that in one or more of those ten-or-so threads I mentioned above. Maybe even PilotMi8 in the Russian forum? I can't quite recall. But it also just follows logically, if you modify my original words to read 'when moving them or desiring to manually hold a specific angle', which is what I should've written. If a pilot wants the yaw AP to take over and hold a heading/yaw angle, he'd have to pull his feet off the pedals. And then whenever he wanted to change the angle, he'd have to put his feet back on to make the adjustment. Thus you wouldn't keep your feet on unless you were intending to manually hold a yaw angle or change to a new angle.

The Yaw AP channel, the accuracy of its implementation in DCS and its proper use remains an extremely confusing and convoluted subject to myself and I’m sure many others here. By my count, since the Hind’s initial early access release, there’ve been ten or more separate threads discussing the subject (and here I’m only talking about in the English forum – there are a few more on the Russian side), making it very difficult for us virtual pilots, both new and old, to try to comprehend what is correct. Aside from the fact that ED hasn't provided any real explanations yet, one exacerbating factor, I think, is that we all tend to mix up terms and use them interchangeably when really they should be separate and distinct terms representing different phenomena. To attempt to clear up some of this language ambiguity, It makes sense to me to refer to the real-life pilot operating handbook, a 2011 version of which can be found put out by the Cold War Air Museum in Lancaster, Texas. Unfortunately it’s not a complete POH, lacking the entire procedures section, but it does cover the systems. In the ‘Flight Controls’ section, it has the below quotes to say about the Yaw Channel; it took me several reads to really comprehend what’s being said here. Two important notes: 1) the excerpt below is entirely separate from the 'course control mode operation', which does not require the yaw autopilot channel to be active; 2) I was initially confused by this, but I now believe the '18% control authority' to refer to the autopilot system's separate authority over the flight control surfaces that is distinct from that originating from the pilot's controls. So although that 18% is all the autopilot controls on its own, it can actually make use of more control authority by directly moving the pedals -- see 3rd bullet point below. “VUAP-1 Autopilot System: Autopilot correction signals are limited to a maximum of 18% of control travel for flight safety in the event of false signals or system failure. The pilot may intervene in control at any time while the autopilot is engaged to make manual corrections by operating the flight controls.” “Yaw Channel Operation: The yaw channel receives signals proportional to the current heading from the flight director system and rate of turn signals from the yaw rate gyro. The yaw channel output signals are sent to the directional flight control servo. If the pilot’s feet are not on the pedals, the autopilot maintains the preset yaw angle, switching the directional flight control servo to displacement mode as needed to introduce large corrections. The speed of pedal movement in displacement mode is controlled by the hydraulic pedal damper in the directional control system. The yaw channel includes a relay which prevents the servo from switching to displacement mode if the pedal damper is disengaged. When the pilot’s feet are on the pedals, the sub-pedal microswitches activate and the yaw channel operates in stabilization mode. The yaw rate signal passes through a low-pass filter to prevent the servo from drifting to the stops while executing manual turns with the yaw channel engaged.” In bullet form, I read this to be saying: The yaw channel outputs to the directional flight control servo, which can either be in an unnamed ‘preset yaw angle mode’, displacement mode or stabilization mode. ‘Preset yaw angle mode’: the pilot’s feet are off the pedals and the yaw channel’s 18% control authority is sufficient to maintain the ‘preset yaw angle’. Displacement mode: the pilot’s feet are off the pedals and, although not explicitly stated, presumably from the context, ‘displacement mode’ means that the directional flight control servo moves the physical pedals to enable itself to have more than the 18% control travel it is usually given. This requires the pedal damper to be active. Stabilization mode: the pilot’s feet are on the pedals and thereby activate the sub-pedal microswitches. Although not explicitly stated, presumably stabilization mode is intended to allow the pilot to change the yaw angle while maintaining stability in the yaw axis. If all the above are true, then how a user experiences this in the DCS Hind depends not only on how it has been implemented, but also very much on whether their pedals have springs or not. I’ve not thought through entirely how users with normal springed pedals should experience this, but for those of us like myself who pull the spring off of their pedals when flying helicopters, I think it should ideally work like this if the Yaw Channel is active -- it's quite simple, actually: If pedal input by the player is detected, Yaw AP enters stabilization mode If pedal input is not detected, Yaw AP enters ‘preset yaw angle mode’ Obviously DCS doesn't have the ability to move our pedals, so the displacement mode cannot be easily simulated; or put another way, it could get very confusing if the Yaw AP ends up using more than 18% of its authority but our pedals remain stationary, leading to a situation where we have a mismatch between our pedals' physical location and where the sim calculates they are. In the worst case, this could cause situations where the player thinks they have more anti-torque authority left before hitting the stops, when in actuality the pedals are closer to the limit. The only solution I can think of for this situation would be that the displacement mode is simply not modeled, and instead it is assumed that wherever the pilot leaves their physical pedals, they match up with where the in-sim pedals appear to be (with the obvious caveat that the actual modeled position of the control surfaces could vary by up to 18% from where that pedal position would ideally suggest they should be). So, after that wall of text ... it seems clearer to me now how what you describe in your opening post indicates that the current implementation only makes sense for users of springed pedals (with that 18% number just being an unrelated coincidence, I think?), because when their pedals are near center, that likely indicates the pilot doesn't intend to change the yaw angle (i.e. their feet are off the pedals) and thus 'preset yaw angle mode' is active; and when they do move the pedals out of the center, the pedals shift to stabilization mode. But for unsprung pedals that could be at any position when the pilot takes their feet off, you would ideally want stabilization mode to kick in as soon as any movement is detected, regardless of where the pedals are at the time ... which is I guess exactly what you've implemented with your vjoy/joysick gremlin profile, right? On a separate note -- I've always found it hard to believe that pilots are taught to pull their feet off the pedals (and thus not activate the microswitches) except when they intend to move the pedals. Is this really how it's done? I would think that would make normal maneuvering in an Mi-24 extremely tedious, unless the assumption is that the Yaw AP channel doesn't need to be active in anything other than a stable regime of flight.

Hi, sorry I missed your post above! But the mfds are sold already, sorry.

I realized too late that it just doesn't fit into my cockpit setup, so now I'm using the smaller WinWing desktop collective.

Edit: sold. Be prepared for the Apache! Bought new in July for $580, but only used for 5 or so hours. In perfect condition, no problems at all. Includes original unused English and Russian label stickers. I also bought a motorcycle damper which I bolted on to add some damping to the collective's motion, and I'm throwing that in for free. I have the original VirPil boxes too.

Dropped the prices on the WinWing panels.

SOLD.

In training mission 8, the AIM-120 / Link-16 lesson: after downing the Su-24s, the voiceover instructs you to fly to steerpoint 3 in order to engage the Tu-22s -- but it should be steerpoint 2. In training mission 9, AIM-9X / HMCS: when setting up to chase the Su-25s, the voiceover instructs you to use the left MFD to switch to ACM mode and then 'press OSB2 twice to enter boresight mode'; but it actually requires 3 presses, as you start in 20, then 60, then slew, then bore.

Ah yes, thank you. Soooo .... might we expect an updated set of these incredibly well-done training missions to be available some time soon? Pleeeeease?

Anyone know if these are working with the 2.0 version of the A-4 mod?

That’s Iranian-accented English, pretty familiar to those who’ve heard it a lot….although shouldn’t it be obvious from the context?

This is really outstanding work. I've been wondering for YEARS now how DCS has somehow never had a livery manager made by the user community when it seems that every other flight sim out there has. So I really appreciate the work you've put into this! Understanding that this is a command-line utility rather than a GUI, I wanted to pose this question: manually importing DCS user files IDs or links is a very different process from how I currently install skins, and I'm wondering if there's any possibility of your tool eventually being able to be just be set as 'open with' in Windows right-click menu? I tend to download a whole bunch of skins at once and then import them into OVGME. In other words, do you foresee any means of using your tool to operate on individual already-downloaded skin zip files? For me at least, that would tremendously boost its utility.

Agreed, this looks awesome! I plan to give this a try soon.

I second that! One of my obligatory apps now -- TrackIR, SimShaker, DCS Moving Map. Really appreciate your work on this!