[Brad]

Is there a method to detect and act upon the changing of a plugin's CVAR?

As a contrived example lets say there's a plugin that makes everyone blind when it's enabled. It has a CVAR to enable/disable the plugin. If mid-round the CVAR gets set to disable the plugin, it'd be nice if a method could catch that the CVAR was changed and act appropriately. In this example, it would "un-blind" everyone since the CVAR was changed to disabled.

[D_Hawk]

I think it does that automatically if you do get_cvar_<>.

[Brad]

I think you misunderstood my question.

In keeping with my previous example, I'm thinking more along the lines of:

public plugin_init
{
   // register_my_cvar(<cvar to register>, <function to call>)
   register_my_cvar("mycvar_blind_enable", "enable_changed")
}

public enable_changed(vNewValue)
{
   if (vNewValue == 1)
   {
      // make players blind
   }
   else if (vNewValue == 0)
   {
      // let players see again
   }
}

I realize that I could just surface a command that could be called to enable/disable a particular CVAR and handle it within the command but I was looking for something a little more generic.

Speaking of generic, it would be even more so if you could specify a function to be called whenever any (as opposed to when specific) CVARS of your plugin are changed.

As in:

public plugin_init
{
   register_cvar("mycvar_blind_enable", "0")
   register_cvar("mycvar_blind_time", "10.0")

   // register_cvar_function(<function to call>)
   register_cvar_function("cvar_changed")
}

public cvar_changed(sCVAR, vNewValue)
{
   if (equal(sCVAR, "mycvar_blind_enable"))
   {
      if (vNewValue == 1)
      {
         // make players blind
      }
      else if (vNewValue == 0)
      {
         // let players see again
      }
   }
}

Still yet, it could automatically be called if the plugin has it defined, negating the need to register a function to be called.

I think this is in the realm of a suggestion now and not a scripting question anymore.

[D_Hawk]

AH my bad, I thought you meant you wanted it to always do something based on a cvar. In that case, I don't know. I was thinking more like this:

#include <amxmodx>

public plugin_init()
{
     register_plugin ("yes","no","maybe" )
     register_cvar ("asdf", 1)
     return PLUGIN_CONTINUE
}

public sdafasd()
{
     new x
     get_asdf(x)
     if (x = 1)
     {  
           client_cmd(0,"say sdafsdafasd")
     }
     return PLUGIN_HANDLED
}

Or something like that. I don't remember how "get_asdf" is actually executed.

[Twilight Suzuka]

Use register_logevent. You can catch when a cvar changes using it.

[Brad]

Apparently not when one uses amx_cvar to change the value of a CVAR.

Matter of fact, the only time I came close to catching any CVAR changes is if I did the changes via RCON. Otherwise, they were never written to the log.

[addons_zz]

Then, you can set a task to checks if the cvar has changed.

Or you can create beyond the cvar, concmd's, just to disable/enable the blind plugin and set it cvar to 0.

Or you can check the cvar change at some special moment, like some forwards or events:
client_putinserver, client_connect, ..., round_start, death, ...

See https://wiki.alliedmods.net/Half-life_1_game_events, and https://www.amxmodx.org/api/amxmodx -> Forwards

Or you could try the forward client_command, called when a client attempts to execute a command.
Then, keep a current logged admins id list, updated at the forward client_putinserver and check if it is a admin, then reload the cvar.

Or don't to use cvar at all, use concmd only, one to active it and another to disable it, or create one that receives parameters, as enable or disable.

Which one you choose, depends how much fast you want to detect the cvar change. To do it immediately use concmd, else you can create a task at blind plugin or some other plugin, for example, repeat the checking each 15 seconds.

Example:
mycvarblind 0 // 1 blind - 0 not
myconcmddisableblind // to disable blindness and set mycvarblind to 0
myconcmdenableblind // to enable blindness and set mycvarblind to 1

[Hartmann]

@addons_zz

Last post: 07-22-05 17:47

Why do you write on the topic from 2005?

[addons_zz]

Originally Posted by Hartmann @addons_zz Last post: 07-22-05 17:47 Why do you write on the topic from 2005?

Because it does still open, hence, those who find it by google like me, will get it more useful.

Haha, more than 10 years later. This teach us to never give up about our not solved topic, 10 years later it could still not solved, but it could get a little better.