Just putting it out there - BINDINGS.... AHHGGGGGG!!!

GunnerBill

GunnerBill
I eventually had to retire my T16000M joystick after 2,500 hrs of Elite Dangerous gaming! And not because of the Twist Yaw but the fire buttons had more or less failed.

Because of the poor reviews of the Twist Yaw on the Thrustmaster I decided to go for the VKB Gladiator NXT with Premium grip. This isn't a review of the new stick although it is great and the software is a bit confusing! No my gripe is with the ED bindings system and perhaps a little bit of my own fault.

In addition to having to rebind all the keys and buttons despite only changing the stick I spent hours trying to set up and calibrate my VKB. I couldn't stop the X Axis (pitch) from drifting. It was doing my head in - Grrrr.

It was only by accident that I noticed the ship pitched slightly when I moved the mouse ... YES I didn't realise that in resetting the bindings ED had added the mouse to the flight rotation axes even though I had assigned those to the new stick. Nothing wrong with the joystick but slight movement on the mouse caused the drift.

TL;DR - when you set up new bindings with a joystick uncheck the mouse from flight rotation axes because the game will let you have both!
 
Last edited:

Navigare Necesse Est

Navigare Necesse Est
If I get past the account shenanigans, because a Steam account somehow doesn't suffice for ED, I'd have to prove somehow I got the game via the e-Mail account that is long lost now and not via Steam. I then would need to reconfigure all the bindings. After which I would have to catch up to all the power creep.

I'm fairly sure it's never happening.
 

Drelthar

Drelthar
There are a couple of things you could have done to avoid having to bind everything again.

Though you absolutely shouldn't have to.

If you kept the old joystick plugged in, and then bound your controls to the new stick, making sure every single binding that was on the old stick is removed, you'd only have to bind the new stick stuff (instead of losing everything and starting from scratch)

You can also open the specific bindings file for that profile, and remove references to the old stick - this would allow you to load the old profile up and then bind to the new stick.

The problem is that if a device is bound in a profile, and the device isn't plugged in, it won't load the profile (or a copy of it) without that item bound, it will just fail to load the profile at all.

Pretty terrible design really.
 

Ian Skippy

Ian Skippy
Drelthar said:
There are a couple of things you could have done to avoid having to bind everything again.

Though you absolutely shouldn't have to.

If you kept the old joystick plugged in, and then bound your controls to the new stick, making sure every single binding that was on the old stick is removed, you'd only have to bind the new stick stuff (instead of losing everything and starting from scratch)

You can also open the specific bindings file for that profile, and remove references to the old stick - this would allow you to load the old profile up and then bind to the new stick.

The problem is that if a device is bound in a profile, and the device isn't plugged in, it won't load the profile (or a copy of it) without that item bound, it will just fail to load the profile at all.

Pretty terrible design really.
Click to expand...
Or when the windows ID code changes for a device, which can happen for example when changing usb ports, it will fail to load. It's hands down the worst design I have ever seen in three decades of gaming.
 

Drelthar

Drelthar
Ian Skippy said:
Or when the windows ID code changes for a device, which can happen for example when changing usb ports, it will fail to load. It's hands down the worst design I have ever seen in three decades of gaming.
Click to expand...
That too, though things are better there than previously (still happens though), it seems to use the device name now, which tends to stay the same (though my ED Tracker changed names once or twice)
 

taniwha-qf

