• Welcome to Final Fantasy Hacktics. Please login or sign up.
 
June 01, 2024, 10:59:09 pm

News:

Don't be hasty to start your own mod; all our FFT modding projects are greatly understaffed! Find out how you can help in the Recruitment section or our Discord!


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

21
PSX FFT Hacking /
January 29, 2009, 06:05:02 pm
Vanya, I made a mistake with the Rod formula, a rather bad one I think. =X

Old: DA160608

New: D7160608

Change DA to D7, I've updated my first post, but I wanted to make sure Vanya noticed. =P
22
PSX FFT Hacking /
January 29, 2009, 05:10:38 pm
Not sure about 1, haven't used that program much myself yet, but editing spell quotes will be in a TacText update, if not the next then soon I'd imagine. Last time I heard melon had figured out where the quotes were and shit, it just needed to be implemented into the program.
23
PSX FFT Hacking /
January 29, 2009, 01:43:08 am
QuoteRods (PA*WP) ---> (MA*WP)

Crossbows (PA*WP) ---> (WP*WP)

Poles (MA*WP) ---> (PA*WP)
Note: I mean Poles, not Spears.

Done.

The instruments/books one is pretty much done too, I just want to make sure I can't find a better way to do it first. The rest will come pretty quickly too, while I was tinkering with instruments I came across the areas I'd look for first for bags and cloths, so half the work for those are done.
24
PSX FFT Hacking /
January 27, 2009, 12:02:55 am
Thanks Zodiac.

QuoteKatana (PA*(Brave/100))*WP) ---> PA*WP
Note: Zodiac did this for Knight Swords, but I don't know if it affected katana.

Yep, it changes Katanas to PA*WP. It also changes Monks bare-handed attacks to PA*PA I think. It does effect bare-handed attacks as well, I'm just guessing it's PA*PA, I didn't do any testing on it since Monks aren't even going to be in my patch.

Nothing you requested should be a problem, but the middle of the week is hectic for me with school and shit, plus it seems teachers like to hand out assignments on Tuesday that are due two days later on Thursdays, so usually Tuesday, Wednesday, and Thursday are school onry, but I'll get them done over the weekend.
25
The Lounge /
January 26, 2009, 09:09:45 pm
QuoteMuch like how government agencies prefer to go after drug dealers rather than buyers

Once I read this, I knew you had no clue what you were talking about.

Drug laws have been abused by the police to target minorities and the poor countless times. The marijuana laws were damn near specifically created to target the influx of immigrants from Mexico at the beginning for the 20th century. You have little to no knowledge of this subject. Our jails and prisons are filled with people convicted with possession. The agencies, at least at a local level, tend to focus on people they "don't like" for whatever reason, and they're often times users, not dealers.

Rather then ask pro-lifers dumb ass questions like that, I instead turn to a different one that none of them can answer and not leave an opening big enough to drive a dump truck through.

Pro-choicers do not believe it's murder, yet pro-lifers do. Why are the pro-lifers right and the pro-choicers wrong? More specifically, what gives the pro-lifers the right and authority to make morality decisions for someone else who disagrees with them?

Be careful, that's a slippery slope. Any attempts to relate abortion to murder or theft, or any other firmly established crime that we can all agree is wrong, is completely missing the point of what makes this subject controversial and a blatant straw man.
26
The Lounge /
January 26, 2009, 06:58:18 pm
Quoteas some FF geeks can go a bit over the top on their niche expertise

Hey man, if you wanna enjoy all these hacks and edits and programs and patches and shit, then you gotta deal with some of the side effects of genius. =P
27
PSX FFT Hacking /
January 26, 2009, 06:46:15 pm
QuoteCan I request some weapon formula changes? ^_^

Yeah, sure.
28
PSX FFT Hacking / Nate's ASM Hacks
January 26, 2009, 07:23:50 am
Attack Up bonus becomes 25%
BATTLE.BIN
Offset: 0x11F0BC
Change 5555 to 0050
Offset: 0x11F0CC
Change 5655 to 0100

Attack Up bonus becomes 20%
BATTLE.BIN
Offset: 0x11F0BC
Change 5555 to CC4C
Offset: 0x11F0CC
Change 5655 to CDCC

Magic Attack Up bonus becomes 25%
BATTLE.BIN
Offset: 0x11F220
Change 5555 to 0050
Offset: 0x11F230
Change 5655 to 0100

Magic Attack Up bonus becomes 20%
BATTLE.BIN
Offset: 0x11F220
Change 5555 to CC4C
Offset: 0x11F230
Change 5655 to CDCC

