øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=278;area=showposts;start=30e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexc2e1.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=278e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexc2e1.html.zxºåg^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ0P.•*OKtext/htmlISO-8859-1gzip8:Ö•*ÿÿÿÿÿÿÿÿTue, 10 Mar 2020 19:25:05 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

31
Hey, Squall - I made a new thread for this project. Let's continue the discussion there, OK?

32
If you want to catch up on the discussion between Squall and myself thus far regarding hacking the Namingway screen, you can find it here.

33
Hello, interested parties!

This is a thread where I'll be documenting the progress of a new "side project." Hopefully this will eventually become the definitive SNES FFIV "everyone gets stored in the Shadow Party" mod.

At this point, it's all conceptual and theoretical, but I'm pretty sure that, with enough time, I can make this mod work exactly according to the plan I'll describe here.

The goal of this project is to make the following changes to the Vanilla FFIIUS ROM:
1) All characters except Cecil can be stored in the shadow party data. As a general rule, characters in the shadow party will not earn experience.

2) Shadow party data, which will occupy the same amount of space in SRAM as it does in Vanilla, will be divided into two distinct parts. Part 1 (0x80 bytes) will store two full character records. Characters stored in part 1 will earn experience. By default, these full records will be used to store Kain (when he is under Golbez's control) and Rydia (between the shipwreck and her return as a teenager). Part 2 (0xB0 bytes) will store a set of essential data for Kain, Rydia, Tellah, Edward, Rosa, Yang, Palom, Porom, Cid, Edge and FySoYa. Characters stored in this section will not gain experience. The tradeoff is that all characters can leave and rejoin the party without losing stat information.

3) The Namingway screen will be removed and replaced with a party switch system, which I am calling the PHS (after the system in FFVII)

4) Character equipment will not be stored in shadow party data, but a hacker using this mod will be able to choose whether all equipment is lost forever or added to the player's inventory (or the fat chocobo's inventory?) when a character is moved to the shadow.


I think this mod will be interesting enough on its own that FFIV fans might want to try it just for fun. The great part about it, though, is that it will be fully compatible with FF4kster, so it will easily lend itself to others' hacking projects.

A few preemptive answers to some possible questions...
Why can't I store Cecil?
Essentially, I had to draw the line somewhere. The reason it's so hard to make a mod that fully stores every character in the shadow party is that the game only has 320 bytes available for the shadow party. I need 128 of those bytes for the records that can gain experience (I wanted 192, actually, but again I had to draw the line), which leaves me with only 192 for the non-experience slots. Even using a little compression trick I thought up, I still need 16 bytes for each character slot, and 16 x 11 (the total number of non-Cecil characters) = 176. I still have 16 bytes leftover then that could be used for Cecil, but that leaves open the possibility to face Zeromus without the ability to use the Crystal, which would leave the player in a game breaking dead end.

So then why include records that can gain experience at all?
In the default game story, I think it's necessary that Kain and Rydia gain experience when they are away. Story-wise, they are off actually doing things (as opposed to, say, Rosa, who spends her time away from the party completely tied up). And also, they are gone long enough that if they didn't level up, their return would be anticlimactic. Kain has, by far, the longest period of time away from the party. You don't want him rejoining at level 13. Rydia needs to come back and immediately provide significant help defeating Golbez and his shadow dragon. In a perfect world, Yang would level up, too, but there isn't enough room, and at least he's only gone for one chapter of the story so he doesn't miss out on very much levelling.

What are these "essential stats" that are getting stored?
A large portion of the character record is completely static and easily retrievable from ROM. What will be stored is everything that is not, specifically: Level, Persistent Negative Statuses, Current HP, Max HP, Current MP, Max MP, Base Str, Base Agi, Base Vit, Base Wis, Base Will, and Exp. I could have opted to save space by not including Persistent Statuses, Current HP and Current MP, but then the PHS system could be used as a free Cabin (for everyone except Cecil) and I feel like that would be a major flaw. The choice not to store equipment also saves seven bytes per record.

