Leaderboard
Popular Content
Showing content with the highest reputation since 11/20/2024 in all areas
-
Version 1.2.0
128 downloads
Dragon Age The Veilguard tools. Work same as my previous frostbite tools. toc_dav.exe - dump tool Change .ini file parameters: - game path - dump path - selection to dump "ebx", "res", "chunks" or "all" Place oo2core_9_win64.dll from the game next to the tool. Then drop any .toc file onto .exe to dump assets. Or run from command line with 1 parameter - toc file name. Main file is default.toc, voice files are inside subfolders - en.toc and other languages Fb_dav.exe - model tool Takes .MeshSet as parameter. rgz_skeleton.ebx - main universal skeleton for all humanoids. Must be in the same folder. Game has 2 skeletons with this name, you need the one from "techanim" folder, which is bigger. If you need another skeleton, use its name as 2nd parameter. Or rename it to rgz_skeleton.ebx. Tool will try to find chunks automatically. If not, it gives error message with chunk name. Set of smd files - to fix distorted faces They are 2-frame animation files to transform head model to its normal state.8 points -
Tool v1.2 posted. Work is not finished, i'm looking into getting custom characters now. Also maybe i can get real hairs later. Textures not supported yet, but they can be extracted with tools for other frostbite games.6 points
-
Try this # Wolfenstein II: The New Colossus (0.3.1a) # script for QuickBMS http://quickbms.aluigi.org # Edited for Indiana Jones and the Great Circle comtype oodle # .resources, .pack and so on idstring "IDCL" get VER long # 13 in Indiana Jones and the Great Circle getDString HASH 8 get Unk long # 116 New var in Indiana Jones and the Great Circle get ZERO long get DUMMY long # 1 get DUMMY long # -1 get DUMMY long #get DUMMY longlong get FILES long get DUMMY_NUM long get DUMMY2_NUM long get FILES_2 long get ZERO longlong get DUMMY2 longlong get NAMES_OFF longlong get DUMMY4_OFF longlong get INFO_OFF longlong get DUMMY6_OFF longlong get DUMMY7_OFF longlong get DATA_OFF longlong goto NAMES_OFF get NAMES longlong for i = 0 < NAMES get NAME_OFF longlong putarray 0 i NAME_OFF next i savepos NAMES_OFF for i = 0 < NAMES getarray NAME_OFF 0 i math NAME_OFF + NAMES_OFF goto NAME_OFF get NAME string string NAME % "$" string NAME | "#" putarray 0 i NAME next i # thanks toxic72 https://zenhax.com/viewtopic.php?p=27774#p27774 goto DUMMY7_OFF for i = 0 < DUMMY2_NUM get DUMMY long next i savepos DUMMY7_OFF goto INFO_OFF for i = 0 < FILES get ZERO longlong get DUMMY longlong # 1 get DUMMY longlong # -1 get TYPE_ID longlong get NAME_ID longlong get ZERO longlong get ZERO longlong get OFFSET longlong get ZSIZE longlong get SIZE longlong get DUMMY longlong get DUMMY long get DUMMY long get DUMMY longlong get DUMMY long # ZIP related? get DUMMY long # ZIP related? get ZIP_FLAGS longlong # 0, 2, 4, 0x210002, 0x410002 and so on get ZERO longlong get FLAGS long # 2 get FLAGS2 long get ZERO longlong math TYPE_ID * 8 math TYPE_ID + DUMMY7_OFF math NAME_ID + 1 math NAME_ID * 8 math NAME_ID + DUMMY7_OFF savepos TMP goto TYPE_ID get TYPE_ID longlong goto NAME_ID get NAME_ID longlong goto TMP #getarray STR1 0 TYPE_ID getarray STR2 0 NAME_ID #string NAME p "%s/%s" STR1 STR2 string NAME p "%s" STR2 if SIZE == ZSIZE log NAME OFFSET SIZE else if ZIP_FLAGS & 4 if ZIP_FLAGS & 1 # no idea but ZIP_FLAGS 5 doesn't need the +12 else math OFFSET + 12 math ZSIZE - 12 endif endif clog NAME OFFSET ZSIZE SIZE endif next i for mus_ packs only MediaID in pack itself narrative_ and systemic_ packs has full wem names3 points
-
3 points
-
3 points
-
3 points
-
I'm working on a set of tools for Dragon Age Veilguard. So far, i have dump tool to extract all files, all models can be converted. Also i have fixed the usual frostbite distorted faces. Now checking if something needs to be done with unified skeleton or textures, and then tools will be published here.2 points
-
Updated script. the last version felt incomplete and for if someone is busy making a blender plugin. There is still too much of this file I don't understand before I would even attempt it. I also don't have ready access to an XP machine to reverse engineer the SDK. Script unpacks all .QOB(Weapons and items), .POB(Vehicles), .CHR(Characters), and .MAP(Map files) into .OBJ, it does not correct positioning data, all extra data is unpacked into a text file. If I have missed something please let me know. Thanks to @alexkimov for 010 Editor templates, they are available on his github repo along with a slew of other filetypes. Ghost Recon_convert.py2 points
-
010 Editor Template... I am sooo lazy to rewrite it to the noesis python script. //------------------------------------------------ //--- 010 Editor v14.0 Binary Template // // File: // Authors: // Version: // Purpose: // Category: // File Mask: // ID Bytes: // History: //------------------------------------------------ OutputPaneClear();LittleEndian(); local string FileName=GetFileName(),FilePath=FileNameGetPath(FileName,true),BaseName=FileNameGetBase(FileName,false); local uint32 i,j,k,l; local string ShapeNum; typedef struct Matrix4x4 { float Mat00,Mat01,Mat02,Mat03, Mat10,Mat11,Mat12,Mat13, Mat20,Mat21,Mat22,Mat23, PosX,PosY,PosZ,PosW; }; struct { char Sign[4]; uint32 Unk0,TypeInfoOffset,TypeNameIndex,Unk3,Unk4,Unk5,BoneNameIndex,ShapeNameIndex,Unk8,Unk9; float Value[7]; }Header; struct { FSeek(sizeof(Header)+Header.TypeInfoOffset); uint32 TypeNameOffset[Header.TypeNameIndex]; uint32 ShapeNameOffset[3]; }TypeIndexInfo; struct { float Unknown[12]; }UnknownInfo; if (Header.BoneNameIndex != 0) struct { struct { uint32 BoneNameOffset,SkinNameOffset,Dummy; Matrix4x4 matrix4x4; uint32 BoneIndex; uint32 Null[7]; }BoneIndex[Header.BoneNameIndex]<optimize=false>; }BoneIndexInfo; struct { struct { uint32 Unk0,ShapeNameOffset,Unk1; float Unk2,Unk3,Unk4,Unk5; uint32 ShapeIndexNum,IndexCount,IndexOffset,VtxCount,Unk6,Unk7,Unk8[14]; local string ShapeNameStr=ReadString(sizeof(Header)+ShapeNameOffset,-1); }ShapeIndex[Header.ShapeNameIndex]<optimize=false>; }ShapeInfo; struct { local uint32 IndexBaseOffset=FTell(); for (i=0; i < Header.ShapeNameIndex; i++) { FSeek(IndexBaseOffset+ShapeInfo.ShapeIndex[i].IndexOffset*6); struct { byte IndexData[ShapeInfo.ShapeIndex[i].IndexCount*6]; }IndexBuffer; } }IndexBuffers; struct { for (i=0; i < Header.ShapeNameIndex; i++) { struct { uint32 Unknown,VtxBufferSize; local uint32 Stride=VtxBufferSize/ShapeInfo.ShapeIndex[i].VtxCount; }StrideInfo; } for (i=0; i < Header.ShapeNameIndex; i++) { struct { byte VertexData[StrideInfo[i].VtxBufferSize]; }VertexBuffer; } }VertexBuffers; FSeek(startof(VertexBuffers)); struct SHAPE { for (i=0; i < Header.ShapeNameIndex; i++) { SPrintf(ShapeNum,"_%u",l++); FSeek(startof(VertexBuffers.VertexBuffer[i])); if (VertexBuffers.StrideInfo[i].Stride == 44) struct { float VPosX,VPosY,VPosZ,Unk0,Unk1,VNPosX,VNPosY,VNPosZ,Unk2,UVPosX,UVPosY; Printf("v %f %f %f\nvn %f %f %f\nvt %f %f\n",VPosX,VPosY,VPosZ,VNPosX,VNPosY,VNPosZ,UVPosX,-UVPosY); }VtxBuffer[ShapeInfo.ShapeIndex[i].VtxCount]<optimize=false>; else if (VertexBuffers.StrideInfo[i].Stride == 48) struct { float VPosX,VPosY,VPosZ,Unk0,Unk1,Unk2,VNPosX,VNPosY,VNPosZ,Unk3,UVPosX,UVPosY; Printf("v %f %f %f\nvn %f %f %f\nvt %f %f\n",VPosX,VPosY,VPosZ,VNPosX,VNPosY,VNPosZ,UVPosX,-UVPosY); }VtxBuffer[ShapeInfo.ShapeIndex[i].VtxCount]<optimize=false>; else if (VertexBuffers.StrideInfo[i].Stride == 52) struct { float VPosX,VPosY,VPosZ,Unk0,Unk1,Unk2,Unk3,VNPosX,VNPosY,VNPosZ,Unk4,UVPosX,UVPosY; Printf("v %f %f %f\nvn %f %f %f\nvt %f %f\n",VPosX,VPosY,VPosZ,VNPosX,VNPosY,VNPosZ,UVPosX,-UVPosY); }VtxBuffer[ShapeInfo.ShapeIndex[i].VtxCount]<optimize=false>; Printf("g shape_%s_%u\n",BaseName,ShapeInfo.ShapeIndex[i].ShapeIndexNum); FSeek(startof(IndexBuffers.IndexBuffer[i])); struct { uint16 F1,F2,F3; Printf("f %u/%u/%u %u/%u/%u %u/%u/%u\n",F1+1,F1+1,F1+1,F2+1,F2+1,F2+1,F3+1,F3+1,F3+1); }IdxBuffer[ShapeInfo.ShapeIndex[i].IndexCount]<optimize=false>; OutputPaneSave(FilePath+BaseName+ShapeNum+".obj"); OutputPaneClear(); } }; //local SHAPE Shape; If you want export them just remove two slashes on last line2 points
-
2 points
-
I tweaked your script to make it more versatile: Now, it is able to import to Noesis models in rsf files with data in little (PS Vita) and big endian (PS3) as well as vertices block formats with data as SHORT. The script should work for most rsf files from Madden 25 (from the year 2014) to Madden 17 PS3 and Madden 13 PS Vita. I also checked rsf files before Madden 25 as Madden 13 and 12 for PS3. I was not able to get the correct data to import the full models. Besides the MESH blocks those files from Madden 13 and 12 have JOBM blocks too, I guess, it should be related to some of the meshes, see the screenshot. The updated script is in the attachment. fmt_madden_rsf.py2 points
-
I dumped all sections from the soundmetadata.bin file, maybe it will be useful to someone Dump_soundmetadata.bin.zip2 points
-
Hello, I've got some examples of some game engine files from the proprietary game engine used to make the BIT.TRIP games, a series Wiiware games made in the early 2010's. Almost all files contained in the attached file have file types that start with ".ae", followed up by a couple extra letters for each file type. There seem to be three notable exceptions to this. Firstly, all sound files are stored as .OGG's, and can be opened normally. These files contain everything from sound effects, cutscene audio, and the soundtracks used in game. Another file type that breaks the ".ae" convention are the .collision files. One of these files exist for each level, and each one varies greatly in size. Despite the odd file type, the contents can be viewed normally through a basic text editor. Each file contains a series of decimal values, each one being separated by a comma. An observation that gives insight as to what these files do is that levels 1 and 2, 3 and 4, and 5 and 6 each have similar sized .collision files (i.e, levels 1 and 2 have collision file sizes of 22KB and 18KB, whereas levels 3 and 4 have collision file sizes of 9KB and 4KB). Each pair of levels share a similar theme, and each theme has varying levels of obstacles that cannot be fired through. Levels 3 and 4 both lack obstacles for the most part, whereas the other four levels all have numerous obstacles throughout. Therefore, it's likely that these decimal values each map to the hitbox of the obstacles placed throughout the levels. the final deviation from convention is the .vs folder under the FATE/Hell/Layouts file path. this contains various json files along with other file types that I haven't seen before (what on earth is the file at the bottom of the FATE/Hell/Layouts/.vs/Layouts/FileContentIndex?) The remainder of these file types, as stated prior, are files made by the proprietary game engine used to make this game. Viewing and modifying these files are restricted to bitwise modifications via hex editors, and are much harder to modify without breaking things. That being said, the names of each .ae file betray their probable purposes. .aetex files store 2D texture information. most of these files are under the "Textures2D" folder. .aescn files store a variety of 2D and 3D objects. these files are stored throughout the whole game. These are used for the cutscenes, level backgrounds, player 2D models and animations, and all of the 3D models in the game. .aemenu files store information about the game menus, including those that display the final score for a level, the level select menu, and the startup menu. Interestingly, the GAME OVER screen is stored as an .aescn file, and not an .aemenu file, which explains how the player isn't booted back to the menu upon defeat in game, but instead is sent back to the start of the level. the .aeefx file type only appears one time under the Effects directory. the file "General.aeefx" doesn't have any obvious hints as to what it might contain (beyond the obvious "it contains game effects" observation). An interesting thing to notice is that the games files are split between two directories, a "General" directory and a directory called "Hell". The BIT.TRIP series released six games on wii ware, each of them having multiple instances of shared assets throughout. the "General" directory contains those reused assets, whereas "Hell" contains the assets from this particular BIT.TRIP title. Underneath the "General" directory is another file type labeled as .aeshader, which contains (you guessed it) shaders. Though these files are stored under the "Shaders" directory, the names attached to the .aeshader files makes it difficult to gauge what each file governs exactly. Lastly, the fonts used for this game are stored in .aefnt files. three of these files exist, with the difference between the three being unclear. I've attached some examples of the game engine files for those that wanna mess around with them, have fun and make friends! AtrophyGameEngineFileTypes.zip2 points
-
2 points
-
I see. Will have to calculate the count manually in this case. What I can tell with some examinations: 1 float quat[4]; 2 float quat[4]; float quat2[4]; 4 float tran[4]; 7 float tran[4]; float tran2[4]; 0xD short quat[4]; 0x10 short tran[4]; For type 2 & 7 using the first key component the anim appeared to be shifted to a different origin, but the two anims seem identical: Code for anim 46 in henry01.bin (same GUI options): calc animBase[=][0x5EE80] seek address[animBase] byte skip[0x14] long hdrOffset calc hdrOffset[+][animBase] seek address[hdrOffset] long skip[2] calc curPos[=][0] tell address[curPos] long boneCnt calc boneCnt[-][0xC] calc boneCnt[/][4] seek address[curPos] begin loop[boneCnt] long offset assert offset[>][0] calc offset[+][hdrOffset] push offsetList[offset] end loop[boneCnt] begin loop[boneCnt] value offset[offsetList][boneIdx] seek address[offset] word type word skip word keyCnt word boneIndex long timeOffset long keyOffset calc timeOffset[+][offset] calc keyOffset[+][offset] typedef dataType[short] calc eleType[=][-1] // 0 = T, 1 = R calc skipSize[=][0] test type[==][1] begin scope typedef dataType[float] calc eleType[=][1] end scope test type[==][2] begin scope typedef dataType[float] calc eleType[=][1] calc skipSize[=][16] end scope test type[==][4] begin scope typedef dataType[float] calc eleType[=][0] end scope test type[==][7] begin scope typedef dataType[float] calc eleType[=][0] calc skipSize[=][16] end scope test type[==][0xD] calc eleType[=][1] test type[==][0x10] calc eleType[=][0] assert eleType[>=][0] // check for unmatched scenarios test eleType[==][0] begin scope seek address[timeOffset] word tKeyIndex[keyCnt] seek address[keyOffset] begin loop[keyCnt] byte skip[skipSize] dataType Translation[4] end loop[keyCnt] end scope test eleType[==][1] begin scope seek address[timeOffset] word rKeyIndex[keyCnt] seek address[keyOffset] begin loop[keyCnt] byte skip[skipSize] dataType Rotation[4] end loop[keyCnt] end scope end loop[boneCnt]2 points
-
I finished my Evil Genius 2: World Domination * load module and I released the following programs: - 3D Object Converter v11.004 (Windows) - 3D Object Converter v1.004 (AmigaOS) How to get the 3D Object Converter (Windows) v11.004: Download the 3D Object Converter from http://3doc.i3dconverter.com and install it or download and use the portable version (if you donβt have it yet). (Or just use the Help/Check for updates... function to get the v11.004.) How to get the 3D Object Converter (AmigaOS) v1.004: Download the 3D Object Converter from http://3doc.i3dconverter.com and install it or download and use the portable version (if you donβt have it yet). (Or just use the Help/Check for updates... function to get the v1.004.) Evil_Genius_2_World_Domination_Helicopter.zip2 points
-
I have already made a plugin for NHL 21 (PS4) and NASCAR 08 (PS3) (*rsf) *(and if I remember correctly and they all have different MESH blocks, yours is no exception. regarding UVS, vertices and UVS can be in different STRMs, this is indicated in the MESH blocks)2 points
-
Unzip appended zipped H2O files. Load Dolphins Madden 13 PC Vita.rsf into hex2obj, then choose File\SaveAs Mmesh unresolved: 73 objx H2O 6 vCnt 299 versa maxFI 266 see 5_H2O 94 objx H2O 7 vCnt 2262 versa maxFI 8 ?? 95 objx H2O 8 vCnt 1352 versa maxFI 8 see 10_H2O Python script to import multiple obj files. Create a text window in blender, copy code into it, press alt-p to execute: (path adjustment required!) import os import bpy # http://blender.stackexchange.com/questions/5064/batch-import-wavefront-obj # put the location to the folder where the objs are located here in this fashion # this line will only work on windows ie C:\objects path_to_obj_dir = os.path.join('D:\\', 'test\\objects') # get list of all files in directory file_list = sorted(os.listdir(path_to_obj_dir)) # get a list of files ending in 'obj' obj_list = [item for item in file_list if item[-3:] == 'obj'] # loop through the strings in obj_list and add the files to the scene for item in obj_list: path_to_file = os.path.join(path_to_obj_dir, item) bpy.ops.import_scene.obj(filepath = path_to_file) edit: uvs are half floats, example: 0x1EEDE0 1650 Vb1 12 99 0x10A1F3 928 020100 0x10CD90 12 Fix needed: about half of the H2Os with uv have a wrong uv addr. edit2: 22 of them fixed. 8 remaining H2Os (_0.H2O to _7.H2O) have an uv addr 0x0. DOLPHINS-Madden 13 PS Vita.RSF_H2O.zip DOLPHINS-Madden 13 PS Vita.RSF_H2O-uvs.zip2 points
-
For short, extract the skeleton with ASH, export it as *.end, then open the anim in ARC and import the *.end skeleton. Code the layout, hit the Compile button to check for any grammar mistakes; press the Execute button to execute the layout context. Pick the correct GUI options and press Convert to convert the read animation data. Then you're free to check the result with the Preview button. Layout for "henry01_1st_animation" (the original animated bone count is 1-off so there's a fix on it): seek address[0x10] long boneCnt calc boneCnt[+][1] seek address[0x48] begin loop[boneCnt] long offset calc offset[+][0x40] push offsetList[offset] end loop[boneCnt] begin loop[boneCnt] value offset[offsetList][boneIdx] seek address[offset] word type word skip word keyCnt word boneIndex long timeOffset long keyOffset calc timeOffset[+][offset] calc keyOffset[+][offset] test type[==][0x10] begin scope seek address[timeOffset] word tKeyIndex[keyCnt] seek address[keyOffset] begin loop[keyCnt] short Translation[4] end loop[keyCnt] end scope test type[==][0xD] begin scope seek address[timeOffset] word rKeyIndex[keyCnt] seek address[keyOffset] begin loop[keyCnt] short Rotation[4] end loop[keyCnt] end scope end loop[boneCnt] Have fun!2 points
-
no, because the matrices are in local coordinates, and the file structure is chunky, so to get the skeleton you need to write at least a script. i made plugin for Noesis for [*.evo]2 points
-
I see, it seems that some values after the countchar pointers of some files have some variations. I will fix it later.2 points
-
I'm someone who is interested in extracting files from games that intrigue me! I'm not usually successful but I do find it interesting! I am a bit socially anxious at times and prefer to lurk but I am somewhat willing to chat if approached and will likely ask questions. I hope to help out when I can!2 points
-
Hi I have files from a Madagascar game for the ps3 version file format is res can you make a Noesis plugin. https://www.dropbox.com/scl/fi/giwogj72c64gptj2rcmza/DreamWorks-The-Penguins-of-Madagascar-Dr.-Blowhole-Returns-Again.rar?rlkey=f3pwtgjs7d37928qr842p70ug&st=hm75ny1y&dl=0 Thanks π2 points
-
2 points
-
Oops, my bad. Thanks for pointing me out! And thanks for your effort!! Fortunately, Joschuka has updated the addon, so everything works fine now! I am not sure whether I have the right to redistribute his addon here, but you can <removed by moderator> to find that updated addon instead. You can use this tool made by DeathChaos25 instead fdata_dump2 points
-
2 points
-
1 point
-
Hi, we already have a Noesis plugin for SH4 Xbox characters(meshes and skeleton), thanks to Durik256 and alanm1: SH4 Xbox characters & skeleton So now I want to know if it is possible to extract animations too. I analyzed animations format and this is my research: Ok, first a reminder, .bin files have a main header. First 4 bytes of this header tells you the number files or parts and then pointers to each part, I am using henry01.bin, most of all pointers go to animations, just last 3 pointers go to mesh, textures and shadow. I cut the 1st animation to analyze it better:1 point
-
1 point
-
Welcome. There is a download section specifically for BMS scripts and other applications. In here you should only put link to it.. https://reshax.com/forum/28-scripts-or-other-utilities/1 point
-
I am a volunteer translator of games as a hobby. Thank you so much for writing me valuable information and distributing your own tools. Best regards.1 point
-
1 point
-
@lorak: yep, FVF size 24 for vertices appears sporadically. Same goes for uvb size of uvs in big endian rsf files (20 instead of 12). Zipped H2Os for big endian "DOLPHINS -Madden 25 PS3.RSF" (only uvs of _0, _2 and _3.H2O are correct, after uvbsize was manually changed from 12 to 20). Unzip appended zipped H2O files. Load "DOLPHINS -Madden 25 PS3.rsf" into hex2obj, then choose File\SaveAs Mmesh Use py file from here to import obj files into blender. For higher blender version read this from lorak. edit: some uvs still wrong DOLPHINS -Madden 25 PS3.RSF_H2O-uvs.zip1 point
-
Here's Make_obj source. It includes most functions which Make_H2O has (except for Create_H2Os()). (It might only help you if you're a coder.) (Make_H2O.exe for RSF will be released as soon as it's confirmed to work with another sample.)1 point
-
I'm sorry. In the meantime I found out where the game text file is located. Simple notepad++ editable .txt and .str files. You can open the Common.kpf file in the game's main folder with winrar and there they are. π1 point
-
My guess, some of the bits indicate whether it's tran, rot or scal, the other bits stands for the actual data types and component count. You'll have to compare with different cases to find the rules. Or perhaps check the C code for any suspicious enum types.1 point
-
1 point
-
Well, that c code is an information overkill for me. I'd start it simpler, here's an assumed animation curve of a bone: (integer list at 0x5AA0 with 27 values should be the time line, 4 values skipped, 4, 0C etc ) The 27 points at 0x5AE0 are floats. At 0xCAB0 a frame with 42 integer points (shorts): Still we don't know which frame blocks belong to which bones. I did a signature check (2 DWords): 1C 3C 58x 1C 4C 20x 1C 5C 13x 1C 6C 9x 1C 7C 3x 1C 8C 6x 1C 9C 2x 1C AC 2x 1C BC 5x 1C CC 2x ------------ 10 80 76x 10 90 61x ------------------ 14 44 9x 14 54 4x 14 74 7x 14 84 3x 14 A4 3x 14 B4 1x 14 D4 1x Sadly the sum of highest counts (58, 76, 61) exceeds 170, so I'm wrong here? (The DWord before those 2 DWs (1C000000 8C000000 for example) is the count of frame lines in the specific frame block. 0x35 = 53 decimal at 0x407B8.) edit: the high counts seem to be wrong because of uncomplete signature search: for 0000 10000000 80000000 there's 3 findings only. For 0000 1C000000 3C000000 still 58 results but 44 to be subtracted (DWord being 0) so 14 findings remain. Good. But not checked now...1 point
-
Guessing π And some experience in finding graphics. You can choose one of the formats supporting alpha channel ("A" instead of "X" in the name). When you export the file and open it in GIMP, you could insert any background you want.1 point
-
Spiderman2 Obb . Spider-Man 2 OBB dumper (Gameloft) . 0xcd [spiderman2_obb.bms] QuickBMS spiderman2_obb.zip1 point
-
1 point
-
Try something like that. local uint32 Count = 50; struct { uint16 Index; } Buffer[Count] <optimize=false>; local uint16 maxValue = 0; // Initialize max value local uint32 i; // Loop counter // Iterate through the Buffer array for (i = 0; i < Count; i++) { if (Buffer[i].Index > maxValue) { maxValue = Buffer[i].Index; } } // Output the maximum value PrintF("The highest value is: %u\n", maxValue);1 point
-
@Kanbara: your Cethleann link links to Joschuka. Using Joschuka's dll I get skeletons at least: InitLocal Get console cmd CreateContext Prepare buffers Get offsets to relevant sections chunk 0, 18 chunk 1, 1cc G1MS chunk 2, b58 G1MM chunk 3, 11e8 G1MG Split between int/ext skels Get ptrs to skels Merge or not Start skel merging Add physics bones Parse all NUN chunks NUNV NUNS SOFT Build merged skel Ext skels NUNO chunks NUNV chunks NUNS chunks Skel names Anims Get geometry Get matrices Process geometry data The bayo.log in the Noesis folder might get some extension for "Get geometry".1 point
-
To make a more detailed analysis you could export from Noesis (including "Additional animation output") then import to blender. Maybe use FBX for it. I tried .dae and there's some issues. (But for me imported dae anims always had issues in blender, haha, so dunno whether those are related to what the _fmt_sof_skin.py produced in Noesis.) edit: used FBX and I don't see an issue (not being too familiar with anims, though). The root bone moves a little bit strange at the end of the jump, maybe.1 point
-
btw, who's the author of the py script? MrAdults (Rick) himself? Which Noesis version did you use? With latest Noesis I get an error: Traceback (most recent call last): File "X:\noesisv4474\plugins\python\_fmt_sof_skin.py", line 48, in checkSkinLoad loadTexture = LoadTexture(textureFileName) File "X:\noesisv4474\plugins\python\_fmt_sof_skin.py", line 352, in __init__ self.parse() File "X:\noesisv4474\plugins\python\_fmt_sof_skin.py", line 363, in parse texture.name = os.path.splitext(self.textureName)[0] AttributeError: 'NoneType' object has no attribute 'name' edit disabled the texture. What's the problem? That the frog fades away upwards?1 point
-
I guess we can mark this as solved. There is still a lot unknown, but i managed to manually rebuild 12 models in just 4 days now which means 6 days to go until i rebuilt the whole game. I wrote down the correct vertex count for every model that i find in this process, so even that information is no longer relevant. What i did find out in the mean time is that vertex blocks after the regular vertices are not trash or LODs (the game has no LODs), they are literally points exactly between 2 vertices, basically the center of the edge connecting them. This is why it's very easy to find the correct vertex amount. It's very obvious and easy to detect these edge centers on models with such a low vertex count: just select 3 suspicious vertices and if one of them is exactly at the average center of all 3, delete it. You do that as long as possible until you come across the first vertex that is obviously part of the model. It helps a lot that vehicles in this game all have roughly the same vertex count, between at least 145 and up to 252. I used these settings in hex2obj: Step 1 start address 0x48, set PtCld, click "go1" Step 2 FVF size 12, click "go2" Step 3 enter start address found at 0x1C and enter a nice number for "count", the largest count i found yet is 481, click "go3" and then click "mesh" to get the point cloud as obj file. Upload this obj file to an online obj - fbx converter, because 3ds max does not import obj files that contain only a point cloud. Done. β¬DIT: Adding 12 decimal to the start address is not required because these 12 bytes basically just generate a vertex at position 0, 0, 0 that can be deleted together with all other garbage vertices that are sitting around the center of the model.1 point
-
I've just released new version of ImageHeat https://github.com/bartlomiejduda/ImageHeat/releases/tag/v0.3.8 Changelog: - Added support for endianess change - Added support for exporting images to DDS/PNG/BMP formats - Added support for ABGR4444 pixel format - Updated dependencies - Added support for XBOX 360 swizzling - Changed default pixel format to RGB565 - Fixed issue with program's icon1 point
-
A bit of both, after formatting everything as Ints, I noticed that one block you mentioned has different data near the end. Turns out the normals are grouped first, then the UV group follow after.So what I thought was fvf size of 20, was actually first 12, then 8. Learnt something new. Was fun while it lasted. π π1 point
-
I'm pretty sure this file stores the in-game text, using a simple compression algorithm (you can see some readable text with a hex editor) But I tried some popular compression algorithms (lzss, lz77, etc.) and they couldn't decompress the game text correctly. I would be very grateful if you could help me analyze the compression algorithm of this file or write a bms script mes_all.zip1 point
-
1 point
ResHax.com: Empowering Curious Minds in the World of Reverse Engineering
Delving into the Art of Code Unraveling: ResHax.com - Your Gateway to the Thrilling World of Reverse Engineering, Where Curiosity Meets Innovation!