Forums » Bugs
VO repeatedly reassigns JOY0BUTTON2 to missionchat
It took me a few minutes to remember how to get past that problem by doing a /bind JOY0BUTTON2 "", but this seriously should be fixed. I'm on windows 10 using a logitech extreme 3d pro if that is needed information.
Hmm.
Would you rather have it bound to nothing? Or is it overwriting your existing bind?
Which button is BUTTON2 and is it easy to accidentally press?
While we figure it out, try binding the button to NONE instead of "" to see if that helps it not repeatedly bind that button.
Would you rather have it bound to nothing? Or is it overwriting your existing bind?
Which button is BUTTON2 and is it easy to accidentally press?
While we figure it out, try binding the button to NONE instead of "" to see if that helps it not repeatedly bind that button.
Hi Ray,
In this particular case that button is one of the 4 buttons on the top of the stick around the hat switch. I like some defaults set. The problem seems to be that when you bind a button to a keyboard function, it immediately causes that action to engage. For instance, if a button is set to fire primary weapon, that weapon will fire once but then be reassigned to the new function.
When the button is set to missionchat or some of the other PDA options, that screen will be brought up, the confirmation to overwrite will pop up but the new function is not assigned. My first solution, before my memory kicked in was to make the change in the config.ini file. However, even doing this while VO was completely shut down and confirming and reconfirming that my change was saved, upon restarting VO that button had been defaulted back to mission chat.
I will use NONE in the future. Using "" did solve the problem and has worked well in the past when I've encountered this issue.
I'm pretty sure this issue has been brought up in the past. If this is going to be one of those difficult or long term fixes, perhaps adding a note somewhere in the control settings on using /bind 'button' NONE in order to help newer players resolve this problem since it's probably happening on game pads as well if I had to guess.
In this particular case that button is one of the 4 buttons on the top of the stick around the hat switch. I like some defaults set. The problem seems to be that when you bind a button to a keyboard function, it immediately causes that action to engage. For instance, if a button is set to fire primary weapon, that weapon will fire once but then be reassigned to the new function.
When the button is set to missionchat or some of the other PDA options, that screen will be brought up, the confirmation to overwrite will pop up but the new function is not assigned. My first solution, before my memory kicked in was to make the change in the config.ini file. However, even doing this while VO was completely shut down and confirming and reconfirming that my change was saved, upon restarting VO that button had been defaulted back to mission chat.
I will use NONE in the future. Using "" did solve the problem and has worked well in the past when I've encountered this issue.
I'm pretty sure this issue has been brought up in the past. If this is going to be one of those difficult or long term fixes, perhaps adding a note somewhere in the control settings on using /bind 'button' NONE in order to help newer players resolve this problem since it's probably happening on game pads as well if I had to guess.
Yeah - Its the imaginary problem I have been bitching about for some time now...
Nothing like having a mission screen pop up in the middle of an ion storm with assault bots on your tail...
The problem is VO assumes the supplied config is wrong instead of assuming its right.
The assumption is correct when a new piece of hardware is attached and there is no config data,
but is wrong in all other instances.
The correct behavior is...
New hardware/no config -> auto configure
if there is config data then only change it if requested by the player.
That is to say - put a configure button for each piece of hardware vo uses in the menu
and perhaps create a commandline interface such as
/configure joy0 -- for joystick 0
/config VR -- for vr helmet
Or you could install a button/config variable to disable VO's constant meddling.
I realize that certain configurations may appear to be wrong or insane to you but please assume we know what we are doing until proven otherwise...
Oh btw some joysticks have more then one fire button and this changes the overall layout / numbering a bit.
My logitech has two firing buttons and 4 more on the top of the stick numbered 2 to 5
My siatek only has one so the 4 top buttons are 1 - 4 instead.
pps - Why are dpad settings required when I have never had one attached to my system?
Is John secretly dating the daughter of a dpad manufacturer? :}
Nothing like having a mission screen pop up in the middle of an ion storm with assault bots on your tail...
The problem is VO assumes the supplied config is wrong instead of assuming its right.
The assumption is correct when a new piece of hardware is attached and there is no config data,
but is wrong in all other instances.
The correct behavior is...
New hardware/no config -> auto configure
if there is config data then only change it if requested by the player.
That is to say - put a configure button for each piece of hardware vo uses in the menu
and perhaps create a commandline interface such as
/configure joy0 -- for joystick 0
/config VR -- for vr helmet
Or you could install a button/config variable to disable VO's constant meddling.
I realize that certain configurations may appear to be wrong or insane to you but please assume we know what we are doing until proven otherwise...
Oh btw some joysticks have more then one fire button and this changes the overall layout / numbering a bit.
My logitech has two firing buttons and 4 more on the top of the stick numbered 2 to 5
My siatek only has one so the 4 top buttons are 1 - 4 instead.
pps - Why are dpad settings required when I have never had one attached to my system?
Is John secretly dating the daughter of a dpad manufacturer? :}
Change it in the config file
VO has a tendency to change it back....
Death Fluffy, it's changing the bind in the middle of the game? For exaple, you bind joystick button 2 to +Shoot2 and then you use the button, it fires once, and then gets changed back to missionchat immediately afterwards? So you release and then press it again you get the mission menu?
As a note, leaving an entry in the config.ini file blank, ie. nothing after the =, VO thinks it is unbound, so assigns a default value to it. That's why I suggest using NONE which is a defined command that does nothing and should get saved.
As a note, leaving an entry in the config.ini file blank, ie. nothing after the =, VO thinks it is unbound, so assigns a default value to it. That's why I suggest using NONE which is a defined command that does nothing and should get saved.
Not quite. I was describing what I experience when changing the bind on a joystick button. If button 2 is assigned to +Shoot2, +turbo, mission chat or as near as I can tell most other assignments and I assign it to something else, the original assignment is activated once. So if I change button 2 from +Shoot2 to something like Activate, normally my ship will fire the assigned weapon once and then make the change to Activate for all future button presses.
Something about the PDA screens inhibits that transfer of assignment. Missionchat is the most common screen I've encountered this issue with because it is a default setting. So I try to change button 2 from missionchat to activate and the missionchat screen is brought up along with the confirmation popup. I choose yes and the popup closes out however the change in assignment is not made.
Where I was having the issue with the assignment being changed back to missionchat was when I closed the vo client, edited the button assignment in the config.ini file. Upon restarting vo, the button is changed back to the default of missionchat.
Actually, using the empty quotes is the solution to this problem I was given by another player years ago and it has worked well. I will of course use NONE in the future, but the empty quotes for some reason clears the button assignment so that it can then be reassigned without further issue.
Something about the PDA screens inhibits that transfer of assignment. Missionchat is the most common screen I've encountered this issue with because it is a default setting. So I try to change button 2 from missionchat to activate and the missionchat screen is brought up along with the confirmation popup. I choose yes and the popup closes out however the change in assignment is not made.
Where I was having the issue with the assignment being changed back to missionchat was when I closed the vo client, edited the button assignment in the config.ini file. Upon restarting vo, the button is changed back to the default of missionchat.
Actually, using the empty quotes is the solution to this problem I was given by another player years ago and it has worked well. I will of course use NONE in the future, but the empty quotes for some reason clears the button assignment so that it can then be reassigned without further issue.