New Project: Porting Saxton Hale mod for Source.Python

Please post any questions about developing your plugin here. Please use the search function before posting!
nergal
Member
Posts: 57
Joined: Sun Mar 15, 2015 2:58 pm

Re: New Project: Porting Saxton Hale mod for Source.Python

Postby nergal » Thu Aug 02, 2018 3:40 pm

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?
User avatar
Ayuto
Project Leader
Posts: 1857
Joined: Sat Jul 07, 2012 8:17 am
Location: Germany

Re: New Project: Porting Saxton Hale mod for Source.Python

Postby Ayuto » Sun Aug 05, 2018 4:48 am

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
nergal
Member
Posts: 57
Joined: Sun Mar 15, 2015 2:58 pm

Re: New Project: Porting Saxton Hale mod for Source.Python

Postby nergal » Sun Aug 05, 2018 4:57 am

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();
##########
User avatar
satoon101
Project Leader
Posts: 2562
Joined: Sat Jul 07, 2012 1:59 am

Re: New Project: Porting Saxton Hale mod for Source.Python

Postby satoon101 » Sun Aug 05, 2018 5:33 am

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.
Image
nergal
Member
Posts: 57
Joined: Sun Mar 15, 2015 2:58 pm

Re: New Project: Porting Saxton Hale mod for Source.Python

Postby nergal » Sun Aug 05, 2018 1:06 pm

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?
User avatar
satoon101
Project Leader
Posts: 2562
Joined: Sat Jul 07, 2012 1:59 am

Re: New Project: Porting Saxton Hale mod for Source.Python

Postby satoon101 » Sun Aug 05, 2018 2:18 pm

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.
Image
nergal
Member
Posts: 57
Joined: Sun Mar 15, 2015 2:58 pm

Re: New Project: Porting Saxton Hale mod for Source.Python

Postby nergal » Tue Aug 07, 2018 4:27 pm

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();
User avatar
satoon101
Project Leader
Posts: 2562
Joined: Sat Jul 07, 2012 1:59 am

Re: New Project: Porting Saxton Hale mod for Source.Python

Postby satoon101 » Thu Aug 09, 2018 3:46 am

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.
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:Also, I've added the `config.execute()` code but does it matter where I put it?
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:

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.
Image

Return to “Plugin Development Support”

Who is online

Users browsing this forum: No registered users and 3 guests