News: 11 March 2016 - Forum Rules

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 - HatZen08

Pages: [1]
ROM Hacking Discussion / Re: FF5 idea for upcoming Four Job Fiesta
« on: June 23, 2015, 08:49:45 am »
For the SNES version of Final Fantasy 5, you can change the innate abilities associated with the jobs. The structure begins at D1/57B8. For every job, two bytes are used. Every bit corresponds to an innate ability. You can locate the bit which corresponds to “dash” ability and apply it to all jobs. For reference, the bit of the dash ability is 0x0800. The other bits are:

Code: [Select]
80 Counter   Cover
40 Evade     Brawl
20 Barrier   Dbl Grip
10 Learning  Medicine
08 Dash      Berserk
04 DmgFloor  Caution
02 Pitfalls  Preemtiv
01 Passages  2-Handed

See Data Crystal (rom/jobs) for better reference.

Because of a bug or bad code, the dash effect isn't applied when you start the game with the freelancer job. You need to access the equip menu to update the job (freelancer) innate abilities.

News Submissions / Re: ROM Hacks: New Hacks Added to the Database
« on: November 15, 2014, 05:53:58 pm »
It probably is the header/no header issue. You need the Japanese version of Final Fantasy 5 with a header. Then, apply the RPGe translation. Finally, apply the Final Fantasy 5 Strategic Battle afterwards. The patch won't work correctly with a rom without a header.

If you are unfamiliar with header/no header issues, you can find the appropriate tools in the Utilities section of the site.

Programming / Re: Dual patcher: Bug Tracker
« on: April 30, 2014, 06:29:45 am »
Dual works with the concept of the undo and applied bytes. It works for binaries files but I will use text files to facilitate the explanation.

As example, considerate that you have three text files called orig.txt, mod1.txt and mod2.txt. The orig.txt correspond to the clean and unmodified file. Mod1.txt and mod2.txt are copies of orig1.txt which were modified to add a new code.

Code: [Select]
orig.txt  0123456789
mod1.txt  0ABCDE6789
mod2.txt  0123VWXYZ9

Let's make a dual patch between orig.txt and mod1.txt called patch1.dua. They have 5 different bytes between them and it begins in the position 1. The undo bytes will be “12345” and the applied bytes will be “ABCDE”. If we create a new patch called patch2.dua between orig.txt and mod2.txt, the difference between them is 5 bytes and they start in the position 4. The undo bytes are “45678” and the applied bytes are “VWXYZ”.

Code: [Select]
patch1.dua position 1, 5 bytes, undo = “12345”, applied = “ABCDE”
patch2.dua position 4, 5 bytes, undo = “45678”, applied = “VWXYZ”

If you get a clean copy of orig.txt its bytes will be “0123456789”. When you try to apply patch1.dua, its undo bytes will be verified against the target file. In this case, “12345” match the target file for the position 1 to 5. The applied bytes will be written in the file and the file bytes will now be “0ABCDE6789”.

If you try to apply patch2.dua, it will check his undo bytes against the target file. In this case, for the position 4-8 in the target file, its bytes will be “DE678” but the undo bytes in the patch will be “45678”. They don't match and the patch won't be applied to avoid a collision. To apply the patch, patch1.dua must be removed first.

If you have another patch in a different format (like IPS), you only need the clean rom and a copy to create a dual patch. Apply the IPS patch in the copy and create a new patch between the clean rom and the copy where the IPS patch was applied.

Dual is aimed to manage multiple dual patches in the same target file. When the setup of the patches is finalized in the target file, another patcher can be used for distribution. You only need the clean target file and the target file which was modified by dual patches. Patchers with high compression or more advanced features can be used.

There is too many issues related to this area and a unique tool can't solve everything. Dual is aimed to avoid collisions between dual patches and to facilitate their management. It may not be perfect but it surely helps. You know, it is my first patcher. I still am learning. :-)

I don't plan to include any kind of relocation support. Also, dual don't support file expansion. You can use specific tools for this purpose.

Programming / Re: Dual patcher: Bug Tracker
« on: April 29, 2014, 08:14:04 am »
Perhaps, I should give a practical example to help understand the patcher objective.