Defense Up bonus becomes 25%
BATTLE.BIN
Offset: 0x11F2E8
Change 5555 to 0050
Offset: 0x11F2F8
Change 5655 to 0100

Defense Up bonus becomes 20%
BATTLE.BIN
Offset: 0x11F2E8
Change 5555 to CC4C
Offset: 0x11F2F8
Change 5655 to CDCC

Magic Defense Up bonus becomes 25%
BATTLE.BIN
Offset: 0x11F338
Change 5555 to 0050
Offset: 0x11F348
Change 5655 to 0100

Magic Defense Up bonus becomes 20%
BATTLE.BIN
Offset: 0x11F338
Change 5555 to CC4C
Offset: 0x11F348
Change 5655 to CDCC

Remove target's faith from spell damage calculations
BATTLE.BIN
Offset: 0x1201F8
64000234
00000000

Longbow, Knife, and Ninja Blade formulas become PA*WP
BATTLE.BIN
Offset: 0x11EBA0
Change 38 to 36

Crossbow formula becomes WP*WP
BATTLE.BIN
Offset: 0x11EB4C
00000000
71520508
Offset: 0xED9C4
0B000234
02006210
D0382290
D5160608
CE3822A0
20170608
00000000

Rod formula becomes MA*WP Updated
BATTLE.BIN
Offset: 0x11EB54
00000000
78520508
Offset: 0xED9EO
07000234
02006210
942D2290
D7160608
37002290
CE3822A0
20170608
00000000

Pole (Stick) formula becomes PA*WP
BATTLE.BIN
Offset: 0x11EC0E
Change 26 to 30

Instrument, Dictionary, and Cloth formulas become MA*WP
BATTLE.BIN
Offset: 0x11EC72
Change 0202 to 4200

Bag formula becomes PA*WP
BATTLE.BIN
Offset: 0x11EC24
00000000
80520508
Offset: 0xEDA00
11000234
03006210
00000000
16170608
F3FF8224
DA160608
00000000

Cloth formula becomes... "axe formula"
Note: Overrides changes done to Cloths in the "Instrument, Dictionary, and Cloth formulas become MA*WP" hack
BATTLE.BIN
Offset: 0x11EC64
00000000
87520508
Offset: 0xEDA1C
12000234
03006210
00000000
20170608
FF00C230
0C170608
00000000
30
PSX FFT Hacking /
January 25, 2009, 09:18:40 am
A screen shot of Miluda in the FFTPatcher, we need. A screenshot of it in the game, we need not.
31
PSX FFT Hacking /
January 25, 2009, 03:11:04 am
A straight 30 HP or 25% of max HP, which ever is higher.

That'd probably be better for numerous reasons.

You could probably use a branch to do it. Load 30 and 25%, if 25% is higher branch off to an area where you write 25% in the relevant temp address, if 30 is higher don't branch and write that to the temp address. You could use the old formula to determine what the constant number is I guess, that way you could still alter that number in the FFTPatcher in case you wanted to change it later, and you wouldn't have to code in any numbers manually.

Items don't consider br/fa/pa/ma/anything, so that'd probably be easy enough to put in, but the branches and shit would have to be written from scratch. You could jump out right after it loads the constant value, but before it alters the HP, that way it'd save some space.

Jump to new area, load 25%, branch so that if 25% is lower it jumps right back to the area you came from, if 25% is higher transfer that value to whatever registry the constant was in, then jump back to the area you came from.

You'd have to have a different area for each potion type though, at least with my understanding. Or you could do some fancy shit with the item value and some more jumps to load one of the three percentage values. Subtract the lowest potions item value from each one, if 0 go here, if 1 go here, if 2 go here. I haven't looked at items though, so it might be harder then that.

Now that I think about it, it probably uses the same ASM code for all three items, it just loads a constant from a different spot depending what the item value is. I know how'd I'd do it, but once it was written you'd have to manually edit the branches in WinHex, and if you changed the constant in FFTPatcher then it'd fuck everything up without doing that. The constant value is what the branches would go by.

All of those methods are probably inferior to what Raz would do. I'm actually interested in seeing how he'd do it.
32
PSX FFT Hacking /
January 24, 2009, 10:43:31 pm
Signed and unsigned. = signed can be a positive or negative, unsigned can only be positive (so a -2 becomes a 2,  or rather then having half of the possible numbers negative and half positive, there are only positive numbers), i might be getting these two switched, and i havent really figured out how the PSX uses these, the standard definition for other languages i have experience with may not apply

