WhiteMagic
commented
4 years ago With regards to the first issue, I can't say what causes this as behind the scenes there is no difference between a "Map to Keyboard" action and a "Macro" action as you've described it. The map to keyboard action simplifies the process and ties the macro into another helper to ensure the macro is stopped when a mode is changed. As for the delay between actions, I think in this version https://my.pcloud.com/publink/show?code=XZzBCG7ZYQqx7BCGr5QH90srhAocxLFxpMAk I've added an option to change it on a per profile level, i.e., "Settings" tab, for all macros. All macros will wait a pre-specified amount of time between executing the individual events they contain unless a pause has been manually added.
As for support, I haven't bothered setting up donations or similar things. One of the reasons is that I'd have to figure out what this means for tax purposes, and I'd rather spend that time working on the program :-) So just reporting issues you run into is just fine with me.
Yeah, moving bits of a configuration around is something that's never been something that the UI tried to support. Mainly because it started rather simple and grew over time, so retrofitting would not have been easy. The next release will change a lot of things, including the UI and how actions are treated. As part of that, I'm thinking of trying to get drag and drop stuff working, and even if that won't make it in at least moving actions between inputs, etc. should be much simplified. For an overview of some of the things planned, you can read over this https://whitemagic.github.io/JoystickGremlin/r14/index.html
A large part of why condition-based things are a bit clunky is that they were used to unify things that earlier versions had as separate options, like the "trigger on release/press". Part of the reason for this was the complex interactions between containers and actions. Some of the things you mention could be implemented using plugins, though that would not add new dynamic "buttons" to the UI. The changes planned for R14 might make some of these things simpler or even possible to implement, but time will tell.
You can change the default action shown in the drop-down menu in the options dialog. I didn't want to assume what is the most used option, so I allow people to change that.
Yeah, an input vJoy device cannot also be an output vJoy device. The reason is that a vJoy device can only be owned by a single process. This means that if an external program is populating a vJoy device, then Gremlin cannot write to it as well. A typical use case for this feature is that another program reads data from a non-DirectInput device and feeds that into a vJoy device. If the user then wants to modify or change that input, the vJoy device would be defined as an input device in Gremlin. This forces Gremlin to use that vJoy device's data read as DirectInput, and treat it like any other physical device. Now, if some response curve etc. should be applied, then the input vJoy device will have to be remapped to an output vJoy device as it's impossible to write to the input vJoy device as vJoy itself prohibits this.
BenBlake79
I do not know if this occours everywhere, i had this issue with tempo and map to key for x-wing. Sometimes it works as it should - Shift + a gives an "A" - and sometimes it doesn't and gives an "a". So I used Macros with "press Shift - press a - release a - release Shift" to make it work. But this way it is not possible to hold the keys. I'd say there should be a short delay (maybe shorter than for macros is enough?) in "map to key" mode, maybe managable in the settings just in case that the time differs on different hardware in the same manner as it works for macro delay?
Great program, thank you very much. Just startet to use it as a replacement for TMs TARGET sw a week ago. How can I support you? Is it possible to make donations?
One thing that frustrates me is that it is not possible to change order of different actions or contaners without deleting the first and setting it or them up again. A drag and drop feature and copy/cut out and past feature (maybe with a second board as an extended clipboard) would be nice. Use it with the opened xml in Notepad++ at the moment and make such manipulations there an then load the profile again. For this workaround a simple reload button was helpful...
I am used to the Saitek Profiler and so setting up some features (Shift function as Joystick-Condition, axis splitting to make an input x times when moving an axis from -100 to +100 - my workaround was to make the calculations and code setup in Excel and pasting them in Notepad++) seem a little fiddly to me. An "autosplitter" which automaticly devides an axis in x parts and 1 or 2 or 3 shift-keys that can be set up globaly and then checked on the primary action page would be nice features. The same goes for the action condition which would be 2 checkboxes (pressed/released / fowards/backwards for axes) that can easily be fitted into the primary action page. This way it also would be easy to check much of a more complex setting with a single glance...
To define starting options for the drop down menus would be nice as well as it always starts with "map to button" and this is the action I (and most people?) use the least... (I think "map to key" is used the most btw.)
I do not know if it is intended this way but when a vjoy device is set up as input device it is not longer possible to use it as a target so "physical joystick => vjoy#2 => vjoy#1" with manipulations on the way is not possible but until now no situation occured to me that could only be solved this way... When I thought I would need this feature I worked around somehow - I do not even know anymore what it was...