Kitty Corp Meow Mix Forums

Yeah, I know, we all need another one of these, right? r)

Smash Hack Assistant is a GUI-based application that's meant to function as "workflow grease" for the process of texture hacking. When completed, it will replace the functions of of ASH, STASH, etc. with simple point-and-click procedures, and will manage all your hacking projects from a single interface.

I'm starting SHA because other similar projects rely heavily on external utilities and/or single-platform software. As a Linux user, I'm forced to jump through hoops to make many of these tools work, and some of them aren't very artist-friendly to begin with.

The goal workflow of SHA is as follows:

• When SHA is started up for the first time, you select several things: a source for unedited textures (as an ISO, pf/-style directory, or ZIP archive), a preferred image editor, a preferred export mode (ISO or pf/), and an export path.
• A simple treeview is shown, containing a list of fighters. You expand one of them, pick a .pac file, then select a texture.
• A thumbnail preview of the original texture is shown, as well as your edited version if the current project contains one. When you have verified that this is the texture you want, you click "Edit".
• The texture is opened using your preferred editor. You make your edits, then save the file normally.
• Repeat this process for each texture you want to edit.
• When you are finished, click "Export", and all your edited files are automatically packed, then either inserted into a new ISO or copied to the desired pf/ directory, as per your preference.
• Play the game with your new textures.

Ideally, SHA should be quicker and easier to use than your editor's default file open dialog. Since it's written using libqt4-ruby, it's also completely cross-platform, so texture hacking will finally be as easy for many people as it should be.

Now, I've just started on this today. Don't expect anything usable any time soon. I've still got a lot of research and nitty-gritty to take care of before even extracting is feasible. If you're interested in seeing the layout I'm working with, here's a mockup:

(http://drop.io/download/public/g1q72sjndbqot0tg3pqt/d87250edd8a01f06f53ead60ada016762a2b3f52/cda97f50-851b-012c-ee3f-f1a3d524c7b1/cf4b0540-851b-012c-5eab-f81317cbb593/v2/thumbnail_large) (http://drop.io/smashhackassistant/asset/sha-mockup-png)

Please note that the above is not in a functional state.

Again, I've just started this, but I'm open to hearing suggestions if you're open to giving them. I'm also not opposed to help, especially from people familiar with Ruby, Qt, or advanced hacking.

Well, that's all I've got for now. Back to work!

Looks nice.  Can't wait to see the final product.

From what I'm reading, it seems as though it will require the ISO. If so, that will greatly limit its usefulness to the general community. While I have the ISO on my computer, I'm guessing that the majority of people these days will not.

The idea itself is great.

Mmm, that hadn't occurred to me. Everyone I've spoken with up to now does their own texture package extraction, so it seemed natural to me that the ISO was one of the required files, and it makes things simpler to have everything in one big lump.

All that it's strictly needed for is to insert edits into for users who want an ISO output file. It shouldn't be a problem to use a collection of downloaded .pacs as a source. I assume that's the usual method?

It is. I have my own ISO, but the SD loader makes things much more quicker.

It be cool if you could browse the entire .ISO with it.

I like the idea.

Hmm... gonna have to hear more about this.

Just a quick update: using Qt4's built-in model/view architecture (which I'm painstakingly learning as I go), I should be able to coerce any hierarchical source into working with the same interface. This means the end user will only need to select a location for their unedited textures, either as an ISO, a collection of folders, or perhaps even a ZIP archive. After that, you don't have to interact directly with your archive any more, since the source is remembered and the extraction is automated.

I'll update the first post accordingly.

Smashbox?

I'm not sure what you're asking, but Smashbox falls under my "jump through hoops" complaint. If I recall, it's .NET-dependent.

Besides, Smashbox and SHA have different goals.

Either way, i was gonna suggest this to the smashbox maker, but never did. A feature should be implemented where you can change the size of the texture and the format. I have most of the details (ill have to take a look at my notes and browse the inside of a file for a bit to refresh my memory). This has to be capable of editing the TPL's EOF and pointers to a different size, then basic header changing.

Y'know, it never even occurred to me that that was possible. One way or another, I'm going to need to refer to the full TPL documentation, because SHA will have to convert to/from TPL without any external utilities, but for some reason I was under the impression that Brawl had hard-coded image format expectations.

If the image's format can be changed that easily, I suppose I could have SHA run a couple checks (does it have alpha, does it have >256 colors, etc) and choose an appropriate format by default.

Anyway, I'm back for the week (I work Friday - Sunday). Occasional updates forthcoming.

I only looked into the compression of tpl for an hour or so, but i found file size, pallet pointers, name pointers, format, how the image is compressed and a heap of other stuff. I suggested this to smashbox aswell, but  if you still need the info, im happy to give it to you.

That would be massively helpful. Post or PM me whenever you like; I'm not really close to using it yet, but I'll tack it into a comment where the loader will eventually go, so it's right in front of me when I get started on that.

And thanks a lot for helping out. It's not often I start a project like this and an administrator shows any interest. In fact, all of you have set down an unusually good first impression of this community. :)