But wait - I just counted, and that all adds up to 18 bytes, not 16 - what's up with that?
You're absolutely right. I devised a bit of a compression trick. It's not much, but it saves two bytes per record. The highest possible value for Current and Max HP is 9999, or 0x270F, or #00100111 00001111. The highest possible value for Current and Max MP is 999, or 0x03E7, or #00000011 11100111. So HP never uses the two most significant bits, and MP never uses the six most significant bits. By shifting Max HP left by two bits I can combine it with Max MP into three instead of four bytes, and likewise for Current HP and MP.

So what happens with the stored characters' equipment?
As I said, the hacker will have the option when a character "leaves" to either discard current equipment outright, or to move the equipment into the player's inventory. To me, there are some instances when it makes sense in the story just to discard the equipment - specifically when a character leaves against the party's will (e.g. - Kain gets hypnotized, party gets shipwrecked); and there are times when a departing character might be able to leave equipment with the party (Palom & Porom get stoned, Cid stays in the Dwarf kingdom, any time PHS is used). I'm pretty sure I can work it out that if the player's inventory is full, the "swap or discard" screen will kick in, though I haven't actually tried yet...

So you're hacking the Namingway screen... How's that gonna work?
Well, I don't exactly know just yet. I can tell you that the player will lose the option to change Cecil's name to "Shitty," but the tradeoff should be worth it. As for how I actually come around to hacking the screen... Well you, dear reader, get to see that develop right before your very eyes. You see, I have a concept of how it will all work, but I don't know enough about the SNES PPU to code the visuals yet. Squall is helping me figure that all out on this forum, so you can watch as I learn what I need to learn.

Stay tuned!

34
Ok. There is only one instance of STA $2101 in the entire Namingway loading routine, but if I alter the value written to 2101 it messes up Namingway, the character battle sprites, and the finger cursor. So I guess that means those are all sprites (I was already pretty sure the characters and the finger were)?

To change where X,Y you must convert X,Y in video memory address and then write it in $2116. If you want to change x+1, the address must be increased by 2. Also x+1 mean 8 pixels to the right :D
Ok, so... The routine writes 4600 to $2116, and I can see the Namingway image data gets written to $8C00 (4600 * 2), but it doesn't seem like increasing that 4600 by 2 shifts the image to the right... is it definitely the value written to 2116 that I would need to change?

35
I researched the routine that "draws" Namingway a bit. Using the disassembly in conjunction with that document I was able to see how the routine enters the sprite (or "tile?") Data into VRAM, but I haven't found yet how it then takes that data and arranges it and places it on screen. This is important information for my purposes because:
A) even though Namingway and the portraits are both 32x32 pixels, Namingway seems to be an arrangement of four 16x16 tiles in a 2x2 formation
Code: [Select]
AABB
AABB
CCDD
CCDD
and the portraits are a straight 32x32
Code: [Select]
AAAA
BBBB
CCCC
DDDD
I'm probably using the wrong words, but hopefully those diagrams better explain what I mean.
B) that's not where I want my 32x32 images to appear, so I'll need to find and change the assembly that designates the x,y location of the image(s) in question.

Anyway, having you explain how it all works definitely will be helpful!

36
I think I understand that - on a conceptual basis, anyway. I'm not really sure how I apply that knowledge when writing ASM to actually display an image, but maybe you just haven't gotten to that part yet?

One question: when I'm working with a screen that already exists (in this case, the Namingway screen), which already contains visual elements that I ultimately want to keep (windows, some text, the 4BPP character battle sprites lined up along the top of the screen, the finger), is the current mode then already defined? Or do I need to define a different video mode for every different type (or layer?) Of image on screen? Or maybe I might have to set a different mode in order to display image data that didn't already exist in some form?

Wait - is it plausible that I could hack the code that normally is used to display the 32x32 Namingway image in order to display the character portraits that I want?

Maybe I should stop trying to find a quick fix and just sit back and digest your tutorial?

37
Oh, so you understand this to some extent, Squall?
I definitely don't have a working knowledge of most of the things listed there.
The only document I've ever found about SNES graphics is this one, and I'm pretty sure the author of that assumes some base knowledge that I do not have.

