Why Steam Beats Pirating, Hands Down

Valve’s Steam is by far my favourite method of digital distribution for gaming. It is simply so easy to use and it’s getting better too, with the new UI beta being a massive improvement on the previous version of Steam.

Why is Steam so good? In case you’re not familiar with Steam, let me run you through the process of buying and playing a game:

  1. Browse to the game on the Steam store
  2. Click “Buy”
  3. Enter payment details
  4. Wait for the download to complete
  5. Play.

That’s it. No complicated installation to go through; no waiting while the game downloads the latest updates; nothing. Compare this to buying a game physically, where you have to install the game (usually swapping discs halfway through), download the latest updates, make sure PunkBuster1 (or similar) is up to date and usually insert the disc every time you want to play a game.

Even compared to pirating games, it’s so much easier. Torrents are usually slow because of the amount of other users downloading at the same time (seeds:peers ratio is usually low), while Steam’s content servers have always been exceeding fast for me (2Mb/s compared to 40kb/s for a comparable torrent). Additionally, simply finding a torrent is usually 10 minutes of searching itself.

Steam’s ease of use shows. Of the past 10 games I’ve played (excluding free ones), 9 of them I bought from Steam, and the other was Modern Warfare 2, which uses Steam.2

Steam is an absolute win for gamers everywhere. The ease of buying, downloading and playing is fantastic. I’m not aware of any other distribution method for games that is as easy to use.

  1. Don’t get me started on how much I despise PunkBuster. VAC is so much better. [↩]
  2. The only reason I bought it physically rather than via Steam is because I couldn’t be bothered downloading it. [↩]

I hate doing work for free. It’s fine if it’s a project I’m interested in, but when I do the work and then people complain, it annoys me. Sure, it may not be perfect, and I’m up for modifying it, but telling me (not asking) to redo it is unacceptable.

Using Hahlo4.1 With Prism

Since Jonnie Hallman is stopping development on DestroyTwitter (still my favourite twitter client ever), I thought I’d try out Hahlo. It appears to be a great Twitter client from what I’ve heard, and the developer is a fellow Australian!

As Hahlo is designed for phones (specifically the iPhone/iPod Touch), I figured it’s best to use it in Prism. Alas, two problems arose. Firstly, using oAuth opened the window in Firefox, and the window was the wrong size. I did a bit of digging, and found a way to fix this.

Open C:Users[user]AppDataRoamingWebAppsprism@prism.app, and drop the code from this gist into there.

Merry christmas!

Plugin Options Page and Nonces

As any good plugin developer knows, WordPress 2.8 introduced a new way to handle the changing of options. The register_setting() function is used in combination with options.php to create an easy way to create option pages for plugin settings. This enables the plugin developer to focus on his plugin, rather than spending a great deal of time creating options pages.

Sounds great, right? Well, sure, until you introduce nonces (which you should).

For most developers, using the update-options nonce, in combination with the page_options POST variable, will suffice, and works fine with their current code. However, the code itself says “this is for back compat and will eventually be removed”. Being good developers, we want to keep up with the latest standards, and make sure our plugins work in future versions of WordPress. Our other option is to set the option_page POST variable. This sounds fine, as we already have unique identifiers for our plugin functions (right?), so we can simply do <input type="hidden" name="option_page" value="rm_plugin_options" />, right?

Wrong. Turns out, you need to do one extra step: whitelisting your options.

Whitelisting your options is what you usually do with page_options, except, that POST variable isn’t used when we use option_page. Instead, we need to whitelist the options in the HTML, via the whitelist_options filter. I could explain the setup of whitelist_options, but you can find that out by simply looking at the source of wp-admin/options.php. Instead, here’s some example code. Enjoy.

function rm_whitelist_options($whitelist) {
	// option_page is the key here, values are option names to let through
	$whitelist['rm_plugin_options'] = array(
		'pixopoint_themeoptions',
	);
	return $whitelist;
}
add_filter( 'whitelist_options', 'rm_whitelist_options' );

So, finally done? Nope, still have one last thing to do: nonces! This is the most simple part. You must set it to [option_page]-options for options.php to accept it.

Finally, we have it done. Now, good luck with your plugin!

A New Blog. Again.

Well, looks like I’m starting a new blog. WordPress powered, again.

I’ll be testing a certain plugin here, codenamed Shot Glass. I’ll be revealing what it is at some time in the future, but for now, you’ll just have to see what the effects of it are… if you can find them. 😉