This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

Toggling "F1, F6 are macros" from within a plugin

Posted by KaVir on Wed 03 Nov 2010 09:58 AM — 17 posts, 73,907 views.

KaVir Germany #0
My plugin using Accelerator() to redefine the function keys, and this works fine - however I noticed that hitting F1 also attempts to open the windows help.

Currently I inform my users that they need to go to File -> Global Preferences -> General and toggle "F1, F6 are macros". But is there any way to do it automatically from within the plugin?

Wouldn't it make sense to automatically disable the help if you manually override F1 with something else? I can't envision a scenario in which you'd want it to do both.
Twisol USA #1
There's no way to change any of the global settings from within a plugin, AFAIK.
KaVir Germany #2
Is there perhaps a local equivalent then? Something that treats F1/F6 as macros for the current world?
Nick Gammon Australia Forum Administrator #3 

db = sqlite3.open(GetInfo (82))  -- open preferences
db:exec 'UPDATE prefs SET value = 1 WHERE name = "F1macro"'
db:close()  -- close


However that only affects the database. You need to close MUSHclient totally and re-open it to have that noticed.

[EDIT]
From version 4.67 onwards then add this line:


utils.reload_global_prefs ()

Amended on Thu 04 Nov 2010 08:32 PM by Nick Gammon
KaVir Germany #4
Thanks Nick - so if I understand it correctly, that means F1 would still bring up windows help the first time you used MUSHclient after installing the plugin, but the next time you started MUSHclient it would be working.

Is there any harm in executing the above code each time the plugin is started? Or is there a better way of doing it, some sort of one-time initialisation when the plugin is first added?

Is it perhaps possible to query the database for the value? If so, I could first check if the value is 0, then if the user tries to use F1 I could at least send them a message explaining that they need to close MUSHclient and reopen it.
Amended on Thu 04 Nov 2010 09:53 AM by KaVir
Twisol USA #5
KaVir said:
Is there any harm in executing the above code each time the plugin is started? Or is there a better way of doing it, some sort of one-time initialisation when the plugin is first added?

Is it perhaps possible to query the database for the value? If so, I could first check if the value is 0, then if the user tries to use F1 I could at least send them a message explaining that they need to close MUSHclient and reopen it.

You can just use GetGlobalOption("F1macro") to get the current value of the that option.
KaVir Germany #6
Handy, thanks!
Nick Gammon Australia Forum Administrator #7
I can see how it would be useful to customize global preferences when distributing pre-made setups. I have added a new script function to the utils table for version 4.67:


db = sqlite3.open(GetInfo (82))  -- open preferences
db:exec 'UPDATE prefs SET value = 1 WHERE name = "F1macro"'
db:close()  -- close

utils.reload_global_prefs ()


Now that will force the global preferences to be updated.
Twisol USA #8
Pardon my skepticism, but how is that any better than just creating a SetGlobalOption function? I could actually create a wrapper that does just that:


function SetGlobalOption(name, value)
  name = ("'%s'):format(name:gsub("'", "''"))
  
  if type(value) == "string" then
    value = ("'%s'"):format(value:gsub("'", "''"))
  elseif type(value) == "number" then
    value = tostring(value)
  else
    error("Invalid value type '" .. type(value) .. "'.")
  end
  
  local db = sqlite3.open(GetInfo(82))
  db:exec(('UPDATE prefs SET value = %s WHERE name = %s'):format(value, name))
  db:close()
  
  utils.reload_global_prefs()
end
Nick Gammon Australia Forum Administrator #9
Oh well, my work is done then. :)

I don't really want to encourage plugins to change global options - after all that makes them a little less self-contained.
KaVir Germany #10
Excellent, thanks again. I can understand not wanting to encourage plugins to change global options, but presumably with this new addition I could at least make the change temporary? Eg:


if GetGlobalOption("F1macro") ~= 1 then

  -- set the F1macro option
  db = sqlite3.open(GetInfo (82))  -- open preferences
  db:exec 'UPDATE prefs SET value = 1 WHERE name = "F1macro"'
  db:close()  -- close

  -- update the global preferences
  utils.reload_global_prefs ()

  -- revert the F1macro option, but don't update the global preference again
  db = sqlite3.open(GetInfo (82))  -- open preferences
  db:exec 'UPDATE prefs SET value = 0 WHERE name = "F1macro"'
  db:close()  -- close

end -- if


