Another exploratory discussion: FFTA job progression.

[Vanya]

What do you guys think of a hack that would overhaul the way jobs are unlocked?
Making it like FFTA/2 where jobs are unlocked based on the number of learned skills instead of by job level.
It would probably also be a gargantuan task, but the potential benefit would be the freeing up of the Job level bytes for use as something else.
Extra job slot(s) maybe?
Thoughts?

[Kaijyuu]

Well, assuming there's still spillover JP, I don't see how it's any different than how it is now. Except for, of course, requiring the player to go into the menu and learn some skills they don't care about.

If there's one thing I'd change it's (guess what) spillover JP. I really think people should have to spend time as a job before gaining levels in it. The obvious consequence of that is more grinding if one wants to be a particular job, though.

[Pickle Girl Fanboy]

You're thinking of RAD's 35 Jobs, aren't you Vanya?

[Pride]

Well, assuming there's still spillover JP, I don't see how it's any different than how it is now. Except for, of course, requiring the player to go into the menu and learn some skills they don't care about.

If there's one thing I'd change it's (guess what) spillover JP. I really think people should have to spend time as a job before gaining levels in it. The obvious consequence of that is more grinding if one wants to be a particular job, though.

There's an asm in my thread to remove spill over jp

[pokeytax]

This proposal has two parts: changing job progression to work from learned skills instead of job level, and freeing up the job level bytes for another purpose. The former just takes some elective surgery on RAD, the latter is hard (rewriting every single instance where these bytes are read or written).

I spent a lot of time thinking about how to clear out unit data for RAD jobs. I think the best way would be to compress JP totals, because those take up 80 bytes (job levels are only ten bytes). If you scrap total JP and back into it from available JP, that frees up 40 bytes. If you capped available JP at 4000 and did some painful maneuvering to store it in 1.5 bytes apiece, that frees up 50 bytes. However, none of this is any fun at all.

[RavenOfRazgriz]

Even if you freed up all that space, Pokeytax, what the fuck would you do with it?

As far as Vanya's suggestion goes, it doesn't mean anything to how the game progresses outside of forcing investment into the primary skillset and probably fucking up AI Job Progression.  10 bytes doesn't seem like you could do fuck all of relevance with, and you'd need to compensate for any and all space used up by RAD that wasn't already in-use originally in the process to make it worthwhile.  Scrapping Spillover JP either way frees up some routine space, but that's in a completely different area and probably not as useful.

I think the big question is - what the fuck are we going to do with any space we free up this way?  RAD covers more Jobs already, so unless cramming things down heavily and rerouting things this way allows us to write RAD into a far smaller space, this angle is basically useless.  ...So what the fuck would we do with it?

[Kaijyuu]

My impression was this was a brainstorming thread for doing interesting things with the job progression, not just a technical discussion on freeing space/etc.

So to answer your question about "what the fuck would we do with it," well, that question is the point of the thread.

[pokeytax]

Even if you freed up all that space, Pokeytax, what the fuck would you do with it?

Permanent unit attributes (e.g. adding eight RAD job slots with distinct JP/learned abilities, indistinguishable from base jobs). But, it's a lot of work for incremental benefit.

[Vanya]

@Pickle: Yes, I was staring down RAD when I made this thread.

@Pokeytax: I figured it would be a lot of work. Basically every time the game references job level would have to be changed to a comparison for a specific value in learned skills, right? I was drawing up a new job tree that included RAD jobs, but I noticed the core problem with using RAD to combine vanilla jobs is that they then lose their individuality in terms of unlocking further jobs. Personally I think having 8 RAD jobs with their own JP/learned abilities would be pure win, but I conceed that the work involved could induce a "Call of Ctulhu"-like insanity in the poor ASMer that would tackle this head on.

[Pickle Girl Fanboy]

Wouldn't FDCs hack free up a bunch of space?  And have you figured out where the game determines where it keeps track of all the JP data?  Couldn't you just reroute all of it - or just the extra jobs - to Kanji Space?  If not, then could you work on optimizing a good enough chunk of the game to create free space, while retaining everything that currently exists?

[Kaijyuu]

Hrm, out of curiosity...

My ASM experience is with super nintendo games, and they rarely ever use all the available ram space. Does the PS1 have really crappy ram space or something?

[Pickle Girl Fanboy]

Totally forgot about that - it needs room in the RAM.  IIRC, Pokeytax and Xifanie both said there isn't a lot of room left.

[pokeytax]

There seems to be some confusion between different kinds of free space (which is understandable because it's confusing).

There are different free spaces. Space is valuable based on how accessible it is in the existing code.

For example, if you edit the ENTD so that Gafgarion never joins the party, his formation sprite is now freespace. It's set up for graphical loading, so it's formation sprite freespace. You don't want code there.

The kanji table in BATTLE.BIN/WORLD.BIN is valuable freespace because it's unused, it's large, and it's always accessible from battle or formation screens. However, it's most useful for code. If I try to save JP data there during battle, what will happen after battle? That JP data will be overwritten when WORLD.BIN is read into RAM. In order to save JP data, I need to put it in a part of RAM that persists after battle - and in order to save it forever, I need to put it somewhere that persists after saving and reloading the game file.

The freespace that compressing JP data would clear is in saved unit data. So while 40 bytes seems trivial because it's only 10 lines of assembly code, this data is already set up to load and save with units. You could use one byte, for instance, to save a unit's permakills and implement the WotL Dark Knight requirement; six bytes to represent a unit's permanent STR/DEX/INT/WIS/CON/CHA; two bytes to save a unit's four favorite foods randomly determined at generation; one byte to save a unit's current weapon enchantment. Or just put more job data back in there.

Of course all of those things would require coding, but they are possible with space in unit data.

There might be some unused space already, but this space you could confidently use without fearing a crash someday which would be nice.

I was drawing up a new job tree that included RAD jobs, but I noticed the core problem with using RAD to combine vanilla jobs is that they then lose their individuality in terms of unlocking further jobs.

That's an interesting point. A learned ability requirement allows you to use RAD jobs as prerequisites. I should probably add that in a future draft, then.

My ASM experience is with super nintendo games, and they rarely ever use all the available ram space. Does the PS1 have really crappy ram space or something?

It has 2 MB main RAM, which isn't much, but then the SNES has 128 kB. But we are not very good at loading memory files. FFT is also not tightly optimized for space - it was coded in C so it takes up more room than necessary.

It would be very nice to create free space by expanding some files and altering the way the game loads files but that's much trickier stuff than simple ASM hacking.

[Pickle Girl Fanboy]

You could use one byte, for instance, to save a unit's permakills and implement the WotL Dark Knight requirement; six bytes to represent a unit's permanent STR/DEX/INT/WIS/CON/CHA; two bytes to save a unit's four favorite foods randomly determined at generation; one byte to save a unit's current weapon enchantment. Or just put more job data back in there.

Could you possibly optimize character data, to fit the existing data into a smaller space?  I'm sure there are full bytes used to represent something which can only be 1 or 0 in there somewhere.

[pokeytax]

Could you possibly optimize character data, to fit the existing data into a smaller space?  I'm sure there are full bytes used to represent something which can only be 1 or 0 in there somewhere.

Sure. It would be a lot of work though.

[Vanya]

Sure. It would be a lot of work though.

True, but that would go a long way on the road to expanding the job tree. Plus you would be loved by the community forever. [/suck up]

[Pickle Girl Fanboy]

Sure. It would be a lot of work though.

I think this is part of FDC's asm optimization project.  If it isn't, it should be.