I should ask, what is the preferred way to design convars?
using a dictionary and convar names as the keys or use a simple list?
New Project: Porting Saxton Hale mod for Source.Python
Re: New Project: Porting Saxton Hale mod for Source.Python
You don't need a list or dictionary. The preferred way is to simply create global variables and using the config module:
http://wiki.sourcepython.com/developing ... onfig.html
http://wiki.sourcepython.com/developing ... onfig.html
Re: New Project: Porting Saxton Hale mod for Source.Python
Ayuto wrote:You don't need a list or dictionary. The preferred way is to simply create global variables and using the config module:
http://wiki.sourcepython.com/developing ... onfig.html
I'm not against the idea of using global variables but im against using global variables when unnecessary. Wouldn't it be cleaner under a dict?
Here's what I've done so far.
Syntax: Select all
########## CVar and Config setup.
vsh_cvars = { 'cfg':ConfigManager('vsh', cvar_prefix='vsh_') };
vsh_cvars["vsh_enable"] = vsh_cvars["cfg"].cvar('enable', '1', '1 to enable, 0 to disable vsh plugin.', ConVarFlags.NONE|ConVarFlags.DONTRECORD);
vsh_cvars["vsh_boss_health"] = vsh_cvars["cfg"].cvar('boss_health', '250', 'how much health bosses start with.', ConVarFlags.NONE);
vsh_cvars["cfg"].header = 'PyVSH Config File.';
vsh_cvars["cfg"].write();
##########
Re: New Project: Porting Saxton Hale mod for Source.Python
nergal wrote:Wouldn't it be cleaner under a dict?
Not necessarily. What you have looks less readable to me than each one having it's own global variable independently importable by any other module. I have used dictionaries for cvars in the past, but only for dynamically named variables:
https://github.com/satoon101/Projectile ... /config.py
In that plugin, I create variables for each projectile type, which is dependent on the game. Due to this, I chose the option of a dictionary because I can store all the variables using the projectile type as a key.
You also run a greater risk of overwriting a key in a dictionary in this respect than doing the same with a global name. If you are using a modern Python editor (which I would highly recommend if you are not), most good ones will let you know if you are reusing/reassigning an existing global name (at the very least when you have not "used" the original object). They typically don't do the same for keys in a dictionary.
Even if you use a dictionary in this instance, I would question adding the ConfigManager to that same dictionary. There is really no reason to store that object anywhere, as it should really end its usefulness after you write and execute the configuration file. Speaking of, you are not executing the config in your code, so your plugin will always use the default values. I prefer using the context manager to automatically write and execute each configuration file. It looks like we never added either of those to the wiki. I will try to remember to do that later.
Re: New Project: Porting Saxton Hale mod for Source.Python
satoon101 wrote:nergal wrote:Wouldn't it be cleaner under a dict?
Not necessarily. What you have looks less readable to me than each one having it's own global variable independently importable by any other module. I have used dictionaries for cvars in the past, but only for dynamically named variables:
https://github.com/satoon101/Projectile ... /config.py
In that plugin, I create variables for each projectile type, which is dependent on the game. Due to this, I chose the option of a dictionary because I can store all the variables using the projectile type as a key.
You also run a greater risk of overwriting a key in a dictionary in this respect than doing the same with a global name. If you are using a modern Python editor (which I would highly recommend if you are not), most good ones will let you know if you are reusing/reassigning an existing global name (at the very least when you have not "used" the original object). They typically don't do the same for keys in a dictionary.
Even if you use a dictionary in this instance, I would question adding the ConfigManager to that same dictionary. There is really no reason to store that object anywhere, as it should really end its usefulness after you write and execute the configuration file. Speaking of, you are not executing the config in your code, so your plugin will always use the default values. I prefer using the context manager to automatically write and execute each configuration file. It looks like we never added either of those to the wiki. I will try to remember to do that later.
is there a way for the config manager to return a list or dict of cvars it has written maybe?
Re: New Project: Porting Saxton Hale mod for Source.Python
Well, ConfigManager does store all cvar names in a set:
https://github.com/Source-Python-Dev-Te ... er.py#L166
It also stores all cvars, commands, and text sections in a list:
https://github.com/Source-Python-Dev-Te ... er.py#L169
I don't see how any of that is useful, however.
https://github.com/Source-Python-Dev-Te ... er.py#L166
It also stores all cvars, commands, and text sections in a list:
https://github.com/Source-Python-Dev-Te ... er.py#L169
I don't see how any of that is useful, however.
Re: New Project: Porting Saxton Hale mod for Source.Python
satoon101 wrote:Well, ConfigManager does store all cvar names in a set:
https://github.com/Source-Python-Dev-Te ... er.py#L166
It also stores all cvars, commands, and text sections in a list:
https://github.com/Source-Python-Dev-Te ... er.py#L169
I don't see how any of that is useful, however.
that's actually pretty nice though, having all the cvars in a single container for the manager makes it easier to get specific, named values though.
Also, I've added the `config.execute()` code but does it matter where I put it?
I placed in the `load` function that each plugin typically has.
Syntax: Select all
def load() -> None:
SayText2('PyVSH has loaded successfully!').send();
for edict_t in PlayerGenerator():
player = player_dict[index_from_edict(edict_t)];
vshCfgManager.execute();
Re: New Project: Porting Saxton Hale mod for Source.Python
Not really. I mean, you're still creating them explicitly anyway, so why not have explicit variable names for each? Then, if another module needs access to it, all it has to do is import the variables it needs.nergal wrote:that's actually pretty nice though, having all the cvars in a single container for the manager makes it easier to get specific, named values though.
No, you can really put it anywhere. But, the best place is to just have it directly after config.write(). Though, I personally prefer to use the context management to automatically do both:nergal wrote:Also, I've added the `config.execute()` code but does it matter where I put it?
Syntax: Select all
with ConfigManager('vsh', cvar_prefix='vsh_') as _config:
_config.header = 'PyVSH Config File.'
vsh_enable = _config.cvar('enable', '1', '1 to enable, 0 to disable vsh plugin.', ConVarFlags.NONE|ConVarFlags.DONTRECORD)
vsh_boss_health = _config.cvar('boss_health', '250', 'how much health bosses start with.', ConVarFlags.NONE)
Also, I see you are ending a lot of lines with a semi-colon. That's 100% unnecessary.
Return to “Plugin Development Support”
Who is online
Users browsing this forum: No registered users and 83 guests