Topic: Damage + Sap = Can't absorb??

[Pinkpuff]

So I had made Bio a dark-element spell in my hack, and when I created the Shadow Fiend, who of course should in theory absorb dark-element damage, he instead took full damage from it. At first I thought perhaps there was something special about Bio in particular so I swapped indexes with another spell and it didn't affect the behaviour. I then swapped it back and instead tried making it into a normal damage spell. The behaviour was as it should be; it healed him. Then I tried making the monster immune to dark instead of absorbing it and put the routine back to "damage + sap" and sure enough it dealt only 1 damage, as it should. So is there something special about the "damage + sap" spell routine that causes it to not be absorbed by things that should absorb it?

[avalanche]

Any chance he's Undead?

I'll go with that working theory for the moment.  The normal damage routine when handling absorbed elements jumps a few instructions past the beginning of the healing routine, the part that converts healing-an-Undead back into the normal damage routine.  The Damage+Sap routine doesn't jump past that Undead check, so it might go from damage+sap -> healing -> damage.  If my guess is correct, and you didn't want to make the enemy not undead, then perhaps you could change Damage+Sap to jump to the same place that the normal damage routine does.  I can be more specific if you confirm my hypothesis.

[Pinkpuff]

He is indeed undead.

[avalanche]

Well, I think the fix is going to require an assembly modification (just 1 byte changed).  Honestly, it seems like it would make sense to make this tweak anyway.  The Damage-only routine takes an absorbed element, and causes it to heal the target, regardless of whether they are undead.  But the Damage+Sap routine takes an absorbed element and causes it to damage the target when they are undead which seems like a bug to me; something that perhaps never normally occurs with the original spells, so they didn't fix it.  I would just change the absorb check instructions of Damage+Sap to match Damage's behavior as follows:

From:

Code: [Select]

03:D3CF   4C 1C D4    JMP $D41C

To:

Code: [Select]

03:D3CF   4C 26 D4    JMP $D426

That will make Damage+Sap's absorb mode skip over the undead check, too.

[Pinkpuff]

Worked like a charm!

I think what I might do is expand my "protect/shell patch" to instead be a "spell routine patch" that fixes various spell routines and/or makes them more customizable for hackers.

[avalanche]

Great!

I've been pondering about how there are several damage-based routines, and several status-inflicting routines.  As far as I can tell, the status inflicting ones are only separate because they deal with different status timers.  They also seem pretty specific in that if they were given an extra status bit that they weren't expecting, they would be buggy.  I wonder if it would be possible to merge them down to one or two, that are able to handle all the statuses and timers specified in the spell record, to make room for entirely new routines.

[Grimoire LD]

Worked like a charm!

I think what I might do is expand my "protect/shell patch" to instead be a "spell routine patch" that fixes various spell routines and/or makes them more customizable for hackers.

I rather like the sound of this. Now if only we could fix whatever is wrong with the Gradual Petrify routine... it's strange, but Spells that Gradually Petrify actually work when the player uses them on an enemy, it's only when Gradual Petrify is inflicted from a normal attack that problems start to appear.

Maybe I should write out some improvements I feel should be made for the routines and start tackling them one by one... let's see here...

Status Ailment Routines
If possibly I would love to somehow add the tags of "Guard!" when an enemy resists an ailment, rather than "Miss" I always hated that about older FF games, how am I to actually know what an enemy is vulnerable to if you tell me Miss most of the time? A simple solution would be a JSR to roughly 10 bytes somewhere which would put a "Guarded against Ailment!" message. Another, cleaner way to go about it may be to somehow change the color of "Miss!" to Green, to signify a Guarded Ailment.

