øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=123;area=showposts;start=705e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexa945-3.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=123e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexa945-3.html.zxòg^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈÀK˜JOKtext/htmlISO-8859-1gzip@øÕ˜JÿÿÿÿÿÿÿÿTue, 10 Mar 2020 20:17:57 GMT0ó°° ®0®P®€§²ð®òg^ÿÿÿÿÿÿÿÿ©3˜J Show Posts - Grimoire LD

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 - Grimoire LD

706
Alright, so I am still playtesting my hack when I noticed something strange... Shields were giving Dark Knight Cecil a consistent x1 Defense Multiplier, no matter what shield the game would give him x1 Multiplier. I took a look through the Shield bytes and there was nothing in there specifically about that. Now this is a problem from a balancing standpoint... All of my other characters have 0-2 Defense Multipliers but Dark Knight Cecil has 3, making many hits to him as glancing blows, even though that was not the intention.

I did some quick searches to find why this was, but continued to come up empty... I tried it on a fresh file and saw that Shields at Level 10 don't effect the Defense Multiplier and I jumped to a late level file and saw that it was giving Kain x3 Defense Multipliers and it was independent of which shield was equipped. So I changed Cecil to Level 99 and saw that his Defense Multipliers jumped to x6, despite his stats being 00 and the only thing equipped was a shield.

This makes it clear to me that Level not only increases Base Hit% by 1 every few levels , but for Shield Bearers it increases their overall Defense Multipliers  every 16 levels.
96/6 = 16x6 thereby giving Shield Bearers an unfair curve against all other characters. I think I'll need to find where this is in code and squelch it for this project since Shield Bearers by their nature already have such high HP...

Alright, I've learned at least that looking at the basic stats is useless because the game first writes all of its proper calculations to the battle stats before transferring the changed values to the basic stats so to find this I set a breakpoint of write on the Defense Multipliers in the battle stat section...

In a short time I located what I was looking for.

$03/99C9   A0 28 00   LDY #$0028   A:0000   X:0003   Y:0027   P:envMxdIZC - Load 0028 (used for 2028 location of Battle Defense Multipliers...) into Y.
$03/99CC   AD 65 39   LDA $3965  [$7E:3965]   A:0000   X:0003   Y:0028   P:envMxdIzC - Load Copy of Level into A.
$03/99CF   20 84 84   JSR $8484  [$03:8484]   A:0063   X:0003   Y:0028   P:envMxdIzC - Jump to Dividing subroutine.
$03/8484   4A    LSR A   A:0063   X:0003   Y:0028   P:envMxdIzC
$03/8485   4A    LSR A   A:0031   X:0003   Y:0028   P:envMxdIzC
$03/8486   4A    LSR A   A:0018   X:0003   Y:0028   P:envMxdIzC
$03/8487   4A    LSR A   A:000C   X:0003   Y:0028   P:envMxdIzc
$03/8488   60    RTS   A:0006   X:0003   Y:0028   P:envMxdIzc - Return