I am a hacker of Final Fantasy 6 (snes version). I have already two digits of patches for this game. For now, forget it and think you are a hacker who wants to do improvements for this game. You searched RHDN and another sites for patches. In the end, you could get nearly 40 small patches. All of them add small improvements for this game and it should be nice if all of them could work together.

Suppose that your patcher doesn't check for applying patches in wrong positions of the rom and that the patches are all from different people. Some of them don't have any documentation.

The first factor for corruption is if the patch is aimed for a rom with or without a header. If the patch is aimed for a rom without the header and the rom has a header, it will apply the modified bytes in the wrong location. Similarly, the patch also need to be aimed to a rom with the correct version. If only one of them mismatch the rom version and the header/no header issue, the game will be corrupted and will be left unplayable.

The most dangerous factor for corruption is address collision. When you apply a patch, if the patch overwrite the bytes already written by other patches, the game will be corrupted. The second patch must no overwrite the first patch. The third must not overwrite the first and the second. The fourth must not overwrite the first, the second and the third. If the patcher doesn't give you support to check or avoid the address collision between the patches, you can only pray that the rom will not be corrupted after the 40 patches.

Also, patches aren't static by nature. They should be upgraded for better versions. Let's suppose you have successfully applied 40 patches without corrupting the rom and want to upgrade only one patch. If you don't have an anti-patch, your only option is to start from a clean rom and apply all your 39 patches again. Of course, the new updated patch will change their addresses and it may or may not be compatible with your 39 patches.

The dual patcher is aimed to avoid the mentioned issues. It avoids the address collision between the patches and the appliance of patches that are not designed for the rom. It can also safely apply and remove the patches from the rom.

What is the max file size?
Internally dual uses a four bytes unsigned integer (32 bits). It can store the max value of 2^32. For my final fantasy 6 rom with 3MB, it is more than enough. For target files in the giga byte range, the patcher won't work correctly.

What sort of memory am I looking at when patching, when patch making and is there compression involved?
Dual follows a different direction from standard patchers. Instead of focus in the creation of small files with high compression for distribution, dual focus in the patches management.

Traditional patchers only need to store the difference between the files bytes. Dual needs to store the original and the modified bytes of the files. It is the double of the size of the bytes a traditional patcher should store.

Dual doesn't have internal compression and it is unfit for the creation of smaller files with high compression for distribution. It follows a different direction.

You seem to be heading for generic, is there any chance of it being adapted for something console/format specific?
Internally, dual perspective is to work with file bytes. It doesn't recognize any specific format for consoles. The actual direction is to follow the generic approach and to avoid any specialization for a specific console format.

Programming / Dual patcher: Bug Tracker
« on: April 28, 2014, 10:14:23 am »

I am developing a new patcher called dual. The patcher objective is the management of multiple patches in the same target file without the target file corruption.

A patch in dual format register the difference between two files with identical size. When the bytes differ in value for the same position, the bytes value of the two files is stored. A dual patch is effectively the merging of a conventional patch with his anti-patch (undo patch).

The main concept is to use the original bytes and the modified bytes stored in the patches to perform smart operations in the target file. As example, when a new patch is applied to the target file, the target file is checked against the original bytes. The modified bytes will only be applied to the target file if the bytes of the target file correspond to the original bytes in the patch. Otherwise, the patch isn't applied.

Dual can also verify if the patches are already applied to the target file and check the compatibilities between different patches. It allows the user to safely apply or undo the patches without the target file corruption.

I compiled the patcher in my system. It is a ubuntu linux 32-bit. To be honest, I don't have experience about distributable binaries and I don't know how compatible the executable file is with others linux systems. The source files are included with the patcher. They only use the standard c library and should be easily compiled with gcc or other c compilers. It is the theory, anyway. :-)

I am releasing a beta version for this patcher here . I did my own tests and it is working correctly in my system. However, many thing can happen between different systems and architectures. If someone has the interest, please give it a try and post any errors found.

I included a documentation in the file. You can also have a summary of dual commands with 'dual -h'

ROM Hacking Discussion / Re: HatZen08 Bug Tracker
« on: March 26, 2014, 07:54:59 am »
It is written in the documentation. It is in a PDF format inside of the 7z file. It is for the USA version (English), version 1.0, with a header.

