===================================== XMV resource types ===================================== by Toastline of SPG http://colourfire.nfshost.com/ June 29, 2014 ===================================== These are really sort of strange. They will always be followed by an XPK, which they have relevant data for. Here I will use the first XMV from GearWG.PRX. The first part of the resource is 58 4D 56 Which is the ASCII for XMV. That part is always the same. Then I don't know what the next 191 bytes are, but the 192nd will tell you how many frames there are. In this case, that is 23 in hexadecimal (which is 35, base 10, however, there are 34 frames to care about). Immediately following is a set of analogous structures to the "divider" in a regular XPK. Guess how many of them this resource has. It has 34 of them! The first one is like this: 00 06 00 00 00 00 00 00 00 00 00 28 00 02 00 02 The "00 06" has no clear meaning. However, the "00 00" immediately afterward is important. It tells you the frame number for this divider (the first frame is 0). The next important thing is the "00 02 00 02" at the end. These are PROBABLY the x and y offsets, respectively, just like the ones in an XPK, which I once thought I understood, but it turns out they're complicated somehow. The next divider follows immediately: 00 06 00 01 00 00 00 28 00 00 00 28 00 02 00 02 So it's frame 1 and the offsets are the same. It keeps going like this. You'll have to store the offsets for when you get to the XPK. After you read the last of the XMV's dividers... You have to read one more divider worth of bytes. In this example, that is 00 0A 00 00 00 00 05 50 00 00 00 00 00 00 00 00 Which looks vaguely similar to the rest of them, but can be ignored for the purpose of extracting images. After that final dummy divider thing, you should arrive at the XPK resource that the XMV contains data for! Then you have to read the XPK, which will be DIFFERENT than a normal one. The relevant part starts here: A5 7E 70 01 B0 02 00 22 00 00 02 10 00 00 04 30 The 22 byte says that there are 22(hex) images... 34 in decimal, which matches the number from before. I think that this is always how it works out. I sure hope so. Then the 02 10 bytes tell you where the palette ends, as normal (The byte before byte number 210(hex), if the A5 is byte 0). Then you get a lot of things that look like "divider" sections but do not appear to be useful for anything. You should ignore all of them, but know that there are, in this case, 34 of them. For the next part, there are 34 4-byte values that tell you where each image in the set will begin, relative to the byte after the palette (which is where this section begins). Reading the images themselves should be the same as a regular XPK, but instead of the file ending after completing the first image, you'll encounter another set of image data. There will be a total of 34 images in this case. As usual, there is no delimiter at the end. You'll run right into the next file once done with this one. =============================== XUI resource types =============================== by Anthony Kozar http://www.anthonykozar.net/ June 29, 2014 =============================== I am guessing that the XUI resource type is some sort of user interface component. These resources are found only in Editor.PRX (3) and UI.PRX (14). They probably coordinate the display of XPK resources in those files and link them to event processing code in the game and editor executables. (Just a guess).