AP - hotkeys are broken

[apricotslice]

From my somewhat limited knowledge of the scripting engine - Hotkeys are registered with a string as the ID in a similar manner to local and global variables. I wouldn't have thought they would get overwritten unless another key tried to get registered using the same ID.

Yes, but the code beneath the command was radically changed for AP, even though the commands are the same.

The same ID is exactly what kurush is saying is happening.

Perhaps the issue is with the way in which the hotkeys are registered. All the XRM hotkeys are registered in a startup script. That means it runs with every single game load and checks for the existence of the hotkey. If its not there, it will add it. So if AP is losing the hotkeys they are being readded with every game load so its not so noticeable.

Until you add extra setup scripts with additional hotkey additions. Then it all falls apart.

I think mine do the same thing. Check for existence, if no, then create. Cycrow wrote mine after all, I cant imagine him leaving that out.

Maybe having all of them in a single setup script is in fact an answer. Thats worth testing. Maybe multiple setup scripts is part of the problem and merging all the setups would be at least some sort of a fix. That is worth testing.

So perhaps the issue with permanently disappearing hotkeys is that they are added in a way where the script does not run at every startup, e.g. where its added via an AL plugin, where the check would only be made when the plugin was turned off and on again.

No, actually its the opposite. ALL my hotkeys were added a single time on the second load because of bugs in TC with game starts. That failed in AP even worse than individual setup scripts run every time does.

In any case, its clearly not something that happens all the time for everyone.

Mainly to people developing new hotkeys, and to people adding scripts to games part way along.

Anyone who starts their game with everything they want in it and never adds anything else, isnt going to see the problem. Thats all vanilla players, and people who are dedicated to only a single mod.

To get to the bottom of it, you'd need to do a lot of trial and error tests with various scripts and methods of adding hotkeys. And even if you work out the issue, don't expect Egosoft to fix it. I'd imagine all their efforts are fully focussed on rebirth so I doubt we'll get another AP update - they've not even fixed the RRF that they broke with the 2.0 update.

I dont disagree with any of that.

Thats why I'm hoping kurush or someone can find the real problem and come up with a work around.

Just for the time it takes, has anyone tried running an XRM game, and after a few saves, installing my salvage pack for AP and seeing what happens ? I'd be interested to know if those hotkeys break any of the XRM ones by being loaded after them. That would be a good test of what Paul is saying about the way he did his. It all adds knowledge.

[paulwheeler]

Yes - if its going to be a community solved thing (and its probably going to have to be), then a lot of testing is required to pin down the exact series of events that cause the problem.

With developing the XRM, I'm constantly adding and removing hotkeys - not just at the start of a game. In fact all the XRM users have recently had a hotkey added that was not there at the start of a game (the jumpdrive deployment kit), and I had no complaints...

It definitely seems to be a strange issue and difficult to consistently reproduce.

[apricotslice]

Paul, maybe you better post some code so we can compare it.

[paulwheeler]

OK - Here's the code for the recently added JDK hotkey. Its lifted straight from the adding hotkeys tutorial in this forum:

Code: Select all

$jdk.activate.hotkey = 'jdk.activate.hotkey' 
 
$jdk.active.hotkey = get global variable: name=$jdk.activate.hotkey

 
if not get global variable: name=$jdk.activate.hotkey
  $jdk.active.hotkey = register hotkey 'XRM - Jumpdrive Deployment Kit' to call script 'plugin.xrm.jddquestion'
  set global variable: name=$jdk.activate.hotkey value=$jdk.active.hotkey
end
 
return null

In fact looking at that again - it doesn't even check for the hotkey itself, but rather the existence of the global variable set when the hotkey is added... so what I said above about it re-adding on every game load is nonsense.

A better method would be to actually unregister and reregister on every game load perhaps.

[apricotslice]

Thats the old way of doing it !

I've got that code, but its all starred out and replaced with hotkeymanager code.

Maybe thats the answer. Like going back to the X3R way of a setup script for each thing, the hotkeys have to be returned to using the original command.

Ie, we scrap using hotkey manager.

Someone care to prove its that simple ?

Maybe half the problem is a mixture of scripts, some using Pauls code, some using hotkey manager, and the mixture doesnt work ?

[kurush]

Someone care to prove its that simple ?

I think I figured out by now the internals of the Hotkey manager and, assuming I did not overlook some scenario where the "purge" bug does not kick in, it basically does not do anything other than registering a hotkey for you via one of two "register hotkey" functions.

it doesn't even check for the hotkey itself

This is something that surprised me as well. May be the function that can check whether a hotkey is registered and return its handle appeared in a later version and everybody was just copying the same code without much thought? In any case, the issue is reproducible on hotkeys without hotkey manager (although not on a game where it is not installed, unless somebody can confirm that).

[Cycrow]

A better method would be to actually unregister and reregister on every game load perhaps.

not a good idea, as it'll mean u'll have to reassign your keys every game load.