The patch doesn't work for the version 1.1. Probably, you are using the version 1.1 or a rom without the header.

I will update the rom information for the page later. It was one of my first hacks and the rom information field didn't exist at the time of the submission.

News Submissions / Re: ROM Hacks: New Hacks Added to the Database
« on: March 14, 2014, 12:01:46 am »
You should consider the time of the triggers. Regen, as example, triggers twice for every poison trigger. Unless I miscalculated it, poison and regen triggers null themselves in damage for this actual configuration.

Characters can have the maximum of 9999 hp. However, it is unlike to happen without grinding and  maximum HP boosts by level. Enemies, however, can have nearly 65000 hp (a little more, I don't remember exactly the number). Because the damage/healing is based in maximum hp/mp, the healing/damage for monsters is always higher when compared with characters.

I put the cap of 999 damage/healing to try to balance the damage between characters and monsters. The cap can be easily removed. However, it is likely regen/poison for monsters will do 9999 damage/healing by trigger for enemies with higher HP. Is it acceptable?

It is common to have a character reserved for healing. A Cure 3 spell can easily heal almost all HP instantly. Regen and poison will take many turns and it is unlikely they will trigger more than once by turn, with few exceptions. Regen can't compete against Cure 3 in usefulness if the HP healing of regen is low.

I don't know where the time of the triggers is set and I can't change them. However, I can easily change the amount of damage/healing, as long as it is X/16 of maximum HP or MP. Seizure and phantasm will share the same amount, however, because of technical restrictions.

I am open to suggestions for a eventual patch update, if the arguments are valid.

NOTE: I like the fact that stamina isn't used anymore because it raises poison damage in the original game. If you raise stamina with espers, it won't hurt you now. :-)

ROM Hacking Discussion / Re: HatZen08 Bug Tracker
« on: September 27, 2013, 09:30:32 am »
The beta version code doesn't use the free space regions in the rom, like from C2/A65A to C2/A7FF, C2/FAA4 to C2/FC6C and C3/F091 to C3/FFFF. I removed the code related to the old magic system and replaced it with the new one.

ROM Hacking Discussion / Re: HatZen08 Bug Tracker
« on: September 25, 2013, 08:08:47 am »
Subject: Imbued Magic patch


I am developing a new patch called “Imbued Magic” patch. In summary, the availability of the spells in the magic command will be determined by the character equipment. It includes all equipable items and espers. If the equipment teaches a spell, it will be automatically enabled in the magic menu. Otherwise, it will be disabled. It is an alternative for the current magic system.

Unfortunately, it is a complex patch which required changes to the game engine. I won't annoy you with the details, but it wasn't smoothly. Because it is somehow complex, I am releasing a beta patch for beta testing. If someone is interested, the patch and the code can be downloaded here .

Please, note that summon, magic and lore spells are affected by the patch. They are managed  together by the game engine. Also, the field menu and the combat menu are different and they use different codes.

Two issues still need to be fixed: The cursed shield exchange after 256 battles and the magic command for the guest characters. For now, they don't work correctly. I will try to fix them later.

Thank you for your attention.

ROM Hacking Discussion / Re: HatZen08 Bug Tracker
« on: July 10, 2013, 08:27:04 pm »
I'm curious, what were the compatibility issues?

In the version 1.0, the Guest Adder patch checks specific flags in the items. If the item is used and the flags are set, the guest character is added to the party. To work correctly, the flags must be set or unset accordingly to every item. If the item is a guest adder item, the correct flag must be set in the item. If the item is a common one, the flag must be unset in the item. It must be correct to all items in the game.

In the item database, I wrongly assumed all the flags for the patch activation were unset, for all items. Unfortunately, it wasn't the case. The Paladin Shield item has the flag set by default and wrongly activates the patch when used as a item. It may be possible another items unexpectedly have the activation flag set by default.

To avoid unexpected activation of the patch for unexpected flags which wrongfully are set, I choose to use only the start-up actor database. The activation of the patch (in version 2.0) is based only in two fields of the guest characters. It is better than check every item to discovery if the flags are correctly set or unset.

And are you saying that in version 1.0 of this patch the extra HP and MP fields have been dropped also?

