Final Fantasy Hacktics

I was wondering... what is DefaultHacks.xml?

One of Razele's hacks is present in DefaultHacks.xml, but not Razele.xml.
One of Razele's hacks has the same hack in DefaultHacks.xml AND Razele.xml, but they're different versions and there's no way to tell which is the good one!

I'm just trying to make some sense out of all this because I think ASM hacks in FFTOrgASM requires one hell of a makeover. I really, really want to be able to group hacks by category, such as [Formula], [QoL] (Quality of Life), [RSM] and so on.

I was thinking of either manually adding those tags in the patch name and have the "All" section automatically reorganize in alphabetical order, or implement a tag feature.

I was also thinking about adding an Author tag, but that's not as important.

<Patch name="Cross Skip v3" tags="Quality of Life, SpeedUp" authors="Xifanie">
<Description>Holding X (Cross button), will fly you through dialog text as if you were mashing the button.&#13;&#10;&#13;&#10;by Xifanie</Description>
<Location file="BATTLE_BIN" offset="CA6C4">
1780023C
D097428C
CE400508
0480033C
</Location>
<Location file="BATTLE_BIN" offset="CA33C">
D3400508
</Location>
<Location file="BATTLE_BIN" offset="C8BC8">
EC400508
0480023C
</Location>
<Location file="BATTLE_BIN" offset="CB6F0">
DC400508
032C0500
40000831
02000015
25400000
A800A897
1780013C
D4DA37A4
D6DA3EA4
D8DA30A4
E0DA22A4
E2DA23A4
</Location>
<Location file="EVENT_ETC_OUT" offset="210">
E040050C
1780013C
</Location>
<Location file="EVENT_ETC_OUT" offset="258">
E040050C
1780013C
</Location>
<Location file="EVENT_ETC_OUT" offset="2A0">
E040050C
1780013C
</Location>
<Location file="EVENT_ETC_OUT" offset="2E4">
E040050C
1780013C
</Location>
<Location file="EVENT_ETC_OUT" offset="320">
E040050C
1780013C
</Location>
<Location file="BATTLE_BIN" offset="E9338">
4459638C
20014230
40006330
B5C50408
25104300
0480023C
4459428C
6400278D
40004230
02004010
FC00E230
03004734
D1C40408
00000000
0480083C
4459088D
BEC90408
00000000
54E4238C
00000000
07006014
0480023C
4459428C
00000000
40004230
02004010
00000000
FF7F1026
0800E003
3840228C
4459428C
00000000
40004230
04004010
1680023C
25A80000
1780013C
04A420A4
F4BE0408
885F428C
</Location>
</Patch>


Yeah, I don't really know what's going on with the organization of the hacks.  Not sure about DefaultHacks.xml either.  I basically just left it using the same scheme it already was.

I suppose the hacks could be organized however; a tag system could be a good idea, although I wonder how it would work in the interface.  Would there be a pre-set list of tags you could select?  Maybe you could search by tag?  Would the left menu be a list of tags instead of file names?

Since we're working with XML files here, in true XML fashion, when you have more than one element that can be specified in a category, instead of doing something like tags="Quality of Life, SpeedUp" it would probably be this sort of thing as a child node:

<Tags>
  <Tag>QoL</Tag>
  <Tag>SpeedUp</Tag>
</Tags>

Same for authors, if you wanted to support specifying more than one.

I suppose we should go with standard XML, yeah. Just never been a fan of the format. :p
I don't think I'd have too much trouble adding Tags/Authors support to my hack spreadsheet in that format, thankfully.

I was thinking of grouping by tags, and leaving the option to view individual files at the bottom... although I don't see how it would be all that useful after everything would be ordered by tags. It could be useful until we manage to more or less implement and standardize the tag system, so that everything is finally nicely ordered.

I also had another silly thought: adding a credits generator button. Copying to clipboard the list of authors and their relevant hacks so that you can easily copy/paste into your mod's main topic.
But you know, that would just be giving in to human laziness. :/
Using a hack is not nearly as hard as making it... you'd think people would at least try to properly credit people for their work, but instead it's only a minority that does. Sad.

