Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 10/28/2025 in Posts

  1. I'm trying my best to make it load somehow
    4 points
  2. Actually the LZSS provide above, is wrong, for the files. I did the reverse enginner of the algorithim, Try the tool, see if the image get right TenchuWoH_DeCompressor.zip
    3 points
  3. Thanks for some info from here and made a tool for unpacking and packing localize map files, if someone is interested in it. https://github.com/dest1yo/wwm_utils
    2 points
  4. The textures are compressed with ZSTD - just that type 0 means the whole file is not compressed. But there doesn't seem to be any encryption once decompressed - looks something like ETC format:
    1 point
  5. Animation file from FGO arcade, uses the same engine as various Project DIVA titles but the animation files are formatted in a different way. .mot Tool: https://github.com/h-kidd/noesis-project-diva (works with FGO Arcade's model files and .mot files from Miracle Girls Festival and Project DIVA but it doesn't work with FGO Arcade's .mot files, but you can edit the source code of the tool to try to make it work with the game's .mot files) Sample file is in the attachment. mot_svt_0001.zip
    1 point
  6. It's Unity, but seems to have a protection layer so it can't be opened in Asset Studio. Game Assembly: https://www.mediafire.com/file/3i7kvobi4nacnbh/GameAssembly.zip/file THO.zip
    1 point
  7. Here my analysis: Header: 24 bytes: [ Int64 EntryCount Int64 ValueCount Int32 Timestamp Int32 Padding ] Buckets: [24-528] bytes, based on allocated bucket TableEntries: EntryCount * [ 8 Bytes Hash(or id?), Int32 RelativeOffset, (formula: text_start = current_entry_offset + 8 + value) Int32 TextLength ] Values: ValueCount * [ Byte[ValueLength] Data ] Null value have zero length and no hash. Successfully unpack and pack, the game load new text normally.
    1 point
  8. To whoever ends up here in the future, there is a really simple to use utility to convert files from Xbox ADPCM to PCM and vice-versa on Github: Sergeanur/XboxADPCM Thanks for the thread, I really thought the WAV files I had were lost forever due to an obsolete codec..! In my case, I am porting the PT-BR voiceover of Max Payne from PC to Xbox, which I am surprised wasn't done before.
    1 point
  9. Hello, I have managed to get the game files and uploaded to AssetStudio to view them, and I found Texture2Ds and Sprites but some of the assets are missing. For an example, there are literally no audio/voice files at all. Then, I noticed AssetStudio doesnt recognize the assets inside a folder called "ondemand" and there are about 2k assets there and I think they are encrypted/compressed. Here is one of the examples of the encrypted assets: Is there a way to decrypt/decompress this type of file? I think those are the remaining assets. If anyone can help me I would really apprecaite it. 5db8fd68-da55-9c4a-c71f-84af76d61103.7z
    1 point
  10. Yea, I'm working on BHD but mostly focused on the JO/DFX2 engine which is slightly newer and a different format. I'll post here when/if I get BHD usable.
    1 point
  11. You can either use this QuickBMS script to extract the msv audio files out of the rp2: get UNK long get FILES long goto 0x20 for i = 0 < FILES getdstring NAME 7 getdstring DUMMY 25 get OFFSET long get SIZE long get DUMMY2 long string NAME + ".msv" log NAME OFFSET SIZE next i Or you can use this txth file to play the audios out of the rp2 directly (needs vgmstream + an audio player like foobar2000): subsong_count = @0x04 subsong_spacing = 0x2c base_offset = 0x20 name_offset = 0x00 subfile_offset = @0x20 subfile_size = @0x24 subfile_extension = msv Save the text above as ".rp2.txth" and put it on the same directory as the rp2 file. Also if you're using foobar2000, make sure to check "Enable unknown exts" on the vgmstream preferences page.
    1 point
  12. Yes! I´ve to create a tool to merge and split image, so i can merge them, edit and later split to insert.
    1 point
  13. Hi Shak-otay, yes it's me, I never imagined you would remember me 😄. I found this texture in the file.
    1 point
  14. Bumping this again because I really don't want this thread to quietly die, as it seems the edits to my message are not enough to constitute a bump. Every single possible 16 bit float format I've tried does not work. Indicating this is some proprietary cursed format. Maybe a LUT. Maybe encrypted. Maybe something else. Which probably explains why the .mot files still have not been decrypted all these years. I do suspect what certain bits mean but I am really unsure. I have the model .bin and some other examples of .mot in hand as well so if you would like me to send it I will gladly do so. Just note I do need these files decrypted for a project so I would like this done as fast as possible it would be nice. What I do know is that this is little endian. Z-Y-X order. I have no clue what else. Help is much appreciated please 🙏 (I am not sure what y'all want but I am interested in a way to export the .mot to .csv with a Frame # column. For my application, that is enough.)
    1 point
  15. Well, I did a little research on Flash Cookies (SOL files) and I put it all together in the article on RE Wiki https://rewiki.miraheze.org/wiki/Flash_Cookie_SOL I saw notes on your github and you were sligthly wrong with some fields, so you can compare it with my article on the wiki and make some corrections in your tool. The most important thing is that you should understand that SOL file is an Adobe format and payload (data block) follows AMF file format documented by Adobe https://web.archive.org/web/20220122035930/https://www.adobe.com/content/dam/acom/en/devnet/pdf/amf-file-format-spec.pdf So anything after data block header is a payload section that needs to be properly serialized by your tool. There are many tools that allow you proper serialization like: minerva, SOL Editor, Adobe AIR SDK, JPEXS Free Flash Decompiler etc. Some code for serializing is available on JPEXS github page: https://github.com/jindrapetrik/jpexs-decompiler/tree/master/libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/sol https://github.com/jindrapetrik/jpexs-decompiler/tree/master/libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/amf/amf3 You can test this code by going to Tools > Sol cookie editor in JPEXS Free Flash Decompiler: So you shouldn't ask "what are those three bytes". You should ask "how can I properly parse AMF3 serialized data" 🙂 There are lots of information (articles) about this, for example on wikipedia: https://en.wikipedia.org/wiki/Local_shared_object https://en.wikipedia.org/wiki/Action_Message_Format Good luck. 🙂
    1 point
  16. Here you can see something, but I don't know how to find the faces.
    1 point
  17. Okay, thanks for the lead. I successfully uncompressed the PUD file, and it is indeed a container. The value 0x2 represents the number of files within it. The uncomressed images are raw pixel data and need to be combined with the PAL file to get the correct image. can use imageheat to view the correct image.
    1 point
  18. I used the files from the zip, iirc. But seems, you're too late to the party...
    1 point
  19. Edit - just tested it and no 4 mrts is uv, you was right in saying the 4th one is the uv maps by the rule
    1 point
  20. They are still pck files. I can find many wwise .bnk files in AA462ABBFEC319B665666E14585F97D9_EndfieldBeta with ravioli explorer , RavioliGameTools_v2.10.zip (if you need)and I think quickbms also work. By the way I guess the really wem audio files are in another pck files. there are over 5000 bnk files in AA462ABBFEC319B665666E14585F97D9_EndfieldBeta. That means the bnk files may not store any actual audio files
    1 point
  21. # Atlas Fallen (Fledge Engine) # script for QuickBMS http://quickbms.aluigi.org comtype lz4f open FDDE "toc" get DUMMY long get SOME_CRC long callfunction GET_INFO 1 get SIZE long endian big get SOME_CRC long callfunction GET_INFO 1 get SOME_CRC long callfunction GET_INFO 1 callfunction GET_INFO 1 get DUMMY byte # 1 get DUMMY byte # 1 get DUMMY byte # 1 get DUMMY long # 1 get FILES long string NAME p "%s_%d.dat" NAME 0 open FDSE NAME 1 for i = 0 < FILES get SOME_CRC long callfunction GET_INFO 1 get OFFSET longlong get ZSIZE long get SIZE long get DUMMY long get DUMMY long get DUMMY short clog NAME OFFSET ZSIZE SIZE 1 next i startfunction GET_INFO get ZERO long get DUMMY long savepos TMP get NAMESZ long if NAMESZ & 0x80000000 math NAMESZ & 0x7fffffff endif getdstring NAME NAMESZ padding 4 0 TMP endfunction
    1 point
  22. Hi experts. I'm trying to read the MT2 images from Indiana Jones and the Emperor's Tomb (PS2), but I'm stuck trying to piece it all together. The images in the PC version are 32-bit RGBA, so that's easy, and gives us a comparison. For the same image in the PS2 version, it seems to be broken down like this... 64 bytes - basic image data (filename, width, height, etc) width*height/2 - 4-bit pixel values (with 4bit PS2 swizzling) width*height/8 - color values This is what the pixel block looks like, as 4-bit values in grayscale: The color values in the last block, look to be something similar to RGBA5551, so even though the length of this block is width*height/8, as they are 16-bit colors, there are actually only width*height/16 colors. This is what the color block looks like when read as RGBA5551 color values: ... you can see the image in that "color block". I know it's not quite the right colors, but think it might just need some color striping applied to it, or it might not be exactly RGBA5551. As the width/height increase, so does the size of the color block, so it's not a plain palette, it's proportional to the image size. For example, for a 128x128 image, the color block is 2048 bytes. For a 256x256 image, the color block is 8192 bytes. I'm struggling to work out how to join the "pixel" block and the "color" block together so that we end up with a usable image that looks similar to the PC image. I'm assuming maybe we need to generate some in-between colors like in a DDS image, or otherwise apply some kind of "intensity" to the colors or something like that. I've never seen anything like this before - is anyone able to assist in understanding this please? I have attached a ZIP with the PC image, the PS2 image file, and PNGs for both the "pixel" block and the "color" block, so you can clearly see there is a correlation between the 2 blocks. Thanks for your help! vinehead.zip
    1 point
  23. Anybody could share mot, tex_db.bin and a model file .bin of a character
    1 point
  24. I tried using the head models and tested two of them (DDP and Rovyal). I was able to get the models to work. From my understanding, all of the heads share the same offsets and parameters, so if you can get one model to construct with no weird faces, you can use the same parameters for the other models. I’m just having an issue with the ears, as you can see in the photo below. If you could share your parameters and offsets, I think it would be very helpful. update 1 : got it woriking however the uvs are not working but you can transfer it using copy vertex order plugin in blender UPDATE 2: got the uvs to work for the model using these params but i still have to go inside blender uv unwrap and then copy uv maps to the main model . is there a way i can get uv maps and model all in 1 in hex2obj ? sorry if this is a rookie question since ive never used hex 2 obj before Final Update : I just have to save the mesh from hex2obj settings and the uvs will be added to the obj. thanks for your help Hex2Obj
    1 point
  25. for the mcgregors normal you can use this bms Decompressor.zip
    1 point
  26. Try this tool, made some adjust to read your file. zstd decompressor.zip
    1 point
  27. Actually your file is a container with a bunch os zstd files. attached the first file decompressed. I did a tool, long time ago, i will search here. head_conor_mcgregor_model_CB540.mcd.zip
    1 point
  28. It's not just 1 block of data, there are multiple compressed ZSTD blocks in your sample file that have to be joined together - e.g. at 0, 0x129b0, 0x31dd0, etc.. It looks as though each file is preceded by the compressed size and anotherr value, except the first block, which looks to be a compressed size of 0x129a0. You might have cut that bit off in your sample. Each block seems to decompress to 0x40000 bytes except for the last one, which is shorter. I guess the header might have some useful info.
    1 point
  29. in the end, I did it, thanks to everyone who posted on this topic.
    1 point
  30. Because the fmlb and sound file does exits anymore because when before Game shutdown that files are dynamic content but some files like that are available in beta versión APK and obb but no all files
    1 point
  31. I have released an early version of the tool that can do just meshes with their material names/skeleton:
    1 point
  32. Hey guys, I'm working on these formats and progressing with the meshes, some files don't work properly, the uvs Jxm have submehs and lods, I will post all the progress here
    1 point
  33. Please use this updated script to repackage the data file. If you have any questions, please let me know so that other capable people or you can continue to process these .pxc files yourself # Update the decompression of pxc file(script 0.2) get FILE_SIZE asize xmath TOC_PTR "FILE_SIZE - 8" goto TOC_PTR get TOC_OFFSET long goto TOC_OFFSET get FILE_COUNT long for i = 0 < FILE_COUNT get OFFSET long get SIZE long get COMP_FLAG byte get NAME_LEN short getdstring NAME NAME_LEN get UNK long savepos TOC_ENTRY_POS if COMP_FLAG == 0 goto OFFSET getdstring MAGIC 4 if MAGIC == "PxZP" comtype zlib get UNCOMP_SIZE long get COMP_SIZE long savepos DATA_START clog NAME DATA_START COMP_SIZE UNCOMP_SIZE else log NAME OFFSET SIZE endif else goto OFFSET get MAGIC long get UNCOMP_SIZE long get COMP_SIZE long savepos COMP_START clog NAME COMP_START COMP_SIZE UNCOMP_SIZE endif goto TOC_ENTRY_POS next i pxc.zip
    1 point
  34. Bumping this, if anyone would be an absolute unit to solve the animations it would be greatly appreciated! 🙃
    1 point
  35. my plugin for vfs work with your file EDIT: and i made preview plugin for *.sggr fmt_sggr.py (*.pvr its image, use pvrTexTool)
    1 point
  36. Seems the game dont accepts a different zlib levels Maybe using levels 0-9 and try. use level 9, the compression file will be the same as original! https://drive.google.com/file/d/11rON0JaDswJCQJ-RBF2USKErQRtPbP_I/view?usp=sharing and maybe solution post;
    1 point
  37. use my plugin for Noesis arc_zlib_plzp_lang_vfs.py (which I mentioned earlier) it recursively unpacks all files, at the output you will get *.png, *.wav, *.pm3, *.vram, *.text, *.pvr and e.t.c You can also find a link to the plugin for 3D models *.vram above in the same topic. (*.pvr can open in PVRTexTool)
    1 point
  38. zlib_DeCompressor.pyHere the DeCompressor update, now works with every file
    1 point
  39. I wrote a VSF UNPACK/PACK program and a new decompressor/compressor for zlib. Now, it accepts large files and there's no need to use QuickBMS anymore. The .vfs file can now be larger than the original. I did a test, and it worked with the image below, maybe you can put music and soundeffects as well, If the .py file doesn't work, you must install tkinter via pip. VFS_PackUnpack_Tool.py zlib_DeCompressor.py
    1 point
  40. 1 point
  41. Maybe you should open a new thread and ask in there, not here, because this thread is for discussing the motion file.
    1 point
  42. for fgo's script, you just need run this: python FGOArcade-FARC.py "your farcfile path" for farcpack tool, Run it in the shell to see the cli commands.
    1 point
  43. for fgo arcade, you can use this to extract the farc file: https://github.com/Silvris/RandomScriptsAndTemplates/blob/main/FGO Arcade/FGOArcade-FARC.py for kancolle arcade, you can use farcpack tools to extract it: https://github.com/blueskythlikesclouds/MikuMikuLibrary/releases/download/v2.2.0/FarcPack.7z the trading card images was in ./rom/trading_card
    1 point
  44. Has anyone managed to extract the trading card images? I tried using the script for the 3D models. but it just doesn't work.
    1 point
  45. https://github.com/h-kidd/noesis-project-diva AFAIK this uses the same (or highly relevant - Virtua Fighter 5 based) engine as other arcade games such as Project DIVA Arcade or Fate Grand Order I guess the animation format would be relevant (and hope this be helpful for REing)
    1 point
  46. This thread is about the audio extraction tools from the legacy Dead Space trilogy (Dead Space, Dead Space 2, Dead Space 3). All of the tools were downloaded from Xentax years back, so credit to all of the original makers of the tools go to them. I just want to preserve them in a single place. I don't recall from memory any more what all of these file formats were, so I'm probably not much help with the usage. I'm just pasting links of the tools I had uploaded to my Mediafire account in 2018. However, what I do remember is that some of these tools that supposedly worked with two games were acting out a bit so I just in case had made seperate versions for each game. Dead Space 1 definitely has its own file formats and tools that don't work on Dead Space 2 and 3 and wise versa. I believe SBK unpacker works for all of the games but I'm not 100% sure. Exa unpacker was for Dead Space 2 specifically and EALayer for Dead Space 3, but I'm not sure if they could be modified so that one tool works with a single game. To be honest, if I was more knowledgeable, I'd just make one megatool with a proper UI that can open and extract from all of the games since having these billion exe files is frustrating. =============================== Universal .STR and DS2-3 BigFile formats' RickVisceral's BigViewer (Note that the BigFile extractor has its own UI and the STR file opener is included in the same folder. I'm pretty sure the STR file tool works with DS1 since I don't have any seperate tool for that file format with DS1 label). https://www.mediafire.com/file/vmgh564ita25wqz/RickVisceral110423.zip/file Dead Space (2008) .SNU to .WAV https://www.mediafire.com/file/tnisaj3elv77ajy/ds1_.snu_to_wav.rar/file XAS decode https://www.mediafire.com/file/tt61elv4u4sr0ca/ds1_xas_decode.rar/file Dead Space 2 (2011) SBK Unpacker https://www.mediafire.com/file/fdr8f6y5mpxf9gt/SBK_unpacker_DS1-3.rar/file EXA to MP3 https://www.mediafire.com/file/240allqyd7a6eck/DS2_EXA_to_mp3.zip/file Dead Space 3 (2013) EALayer (same as exa to mp3 if I recall but for Dead Space 3 only) https://www.mediafire.com/file/gg10lwpe0i6blla/ds3_ealayer.rar/file If I recall, some audio files can't be extracted for some reason, I think it was because they use console audio formats for some reason. For one, I recall that Dead Space 3 audiostreams folder was missing quite a bit of music files when I was uploading the whole soundtrack on YouTube some 6 years back so I had to resort to recording in the game. Also, the NPC chatter sounds come in multiple languages, so if you want English version, you need to pick the right one from the number stack. So don't be alarmed if you think you're missing some final audio files. Here are all of the 3D model tools: Edit: Here are all the tools linked to this forum instead of Mediafire: Gibbed Visceral viewer (DS2-3 archive unpacker, DS1-3 .STR unpacker) Visceral Viewer DS2-3 Parsed.rar Here is the uncompiled version of the Visceral viewer. I don't see the Dead Space 3 file list, so the version I originally received from Xentax, that I have attached, is much more up to date. https://github.com/gibbed/Gibbed.Visceral DS2-3 EAlayer (exa / snu to MP3) ds2 ealayer.rards3 ealayer.rar DS1 SNU to WAV ds1 towav snu.rar DS1-3 SBK unpack (DS2 version works with DS1 as I recall) ds2-3 sbk unpack.rar DS1 Xas decode (exa to wav or mp3) ds1 xas_decode.rar Credits go to all the original authors of these tools, I am merely reuploading them for the sake of preservation purposes and take credit only for that.
    1 point
×
×
  • Create New...