Yes. The calculation of HP, MP and Exp for the guest character is different from the official ones.

In the traditional HP calculation, a list of additional HP by level is used. Every level is associated with a HP value. The base HP (without equipments or special effects) is calculated by the sum of all designated HP for every level lower than the actual character level. As example, suppose the list is:

Code: [Select]
100 Level 1
200 Level 2
300 Level 3
400 Level 4
500 Level 5

The HP for level 5 is the sum of the levels 4 (400), 3 (300), 2 (200) and 1 (100). It is 1000.

The extra HP field is added to the sum. If the value of the extra HP field is 100, the base HP value will be 1100.

The same procedure is used for MP and Exp calculation, with different lists with different values. The HP and MP list are 16-bits values and the Exp list is 24-bits values.

The Guest Adder patch finds the average level of all encountered official characters. After it is calculated, a official character near the average level is selected. The HP, MP and Exp values are copied from the selected character to the guest character.

This may look a lazy approach. However, the lists of HP, MP and Exp are fixed. All characters gains the same amount of HP by level. Unless I am mistaken, without the interference of Espers boosts and the extra HP field, two characters with the same level have the same HP value.

The extra HP field is only one byte and can only add the maximum value of 255. The maximum value of HP is 9999 and the extra HP value is too low to be significant in the HP calculation. The maximum value of MP is 999 and the extra MP (maximum of 255) may be significant. However, guest characters can't use magic and it renders the MP value almost useless. I used the extra HP and extra MP fields as data storage for the patch configurations. I believe it is more useful than its original purpose.

I'd really, really love to use this patch, but as it is I just can't bare to sacrifice the extra HP and MP fields for my hack  Unless there's another way to give characters extra HP and MP upon startup...? (not by equipment)

Official characters use the original calculation of HP/MP values. The extra HP and extra MP fields are used. Only the characters created with the guest adder items use different HP/MP calculations.

I am open to suggestions of HP, MP or Exp calculations for the guest characters. If it has valid points, I can change the actual approach and eventually update the Guest Adder patch.

If you are comfortable with the actual approach for HP/MP calculation, it shouldn't be difficult to add a fixed value for HP or MP after it is calculated. If it is the case, I can implement it in the next update of the Guest Adder patch.

ROM Hacking Discussion / Re: HatZen08 Bug Tracker
« on: June 21, 2013, 09:10:56 am »
For compatibility issues, I choose to use only the startup actor data. The item data won't be used.

Because of technical issues, the calculation of HP and MP doesn't follow the traditional game engine approach. The extra HP and extra MP fields aren't used in the HP or MP calculation. It includes versions 1.0 e 2.0.

ROM Hacking Discussion / Re: HatZen08 Bug Tracker
« on: May 22, 2013, 05:19:26 pm »
I forgot to include the source file. I will submit an update with it included.

In summary, the original code loads the maximum HP of the character and divide it by 8 using three LSR instructions. The resulting value is compared with the actual HP of the character. The near death flag is set or unset based if the actual HP of character is below 1/8 of max HP.

The patch nulls two of the three LSR and replaces them with two NOP instructions. Instead of 1/8, now it uses ½ of max HP.

Original code:
C2/4536  B9 1C 3C LDA $3C1C,Y load max HP
C2/4539  4A LSR divide by two (now 1/2)
C2/453A  4A LSR divide by two (now 1/4)
C2/453B  4A LSR divide by two (now 1/8)
C2/453C  D9 F4 3B CMP $3BF4,Y compare current HP
… The following code set or unset the near death flag based in the result.

Patch changes:
C2/453A EA NOP
C2/453B EA NOP

ROM Hacking Discussion / Re: HatZen08 Bug Tracker
« on: May 06, 2013, 09:53:56 am »
There are two versions of this game for English. The differences between them aren't noticeable for the player but they have smaller differences in their code.

The patch is a set of patches aimed for the version 1.0 of the game. For the version 1.1, there are patches that won't work correctly.

I did a quick test in the version 1.1 of the game and the Sword Tech Ready Stance patch doesn't work. The game freezes when you select the Sword Tech command and the gauge never fills. It is similar to the description of the bug you have found. However, there are other patches that work correctly in the version 1.1.