Which makes me think: prior to the current release, my XML had Choto's Mime hack in it, and fdc completely removed my Weapon Strike Fix hack (which was a misnomer, I'll admit), to replace it with his Elemental Fix hack thing, which COMPLETELY disables the features that I've built in MY hack (which allows to choose between weapon/ability elementals). Yeah, when I learned that, I was pretty fucking pissed. So I bet people have not used my hack in years because it was gone.

Thanks a lot fdc

Hmm... yeah :/  ASM hacks shouldn't be disappearing like that.

I have a feeling that most people just wouldn't press the credits generator button if it existed although who knows.

Are the XML patch files that are in the current release the right ones or are there some updated ones that I should replace in the source?

They probably wouldn't press the button; just wishful thinking.

The xml files are fine AFAIK. I just don't know where DefaultHacks.xml came from; it wasn't there in .489.

I think I know what happened with DefaultHacks.xml.  It's been in the source forever, but it wasn't being included in the released builds because it was set to not copy to the output directory.  At some point, perhaps around the .491 release, I probably noticed it wasn't being copied and figured it was supposed to be, so it was included in 491.

DefaultHacks.xml seems like mostly an old version of Razele.xml, but there are a few (broken with load delay issues) hacks in DefaultHacks.xml that don't seem to have an equivalent in Razele.xml, namely:

Defending reduces physical damage by 25%
Float weak against Wind; Oil weak against Fire
Formula 4E hack

That said, they'd have to be rewritten anyway to work correctly.  I suppose they could either be fixed and included in Razele.xml or just deleted from the source.

I'm now releasing FFTPatcher suite v0.492! It includes... mostly a bunch of changes to FFTorgASM, but I think I've fixed some pretty signficant things with it, including the intermittent problem where it sometimes wouldn't patch, the problem with variable values sometimes being wrong, and the form resizing problem.  It also now checks for potential ASM hazards within patches and highlights ones that have them in red.  I also included a few other small changes. 

I added another release on the online repository for 0.492 here, which also includes the release notes!  Let me know what you think and/or if you find any bugs!

(Edit: MassHexASM has also been updated with the latest ASM encoder/decoder changes.)

So I'm confused.. Don't see any reason why these 2 hacks would conflict unless I'm looking over something incredibly dumb, but conflict checker has them marked as conflict:

http://i.imgur.com/ksvtv5d.jpg

http://pastebin.com/Uquz01eP

They don't.

It's probably checking:
[116B6C - 116B70] VS [116B70 - 116B78]

instead of:
[116B6C - 116B6F] VS [116B70 - 116B77].

Thus creating an imaginary conflict.

Since Glain develops this from time to time, here's some requests/suggestions for whatever future updates may come:

FFT OrgASM:
The left window which lists the .xml files - please make this control behave more like its counterpart on the right - a checkbox where you can click to show the contents of every .xml you're interested in on the right, with an "All" option that checks all the options for you.  The current method is nice but also a bit obnoxious at times - especially because it doesn't default to "All" being loaded, nor can you load an option by clicking the white space next to the .xml's name.  A checkbox setup similar to the method used to choose which hacks are going to be applied would streamline what you've done greatly.

ShiShi:
I know this one's probably obnoxious, but at some point, can the default resources for ShiShi use base-0 for the listings of Character Sprites, Formation Sprites, etc.?  Not only are things like UWEntries base-0, but even the values shown in FFTPatcher are base-0, as one might expect the game data itself to be, etc.  ShiShi is the odd exception that indexes all these things in base-1 and it requires constant mental conversion if you're, say, debugging a list of changes to UWEntries.  It's not a big deal for a user only making one or two changes but its obnoxious for anyone attempting anything on a larger scale.

Otherwise I really like what I've seen from .492 so far.  Good work.  Both of my suggestions are mainly just usability quibbles, really.

Quote from: Glain on January 02, 2017, 02:24:37 am
I suppose the hacks could be organized however; a tag system could be a good idea, although I wonder how it would work in the interface.  Would there be a pre-set list of tags you could select?  Maybe you could search by tag?  Would the left menu be a list of tags instead of file names?