taniwha-qf
Ian Skippy said:
Or when the windows ID code changes for a device, which can happen for example when changing usb ports, it will fail to load. It's hands down the worst design I have ever seen in three decades of gaming.
Click to expand...
The problem here, I think, is ED trying to keep bindings consistent across devices when multiple devices are the same (eg, dual joysticks of the same make and model). The root cause is many USB devices do not provide a unique id (like ethernet ports do), so the next best thing is the usb path, which will change when you change ports (obviously). I've done something like this in my recent work on QuakeForge's input system: devices are identified by device name (which most (if not all) devices do provide), and device unique id if available or usb path if not. The binding system uses only the device name by default, but the unique id/path if requested. Using only the name makes changing usb ports a non-issue, but causes problems for dual-wielding. Using name+path (since id is generally not available) works well (or should, I don't have sufficient hardware to test) for dual-wielding, but causes problems for moving ports. It does, however mean you can change what devices is in that particular usb port without causing problems (since the name will change).

Actually, a lot of my design decisions were influenced by my experiences with ED's binding system and some of the things I've heard about it.
 
Last edited:

Drelthar

Drelthar
taniwha-qf said:
The problem here, I think, is ED trying to keep bindings consistent across devices when multiple devices are the same (eg, dual joysticks of the same make and model). The root cause is many USB devices do not provide a unique id (like ethernet ports do), so the next best thing is the usb path, which will change when you change ports (obviously). I've done something like this in my recent work on QuakeForge's input system: devices are identified by device name (which most (if not all) devices do provide), and device unique id if available or usb path if not. The binding system uses only the device name by default, but the unique id/path if requested. Using only the name makes changing usb ports a non-issue, but causes problems for duplicate dual-wielding. Using name+path (since id is generally not available) works well (or should, I don't have sufficient hardware to test) for dual-wielding, but causes problems for moving ports. It does, however mean you can change what devices is in that particular usb port without causing problems (since the name will change).

Actually, a lot of my design decisions were influenced by my experiences with ED's binding system and some of the things I've heard about it.
Click to expand...

Yeah, I mean, all of the above stuff is actually fine - the main problem is not loading the profile at all if one device can't be found.
It should just make a duplicate profile, without the devices it couldn't find, and give you a warning message saying which device(s) it can't find.

I use about... 5.. 6? not sure? devices in one profile - so not just removing the one device I don't have plugged in is kind of annoying.
 

taniwha-qf

taniwha-qf
Drelthar said:
Yeah, I mean, all of the above stuff is actually fine - the main problem is not loading the profile at all if one device can't be found.
It should just make a duplicate profile, without the devices it couldn't find, and give you a warning message saying which device(s) it can't find.

I use about... 5.. 6? not sure? devices in one profile - so not just removing the one device I don't have plugged in is kind of annoying.
Click to expand...
That is one of the horror stories I heard that influenced my design. Missing devices don't affect the profile at all: information about the device is recorded so its bindings don't get lost, but those bindings are simply not connected to a device and thus don't get activated (because there's no device to activate them).
 

Drelthar

Drelthar
Oh yeah, the profile is still there, doesn't get deleted, just doesn't load up.

However, if you just use the default "custom" profile, you can end up overwriting it.

It's just... a really weird way of handling things.
 

taniwha-qf

taniwha-qf
Yeah, profiles should be based only on game mode, not what devices are connected (once bound, always bound). Have to wonder how much of it is due to ED allowing only two inputs bound to one action, and only one action per input.
 

Navigare Necesse Est

Navigare Necesse Est
taniwha-qf said:
That is one of the horror stories I heard that influenced my design. Missing devices don't affect the profile at all: information about the device is recorded so its bindings don't get lost, but those bindings are simply not connected to a device and thus don't get activated (because there's no device to activate them).
Click to expand...
Your "design"?
 

CMDR Harada

CMDR Harada
Congrats on the new stick. You'll find the VKB is a nice step up from the T16k. I know I was amazed.

For bindings, I found that I could use the VKB software ( powerful, but obscure and arcane to say the least ) to map buttons on the JS to keyboard keys in a profile. IE: The button on the joystick to drop landing gear was mapped in the JS profile to match the keyboard shortcut in elite. This way I never modded the ED defaults, and have never had an issue with bindings again. The only problem is playing another game, where I have to load another profile to the JS.
 

GunnerBill

GunnerBill
Drelthar said:
There are a couple of things you could have done to avoid having to bind everything again.