i beleive the problem is actually with unregistering the hotkey. The internal hotkey table most likly gets curropted so new ones actually used.

the temporary fix would be to simply never unregister the hotkey.

it should prevent the bug from occuring

until a proper fix can be implemented

[kurush]

Glad you are back with us!

i beleive the problem is actually with unregistering the hotkey. The internal hotkey table most likly gets curropted so new ones actually used.

My investigation shows that no hotkeys are getting unregistered via the hotkey manager as the purge part does not kick in. And I have never ran any manual scripts to unregister a hotkey for any of the scripts I tried.

[Cycrow]

last time i checked it was purging fine.

it runs an init script that marks all the added hotkeys, then theres a delayed script that lauches after the start to purges all the hotkeys that havn't been reregistered

[kurush]

it runs an init script that marks all the added hotkeys, then theres a delayed script that lauches after the start to purges all the hotkeys that havn't been reregistered

Well, there is a small chance that exScriptor messed it up somehow when I was adding logging. But when I placed 3 log entries
1) As the first line
2) After checking the syncrhronization variable but before delay
3) After delay

Only the first entry was written. After some more testing I found that after the sync. variable is set to [FALSE], reading it actually returns NULL and the script does not proceed.
Another indication that the purge didn't work is a bunch of junk hotkeys I found in that collection after dumping it into the log file. I had a second hotkey there for Plugin Configuration pointing to a slightly different script (probably from some old version) and also 3 hotkeys for boarding hotkeys that I probably installed briefly at some point. This can't really be explained by exScriptor doing funky things with the code as it was observed before I even unpacked the hotkey manager files. (I used a separate setup.* script to print the collection contents).
I had to change this sync. variable from [FALSE]/[TRUE] to 0 and 1 to make it work.

[Charon_A]

It occurs to me that there is a problem in hotkey purge single instance check

Code: Select all

* prevent multiple instances
skip if get global variable: name='hotkeys.manager.running'
  return null
set global variable: name='hotkeys.manager.running' value=[TRUE]

I believe instead it should use

Code: Select all

do if get global variable: name='hotkeys.manager.running'

Though I may overlook some grand scheme
Thanks

[kurush]

It occurs to me that there is a problem in hotkey purge single instance check

I totally agree that there is a problem there. May be it is actually just the double-negative that got us all confused. Now I think it is not boolean-> integer change that fixed it in my situation, but rather changing "skip if" to just normal if

The termination of a second instance (return null) is being skipped (skip if) when the first instance of the script is running. And it does not get skipped if there is no 1-st instance, meaning the 1-st instance will never run.
Should be other way around.

I think you nailed it. I just fixed it without thinking much about the underlying logic Problem is this bug is relatively harmless. It just causes some junk hotkeys accumulating in that collection. I am not even sure AP displays them if there is no corresponding script. There is another bug that causes hotkey registrations to overwrite each other, also referred to as "Evil Monster from W" in the root post

[Logain Abler]

Hope I'm not breaking any rules by posting this, I changed the init.community.config as follows:

Code: Select all

* whipe all settings at begining
set global variable: name='config.scripts' value=null
set global variable: name='config.menus' value=null
$aOptions = get global variable: name='config.options'
set global variable: name='config.backup.opt' value=$aOptions
set global variable: name='config.options' value=null
$page.id = 7000 
set global variable: name='pageid.config' value=$page.id
load text: id=$page.id
 
$text = read text: page=$page.id id=1
if [THIS]->call script 'plugin.hotkeymanager.add' : a.name='config'  a.text=$text  a.script='plugin.config.menu' 
  $key = get global variable: name='config.key'
  if $key 
    unregister hotkey $key
    set global variable: name='config.key' value=null
  end
   
else
  $key = get global variable: name='config.key'
  if not $key 
    $key = register hotkey $text to call script 'plugin.config.menu'
    set global variable: name='config.key' value=$key
  end
end
return null

TO:

Code: Select all

* whipe all settings at begining
set global variable: name='config.scripts' value=null
set global variable: name='config.menus' value=null
$aOptions = get global variable: name='config.options'
set global variable: name='config.backup.opt' value=$aOptions
set global variable: name='config.options' value=null
$page.id = 7000 
set global variable: name='pageid.config' value=$page.id
load text: id=$page.id
 
$text = read text: page=$page.id id=1

  $key = get global variable: name='config.key'
  if not $key 
    $key = register hotkey $text to call script 'plugin.config.menu'
    set global variable: name='config.key' value=$key
  end

return null

I removed the first if condition.

I had to re-setup my hotkeys but at least I was able to see them again.
Not sure if it will work in all scenarios.

LA

[kurush]

I had to re-setup my hotkeys but at least I was able to see them again.
Not sure if it will work in all scenarios.
LA

Do you actually see all hotkeys? Because after I did something similar with various scripts, I first thought I fixed it only to later discover that some other hotkey disappeared. Now I am basically commenting out various hotkey registrations to make available the hotkeys I actually use.