PSP2i modding

[JamRules]

Ignore the window border, I somehow managed to... break the printscreen key...

Scratch visual effect units off the "only one can be allowed at a time" list. I'm actually kinda surprised the game lets you do that without freaking out...

(Those are the effects from Ghost Ring (PSU)/Heavenly Ring (PSP2), Infinite Guardian (PSU)/Yellowboze Wing (PSP2i), Celebrity Aura (PSP2), and Fighting Lord (PSU)/Boost Aura III (PSP2i), for reference.)

I never gave it much thought before but that's a great idea, it's nice to have the choice and it looks excellent with multiple effects.
Probably some fun to be had trying the different combinations.

After seeing your example I just had to try it myself for PSP2i, thanks for the inspiration

[JamRules]

I never gave it much thought before but that's a great idea, it's nice to have the choice and it looks excellent with multiple effects.
Probably some fun to be had trying the different combinations.

After seeing your example I just had to try it myself for PSP2i, thanks for the inspiration

*snip*

That's pretty cool! Kinda suspected it'd be easier in PSP2/i given the whole "any unit can be in any slot" thing was already there, but there's a big gap between "theoretically possible" and "actually done".

Generally, I'm too lazy to try to add a mutual exclusion thing for units, so assuming the freeform unit thing gets done ("very likely", not "guaranteed"), you should be able to have a bunch of cool-looking combinations and a few... err... not-so-good ones (generally anything with multiple sets of wings).

(Note: I'd try to make the supplemental outfits into 3-part ones, but they're awful in that regard. We're talking "The jacket has the torso, right arm, right hand, and left arm, while the pants include the left hand, both legs, and the left foot" level bad. "Clothes that clip significantly" are a little past my limit, so "outfits that cause arms and legs to disappear" is well past it.)

Yeah, as you pointed out it wasn't so bad as everything just worked when the unit was put into the slot,
the only thing that needed changing was the way it filters the units you can select from when setting them.

From the little I looked into it the textures are bit crazy too, since they can support the different palette swaps it seems they're put together from loads of textures which at run time share the same CLUT (even though they're stored with individual ones).
Also found it funny there are multiple sets of textures for the same costumes, ones for out in the field and separate ones for the changing room/screen.

Extra outfits would be pretty cool though, guessing this could be easier for Infinity since the DLC system could possibly be leveraged to add the new items.

[Agrajag]

From the little I looked into it the textures are bit crazy too, since they can support the different palette swaps it seems they're put together from loads of textures which at run time share the same CLUT (even though they're stored with individual ones).
Also found it funny there are multiple sets of textures for the same costumes, ones for out in the field and separate ones for the changing room/screen.

Extra outfits would be pretty cool though, guessing this could be easier for Infinity since the DLC system could possibly be leveraged to add the new items.

PSU has that weird "two copies of every outfit" thing going on, too, fairly unsurprisingly given the shared codebase. It may have been a PS2 optimization thing...?

Your description is accurate for how clothes/etc work. Assuming they didn't get completely reworked (a few parts did), essentially, there's one big (palettized) texture that's used for "a character", where each part of the character contributes a part of the texture and a part of the palette; changing your skin color will change one particular range, etc. I may have notes (just kidding, I never keep notes; I remember a fair bit, though), I can chase them down if you're interested.

One of the future things I'd maybe take a look at is how the DLC system works; I've seen one of the weapon files (thanks to our mutual friend shade), and in theory I have an idea on how to add missions (I mean, it should just be a matter of putting the mission files in the right place and updating the DLC counter for them, right?), but the gap between "in theory" and "in practice" is... you know.