Since we're working with XML files here, in true XML fashion, when you have more than one element that can be specified in a category, instead of doing something like tags="Quality of Life, SpeedUp" it would probably be this sort of thing as a child node:

<Tags>
  <Tag>QoL</Tag>
  <Tag>SpeedUp</Tag>
</Tags>

Same for authors, if you wanted to support specifying more than one.

I had the same thoughts (about authors and tags), but why is a <Tags> wrapper needed? Is this some XML style thing I'll regret asking about?

Another feature I wanted was `endian="little"` (or "big" or "auto") for the locations.

Suggestion: Any chance that you can make Patcher more consistent with its use of hex and decimal values?  Ideal: an option to toggle between use of hex/decimal values for all boxes under "file" (where the program will convert between them if you click the other option).  If that's not possible, make it only use hex?

Quote from: Emmy on April 19, 2017, 12:34:41 pm
Suggestion: Any chance that you can make Patcher more consistent with its use of hex and decimal values?  Ideal: an option to toggle between use of hex/decimal values for all boxes under "file" (where the program will convert between them if you click the other option).  If that's not possible, make it only use hex?

Standard form for tools like FFTPatcher is to use Decimal for known values (ie Multipliers and Growths on jobs, X/Y tile locations, etc.) and Hex for index values (Sprite ID, Unit ID, Job ID, Skillset ID, Item ID, Ability ID, etc.).  The problem with FFTPatcher is that it isn't always consistent even on these rules.  It's been a long time since I've reached my fist into the guts, so I can't think of examples off the top of my head, but I remember it having issues in not always consistently casting data types in the GUI following this rule.  If those could get fixed, it would be nice, but someone would have to dig through FFTPatcher and find all the examples of stuff that needs fixing since Glain just inherited Melonhead's mess.

Quote from: RavenOfRazgriz on March 31, 2017, 08:39:24 pm
I know this one's probably obnoxious, but at some point, can the default resources for ShiShi use base-0 for the listings of Character Sprites, Formation Sprites, etc.?  Not only are things like UWEntries base-0, but even the values shown in FFTPatcher are base-0, as one might expect the game data itself to be, etc.  ShiShi is the odd exception that indexes all these things in base-1 and it requires constant mental conversion if you're, say, debugging a list of changes to UWEntries.  It's not a big deal for a user only making one or two changes but its obnoxious for anyone attempting anything on a larger scale.

I took a look at this - to be clear, this is for the dropdown in the Other Images section where you select a specific image inside a category?

The general format of an entry in that dropdown is "{LeadingNumber} - {Name}".  If {Name} isn't specified for a specific entry in the source XML file, then {Name} uses the format "{CategoryName} ({TrailingNumber})"

I could change {LeadingNumber} to two-digit hex starting at 0, which would be more in line with what FFTP does (and UWEntries, for that matter).  As for {TrailingNumber}, I could also change that to start at 0, but maybe leave it decimal.

Some directly specified {Name} values within the input XML contain their own specific numbers starting at 1 (e.g. WLDTEX1).  Not sure if those would be worth changing.

To be consistent, I could also use base-0 for the Palette dropdown in the same section.

Quote from: RavenOfRazgriz on April 19, 2017, 01:31:05 pm
Standard form for tools like FFTPatcher is to use Decimal for known values (ie Multipliers and Growths on jobs, X/Y tile locations, etc.) and Hex for index values (Sprite ID, Unit ID, Job ID, Skillset ID, Item ID, Ability ID, etc.).  The problem with FFTPatcher is that it isn't always consistent even on these rules.  It's been a long time since I've reached my fist into the guts, so I can't think of examples off the top of my head, but I remember it having issues in not always consistently casting data types in the GUI following this rule.  If those could get fixed, it would be nice, but someone would have to dig through FFTPatcher and find all the examples of stuff that needs fixing since Glain just inherited Melonhead's mess.

Right, this is how I understand the general idea as well.  I don't like the idea of having a universal toggle. (IDs in decimal are fine, but why display something like Evade % in hex?) If it's not consistent in places, we can change specific values as they come up.  I don't know of any off the top of my head, so as you've said, somebody would have to find the values they want changed and list them out.

