øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=278;area=showposts;start=210e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexef56-3.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=278e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexef56-3.html.zx¿åg^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ0P.Ç*OKtext/htmlISO-8859-1gzip8:ÖÇ*ÿÿÿÿÿÿÿÿTue, 10 Mar 2020 19:25:09 GMT0ó°° ®0®P®€§²ð®¾åg^ÿÿÿÿÿÿÿÿý5Ç* Show Posts - chillyfeez

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - chillyfeez

211
I just finished putting a new little function into TfW that I thought others might be interested in for their own projects at some point.
This is kind of a "User Options" sort of mod.
This allows you to scroll through all of the available (individual) targets in battle by pressing Y.
I developed this because I am working on a boss battle that involves seven different "Special" size monsters, which are scattered all over the screen. Since there isn't a natural formation that accommodates this particular arrangement of monsters, it's kind of hard sometimes to target a specific monster on the field. So I devised this mod so that the player can simply hit Y to scroll through available targets. Each Y press moves the target selection up by 1, instead of relying on using the D-Pad to move the cursor to where the game thinks the next monster should be. I was thinking this might come in handy for any battle that has a large number of monsters, but especially for a situation like mine.

If you want to use this assembly, by the way, bear in mind that for my purposes I used some free space realized by creating a new (shorter than what it was replacing) song. So inserting the bulk of this assembly where I did will likely cause problems, but you shouldn't have too hard a time finding a place to absorb the 53 bytes in question.

Code: [Select]
$02/B086 20 FC FF    JSR $FFFC  [$02:FFFC]   ;Normally this says "JSR $AE27" which is the routine that looks for D-Pad input

$02/FFFC 5C BD 80 08 JMP $0880BD[$08:80BD]   ;Jump to custom assembly. NOTE: BY DEFAULT THERE IS MUSIC DATA AT 880BD. I have a custom song there, so this is empty space for me, but you shouldn't have too hard a time finding 53 free bytes somewhere, and as this is a long jump, it can be anywhere at all.

$08/80BD A5 38       LDA $38    [$00:0038]   ;Load "Controller Input 2" (up/down/left/right/select/start/Y/B)
$08/80BF 85 1C       STA $1C    [$00:001C]   ;Store into 1C (probably not needed as a matter of fact)
$08/80C1 C9 40       CMP #$40                ;Compare with 40 (Y pressed without any other buttons)
$08/80C3 F0 04       BEQ $04    [$80C9]      ;If Y is being pressed (by itself) then skip the next op
$08/80C5 5C 27 AE 02 JMP $02AE27[$02:AE27]   ;Jump to regular D-Pad input routine
$08/80C9 AD 8D EF    LDA $EF8D  [$7E:EF8D]   ;Load currently highlighted target (which can be 00-07 for monsters, 08-0C for characters, FF for all monsters or 0D for all characters)
$08/80CC 1A          INC A                   ;Increase value by 1
$08/80CD C9 0D       CMP #$0D                ;Is the adjusted value 0D?
$08/80CF 90 01       BCC $01    [$80D2]      ;If less than 0D, skip the next op
$08/80D1 7B          TDC                     ;Transfer direct page (essentially, load 00 into A)
$08/80D2 8D 8D EF    STA $EF8D  [$7E:EF8D]   ;store new value into Current Target
$08/80D5 C9 08       CMP #$08                ;Is the value 08 or higher?
$08/80D7 90 0F       BCC $0F    [$80E8]      ;If not, skip to 80E8
$08/80D9 38          SEC                     
$08/80DA E9 08       SBC #$08                ;Subtract 8
$08/80DC AA          TAX                     ;Transfer A to X
$08/80DD BD C5 29    LDA $29C5,x[$7E:29C5]   
$08/80E0 C9 FF       CMP #$FF                ;Is there a targetable character in that slot?
$08/80E2 F0 E5       BEQ $E5    [$80C9]      ;If not, jump back up to the beginning of the routine to try again
$08/80E4 5C F1 AE 02 JMP $02AEF1[$02:AEF1]   ;Jump to the end of the D-Pad input routine (RTS)
$08/80E8 AA          TAX                     ;Transfer A to X
$08/80E9 BD 23 F1    LDA $F123,x[$7E:F123]   
$08/80EC C9 FF       CMP #$FF                ;Is there a targetable monster in that slot?
$08/80EE F0 D9       BEQ $D9    [$80C9]      ;If not, jump back up to the beginning of the routine to try again
$08/80F0 80 F2       BRA $F2    [$80E4]      ;Jump to the end of the D-Pad input routine (RTS)

