View Issue Details

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

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.

Relationships

related to 0008747 resolvedccw MTA forgets user made resources related binds 

Activities

arranTuna

2014-04-06 20:15

manager   ~~0020596

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

Grafu

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.

Grafu

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.

qaisjp

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.

Grafu

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.

qaisjp

2014-04-27 22:33

administrator   ~~0020794

So what's stopping the server from doing http://pastebin.com/bqAC1WzB?
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.

Grafu

2014-04-28 10:59

viewer   ~~0020806

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

drifterCZ

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.

Example:

  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

arranTuna

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()
outputChatBox("blah")
end
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()
outputChatBox("blah")
end
addCommandHandler("blah", blah)
if (not getKeyBoundToCommand("blah")) then
bindKey("z", "down", "blah")
end

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
outputChatBox("blah")
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
outputChatBox("blah4")
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)
end

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.

ccw

2015-07-21 18:40

administrator   ~~0023705

Is this a duplicate of #8747 ?

Grafu

2015-07-21 20:43

viewer   ~~0023707

Last edited: 2015-07-21 20:54

View 3 revisions

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

Issue History

Date Modified Username Field Change