byte = 2 numbers (8 bits, 1 byte), such as 08, 19, ect
word = 8 numbers, or 4 bytes, a register has space for 8 digits, you can only fit a single word in the registers, its hard to give a consistent definition for this, but when you see the "lw" or "load word" command, it means its going to load 8 digits, or 4 bytes
half-word = 4 digits, or 2 bytes, or half of the available space in a register

branches are conditional jumps, just like the guy said in the chat logs, uhhh, i dont think i could offer an explanation any more clear then what he said

immediate = http://en.wikipedia.org/wiki/Constant_(computer_science)#Constants
"In many machine assembly languages or instruction set specifications, constant values are termed immediate values because they are available immediately (often embedded as part of the instruction stream) without needing to load a value from the data cache[1]."
immediates can be seen as values being directly being inputed into the registry, so that the value itself stays in the registry, rather then the register going to the values memory address and loading that value instead, at least thats the gist of it within other contexts ive looked at, but it may operate differently in the PSX

registers = r2, r9, r17, ect, if youve looked at the debugger youll see a list of these values, values are loaded into the registers so they can be used through opcodes (instructions)

breakpoint = basically, you tell the game to instantly freeze once this address is read, or this instruction is executed, ect. that way you see see exactly where in the hex data a particular instruction is, what the game is doing at that very moment, this is pretty much the most important part of ASM editing, to get started, in your debugger, add a break point (memory, read, youll see these options) and put this address: 0x80192D94, then do something, like use an ability, cast a spell, or use a physical attack
33
PSX FFT Hacking /
January 24, 2009, 10:23:38 pm
The formation sprites and portraits are found in wldface.bin and unit.bin. You use a JP program to edit them. However, there are some limitations.

http://www.ffhacktics.com/forum/viewtopic.php?t=764
Editing Unit.bin Video: http://blip.tv/file/1128977/

There's lots of info around the forums on this subject, so if that topic alone isn't enough pick through the threads.
34
PSX FFT Hacking /
January 24, 2009, 09:20:13 pm
Actually, with Zodiacs ppf files, all those sprite file sizes were increased, so that shouldn't be problem. Just remember those sprites are used in the game somewhere.

You should do it and tell us how it goes. =P
35
Hacking/Patching Tools /
January 24, 2009, 10:09:25 am
I have zero experience editing events, but....

{45}(r020001) Ramza
{45}(r170001) Gaffy
{45}(r830001) Generic
{45}(r800001) Generic
{45}(r810001) Generic

Those look like unit ids to me.
36
PSX FFT Hacking /
January 24, 2009, 08:22:34 am
Yeah, that was my initial thought on ORI, but when I used it to set Target's Faith to 0x0064 it kept popping out the wrong damage, but now that I'm getting the wrong damage output on a vanilla ISO it makes sense that I used ORI right.

I just assumed I wasn't understanding ORI correctly, considering I'm new to it.
37
PSX FFT Hacking / ASM notes
January 24, 2009, 05:19:14 am
I'll probably add this to the wiki eventually, but for now I'll keep it on the forum for anyone who wants to take a look at it. I gotta give back to the forum in some way, and I figure something like this will help anyone trying to ASM edit.

The fact of the matter there is limited space in BATTLE.BIN and WORLD.BIN to write ASM code. Eventually we will run out of the space. However, if you aren't using every single ASM hack that has been posted on the site, you will actually have space in your own patch's files that hasn't been used. Anyone serious about making a patch should have some basic understanding of ASM so they can change jumps and what-not to add in stuff they wouldn't otherwise be able to. Changing jumps is fairly easy, and people like Razele and Zodiac do most of the footwork if that's all you have to do to add in stuff.

Mostly though, Razele's topic is swamped with requests, and some us don't feel comfortable walking into a topic and requesting shit. DIY isn't just for punk rock bitches.

Notes: (for anyone interested)

Clarification: raw value means the actual value you see, otherwise the "value" is referencing a memory address.

The PSX is little endian. This means values are "reversed" in a way. If an opcode (instruction) writes a value to the memory the bytes get reversed. Example: If it's writing 8019 to the memory, the two bytes are reversed, this means 80 19 is actually stored at the memory address as 19 80. They are read backwards just like they are stored backwards.

Some examples may seem confusing, like addiu (why would I use an example that has r29 as two values?), this is because I'm strictly going to use examples I have seen in the debugger, or "in the wild," unless I'm 100% sure I'm right.

This is meant to compliment Zodiac's ASM lessons which you'll find in another thread. You should read it, although a thorough understanding isn't really required. I barely understood it when I started anyways.

0x8FFFAAAA is the same thing as 0x0FFFAAAA, you'd know that if you read the lessons thread, and you'd know why you use the 8





addiu r29,r29,0xffe8