Magic Damage Routines
There may also be a way to throw in Elemental Boosting as well. In vanilla FFIV unfortunately the main three elements mainly become rather useless when you have access to things like Leviathan, Flare, and Bahamut.  This would give them continued use (not too powerful I'd imagine though)

Damage, Sap
Ugh... what a poorly programmed waste of space. Was one of the first routines to get the axe in Combat Boost, however there are some intriguing things that could be done with it, and I've already recorded the ways to increase Sap's timer so there is always that I suppose.

HP Healing

I've done everything I wanted with this by getting rid of the useless Cure 4 Check and throwing in an Item Lore like functionality.

As Avalanche has pointed out it would be nice to have all of the Status Routines in a single routine... but I'm not sure logically how to do that. We also need to figure out why Poison resistance doesn't actually work for monsters.

Reflect Needs to be accounted for in Counters. We need to find someway to make that happen. My thought is because it doesn't directly target a foe that their counters don't go off because of it.

Life... oy... well I think I've already given PinkPuff the tools to make that a decent idea for a routine. Vitality x5 was such a silly idea in the first place.

I have been mulling over in my head a way to make Protect and Shell into two new statuses that give +25% Defense and Magic Defense when applied (I like the idea of incremental increase as well, which is what I emphasized for Combat Boost, but that's only because they're free songs) The only issue is of course the changing of gear which resets that, but I don't think that's too big of a deal if people know that will reset their defenses.

Sylph...  what to do with this? We'd need to basically rewrite it. Maybe make it more universal and not just "Adult Rydia" and have it cost MP.

Count - Another terribly convoluted status. I'd really like it for players to be have it in the same vein as Gradual Petrify but there's some sort of timer problem we can't explain yet.

Attack Based on Physical Power - Ideally I would change the default Magic Routine to do a special look for Physical skills that take Strength, Agility, and Vitality into account so there can be a greater use of skills that involve more than powering up Wisdom and Will.

Those are all the ideas I can think of for the moment.

[avalanche]

Such an extensive rewrite of the code would be so much easier with a full assembly language.  Has anybody done coding for hacks using a bona fide assembler? 

[Grimoire LD]

Such an extensive rewrite of the code would be so much easier with a full assembly language.  Has anybody done coding for hacks using a bona fide assembler?

I've mapped out all of the spell routines, command routines, and damage routines to my knowledge, but I've done everything by hand because advanced math really throws me off.

[chillyfeez]

I'm not really sure what you mean by a "bona fide" assembler. I used to use a program called "SNES Professional ASM Development Kit," but I eventually got to the point where doing all of the Assembly by hand was quicker. The program does a good job of turning your commands into code, but it doesn't keep track of processor status, so it pretty much always assumes your Accumulator is 8 bits and your x and y registers are 16, which makes it mess things up pretty regularly.
Anyway, I've done so much assembly by hand now that I'm pretty fast with it (I generally keep this open in the background so I can switch to it if I forget an opcode).
If you know of a program that would work better than the one I've tried, I'd be thrilled to give it a whirl.

[avalanche]

I'm not familiar with that one (or any, for that matter) but I was referring to an assembler that would compile the assembly to the binary that could be patched.  There would be some advantages for *some* use cases. For example, branch and jump targets could be labels/names instead of hardcoded addresses, so if you remove a line or two, all the branches and jumps in the whole area don't have to be adjusted by hand.

I will say that for most of what we do here, it would likely be the opposite of helpful.  But when picturing recoding all of the spells and consolidating the new free space, it could be nice. Hard to say.

[LordGarmonde]

I'm not really sure what you mean by a "bona fide" assembler. I used to use a program called "SNES Professional ASM Development Kit," but I eventually got to the point where doing all of the Assembly by hand was quicker. The program does a good job of turning your commands into code, but it doesn't keep track of processor status, so it pretty much always assumes your Accumulator is 8 bits and your x and y registers are 16, which makes it mess things up pretty regularly.

I've been using the Development Kit to get a grasp on ASM in general, but specifically how the math works. It took me a bit to figure that out about 8-Bit (A) & 16-Bit (X,Y) being the preferred setting. I still don't quite get the 'why' of that, but the Kit still works well enough for my experiments.

I've mapped out all of the spell routines, command routines, and damage routines to my knowledge, but I've done everything by hand because advanced math really throws me off.

I know what you mean. Things are confusing enough even when you're playing the game and you can see the results of the code. I have the problem of knowing exactly what I want to do (on paper) and then bashing my head on the desk for hours trying to code it properly.

- One thing I can say without a doubt: the Mode-7 math registers are phenomenal - wicked fast!     It doesn't bat an eye at stuff like (#100) x (#65000) ...  $A02E63 just pops right up. 

[Deathlike2]

Well, I think the fix is going to require an assembly modification (just 1 byte changed).  Honestly, it seems like it would make sense to make this tweak anyway.  The Damage-only routine takes an absorbed element, and causes it to heal the target, regardless of whether they are undead.  But the Damage+Sap routine takes an absorbed element and causes it to damage the target when they are undead which seems like a bug to me; something that perhaps never normally occurs with the original spells, so they didn't fix it.  I would just change the absorb check instructions of Damage+Sap to match Damage's behavior as follows:

From:

Code: [Select]

03:D3CF   4C 1C D4    JMP $D41C

To:

Code: [Select]

03:D3CF   4C 26 D4    JMP $D426

That will make Damage+Sap's absorb mode skip over the undead check, too.

The Damage+Sap routine applies the Sap status when a target is actually weak vs the elemental in question.

While you see this in Bio/Virus (which has no elemental attribute), it is also actually applied on Holy. While Holy itself deals a lot of damage, you'll find that you'll deal weak/negligible damage to the undead dragons in the Lunar Subterrane (assuming you're not playing FF2US or FF4 Easytype). It's easy enough to calculate the sap damage (sap damage is default 60 points/ticks, affected by speed modifications from haste/slow).