• Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!

    You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!

Completed Random Custom Stages

DRGN

Technowizard
Moderator
Joined
Aug 20, 2005
Messages
2,178
Location
Sacramento, CA
I've had this thought for a long time; I think it'd be awesome if there was a code that does something along these lines: whenever you select any stage, the code randomly generates a number (for simplicity for this example, let's say from 0 to 9), includes it into a filename, e.g. "GrSt.3at", and then if that stage exists in the filesystem, load it. If it doesn't, the code starts over with another random number and tries again. (In part, similar to how the game normally picks a random stage.)

If the code generates a 0, it could skip adding the number to the filename, so the game would still look for "_.dat", or, all default stages could be renamed to .0at.

I know something similar to this already exists in 20XX, but I'll get to that later.

So far this is pretty simple for vanilla Melee, where you only have one stage select screen (SSS). But for 20XX's multiple screens, perhaps the stages could be named so that the first character in the extension corresponds to the SSS number, and the last character could be the number randomly generated by this code. So, for example, if you're on the second SSS, selecting Yoshi's Story, and the code generates a 4, the filename generated would be "GrSt.2a4". (It would be interesting to talk about why we can't have strings of non-original size, like GrSt.dat-2.4, too, which would make them to be a little more readable. But that's a tangent and not really that necessary.)

Obviously this would be a toggleable option that could be disabled in options if this were in 20XX, for those that might not want to use it or for tournaments. Controlling whether this feature is turned on/off on a per-stage basis would be pretty cool too, but is obviously not as important and could be added to the super-low priority todo list. (or even deeper options for percentage chances for certain numbers? lol)


So, something similar to this already exists in 20XX for Battlefield. But an important distinction is the 'retry' part; checking to make sure the stage exists and trying a different number if it doesn't. As it is now, 20XX may crash if you take some of the Battlefield stages out of the filesystem. (Although I noticed there is no GrNBa.1at by default, which I think is pretty weird. Maybe I just haven't loaded the stage enough times to see a crash that should be there.) The other distinction is of course the numbering for different SSSs.

A code like I'm describing would make adding new stages to your game as they're released, while keeping favorite existing stages that share the same stage-slot, incredibly easy. (Especially because the new features of DTW will allow you to easily add a file to an ISO (that's "add", not import/replace) without having to use GCR to extract and rebuild the disc.) So, for example, if you already have two different Yoshi's Story stages in your ISO for the first SSS (i.e. "GrSt.1a0" & "GrSt.1a1"), and a new really cool Yoshi's Story comes out, you would just name it "GrSt.1a2" (if you want it too to be loaded on the first SSS) and add it to your ISO. Once you've added the stage, the game's code would do the rest and no other steps or modifications would need to be taken. You just boot up and enjoy. This kind of naming convention would make it easy to decide which stages you want to be able to be loaded for each of the SSSs, and allow for a ton of user customization in stage choices.

It might be a good idea to have the SSS's numbering start from 0, to match the numbering of the individual stage numbering, to prevent confusion. (If we changed the latter to match instead, we'd have less stages per slot.)

Thoughts?
 

Achilles1515

Smash Master
Joined
Jun 18, 2007
Messages
3,211
Location
Cincinnati / Columbus OH
As I said to you earlier, this gave me the motivation to rewrite the Stage Swap code, or at least a portion of it. This stuff still applies. The current Battlefield texture Debug Menu flag was quickly hacked up and poorly implemented (really, this is why I never got around to adding the other stages because I was so unsatisfied with its original implementation). The new code now implements texture filename swapping as well as the stage ID swapping detailed in that link above, all within the same injection code which makes me a happy camper. Its current design is to allow 16 custom stage textures for each of the legal stages (ex. GrNBa.0at to GrNBa.Fat), which will have a Debug Menu option to select a specific texture or random between them all. The process for random stage selection is as you stated; if the file does not exist in the ISO, a new random filename value is chosen and checked for validation.

Like Popo/Nana and Zelda/Sheik, there are always outliers in this game that overcomplicate everything. For stages, it is Pokemon Stadium and the transformations.
1) Proper filename extensions (.usd/.dat) is selected based on current language setting and added to the ASCII stage name in RAM. So it is easiest for Pokemon Stadium alt textures to be of the type GrP0, GrP1, etc.
2) Transformation stages are separate files...still thinking of the best way to handle these, if at all. I might not have support for changing these for the time being.

I like the idea of per SSS textures, but there are some logistics behind it that the Hack Pack is not ready for. And not nearly as streamlined and convenient as your suggestion, per SSS random textures (up to 4) can already be accomplished with the stage swap flags detailed in the linked post (except for the first SSS page).

.1at is "unused" in 4.05 because the number used to replace "d" is directly selected from the Debug Menu string enum (0 = default, 1 = random, 2 = ancient, etc..) and 1 [random] doesn't represent an actual stage.
 
Top Bottom