If you are referring to the "Loading..." screen, then it's because it has to perform an RPC to Allegro.cc. If you're not referring to the "Loading..." screen, then keep in mind that the tour bubble won't pop up until the page has finished loading (including all images).

"Hiding"? http://cgamesplay.com/bin/tour/ is all of the javascript. json.js (available via google) is JSMin'ed, the rest is there, uncompressed and neatly formatted.

Is my coding style that bad?

I just would like to point out that no one can see your private user.js file. (That would be a privacy breach.) The user id parameter is completely ignored and really only exists in case multiple people share the same browser.

I wonder how long it took to get this much done... We've seen it's still buggy... As well as unresponsive and slow loading... And unless I missed something it's still very short. I'm not trying to put down your efforts, CGamesPlay. It's really rather cool, but this might be a good application for Flash...

It seems odd that you would have us load code from your custom js (even though what appears to be happening per Matthew Leverton's rule is our own user.js file is loaded again... ) and from a file on your domain. Why didn't you just post all of the code (all 1471 lines of it )?

The entire thing has taken roughly 10 hours of work. I originally wrote the balloon library and wanted to test it and show it off a bit. So I made this.

Could you please be more specific?

See my above post, I need more information. Also, what browser and machine specs?

Well, there's the front page chapter, which takes you through the news, the front page, the IOTD, and the resources section. Then there's the manual chapter, which includes a short breakdown of the manual page. Then there's the forum chapter, which goes through the thread list as well as the actual thread page. All in all it'll take about 15 minutes to go through if you read everything.

It's not possible to do the balloon tips in Flash, or to provide the interactivity part, or to navigate to separate pages on the site. Also the upcoming Posting chapter will really be inappropriate for Flash (it's going to make sure you've selected a good topic, used good writing style, not posted code without code tags, etc).

Ideally, the finished product will have all the ugliness of packaging and distribution worked out. Unfortunately, there's going to be at least 200 KB of javascript, even if it's compressed. I want to keep the steps part on my server so that updates happen without reinstalling. And with that vein in mind, tour.js, balloon.js, and json.min.js just follow suit. Btw, "hiding" was a bad choice of words. You can navigate to any of the URLs to read the source yourself. You can copy them to your server, too

What I'd like to happen is have a newbie come to my tour installer, put in their user and password, and have a script copy the necessary code into their custom JS field. Of course, I will also include directions for manually installing, for those who don't feel like giving away their user information. I'm also going to write an uninstaller directly from the tour (after you've seen everything there is to see it will prompt to automatically uninstall itself).

Thanks for everything you guys have said; I'll definitely keep working on it. I'd really appreciate it if you guys kept the bug reports coming in!

Let me break the process down in pseudo-code:
Process of any single page view while the tour is installed:

User custom JS is loaded (possibly from cache)
User custom JS is loaded with caching disabled
JS files from my domain are loaded (possibly from cache)
If the tour has not been run before
    Put up the loading screen
    Open the theme-css page in an iframe
    Set the configuration variable specifying that the tour has been run
    Save the page
    Close the iframe
    Show the welcome screen
Else if the cookie tourWhenPageChanges is set
    Go to that tour page

The second step is necessary because the user JS file is cached by the browser, so tour configuration values are cached, so it will assume the tour has never been run before until the cache expires.

That's why the post goes to "my" user javascript: it's loading a non-cached version of the current user's javascript, so the configuration is guaranteed to be updated. It's very hackish, but without very much thought going towards it I can't see any other way. Well, I could store the tour configuration off-site, but that's evil.

Seems the top row is counting the smilies below the reply box ....

There shouldn't be a top or bottom row. The user.js file is being loaded twice, hence a second csmiley bar is created, which also counts the smileys in the first row...

CGames's javascript loads it a second time...

Matthew fixed the "There is also the text that is displayed at the top of the custom js page when your JavaScript is loaded...", but I've explained why I load the user JS file 3 times so I'm not going to do it again.

Did you get the "Tour Exited" balloon? Btw, if you go back to the control center, press the "Begin Tour" link by the Log Out link to skip to a particular chapter.

A cookie isn't persistent. Short-term things like the next page in the tour can be stored in a cookie, but whether or not a user has ever seen the tour before needs to be stored in a manner that will affect all browsers he connects to the site from.

Matthew seems to have added a field for me

[append]
Thanks, Matthew, that will work a lot better! I'll switch to using it ASAP.

Now the script is nice and simple. It uses the new User Data feature of Allegro.cc, so it doesn't require any weird hacks. Here's your new JavaScript:
document.write('<script type="text/javascript" src="http://cgamesplay.com/bin/tour/"></script>');The old JS either will or will not work at this point. I'm banking on "will not".

Test this one out, let me know if anybody has any bugs. Tomasu, does it work in Konqueror?