The GCT for no-homebrew is the same as default, with the Disable Custom Stages code.
Ok, the reasoning behind Zelda. First, foremost, and above all else, the biggest consideration in my mind is mitigating the stupid, stupid loading queue and making the move have, ideally, a constant duration. It solidifies risk when using the move, allows you to make snap decisions about transforming because you know how long the move is going to take. I'm fully aware of the mechanics behind ryoko's change, and slowing the startup animation so that the total duration outside of the actual transform load is the same, but moving the point where it goes into transform. I think, quite frankly, that it looks like ***. Furthermore, I think it's a sloppy direction in which to take the entire dynamic of the move, because it tries to negate the impact of this undesirable trait (a nonstatic load time) instead of remove it entirely. I understand how it works. The dangerous period is both constant and contained in a single animation, and the negative part concerning the actual transform is no longer important because as soon as it's finished the move is over. I don't like the idea. I would prefer to take the entire thing and encapsulate it as a single entity. Towards that end, SD loading is the clear path ahead. Solid state storage retrieval is exceptionally faster than optical, drastically reducing the necessary loading time. Maybe it's not the same from system to system, but on each system it's the same from instance to instance. But, I've seen you all say, that doesn't change the fact that it's not a constant speed, because of the loading queue, etc. No, at this point it isn't and most likely never will be, but it is faster, and it is better. And just based on one of your examples, I think we have an avenue of investigation to help reduce the impact of the problem further.
The way I'm looking at it is, if you take all the factors involved in doing a transform load, and convert them to solid state storage, it will decrease and largely homogenize the total time it takes to perform all those loads. What this does, apart from decreasing the total length of load time, is decrease the variation in the total duration. Say your vbrawl load time is somewhere around a second. But we've all seen the factors that can affect that. Having multiples of the same character already loaded, hitting a stage loading point, can make that total duration, or t, last anywhere from less than a quarter second to nearly 2 seconds. The variability of t, or Δt, is quite large, over 100 frames.
|-----------------| t Loading just Zelda
|--|t Zelda preloaded
|-------------------------------------| t Loading Lylat plus Zelda
....|--------------| Δt Zelda only
....|----------------------------------| Δt plus outside factors
However, if we Take the Zelda files and put them on the SD card, the time required to load them is changed drastically.
|----| t Loading just Zelda
|--| t Zelda preloaded
|-----------------------| t Loading Lylat plus Zelda
....|-| Δt Zelda only
....|--------------------| Δt plus outside factors
While my diagrams are not to scale, you can see that just by putting Zelda files on the SD card, you can drastically cut down on both the total amount of loading time as well as the load time variance. In other words, Δt becomes relatively small. Using texture files, and maybe motionetc pacs, to reduce the t, and thereby Δt, of transforms is going to be part of the way the transforms are handled. This is not up for discussion. The idea I had last night was to investigate the other events that get dumped in the loading queue and mess with transform time. You all gave me the biggest perpetrator already: Lylat cruise. That stage is really 5 pacs in one. We can put them all on the SD card and all but eliminate the potential for variance on that stage entirely:
|----| t Loading just Zelda
|--| t Zelda preloaded
|-------| t Loading Lylat plus Zelda
....|-| Δt Zelda only
....|----| Δt plus outside factors
This would substantially cut down on just about all of the potential for variance in the transform time. What we can then do is search out other potential speed bumps in the loading queue and work out if they can be similarly transferred. I'm going to make a logical leap here, so bear with me, but for the rest of this post I'm going to assume the invulnerable loading period is static, or as close to static as we can possibly make it, and therefore, based on what I've demonstrated here, able to be regarded as a fixed amount of time.
If the amount of time it takes to load Zelda is constant, then the only factors left to consider are the (approximate) total duration of the transform animation and the animation appearance. When you assume a near-constant transform time, then shifting the placement of the load event is no longer necessary. It all becomes part of the total animation duration. It can then be relied upon in making the decision of whether to transform, at any point in the match. Between stocks, defensively, offensively, whatever.
tl;dr - Go back and ****ing read it. Even if SD loads aren't truly static, moving enough files to the SD card should cut down on so much of the load time variance that it's close enough to be considered so, which completely negates the need for an animation tweak.