My players are pretty lazy when it comes to updating (either MUSHclient or the plugin), but I always recommend the latest version for new players, and this change is mainly for their benefit anyway (the existing players will already have manually set the global option themselves).

P.S: On the subject of MUSHclient versions, Nick, you may find this of interest: http://www.godwars2.org/mwi/clients/mushclient - note that this page lists MUSHclient versions by character rather than by player or IP address, but the percentages still give a general overview of which versions are used the most. My plugin currently requires 4.51 or later, and most people still use that version.

Worstje Netherlands #11
KaVir, if you want to 'revert' the value, do exactly that. Don't turn it off. Or in less cryptic words: save the old value, restore it afterwards.

If someone made the change by choice, you don't want to mess with it and confuse the crap out of them whenever your code runs.
Twisol USA #12
Worstje said:

KaVir, if you want to 'revert' the value, do exactly that. Don't turn it off. Or in less cryptic words: save the old value, restore it afterwards.

If someone made the change by choice, you don't want to mess with it and confuse the crap out of them whenever your code runs.

I presume that's why there's an if-check around the block.
Worstje Netherlands #13
... Shh. I get to ignore that at my choosing. >.>
Nick Gammon Australia Forum Administrator #14
KaVir said:

Excellent, thanks again. I can understand not wanting to encourage plugins to change global options, but presumably with this new addition I could at least make the change temporary? Eg:


Yes, very cunning. My psychic powers told me someone might do that, so I left the way open for it.

The only problem is, if one plugin wants F1 to bring up Help, and another plugin wants F1 to NOT bring up help. Then you are stuck, eh?

An alternative would be to ask the player, and then permanently change it. Maybe remember if you asked them so you don't ask every time.
Nick Gammon Australia Forum Administrator #15
KaVir said:

P.S: On the subject of MUSHclient versions, Nick, you may find this of interest: http://www.godwars2.org/mwi/clients/mushclient


Hmm - that's interesting. I changed the URL to see how popular other clients are. Not as much as MUSHclient it seems. :)

But that is probably because you have quite significant enhancements designed around miniwindows.

And that is also an interesting commentary for those people who argue that MUDs should still have a "text-only" fallback so "anyone can play".

Judging by your figures, you would have about 10 players rather than 200 if you stuck to a text-only mode. I mean, if the extra graphical features aren't that important, why aren't half the players using other clients?
KaVir Germany #16
Nick Gammon said:
The only problem is, if one plugin wants F1 to bring up Help, and another plugin wants F1 to NOT bring up help. Then you are stuck, eh?


True, but that would be the case anyway, even if the changes were permanent. At least with this approach the user only needs to restart MUSHclient to revert back to their old global preferences - they don't need to manually go through the options trying to work out which ones the plugin has changed.

Not perfect perhaps, but it's a definite improvement. Out of curiousity, what would happen if the user opened two MUSHclient sessions (rather than two worlds in a single session) using this approach? Presumably utils.reload_global_prefs() would only update the preferences for the one session that called it?

Nick Gammon said:
Hmm - that's interesting. I changed the URL to see how popular other clients are. Not as much as MUSHclient it seems. :)

But that is probably because you have quite significant enhancements designed around miniwindows.


Well MUSHclient had a clear lead even before I started playing with plugins (it had around the same number of users as the second and third most popular clients combined), but quite a few players have switched over to it in the last 6 months, and the current figure (55.9% of the active players) is about as high as I've ever seen it - so it does still seem to be gaining in popularity.

Nick Gammon said:
And that is also an interesting commentary for those people who argue that MUDs should still have a "text-only" fallback so "anyone can play".

Judging by your figures, you would have about 10 players rather than 200 if you stuck to a text-only mode. I mean, if the extra graphical features aren't that important, why aren't half the players using other clients?


To be honest I've not noticed any real change in the size of my playerbase since introducing the plugin - although admittedly I've not promoted it heavily, other than to existing players, as I don't feel it's quite finished. It's also worth noting that around one third of the MUSHclient users on my mud don't use MSDP, which means they're not using the plugin (the other two thirds are using various different plugins, including a few player-written ones, but I believe most use graphics).

I should also mention that around 14% of my active players use screen readers, and they rely on that text-only fallback. While I'm very much in favour of adding graphical elements, my mud is still primarily text-based, so my target audience will have certain expectations. In my experience it's easier to persuade people to try a client than it is to force them.