View Issue Details

IDProjectCategoryView StatusLast Update
0008145Multi Theft Auto : San AndreasClientpublic2015-08-17 12:12
ReporterGrafu Assigned Toccw  
Status resolvedResolutionfixed 
OSWindowsOS Version8.1 
Target Version1.5Fixed in Version1.5 
Summary0008145: Controls don't reappear in Settings ==> Binds, if bindKey isn't used

If you use bindKey('key', 'state', 'command name') in a resource client script file, it creates a section 'resource name' and the command with the keys bound to it. When you disconnect the server, the section and it's controls disappear. The controls made by a resource yet get saved to the config file, but doesn't reappear when connecting to the server again, if no bindKey('key', 'state', 'command name') is used again.
getBoundKeys('command name') returns all the controls, but they are not visible in the esc/settings/binds.

Steps To Reproduce
  1. '/crun bindKey('f', 'down', 'hello')'
  2. The control with it's section appears in escape/settings/binds
  3. /disconnect
  4. The control and the section disappears from escape/settings/binds
  5. /reconnect
  6. Control and the section in escape/settings/binds doesn't appear
  7. '/crun for control, in pairs(getBoundKeys("hello")) do outputChatBox(control) end' outputs f, but it's not visible in the settings any more.
Additional Information

The controls should reappear in the settings when joining the same server, otherwise people can't simply change them or delete.

TagsNo tags attached.


related to 0008747 resolvedccw MTA forgets user made resources related binds 



2014-04-06 20:15

manager   ~~0020596

But why wouldn't a script use bindKey again? It should do every resource start.


2014-04-07 06:42

viewer   ~~0020604

Because I want to check, if a player has already bound his own key on it. And if he did, I wouldn't overbind it.


2014-04-07 15:08

viewer   ~~0020615

I had some further testing with the binds. If you add alternative keys to the one bound by a resource, you get various saving bugs. For example, if you remove additional binds from the command and confirm it, the binds reappear in the key menu when you open it next time. Also noticed, that my coreconfig.xml contained 2 identical lines of the same bind.


2014-04-27 19:16

administrator   ~~0020788

Anyway, are binds created by scripts supposed to be saved? I assumed they were only saved if you changed them.


2014-04-27 22:28

viewer   ~~0020793

There should be a way to bind a key by the server and leave the full control for the user as long as there are any keys bound to the command.


2014-04-27 22:33

administrator   ~~0020794

So what's stopping the server from doing
If you change a bind after the server sets it to a command, change the bind in the settings, and then leave the server, does it stay there or hide? Surely if you change a bind in the settings it should be converted into a regular /bind; but this should not mean that the server bind is removed. There's no real easy way to do this.

TLDR the best way is for servers to have a bindmanager resource so that users can manage their own command binds inserver. When you change the bind inserver and reconnect, the client script will load it from the client config.


2014-04-28 10:59

viewer   ~~0020806

If you rebind a server bind, it disappears from the settings, but stays in the config file.


2014-04-29 14:39

viewer   ~~0020810

I found only one problem with bindKey used by client scripts for commands:
You can rebind it in esc settings, which is a nice way, it even remembers the setting after rejoin but the problem is it adds the original key to secondary control.


  1. join server and run client scripts with bindKey ( "l", "blabla" )
  2. change the key from L to P in settings
  3. quit server
  4. join again (and run the bind script)
  5. look in settings, now you have command "blabla" bounded to both P (primary) and L (secondary) keys, which is wrong - only P should be binded


2014-05-03 12:52

manager   ~~0020827

So this bug basically makes the alternative syntax useless. The whole idea is that a player can change the key bind in their settings but if every time they rejoin the server the default key gets re-added (and it has to be) then it ends up being bound to 2 keys which is completely useless.

For example: You have something bound to "z" by default but make it so that it can be changed:

function blah()
addCommandHandler("blah", blah)
bindKey("z", "down", "blah")

Players who have AZERTY keyboard will then complain that it triggers every time when they press their forwards key. So they go to settings and change the key bind to lets say "e" everything works fine and they're happy.

They rejoin the server and press forwards key. "Blah" spam would result. The key is now bound to "z" and "e"

I tried this to fix it:

function blah()
addCommandHandler("blah", blah)
if (not getKeyBoundToCommand("blah")) then
bindKey("z", "down", "blah")

But getKeyBoundToCommand("blah") returns false even if you have it bound to "e"
getKeyBoundToCommand("blah") only works after bindKey has been called. So there is no hack fix for this, I even tried this:

function blah(key)
if (key ~= getKeyBoundToCommand("blah")) then return end

addCommandHandler("blah", blah)
bindKey("z", "down", "blah", getKeyBoundToCommand("blah"))

But that doesn't work at all, because getKeyBoundToCommand("blah") returns false as an argument inside bindKey. I even tried this super hacky mess:

function blah(cmd, key)
if (key ~= getKeyBoundToCommand("blah4")) then return end

addCommandHandler("blah4", blah)
bindKey("z", "down", "blah4", "z")
outputChatBox("key: "..tostring(getKeyBoundToCommand("blah4")))
if (getKeyBoundToCommand("blah4") ~= "z") then
local newKey = getKeyBoundToCommand("blah4")
--unbindKey("z", "down", "blah4") -- Doesn't work for some reason
bindKey(newKey, "down", "blah4", newKey)

But it's still no good because if you change it in settings it won't work without restarting the script / reconnecting.

Bottom line:
bindKey should not add the bind if there is an already existing key bind for that command.


2015-07-21 18:40

administrator   ~~0023705

Is this a duplicate of #8747 ?


2015-07-21 20:43

viewer   ~~0023707

Last edited: 2015-07-21 20:54

Breaks the scripting logic, but the magic seems to work ;p So YEA, a duplicate.

Issue History

Date Modified Username Field Change