Please login or register.

Login with username, password and session length
Advanced search  


Please use .png instead of .bmp when uploading unfinished sprites to the forum!

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

Pages: [1] 2 3 ... 24
Help! / Re: Help coding new stealing/breaking routine
« on: August 14, 2018, 07:05:55 PM »
The main conceptual issue I see with this is that the game might not support it as-is because the action data can only have one item ID for stolen/broken item.  That being said, I took a look at this... a few things stand out.  You need to either use labels or have some idea of what address in RAM this code is going to be stored at.  This line is pretty much guaranteed to crash the game:

Code: [Select]
j 0x00000000

Jumps to literally the beginning of RAM.  Jumping to 0x25c or what have you will also crash the game.  You need to be jumping to the address in RAM where your code is.  Labels can help a ton with this, as you'll see in my code example below.  There's also a ton of inefficiency, as Xifanie touched on, but since your register values aren't even being overwritten, you don't even need to save anything to the stack.  You're reloading values just to reload them...

I simplified the logic down to this, which I believe should largely do what was intended (though is completely untested).  It fills out the action's 0x19 flags with the items to break/steal by using a loop.  Since you were basically doing the same thing for each item type, I just made that logic part of the loop.  This routine doesn't do the normal checks like evasion, Maintenance, etc., but those could possibly be checked in another routine if this is to be an inner routine... otherwise those checks would need to be added here.

Code: [Select]
    lui     at, 0x8019   
    lw      t1, 0x2d98(at)          #   Load Defender's Stats
    lw      t0, 0x2d90(at)          #   Current Action Data Pointer
    lbu     t2, 6(t1)               #   Load Defender's 0x06 flags
    andi    t2, t2, 0x20   
    bne     t2, zero, end           #   Branch to end if Defender is a Monster

    li      t4, 0x1a
    li      t5, 0x80
    li      t6, 0

    addu    t2, t1, t4
    lbu     t3, 0(t2)
    li      t2, 0xff
    beq     t3, t2, loop_bottom
    or      t6, t6, t5
    addiu   t4, t4, 1
    sltiu   t2, t4, 0x21
    bne     t2, zero, loop_top
    srl     t5, t5, 1
    sb      t6, 0x19(t0)
    lhu     t3, 0x38d6(at)          #   Load ability used
    li      t2, 0x73
    bne     t3, t2, break_item      #   Branch if not Great Heist (Thief)
    li      t2, 0x10                #   Special flag -Steal-
    sh      t2, 0x10(t0)            #   Store as steal item

    li      t2, 4                   #   Special flag -Break-     
    sh      t2, 0x10(t0)            #   Store as break item   

    jr      ra   

Help! / Re: Transforming Algus and disappearing Ramza
« on: August 14, 2018, 05:30:10 PM »
I believe this sort of thing can happen if a unit is supposed to appear as a Guest in a battle (e.g. Algus in Sweegy Woods) and uses the Load Formation flag, but isn't in your party as a guest.  The unit's data instead just gets a bunch of zeroes loaded into it.  That includes the unit's party index.  A party index of zero means your first unit... Ramza.  That makes the game think this unit's data should overwrite Ramza's data at the end of the battle.  And with zero brave, well...

Hmm.... I think the patch could be adapted to do something like that.  The main difference is probably having to keep track of which scenario is the "current" one... but it also makes me think there could be multiple button combinations.

(Base button combination): Play the current event
(Base button combination) + Left: Go to previous event (roll around to the end if already at the first?)
(Base button combination) + Right: Go to next event (roll around to the start if already at the last?)

Or maybe different button combinations based on which event you want to play? (First, second, third, etc.)

Things can get weird if you keep repeatedly running the same event though (without reloading). When I was still developing the patch, I had a bug where it would always play the intro event instead of the victory event, and after that happened enough times, things became... interesting to say the least :D

Haha, yeah... I think it's a cleaner way to just win a battle without having to create uber Wish or what have you.

