WillyPete

Hi Prav. It's been a while but did you sell the throttle?

I understand the difference. Your claim that it is due to the vertical stab is wrong, plain and simple. In aerodynamic trim at cruise speeds, the heading should be centered. The stab is designed to permit close to neutral pedal position at cruise speeds. This is true for all modern helicopters. The tilted gearbox and MR in modern designs are also implemented to counteract drift. In a no wind, scenario, with low to little loading there should be no crabbing of note. None at all. As you can see from the images that the crabbing is quite drastic. Get in the cockpit, fly over a very visible landmark like a road or powerline and observe which position the ball is in when you are on a true follow heading to the landmark, and nose to tail with it.

If you watch that video that Wags presented, after he has "trimmed" the slip ball you can actually see via the heading tape that he is actually in a sloppy turn. The tape moves about 1 degree per second. This indicates that he is providing more yaw pedal than needed to maintain zero slip, yet the ball says otherwise. You can try it for yourself and see. At recommended cruise speeds, any vertical stab on a helo will be designed to hold a straight track. The rotor is tilted to provide a natural bank to counter these in flight forces in a helicopter. Unless there is a crosswind present (easy to set in DCS), a slip ball should indicate straight and level flight at cruise speed, without crabbing. Yes, near VNE you should need more power pedal and a slight bank to retain that course.

It's also worth noting, that the trim problem affects other helicopters. Have a look at this following screenshots from Wag's video introducing flight in the Apache. The first shot shows the slip ball off to the left (same rotor system as huey) and the Flight Path Vector indiscator is centered. The second shows him in an "aerodynamically trimmed state" (his term) with the ball centered, but the FPV showing his heading off to the right. When in this state it is very obvious in the video, that he is crabbing right. It's not just the huey.

I want to jump in on this by asking you all to check how the huey performs in the hover (IGE) in extremely high winds. Last week on GAW Hoggit server, the winds were in excess of 18-30m/s allegedly using IRL data from that region. That's over 35-59kt winds. The TR behaved incredibly strange, needing almost full right pedal to keep the nose stable when IGE hover. I have never ever experienced a helicopter requiring so much non-power pedal, not even in autorotation where torque demands are virtually zero. I'd never have noticed this or thought to test that way without those winds being present. The aircraft should have behaved as though it was in flight, with almost balanced pedal input. I recommend all who are interested in this bug try a flight with extremely high winds. Also look at the ball during those conditions, when I was flying the ball was insisting I use left pedal while keeping straight flight in that wind required constant right pedal. The ball seems to have been programmed to some other constants (forward speed, cyclic position) and not dependant on actual torque demands, pedal input and aircraft orientation.

Yes, all tracked units seem to be affected. Tracked units also seem to "spin" in a completely unrealistic manner if turning when applying acceleration from a start. Wheeled units like Humvee offer correct audio.

Same here.

I also get this. Right after rearming conformation, like you. Thought I was alone. I am trying to see how to recreate it, but typically after being shot down and then it CTD the next time I respawn and have to re-arm. I have also noticed it happens less when I do not have the NS430 turned on or the pop-up enabled. Also happens with KA-50 It primarily happens at FARPS on multiplayer servers.

CTRL+Enter is the default keybind to show controls. Works for me. Check your bindings.