Though you absolutely shouldn't have to.

If you kept the old joystick plugged in, and then bound your controls to the new stick, making sure every single binding that was on the old stick is removed, you'd only have to bind the new stick stuff (instead of losing everything and starting from scratch)

You can also open the specific bindings file for that profile, and remove references to the old stick - this would allow you to load the old profile up and then bind to the new stick.

The problem is that if a device is bound in a profile, and the device isn't plugged in, it won't load the profile (or a copy of it) without that item bound, it will just fail to load the profile at all.

Pretty terrible design really.
Click to expand...

That's some excellent advice, thanks!

CMDR Harada said:
Congrats on the new stick. You'll find the VKB is a nice step up from the T16k. I know I was amazed.

For bindings, I found that I could use the VKB software ( powerful, but obscure and arcane to say the least ) to map buttons on the JS to keyboard keys in a profile. IE: The button on the joystick to drop landing gear was mapped in the JS profile to match the keyboard shortcut in elite. This way I never modded the ED defaults, and have never had an issue with bindings again. The only problem is playing another game, where I have to load another profile to the JS.
Click to expand...


Cheers! It's weird but it feels like manoeuvring is slower and more serene with the Gladiator but it isn't slower at all.

I hadn't realised how bad various buttons on my old stick had got, even the thrusters on the T16000M hat must have been responding badly. Interesting about the button mapping but I'm way to far down the line for that!
 
Last edited:

taniwha-qf

taniwha-qf
Navigare Necesse Est said:
Your "design"?
Click to expand...
Yes. I redesigned QuakeForge's input and binding system (haven't push the code yet, so you can't look *). QuakeForge is one of many quake engines based on the original source release back in December 1999 (yes, I've been working on it for 21 years). https://github.com/quakeforge/quakeforge

* You can't look at the code yet, but...:
Code: 
{
    input = {
        contexts = (
            {
                name = key_game;
                imts = (
                    {
                        name = imt_mod;
                    },
                    {
                        name = imt_mod_strafe;
                        chain = imt_mod;
                    },
                    {
                        name = imt_mod_freelook;
                        chain = imt_mod;
                    },
                    {
                        name = imt_mod_lookstrafe;
                        chain = imt_mod_freelook;
                    }
                );
                default_imt = imt_mod;
                switchers = (
                    {
                        name = mouse;
                        inputs = (
                            +strafe,
                            lookstrafe,
                            +mlook,
                            freelook
                        );
                        imts = (
                            imt_mod,
                            imt_mod_strafe,
                            imt_mod,
                            imt_mod_strafe,
                            imt_mod_freelook,
                            imt_mod_strafe,
                            imt_mod_lookstrafe,
                            imt_mod_strafe,
                            imt_mod_freelook,
                            imt_mod_strafe,
                            imt_mod_lookstrafe,
                            imt_mod_strafe,
                            imt_mod_freelook,
                            imt_mod_strafe,
                            imt_mod_lookstrafe,
                            imt_mod_strafe
                        );
                    }
                );
            },
            {
                name = key_demo;
            }
        );
        devices = (
            {
                name = mouse;
                devname = core:mouse;
                num_axes = 2;
                num_buttons = 32;
                axes = (
                    {
                        imt = imt_mod;
                        num = 0;
                        axis = move.yaw;
                        min = 0;
                        max = 0;
                        minzone = 0;
                        maxzone = 0;
                        deadzone = 0;
                        curve = 1;
                        scale = 1;
                    },
                    {
                        imt = imt_mod_strafe;
                        num = 0;
                        axis = move.side;
                        min = 0;
                        max = 0;
                        minzone = 0;
                        maxzone = 0;
                        deadzone = 0;
                        curve = 1;
                        scale = 1;
                    },
                    {
                        imt = imt_mod_lookstrafe;
                        num = 0;
                        axis = move.side;
                        min = 0;
                        max = 0;
                        minzone = 0;
                        maxzone = 0;
                        deadzone = 0;
                        curve = 1;
                        scale = 1;
                    },
                    {
                        imt = imt_mod;
                        num = 1;
                        axis = move.forward;
                        min = 0;
                        max = 0;
                        minzone = 0;
                        maxzone = 0;
                        deadzone = 0;
                        curve = 1;
                        scale = 1;
                    },
                    {
                        imt = imt_mod_freelook;
                        num = 1;
                        axis = move.pitch;
                        min = 0;
                        max = 0;
                        minzone = 0;
                        maxzone = 0;
                        deadzone = 0;
                        curve = 1;
                        scale = 1;
                    }
                );
                buttons = (
                    {
                        imt = imt_mod;
                        num = 0;
                        binding = +attack;
                    },
                    {
                        imt = imt_mod;
                        num = 1;
                        binding = +mlook;
                    },
                    {
                        imt = imt_mod;
                        num = 2;
                        binding = +forward;
                    },
                    {
                        imt = imt_mod;
                        num = 3;
                        binding = z_in;
                    },
                    {
                        imt = imt_mod;
                        num = 4;
                        binding = z_out;
                    }
                );
            },
            {
                name = key;
                devname = core:keyboard;
                num_axes = 0;
                num_buttons = 256;
                buttons = (
                    {
                        imt = imt_mod;
                        num = 1;
                        binding = togglemenu;
                    },
                    ... (lots cut out)
                );
            }
        );
    };
}
 