I'm not against reading up in order to learn what I need to know, but if you could direct me to the proper resources, that would be awesome.

 :edit:
Looking again at that document I linked... I think it probably has a lot of useful information, but what it lacks (that I need in order to understand) is concrete examples. I'm sure I could learn how this stuff works if someone demonstrated for me.
 :blits:

38
Sheesh... Spent all morning sifting through graphics code trying to find useful nuggets. I forgot how complicated this crap is...
Maybe I should table the PHS idea for a bit...
 :lame:

39
Hey, BZ!
From the online Final Fantasy 4 Reference Book:

Shadow Party Data

I still have a lot of research to do before I can start actually hacking the Namingway screen - I figured out how to remove the alphabet from the entry box, but that's the easy part. Now I have to research the regular menu screen to figure out how character portraits are drawn. Since I don't really know much about graphics processing, this will be a much longer process and will involve a lot of trial-and-error assembly copying. Once I get that down, though, I'm pretty confident I can get the actual character switching process coded pretty easily, though I'm not sure how much ROM space will be needed for all of it. Anyway, once I have something worth actually showing off, I'll start a dedicated thread for that.

40
The 'namingway screen' is the ffiv character name change system. In order to change Cecil's name to (the much-more appropriate) "Fart," you talk to Namingway, and a new screen opens up in which you select which character to rename, then input the new name.
Since name changing in FF games is a fun but ultimately useless luxury (either partially or completely removed from all games past IX), I've had a dream about replacing it with a system that allows easy party changes. I'm not sure if you were around in this community yet a few years ago when I was working on a "shadow party hack" that would allow the game to save the data of all characters that leave the game (instead of only having five slots for character saving), but it was something I worked on for a long while. I had gotten it to work, but I was never really fully happy with it, which is why it's not implemented in TfW (same reason the dash toggle from User Options isn't used). Part of the reason I wasn't happy with it is that the system it uses to control level growth when characters are not in the party is enormously complicated and doesn't work properly 100% of the time (if a character is supposed to gain 90 levels while not in the party, sometimes they'll only come back having gained 80 levels,but then they level up ten times after their first battle, which feels hacky). But the other "problem" was that even with free access to all of the characters, there was no system for easy swapping in and out. I think Grimoire LD had tried a system in which all of the characters hang out in the Big Whale after the Giant of Bab-il and you added and removed each one by talking to them. But again, after much more streamlined systems in all titles beyond V, this lacks the user-friendliness you want in a good mod.
So... That's what I've been playing around with.

41
Sure, okay...

So the story concept hasn't ever changed. There were details - how to get from Major Plot Point A to B - that I didn't plan ahead of time. I actually think the dialogue ends up better and more natural because of this. When I'm writing a scene, I know the gyst of what's going to happen, but all of the actual lines are written on the fly. The downside to that, though, was that I was maxing out quickly on dialogue space. That's the big problem that was resolved by expanding the ROM, but I didn't need an entire extra MB of ROM for dialogue, so I sat down and figured out which other sections of data could benefit from periodic refreshment. The following sets of data will change over a few times in the game depending on story progress (a flag in RAM will be set that tells the ROM to now reference an entirely separate location in ROM for the data in question):
-Dialogue bank 1 (including pointers)
-Dialogue bank 2 (including pointers)
-Dialogue bank 3 (including pointers)
-Event data
-Trigger data (meaning some chests will contain different treasures depending on when they're opened, like in FFVI)

But I'm also toying with some other ideas...
-now that I've done away with the relative monster scaling, another possibility could be different sets of monster data. So (for example), Imps don't ever get to be super-powerful, but maybe they get a few hundred more HP and an attack that can deal a couple hundred HP damage. I could also have the Exp tables change at the same time.

-I might create a second set of location map data, so that towns might be slightly different when you revisit them. I'm not exactly sure how I would use this, but it creates a lot of possibilities.

-This is a new but very intriguing idea - I have the ability to create separate sets of character starting data and even image data. Originally, Rydia was going to be the only temporary playable character, but by doing this I could include, say, Luca and Cuore as temporary characters as well (both were planned into the story, but only as NPCs)

I haven't actually gotten back to working on story progression yet. Before I get to that I have to rebalance all of the existing monsters in the game thus far, since their stats will be static now. As far as the story's progress, I'm actually pretty close to a place that could be a stopping point for the end of a chapter, so depending on how long it takes me to get through the rebalancing it's possible I'll be able to roll out another release pretty soon.

I don't get to work on the project as frequently as I was a couple of years ago. I got a promotion at work this year, which means my work schedule is more similar to that of normal people's jobs (it's still big box retail, though, so still not anything close to 9-5 M-F). What that means for my life, though, is that I get to hang out with my wife more, but I am alone in the house less, and alone in the house is when I do most of my serious ROM hacking. Rest assured, though, I am still committed to this project.

Since my brain always seems to need a hacking side-gig, though, I've also been researching the workings of the Namingway screen. I think there really is a possibility that I could hack it into a PHS system. I really have no idea what I would do with that, but I feel like it might be a fun patch to release to the world for other people to use in their own hacks, maybe. I donno, maybe I could find a use for it in TfW, too. I do plan on having a fair amount of final party fluidity for the player. We'll see, I guess...

42
My personal advice - pick one that is easy to make (luckily 2 seems simple enough). When all things are done and you still think: "this is a wrong" - implement another option, just don't stop and waste time for it (now) :D
You're right - I'm over-thinking the matter. Just pick a way and if it doesn't seem right down the road, fix it then.
Thanks!

43
The more I play through TfW, the more I get bothered by the ally hiring system.

The original idea was that by the time the player is able to visit all hiring locations freely, there would be incentive to change allies every once in a while - even if just to keep things fresh. The problem with that, though, is that the starting level of these allies would be prohibitive of this practice. Why would I want to hire a lv 15 ninja when I've spent all this time getting my black mage up to lv 60?

So I thought of a relatively easy solution to this issue - make the hired ally start at a level that is appropriate based on the player's progress. With my expanded ROM, I have plenty of space to construct a starting stat table for every hireable character.

The only part of this I'm hung up on is how to determine the starting level of the hired ally. I'd welcome input from anyone reading this...
1) match (or base upon) Furio's level
2) match (or base upon) average party level
3) base entirely upon game/story progress
4) some other way I haven't considered
5) match the level of the hired ally currently in the party, unless there is no current hired ally, in which case fall back on another of option 1-4.

