Anybody who never got a registration mail, IM me here with your handle or email address and I'll get you fixed up.

Anybody who tried to register but wasn't able to, also let me know and that'll take longer but I will get it fixed up for ya.

I'll also be going through the support requests on the site soon, I promise!

For the record, I think I figured out what's happening with the registration being weird (and why sometimes other people's form responses end up showing up in it -- and it's not my fault, actually!)

Some ISPs, (AOL for instance, as just one but a big one) in order to appear to be faster than they really are, cache web responses. Now, they're set up to not cache CGI scripts (things ending in .'cgi', '.php', '.asp', '.cfm' and so on -- known negotiated content types) and there's probably a meta tag that I don't know about which also overrides it.

XFX3d is written entirely in old-fashioned Perl CGIs (except for the fora, which were put in as PostNuke PHP a while ago just because of a specific forum I was formerly hosting -- and I keep meaning to rewrite that to have threading forums because I have a way to make properly threaded forums that respond quickly).

One of the common things done on Perl based websites is to use an apache webserver module called 'mod_perl' to speed the scripts responding time up (for the record, the webserver itself barely got bogged down at all during all that, it was just the connection and I think the caching thing I'm talking about now that were having issues, so if I can eventually afford colocation that'll solve a lot).

Usually people set up mod_perl to just do all CGI scripts as mod_perl. However, since I like to be able to specify things as 'staging' and 'live' -- and in some cases non-mod_perl scripts actually do work better for some unknown reason, too -- I like to have both method available to me. Regular old non mod-perl CGIs are slower but have the advantage of re-reading included modules every time. Mod_perl stores the preloaded modlues in memory (as well as the Perl interpreter itself) in order to speed things up. However, if you have a module doing part of the work, and you change that module, you have to restart Apache to make it reload (there are other ways but usually even more of a pain in the butt).

As a result, all my mod_perl CGIs are named '.mp' (for mod_perl, of course). However, this also means that those caching servers don't see the '.mp' as dynamically generated code (they have no clue what it is) and thus might go ahead and cache it.

A lot of Renderosity (and formerly all of Rendo, not to mention RDNA) uses the proprietary Bondware system with a '.ez' extension, which is also nonstandard. It may be that more ISPs know about this extension, but it's probably that there is some code I can insert that I don't know about to force them not to cache (the Pragma: No-cache header doesn't work consistently as that is old code, and it also calls for sending non-parsed headers usually, which is a pain in the butt -- though there may be a way I can make Apache send this header automatically on anything mod-perl that runs).

I'll look into that and, if all else fails, I'll do something goofy like make my .mp scripts be .asp or .cfm or something else. I mean, I can use any extension I want really (though it might end up complicated with some browsers that make assumptions if I was really weird, like making CGI webpages end in .jpg for instance).

Actually the CFM one would be kind of funny, as it'd result in me getting a call from the company that makes ColdFusion asking me why I'm running ColdFusion without paying for a licence, at which point I'd inform them that I'm not and they have no control over file extensions.

So in a weird way, this massive server hit was good on a whole other level -- it made it so I can see things that need fixing better, and how common or not-common they are. Thus thanks! B^)

I'm the asshole. You wanna be a shit? You gotta go through ME.