I believe you used the version 1.1 instead of the version 1.0. Please, check if you used the correct version of the game.

ROM Hacking Discussion / Re: Final Fantasy VI hack: "Fair Hit"
« on: March 30, 2013, 02:18:15 pm »
My apologies. I do tests and I was wrong.

The hit system algorithm is complex and involves special cases, status conditions and attacks flags. It is difficult to understand and it has bugs. I tried to follow the algorithm logic and I misunderstand it.

In the tests, the magical evasion of enemies is considered. High values for magical evasion will make common spells miss against the monster. Like characters, monsters will use only magical evasion for both physical and magical evasion.

As a player, I never missed the Fire, Ice or Bolt family of spells against the majority of the monsters in the game. I associated the few monsters which can dodge magic spells as a special monster characteristic, unrelated to the magic evasion.

I believe, now, characters and monsters will use his magical evasion for both physical and magical evasion.

Without the interference of attack flags and status conditions, the major values which determinate if the spell hits are the hit rate value and the magical evasion.

In the original game, the hit rate value for the spells are too high and the magic evasion of monsters is zero or low. Because of it, the majority of common attack spells against monsters will hit, with few monsters exceptions.

I agree with you, assassin. If the magical evade is high and the attack hit rate is low, the spell can miss against a target. However, because of the original data for spells and monsters, it is unlike to happen, except for specific enemies with good magical evade and attacks with low hit rate.

ROM Hacking Discussion / Re: Final Fantasy VI hack: "Fair Hit"
« on: March 29, 2013, 05:35:05 pm »
Any attack in Final Fantasy 6 has its own internal structure. It includes many flags which determines the attack behavior.  The short version of the structure can be viewed at Data Crystal, in the Attack subsection:

The hit system uses that structure to determinate if the attack hits or fails in battle. The algorithm has fixed priorities over the flags. Status are considered by the algorithm, and they have fixed priorities with the attack flags.

I was talking about the effect of status in the hit determination. I wasn't talking about the spells themselves.

I agree with the “Vanish Bug”. In summary, if you cast Vanish and Doom in the target, the Doom spells always hits and kills the target.

The Doom spell, however, isn't a common attack. It has the “Defense based in stamina” flag.

The Vanish status is considered by the algorithm. If the target has Vanish status, all physical attacks against the target will miss. However, all magical attacks will hit.

If you use the Doom spell against the target and the target doesn't have the Vanish status, the “Defense based in stamina” flag has priority. It has priority over the default behavior of the algorithm, like a special case. In this special case, the spell can miss the target.

If you use the Doom spell against the target and it has the Vanish status, the “Vanish status” case has priority over the “stamina based” flag. In this case, all magic attacks must hit, and Doom is a magical attack. It is the source of the bug.

When I said that common attacks always hits against monsters, I used the word “common” as attacks without special flags. As example, the spell “Fire 2” doesn't have special flags. If a monster uses “Fire 2” against a character, the character can block the attack based in his magical block. However, if the character uses the spell against a monster, it will never dodge it based in its magical evasion alone.

The hit system algorithm is based in many attack flags and status conditions. It has complex and sometimes questionable priorities over themselves.

I will list only the relevant flags and status which can make a target hit or miss in battle:

  • Miss if target immune to death
  • Only target dead or undead monsters
  • Stamina is used as defense
  • Can't dodge attacks
  • Lv X spells
  • Miss if target is immune to inflicted status

  • Vanish: Physical attacks will miss and magic attacks will hit.
  • Image: Physical attacks will miss.
  • Sleep, Stop, Freeze: All attacks will hit against the target, but I am not sure about their  priorities with the other flags or status.
  • Reflect: Magic attacks will miss and be reflected.

As a note, the attack structure has the special effect field, namely the $11A9 variable. In short, it is used as a index for a table of pointers. They practically can alter anything in the attack structure and related structures, without restrictions. It includes the determination if the attacks hit or miss, based in his own code referenced by the pointers.

ROM Hacking Discussion / Re: Final Fantasy VI hack: "Fair Hit"
« on: March 28, 2013, 01:42:50 pm »