Neither 1, 2 or 3 is perfect. 1) stands to be abused - player could kill off all other characters, grind Furio way up, then hire a super ally. 2) gets dicey specifically when Rydia is in the party, as she joins at level 50. 3) stands to punish the player needlessly for grinding. 5) is probably the best, but it's also the biggest pain to program, and then I'd still have to figure out which method to fall back on if there is no current hired ally.

Any thoughts?

44
All done, TYVM chillyfeez!
952 Attack - very impressive! Personally I don't see why it was consider OP - no AoE, no upgradable skills.
He has a very high base power, can use both Katanas and Large Swords (which generally have the highest attack power, as well as +50% attack power abilities that are pretty easy to acquire), and his most powerful move reduces the opponent's light resistance, which couples well with the easily-obtained Excalibur.
He doesn't have an AoE move, but for the toughest bosses AoE tends to be overrated, and if you need AoE his limit skill is, and he has an innate high tide. He's also a capable stat debuffer, especially if you got his Crush Helm during his debut event.

Quote
P.S. Do you keep your account in Telegram? I tryed to reach you there (so we don't flood this thread) but it says: Deleted Account
I didn't delete it, but I only ever used it to communicate with you, so if they delete unused accounts, that might have happened. I'll look into it at some point soon.

45
OK, done. I'll keep Orlandeau up. He's overall probably more useful than Dark Fina. My Dark Fina is probably stronger relative to the field of Dark Finas out there than My Orlandeau is, but his 943 attack power is still awesome enough in most situations.

Oh, and I'm rank 120, BTW. Better than I thought.