Jump to content


  • Posts

  • Joined

  • Last visited

About WillyPete

  • Birthday 01/01/1870

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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...
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  • Create New...