Further to my last posts on locating the error. All faulty keybinds are restricted to the devices defined by three determining factors: They all belong to the device class: cockpit_device_id = devices.ELEC_INTERFACE, They all have a 3 digit identifier as seen in default.lua : device_commands.Button_120 They are all multi-action commands (ON/OFF, rheostat axis, CCW/CW, Cover OPEN/CLOSE) The identifier matches that found in the hash that is visible when you export the keyboard bindings to HTML. (export is of a default bind list) Example: d3120pnilunilcd1vd1vpnilvunil assigned to the action AC Ground Power Switch - ON/OFF Using that example, if we increment the device ID number in the hash identifier by 1, we get d3121pnilunilcd1vd-1vpnilvunil which is the hash for 115V Inverter Switch - Down action. Using the default keyboard binding for AC Ground Power Switch - ON/OFF which is LALT+LSHIFT+` then we notice the 115V Inverter Switch being activated instead. The finding is thus that the default keybind is activating the interface listed by the hash incremented by 1 for some of the faulty keys. The first bound key to suffer from this is the binding: RCtrl - 0 Battery Heating Switch - ON/OFF Right Side Panel d3107pnilunilcd1vd1vpnilvunil 106 is the first listed hash, but there is no device bound to it. Binding a key to it offers correct function as the d3106 hash is for the separate On or Off actions, and not the ON/OFF action for d3107. 106 and 107 are also unique in the default.lua in that they are the only commands with "cb_start_cmd +" instead of "device_commands.Button_" Additional findings were that while the keybinds were affecting hash+1, they were also affecting the TYPE of action for the interface as defined in clickabledata.lua The sequence of +1 is also not maintained strictly, indicating it is not merely an issue of decrementing some values to correct it. Example: LALT+LSHIFT+9, LALT+LSHIFT+0, LALT+LSHIFT+-, LALT+LSHIFT+= are for the Gen 1 Voltage Rheostats CCW, CW and Gen 2 Voltage Rheostat CCW, CW respectively. LALT+LSHIFT+9 (assigned hash d3124) instead activates the AC Voltage selector (hash d3123 device), but also causes it to turn like a rheostat (device_axis_limited in clickabledata.lua) instead of a clicking Position Switch (multiposition_switch in clickabledata.lua) The same happens for the DC Voltage selector (hash d3116) when you use the commands for the DC Rheostat (hash 117; LCTRL+LSHIFT+ -or=) This indicates that the command sent to the sim is activating the next or previous device according to hash number, but driving the action as per the correct hash identifier. What appears to be an anomaly is that the Multiposition_switch type action is not present. I suspect that the two multiposition switches (DC and AC Selector) in the devices.ELEC_INTERFACE are missing from where the sim looks up the desired action called by the keybind, and the other actions have "filled the gaps". Keybinds are calling the wrong action, but they are dragging their correct device behaviour with them. If the action they are calling can't perform the device behaviour, the action simply fails. This would also explain why keybinds for inputs assigned to hashes d3106-108 do not cause any action, and the same for hash d3126, and why the keys activate the hashes+1 before the DC selector, and hash-1 after the AC selector. Keys bound to single actions in the command list work as intended, *except* for the CCW/CW actions on multi_selector devices. Before and after these, multi action commands (ON/OFF) all fail. Sorry this is so round-about and not a short comment, but I'm hitting this blind and having to make assumptions about dependencies and references in the ED file structure. I don't know what role the hashes or device ID numbers play in this structure. Basically it's a "I think we should look here, and this is why." type of post. Good luck.

Thanks Flappie. This is new ground for me. Are there any approved guides that I can read to give me greater insight as to how the dependencies work between the lua files? For instance, am I right in thinking that macro_sequences.lua is actually looking up clickabledata.lua when it makes a call to "device_commands.Button_15" or is it referencing a different lua ort even a dll? Just to save me barking up the wrong tree and spouting inaccurate claims in trying to resolve my issues.

It's become obvious to me that there is a version control error for either Input>Keyboard>default.lua or Cockpit>Scripts>clickabledata.lua in the module files. To start with, I tried to find a command in the autostart macro that was not working. In autostart, the pilot's window does not close. Macro_sequences.lua is the autostart macro for the Mi-8. During the startup, the macro calls to close the pilot's seat "Blister" or window. The command calls push_start_command(1.0,{device = devices.CPT_MECH, action = device_commands.Button_15, value = 1.0}) clickabledata.lua uses the same Button variable when it specifies the type of action to be used: elements["PTR-BLISTER-LOCK-L"] = default_2_position_tumb(_("Left Blister, OPEN/CLOSE"),devices.CPT_MECH, device_commands.Button_15, 215) The default keybind does work for the pilot window. These are found in default.lua. default.lua has the following variable for the Blister (window): {combos = {{key = 'C', reformers = {'LCtrl'}}}, down = device_commands.Button_18, value_down = 1, cockpit_device_id = devices.CPT_MECH, name = _('Open/Close Left Blister'), category = _('Systems')}, The first two refer to device_commands_Button_15 while default.lua uses _18 It's clear that many of the default keybinds, are not calling the correct commands and are mismatched between the different lua's that reference them.

Thank you. I've tried searching for a solution or to see if it had been reported, but no luck with the search utility. As the post you linked is in French it did not flag for me.

Example: Commands list shows "LCTRL+LSHIFT+1" for "Battery 1 ON/OFF". However "LCTRL+LSHIFT+2" is the working key for "Battery 1 ON/OFF" even though that keybind is assigned to "Battery 2 ON/OFF" Findings: In the commands list, setting "LCTRL+LSHIFT+1" to the "Battery 1 ON" command allows the use of "LCTRL+LSHIFT+1" properly. In default.lua for keyboard input: "Battery 1 ON" has the entry of "device_commands.Button_3" "Battery 1 ON/OFF" has the entry of "device_commands.Button_111" All keybinds that use a 3 numeral identifier in the "device_commands.Button_XXX" entry in the default.lua used for input in the Mi-8 mod are faulty.

I understand and agree with your points, but isn't that quote exactly what a lot of those against the FM do to those who say they enjoy it? Every post where someone comments on how they enjoy it, regardless of faults, always has the same few people turn up to question their sanity and berate. This isn't a uni-directional issue.

Thanks, this is good to know.

Are you in the UK? I might be convinced to jump at the throttle, but don't want to get hammered with import duty from Europe. Thanks Brexit...

Yeah, it only kicks in as collective increases. The behaviour overall (again, I can only verify this as sample size = 1) is absolutely different to what I have previously experienced. The flight model doesn't puzzle me as much as how it has changed from one patch to the next, as though something fundamental underlying the communication from hardware (which hardware has not changed) has been altered.

I don't know why, or can't give you an explanation how, but this was a completely different aircraft for me. Perhaps this is why people quite often appear to be speaking of two different aircraft? Today, it didn't even need that. I can't explain why. When I discovered it, I restarted the mission and simple added a tiny bit of right pedal and lifted the collective to hover. Slight left drift due to the tail.

Okay, update. So I thought I'd load it up and fly again this morning, (I mostly use the other helos because they simply do more of what the Gaz does, on servers) and while this is anecdotal and a sample size of one, it's definitely "quirkier" than I remember it being prior to the Hind update. I've double checked all settings, and they're as they should be. The obvious difference to me is that I killed myself on lift-off multiple times, using the same technique as always. Really frustrating. Then I discovered it rises to hover without moving the cyclic. That never was the case before, and completely alien to how I know how to fly and how I've flown this module before. The standard pulling a bit of rear and right cyclic does not seem to be needed any more for take off. Perfectly level without any input. The cyclic diamond is on the middle of the cross in the controls indicator. Trying to "fly" it off the FARP in a manner that you normally would resulted in a dynamic rollover. It might be wind, I didn't bother deep testing but used the Caucasus quick action tank mission. Will have to verify on a self-built testing mission. Next, anti-torque requirements seem to be massively reduced. From personal experience flying fenestron equipped helicopters this is way off anyway (but something a lot of sim devs get wrong), but much more so than previous. I'm barely putting in any right pedal. A trainer like the Cabri G2 uses nearly 4/5 of its right pedal input when at the hover, nose into wind. And it's linear input, not logarithmic as all Fenestron tail rotors require. Last observation (I'm sure there are more, but I just did a quick flight) is that a centered stick (so no forward pressure of cyclic) with no trim flies a stable 100 kph. This doesn't happen, and previously was not the case from my previous experience with the same hardware and setup. It would appear that it's been made more spring centered table stick, with twist TR, than it was before. Once I stopped trying to "fly" it as muscle memory and real life experience has taught me, and I just tried to steer it like a novice would, it was piss easy. Perhaps the inputs ED code is sending from a static and centered stick to the module are much more "stabilised". So after this update I've shifted from "It's quirky but does the job" to "Does not reflect the physical world." in my attitude to the module. I'm going to have to triple and double check all module settings, because this truly is wonky to me now. I was prepared to give the devs leeway on it based on previous performance, but I think that the patch has cause a landmark deviance in how their interface works with it. If it is the case that the latest patch causes issues with their input coding then I'm not surprised they've gone radio silent and are spending a long time reworking their Kiowa. We definitely can't have ED code up two modules every time there's a patch.

To be fair, it was the second helicopter to be released. The only other helo with which it could be compared at the time was the huey due to the KA-50 being a completely different animal. The huey is still a whack flight model (it should definitely not let me do what I do with it), and only belsimtek seem to have modelled inertia properly, bringing that knowledge to the hind. I'm okay with the huey as it is, even with the obvious lack of inertia and it's very forgiving state. It allows new players top get a lot of fun. Empty servers are shit. They need to bottle what Belsimtek have created, and force all 3rd party devs to drink it down and follow its footsteps.

Yup. One chance. At the end of it, if the customer isn't satisfied *even after all the good things* then something needs to change. I think it's an artefact of an early era of DCS, where people thought that modelling and variety (3 different variants) was more important than fidelity and close integration with the DCS code base. If they had the ability to hand over FFB and related interface input to the DCS code then it might have fared better, but they had to add a layer of their own to accomplish it.

So you can land. Do you hover to do it or just "fly" it down to your landing spot? Are you asking about the auto-hover function? One thing to check, I discovered the other day that FFB got turned on in the Gazelle tab in options. It might have happened in the last update. I'm 100% sure it was off before hand. This screwed me up no end, never allowing a "zeroing" input value from the stick, never letting the aircraft become stable. A light touch forward kept nosing it down until I corrected, which kept raising the nose, which required a light touch forward... ad nauseum.

The main problem in this is the Gazelle is so much lower than the others. You keep thinking you should be down when you aren't, and relaxing attention on the hover or how much you're dropping collective. Being much closer to the rotor hub you're also inside the IGE envelope for a relatively longer time, making your collective inputs more important.

To be honest, a lot of people DO get it, even if they don't have FFB. Your statement has a bit of a gatekeeping scent to it, that unless people had FFB and experienced your problems then they didn't understand. Face it, the majority of customers on DCS do not own FFB sticks, or even centered sticks with extensions. To ignore that is to do the same thing you accuse others of doing. Every DCS module has to be developed for table mount, short sticks with longer sticks as a secondary. The game doesn't have to be even more exclusionary than it is. If Polychop are supplying table top sticks to actual ALAT pilots and the pilots are telling them it "feels ok" then can they really be blamed for not knowing themselves? Look at all the actual pilots in DCS that focus helos, like Casmo, Hell_Gato, Barundus, and Gimbal who have come out and stated clearly that it is very twitchy, but that they compensate, like all real pilots do to differences between airframes and types. I've been in the same type of helicopter and airframe and had them both handle like they were made by different companies. I don't care if the stick is 5 degrees to the right or left of the other for any given manoeuvre, or that it lacked power in comparison, it was my role to adjust. Same with the dcs helo modules. The hind is out. you can barrel roll it, loop it, and do all sort of other fucking stupid shit with it that is obviously not indicative of a healthy FM, but guess what everyone has done (including you, if you have it) they've compensated. I have no doubt that the initial brutality it's been treating inexperienced players with is going to get smoothed by ED, to make it easier on them. Exactly like their preferential treatment of short sticks on tables. Exactly like them toning down VRS. The problem a lot of people "don't get the angle" on is what is the real problem you have? What about the FM stops you from actually piloting it or doing things in the game that other modules do? Can you fly it? Can you navigate it? Can you utilise weapons or complete tasks in it? Their attitude is "If you can do those, then what is the issue?" and it is equally valid as yours in your criticism of it. Yes, we've all seen the videos from several years ago of flying upside down, but that's like complaining the devs in GTA didn't model cars sinking in water properly if you landed in a river or something like that. It just something you don't intend doing if you're serious about "realism" flying and it's not something any dev would seriously claim to spending time thinking about. It's exactly like the hind is right now with its loops and rolls. "We didn't model what would happen when you loop a hind because you're not meant to be doing it!" If it's "wrong" then all they will do is add a code switch (like PC did) that goes something like if inverted then main_rotor_eject_and_die_in_flames. I don't think the FM is perfect. In fact I think it's lacking in a lot of aspects, but that's mainly down to me and my equipment and my general enjoyment of its role in the DCS environment as a whole. People like those in Black Shark Den, who demand a high standard from pilots and modules, seem to do just fine with it but this rests largely on them running scenarios that favour its role. There's too few servers that utilize it properly, and too few campaigns written for it for me to derive pleasure from it like the others. I hope they do get it right, with the importing of the Kiowa FM interface replacing the code layer they had to apply to get where they have with the Gazelle. Rewriting that code layer tells us that even they think they hit a theoretical and realistic limit to it and it needs to be wiped to play properly with DCS as it currently stands. Hopefully they've learnt their lesson and I think they have because all communications appear to tell me that they don't just hope to sell the Kiowa to DCS players, but to Bell themselves which will have a higher selling price for them but also indicates a requirement for a much higher fidelity model. They've basically got one last chance.