This whole issue starts somewhere around the end of last year, 2009. I had discovered that I was still being charged by PowWeb for a hosting price from 2005, which had since dropped to almost half the rate since. I contacted support over this, and eventually decided that, due to the general quality of the hosting service dropping since they got bought out a couple years ago, that I would just set the account to change to domain parking once the web host plan expired, this September, so that I wouldn't loose any domains during the move to a better host. So I did. Or at least I thought I did. Imagine my surprise when I logged in during May to find the following on the account renewal page:

2012? What? I haven't even agreed to renew in 2010 yet! I go over to the billing information page to find out that they are, in fact, billing me on September 9, 2010 for another two years of sub-par hosting. So a week is spent waiting to find out with PowWeb support what is going on, finally leading to this resolution:

So they said I would not be charged for another two years, and my website's hosting plan will expire as expected in September. Yes, this is what I want. Fast forward to today, where I log in to check which day it is that my hosting plan with PowWeb ends and I discover this:

They are still charging me, from the future, for two more years of hosting. What was all that from three months ago? Did that not mean anything? Why is my account still set to renew in 2012 without the option to NOT RENEW IN 2010? To top that off, their front page advertises their current hosting plan:

Let's do a little math here: $3.88 per month for 24 months equals $93.12. The "regular" price of $7.77 per month, which hasn't been a payable price for long over a year now ("limited time only" is longer than "unlimited transfer," apparently), is $186.48 for 24 months. I am being charged $203.28. Divide that by 24 and you get $8.47 per month. What is this? The only thing I can think of is that PowWeb, once famously known for having a stable hosting service for no more than $7.77 per month, has gradually devolved into some sort of scam.

Things work again. Apparently when you create a new MySQL database, Powweb doesn't actually create a new user login and what you put in the password field just changes the old one, so everything stopped working because the password for three different databases were changed because I created a new one.

Now that school is out for a bit, I was able to get more work done on 60 Seconds to Deliver. Here's the previous to-do list with progress updates:

• Air attacks - 77%
• Ground attacks
• Enemies - 10%
• Building variety - ?% (More than before)
• Game background
• Introduction cutscene animation
• End sequence and game over screen
• Difficulty levels
• Music

My contract with my current website's host runs out in a few months. I had decided not to renew it and move to a different host, since PowWeb's service has been going down-hill ever since they got bought out by some larger hosting company. Don't be surprised if there's any downtime during the move. Though with how well things have been staying up lately, you probably won't notice anything different until it's moved over to the new host.

An issue many of us have as Flash animators and game developers is protecting our work from appearing on websites that for some reason or another we don't want it to show up on.

Site-locking is the method of locking your Flash file so that it works only on the website(s) you want it to. There are numerous methods for site-locking your project out there on the web, but many are simple and don't protect against more devious content-lifters.

Most site-locking scripts are designed with the following logic: you want it to only work on mywebsite.com, so you make it so that it only works when mywebsite.com is part of the URL. This is pretty effective until someone places your file in a certain folder such as www.badwebsite.net/mywebsite.com/, or plays around with their sub-domains so that they have it working on mywebsite.com.badwebsite.net.

So how do we go about coding a site-lock that takes these problems into consideration? The first thing we'll want to do is get the URL that the Flash document is being hosted on:

var siteURL:String = root.loaderInfo.url;

The URL will be build of three main sections. The first is the transfer protocol. This is the http:// part of the URL. We'll want to strip that off our URL, though there are a number of different protocols each with different acronyms. To get around this, we use the split function to split the URL where the "://" part is.

var httpBits:Array = siteURL.split("://");

We now have the variable httpBits, which is an array containing the split strings from siteURL. httpBits[0] will contain the "http" string and the second two parts of the URL after the "://" part is stored in httpBits[1].

So now that we've removed one part of the URL, we're left with the other two parts: the domain name and the folder(s) that contain your file. We only want the domain name, and we can get that by splitting our string with "/".

var urlBits:Array = httpBits[1].split("/");

Now we have the array urlBits containing the domain name and each folder along the directory tree to your file. The domain name is stored in urlBits[0], but there is still one more step to take before we can compare the URL's domain name with our preferred domain name.

The domain name can be as short as domain.com, but it can also be lengthened by sub-domains, which can be named in ways meant to trick your site-locking scripts as presented above. We will need to split the domain name with ".":

var domainBits:Array = urlBits[0].split(".");

Now that we have an array of domain parts, we can start comparing them. The real domain we want to check with will be stored in the last two entries in our domainBits array, so we can finally use them to check the website's domain name:

var i:int = domainBits.length;

if (domainBits[i-2].indexOf("mydomain") < 0 ||
	domainBits[i-1].indexOf("com") < 0)
{
	/* If the domain isn't the right one, your script to handle that
	goes here.

		You could remove the display object containing your game
	or, if you're using the Flash IDE and programming straight into the
	time line, use gotoAndStop to send the player to a frame that loops
	back onto itself.  Whatever you do, you'll want to display some
	kind of message telling the user where they can legitimately play
	the game or animation. */
}

Here is the whole code built into a function that will return true if the website's domain name matches the one you specify or false if it doesn't match:

private function checkURL(URL:String):Boolean
{
	var siteURL:String	= root.loaderInfo.url;
	var httpBits:Array	= siteURL.split("://");
	var urlBits:Array	= httpBits[1].split("/");
	var domainBits:Array	= urlBits[0].split(".");
	var myDomainBits:Array	= URL.split(".");

	var i:int = domainBits.length;
	var j:int = myDomainBits.length;
	
	if (domainBits[i-2].indexOf(myDomainBits[j-2]) < 0 ||
		domainBits[i-1].indexOf(myDomainBits[j-1]) < 0)
		return false;
	return true;
}

This allows you to check multiple domains and handle them like this:

if (!checkURL(mywebsite.com) && !checkURL(somewhere-else.net))
{
	stop();
}

I hope this helps anyone with questions about site-locking.

Final project for the Intro. to Animation class I took last semester.

Last week's class sketching assignment was to create a pirate, a cowboy, and an astronaut, with one of them being female. So I drew a communist space pirate, a robot cowboy, and an astronaut taking her astrochihuahua for a spacewalk.

My post for the month. School's almost over, just one final left. I got a quick Flash job that should be done by the end of next week. In an effort to reduce redundancy, the "News" page now redirects to the Blog and the main page will eventually be updated to reflect that. The Portfolio page will be next on the list of site updates. You'll find that some things are already marked with portfolio tags.

Anyone actually reading the RSS feed through Google Reader will probably find that everything is marked new again because I changed how the site treats URLs (people who aren't computers can make sense of them now). It might be better to just unsubscribe and resubscribe off a site RSS link so that everything links up right, since I'll probably be deleting the News page entry altogether.

Okay, so this hectic month is almost over. The midterms round 2, and the history term paper rough, peer review and final draft three-week combo are over, and my application portfolio is due this Thursday. After that, I can get back to trying to get something finished. Again.

I'm still working on the games whenever I can. Here's a list of what's left to finish in 60 Seconds to Deliver:

• Air attacks
• Ground attacks
• Enemies
• Building variety
• Game background
• Introduction cutscene animation
• End sequence and game over screen
• Difficulty levels
• Music

A selection of gesture drawings from January and the beginning of February. I started with a micro-point Uniball and switched to a Pitt brush pen later on. Drawing time ranges from 30 seconds to 2 minutes.