Re: An interesting FF7 challenge.

[Nathangamer]

Can you hack a code to make the Tiny Bronco fly (and control like the Highwind and land in water or on land)?

[SephiRon]

hehe, that does sound neat. i bet it wouldn't be impossible, you'd just need to find the z (height) modifier i guess, and change it so moving upwards will change it to a higher value. of course, i'm just completely stabbing in the dark here, eheh.

[LiquidManZero]

What you thought of would work, but not too well. If nothing else, the whole thing would be rather a pain to control, I suspect. I do have some odd ideas about making the plane fly like an airship, though.

[Evolver]

Is it just me, or would it be easier to do something like... Change the sprite for the highwind to that of the tiny bronco, somehow put a joker on to let it "land" in the water, except that when it does so, it's actually changing into the tiny bronco.
Just an idea.

[Lazy Bastard]

Hmm...I could probably do something like that with the work I did on world map sprites...if I had a save when the Tiny Bronco was around still, all I'd have to do is relatively what Darke said - I'd take the Highwind, give it the graphic of the Bronco (making the Bronco's graphic nothing so as to avoid conflict), and use the Land Highwind Anywhere code (I believe it was hacked by HAcKen). It should be possible to walk onto the land as such, as long as you landed on the coast and not in the middle of the ocean...but even then there's the old Walk Anywhere code, based off the abilities of the Gold Chocobo.

But I suppose if you wanted to basically have a two-in-one code, you'd mask the Highwind as the Bronco while you're in the air, but the moment you press a certain button (set to joker), you switch sprites to the invisible Bronco, which changes back to its original graphic immediately after the Highwind does likewise. Then you'd be back to having the controls of the Bronco, and gliding around on water. You'd set another button to switch back to the Highwind, and for it, the process would be the same, but in reverse. Just use http://gshi.watnet.blacklotus.net/Ul...onProject.html

And, incidentally, I may as well post this, in the hopes that someone on staff will pick it up and append it to the page...just some stuff I typed up before I left, about six months ago:

---------------------

Reading something a wrote a while ago, I noticed something I shouldn't have missed the first time. Here:

A - If you remember back to the discovery of the zero point and the massive amount of empty sprites, I've already said that there's no real way for me to test all possible values of the world map sprite control mod, as there are too many glitched slots between unused sprites. Sprites themselves could possibly be used as triggers on the world map, if they were assigned a certain trigger (or trigger value), but never assigned a graphic. You'd simply be running into an invisible sprite, with an event trigger. But are we to assume that there are invisible sprites standing on every town?

B - The memory could work in such a way that if you were using the correct sprite for a particular event, when you reach a certain set of coordinates (probably a small range of coordinates), your own trigger would change (more accurately, the trigger for the sprite you're controlling would change), and since you are in exactly the same spot as yourself (heh), the trigger would instantly be...pulled, heheh.

I don't know why I didn't realize the obvious mistake I was making, when the values of the original "World Map Event Mod" were sitting right there in front of me. If there are values like 2AEF, which automatically sends you to the Midgar Gate (in the town environment, not the world map), the obvious answer is that B, and not A, is correct, or at least the basic idea of it is.

As odd as sprite event mods act sometimes, I think I'll do a little more work with them now. Really, the main goal of my hacking involving this project, at this point, is to find the address that controls the amount of sprites that there are on the world map, artificially keep it at the max, mod the unused sprite slots to the desired sprites (whether someone wants to always have Ultimate, Ruby, Emerald, etc), and, when I get to that point, keep in mind not to use any slots that will ever be reached by other sprites later in the game. I can already take the event mod for any sprite (say, the Condor) and mod it so that every time you run into it, you'll fight Emerald, Ruby, Ultimate, or whatever. I could just choose a sprite, edit the values of a few addresses, and have fun fighting the Weapon of my choice. Hence, all that's left is the graphical part of the code, which would normally be the easiest part of a hacking project, and would have been hacked a long time ago. This situation is a bit different, so it'll take some serious thinking (and not a small amount of tedious RAM editing) to finish, but I think it's a goal that can be reached, if I can scrape together enough time. We'll see.

What if graphics get bound to sprites...that would explain the "Whatever You Control" coordinates. So you're already controlling sprite #blah, and then when you "change sprites" (as I've been thinking of it), you're really changing what graphic is bound to you. The coordinates of certain "sprites" (as I've been thinking of them, once again) are really the coordinates of certain graphics, and since the sprite and graphic are bound, and coordinate values of any kind are static, so they can be changed without a problem, whenever you change one, the other changes accordingly. As far as I can see, if you change the coordinates of a graphic, the sprite goes with it since they're bound, and the same occurs when you change the coordinates of a sprite (ie, the Whatever You Control coordinates). I wonder what would happen if you changed both coordinates to two different values, and set them both at constant write.

If all of that's true, you always control the same sprite, but you can mod what graphic you're bound to, and then what that graphic is in terms of visual identity...in other words, any graphic can theoretically be any other graphic, considering they're switched, or at least one of them isn't being used at all...there can't be two of the same graphic.

------------------------

Thinking back on that, it seems to be that a more simplified way of describing what I was saying in the final paragraph is that we're toying with RAM usage of image files; what image file corresponds to what sprite, what graphic corresponds to what image file, and the other details that aren't quite as important, heh.

Anyway, let me know if you have any trouble thinking of a way to accomplish this. I'll still be around until about the 3rd of January.