And then there's this, which makes pressing the Y button make a sound (cuz it seemed weird for it to do something but not make noise)

Code: [Select]
$02/B90C 29 4F       AND #$4F                ;Normally, this says "AND #$0F" thus only making a sound for a D-Pad button, this change makes it so Y returns true as well
Enjoy!

212
"Yup" and "should be fine" are the answers to most of your questions.
Yousei's editor comes packaged with his "ffiv.txt" document, which is the most complete ROM map to date for the game. World map data is in the same place in versions 1.0 and 1.1, so after making your edits, you can just copy the data directly from one to the other. ("World map formation pointers" and "world map formation data" or something along those lines is how he refers to the data in question in his document - and bear in mind that Yousei's offsets assume a header, so subtract 200(h) if you are headerless). I've only made edits that, in effect, shrink or maintain the amount of space used, so I can assure you FF4kster will be OK with either of those possibilities. Don't know what will happen if you increase space. It depends on what follows world map formation data in ROM. It's worth noting here, though, that Yousei's utility will resize (expand) your ROM automatically if you expand the formation data beyond its natural limit. The process will, in effect, relocate ALL of the world map formation data to a new bank in ROM. this will a) make it harder to copy into your own project and b) make it incompatible with FF4kster, assuming you keep the expansion. So I'd recommend not using more than the originally allocated space.
Oh, yeah, and the format is one byte for a single tile (say, "19" IIRC for one tile of ocean on its own) and two bytes for more than one of the same tile ("99 03" for four tiles of ocean, where adding 80 indicates the multiple and "two" is signified by 01, etc). The only difference in format between world map data and location map data is that in locations, a row is terminated with an "FF," but it is not in the world map (the next row simply begins where the previous row ended, and the row pointers take care of indicating the terminus). But that last bit is porobably more than you need to know if you're using yousei's editor.

213
I just keep saying "boring" now because it is a pretty convenient way to sum up a lot of different processes. And it's pretty applicable to FFIV because pinkpuff has graced us with one of the most comprehensive and stable game-specific ROM editors available, so a lot of that stuff can be done with very limited background knowledge, so the "exciting" stuff now is when we really get to mess with how the game works.

And you're welcome. Like I said, I was in a pretty similar position just about four years ago. I couldn't have developed the skill as I have in that time without some great guidance and encouragement from more experienced ROM hackers,  so I feel it's only right to pay it forward.

214
Hmm, kind of a tough call. I was lucky enough that as I was really starting to get into the nitty-gritty of assembly, Grimoire was just at about the same level and also learning, so we had this really cool piggybacking thing going on, which was further fueled by the fact that pinkpuff was developing ff4kster at the same time, so there was this sudden collective excitement about FFIV. That's all sort of blown over by now.
I guess I would say the best thing to do is pick one thing you want to try. It might or might not be something that ends up in your final project, but don't worry so much if it's not. It should be something that specifically messes with game mechanics in some way (so, not a graphical change or a text edit or, you know, "boring stuff") - maybe a single new battle command or something.
If you have previous experience with NES assembly, then you probably have the basic knowledge you'd need to do something like that. The big thing to keep in mind is, a running SNES game is made up of three primary components - ROM data, assembly and RAM. He goal is to use the first two in order to affect the right outcome in RAM to make the game behave the way you want. But in order to do that, you need to know what part of RAM to affect in order to get the desired result. For the most part, you can find that here: http://rb.thundaga.com, But I'm also happy to help you find what you need to know. Looking at Grimoire's command disassembly will help you get an idea of how the game does those kinds of things naturally. From there, come up with a plan for something you'd like to try. If you're just making one custom command that executes in a normal fashion (by being selected by the player in-battle), that's probably a good first step to work towards. Doing that for the first time will probably still take a while, but once you've got one success under your belt, things will eventually start coming more easily.
Does that help?

215
and as far as your own work with the "black belt", how exactly did you try to implement it, and how was it unsuccessful?  was it based on an equipped item like FF6?