(Adding actual new weapons/costumes in PSP2i would require figuring out the model formats, and those are not the same as the PSU ones I've been looking at.)

[JamRules]

I think your probably right about it being for optimisation purposes, Infinity seems to have a lot of repeated files, especially in missions where it seems that some resources needed for a mission are just added again to the related .nbl/.pac so that it can be loaded in one go.

Similar here, I don't really have any proper notes either.
Any notes you can provide for any aspect of the game would be great.

Shame the models are different, I suppose they have been optimised to match the psp.
On the plus side the textures are hopefully the same and the DLC archives use the same formats as the original files (.pac and .nbl).
Though figuring out how to get the game to recognise completely new files as valid may be difficult.
I looked at the DLC briefly and was able to modify an existing DLC item to change the related text to English but that's about it.

[Agrajag]

When I saw the weapon archive, a couple things stood out:
1. NBL old format. This makes me happy; I can deal with the old format (pretty well, at this point!).
2. Most of the data's fairly unsurprising. Model (unj), bone names (una), texture filename lists (unt), visual effect (dat), a filelist (_filelist.rel), and some textures (uvr).
3. The rest of the data, though...
.bin files: text data (description); you saw these, you know.
.unr files: these are... a mixed bag. xnr/unr is the generic data file, you can't predict what it is without knowing what file you're looking at.

Couldn't really make heads or tails of the actual stat data (think they obscured it somehow; they did not approve of people ripping item data out of the game, so each one made it harder to get that...), would need more to be able to figure it out.


A while back, I did look at the PSP1 mission DLC. It was just a bunch of mission files (same as PSU uses, just with the filenames adjusted to match the PSP games) and a counter that would include them...

[JamRules]

It's not too bad to break the DLC apart but I actually haven't worked out the .pac file encryption yet so I wouldn't be able to modify the file sizes in the header if the .nbl contents were bigger than before.

Haven't looked at the stats yet but I've been investigating the naming conventions for the files, here's what I've got so far.

The files seem to be named with the following pattern
ITM{aa}{bbb}{cc}{d}.EDAT

aa – Sub-Type (list below)
bbb – unique id
cc – Type (01=weapons,08=visual units,09=costumes – with colour palette display,10=costumes,11=room items)
d – manufacturer (only for weapons, 0 otherwise) – 0=GRM, 1=Yohmei, 2=Tenora, 3=Kubara

aa

If cc = 01 (weapons)
01 - long sword
02 - knunkle
03 - spear
04 - double saber
05 - axe
06 – twin swords
07 - twin dagger
08 - twin claws
09 - single handed sword
10 - single claw
14 – rifle
15 – shotgun
16 – bow
17 – grenade launcher
18 – cannon
20 – handgun
21 – crossbow
23 – machine gun
24 - staff
25 - wand
26 – mag unit
28 - shield

If cc = 08 (visual units)
04 – always seems to be this
If cc = 09 (Costumes – with colour palette display)
06 – always seems to be this
If cc = 10 (Costumes)
06 – always seems to be this
If cc = 11 (Room Items)
05 – always seems to be this

itm{aa}{bbb}{cc}{d}.unr holds the related values for aa,bbb,cc and d internally so an existing DLC could possibly be updated with a new unique id and the files renamed - I'll have to try it. If it works it would allow a new DLC item to be produced that could then be distributed without the need to replace the original official DLC, the next step would be to update the stats and model (renaming the weapon and updating the description is easy)

Edit: Proof of concept, I created a test separate English version of ITM01015010.EDAT as ITM01255010.EDAT





I was able to import both versions, add them to my inventory and it didn't seem to fall over in battle

[Agrajag]

The naming convention's going to be something similar to the item IDs you'd use to edit your inventory, just in decimal. It's also pretty close to the model filename.

To borrow the equivalent on PSU:
011B0603 Sonichi (model filename: IW_27_4_07.nbl; note that item numbers start at 0, but models start at 1)

That's category 01 ("weapon"), subcategory 27 ("Shadoog/RCSM/R-Mag"), index 06, brand 3 ("kubara").

It's not too bad to break the DLC apart but I actually haven't worked out the .pac file encryption yet so I wouldn't be able to modify the file sizes in the header if the .nbl contents were bigger than before.

scriptkiddie's actually looking at that right now, seems to be mostly there.

cc – Type (01=weapons,08=visual units,09=costumes – with colour palette display,10=costumes,11=room items)
d – manufacturer (only for weapons, 0 otherwise) – 0=GRM, 1=Yohmei, 2=Tenora, 3=Kubara

09 is probably costumes, 10 is probably cast parts.

[JamRules]

Yeah, I haven't looked too much into the standard naming for the ids but I suspect that your probably right for Infinity too, or at least something similar will be used.

scriptkiddie's actually looking at that right now, seems to be mostly there.

I noticed him mention it was basic in the other thread, furthest I've got at the moment is that it looks like the 8 bytes from 0x8 in the header is the encryption key (or controls it). Hopefully he'll solve it.

09 is probably costumes, 10 is probably cast parts.

That makes more sense, was difficult for me to tell since the costume list doesn't say what type the costume and I don't know by name

[scriptkiddie]

Pac craps done...
Decrypt from 04-0f
Word at 4 = archive type (i think) or 2 bytes, cant remember
Word at 6 = nb_files (nbl & pac contained in the pac) Also used to get tbl_size
$10 -> xx = fileindexTbl similar to afs (used to generate pos & size)

Prs... Getting on my nerves, done initialise, bug in generate string_Tbl/dictionary somewhere probably one of the #%$!%#$ delay slots in the wrong place, decompress loop should be fine, so when i have the time & patience to bug hunt it should work

[JamRules]

Looks like you already know but from what I could tell the format for the pac header was

word - magic
Half-word - sector size type (0x0 = 0x800 byte sectors, 0x1 = 0x40 byte sectors)
Half-word - file count
word - set to null after decryption
word - set to null after decryption
Half-word * file count - starting sector for file

Possibly half-word for end sector, can't remember.

There may also be 0x40 of data after each .nbl, can't remember how this is handled for sector counts


Was the encryption something already existing or did you have to write something from the asm?