ThePops

Meaning that the stable version of DCS is not stable? Anyway, excellent asset packs, and most of them works just perfect also in the stable unstable version of DCS Maybe I should switch to the beta, it's just that I have no urge to update the sim every two weeks.

Made a separate track just for the helicopters. At least in my DCS (2.9 stable) none of the KAs raise the gears, and none of the two HKP 15Bs lands, they just stay hovering. This time, one of them first stay hovering, then run off, comes back and continue hovering forever. The route is just take off from ramp, two waypoints at 1500 feet, then land at the same field. 1.1.0 Russia asset pack. CH-test-heli.trk

The landing is an ordinary air base (airport). Other helicopters land just fine, the HKP just stay hovering 1 feet off the ground forever.

What a truly amazing piece of work Absolutely incredible. One thing I noticed. The HKP 15B does not seem to land again. It just stay hovering at 1 feet forever. I have only tried at the Caucasus map. Sometimes it do land, but more often than not, it doesn't (no apparent regularity or reason that I could see). Another thing is the KA-52 does not retract the landing gear when flying.

OK, thanks I'm afraid it's a bit over my competence to look inside (and understand) the code though but thanks anyway, maybe some day I get the time.

Hello Just tried it, and I can read data in the dcs-insight.exe application. Is it possible to use other applications? There's an IP and a port, UDP ?

Only a 4 position switch would help here, since the mags are implemented as one of 4 positions shall be ON (for the modules in the sim). With a 3 position, there will always be 1 of 3 positions that is ON, one position will be missing. A 3 position with a push button, like on the Orion 2, will not help. I like my WinWing setup, but it's better suited for F-18/18/15 etc modules than a FW-190 for instance It wouldn't hurt if WinWIng was a bit more generic, but there are other manufacturers that are. The root of the mag "problem" is obviously that a quasi implementation of the mag switch is done, and not an implementation of the mag switch functionality. It's also in error in fact. A real mag switch does not have an active OFF state, it's simply the absence of ON state(s). The functionality is simply to put mag1 on and off, and mag2 on and off. This requires only two buttons. The problem with implementing it as two buttons, is that this would be incompatible with a 4 way switch, if you happen to have one. It would need additional scripting to map: OFF OFF to 4 way switch OFF ON OFF to 4 way switch Mag1 OFF ON to 4 way switch Mag2 ON ON to 4 way switch Mag1+Mag2 The solution is if the module builders could implement the functionality as well as the "buttonology" and give the user the choice to pick what is best for his gadgets. The other solution is called Joystick Gremlin Ex and a plugin I don't know, it seems to me this is more typical of DCS than other sims. It sort of scratches the surface, but doesn't go into the functionality of things, like for instance X-Plane, or even Il-2. DCS is kind of "buttonology over function", which is kind of weird all the time only extremely few have a true replica cockpit of any aircraft in their homes. If they had, they would be much better of with mapping of functions anyway, like it's done in X-plane for instance for pro simulators. Which is also kind of weird, because X-Plane started out requiring only the use of a mouse to manipulate switches in the cockpit. It was one of the major selling points in the beginning: No need to remember tons of awkward keyboard key strokes (like in MSFS at that time), "use point and click for everything". A bit like DCS today, as well as most others today. Unless you have a practical way to implement functionality on your controllers that actually works, you are better off using the mouse point and click method. This makes this tendency of "buttonology over function" even stranger IMO. Some modules do have some basic functional approach also though for some stuff, which I like. Btw, there is a bug in the I-16 module regarding mag switch. It can only be turned to Mag 1 and Mag 2 by mouse clicking. Using switches it would either be OFF or Mag1+Mag2 regardless. But, with Gremlin Ex and plugins, everything can be solved to your liking It's an additional layer, and it takes some computer recourses though, it's not a perfect solution. Ex is much faster than the old Gremlin (newer and faster Python), so it's not too bad either.