This is only called if a Shield is equipped (which places a 01 in the Stat Copy Section which is used to somehow multiply the existing defense multiplier by x1, if no shield is equipped it returns a x0 and nullifies the Level Bonus for Shield Bearers. And there we have it! All I need to change is the LDA 3965 to look at an area that will always read 00. Or if I wanted to make it available to everyone independent of a shield I would change the second value that is looked for into a guaranteed value of 01. For this project I want to eliminate this unfair addition so...

$03/99CC   AD 65 39   LDA $3900  [$7E:3900]   A:0000   X:0003   Y:0028   P:envMxdIzC - Load 00 into A.


There's quite a bit in this section actually! I should take some time out one of these days to research this entire area since it flows so well into one another and there might be some other useful information in here.

707
Hmm, the initial problem with this plan is that the Mist Background uses resources from the Caves Palette set. In another palette it either just won't appear or will appear in a glitched manner.

However if you can find a section of the Mountain Tileset that can be used, you could make a new background that has a similar or identical effect.


708
These are some creative ideas you have! Yes, Critical Hit chance only changes if you have a weapon equipped (x2 with a normal weapon, x4 with a Bow&Arrow) and the Critical Hit Bonus is added from half of the weapon's power + a default amount for each specific character and Steal Evade... is used by Porom and Porom only in the initial Cry command which would increase the chance of stealing an enemy's item, it doesn't ever change, but in most cases it matches the default level of the character.

16 characters would be an ideal amount, it would allow us to use Golbez and Anna's slots to their fullest potential. (Eventually...)

709
I was going to say that this space may have been the space I had previously located for my failed "keeping commands in RAM" hack.  But if it's only accessed inside of battle then it shouldn't cause any issues I'd imagine. But yes, as you said the problem the size of the inventory display window. That part is a little bit difficult to actually deal with, I'd imagine. Likely something says to repeat the screen 64 times before stopping, in theory it would be a matter of finding LDA/X 0040 that is continually decreased to building the screen and changing it to FF.

710
1340 to 143F is ridiculously the amount of space that the Fat Chocobo has...

12A0-133F appear to be default visibilities of NPC's. Now the Fat Chocobo section... FF Bytes... 255 slots... this begs the question of Why FFIV chose to do it in this frankly silly manner instead of having a slot open for each item! This is already more than enough slots for items! I wonder what would happen if you tied all item use and acquisition in battle and outside to the Fat Chocobo Bag. Would you not have to worry about item space the?

711
It does, here is what his Shadow Party hack checks...

         1140   character id/handedness
    1141   class id
    1142   level
      1143-4   max HP
    1145-6   max MP
    1147   strength
    1148   agility
   1149   vitality
    114A   wisdom
    114B   will
   114C   helmet
   114D   armor
   114E   gauntlet
   114F    right-hand item
   1150   right-hand quantity
    1151   left-hand item
   1152   left-hand quantity
   1153-5   experience
His hack also changes matters to a Class based rather than Actor based for Events. I imagine that the Actors are still referenced for their commands, but I couldn't say for sure.

His hack is a good foundation, but it is extremely specific and would be difficult to make work in a basic sense without a heavy overhaul. I'm hoping that Chillyfeez's attempt might be a bit more open, so to speak.

712
That's pretty much all you need for this. Outside of battle the game only stores 40 bytes and the rest are added in-battle.

2D - Critical Hit Chance
2E - Critical Hit Bonus Damage
2F - ?Steal Evade?

3A and 3C are still unknown, but I've never personally seen them referenced. They are quite possibly unused, which could have interesting ideas for mods down the line....

Phoenix's idea was to get rid of extraneous bytes like current HP/MP, modified stats, status, resistances/weaknesses, physical attack, defense, and magical defense (this would all be recalculated when they would rejoin the party anyhow) so there would be room enough. Would his plan work? Difficult to say, there is a problem with experience that was never addressed. (though there is a mention of disabling Exp. gain for the Shadow Slots, which should, in theory solve the problem) The only real issue is the loss of critical hits from thereon out when using it. All you would need is three more bytes of space, if I'm not mistaken. Thereby the amount of space would go from 0B to 0E which should still be enough space for all of the characters.


713
Yep, looks like these new changes work fantastically! Index changing, the new shields, all of it seemed to work flawlessly. If I may make a suggestion then... is it possible to also include a Copy function as well as a Switch function?

Shouldn't be too difficult. It already has the code there for "highlighting" an index, maybe for "paste" it could just be Insert instead of Enter?

That looks like a workable idea.

Yup, there are a couple things from the wishlist that have yet to be solved. The biggest thing off the top of my head would be getting the tile graphics read dynamically from the rom. I was trying to do this last year and met with mixed success. I can get it to read all the regular tilesets correctly; the only ones that are causing issues are the 4bpp ones (airship, ship). I posted my code in the other thread just to see if anyone could see what I was doing wrong. I can try to pseudocode it down to make it more readable if that would help. In any case, that can be discussed in that thread.

Yes... unfortunately graphics are not my strong suit, whether it be GB, SNES, PS or N64 graphic matters have always gone way over my head. I'm afraid I'm no help there.

I would also like to make an "arrangement" editor, for editing the monster arrangements (the screen positions of the monsters in a battle, possibly other information related to that?). The wishlist thread on that topic didn't really go anywhere.

Chillyfeez was 100% correct on his thoughts. It is the "Mystery Byte" that effects the targeting. I just tested this on the Sandhags in the Desert and changed it to 1 and the targeting was rather screwy, but its initial value of 34 is used in several different places and seems to be the code for "straight line targeting", so I guess you can assuredly change that "Mystery Byte" in Formations to Targeting Setup or something like that. In fact, I will go through quickly and mark the kind of targeting each formation uses...

Targeting List (With help from Zyrthofar's Editor)
Code: [Select]
0 - No targeting, only used by single foes.
1 - Diamond  (4 Foes)
2 - Left-Right  (2 Foes)
3 - Upside Down Triangle (3 Foes)
4 -
5 - Adjoining Squares (4-6 Foes)
6 - One Small Square to an Adjoining Sideways Triangle (4-6 Foes)
7 -
8 - Oblong Square (4 Foes)
9 -
10 -
11 - Square with Jutting Triangle at Left (3-5 Foes)
12 -
13 - Double Squares Down (3-6 Foes)
14 - Left Jutting Triangle (3-4 Foes)
15 - Three Sideways Squares (2-8 Foes)
16 -
17 - Full Diamond (4 Foes)
28 - Obtuse Triangle (open) (3 Foes)
34 - Straight Line (4 Foes)
79 - Slightly-off Square.

...Actually a lot of this depends on Arrangement as well. But yes... at looking at Zyrthofar's editor he has it clearly listed where which values correspond to where, but without a visual aid as he has... I imagine it would be difficult to change that on the fly.

They start in ROM at 0x73CC0 starting from Targeting Setup 00. They are all in eight bit basis, meaning that they use only half-bytes for their values.

And the Arrangement's start at...

ROM 0x71200 and it is the same case as above, except they only use 8 Bytes rather than 16 as Positioning seems to take up less space than Targeting.

There are still several game objects that have "mystery" bits or bytes that we have yet to discover the function of. It's entirely possible that some of them are redundant and actually ignored by the game (the "two-handed" flag comes to mind) but it's also possible that they do have a funciton which we just don't know what it is yet. While working on a test hack (I found this is a good way to test the actual usability/friendliness of the editor for an actual hack) I discovered completely by accident that the spells have a mystery bit (the top bit of the "effect" byte) that was causing a damage spell that had it to deal much less damage than it should. I'm planning on going through all the game objects at some point and making all the "mystery" information editable, if for no other reason than to assist with experimentation.

Yes... that was an issue that I was going to have to tackle eventually. Several of Kain's Dragon Spells had this problem, even at Power 255, I thought it was something to do with some unseen index I was going to have to scrounge for, but yes. That Mystery Flag does Exactly what you say it does. It mitigates the damage in a horrendously low fashion when activated. Phew, that actually gets rid of that worry.

While not technically part of the editor proper, getting the "complete shadow party" patch working would be such a useful tool for anyone hacking this game, particularly if they're planning on changing the plot in any significant way. That way you wouldn't have to design your plot around the limitation of who can be in the shadow party in what slots at what times.

A new Shadow Party Patch would need written from scratch unfortunately. What Phoenix did was he shoved all of the data into the normal Shadow Slot area, but he got rid of "useless bytes", unbeknownst to him these bytes were the Critical Hit Chance, Critical Hit Bonus, and "Steal Evade", he also askewed the Exp. Tables with this somehow. The key would be to finding another area in RAM that is saved to with loads of free space that could compensate the space for all 14 characters, that is the tricky part, I'd say.

And finally, on a less technical note, I've been delaying adding the overworld to the map editor, at least in part due to my understanding that it uses at least one multi-tile code (i.e. one of the bytes corresponds to several tiles in a row, f.ex. the snowy mountain tops I think it was). On a technical level this is pretty trivial to implement, but on a user-interface level I've been having problems imagining how to handle the cursor for such a situation.

That's all I can think of off the top of my head but I'll certainly let you know as I think of things  :happy:

Hmm... that does sound tricky to use, I'm sure someone can help you with that part though. Maybe just have the Mountains outline with some color to indicate that anywhere you choose on these four tiles you will be pasting a four-tile mountain top?

714
Yep, looks like these new changes work fantastically! Index changing, the new shields, all of it seemed to work flawlessly. If I may make a suggestion then... is it possible to also include a Copy function as well as a Switch function?

Also, is there any more information you'd like added to the editor that I haven't really explained or explored yet?

What were the minor fixes and cleanups in this update out of curioisyt?

715
Well, there we go. It looks like that should work ideally then.

Alright, I guess that silences my concerns about the equipment ranges, at least as far as I'm aware.

That part of it might be near completion.

716
Hmm, none of those seem to be the "break bit" as far as I can tell. The Break Bit is the 40 Bit in the Equip Index. As a point of curiosity...

20 - Two Handed Weapons
40 - Arrow
80 - Bow


It would likely be much easier for you to add the bit into the normal Weapon menu rather than to set it with the Range because that means you would have to write a 40+ Initial Equip Value to Every single new Arrow that people would choose to make, which could be a bit of headache inducing code.

We know the 40 does something, I'm not sure at all if it is the case with Bows or Two-Handed Equipment though.

717
Ah right, that reminds me, when you go to change the range of Arrows (or plan on one use weapons) have you also included the Break Bits with it as well? Since that is just part of the Equip Index byte after all. Just checking to see if you've set it up that way.

718
Alright! I think I've finally solved this conundrum and it dealt nothing with ranges or anything like that, but instead it writes to an exception, this is normally used while dual-wielding. Shields... somewhere... have an innate 80 which is looked at, and it is this which decides whether the game increases defense or offensive capabilities. Weapons and other types or armor do not have this 80.

Yes, here is a prime example of what I mean...

Iron Shield -
8001 1400 8000 0400

80 - Magic Evade/Metallic
01 - Defense
14 - Evasion
00 - Magic Defense
80 - Will This Item Grant Defense if Held - Negative Hex If So/Along with other elemental/race matters. 80 is the Very Important Part though and is the key to using other Items as Shields.
00 - Status/Element resistance
04 - Equip Index
00 - Bonus Index

You will notice that the helms and all other armors (and items in the game...) lack this negative portion of the byte. That's likely something you'd want to add to the editor, hehe.

Now that I think about it though, that's a pretty neat way to go about it. This way the player can have "weapons" that don't necessarily add to attack and "shields" that don't necessarily have to add to defense.

719
They are indeed, just as above (I thought I noted that, apparently I did not, eh heh). If you're using a headered ROM just add (or subtract?) 200 to the final amount to find them.

720
Hmm... yeah it worked for me, just fine. It is C9 6D 0B 04, right?

Oh wait... hmm, this is strange. If you came into the battle with the Helmet/Shield equipped the game would read it as re-equippable. But if the Helmet/Shield is in your inventory it shows up as darkened and unequippable. What does this even do then? Hmm...

Ah! I found it! It took a bit more data-diving than I had thought, but I found, at least, the way to equip Helmet/Shields in battle... there's more index checks at...

03A165 - C96D - This controls whether the index will show up as lightened as well as equippable (granted you can actually equip them, of course)

03F36B - C96D - This allows you to actually equip the helmet if the above is fulfilled (and not just if you have de-quipped and requipped it in battle)

That solves that mystery! Now onto the other...