Interesting. Looks like the two patches fix the magical block bug and enemies evasion. I guess, now, it is only a matter of personal preference between the classic or alternative approach.


Note: The subject only applies to the original game (SNES version) without patches.

The enemies database contains fields for physical and magical evasion. However, it is somehow nonfunctional in the original game.

Monsters effectively don't have evasion, physical or magical. All common attacks will hit against them, except for special status effects like Image, Vanish or Reflect.

Characters will use the magic block evasion for both physical and magical evasion. Monsters, however, don't use evasion at all or it is null.

About the Blind status, in the original game, his only effect is to stop Strago from learning Lores. Nothing more.

ROM Hacking Discussion / Re: Final Fantasy VI hack: "Fair Hit"
« on: March 27, 2013, 06:05:08 pm »
The original hit system has the magical block bug. All attacks, physical or magical, will use only the magical evasion. Physical evasion is ignored. Monsters technically have physical and magical evasion in their database. However, it is ignored or ineffective.

Terri's Bug Fix corrects the magical block bug. It will use the correct physical or magical evasion, based in the type of attack. It also activates a unused code, hidden by the bug. In physical attacks, it will raise or lower the hit rate based in status. As example, hit rate is cut by half if the attacker has Blind status. His page describes the hit rate changes:

I believe it doesn't fix monsters evasion. A character may miss a monster only because his hit rate was lowered because of a status, like blind. Otherwise, it behaves like the original code. It should be checked for better accuracy.

The Fair Hit patch is a reimplementation of the hit system. It is a different algorithm from the original and produces different results, for the better or the worse. It uses the correct evasion for physical and magical attacks and it works for monsters and characters.

In the patch archive, there is the source file and a documentation for better details.

In summary, Terri's patch is a bug fix and Fair Hit is a reimplementation. If you prefer to stay close to the original concept of the hit system, use Terri's Bug Fix. Otherwise, you can use the Fair Hit patch. Both of them corrects the magical block bug, in different ways.

About the monsters evasion, I believe only the Fair Hit patch corrects them. You can test Terri's patch to see if altering the monsters evasion make practical difference in battle.

ROM Hacking Discussion / Re: Final Fantasy VI hack: "Fair Hit"
« on: March 27, 2013, 09:48:42 am »
The enemies database contains fields for physical and magical evasion. Unfortunately, many enemies have zero as evasion, for both physical and magical. For them, you won't notice any difference because their evasion is null.

In general, the majority of the enemies have null or low evasion. In practice, it will make you occasionally miss a Fight command in battle, but the majority of the attacks will hit. However, you will find specific (and few) enemies with noticeable physical evasion.

The Mt Zozo area has enemies with high physical evasion. It is the area where you find Cyan and fight the Wind Dragon. The majority of physical attacks will miss against them.

The Brachosaur enemy, in Dinosaur Forest, also has noticeable physical and magical evasion.

If you are curious about enemies evasion, you can use Final fantasy 3 Multi Editor to inspect the enemies database. If you only want to test the patch, you can arbitrarily edit a specific enemy evasion and test it in battle.

ROM Hacking Discussion / Re: HatZen08 Bug Tracker
« on: January 06, 2013, 12:02:14 pm »
From Gi Nattak (Guest Adder Patch):

Gi Nattak: There’s a bug in the patch’s code I found while testing this patch that affects the Paladin Shield - it makes it act like a ‘Guest Adder’ item (like the creator’s example item: ‘Leo Doll’). I’d really like to contact the patch creator about this instead of write a review about it, but there seems to be no contact info for the person. Hopefully this will catch his attention and he can fix the issue in a 1.1 patch.

From HatZen08:

The code is triggered by a specific flag in the item database. I presumed it was unused and unset in all items. I was wrong. The Paladin Shield has the flag set by default.

I will fix it later. Thank you for the feedback.

Note: I couldn't contact you either. You can post in this thread if you need to contact me.

ROM Hacking Discussion / HatZen08 Bug Tracker
« on: December 29, 2012, 02:53:58 pm »

   If you have found a bug in HatZen08 patches, you can post it in this thread. If confirmed, it will be added in a log for future reference. Hopefully, it will help to track and fix bugs in the patches. You can also discuss future updates to the patches.

Pages: [1]