Search the Community

Hi everyone! I recently extracted Midnight Club 2's textures as I am looking to experiment with creating a HD texture pack (which does not exist today). Most of the files are .TEX, with a few .IPU and .PAL files and one .OUT file. However, I have tried several different programs to convert the .TEX files to PNGs in order to upscale them properly, without much luck. ScarletConvert doesn't recognize the tex, Rainbow doesn't support tex files, TextureFinder 1.3.2 opens up a weird image with distorted colors, and TextureFinder 2.1 may be a virus based on VirusTotal and my W11 PC literally stopping me from opening the file. In addition, there are also IPU, OUT, and PAL files in the directory for seemingly larger assets. Can I get some assistance with this problem? Thank you, and have a great day!

love it or hate it Metal Slug 3D PS2 (2006). I just need to extract pak file so I knew there are 3d models of enemies and vehicles in the 2006 game but I couldn't extract it I used BMS quickbms https://aluigi.altervista.org/bms/metal_slug_3d.bms it only works only DATA file and the folder in the iso metal slug 3d ps2 doesn't have it! help please !

I'm currently in the early steps of a translation project for Tokimeki Memorial 3: Yakusoku No Ano Basho De. Right now I am making a tool for extracting the game's script. I have extracted the file system from the .iso. It has five .BIN files which contain all of the game's assets. At first I extracted text from Data5.BIN, as it contained uncompressed text that simply needed to be filtered from the other data. This text is almost exclusively for menus, which means the dialogue must be stored in the other .BIN files. When viewed in a hex editor, it becomes clear that the other data files (Data1.BIN - Data4.BIN) contain a large amount of compressed files with the header ATP. I know some of these contain dialog, because I can see scattered bits of Shift-JIS strings, some of which line up with dialogue I've seen in-game. Using a combination of the PCSX2 debugger and Ghidra I was able to identify where the compressed files are stored in memory when they are loaded off the disk and the function that is responsible for decompressing them. I've recreated this function in my toolset and it runs/exits without crashing but I don't think the decompression is working. It seems to have the following issues: Sometimes there are no changes between the compressed and "decompressed" ATP file (it's possible that this means the file's content was never actually compressed to begin with) Oftentimes the strings appear more jumped in the "decompressed" version than the compressed version. It doesn't stop when it needs to, running into the next ATP file and stopping halfway through "decompressing" that. Here's the assembly function taken from the PCSX2 disassembler: lbu a3,0x0(a0) addiu a0,a0,0x1 daddu t1,a1,zero addiu t0,zero,0x8 bne t0,zero,0x001E93F8 andi v0,a3,0x0001 lbu a3,0x0(a0) addiu a0,a0,0x1 addiu t0,zero,0x8 andi v0,a3,0x0001 bne v0,zero,0x001E9418 addiu t0,t0,-0x1 lbu v0,0x0(a0) addiu a0,a0,0x1 srl a3,a3,0x01 sb v0,0x0(a1) beq zero,zero,0x001E93E0 addiu a1,a1,0x1 bne t0,zero,0x001E942C srl a3,a3,0x01 lbu a3,0x0(a0) addiu a0,a0,0x1 addiu t0,zero,0x8 andi v0,a3,0x0001 beql v0,zero,0x001E9498 lbu v0,0x0(a0) addiu t0,t0,-0x1 bne t0,zero,0x001E9450 srl a3,a3,0x01 lbu a3,0x0(a0) addiu a0,a0,0x1 addiu t0,zero,0x8 andi v0,a3,0x0001 srl a3,a3,0x01 addiu t0,t0,-0x1 bne t0,zero,0x001E9470 sll a2,v0,0x01 lbu a3,0x0(a0) addiu a0,a0,0x1 addiu t0,zero,0x8 andi v0,a3,0x0001 srl a3,a3,0x01 lbu v1,0x0(a0) addiu a0,a0,0x1 addu v0,a2,v0 addiu t0,t0,-0x1 bne v1,zero,0x001E94E0 addiu a2,v0,0x2 beq zero,zero,0x001E94E0 addiu v1,zero,0x100 addiu a0,a0,0x1 lbu v1,0x0(a0) addiu a0,a0,0x1 sll v0,v0,0x08 srl a3,a3,0x01 or v1,v0,v1 beq v1,zero,0x001E9510 addiu t0,t0,-0x1 andi a2,v1,0x000F beq a2,zero,0x001E94D0 addiu a2,a2,0x2 beq zero,zero,0x001E94E0 srl v1,v1,0x04 nop lbu v0,0x0(a0) addiu a0,a0,0x1 srl v1,v1,0x04 addiu a2,v0,0x1 beq a2,zero,0x001E93E0 subu v1,a1,v1 lbu v0,0x0(v1) addiu v1,v1,0x1 addiu a2,a2,-0x1 sb v0,0x0(a1) nop bne a2,zero,0x001E94E8 addiu a1,a1,0x1 beq zero,zero,0x001E93E0 nop nop jr ra subu v0,a1,t1 and here's my attempt to recreate it for my tool set . I apologize in advance for the poor readability public static void DecodeATP(int startAddress, byte[] byteArray, String outputPath) { //Note to self: when implementing this, use integers that refer to indexes on the array as "pointers" //Use labels and gotos for the parts byte[] destination = new byte[byteArray.Length]; uint sourcePointer = (uint) startAddress + 8; //a0 in the assembly, skips 8 to avoid the ATP file header //set up a few variables to take the place of some registers in the original assembly uint v0 = 0x0; uint v1 = 0x0; uint a2 = 0x0; byte previousByte = byteArray[sourcePointer]; sourcePointer++; uint destinationPointer = 0; uint counter = 8; byte buffer; Part1: //Part1 v0 = (byte)(previousByte & 0x1); if (counter == 0) { previousByte = byteArray[sourcePointer]; sourcePointer++; counter = 8; } else { goto Part2; } Part2: //Part2 counter--; if (v0 == 0x0) { buffer = byteArray[sourcePointer]; sourcePointer++; previousByte = (byte)(previousByte >> 0x1); destination[destinationPointer] = buffer; destinationPointer++; goto Part1; } else { goto Part3; } Part3: //Part3 previousByte = (byte)(previousByte >> 0x1); if (counter == 0) { previousByte = byteArray[sourcePointer]; sourcePointer++; counter = 8; } else { goto Part4; } Part4: //Part4 v0 = (byte)(previousByte & 0x1); v0 = byteArray[sourcePointer]; if (v0 == 0x0) { goto Part7; } else { counter--; previousByte = (byte)(previousByte >> 0x1); if (counter != 0){ goto Part5; } previousByte = byteArray[sourcePointer]; sourcePointer++; counter = 8; goto Part5; } Part5: //Part5 v0 = (byte)(previousByte & 0x1); previousByte = (byte)(previousByte >> 0x1); counter--; a2 = (byte)(v0 << 0x1); if (counter != 0) { goto Part6; } else { previousByte = byteArray[sourcePointer]; sourcePointer++; counter = 8; goto Part6; } Part6: //Part6 v0 = (byte)(previousByte & 0x1); previousByte = (byte)(previousByte >> 0x1); v1 = byteArray[sourcePointer]; sourcePointer++; v0 = (byte)(a2 + v0); counter--; a2 = (byte)(v0 + 0x2); if (v1 == 0) { v1 = 0x100; } goto Part9; Part7: //Part7 sourcePointer++; v1 = byteArray[sourcePointer]; sourcePointer++; v0 = (byte)(v0 << 8); previousByte = (byte)(previousByte >> 0x1); v1 = (byte)(v0 | v1); counter--; if (v1 == 0x0) { goto Part11; } else { a2 = (byte)(v1 & 0xf); a2 = a2 + 0x2; if(a2 == 0x0) { goto Part8; } else { v1 = (v1 >> 0x4); goto Part9; } } Part8: //Part8 v0 = byteArray[sourcePointer]; sourcePointer++; v1 = (byte)(v1 >> 4); a2 = (byte)(v0 + 1); goto Part9; Part9: //Part9 v1 = (byte)(destinationPointer - v1); if (a2 == 0) { goto Part1; } else { goto Part10; } Part10: //Part10 v0 = byteArray[v1]; v1++; a2--; destination[destinationPointer] = (byte)v0; destinationPointer++; if (a2 != 0x0) { goto Part10; } else { goto Part1; } Part11: destination = SubArray(0, (int)destinationPointer, byteArray); File.WriteAllBytes(outputPath, destination); return; } Could anyone help me identify where the problem is?

