JamRules wrote: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.

JamRules wrote: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.)

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.

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

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 patternITM{aa}{bbb}{cc}{d}.EDAT

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

Last edited by JamRules on Sun May 29, 2016 12:10 pm, edited 1 time in total.

JamRules wrote: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.

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.

Agrajag wrote: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.

Agrajag wrote: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

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