search

GiN720 / confogl

Automatically exported from code.google.com/p/confogl
0 stars 0 forks source link

Suggestion: When a cvar is multiple defined with confogl_addcvar, use the last value #145

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
I was creating a config the other day, and added all CVars that I wanted to 
change with confogl_addcvar between the default confogl CVars and 
confogl_setcvars.

But some things were not running as intended, and I figured out that some CVars 
were ignored because they were already set to other values in default confogl 
(spawntimers for example).

So my suggestion would be, that in such cases the earlier set values get 
overridden by later values (but of course only before confogl_setcvars). That 
way you can easier add CVars when creating configs without always having to 
check whether they are already in the default cvars and commenting them there.

Original issue reported on code.google.com by Dynastic...@googlemail.com on 24 Apr 2011 at 9:48

GoogleCodeExporter commented 8 years ago 
I think if anyone plans on distributing a config they should be doing it 
correctly.  Meaning, they should only have one reference to each cvar.  That 
way it allows people to modify the config much more easily since they don't 
have to test to see which cvar Confogl is actually using.  Consider it a 
feature that forces good practice on config makers!

Original comment by Canada.R...@gmail.com on 27 Apr 2011 at 6:09

GoogleCodeExporter commented 8 years ago 
Well it would be the one thats at the lowest point in the config. :p
But I agree that it might make it a bit more difficult on the other hand for 
others to edit said config.

Does the fact that you labeled it as a low priority enhancement mean that you 
still plan on doing this somewhen? xD

Original comment by Dynastic...@googlemail.com on 1 May 2011 at 12:16

GoogleCodeExporter commented 8 years ago 
Nope, when the status is Accepted it means we are planning to work on it.  I 
just didn't want to set it to WontFix in case Prodigy has some reasoning for 
doing this.  I put it as low so it would be moved to the bottom of the list so 
I don't confuse it with any newer issues.

Original comment by Canada.R...@gmail.com on 5 May 2011 at 6:51

GoogleCodeExporter commented 8 years ago 
Done in LGOFNOC: 
https://github.com/ProdigySim/LGOFNOC/commit/8a25effc04f8bcee09246814fe7931aad83
fc505

Original comment by TheDonSanchez on 20 Nov 2011 at 7:06