A cookie system
 

I was planning on writing an extension that would implement a 'cookie' system for SourceMod which would allow per-player (and per-plugin, where plugins can't access other plugins' cookies) long-term storage of basic data. But, I would like to know if scripters think if this would be useful or not... here's my current idea for implementation: http://www.ampaste.net/10980

Supports use of all the basic types (string, number (integer), float, and bool) while giving each cookie a lifetime, or expiration.

Anyways, just wanted to see if this kind of thing would be worth making. Suggestions are always welcome.

Re: A cookie system
 

I don't see why not, like I said and bail said, I currently use keyvalues because it's the best, and as far as I know, only long term data storage system in sourcemod. An alternative would be great.

Re: A cookie system
 

I like the "autocleanup" based on the expiration.

:)

Re: A cookie system
 

AMX Mod X had a system like this for HL1 called "nVault" -- it was a bit more generic. You could create a vault where you could store arbitrary key/value pairs, and each pair was timestamped so you could expire them.

The only problem was that it was flat; your idea has different key/val pairs for each player, which is an interesting thought.

Note that if you just wanted to play around with the API, you could use KeyValues internally. Once sqlite support comes around, it may be easiest to move to that, unless you have something more efficient in mind.

Re: A cookie system
 

If their isn't any vault yet why not :|
And can I have a link explaning "keyvalues" ?

Re: A cookie system
 

Re: A cookie system
 

I planned on doing all of the storage manually (taking advantage of hash lookups, sorting based on usage, etc.) and storing to file on every level transition... I noticed nVault had a journaling system which is nice. The cookies system would probably have to have something similar.

Steam ID and IP lookup will be very fast since both are easy to make 32-bit keys out of (reversible, too).

Edit: One thing that I am not sure about is how the value of the cookie should be stored internally...should it always be stored as a string? Or, should it depend on what it was last set as, and make its type dynamic--similar to how KeyValues works I believe, with a union and whatnot.

Re: A cookie system
 

Always a string is probably best, like a cvar, it's easier to go back and forth between types.

Re: A cookie system
 

I would assume that a good syntax would be:
InitCookieSystem(maxplayers,TYPE_INT);

Re: A cookie system
 

Thanks, just as a ini file just with sub sections (Maybe more as a hash of hashes).