add r29 to 0xffe8 and store the result in back into r29, the first instance of r29 is the destination

r29 was 801ffec8
r29 became 801ffeb0

A difference of 18.

801ffec8 plus ffe8 is 8020feb0, but notice how the first four digits do not change, only the last four.

you can use addiu to store new values, like if r3 is nothing but zeros, you could do addiu r3,r3,0x0064 to store 64 to r3, this is probably more reliable then ori, addiu r?,r0,0x0000 can probably be used to zero out r?

addu r16,r4,r0

add r4 and r0 together and store the result to r16... r0 is ALWAYS a series of zeros, this particular example is used to move a value from r4 to r16 without changing it

blez r5,0x0005e664

if r5 is something, you do something, then something happens, and you get yummy pie, r5 was higher then the value at that address, which was 08, and r5 was less then 5e664, it skipped the instruction right after it

bne r2,r0,0x0005e650

if r2 and r0 are not equal, go to 0x8005e650

lbu r2,0x0026(r3)

take the value at r3, add 0x0026, and store the byte from the resulting memory address to r2, if r3 was 0x80192bcc, you add 26 to that, which is 80192bf2, the byte at 0x80192bf2 is then stored at r2

lui r1,0x8019

loads raw value 0x8019 into first four "slots" of r1

lw r2,0x2d98(r3)

add 0x2d98 to r3, go to that memory address, and write the 4 bytes (8 digits) to r2

ori r2,r0,0x0001

Zodiac said:
ori is more appropriate to set a value in a register.

ori r2, r0, 0x0000
r2 = 0x00000000

ori r3, r0, 0x0063
r3 = 0x00000063

I think you should go back at lessons to understand how or and ori works. 0x00000000 OR 0x0063 = 0x00000063.


basically ori is used to load constants/immediates into the registries, while lbu and lui are used to store memory addresses into the registries

sb r2,0x38e5(r1)

stores last two digits of r2 to r1+0x38e5, if r1 is 80190000, then it will store the two digits at 0x801938e5, it adds the two values together, although ive never seen it add to a value that didnt end with four zeros, it probably does at some point in time

ive seen sb r0,0x0000(r4), in that example it used the r0 register (which is always a series of zeros) to zero out the byte at he memory address r4 references

sh r2,-0x2f7e(r1)

this operates just like sb, except the length of data being stored is differed (sb is byte, sh is half-word), this is worthy of being noted because of the negative sign you see before 0x2f7e, this means exactly what you think it means, rather then take r1 and add 0x2f7e, it instead subtracts it, if r1 was 80150000, then it will store at 0x8014d084

slt r2,r3,r5

if r3 is less that r5, write r3 to r2

sw r31,0x0010(r29)

stores all eight digits of r31 at r29 + 0x0010

Shift Word commands (sll, sllv, sra, srav, srl, srlv, ect)

http://www.cs.uaf.edu/~cs301/notes/Chapter5/node3.html

QuoteBATTLE.BIN
Offset: 11EBA0
Change 0x38 to 0x36

Crossbow, Knife, and Ninja Blade Formulas become PA*WP

How this was accomplished:

First I looked at 0x80192D94, which is where the current units address is stored (http://www.ffhacktics.com/wiki/Current_ ... ts_address) then I added the SP value to the current units address (http://www.ffhacktics.com/wiki/Formula_Hacking), now I know what specific byte that units speed is stored at.

You have to look at the current units address after you've selected something to attack/cast a spell on/ect. There can be old or incorrect data at that address. Basically, if the game is telling you the amount of damage, or percentage to hit, then it has the correct unit address there. It's best to err on the side of caution in this instance.

Generally, just breaking on the units address is a bad idea. It's interesting enough, you get a chance to see the game loading all sorts of values, from X/Y coordinates to equipment, but it'd take an eternity to zero in on the relevant stat.

The problem I had with this particular edit is that it seemed to alter the SP stat right after throwing it into the registry rather then assigning a temporary address it could pull from later. This meant I could easily see the SP value in the registries after it was called, but no temporary address to follow after that. It is entirely possible I overlooked it though.

Instead, I took the address I got from the units address plus 0x0038 and just followed that. In this case It came up a number of times. It showed up six times at 0x80183968 for all three weapon types, once at 0x80185ba4 for the crossbow and ninja blade, and twice at 0x80133814 for the crossbow and ninja blade.

Rather then edit all three of those addresses I did one at a time to see which one effected all three weapon types. Even though the game never broke at 0x80185ba4 for knife, it ended up being the one that effected the damage on all three.

I wanted to stay as far away as I could from the address that showed up six times. You always have to keep in mind that parts of a formula may be reused elsewhere in the game. Logically it would make sense the address that only showed once would be the one the game uses for those formulas. Indeed, the edit I posted above could very well screw something else up and I just didn't pick up on it. It's probably a good idea to alter as little as possible.

Another thing to keep in mind, take a look at the area around 0x80133814. You see lots of different stats being loaded and stored right? To me that says that this is an area that is used by lots of things. As if the game goes through this area for a lot of skills/spells/weapons/ect, and loads up a whole bunch of (mostly irrelevant to these formulas) values. That was a red flag, if I screw with things here there's a much higher chance I'll inadvertently effect other things.

QuoteBATTLE.BIN
Offset: 1201F8
64000234
00000000

This removes the target's faith from damage calculations, and likely accuracy calculations as well.

How this was accomplished:

Just like the first edit, I found target unit's address using the same method. This time, I added 0x0026 to it for the exact location of the target's faith and set a break point on that stat, and the game broke 0x801838d2. However, once again, there are a lot of values being called and stored in this area, so it was best not to alter this area. This time I did find a temporary address, which was 0x801938d2, and thus it became my second break point.

The temporary address was called at 0x801871f8, and the game broke there. I wanted to know where the game jumps into this area though, because I see multiple mult commands, and I see these mult commands dumping out huge numbers. It jumps in at 0x801871f0, and the first two commands I want to stay clear of. It isn't loading any value from either units address. The address at 0x801871f8 is calling the target's faith, and this is where having a target and unit with different faiths helps, otherwise both values will be the same and it becomes harder to see which is which with certainty.

Rather then try to alter this large string of commands and mults to get it to dump out proper numbers while only considering the caster's faith (which is impossible unless you got a shitload of time to kill), I simply replaced the two commands used to call the target's faith with one "nop" (just zeros) and one ORI command (ori r2,r0,0x0064). 64 is 100 in hex, so basically I just forced a value of 100 instead of letting the game load the target's faith. The formula has a TargetFaith/100 part to it, and this makes it 100/100 (or 1) regardless of the target's faith.

After this the game did break one more time, but I ignored this because when I let the game go one step at a time it seemed to lead me nowhere. More importantly, the step I just did altered the damage the way I expected it to. In all likely hood this edit will effect both damage and accuracy calculations, but at this point I can't say for sure.

Why does the game line up mult commands the way it does around the area I edited? Well, rather then actually using division to calculate this stuff, it simply does a TaFa*CaFa*MA*Y / 10000 formula (to simplify it greatly). Those huge numbers are needed so that after the last mult command it can pull the value from hi rather then lo. This way no division command in necessary, thus it can avoid the nasty effect of division's quotient and remainder being split between hi and lo. It probably does it in less commands this way as well.
38
PSX FFT Hacking /
January 23, 2009, 06:55:40 pm
Woot! Thank you Raz, that cleared things up for me.
39
PSX FFT Hacking /
January 22, 2009, 04:34:25 am
I have a request.

Change formula 08 from MA*Y to MA*MA

When you use an ability using this formula memory offsets 0x187208, 0x18721C, 0x18722C are all used, but I just can't get this shit to work. I tried jumping to some empty space after the last one and just writing a MA*MA calculation from scratch, but that didn't work either. I tried to add "lbu r2,0x0037(r2)" right before the last mult, and changing the last mult to "mult r2,r2", but that kept returning a 0. I don't think "0x0037" is the units MA. I got the idea that the units MA is "0x0037" from here: http://www.ffhacktics.com/wiki/Formula_Hacking

It jumps to 0x1871F0 and then goes through the mult commands at those offsets, but I don't know where it is before that.

If those are the right memory offsets, that would put the formula at about 0x120208 in battle.bin, and that's nowhere near where you have to edit to change other formulas.

I've spent about 6 hours on this. I'm making a major fuck-up somewhere. None of the mult commands from 0x185ADC to 0x187204 change the damage of a spell using the formula.

I did a breakpoint at the first of those offsets and just "step into" for what seemed like an eternity and didn't come across any other mult commands.

On the plus side I found part of the code used to determine accuracy from zodiac compatibility (0x1859B8), at least I think it's zodiac, it isn't equipment. I followed that with "step into" and it lead me to another mult command (0x7c02210), but when you set that as a breakpoint the game instantly breaks, so it must be something else.

So yeah, if I could just see what you'd do to change it it'd probably teach me a good bit, plus it's one less edit I have to do for my patch. =P
40
Old Project Ideas /
January 19, 2009, 08:17:33 pm
Well, I'd say it's far from done. =P