I thing that has irritated me with several modules for piston aircraft is the Mag switch implementation. The de facto standard for Mag switches is: A 4 way rotary/sliding switch (In GA, it's sometimes 5 way with starter as the fifth) Two two-way switches (+ a starter button) They both do exactly the same thing physically with regards to the ignition systems. They switch the Mags (or ignition systems) to: OFF OFF : (OFF) ON OFF : (Mag 1) OFF ON : (Mag 2) ON ON : (Mag1 + Mag2) The problem (for me at least), is they are implemented in the modules as 4 separate buttons. One for each position of a 4 way switch (one also for the off position, which is actually pretty weird when thinking about it ). Unless I actually have a physical 4-way switch, this makes no sense to map to my controller, it simply isn't possible in any natural way. There are no 4-way switches on my WinWing. I do however have lots of two-way switches I don't use in any piston aicraft. Anyway, with Joystick Gremlin Ex and vJoy this is easily fixed as a plugin (I only use Ex now, since the original Gremlin is full of bugs when working with plugins, probably due to using older libraries, don't know). The way I did it was to use two two way switches, thus simulating the "other way" to implement Mags. Be aware that in the Gremlin app when configuring switches for a plugin, it will detect the first event regardless. When flipping a two way switch, the first event is usually (but not always) to turn the existing switch OFF before turning the other switch ON. Thus you may have to switch in "reverse" to actually get the correct button. It's only the "ON" position of each switch that is necessary to configure in Gremlin. In case someone else also have this "problem", the plugin is included below. magneto_fix_v00_EX.py

An update and improvements. I tried using some usable axis on the throttle as brake instead of my usual slider on my stick, and run into trouble. The plugin above assumes that each axis starts at -1.0 and ends at 1.0 (in Gremlin scaling). This is often the case, but far from always, which is the reason axis can be inverted in all games. In addition, many axis are spring loaded to mid point position. If using that axis as a brake, you would typically only use half of that axis. When using an axis going from 0 (zero braking) to -1 (full braking) for instance, this needs to be scaled appropriately This new plugin is updated to account for that. Both brake and rudder axis can now start at any point and end at any point, fully user configurable. However, I then discovered a bug in Joystick Gremlin 13.3. The input field for the plugin FloatVariable is bugged. It does not import the correct default value, it does not use the correct min and max values, and can only take numbers from 0.0 to 99.99. This was a bummer, especially since the software is no longer updated. What I did was to make the Python file itself easy configurable. It's called brake_sticknrudder_v02.py below. It's all explained in the comments in the file. A bit of Googling I found that Joystick Gremlin actually IS being updated. A person has forked off version 13.3, and it's now version 13.40.3. The updates include 64 bit (was 32 bit), newer Python (much faster), newer Qt and a host of other improvements. This new version is called Joystick Gremlin Ex and can be found here (look at the right side for the release version). And wouldn't you know, the input field bug is fixed as well I made another plugin for Gremlin Ex. This will only work in Gremlin Ex, because it creates a divide by zero error in 13.3 due to the default values being set to zero. This file is called brake_sticknrudder_v02_EX.py The Ex version does not have an installer, just unzip it to some folder (not the Program Files folder). It uses the same profile files as the 13.3 version, and you can run either one (not at the same time though). brake_sticknrudder_v02.py brake_sticknrudder_v02_EX.py

