DiegoMM wrote:Looks really good. Normally as second img shows the class names comes after the name, why it is first(mastermonk sheela) in the first image? something to do with space?
I think its great that in battle and small windows still has abreviation, its a good use of space and remais some classic flavor :P
That's how it is in the original game, e.g., "MMNK SHEELA". I aimed to stay as close as possible to the original layout, but it's not a problem to swap the two strings positions should that be preferable. As for what's preferable, well, that's subjective so I'm open to suggestions.
By the way, there's a visual oddity that I've purposefully omitted in the above pictures.
In the characters listing window, "Pegasus Knight" is running out of space, so the "t" is being overwritten by the level... That's servicable as-is, but hardly looks good! A solution could be to kill the EXP reading and shift LV all the way to the right I guess, but I'm really not sure how
preferable that would be! In fact, "Pegasus Knight" is just being a pain in general. Damn you, "Pegasus Knight"!
Remuko wrote:I'm curious in one of those Sheela pics from the menus, it has the bit on the side that shows the map sprite, but it has a number 19 above her sprite. What's that about?
My bad. I took the picture while in debug mode (which is a feature of the original game, so unrelated to my work). Don't worry, it won't show up when playing normally.
--
So, I figure it's about time that I share my work on a much requested feature:
Character Expansion
You can finally play as your favorite character: Elis
Download link:
Latest patched disassembly
Features:
- Currently supports the two dummied out character slots, as I'm unsure whether we can easily repurpose superfluous enemy slots at this time.
- Basic functionalities in and out of battles have been tested; it seems to work fine!
- Saving/Loading works (although I didn't have to do anything; the engine already supported it. )
- Reworking of the portrait assignment routine for force members.
When I say basic functionalities, I mean common actions that we typically perform when playing SF. Off the top of my head:
- Out of battle:
- Stats generation (level-up to starting level at new game start)
- Recruitment/Appointment to the active force
- Transferring items
- Equipping weapons
- Resurrection
In-battle:
- Presence on the battlefield (normally, even if we manage to hack one of the dummied out characters into our active force, they couldn't participate in battle. In fact, they wouldn't seem to even exist at all!)
- Getting a turn
- Attacking an enemy
- Being targeted by enemy attacks
- Gaining EXP/Leveling up
- Stats being reset after battle
On the other hand, I didn't get to test some edge cases/hardcoded effect routines such as, say, Aura 4 targeting the whole force or Prism Flowers death ray of
doom moderate annoyance. Use at your own risk, and bug reports are welcomed!
As for "reworking of the portrait assignment routine for force members", we must know that the character index is normally used as the portrait index for force members. In vanilla SF2, we have the first 30 portraits which are reserved for our force immediately followed by Elis' and Astral's; this means that our new recruits are forced to use these two portraits by default. In addition, there are some further hardcoded shenanigans going on that override portrait index based on class (for those who get a new portrait upon promotion.) This poses a problem whenever we want to repurpose classes; all our ninja would belong to Slade!
In other words, the current system is hot garbage, so I wrote a routine that instead retrieves a portrait based on a character's map sprite, referencing a table that already exists (thanks to Earl for reminding me of it!)
Thankfully,
Wiz has recently released a nice tool that allows us to easily modify this data, so it shouldn't be too much trouble to set up your new characters. Basically, once you've defined a base map sprite in "disasm\data\stats\allies\allyspriteids.bin" (here's another beautifully hardcoded system, by the way), then you simply make sure that a portrait is linked to it in "disasm\data\spritedialogdefs.bin" using Wiz's SF2DialogPropertiesManager tool.
Let me know how it goes!