Hi all - I've been obsessed with this little game for a very, very long time, and I'm trying to learn the file structures to try to make it work. I've got the files broken out into the different formats from the disk, and I've pretty confidently identified the .md model files. The mesh files themselves I'm exploring with ModelResearcherPro, and this is what I've come up with so far. most models have multiple meshes embedded, and there's some things I have and some things I haven't figured out yet. I'm using the attached GSG03.MD as the example model, which Iam pretty sure is a robot broken into multiple bits. (There are some models for like a map model, and it's broadly similar.) File Start: Little Endian First long 26 00 00 00 Mesh Start 7x long or floats of header - this is different for each file, but very consistent in length. First long is an address pointer to the end of the vert section, 4 bytes after the vert end marker. Then 6 other ones? Next is what I'm calling a New Mesh Indicator, but probably has some other function: 3x 00 00 80 3F (read as 1.0 as a float?) Next long is the address pointer to the of end of the mesh total (eg. 74 05 00 00 -> 0x0574) then a null long, then a set of bytes that are a consistent header within the file but I haven't sorted them out yet (eg: 17 25 06 00 A3 9E 9C FF 3F 3F 3F FF 99 99 99 0C 40 00) (somewhat consistent between files, at least the same header format, read as: 17 25 06 00 XX XX XX XX XX XX XX XX XX XX XX XX XX XX. ) Then an unsigned int short for....something? doesn't seem to line up with number of faces, or a pointer, or anything like that, but it changes for each mesh in the file. It's bigger than the vertex count, but that's about all I know. Maybe a total number of objects to process, and you subtract out the verts? Then a mix of triangular faces and normals, maybe? Triangular Faces using unsigned int shorts as vertex identifiers (I think), and probably normal vectors? Not really sure how to break through this, the faces don't really align with anything resembling sensible geometry. Also, there's periodically very large shorts, like FB FF, that break the vert indexing. They one's complement into somewhat sensible vertex indices, but no other rhyme or reason as far as I can tell, and I don't know how to do that automatically. At the end of the faces section, there's a long of FF 00 00 00, which I think is an end marker. Then another short 29 00, then another short that's different for each mesh, then another null short. Then a Vertex Count Short (unsigned int). This one I'm fairly confident in, and it's reproduceable. Then starts a mix of Verts and UV and maybe something else. I don't really know if this is right, but it makes the address math work out: each point is 6 floats: ??, U?, V?, X, Y, Z. Then after vertex count of verts, another FF 00 00 00 end marker. Next is 6 longs, and the first is the one that the End of Verts pointer addressed Finally either a short and a null short, or a long, but a low int 24 00 00 00, or 36 00 00 00, and is the address of the end of mesh pointer. Maybe it's actually the beginning of the next mesh? Sometimes there's an empty mesh at the beginning or end. Not sure, but they don't have an end of mesh pointer; sometimes they have a few vertexes, sometimes not. I'll get to textures eventually, but I'd really like to figure out what the mesh format is first. Anyhow, thanks for taking a read! I don't really know what I'm doing yet, but I'd really appreciate any guidance you've got on this. GSG03.7z

