Leaderboard

I'm trying my best to make it load somehow

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

I've just released new version of ImageHeat 🙂 https://github.com/bartlomiejduda/ImageHeat/releases/tag/v0.39.1 Changelog: - Added new Nintendo Switch unswizzle modes (2_16 and 4_16) - Added support for PSP_DXT1/PSP_DXT3/PSP_DXT5/BGR5A3 pixel formats - Fixed issue with unswizzling 4-bit GameCube/WII textures - Added support for hex offsets (thanks to @MrIkso ) - Moved image rendering logic to new thread (thanks to @MrIkso ) - Added Ukrainian language (thanks to @MrIkso ) - Added support for LZ4 block decompression - Added Portuguese Brazillian language (thanks to @lobonintendista ) - Fixed ALPHA_16X decoding - Adjusted GRAY4/GRAY8 naming - Added support section in readme file

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:

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

When you choose "uncompressed" the file size should be bigger than for a DXT5 file. I'd try some other tool, maybe Gimp, for testing.

hi need help ripping and reverse engineering the Geekjam, Toejam, and the Earl models from Toejam and Earl III for a animation. below are the .funk files (which is located in the bdl folder for some reason idk) and .bmt files for each character. files for toe jammin and fateral.zip

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

So here's pixel format for ps4. PF_DXT5 = 7 PF_DXT1 = 13 PF_BC7U = 22 PF_UNKNOWN = 2 not sure but can be RGBA

I remember to make a request in your github about it. 👍 Somehow, we were not able to see these textures in ImageHeat, only after extraction and decompression. Anyway, for the Switch textures it seems to be an issue as h3x3r said above and I confirm it too. In the attachment you find all the textures in UNIFORM.TEX (including jersey-color) from the Switch version already decompressed. The stock texture file is in the Switch files in the first post (UNIFORM.TEX). In the screenshot below you see the parameters for the jersey-color texture. Maybe useful when you have time to check it to help you fix ImageHeat. UNIFORM Switch decompressed.zip

LZ4 is supported in ImageHeat.

O.K. so here's script for ps4 format. Inside unpacked file is texture width/height and pixel format all in 6 bytes. Rest is image data. Also i don't know about pixel fomat so you must figure out. get BaseFileName basename comtype lz4 getdstring Sig 0x8; get Unknown_0 uint32 get Unknown_1 uint32 getdstring Platform 0x4 get TextureCount uint32 get Unknown_2 uint32 get UnknownCount uint32 get TotalCompressedSize uint32 get TotalDecompressedSize uint32 get Unknown_6 uint32 get Unknown_7 uint32 for i = 0 < TextureCount getdstring TextureName[i] 0x40 getdstring Unknown_0 0x10 get CompressedSize[i] uint32 get Offset[i] uint32 # + BaseOffset get Unknown_3 uint32 get DecompressdSize[i] uint32 get Unknown_4 ushort get Unknown_ ushort get Unknown_6 uint32 get Unknown_7 uint32 get Unknown_8 uint32 savepos WidthHeightPos[i] get TextureWidth ushort get TextureHeight ushort get Unknown_9 uint32 savepos PixelFormatPos[i] get PixelFormat ushort get Unknown_10 ushort get Unknown_11 uint32 getdstring Unknown_12 0x4 get Unknown_13 uint32 get Unknown_14 ushort get Unknown_15 ushort get Unknown_16 uint32 getdstring Null 0x10 next i math UnknownCount * 40 getdstring UnkInfo UnknownCount savepos BaseOffset for i = 0 < TextureCount math Offset[i] + BaseOffset string FileName p= "%s/%s.dat" BaseFileName TextureName[i] append 0 log FileName WidthHeightPos[i] 4 log FileName PixelFormatPos[i] 2 clog FileName Offset[i] CompressedSize[i] DecompressdSize[i] next i

Nobody's making fun of you. However, it would have been useful if you had mentioned not having a computer at the start, instead of having people waste their time on things you can't use. It also sounds like you were harassing another user in DMs for help, which you also need to stop doing. People will help if they want to, and if they have the time.

I've moved this topic to graphic file formats, rather than 3d Models where you posted it. Also, please don't start another post for the exact same thing. I've deleted your other post as a duplicate. Please read the rules before posting again.

The game have update and they hard-coded new text in .mpk lua script, because some words have many different meaning depend on the context. With packet sniffing, i observed that the game download some .pak file from easebar.com and put them in .mpk file. These file are encrypted.

fmt_FGOArcade_mot.py Still incomplete

tool.py Here a working script that will output json file with { hash: text, ... }