Quote from: Raijinili on March 31, 2017, 08:44:40 pm
Another feature I wanted was `endian="little"` (or "big" or "auto") for the locations.

Is there a practical application behind this?

This would require some way to separate the bytes into groups to then apply the byte ordering on.  We could either use a delimiter between groups (the delimiter could just be a newline), or require a specified, uniform number of bytes per group.

If implemented, the only thing this would do is check for endian="big" and if so, reverse the bytes in each group.

Quote from: Raijinili on March 31, 2017, 08:44:40 pm
I had the same thoughts (about authors and tags), but why is a <Tags> wrapper needed? Is this some XML style thing I'll regret asking about?

It's just standard XML format.  It would allow for more information to be added to the tags per item if necessary, although maybe that isn't needed.
It could be done as CSV (comma separated) within an attribute as well, as was first suggested.  That can get dicey if you want to put a comma inside a tag name, but the same can be said for < and > characters inside XML tags (although you can escape those using CDATA).

Quote from: Glain on April 25, 2017, 11:45:40 am
I took a look at this - to be clear, this is for the dropdown in the Other Images section where you select a specific image inside a category?

Actually, never mind this one.  I was talking about the main Sprite page, but I apparently still had a .482 FFTPatcher loaded when posting this.  I just checked and it's fixed in both .491 and .492.

The unknown flags in shishi are actually for the sprite's "height" value - most units are 36 (3 tiles), Altima 1 is 60 (5 tiles) and Altima 2 is 120 (10 tiles) tall. This affects things like arrow arcing and deciding where a unit can pass on the map if there's a spot where there's a higher tile on the same X/Y (like in the cases of bridges).

Quote from: secondadvent on May 08, 2017, 07:53:20 pm
The unknown flags in shishi are actually for the sprite's "height" value - most units are 36 (3 tiles), Altima 1 is 60 (5 tiles) and Altima 2 is 120 (10 tiles) tall. This affects things like arrow arcing and deciding where a unit can pass on the map if there's a spot where there's a higher tile on the same X/Y (like in the cases of bridges).

You always know when SA makes it post it's gonna be good. He's almost up to 20! That's almost 2.25 per year! Woo!

Should I post anything I find wrong with the FFTPatcher in here or is that somewhere else now? I know this page is almost a year old, but it seems to be the continued thread for it. I just noticed a couple things in the patcher that are incorrect and may be confusing to new people using it that wouldn't otherwise know.

1. Formula 1F for Malak's Un-Truth skills shows an incorrect formula. In patch it shows,
1F Dmg_((100-CasF)*(100-TarF)*(MA+Y)*Ma/2)

which is incorrect and Malak would be breaking all kinds of damage limits if it were correct lol. The correct formula is as follows,

1F Dmg_((1-CasF/100)*(1-TarF/100)*((MA+Y)*Ma/2).

2. I've found that in the tips box for the Faith forumla it lists F as F=CasF*TarF/100^2 which is also incorrect.
The faith formula is actually F=(CasF/100)*(TarF/100)

I'm not sure if someone has already pointed this out somewhere in here as I didn't thoroughly look through the other pages. I just figured I wouldn't mention it in case it hadn't. If it has then you can ignore this.

I mean, you're not wrong, but you're also not right...

In PSX games and thus FFT, floating points do not exist. So 99/100 (or 0.99) is 0.

I know that the faith formula is wrong in that regard, but from a mathematical perspective, your "correct" formula is the same thing as mine... Maybe you forgot about the priority of operations that you learned in school? Exponents come before nearly much anything else.

The issue is that I never based the formulas off actual code. Someone would really need to go through all the documented code and properly document all the ability/weapon formulas, but no one has ever done it in the 10 years FFH has existed, so I doubt it will ever happen.

You are right! Haha! Don't I look the fool now. I forgot to do the exponent on the faith formula first. So the only one wrong is the un-truth formula, and since floating points don't work then my formula probably isn't correct from a code stand point either.

I understand where you are coming from. I didn't make the post as a criticism, but rather a bug report. Just a small thing that is easily fixed through the resources.zip for one that knows what they are doing. I already corrected it for my download, but thought I'd throw it out there for a future update if and when that happens.