Hello, I believe this is a good place to have this topic, anyways, I want to know how I can extract the models from the following 3 games: Monster Rancher 3 (2001), Monster Rancher 4 (2003), and Monster Rancher EVO (2006 in the states, 2005 in Japan). These 3 games are for the PS2 console, and I want to know how to open the .dat files of these 3 games. I'm willing to accept your wisdom, provided that you know what you are teaching me. I thank you in advance, and I also provided 3 screenshots, one for each of the 3 games, and all of them are Monster Rancher related.

There are at least two types of i3d file formats, used within the .i3d files used in ape escape 3 and Rule of Rose uses .i3d files in .mdl files. I3D_BIN: Mesh ✔️ Bones ✔️ Skin ❌ I3D_I3M: Animation ❌ Tools: https://github.com/Durik256/Noesis-Plugins/blob/master/fmt_i3dg.py - Supports meshes. fmt_RuleOfRose_PS2__i3d.zip - Supports bones (made by Bigchillghost from xentax, reuploaded into reshax for quicker accessibility)

I want to rip from a game released only in Japan on PS2 called "Jigoku Shoujo Mioyosuga" developed by Compile Heart. More info for curious people on the game or franchise : https://en.wikipedia.org/wiki/Hell_Girl#Video_games or https://gamefaqs.gamespot.com/ps2/961167-jigoku-shoujo-mioyosuga I've extracted the files from the game and it seems most of the game data is stored in .PTD archives (other files are .PSS that are movies files). There are 11 PTD files and I don't know if they are encrypted or compressed. What I've noticed is that it seems there is a file index table named "PTDALL.PID" which seems to contain the location of files and data but I'm not very familiar with it so I'm not sure. Maybe with some bms script it will be possible to extract everything so thanks for the people that will be able to do this. Download link of the files : https://drive.google.com/file/d/1IIgGjkqZBM__VNdzehLaWAFwmuNUGckl/view?usp=sharing. The PTD files are in the DATA folder.