[^BuGs^]

This plugin is "plugin development" script. It allows your script to use the API to store client preferences and retrieve them, if you have this functionality. This allows "set" standards to take place and saves plugin authors time into not having to develop their own system. The system is using thread SQL operations so there is no pause in script process.

As it stands right now, this will not be in the "core" Sourcemod code until after 1.0.0. There is no public "cvar" as it doesn't require one.

Post all bug reports/ideas here and view current status here. Bug reports/ideas posted on the forums will not be taken. If you do not report bugs, I will not be able to fix it. Use your forums username and password to login to the system!

REQUIREMENTS:

• Min. Sourcemod Version: 1.0.0.1268

API:

/**
 * Insert an item into the database. If already exists, it will update with the new value.
 *
 * @param userid    Client's Userid.
 * @param steamid    Client's SteamID.
 * @param id        Your Unqine ID.
 * @param value        The value you are setting.
 * @noreturn
 */

native ClientPrefUpdate(const userid, const String:auth[], const String:id[], const String:value[]);
 
/**
 * Delete the item from the database.
 *
 * @param userid    Client's Userid.
 * @param steamid    Client's SteamID.
 * @param id        Your Unqine ID.
 * @noreturn
 */

native ClientPrefDelete(const userid, const String:auth[], const String:id[]);
 
 
/**
 * Select the item from the database and get it's result
 *
 * @param userid    Client's Userid.
 * @param steamid    Client's SteamID.
 * @param id        Your Unqine ID.
 * @noreturn
 */
 
native ClientPrefSelect(const userid, const String:auth[], const String:id[]);

/**
 * The data from the selection is sent through this forward.
 *
 * @param client    The Client ID.
 * @param id        The Unqine ID.
 * @param value        The Value.
 * @noreturn
 */

forward OnClientPref(client, String:id[], String:value[]);

API Note -- I did add optional support for this until this is added into the SourceMod core. Please read this wiki article that explains this.

CHANGELOG:

• 1.0.0.0 (08/05/07)
  • Public Release

INSTALL NOTES:

• Place clientpref.inc API in your include directory in relation to spcomp.exe

Attached is also my test plugin script used to test the features. It's very basic.

[API]

Great job :]

[Lindgren]

I asked on irc but it was getting late/early and i couldn´t hang around so ill just ask here.
1. Is there any way to get a value based only on steamid? Since clientid change everytime a client connects i can´t use that.
2. What would be the quickest, most efficient or any way at all to delete or totaly clear the database from inside a plugin?

[^BuGs^]

The field you pass is not clientid, but the userid. The reason is the SQL can not process something to someone who disconnected. So the first flied is always userid other than the forward. For the value you need both the STEAMID and the "pref" id. If it was jsut the steamid, it get all the STEAMID prefs and it might not be yours, and that could be pretty big depending on how many prefs you store plus all the other plugins.

For the mass deletion, that option does not exist. I could work on a new native that deletes all your IDs if the plugin gets unloaded..

public OnPluginUnload()
{
      ClientPrefRemove("Your id");
      ClientPrefRemove("Your id 1");
      ClientPrefRemove("Your id 2");
      ClientPrefRemove("Your id 3");
      ClientPrefRemove("Your id 4");
}

[Lindgren]

Im looking it over trying to get a grip of how it works, maybe i missunderstand or maybe even it´s the wrong tool for the job but all i need and trying to do is save a steamid and a value. So if i play in the server the value is saved, if i disconnect and rejoin 16 hours or 7 days later even i want to be able to get the value saved the last time.
Since i need to manually get the steamid and send as a string when i call the function to write and there is nothing more uniqe then a steamid shouldn´t that be enough?

Again, i´m probably not understanding right but would be great if you could explain since it could be a nice shortcut for me. Have never used SQLite before only normal databases.

[^BuGs^]

Ok. lets take this example...

public YourFunction()
{
     ClientPrefUpdate(userid, <STEAMID>, <ID>, <VALUE>); // save
}

Now you left the server. Now your plugin gotta check when you join the server:

public OnClientAuthorized(client, const String:auth[])
{
   new userid = GetClientUserId(client);
   ClientPrefSelect(userid, auth, "Your ID");
   ClientPrefSelect(userid, auth, "Your ID 2");
   ClientPrefSelect(userid, auth, "Your ID 3");
   ClientPrefSelect(userid, auth, "Your ID 4");
}

public OnClientPref(client, String:id[], String:value[])    //    All values are passed through this forward as a string. You must do a match on your ID.
{
    if (strcmp("Your ID 4", id, false) == 0)
    {
        PrintToConsole(client, "ID %s Value: %s", id, value);
    }
}

This is what would have to be coded into the plugin. I will update the testpref.sp file to reflect this example.

[dalto]

How static is the user id and where are they stored?

In other words, what is the assigned life of a user id?

[^BuGs^]

The userid is unique and happens only once and is gone after the user leaves. You can get the userid from a client ID using the above function. The reason the plugin requires the user id because if a person who runs a query leaves before the process is finished, it could effect the new user who took the spot if the client ID was used again. However, if everything works out, the client ID is passed in the forward.

[dalto]

I have been looking at this for while and I have some concerns that I thought were worthy of discussion.

The first is that it seems to store all preferences in the same space. Meaning that if two plugins use the same id name they will stomp on each other.

The second is that it seems like there will inherent performance problems here. Since everything is stored in a single unindexed table, as time passes it seems like this grow unmanageable. Especially since there is no easy way to prune old entries.

If I take a quick look at the numbers lets say we have 10 plugins using the preference system. Server size varies but lets say that over time we are storing preferences for about 2000 people. A pretty conservative estimate I would say. Now lets assume that each plugin stores and average of three preferences each. That means the table has 60,000 rows. Every lookup has to now scan all those rows to find a match. Probably multiple times if they have more than one preference.

Lastly, there is no ability to store meta data about the id's. This makes it difficult to extend this plugin for generic actions such as someone's suggestion about putting a menu system on top of it.

I would make the following recommendations to make this more useful.

• Store each plugins information in a separate table or add a plugin field to the database. The former would help with performance more although it would be a little harder to manage.
• Put a composite index on steamid and id. This would make lookups a lot faster.
• Add a timestamp to every row. Add a function to prune information over a certain age.
• Add the ability to store some meta data about the plugin. This would take some real thought to figure out what makes sense and how to make it work with translations.

Please keep in mind that I am not an expert in sqlite performance so my suggestions may be way off base.

[^BuGs^]

The first is that it seems to store all preferences in the same space. Meaning that if two plugins use the same id name they will stomp on each other.

I would hope this would never happen, i.e. two plugins using the same commands, but going on to your other ideas to "help" this one...

The second is that it seems like there will inherent performance problems here. Since everything is stored in a single unindexed table, as time passes it seems like this grow unmanageable. Especially since there is no easy way to prune old entries.

Will add.

If I take a quick look at the numbers lets say we have 10 plugins using the preference system. Server size varies but lets say that over time we are storing preferences for about 2000 people. A pretty conservative estimate I would say. Now lets assume that each plugin stores and average of three preferences each. That means the table has 60,000 rows. Every lookup has to now scan all those rows to find a match. Probably multiple times if they have more than one preference.

Point taken, will work on the design.

Lastly, there is no ability to store meta data about the id's. This makes it difficult to extend this plugin for generic actions such as someone's suggestion about putting a menu system on top of it.

BAILOPAN has touched this issue in another thread, but to expand I will not design the menu system for client prefs until the menu generation core is completed.

Store each plugins information in a separate table or add a plugin field to the database. The former would help with performance more although it would be a little harder to manage.

Will add. I'll have to add a "CreatePrefTable("plugin");" command.

Put a composite index on steamid and id. This would make lookups a lot faster.

You already need the STEAMID and the "pref" id to select so I see no need to add the "composite index". I thought about this originally, but decided against it. With each plugin in a different "table", searching by SteamID and getting all those values will not be a problem.

Add a timestamp to every row. Add a function to prune information over a certain age.

Will Add. Default timeout will be forever, but plugins will be to set how many X days/hours/months/years it's good for for each ID, not just as a whole.

Add the ability to store some meta data about the plugin. This would take some real thought to figure out what makes sense and how to make it work with translations.

This is not me. That's BAIL.