I made a blender addon to import models, textures and animations for dolphin wave and other games that used the same engine. it can import lzs and lza files as is. You don't need to decrypt or decompress the files https://github.com/Al-Hydra/blenderBUM

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.

thanks 2001_800xcsled.zip 1999_440xcrsled.zip

make some ajustments! now its working

When i get home, i will compile the decompressor/compressor unpack and pck tool, is one all tool. std::vector<uint8_t> compressLZSSBlock(const std::vector<uint8_t>& input) { const int MIN_MATCH = 3; // comprimento mínimo para virar par const int MAX_MATCH = 17; // (0xF + 2) const int DICT_SIZE = 4096; const size_t n = input.size(); // Dicionário igual ao do descompressor std::vector<uint8_t> dict_buf(DICT_SIZE, 0); size_t dict_index = 1; // mesmo índice inicial do descompressor size_t producedBytes = 0; // quantos bytes já foram "gerados" (saída lógica) std::vector<uint32_t> flagWords; uint32_t curFlag = 0; int bitsUsed = 0; auto pushFlagBit = [&](bool isLiteral) { if (bitsUsed == 32) { flagWords.push_back(curFlag); curFlag = 0; bitsUsed = 0; } if (isLiteral) { // bit 1 = literal (mesmo significado do descompressor) curFlag |= (1u << (31 - bitsUsed)); } ++bitsUsed; }; std::vector<uint8_t> literals; std::vector<uint8_t> pairs; literals.reserve(n); pairs.reserve(n / 2 + 16); size_t pos = 0; while (pos < n) { size_t bestLen = 0; uint16_t bestOffset = 0; if (producedBytes > 0) { // tamanho máximo possível para este match (não pode passar do fim do input) const size_t maxMatchGlobal = std::min(static_cast<size_t>(MAX_MATCH), n - pos); // percorre todos os offsets possíveis do dicionário for (int off = 1; off < DICT_SIZE; ++off) { if (dict_buf[off] != input[pos]) continue; // --- SIMULAÇÃO DINÂMICA DO DESCOMPRESSOR PARA ESTE OFFSET --- uint8_t candidateBytes[MAX_MATCH]; size_t candidateLen = 0; for (size_t l = 0; l < maxMatchGlobal; ++l) { const int src_index = (off + static_cast<int>(l)) & 0x0FFF; // valor em src_index, levando em conta que o próprio bloco // pode sobrescrever posições do dicionário (overlap) uint8_t b = dict_buf[src_index]; // Se src_index for igual a algum índice de escrita deste MESMO par // (dict_index + j), usamos o byte já "gerado" candidateBytes[j] for (size_t j = 0; j < l; ++j) { const int dest_index = (static_cast<int>(dict_index) + static_cast<int>(j)) & 0x0FFF; if (dest_index == src_index) { b = candidateBytes[j]; break; } } if (b != input[pos + l]) { // não bate com o input, para por aqui break; } candidateBytes[l] = b; ++candidateLen; } if (candidateLen >= static_cast<size_t>(MIN_MATCH) && candidateLen > bestLen) { bestLen = candidateLen; bestOffset = static_cast<uint16_t>(off); if (bestLen == static_cast<size_t>(MAX_MATCH)) break; // não tem como melhorar } } } if (bestLen >= static_cast<size_t>(MIN_MATCH)) { // --- CODIFICA COMO PAR (offset, length) --- pushFlagBit(false); // 0 = par uint16_t lengthField = static_cast<uint16_t>(bestLen - 2); // 1..15 uint16_t pairVal = static_cast<uint16_t>((bestOffset << 4) | (lengthField & 0x0F)); pairs.push_back(static_cast<uint8_t>(pairVal & 0xFF)); pairs.push_back(static_cast<uint8_t>((pairVal >> 8) & 0xFF)); // Atualiza o dicionário exatamente como o DESCOMPRESSOR: // for (i = 0; i < length; ++i) { // b = dict[(offset + i) & 0xFFF]; // out.push_back(b); // dict[dict_index] = b; // dict_index = (dict_index + 1) & 0xFFF; // } for (size_t i = 0; i < bestLen; ++i) { int src_index = (bestOffset + static_cast<uint16_t>(i)) & 0x0FFF; uint8_t b = dict_buf[src_index]; dict_buf[dict_index] = b; dict_index = (dict_index + 1) & 0x0FFF; } pos += bestLen; producedBytes += bestLen; } else { // --- LITERAL SIMPLES --- pushFlagBit(true); // 1 = literal uint8_t literal = input[pos]; literals.push_back(literal); dict_buf[dict_index] = literal; dict_index = (dict_index + 1) & 0x0FFF; ++pos; ++producedBytes; } } // Par terminador (offset == 0) pushFlagBit(false); pairs.push_back(0); pairs.push_back(0); // Flush do último flagWord if (bitsUsed > 0) { flagWords.push_back(curFlag); } // Monta o bloco final: [u32 off_literals][u32 off_pairs][flags...][literais...][pares...] const size_t off_literals = 8 + flagWords.size() * 4; const size_t off_pairs = off_literals + literals.size(); const size_t totalSize = off_pairs + pairs.size(); std::vector<uint8_t> block(totalSize); auto write_u32_le = [&](size_t pos, uint32_t v) { block[pos + 0] = static_cast<uint8_t>(v & 0xFF); block[pos + 1] = static_cast<uint8_t>((v >> 8) & 0xFF); block[pos + 2] = static_cast<uint8_t>((v >> 16) & 0xFF); block[pos + 3] = static_cast<uint8_t>((v >> 24) & 0xFF); }; write_u32_le(0, static_cast<uint32_t>(off_literals)); write_u32_le(4, static_cast<uint32_t>(off_pairs)); size_t p = 8; for (uint32_t w : flagWords) { block[p + 0] = static_cast<uint8_t>(w & 0xFF); block[p + 1] = static_cast<uint8_t>((w >> 8) & 0xFF); block[p + 2] = static_cast<uint8_t>((w >> 16) & 0xFF); block[p + 3] = static_cast<uint8_t>((w >> 24) & 0xFF); p += 4; } std::copy(literals.begin(), literals.end(), block.begin() + off_literals); std::copy(pairs.begin(), pairs.end(), block.begin() + off_pairs); return block; } @morrigan my compressor, try it, and let me know the results.

In the ..var01.st2 csv data is contained: edit: and xml data: <!-- ______________________________________________________________________________ Copyright 2004 The Collective, Inc. DISMEMBERMENT DEFINITION Character: Clone Trooper Author: Baback Elmieh Date: 01/07/2004 ______________________________________________________________________________ --> <!-- HEAD --> <DismemberablePart Name="Head" Hitpoints="25"> <!-- The Materials section is a list of materials in the original mesh that are to be turned off when the part is dismembered --> <!-- <Materials> <Material Name="headSG"/> </Materials> --> <!-- ReactionProcessing defines the chunks and particles to be spawned when a reaction dismemberment is processed for the character the definition requires a Bone from which a chunk should be spawned and the name of the chunkmesh. The ChunkMesh definition in turn can have several values set such as GravityScale and UseGinFile. GravityScale greater than 1.0 pulls a chunk down faster, UseGinFile will look for a bounding box with the same name as the chunkmesh in the damage mesh's gin file, if the bound is found, it is used instead of the default rendering bound which can help artists orientate chunks so that they land on their correct side --> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="neck_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <!-- <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="neck_g"> <Param Name="ChunkMesh" Value="head"/> <Param Name="GravityScale" Value="1.4"/> <Param Name="RandomVelocityScale" Value="0.2"/> </Param> </Chunk> --> </ReactionProcessing> <!-- The Capsules section provides a list of capsules that should affect the hitpoint of the part and should be disabled once the chunk has been dismembered --> <Capsules> <Capsule Name="Dneck_g"/> </Capsules> </DismemberablePart> <!-- LEFT SHOULDER --> <DismemberablePart Name="Left Shoulder" Hitpoints="25"> <Materials> <Material Name="Shoulder_LSG"/> </Materials> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="shoulder_L_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="shoulder_L_g"> <Param Name="ChunkMesh" Value="Shoulder_L"/> <Param Name="GravityScale" Value="1.8"/> <Param Name="RandomVelocityScale" Value="0.1"/> </Param> </Chunk> </ReactionProcessing> <Capsules> <Capsule Name="Dshoulder_L_g"/> </Capsules> </DismemberablePart> <!-- RIGHT ELBOW --> <DismemberablePart Name="Right Shoulder" Hitpoints="25"> <Materials> <Material Name="Elbow_RSG"/> </Materials> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="shoulder_R_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="shoulder_R_g"> <Param Name="ChunkMesh" Value="Elbow_R"/> <Param Name="GravityScale" Value="1.8"/> <Param Name="RandomVelocityScale" Value="0.1"/> </Param> </Chunk> </ReactionProcessing> <Capsules> <Capsule Name="Dshoulder_R_g"/> </Capsules> </DismemberablePart> </DismembermentDefinition>

I have a basic exporter for 3ds max here https://github.com/taylorfinnell/onbadexporter

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.

Hi Shak-otay, yes it's me, I never imagined you would remember me 😄. I found this texture in the file.

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.)

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. 🙂