Ian Skippy

Ian Skippy
taniwha-qf said:
The problem here, I think, is ED trying to keep bindings consistent across devices when multiple devices are the same (eg, dual joysticks of the same make and model). The root cause is many USB devices do not provide a unique id (like ethernet ports do), so the next best thing is the usb path, which will change when you change ports (obviously). I've done something like this in my recent work on QuakeForge's input system: devices are identified by device name (which most (if not all) devices do provide), and device unique id if available or usb path if not. The binding system uses only the device name by default, but the unique id/path if requested. Using only the name makes changing usb ports a non-issue, but causes problems for dual-wielding. Using name+path (since id is generally not available) works well (or should, I don't have sufficient hardware to test) for dual-wielding, but causes problems for moving ports. It does, however mean you can change what devices is in that particular usb port without causing problems (since the name will change).

Actually, a lot of my design decisions were influenced by my experiences with ED's binding system and some of the things I've heard about it.
Click to expand...
But it really shouldn't be too hard to check if a present actually uses two devices of the same make and model. Right now you get ED to go "Hmm, you had a preset with one joystick, and now you start the game with the exact same joystick in a different port. Better not load anything, might be a different joystick of the same make and model that you may one day use together with the other one." Its fine to check for stuff, and be prepared for complex stuff. Its weird to do literally nothing when a very common thing happens on the off-chance something much rarer happens.
 

taniwha-qf

taniwha-qf
Ian Skippy said:
But it really shouldn't be too hard to check if a present actually uses two devices of the same make and model. Right now you get ED to go "Hmm, you had a preset with one joystick, and now you start the game with the exact same joystick in a different port. Better not load anything, might be a different joystick of the same make and model that you may one day use together with the other one." Its fine to check for stuff, and be prepared for complex stuff. Its weird to do literally nothing when a very common thing happens on the off-chance something much rarer happens.
Click to expand...
Yeah, which is why QF defaults to checking just the device name, seeing "3Dconnexion SpaceNavigator" and saying, "oh, look, you plugged your 3d mouse into some random port, I guess you want to connect that to your spacemouse bindings", but if I'd asked for it to check the id as well, it would not connect the bindings to the device (I do plan on adding an option to reset the id). Like I mentioned earlier, it was just this sort of horror story I'd heard and kept in mind while designing the system :) (learning from ED's... mistakes might be a bit strong).
 
You must log in or register to reply here.
Top Bottom