It finishes the battle by running the (first) victory event.  It also makes the game think all enemies are defeated (to make it work with random battles).

I've finally updated this to include my latest ASMs, some of which were around already but not included here, and a bunch of others that are new, including a variety of things that I had been tinkering around with for a while...

Fix Reraise Graphic Width
The graphic width for the Reraise status text is slightly too short; this patch fixes that.

Start button skips events, effects, battle and event text, etc.

Speed shortens ability CT
This one uses a curve where CT is affected more at lower speeds, and the effect depends on the CT factor you choose (default 5).  With CT Factor = 5, it begins taking effect at Speed = 5 and ability CT halves by Speed = 10, and would quarter by Speed = 20. 
Basically, for any ability, the CT is affected by a multiplier where ((CT Multiplier) = (CT Factor) / Speed).

Geomancy single ability
A single ability for geomancy, having the appropriate effect based on terrain.  Ability ID can be specified; default is 0x7E (Pitfall)

JP scroll glitch actual fix (Disable paging on confirm menu)
This patch disables paging up or down while the confirm menu is up on the ability learn screen.  As a result, there is no way to do the JP scroll glitch.

Unit slots backfilled when unit is removed from party
Removing a unit from the party no longer leaves a gap in the party!

Speed up text crawls
Speeds up text crawls significantly.
Text delays longer than a certain amount are changed to that amount.  Default is 2.  Lower is faster.

Switch unit number with L1 and R1 buttons (formation)
Switch unit number with L1 and R1 buttons in the formation screen.  Changes unit order as appropriate.  L1 and R1 still work normally (switching the selected unit) in menus.

Press buttons to win!
Press a button combination (default L1 + Select) to win the current battle.  It needs to be done while the game is processing the battle event conditionals, so between turns, or between a unit moving and acting, or somesuch.  Works even in Bethla Sluice.

Load Formation ignored if unit not in party
Doesn't try to load a unit from the party from the ENTD (Load Formation flag set) if they're not in the party, and instead uses whatever data is in the ENTD for that unit.  You won't normally encounter this scenario, but if it were to happen in the normal game, it would create a messed up unit that would overwrite Ramza when the battle/event was over.

Break out of multi-battle sequences
Break out of multi-battle sequences by pressing a button combination directly after exiting the formation screen.  Default is L1 + R1.
Includes the "Load Formation ignored if unit not in party" patch, because that situation can occur if breaking out of a sequence where a Guest has already left the party.

Equipment duplication glitch fixes
Fixes the equipment duplication glitches that can be triggered from using Best Fit in the shops.

Level down fix
Fixes leveling down to subtract raw stats based on old level instead of new level, so it should subtract the same amount gained in the previous level.  Also fixes level up abilities so that they add the same amount as leveling up via experience gain.

Crits always deal bonus damage
Crit XA bonus minimum is 1 instead of 0.  Maximum is still XA - 1.

Always crit
Always get a critical hit.  Can be useful if you're testing crits or somesuch.

Yeah, battle.bin.

That routine is an inner routine for this one, also in battle.bin:
The data is loaded into SCUS RAM from this code in attack.out:

I recently went through the code that handles ATTACK.OUT battle event conditionals and made a reference for all of the conditional commands contained therein... and there were quite a few more than I've seen documented anywhere, and some were a bit different than how they'd been described before.

Some of these are well known and others less so!  I added a table to the Wiki page here for the ATTACK.OUT conditionals since the table didn't seem to fit very well as a post.

I'm releasing a new version of this patch to fix the reported issues and more!  I've updated the attachment on the original post to the new version.  Thanks to johnmyster and White Knight Wiegraf for reporting the issues they found.  To use the new version, download the attached file and unzip it into the XmlPatches directory within the FFTorgASM base directory and apply the patch.

Unit movement:

