I'll have to get back to you after I figure out an efficient way to do this. I don't think that's going to be as easy as it sounds.

Actually, if you want to quote a price just for figuring out a good method to do this, I could probably pay that. I'm well aware that the initial scoping and planning is a significant part of any programming project.

Could I get a quote on adding support for merging identical textures?  I initially described the technique at http://forums.kc-mm.com/index.php?topic=67847.msg1316821#msg1316821.

What I'd like to see is, for groups of identical textures (identical except possibly for their palette, anyway), it puts them in a group, probably represented by having each one after the first being displayed as a child of the first, in the same tree structure BrawlBox uses throughout.

For simplicity, it'd be fine if the only action that can be taken on a merged group is to split them apart, so they can be edited normally.

To create groups, possibly have an option to look for identical items and merge them on the BRRES menu, and/or just automatically do it whenever a BRRES is saved.

For getting recolors to have identical image data except the palette I plan to make a separate program, so I'm not worried about that part. (A simpler use case would be to merge the five Random CSPs if they're all replaced with identical Ditto images.)

So I figured out a new technique for reducing the size of CSPs substantially, and it'd be nice if BrawlBox could be updated to support it.

It's desirable to store CSPs in CI8 format, but limitations on the compressed size of common5.pac make that impossible if there are too many characters and costumes.  However, many costumes are just recolors.  Since we want to store them in a format that separates the main image data and the palette, it'd be nice to store just one copy of the main image data and then a palette for each recolor.

In testing, I've found this is possible - each TEX0 does require its own header, in order to point to its name, but it is possible to put, for example, 9 TEX0 headers in a row, followed by their data, as long as each header has its length changed to include all the following headers.  (So with 9 the first has length 0x240, the second 0x200, and so on, until the last is just the standard 0x40.)

I've done a proof-of-concept test, available here. To see it, just import that BRRES over sc_selcharacter_en > char_bust_tex_lz77 > MiscData[17], and change the compression to ExtendedLZ77 (or just LZ77).  It's the Smash 3 textures for Mr. Game & Watch, but note that while they all share the same image data I did not rearrange the palettes so that would actually work well.

So there's obviously a lot of work to get this to a place where it's easy to use.  I'm wondering, in particular, what the interface in BrawlBox should be.  One possibility, for minimal support, is just having an option on a BRRES to compact it, where it just goes through and looks for identical textures and merges them if found, relying on other tools to create textures that will work with that.

More thorough support might be having an option to import multiple images at once, ideally including doing the quantization with all of them together, to make image data that works as well as possible with each of the palettes.  Not sure how the UI would work for that, though.

My current plan is to work on some simple tools in Ruby for doing much of this (as I find that more enjoyable to work in, particularly when experimenting on things).  As I've been looking into quantization algorithms, I'm hoping to at some point add another algorithm to BrawlBox, whether or not it includes support for multiple images at once.

Thanks a bunch, i thought i had fixed this same thing at one point but i must have forgotten. I went ahead and merged it. I'll look into a more precise and permanent fix soon.

Cool, glad it was helpful.

I've noticed that texture UVs don't seem to be editable - any idea why?  I'd like it fixed, and may look into it myself eventually, but if you wanted to get to it first (or point me in the right direction), that'd be great.  (Also, I'm not sure if it ever worked.  Not in 0.71, anyway.)  The first time I needed it done I exported to a raw file, hex edited, and imported...

So I just submitted a pull request - I'll repeat the description here, so others can see it and because I'm not sure where you'd prefer to discuss.

I was seeing a NullReferenceError on the first line changed when previewing a model, closing the model editor, then repeating - on the third close it would throw the error. (This was editing Project M's sc_selcharacter.pac > MiscData[30] > MenSelchrBack2_TopN, or MenSelchrFaceI_TopN - I didn't test any others.)

The second error (with _targetModels) would show up when the same thing was done, but would take between 2 and 7 iterations to crash. It seemed to happen more consistently when editing was done - changing the animation for MenSelchrFaceI was what I was trying to do when I came across this.

Obviously this is a blunt fix; it would be better to learn why these are null sometimes. I think _targetModels in particular should probably never be null, and things setting it to that should probably be making it be an empty list instead.