Hello, and merry Christmas This is a plugin for JoystickGremlin to map an analog slider and rudder pedals to work like a typical Russian WWII fighter, Spitfire and many GA aircraft. Or simply to have proper braking in any sim when using T-Rudder pedals What's needed is: A stick (or a throttle) with a an extra analogue slider or rotation to work as brakes (I have a WinWing F-16 stick with enough sliders) VKB T-Rudder pedals (any pedals will obviously work, but none as well as a T-Rudder ) vJoy software JoystickGremlin software The plugin itself (further down) For the basics of vJoy and Joystick Gremlin I suggest reading this excellent post. In addition HidHide could be useful in general, but it's not needed for the purpose here. First you need to set up vJoy. The only thing needed is two axis. Any axis will do. As a minimum one vJoy device with 2 axis is needed. Then Joystick Gremlin and the plugin must be set up. There is no need to configure anything at this point (like remapping, curves etc), because the plugin will handle everything. I tried this a year or so ago looking at plugins, but gave up because I couldn't for the life of me figure out how these plugins even were supposed to work. Looking at the plugin examples, they have no detailed hardware addresses or anything... It turned out that this Gremlin software is truly amazing, although lacking in documentation. In the mean time I made my own brake pedals that works, sort of, but with none of the precise control you get with a proper brake/rudder mix. The plugin itself is a small Python script. I merely "hacked" one of the examples. It can be downloaded below, or simply cutn paste. An important thing is that the plugin does not work by itself. It must be imported and configured into Joystick Gremlin. This is done by opening Joystick Gremlin, chose the plugin tab and the Add Plugin button at the bottom. Once the file is chosen, it will look like this: At this stage the plugin must be configured. Just push the configure button, and a set of configurable setting (all that is needed) pops up to the right. There you map the physical brake and rudder axis to the corresponding virtual axis that was made in the first step. The activate button can be on or off. Remember to save the configuration, or Joystick Gremlin will forget all about it when you close, and there is no reminder before closing. You can view if everything is working in the viewer in the tools menu. I found that sometimes when a tried a new plugin, I had to push the activate button on and off a few times etc before it worked, but that could easily have been due to my plugin not working properly (with a working plugin, it just works). For those who have tried IL-2, this brake/rudder mix works exactly as that (which is exactly as it works in the real aircraft). It requires a tiny bit of getting used to if you have tried only brake pedals, but we're talking minutes, not hours. A real Piper Cub has heel brakes, also fundamentally different from toe brakes, but more intuitive actually, and easily adopted. It's fully possible to tweak the brake input to use 2 or 3 buttons instead of a slider, or even just one single button, but the finer feeling and precise control will then be limited. import math import gremlin from gremlin.user_plugin import * mode = ModeVariable("Mode", "Mode in which to use these settings") pa_brake = PhysicalInputVariable( "Physical brake Axis", "Physical brake axis input", [gremlin.common.InputType.JoystickAxis] ) pa_rudder = PhysicalInputVariable( "Physical rudder Axis", "Physical rudder axis input", [gremlin.common.InputType.JoystickAxis] ) va_leftBrake = VirtualInputVariable( "vJoy left brake Axis", "Virtual left brake axis output", [gremlin.common.InputType.JoystickAxis] ) va_rightBrake = VirtualInputVariable( "vJoy right brake Axis", "Virtual right brake axis output", [gremlin.common.InputType.JoystickAxis] ) # Decorators for the two physical axes dec_brake = pa_brake.create_decorator(mode.value) dec_rudder = pa_rudder.create_decorator(mode.value) # Storage for the last known axis values brake_value = 0.0 rudder_value = 0.0 def update_vjoy(vjoy): leftRudder = rudder_value rightRudder = -rudder_value if leftRudder > 0.0: leftBrake = min(-2.0*leftRudder + 1.0, brake_value) else: leftBrake = brake_value if rightRudder > 0.0: rightBrake = min(-2.0*rightRudder + 1.0, brake_value) else: rightBrake = brake_value vjoy[va_leftBrake.vjoy_id].axis(va_leftBrake.input_id).value = leftBrake vjoy[va_rightBrake.vjoy_id].axis(va_rightBrake.input_id).value = rightBrake @dec_brake.axis(pa_brake.input_id) def axis1(event, vjoy): global brake_value brake_value = event.value update_vjoy(vjoy) @dec_rudder.axis(pa_rudder.input_id) def axis2(event, vjoy): global rudder_value rudder_value = event.value update_vjoy(vjoy) brake_sticknrudder.py