The idea was that it'be item-based, but that's kind of irrelevant. It's equally easy to have something trigger because of a character's identity, level, certain piece of equipment, individual stat, etc. Those things all show up together in the same bank of RAM data during battle. The problem is getting the reaction to trigger at all. FFIV has a reaction system in battle, but unlike that of most other FF games, it doesn't include player characters, only enemies, and because of the game's super-weird enemy AI system, it's not easy to shove player characters into it. And we haven't really parsed the way the game actually executes enemy AI enough that writing a workaround was a feasable option, at least not at the time that I was trying all this.
Quote
i was imagining putting checks into the battle code such that for example if CHAR X's HP drops below a certain threshold, Regen or Protect is cast on the party.  that by itself seems OK, but then i think getting a spell to autocast without a menu input/using a turn might require a monumental retooling of the battle system...  that would be amazing if possible, you could have all kinds of gameplay like more dynamic/variable monster AI.

As a matter of fact, that's very possible. The game already has an auto-command: Hide. And it's always easier to harness an already a existing feature and alter it as needed than it is to create something brand-new. My Limit Break system is actually a fork off of the original auto-hide implementation.
Quote
on the battle code, does each character have their own "sequence" or "script", or is it just generic?  by that i mean does i know that it' Cecil's turn vs Rosa's turn?  i'm still looking around, there's just tons of info to go thru
... Eh, kinda... I think. We've never fully explored how the game determines whose turn it is, but I'm nearly positive that it cycles through a preset increment of x-values, and when it hits one that has a "ready" ATB status, then it calls the relevant character/monster data to determine how to proceed from there. Once it calls the character data, then it goes through a series of checks to determine if there's anything special about the character that would affect how to proceed (I.e. the character has mute status, so gray-out any magic commands). In theory, it wouldn't be difficult to hijack one of those checks in order to initiate some character-specific passive ability.

216
In my experience, working reactions into ffiv's existing battle system has proven much more difficult than I expected. Never really put a whole lot of effort into it, but I tried to make a simple "black belt" kind of fight counter and was unsuccessful. The points system you're envisioning (if I understand it right) is actually quite a bit easier. There's a decent amount of unused SRAM (the variable data that actually gets saved into a save file) that could easily be employed to keep track of a points system, once the plan for such a system was formulated of course. And as for abilities that are tied specifically to particular levels of particular characters, well, you wouldn't really need SRAM for something like that at all. You could work characters' level checks into the battle code, so that the applicable bonuses (or whatever) run as long as the level check returns true.
Sorry, that probably sounds like gobbledygook. My point is, the basic plan for learning abilities will likely be the easiest part of all this. Second-easiest would be coding the abilities/bonuses/whatever (possible exception being reaction abilities). Working the Heroic abilities in will be a bit tougher, because anything that requires new user interface is a bit more advanced work. Player management of all of it would likely be the hardest part, as it combines implementing new user interface and, presumably, new stuff in new windows.

217
You have some great ideas for abilities here, and I don't see (though admittedly I only read up through Rydia) anything that would be impossible - most of these ideas seem well within the capabilities Grimoire LD and myself have developed over the past few years - but what you're suggesting is definitely a task for somebeody with advanced knowledge of SNES assembly. I would say either 1) shouldn't be attempted by a beginner, or 2) a beginner should expect a project like this to take at least a couple of years to finish.
For my part, I can't really offer much help with the doing because I need to focus on my own project, which combines a ton of the "boring" stuff (it's a sequel to the original, so new character identities, new story) with a fair amount of the fun stuff (limit breaks, blue magic, a mimic character, chocobo time trials). For a splash of perspective, I was a complete beginner when I conceived of the idea in late 2012, and to date I have a demo with about 4.5 hrs of playing time (working toward an eventual goal of a full-length game).
I'm not trying to discourage you, by the way, if you're serious about getting this dine, I'd be excited to see your progress, and I'd be happy to lend advice along the way. Given the amount of work something like this would require, though, I can't imagine you'll find somebody who says, "yeah this is a great idea - I'll start working today." I think you're gonna have to be the one to actually do the doing.
A couple of pieces of advice to begin with: start living and breathing FFIV now. Lift up the hood and start seeing how everything works. A lot of that has been done by Grimoire LD here. Study his disassembles, while keeping this open in a separate tab for reference to what all the assembly commands mean. Doing that will help both knowing how the game does stuff and how FFIV does stuff. Both will be important to learn. Grimoire's thread there and mine here both contain a fair amount of examples of custom stuff that have been added into the game along with specific explanations of how they work. Those should also be useful to you.
Download Geiger's SNES 9X Debugger and a good, feature-rich hex editor. Those tools will be entirely necessary eventually if not right away.
Also, consider an option other than adding a new window at the end of battle. Unless you have a very advanced knowledge of how SNES graphics work, putting windows in where they weren't before can be really difficult.

