Total Request ASM: All armor replaced by shoes

[Timbo]

Oops. I totally forgot to mention that very necessary step. I thought the No Spillover JP hack is included in the ASM for the most recent FFTPatcher.

[Edrin]

Ok found the spillover asm, thx.

Next on the list: I need to control who is affected by Golem. Currently it always applies to all allies, regardless of target. I need it to only affect targeted units. And, if possible, be able to set up multiple instances of Golem.

[RavenOfRazgriz]

You're... not going to be getting that to happen without rewriting the entire Golem routine.  Hate to break it to you.  Not to mention that one instance of Golem already breaks the AI, god knows how bad it'd get with multiples.

[MysticKnightFF5]

Life as we know it will come to a neutral halt and be filled with nothingness... and golem.

[pokeytax]

Bump.  (I am running out of Suikoden translation to do, so I'm looking over some old hacks.  You can post bug reports or new requests here - this thread is essentially starting again from scratch.  As always, no guarantees - I'm not as terrible at coding as I used to be, but I have less time too, and I've forgotten everything about FFT.)

[Celdia]

You can post bug reports or new requests here - this thread is essentially starting again from scratch.

So no chance of getting some small things in ALMA 4 tweaked then?

[Neophyte Ronin]

Maybe I'm imagining things, but isn't there a Hack that multiplies experience gains by zero so it does not increase Level?

Reasoning:

Set all characters to 50+original variance.  Their current Exp and Lv never change.  Dismiss instances of Degenerator (or retool them to perform another effect).  Any instance of Level Increase/Reduction ability is altered.  Equipment appears piss-poor, but can be altered so that some have qualities that others lack, so you now have a wider selection instead of things that get outdated by level.

Alternative: have equipment values improve by the level of characters equipping them.  One man's Aegis Shield is different from another man's Aegis Shield by virtue of level.  One man's broadsword is superior to another man's rune blade by virtue of level.  How that can be achieved will probably cause a sane programmer a heart attack.  I prefer the former.

[RavenOfRazgriz]

There is a hack that allows you to hardcode the Experience gained from an Action to a specific value, which could be made 0, but the display for how much Experience is gained doesn't function properly.

I don't think you even begin to understand the rabbit hole you're getting into trying to make most/all equipment "usable".

[pokeytax]

So no chance of getting some small things in ALMA 4 tweaked then?

That is precisely what this thread is for!  Starting from scratch just means that my to-do list has zero things on it right now, because I don't know what needs doing most, and you probably do.

Maybe I'm imagining things, but isn't there a Hack that multiplies experience gains by zero so it does not increase Level?

Well, you could just use the hack that zeroes stat growths.  That's pretty close.  Or use ALMA to make Gained EXP Up into Gained EXP = 0 and then give it to everyone.

I don't think you even begin to understand the rabbit hole you're getting into trying to make most/all equipment "usable".

Yeah, while this sounds tempting, and vanilla FFT goes too far the other way by having only a few viable equips at many points, what you end up with in practice is often someone using the same equipment all game because it's already optimal.  Raven is right.

[Pride]

My ASM thread has the experience edit (there are display issues though that i have yet to fix #asmcleanup2020) and to prevent level up is in Xifs if i remember correctly. Or Razele's thread.

[Choto]

I would cast a vote on the side of ALMA or RAD revision. I remember always having trouble with RADster

[Celdia]

That is precisely what this thread is for!  Starting from scratch just means that my to-do list has zero things on it right now, because I don't know what needs doing most, and you probably do.

Raven could probably point out more things than me since he pays more attention but I think my only current issue with ALMA 4 is how when a unit that has used a skill like Accumulate to boost their PA levels up in battle their stats reset back to pre-Accumulate values [which I assume are just the proper values for the unit at their new level.] A fix so it would have it keep the boosted value after the level up is calculated would be most helpful. ...and if there is a way to change the sheet without me having to re-input pages and pages of data into a new spreadsheet, that would be phenomenal. >_>

[3lric]

I know that certain ASMs such as ALMA or RAD3 have the load delay that makes you unable to play on console or PSP. A fix for those would be great.

I know there was also a gameflow editor issue that effects sidequests? (Eternal experienced this)

Pride has also found a lot of new stuff concerning the worldmap commands that could be added to Gameflow Editor as well.

[pokeytax]

i know that certain asms such as alma or rad have the load delay that makes you unable to play on console or psp. a fix for those would b great.

Can anyone confirm these?  I ask only because I think I investigated a couple reports like this and they turned out to be other hacks.  (I'm not saying it didn't happen - lord knows RAD, especially, needs a lot of work.  But a clear reported case would help a lot.)

Celdia, if you send me your current ALMA 4 spreadsheet I'll make sure it's transferred.

Thanks for the notes.  I'm also looking at knocking out some of the hardcoding FFT does (e.g. having whether an item is a shield, hat, armor, or accessory be determined by FFTPatcher, not its item number; having the "Action Menus" tab in FFTPatcher actually do what you would expect it to without the Generic Skillset Hack).

[Choto]

Keep in mind that there's loads of new routines up on the new-and-improved wiki. Any routines that are red mean I have them in my working file. I can post it when I get home. No sense in documenting stuff that's already done.

[pokeytax]

Keep in mind that there's loads of new routines up on the new-and-improved wiki. Any routines that are red mean I have them in my working file. I can post it when I get home. No sense in documenting stuff that's already done.

Yeah, I've seen the page - it's very nice.  I'll try to add to it as I go.

[Celdia]

Celdia, if you send me your current ALMA 4 spreadsheet I'll make sure it's transferred.

I'll PM you a dropbox link for it

[Choto]

At first glance, ALMA 4 and RAD 3 seems to be coded correctly with load delay. I literally just skimmed over a couple parts so that's not to say there isn't a bug somewhere hiding. I think in the ARH we found load commands being used in the branch delay slot and then using the value at the branch location.

This problem with the console crashing must be something different than load delay. My microprocessors professor said dividing by 0 may cause it to crash as well, so that's the next thing to check. I'm not sure what else could cause it to crash but there must be something. The dult/div and mfhi/mflo process has a delay stipulation too.

[Glain]

I ran into another one when working on one of my elemental hacks and it was being tested on an EBOOT (and maybe we should put this in the coding standards sticky)...

The memory is aligned so that words (4-byte blocks) always begin at memory locations divisible by 4 (ending in 0x0, 0x4, 0x8, 0xC) and half-words (2-byte blocks) are always at memory locations divisible by 2 (even).

Say you have this:

Code Select Expand


lui r4, 0x8019
lw  r4, 0x2d93(r4)


You're loading a word from 0x80192d93... which is not divisible by 4, and that's illegal based on where words have to be aligned (memory addresses that are multiples of 4).  Apparently this freezes on an actual PSP EBOOT.  From my experience, both ePSXe and pSX will cheerfully do it without complaint.

Same idea with something like this:

Code Select Expand


lui r4, 0x8005
lhu r4, 0x9041(r4)


As you can't load a halfword from an odd memory address.

This seems to apply to the store instructions too.

For reference, here's where I discover/post about it:
http://ffhacktics.com/smf/index.php?topic=8351.40#msg168560

Here's another example of someone getting this error (simulator).  This seems to confirm it affects sh/sw too.
http://stackoverflow.com/questions/9830892/mars-mips-store-address-not-aligned-on-word-boundary

EDIT - I'm not sure if loading in a branch delay slot and then using the value at the branch location is actually an error (as the actual branch happens between the load and the fetch of the register value).  Does anyone know for sure?  I know sometimes parameters for subroutines will be loaded in the branch delay slot of a jal, for example.

[pokeytax]

I was definitely aware of load delay, branch delay, load alignment, and mflo/mfhi pipelining.  All of my hacks target pSX, which seems stricter than ePSXe and has the handy debugger.

Hmmm... some of you may remember me whining about bizarre errors I got when writing ALMA that triggered in pSX, but not ePSXe, and only in runtime, not in stepthrough.  Just terrible stuff where a section would crash after 3 nops but not after 5 nops, and LOAD instructions in branch delay slots caused problems even when the results weren't being used at the destination.  (e.g. http://ffhacktics.com/smf/index.php?topic=6664.180#msg151469)  The most rational explanation is still that I screwed up somehow, but I checked every line of my code enough times to be sure that it wasn't an ASM 101 mistake.  Maybe I was simply cramming so many instructions in that it introduced inconsistency into the game loop?  Does that even make sense?  In any case, if there's a root cause to this I did not address, that could be creating problems on physical systems.

Anyway, I'm curious enough to test ALMA and RAD on a physical PSX myself and see if it works.