Archive for the ‘Wiki Articles’ Category

Command API, Part 2 of 3

Friday, March 2nd, 2007

Today’s update is a large addition to the wiki, extending Wednesday’s article. (I think the timing got a bit screwed up so this might have already been on the wiki for the previous article.)

Given the length of the addition, this devlog article will be short. Most of the text is an application of console commands combined with the administration system, which has been described in much detail.

The major difference between SourceMod and AMX Mod X here is that admin access checking is done in Core, not in plugins. This lowers the burden on the plugin author, and allows Core to provide much more extensibility/flexibility via configuration files. While AMX Mod X 1.77 will have the ability to alter command flags, SourceMod takes this a step further with command groups, as well as per-group ACLs to deny or allow commands/command groups.

Command API, Part 1 of 3

Wednesday, February 28th, 2007

Today I’d like to highlight the latest wiki article: Scripting Commands in SourceMod. SourceMod’s Command API is slightly different than AMX Mod X’s; this is partly for optimization, and partly because of how Half-Life 2 works.

The first difference we’ll discuss is that there is no command filtering. As noted in the article, this notation is no longer possible:

register_clcmd("say /ff", "Command_FF");

Why didn’t we accommodate this? Two reasons, and they’re both related to one fact: The only usage of this syntax seemed to be for “say” and “say_team” and no other commands. I have never seen a plugin use this syntax for anything else, although I’m sure it has been done.

So, the first reason is that we’d be adding a rather complicated functionality with very limited use. The second reason is that since it’s limited, every command that went through IVEngineServer::ClientCommand would essentially be compared against a list of say hooks, even though most commands aren’t actually “say.” Of course, we could find ways to optimize around this; for example, per-command filters or filters strictly for say — but it’s a lot of work for a feature that’s entirely a convenience.

There’s a third hidden reason which will be explained in part 3 – it’s not actually technically feasible to implement it, given how Source’s command system works.

Next article we’ll see how SourceMod handles admin commands.

Handle System API, Part 1 of 3

Wednesday, February 21st, 2007

There’s a new wiki article up that goes over the Handle System API (from a C++ perspective) in somewhat scary detail. It also provides a complete introductory example. Visit it here:

The initial example is the typical usage of Handles: creating a temporary structure that can be safely shared in between plugins. When the Handle is destroyed (via CloseHandle once plus again for each time CloneHandle was called), the temporary structure is freed.

However, there are more advanced usages that take advantage of the security features. More examples will be posted about this in Friday’s article.

Administration API (Part 2)

Tuesday, February 6th, 2007

It’s finally here! Click here for an indepth article on the technical details behind the Administration API. This devlog article will go into how the API was formed, and its relation to AMX Mod X.

The SourceMod Administration API, from the backend, is designed to be flexible as both a fast lookup cache and an on-demand in-memory storage cache. This was to correct two flaws in AMX Mod X. Recall the two admin plugin types: flat file, and SQL.

With flat files, it is obviously unacceptable to reparse the entire file on a player connecting to the user. Likewise, since threaded queries came much later, it was unacceptable to start a remote query in the same thread every time a user connected. AMX Mod X solved this in a lazy way. The admin plugin defines a giant array (default max size is 64 admins), and reads every admin into it at startup. Do you need more than 64 admins? You’d better recompile.

AMX Mod X 1.77 eliminates the limit by moving the “admin cache” from the plugin and into Core itself, via natives (you can thank sawce for this feature, by the way). Certainly, the SQL side could be solved with threaded queries. Because AMX Mod X’s permission system is very simple, there’s no need to go further and use a cache, when the query can call set_user_flags() and be done with it.

But with SourceMod, things are a lot more complicated. Groups, command overrides, special immunity rules, and pluggable authentication methods add a good deal of potential overhead. Thus, the cache is used for everything; even with a threaded SQL implementation, the permissions must be loaded into an Admin object in order to be attached to an in-game user.

For plugins, this API is largely transparent. Unless you’re implementing specific access/authentication rules, or supporting a new storage mechanism, it is unlikely you will ever need to encounter it directly. Admin commands will be registered separately from console commands, and access checking will be automated by Core. Similarly, a simple native from Core will be provided which checks if one user is immune to another.

Writing Natives

Monday, January 29th, 2007

The good news: I’ve finally finished the extensive administration API. Sadly, I have not yet had the time to document it.

In the meantime, there is a new Wiki article up: Native Functions. As you will see, writing SourceMod natives is nearly identical to AMX Mod X. There are a few major differences:

  • cell is renamed to cell_t.
  • The params array is const.
  • Instead of an AMX structure, you get passed an IPluginContext interface which contains a large number of helper functions.
  • Retrieving strings from plugins is now a direct operation, because of our natively packed strings addition. As such, you can edit strings directly, rather than having to make a call to a secondary function. It also means there is no intermediate buffer which was previously a huge performance loss.

Overall, it’s similar enough to make AMX Mod X coders right at home; and having an object oriented context makes development much smoother.

Writing Extensions Article

Friday, January 19th, 2007

There is now a very long article on the wiki entitled Writing Extensions. If you haven’t read the earlier articles, Extensions are SourceMod’s successor to AMX Mod X’s Modules. They allow you to write C++ plugins that use SourceMod and SourceMM API, with the ability to extend plugins with new events and functions.

We recently finished this Extension System, and it’s one of the bigger and more complicated pieces of SourceMod. This week we will be releasing both the SDK and the extensions we’ve made so far as examples. All of the articles for next week will be more on extension writing and the SourceMod API surrounding it.

I am pleased to say that with this, we are reaching very close to a usable beta of some sort. This beta will be for developers only (i.e. very thin on user features), but it will be a very complete development system. Once we have finished the base administration plugins, we’ll be able to do a public feature release.

More on Handles and Tags (Articles)

Tuesday, January 2nd, 2007

The first two Wiki articles on SourceMod are up.

The first is a a brief look at Handles for scripting. It explains how Handles are used in scripts and why they are important. It also has an incomplete list of the Handle types SourceMod creates, which will be growing soon.

The second article is targetted to SourceMod, but also has information relevant to AMX Mod X as well. It offers an in-depth explanation of how “tags” work, why they’re not data types (except in one case), and how to avoid problems with them.

In the coming week, more articles will appear on writing extensions (C++ extensions to SourceMod), which includes writeups on the Handle and Administration API.


Note: Future articles will be timed posts, to appear at 10AM EST of the closest day.