* Fixed issues with skipping unit movement where the code would (sometimes repeatedly) move a unit inappropriately, even when it calculated that there were no more tiles to move.  This could cause units to go off the map, into other units, etc., and cause all sorts of weird behavior/crashes. (I had a hard time reproducing this one until I realized it happened a lot when moving into the water!  It could also move you one tile too far if you pressed the button on the perfect frame.)
* Fixed an issue where skipping unit movement didn't take jumping over gaps into account and could move a unit to the wrong location.

Pre-battle events:

* Fixed various concurrency issues by giving control to other threads more often.  This fixes the Fort Zeakden enemy formation and pre-Velius event where your party wasn't showing up.
* Fixed an issue where the WaitValue command could get stuck waiting on text characters to show up that had already been skipped (Riovanes Castle rooftop post-battle).
* Fixed an issue where the camera would be incorrect that could occur after making a dialog choice, causing weird rotations to happen in battle.  Notably happened in Araguay Woods.
* Units should no longer weirdly slow down during the dark screen before battle start (Now running the EventSpeed instruction).
* Skipping an event while the camera is moving should cause the camera to quickly snap to its destination.
* In general, events should look mostly natural (albeit fast-forwarded) even when skipped, as more relevant commands are run (including EVTCHR animations).

Help! / Re: Trying to figure out an asm formula
« on: April 14, 2018, 11:00:26 PM »
The 0x prefix designates a hexadecimal (base 16) number.  Place value is based on 16, not 10.  0x10 = 16 * 1 + 0 = 16.
Each number is double the previous, and represents a different bit inside the status byte.

PSX FFT Hacking / Re: Soldier Office Upgrade
« on: April 14, 2018, 10:53:10 PM »
As an aside, if you want to get rid of the warning in FFTorgASM, you can add mode="DATA" to the relevant <Section> tag in the XML.

Help! / Re: Seeking clarification on some ASMhacks (Mostly AFAE)
« on: April 06, 2018, 08:50:32 PM »
Some of the confusion might be caused by having old versions of some hacks.  The newer versions should be included in the latest version of the FFTPatcher suite here.

For some more detail about some of my hacks, there is also the thread here.

On the All Formulas Apply Elemental hack: By default, there a lot of ability formulas that either don't check element or only look at the weapon element when they should take the ability's element into account, with the Holy Sword and Dark Sword skill sets being obvious examples, but there are many others (it's not the Weapon Strike flag, it's the formula code itself). This hack disables the normal element checks and then forces element to be taken into account by every ability after the ability's formula code has already run.

The way I originally designed the damage and healing multiplier hacks, they were dependent on the All Formulas Apply Elemental hack (using the same strategy of applying after the formula code was already run), but I didn't like having that kind of dependency, so I just absorbed these as an optional component into the All Formulas Apply Elemental hack.

Regarding the hack to make formula 44 use HP instead of MP, it was just a simple example of an ASM hack I used in this thread.

For X% chance of procs, a lot of abilities that can proc statuses (like Geomancy or Holy Sword abilities, for example) by default use the same chance to proc: 19%.

PSX FFT Hacking / Re: ASM Requests
« on: June 11, 2017, 01:25:57 AM »
I also created a hack for this when I was playing around with the same concept.  This one uses a curve where CT is affected more at lower speeds, and the effect depends on the CT factor you choose (default 5).  With CT Factor = 5, it begins taking effect at Speed = 5 and ability CT halves by Speed = 10, and would quarter by Speed = 20. 

Basically, for any ability, the CT is affected by a multiplier where ((CT Multiplier) = (CT Factor) / Speed).

Help! / Re: FFT Vanilla NO DIALOG/ NO Cutscene patch?
« on: May 30, 2017, 08:27:12 PM »
You're welcome, and glad to hear it!  A lot of games allow cutscenes to be skipped with Start, and that's what I made the patch to do.  And yeah, you can skip summons, meteors, and any other effect.

