[Impact123]

Like i told you in the updater thread, it's not easy to change or remove stuff because the format cannot be relyed upon.
The default value could be changed in theory, but there is a reason this isn't implemented, think about someone who relies upon it being the same value after an update.
I don't plan to add any new complex functionality besides bugfixes, but feel free to send me an pull request if you want.

Originally Posted by Bittersweet not even the version.

A plugin version cvar shouldn't be in a cfg file.

[Bittersweet]

Originally Posted by Impact123 Like i told you in the updater thread, it's not easy to change or remove stuff because the format cannot be relyed upon. The default value could be changed in theory, but there is a reason this isn't implemented, think about someone who relies upon it being the same value after an update. I don't plan to add any new complex functionality besides bugfixes, but feel free to send me an pull request if you want. A plugin version cvar shouldn't be in a cfg file.

Right, I was just using that as a test, which was a bad choice. But it doesn't matter, this only adds new cvars, and does preserve values for existing cvars. It doesn't remove unused cvars, or update any of the changed default values, descriptions, etc.

This is very nice, and I'll use it, but I still need to implement my code anyway. Some folks had suggested this did the same thing. It doesn't.

[Impact123]

I thought i let you know that TheChineese just ported the include file to the 1.7 syntax. You don't have to use the view_as operator anymore in your 1.7.* code.
If, for whatever reason, you currently can't use the 1.7.* compiler for your project, the last non 1.7 code can be found here.

[TnTSCS]

Thank you

[Impact123]

I just added convar caching to the include. I'm not really satisfied with the amount of duplicate code and I've only tested this very briefly (it shows), hence it's in the development branch, but it shouldn't break anything unless you use the added function. In my tests this method reduced the overall time it took to run the test script, which can be found here, by 50~%. This will, of course, only work after the config was created the first time.

The way this works is relatively simple, you use it like this

PHP Code:

// Call anywhere after AutoExecConfig_SetFile but before using AutoExecConfig_CreateConVar
AutoExecConfig_CacheConvars(); 


This will read the whole config and store everything within which looks like a valid convar in a trie. It will also toggle a switch which tells the AutoExecConfig_FindValue function (which is internally used by AutoExecConfig_CreateConvar) to use this trie instead of reading whole the config file and searching it within.
If you could test this and and let me know what you think, that would be great.

[headline]

Originally Posted by Impact123 I just added convar caching to the include. I'm not really satisfied with the amount of duplicate code and I've only tested this very briefly (it shows), hence it's in the development branch, but it shouldn't break anything unless you use the added function. In my tests this method reduced the overall time it took to run the test script, which can be found here, by 50~%. This will, of course, only work after the config was created the first time. The way this works is relatively simple, you use it like this PHP Code: // Call anywhere after AutoExecConfig_SetFile but before using AutoExecConfig_CreateConVar AutoExecConfig_CacheConvars();  This will read the whole config and store everything within which looks like a valid convar in a trie. It will also toggle a switch which tells the AutoExecConfig_FindValue function (which is internally used by AutoExecConfig_CreateConvar) to use this trie instead of reading whole the config file and searching it within. If you could test this and and let me know what you think, that would be great.

Im sorry I dont understand. Why would I use this?

[Impact123]

Well, to get the benefit of a cache, performance, which is crucial on a game server

[headline]

Originally Posted by Impact123 Well, to get the benefit of a cache, performance, which is crucial on a game server

Hm okay!

[Powerlord]

Originally Posted by Impact123 Well, to get the benefit of a cache, performance, which is crucial on a game server

...and you think a StringMap lookup is going to be quicker than just grabbing the default value of the ConVar directly?

Have you profiled this?

[Impact123]

No, but it's faster than reading the autoexecconfig file. A convar's value isn't useful in finding out if the convar exists in this file.