What I'm trying to do is create a new texture and trying to add an alpha channel while hex editing. The Zip File I provided is mostly for demonstration purposes. I'm trying to edit NINJA_FACE_DAMAGE_000, NINJA_FACE_DAMAGE_001, and NINJA_FACE_DAMAGE_002. My biggest problem is that the textures I'm trying to add an alpha channel to is different than it's original textures and is swizzled differently thus the alpha channel will be different. I am aware the image data will always start at 592 (0x250) and palette data differs depending on the size of the texture 64x64 (0x12A0), 128x128 (0x42A0), 256x256 (0x102D0). Anyways, I was able to use ImageHeat to get an alpha channel from the original textures with PAL8 pixel and RGBA8888 palette and exported it. Also, was able to use the ReverseBox Demo 2 to export and import the original textures just to get familiar with it. These are just a few textures that I'm trying to insert into the game and the alpha channels. MKD Texture Edit.zip

I used the files from the zip, iirc. But seems, you're too late to the party...

Here's a sample model for one of the enemies in the game. Notice that "*_div.msb" can't be view/export properly for some reason, but the base one did just fine. PSVitaSample.zip

fmt_psaVita_ValkyrieDrive.py Here's a old noesis plugin to view and export most of the mib, msb and mab of the PSVisa version of the game.

