This gives you the most physical influence, being from 100% up collective to 30-40% down collective having an affect, with the remainder having no effect (in Basic Flight Model). The closest solution I have found is to map both + and - to "Collective raise (analogue)" and just - to "Collective lower (analogue)".
UNIVERSAL CONTROL REMAPPER JOYSTICK SENSITIVITY FULL
Full down collective is achieved at 50% physical controller travel. The whole forward half (or back, depending on how you have the axes set up) has zero influece. You only get one half of the physical collective throw affecting the in-game collective. I tested this as recently as this morning (Nov 18, 2014) and it doesn't work this way. For example with Hummingbird a hover can be maintained with collective around 60% with SFM and around 50% with AFM.)" (This way it gives you exact control over the collective in 0-100% range both with Standard and Advanced flight model. I will try to investigate what may be causing the issues. If you still experience problems, please send me ( ) a screenshots of your mapping in A3 and settings in the Saitek profile. Make sure you are mapping only one of the levers and you have it set as linear in its full extend. For example with Hummingbird a hover can be maintained with collective around 60% with SFM and around 50% with - I've noticed you are using x55, which afaik handles throttle as a X/Y axes, not a slider.
Collective - half of the chose axis has to be mapped on Collective raise (Analogue) the other half on Collective lower (Analogue). Airbrake - both halves of the chosen axis have to be mapped on Brake (Analogue). 
Throttle - both halves of the chosen axis have to be mapped on Throttle (Analogue). To have the full extent of one axis used on an action it has to be mapped this way: Plugins can be organised into Profiles, and there are plugins which allow you to change profile using inputs, so you can make “Shift States”.Ok, let's sum it up. This makes it easy for the end-user to add the configuration options that they need, leaving them with only the logic that connects them to worry about. Regular Controls (EditBoxes etc) can also be added, and the values the user enters into these will automatically be remembered between runs, and their value is always easily accessible by the plugin code. When you add an Output Control, you are given an object which you can call methods on to set the state of the output which the end-user selected. When you add an Input Control, you can pass a callback to be called when the input changes state. Input and Output GuiControls are custom GuiControls which allow the end-user, at run time, to select what inputs and outputs to use. This is done through a collection of custom GuiControls. In order to do so, you create a plugin file, and define it’s inputs, outputs, and configuration options. So with all the tools in place, I decided upon the following broad architecture:įrom an end-user’s perspective, everything boils down ultimately to a plugin.Ī plugin generally does one single unit of work – eg “Map X to Y”.Ī number of basic plugins are provided (Map Button to Button, Axis To Axis, Button and Axis to each other etc) but as mentioned, it is intended to be as simple as possible to create a new plugin. Luckily, there is a fork of AutoHotkey called AutoHotkey_H which does the first two, and the author is a rather amenable chap, and we collaborated to implement dynamic scrollable GUIs in AHK_H’s C++ source code. I needed resizable, scrollable, dynamic GUIs. I needed to be able to spin up multiple copies of AHK (To detect input, and allow multiple profiles, and rapid profile switching) I needed to be able to dynamically include a script which derived from a class in the main (running) code. The limitations of what I could do in AHK presented the following hurdles: Towards the end of 2015, I started examining what would be required to achieve such a goal. Something where end-users could add new features themselves? What if you could build something like UJR, but modular, and working with many kinds of inputs. The success of UJR surprised me – it seemed to plug a gap in the market and seemed to have rapidly become the go-to tool to fix numerous joystick woes.
0 kommentar(er)