Help! / Re: FFT Vanilla NO DIALOG/ NO Cutscene patch?
« on: May 29, 2017, 05:27:48 PM »
Yeah, I was about to post a link to that hack.  I designed it for the express purpose of skipping cutscenes (and more!) with the start button!

Hacking/Patching Tools / Re: FFT Patcher .478 Source Code
« on: April 25, 2017, 03:45:40 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.

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.

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.

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).

PSX FFT Hacking / Re: "Quadratic" Ability Formulas
« on: April 21, 2017, 06:24:42 PM »
Eh? Those formulas are indeed quadratic.

A quadratic expression is a polynomial involving a squared term (and no higher exponent). That's actually a correct way to describe these formulas, since they do include an X squared term if you multiply them out. Using Truth as an example, each graph would be a parabola (and bottom out at MA=0) (they would bottom out at different points, generally the MA addend divided by -2) if you graphed the formulas out on, say, a graphing calculator (where MA would be the X-axis and would span negative to positive MA), but since you can't have negative MA, we don't normally worry about the negative MA part of the graph. Nonetheless, those formulas are quadratic (and not exponential - exponential means the exponent itself is the variable; something like 2^MA, which would start slow but grow to insane levels extremely fast).

Help! / Re: [asm] Can this triangular rand function be more concise?
« on: March 22, 2017, 04:36:23 PM »
Okay, I see what's going on with the bit shift.  I just didn't see that in the original formula, but it would make sense to do that so the result is in the range you want.

Technically the stack pointer offsets are supposed to be multiples of 8 (thus 16 instead of 12), although I can't exactly remember why.  Something to do with exception handling, if memory serves.

Overall, it looks good, except you shouldn't add to the stack pointer until after you're done popping, i.e. it should be like this:

Code: [Select]
    pop x
    pop $ra
    stack += 16

Help! / Re: [asm] Can this triangular rand function be more concise?
« on: March 10, 2017, 03:09:45 PM »
I tried writing this as an ASM routine and I had it at 18 lines. I ended up with something very similar to what you have here, but there are a few things missing from the pseudocode:

You need to push the return address ($ra) before calling rand(), and pop it sometime after the last subroutine call, otherwise your routine will crash.  That adds 2 more lines, and also changes the stack offset to be 16 instead of 8. (Also, it should be -16 at the top, +16 at the bottom, not -16 in both spots.)

I also couldn't find a statement in your code moving the multiplication result out of LO (the ASM command for this would be mflo).  I may actually be misunderstanding this entire part:

Code: [Select]
LO, HI = x * n
r2 = x >> 0x10

The first line calculates x * n, but that result is never used and instead r2 is set to the high 16 bits of x?  Also, is the division by 2 accounted for somewhere?

Help! / Re: Elemental ability/Masshex weirdness
« on: March 01, 2017, 06:06:02 PM »
A bit late to the party here, but this was caused by a bad lbu statement in your input (offset too high: 0xe618; maximum is 0x7fff). I discussed the specifics in the MassHex thread here.

The issue here is that 0xe618 isn't a valid value for the offset in your lbu statement.  The valid offset values go from -0x8000 to 0x7fff.

Since you specified a value outside that range, MassHex is trying to expand your lbu statement into a series of multiple statements to still get the proper result, assuming you want a positive 0xe618 as your offset. The method it's using here would normally work, except that you're using the assembler temporary register (r1) as the base register for your load, and MassHex needs that register to do the expansion, so the result is messed up.  Regardless, looking at what you're doing, this is unnecessarily complicated anyhow.

I suspect, based on the input you're giving MassHex, that you're looking to load a byte into r4 from RAM address (0x8016e618 + r2).  You could actually tell MassHex to do that with the following statement:

lbu r4, 0x8016e618(r2)

You'll notice that will expand into:

lui r1,0x8017
addu r1,r1,r2
lbu r4,-0x19e8(r1)

Which is probably the input you're looking for.

Pages: [1] 2 3 ... 24