rename it to .awb files then use the lastest vgmstream, works well

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

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

I've been doing a Noesis script for the beta of Once Human. Still got a few things to do on it, but it should work for most of the models so far: Edit: Read the notes at the start of the script regarding the various files needed. once_human_mesh.zip

Bump numero 3

for the mcgregors normal you can use this bms Decompressor.zip

I know I’ve already posted my progress with materialising Mike Tyson but I thought I’d show these also as I managed to convert the normals from green to purple which for me personally and unity mods it works better

I've just released a new version of ImageHeat 🙂 https://github.com/bartlomiejduda/ImageHeat/releases/tag/v0.31.2 Changelog: - Added new pixel formats: APLHA4, ALPHA4_16X, ALPHA8, ALPHA8_16X, RGBA6666, RGBX6666, BGRT5551, BGRT8888, PAL8_TZAR, BGRA5551, BGRA5551_TZAR, BGRA8888_TZAR, BGRA4444_LEAPSTER - Added support for LZ4, Emergency RLE, Neversoft RLE, Tzar RLE, Leapster RLE, Reversed TGA RLE - Fixed issue with x360 swizzling - Fixed issue with PS Vita/Morton swizzling for 4-bpp images - Added support for palette values scaling (1x, 2x, 4x, 8x, 16x) - Added dropbox for palette scaling in "Palette Parameters" box - Added funding info

in the end, I did it, thanks to everyone who posted on this topic.

My script for another game should work with these GSB files: https://github.com/DKDave/Scripts/blob/master/QuickBMS/GameCube/Legend_Of_Spyro_New_Beginning_(GameCube)_GSB.bms

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

Bumping this, if anyone would be an absolute unit to solve the animations it would be greatly appreciated! 🙃

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

Mostly, PNG files are decompressed, so it's fairly easy to edit and reimport them. However, you need to compress your PNG files using the site iLoveIMG. For example, if the original PNG is 10 KB, your PNG must be 10 KB or less, so you will need to compress it on the site. I’ve attached 3 files: Two BMS scripts: One script will unpack the data, decompressing all files. The other script will unpack the file without decompressing it (this is the one you should use for reimporting; reimport with -r, not reimport 2 in quick bms). A Python script (.py): This program decompresses and compresses zlib files individually. I have set a compression level to reduce the file size even further. Use this if you need to handle compressed files. zlib_DeCompressor.py BMS.ZIP

The WAVE files just use XBox ADPCM (not that obscure) and you can play and convert them with Foobar + vgmstream (note: some files don't contain audio). You don't really need to do anything else.

Well, it's not a model delivery forum.😁 Trying to make some tool (seems there's up to 9 lods for the coat at least.) Some weird stuff, too. Not sure, whether I should leave it as is.

Guys just close this post make no sense, The forum is new in 3d category are 260 post and 4 of this are with the same title "please help .......3dunity". Please search first in forum if exist a answer next make post. Its more easy if collect all the info for type of file in 1 place, honesty the old xentax have guys who redirect to main post if some1 go like this for every little thing. And I see the OP make 3 post in row 5 min from each other for almost the same thing. Just start over this obvious goin anywhere.