218
Final Fantasy IV Research & Development / Re: Mystery Flags?
« on: March 18, 2016, 11:11:58 AM »
That's right, I forgot about that one! I don't know if we've ever discussed that before but I've noticed it, too.

219
Final Fantasy IV Research & Development / Re: Mystery Flags?
« on: March 17, 2016, 05:13:45 PM »
I've wondered about that, too. Theoretically, you shouldn't be able to play the game before that flag is set, so there should be no reason for it...

220
So I'm trying to play through, and I realize that the fight with Indra (and not Shiva) is basically impossible. Or I'm just not very good at this game. Gonna have to look into the AI for that one...
Aside from that, things are looking good so far.
 :edit:
Impossible without a thunder ring, that is. Still, that's a problem.

221
Final Fantasy IV Research & Development / Re: Mystery Flags?
« on: March 11, 2016, 08:49:11 PM »
Cool. Having all of that in one place would be handy.
I can definitely help you change the linchpin flags once they're all identified, if you want.

222
I like that castle wall. The texture seems much more real than the original. Is that from something, or did you make it?

223
I've seen that before but never played with it. Good to know!

224
Little discovery here.
I was trying to fix the little (sort of) oddity in TfW whereby the entire stock of Job Cards would be wiped out when using one.
Well, this was happening because I was using the "remove item from inventory" instruction, which removes all of one inventory instance of an item (so if you have 2 x 99 of item XX, you will lose 99 of them). The thing is, I was using that because I thought I had to, because otherwise the item wouldn't go away at all.
But here's the catch - in TfW, the Job Card replaces the Troia Pass. Turns out, there's a special case exception in the "Open Item Window Searching for XX" event instruction routine that skips over the part of the routine that reduces the inventory by one. You therefore get to keep your Troia pass for repeated use. It's also entirely possible to change which item has the special case exception, so maybe you want to keep the Legend sword instead, or (yay, cheating!) keep your Pink Tail. All you have to change is one byte.
In ROM without header:
00/6B3E    C9 EC   CMP #$EC; compare A to EC (Pass)
Just change that EC to the item # of whichever Item you want to keep upon use.

But wait - there's more!
Turns out we never really needed that single special case instruction for item EC at all, because a few opcodes later, we have this:
00/6B46   C9 ED  CMP #$ED; Compare A to ED (the next item after the Pass, whatever it is)
00/6B48   B0 18  BCS $18; If it is that or higher, skip the -1 portion if the routine

So all we have to do is change that ED to EC, and then that part of the routine includes the Pass, and we can comfortably change the routine to make an exception for a different item without losing the Pass.
Or, in my case, I can wedge in a subroutine jump where that Pass exception was!
 :shadow:

225
Final Fantasy IV Research & Development / Re: Mystery Flags?
« on: March 07, 2016, 09:01:29 PM »
I think the "mystery flags" in ff4kster to which you're referring might not be event flags. They might just be other bytes or bits of RAM that toggle on or off depending on the situation.

Regardless, I can think of a potential issue cropping up with this plan: there are some non-event related things (which, as yet, can't be edited with ff4kster) that depend on event flags: the Overworld Terraforming (Agart crater, mist mountains, broken damcyan), the ability of the Enterprise to take off, the ability of the Enterprise to go to Zot, "mystic silver," Magnetic Magnes Cave (you can change whether or not it's magnetic, but not which flag controls the property), the Enterprise crane, the Falcon drill... There may be more, but that's all I can remember at the moment. All of those things are affected by event flags, and FF4kster does not allow you to edit which of those flags affect them. I also don't believe FF4kster documents which flags affect them by default. The information for many of them is on these boards, but not all in one place, and not necessarily all of them.
That's the most info I can give you right now about it,
What you are trying to do isn't necessarily impossible, it might just be more work than you thought initially.