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.