BrawlWall is kinda buggy... but it revealed something interesting to me.

[Amazing Ampharos]

BrawlWall seems to like to subtly corrupt stage .pac files while saving (maybe it's because I always save stuff to different directories), but one of the random corruptions it did showed me some fairly promising behavior. Specifically, when messing with Mushroomy Kingdom 1-1, it created a version with drastically reduced scrolling speed (so slow at first I thought it wasn't scrolling). Perhaps stage .pac files have internal progression rates and we can edit those to replace the .gct codes currently employed to this effect (which would fix a bug on Halberd and Rumble Falls which exists in at least Bbrawl and Brawl+ right now).

I'm not really sure how to analyze this to figure out exactly what went "wrong" though; perhaps someone more knowledgeable could take a look at it?

http://www.filefront.com/15498121/STGMARIOPAST_00.PAC

 

[Almas]

Post a pac of the original, please.

 

[Amazing Ampharos]

I guess it was silly to assume everyone had these files; not everyone is like me and has the whole ISO just kicking around...

http://www.filefront.com/15515705/STGMARIOPAST_00.PAC

Best of luck.

 

[Almas]

The files contain a large amount of very small differences. It's hard to isolate any particular one.

 

[Eldiran]

Very interesting. I wonder if BrawlBox would have the same result if you edited the file in a similar manner.

What (if anything) did you change, by the way?

 

[Dantarion]

BrawlBox is using an old version of BrawlLib that contains a bug that messes with animations.

I guess ill release another version, but to be honest, im discontinuing it because of BrawlBox

Also, to fix the scrolling all you have to do is edit the animation that controls the scrolling.
And to edit halberd...well, I haven't tried.

 

[Amazing Ampharos]

Very interesting. I wonder if BrawlBox would have the same result if you edited the file in a similar manner.

What (if anything) did you change, by the way?

I just was changing the upper death boundary, but what Dantarion is saying about just changing animations is interesting itself. Unfortunately, I have very little experience with this sort of thing; just looking at Mushroomy Kingdom 1-1 in BrawlBox isn't making too much clear to me. I am seeing some stuff...

I'm pretty sure the animation for the stage moving is StgMarioPast00_Ashiba_locator which is 7200 frames long. In this animation, two bones (the promising X_move and the more mysterious haikei_locator) increment their translation X values each frame for most of the animation, growing more negative as time goes on (and they always have the same value on any given frame). Frames 1, 3449, 4649, 5845, and 7041 all have their translation X values highlighted in yellow in the "advanced model editor"; I think that makes them keyframes. I actually think I might have this figured out; I'm going to try cutting the translation X values of all of these in half. Here are the appropriate values per keyframe:

1: 0
3449: -846.6755
4649: -1141.342
5845: -1435.027
7041: -1728.711

I actually just tried that in-game. The result was that it mostly scrolled at half speed (though things like the background moved at normal speed, making it actually a better version than the slowdown method), but at a few places the stage jumps in very undesirable ways. A better approach might be doubling the length of the animation and doubling the spacing of the keyframes. I don't know if the game will barf on a 14400 frame animation, but we'll have to find out, right? This puts the keyframes at 1 (by executive decision not to double), 6898, 9298, 11690, and 14082.

The result was that one undesirable jump still happened, and then where the second one used to happen the looping seemed all but broken. It took an exceedingly long time (several minutes) to loop, which it did via warping.

So, I feel like I'm really close here, but I don't quite have it. I think this sort of thing could be pretty useful if only we could work out these... quirks. Hopefully this chronicle of what I was doing will prove useful to someone inspired to look at stuff further.

 

[Eldiran]

It's possible your warps/speedups are caused by BrawlBox' failure to deal with interpolation -- that's something that should be fixed next update.

 

[Amazing Ampharos]

Well, the warp points I think I understand in a vague sense though not really how to fix them. The first seems to happen at the "loop point" where Mushroomy Kingdom moves the player from the far right side of the stage to the far left (it puts you in the wrong place, out over the void). The second I'm pretty sure is happening at the end of the animation.

 

[Amazing Ampharos]

I tried using the newer version of Brawlbox; it produces new but still bad behavior. It still does the warp out into the void at the exact same spot, but now after a little bit it starts scrolling backward for a bit (!!!) and then scrolls forward very fast back to the start. There is something I'm missing here, and I really just see nothing in this .pac file which seems like it could be relevant. As per the specific animation and its assorted bones...

X_Move is definitely what controls the scrolling of the foreground. Editing it seems to cause the jumping issues.

haikei_locator controls the scrolling of the background. It still animates at full speed if given slower values (most obvious when observing the sand blowing effect); it just scrolls more slowly (for nice looking play, it should be exactly the same as X_Move).

The four Ashiba bones are all subsidiary to X_Move, have strange values for their keyframes (as far as I can tell, they're all around either 0 or 7200), and editing them has little discernible effect on the game. To be clear, the ones without numbers (both A and B) have a keyframe at 1, remain at 0 for nearly the entire animation, and then the rest of their keyframes starting at 7180. The ones with the number 2 (both of them) have all their keyframes in the 1-22 range and then remain at the same value for the entire rest of the duration of the animation. Does anyone have any clue what these are for?

I'm going to do one more test...

The jump appears to happen about 87 seconds in with half scrolling speed which puts it between frame 5220 and 5280 which are NOT among the relevant keyframes I have found.

Really, I'm just stumped. The only other animation on the entire stage seems to do very little other than define where random things like the flagpole are (a few things labeled as joints spin with a fairly brief period, but I'm not sure what they are supposed to be, probably pieces of sand or something silly). There's something else going on here, and it's a shame I can't figure it out since other than these jumping issues this is a much better alternative to the current model of slowdown.

I also just double posted.