Leaderboard

I'm looking at the textures/materials now, trying to allocate them properly. Just a few tests so far:

please update the script ! if you would be so kind.

Yes, but it's still in progress, not ready to upload it yet while I iron out a few issues.

Here's an initial Noesis script for the TMD2 mesh files. I've probably made some assumptions with the format, so I don't know if it'll work for other tmd2 files that I don't have samples for. It doesn't load the textures/materials as yet, mainly because I'm not 100% sure on how they're referenced, but it will do vertex colours and the bones should also work. bleach_rebirth_tmd2.zip

Yeah, original scripts don't seem to account for all of the different vertex formats, so a lot of meshes won't work. I can get the skeleton working by doing some manual extracting of the data. I'm not sure if the original script author(s) will update theirs. If not, I may do an updated one at some point.

Another update. Should load almost everything now. Since the last updated, I've integrated reading of the textures and created the materials for each submesh, so they should display correctly. No need to decompress any files first, just load a tmd2 file and it will load the matching texture file. There are issues with some hair meshes - some of them don't seem to have proper textures, maybe they're handled differently, not sure. There are still some texture types that I'm not sure about - they could be specular, metallic, or whatever. As always, it's still a work in progress. bleach_rebirth_tmd2.zip

Still working on materials. Diffuse/Normal maps look ok. But still quite a way to go.

You can use this Noesis script to get the textures from the LDS files. Not sure how the textures are integrated into the materials to allocate to individual submeshes. rebirth_lds.zip

tm2 and lds its zlib lds after unpack (dds texture) tm2 after unpack (3d model) structure: 8 bytes magic(PZZEtmd2) uint decSize uint zero uint ofsData uint zero bytes* comData EDIT: i made qbms script BLEACH_TM2_LDS.bms

So I've been following this thread from today, seeing all the progress as it comes. My main aim from the beginning was to find Tier's files and edit her to the authentic look. I've been able to find an alternate, albeit possibly outdated now, method of revealing the full 3d models for the files in Noesis. The python plugin is a slight change to DKDave's code that I found earlier in the thread (same file name). It forcibly commits all triangle data to a single mesh, essentially forcing all vertices and submeshes to appear. Maybe someone can benefit from this potential checkpoint? Can't wait to see what modding brings for this amazing game. I'll continue trying to fiddle with the textures tomorrow! Biggest thanks to DKDave again, doing the Soul King's good work. bleach_rebirth_tmd2.py

Just a small update to add a few more mesh types from the additional samples provided. bleach_rebirth_tmd2.zip

Is there a specific file you're having trouble with inside that archive? These appear quite similar. e.g. 0000000000000000_unpack.seg is uncompressed 8-bpp indexed pixels 512x1024 starting at 1600h and a palette at 200h. (you'll have to tell me if the red and blue channels are reversed, since you've played the game)

Thanks ! it works Script for noesis after decryption I'm sorry that i forget who wrote this. it's from xentax fmt_tamsoft_tmd2.py

Can't open with old tmd2 script Sample Files included chara.zip

as too will I

so i figured that this method would be used in order to get the line details for the models. unless there's a texture that i am missing missingin some way i would presume?

ah, I may have been using the wrong addon version. I changed it and used the 64 bit and it works fine. Thanks :)

I'll have to try to identify which submeshes only use vertex colours and then set them according to that. I think the heads and hair mostly are in the same positions as well. Making a bit more progress.

Exporting as fbx/dae will preserve the vertex colors. Idk about gltf.

Yeah, I've got lots of files for testing, although there's about 1,700 tmd mesh files, so I probably won't check every single one myself. Still having a few issues with materials, but some of the non-working ones will now load - pl036 and pl038 above. Materials still aren't perfect yet, so still looking into those.

Looking to see if anyone is interested in this, 3D models/geometry isn't exactly my strongest skillset (which I'm sure you will soon notice). I was originally inspired by an old thread on Xentax for other Rareware games (primarily Grabbed by the Ghoulies) however Live and Reloaded seemed to get skipped over since no one could figure out the compression the game was using. Fast forward a few years and i learned that Xemu had a debugging feature with support for IDA which is a tool I'm fairly familiar with, using this i was able to extract the x86 assembly instructions the game uses to decompress the game assets and write a wrapper for it allowing me to unpack the files to a state similar to what's used in other Rareware titles. You can check out that tool here: https://github.com/birdytsc/clr_unpack I'm currently in the process of reversing the games model format but my limited experience with 3d models/formats is hindering my progress. While some of the data is pretty straightforward to obtain some are packed away in pushbuffer instructions, one example is the tri's/faces data: This makes it a little more annoying to tell what set of vertexes they belong to but they are (so far) stored in order that you will find any vertex data one problem i am having is im not sure whether im extracting the data properly, example: the first part for conkers main model is broken into 3 sets of triangles all sharing a single set of vertexes, uv's etc. the model only looks correct if i separate the 3 sets of tri's into there own mesh, keeping them together creates artifacts: Another issue im having is Texture alignment, the game stores the textures as raw DXT data (usually DXT1 or DXT5) even in simpler models that only consist of a single set of triangles im still having alignment issues, for example: Perhaps this is a sign that there is indeed an issue with how im extracting the Tri's? If anyone wants to play around with this stuff ive included some files in the zip: aid_bfdmodel_characters_conker.py - a script for ModelResearcherPro that will load the verts/tris for the main conker model retail_aid_zpackage_general_singleplayer.rbm.listfile.csv - list of file names (if they havnt been stripped from the asset packer) and offsets retail_aid_zpackage_general_singleplayer.rbm.unpacked - just the decompressed version of the file found in the retail game retail_aid_zpackage_general_singleplayer.rbm.unpacked.mapped - same file as above but after its had a bunch of pointers mapped, useful for diffing against the original to find pointers. retail_aid_zpackage_general_singleplayer.rbm.unpacked.mapped.hexpat - imhex pattern file for the previous file. conker_stuff.zip

It doesnt work on decompressed lds files, you have to open the ones straight from the game files

i figured out how to use retoc but i'm gettig the error Error: invalid EIoStoreTocVersion value Edit: i worked it out

Speaking of files? Then usually the answer is "no", because you would need the offset of every byte , DWORD, float and string in the source file to treat them accordingly. (If the file were a block of floats, for example, it would be possible.) Getting something useful out of bnk will require some fidling, I guess:

yeah tried those, plus i'm unsure if it's supported with version 4.25 onwards. All the data of my files are stored in the UCAS files i believe

Hoping someone can get these files out soon

Hello, sorry if this isn't the appropriate place for to ask for help regarding modifying a game but I'm looking for help trying to modify the Far Cry 3 Editor. I've tried reaching out to countless different modders that have made mods for Far Cry 2 and 3 aswell as in the Far Cry Modding Discord to no avail. I'm far from tech savvy or a software developer/hacker but I'll be more than happy to help along the way in any way that I can since I would really love to enjoy all of the different models that the game has to offer. What I'm looking to achieve: -Add in all of the missing models, NPC's (Pirate Beheader, COOP Heavy Pirate Flamer, Guard Dog/Attack Dog) -Different textures/materials of models (different colors of crates, barrels, tarps that appear in-game, but not the Editor.) /To my knowledge only vehicles cycle trough the different textures. -Missing COOP, Multiplayer, DLC content There are already some mods that try to do this, like https://www.nexusmods.com/farcry3/mods/156, https://www.nexusmods.com/farcry3/mods/334 Unfortunately there are still many missing models and the different textures aren't present. Basic Introduction: This modding guide should be a wonderful read for those interested, while it is for Far Cry 2, all principles still apply. It can be found here: https://docs.google.com/document/d/1ozhN9s_4puzSXVYs12ZAOayyL036hgQuFCVS_jSXbd0/edit?tab=t.0#heading=h.5yuedjwzmzz8 NOTE: If necessary I'll personally provide these archives, including after they have been unpacked. I can guarantee you that none of these have any sort of malware. Inside of our Far Cry 3 installation is the data_win32 folder, inside of it are .dat & .fat file archives which contain different folders as well as the different file formats that the game uses. In order to open these archives, we can use https://www.nexusmods.com/farcry3/mods/5 Alternatively https://github.com/gibbed/Gibbed.Dunia2 There are multiple .exe's that are geared towards modding, which I'm far from knowledgeable about, one is supposedly for .XML editing In order to extract them, all that's needed is to just place the example.dat and example.fat file withing the Gibbed.Dunia2 Tools folder. After that we need to place the example.dat file onto the Gibbed.Dunia.2.Unpack which will open up a program pop-up window that is going to extract all of the files from the archive and create a example_unpacked folder which includes the different types of data like the .XML files, models, sounds, textures, etc... Far Cry 3 uses a "patch" system where putting in a new patch.dat and .fat file inside of data_win32 modifies the game, whether it be changing values, adding in new objects, etc... The 2 mods mentioned above utilize this method in order to change the Editor (IGE-In Game Editor). The specific file being edited is the object_inventory.xml which is a giant list of all the available models, NPC's, Vehicles as well as Directories which just neatly organize where models are found within the editor. The problem: Objects have different tags which I have no clue in figuring out, like how big the Bbox (Bounding box/Collision model) is or what are all of the materials an object can use (e.x. a Barrel can be black/red/blue/green), it seems to be some sort of internal setting since there is no mention of which colors/materials a object can use anywhere. Ideally a script would go over all of the folders and add in the content since doing it manually would be a painstaking process. Hopefully this has been helpful in some way, as I've said already I tried reaching out to many different people but unfortunately it seems that there isn't anyone around who could help me figure all of this out, I wish I was skilled enough to do this myself but this seems like my only option and place where I feel like I can ask for help. If there is any way that I can help, feel free to write so.

plz do id love to get these models

Santex then share here how you extracted the language file. Because none of the existing tools open forge and dat files. If you have opened these files and reached the LocalisationPackage file, share how this was done so that the only thing left for the toolmaker and the tool is to open the LocalisationPackage file. And other people can also benefit from this.

Log from the Noesis script for ad005_cos00_00_dec.tmd2 (I used a stride of 60 instead of 56 for the 1st sub mesh, most index counts make sense): offs verts, vStride 0x645b0 56 counts of sm-indices start at 0x760 numFIs 3542 StartIndex 0 numFIs 3222 StartIndex 3542 numFIs 4403 StartIndex 6764 numFIs 2077 StartIndex 11167 + 2077 = 13244 numFIs 903 StartIndex 13244 numFIs 13652 StartIndex 14147 numFIs 2834 StartIndex 27799 numFIs 1120 StartIndex 30633 numFIs 11557 StartIndex 31753 numFIs 11628 ?? StartIndex 43310 ?? numFIs 9684 ?? StartIndex 54938 ?? The address of the 2nd sub meshes face index block was harder to obtain (it was not 0x236c, calculated): H2O file of 3rd sub mesh: 0xE836 4403 Vb1 60 52 0x645B0 6791 020000 0x0 255 All three together:

I went by the "dolls" model, altho 1 has no doll model, so not sure if that was intentional or not.

Just had a quick look at the samples in here. There are some other vertex types in there with different stride values. This is the face one with the vertex colours. Definitely needs a script update to do it all properly though.

If you hex the exe, you can find 5 of the upcoming DLC characters. There's some other stuff in there but this isn't the place for me to post it I suppose. It's all on my X page

If anyone want's a list of which pl#### character is, here's a list. Do note, there is 2-3 DLC chars in the game files which will not have their names shown.

OK, so managed to extract them, but models aren't currently usable unfortunately. The bones aren't linked and don't export properly to Blender, and also some meshes are missing from clothing, and also don't have a proper rig. If anyone can help update it, I would be grateful. Included some of the models in question. Models.zip

unpacking works correctly. most likely a bug in your plugin

But it seem like it only works for the files i uploaded. can u try this too? UPDATE: It might should my TMD2 script issue. tested with captain tsubasa script and the tmd2 script they show same result for kon but not for others model UPDATE2: Hair / Cos(Body) Doesn't read properly chara.zip

I checked both single decompressed file vs individual decompressed files and they are same in size. So I believe that decompression is fine. Maybe that chunks are stacked in some order. But it's just guess... Also i noticed after decompression that some files have pointer on data which actually doesn't exists. See below

I went to try some games Artificial Mind & Movement made (AKA Behaviour Interactive) for the DS All of them contain a file named Rom_3D.bin (.urf in the Behaviour era), this contains the game's 3D models I've used the extract command with Apicula and got inconsistent results, mainly from their early DS games Most games extract almost all files contained in the bin, sometimes it can't get all of them, leaves out the textures/nsbtx files, and some games just don't work at all or only output animation files with no nsbmd files Here's a Google Drive link of a few samples from different games, some working, some not. https://drive.google.com/file/d/1jh5H1LnIPedAuwnX2mTrsGzhqKeZhpLQ/view The results of all games this studio made As Artificial Mind & Movement Scooby-Doo! Unmasked - works Kim Possible: Kimmunicator - works Monster House - doesn't work The Suite Life of Zack & Cody: Tipton Trouble - doesn't work Happy Feet - doesn't work Kim Possible: Global Gemini - doesn't work High School Musical: Makin’ the Cut! - doesn't work Spider-Man: Friend or Foe - works The Suite Life of Zack & Cody: Circle of Spies - works Power Rangers: Super Legends - doesn't work The Golden Compass - works High School Musical 2: Work This Out! - works Iron Man - works The Mummy: Tomb of the Dragon Emperor - works Transformers Animated: The Game - works Kung Fu Panda: Legendary Warriors - doesn't work The Lord of the Rings: Conquest - works MySims Racing - works Ice Age: Dawn of the Dinosaurs - works Indiana Jones and the Staff of Kings - works Shorts - doesn't work As Behavior Interactive Rango - works Transformers: Dark of the Moon - Autobots/Decepticons - both work Alvin and the Chipmunks: Chipwrecked - works Victorious: Hollywood Arts Debut - works Brave - works Ice Age: Continental Drift - Arctic Games - works Phineas and Ferb: Quest for Cool Stuff - works

If the source code of the robin tool is available, I think it can be updated. I have extract some of the texts.

The developer of Anviltoolkit said that the support of ACS will not added until EOL (end of life) Also my tool will not work with ACS files because they changed the structure of forge + LocalizationPackage Implanting new struct of forge is not a big deal but the big problem is LocalizationPackage. This file contains texts and string is hardly encoded/encrypted/compressed in this file. In past we used robin tool to import/export this file but now the tool is not working and the structure of LocalizationPackage is so complex.

XPR files BMS script format sample files Beard And Granny 3D engine .gr2 files? https://www.mediafire.com/file/y4bjdaizb26q4v8/SplosionMan_XprGamesFiles.zip/file XPR games Archive Twisted Pixel Games Splosion Man Ms. Splosion Man Comic Jumper The Adventures of Captain Smiley The Gunstringer final

I wish you had written how you extracted the language files. Right now I can't open the .forge file either. Can you share how did you open it?

Hi everyone, We're excited to announce a small yet important update regarding user groups on our board. This change is the first in a series of improvements planned for the very near future. Please find below the updated and detailed descriptions for each user group: Administrators Moderators Donators Engineers Supporter Members Guests Banned Thank you all for your attention, and we appreciate your ongoing support and contributions to the board. Stay tuned for more exciting updates! Best regards, The Administration Team

(Little preamble:) Unsure if I should post each archive format separately... I'll start with this one, as I have it best described atm. I reversed bunch of other audio-related formats of Glacier 1 games so I plan to slowly put them all here. Take this as an appetizer 😛 Streams files of Glacier 1 games can be read on their own, they contains all of the required data. It should actually be read before any scenes when someone wants to do anything audio-related to have best support, unlike older Glacier 1 games which had streams.wav. Data in file can be separated into following sections, some have clear indices some can be implicitly inferred: - header - block of WAV data (also contains LIP-encoded segments in some data, current exact structure of these is unknown...) - block of WAV headers (different format than headers in *.WHD files, is much simpler and more concise) - file name table (file names match those in *.WHD and *.SND files, there are some extras though contained within this file so this is not full subset!) - records table (start marked in header along with records count) Block of WAV data seems to be aligned on 0x100 boundary (which coincidentally seems to also be size of header and offset to block of WAV data...). Rest of the file does not seem to have any specific alignment. Any WAV data may be encoded in LIP segments which have variable length. Header of the LIP chunks seems to have size of 0xF00 or 0x1000 (with first header containing 'LIP ' magic). Each record seems to contain a field which can be checked to see if data contains LIP segments or not without the need to rely on comparing magic of each data block. For distance-based records, you will have to look into master record to see if LIP encoding is used. There may be multiple LIP segments in the data block, but only first one has magic in first four bytes. Due to variable data length, we have to find out the right size of the LIP segment first before parsing. It seems to appear roughly every ~4 seconds, but naive formula of `average byte rate * 4` just roughly yields what the LIP segment is. Therefore, there is some guessing work that has to be done on the algorithm side to extract data properly. If anyone could help with reversing these LIP segments, it would be great! They do not seem to correspond to speech necessarily. Current detection method for LIP segments relies on the fact that archive is aligned, we know roughly where the offset should be and that we can calculate exact size of each data block (next block offset - current block offset). There is also additional observation to be made that nearly all LIP segments seem to have around half of their data filled with zeroes. We can also notice that when we subtract real data size, aligned on 0x100 boundary, from whole data block size, we get amount of bytes belonging to LIP segments. We can then calculate from this size amount of LIP segments in the data block. There may be only one such segment (calculated size of all LIP segments is <= 0x1000), which does not require us to do any magic - we just have to skip past the header and read real data right after it. Note that the size of the block may be 0xF00 and not 0x1000 so <= and skipping whatever offset you get is probably best course of action until the segments are bit better understood. If there are more segments, we can proceed with calculation of segment size (as the data is interleaved in a way described above). As mentioned before, we roughly know when each of LIP segments appears in the audio file (it is roughly equivalent to 4 seconds, leaving last block unaligned most of the time with smaller size). We should try to pattern match buffer of size 0x780 filled with zeroes, masking each found offset with ~0xFFF (which will left-align on 0x1000) and taking closest offset to the one we predicted. We then read in minimum from "data block bytes left to read" and this "found LIP segment offset", skip 0x1000 bytes to get "divider offset" for the encoded block and copy each part of the segment into its own buffer. In the end, we are left with complete LIP data and complete WAV data. Block of WAV data is organized in such a way that it has all non-distance-based entries at the beginning and all distance-based entries at the end. There is no clear block of LIP data, it seems to be mixed randomly in-between all of the entries so no reliable distinction in the block. Distance-based entries point to same data offset, there are always exactly three such pointers (2 defined in *.WHD which have their copy in *.STR file also, 1 is only defined in *.STR file). There cannot be other number of "duplicates" pointing to same data offset than 1 (none) or 3 (distance-based entry, 1 for master and 2 for near/far data). Third entry we mentioned is STR file only, it is the true data definition used by the sound graph. If LIP data is present, master record has appropriate flag set. Note that master record should not really be used for other things, as its parameters are not exactly the same always and correct ones are located directly in the entry. TODO - add information about distance-based records structure, it is also interleaved... Due to all this, recommended way to get to the actual data is to pre-calculate all individual WAV data block sizes and resolve LIP segment sizes for each record along with detecting which records are distance-based. TODO - add parsing process used by Glacier 1 Audio Tool which seems to have correct export Note that format information of data, along with data sizes, offsets, names, etc. are all the same as one can find in their equivalent records in *.WHD files. So there is no need to reference *.WHD files for any sort of information for extraction of the *.STR files (unlike older Glacier 1 games). Below are simple C++ headers which should help anyone interested to get started with the file format I hope! V1 is for Hitman: Blood Money V2 is for Kane & Lynch: Dead Men and Mini Ninjas V3 is for Kane & Lynch 2: Dog Days (TODO - missing information+header!) // // Created by Andrej Redeky. // SPDX-License-Identifier: Unlicense // // Extended format information: https://reshax.com/topic/27-glacier-1-str-file-format // #pragma once enum class STR_LanguageID_v1 : uint32_t { Default = 0, English = 1, German = 2, French = 3, Spanish = 4, Italian = 5, Dutch = 6 }; struct STR_Header_v1 { char id[0xC] = {'I', 'O', 'I', 'S', 'N', 'D', 'S', 'T', 'R', 'E', 'A', 'M'}; // always "IOISNDSTREAM" uint8_t unkC[0x4]; // always seems to be a sequence 09 00 00 00 uint32_t offsetToEntryTable = 0; // points at the STR_Footer, right after string table ends uint32_t entriesCount = 0; // same as number of STR_Data entries in STR_Footer uint32_t dataBeginOffset = 0x100; // offset to beginning of data probably, but it is like this even for PC_Eng.str which does not have such size and has no data... uint8_t unk1C[0x8]; // always seems to be a sequence 00 00 00 00 01 00 00 00 STR_LanguageID_v1 languageId = STR_LanguageID_v1::Default; // specifies which language data is contained within the archive }; enum class STR_DataFormat_v1 : uint32_t { INVALID = 0x00, PCM_S16 = 0x02, IMA_ADPCM = 0x03, OGG_VORBIS = 0x04, DISTANCE_BASED_MASTER = 0x11 }; // beware that this is really 3 different headers, as there is no padding... didn't know how to name things so left it like this for now.. struct STR_DataHeader_v1 { // PCM_S16, IMA_ADPCM, OGG_VORBIS and DISTANCE_BASED_MASTER have following bytes STR_DataFormat_v1 format; // specifies how data should be read uint32_t samplesCount; // samples count uint32_t channels; // number of channels uint32_t sampleRate; // sample rate uint32_t bitsPerSample; // bits per sample // all PCM_S16, IMA_ADPCM and DISTANCE_BASED_MASTER have following bytes on top uint32_t blockAlign; // block alignment // all IMA_ADPCM have following bytes on top uint32_t samplesPerBlock; // samples per block }; struct STR_Entry_v1 { uint64_t id; // probably some ID, is less than total entries count, does not match its index uint64_t dataOffset; // offset to beginning of data, beware of the distance-based records which alias the same index! uint64_t dataSize; // data size uint64_t dataHeaderOffset; // offset to table containing header uint32_t dataHeaderSize; // size of STR_DataHeader_v1 (unused fields from the structure are left out) uint32_t unk24; // unknown number uint64_t fileNameLength; // length of filename in string table uint64_t fileNameOffset; // offset to filename in string table uint32_t hasLIP; // 0x04 when LIP data is present for current entry, 0x00 otherwise uint32_t unk3C; // unknown number uint64_t distanceBasedRecordOrder; // if 0, entry is not distance-based, otherwise denotes data order of individual records in data block (or is simply non-zero for master record) }; enum class STR_LanguageID_v2 : uint32_t { Default = 0, English = 1, German = 2, French = 3, Spanish = 4, Italian = 5, Dutch = 6 }; struct STR_Header_v2 { char id[0xC] = {'I', 'O', 'I', 'S', 'N', 'D', 'S', 'T', 'R', 'E', 'A', 'M'}; // always "IOISNDSTREAM" uint8_t unkC[0xC]; // always seems to be a sequence 09 00 00 00 XX XX YY YY 00 00 00 00 where XX XX changes with language and game and YY YY is same for a game (Kane & Lynch: Dead Man has this sequence E1 46, Mini Ninjas has this sequence 4C 4A) uint32_t offsetToEntryTable = 0; // points at the STR_Footer, right after string table ends uint32_t entriesCount = 0; // same as number of STR_Data entries in STR_Footer uint32_t dataBeginOffset = 0x100; // offset to beginning of data probably, but it is like this even for PC_Eng.str which does not have such size and has no data... uint8_t unk24[0x8]; // always seems to be a sequence 00 00 00 00 01 00 00 00 STR_LanguageID_v2 languageId = STR_LanguageID_v2::Default; // specifies which language data is contained within the archive uint8_t unk30[0x8]; // always some sequence 38 XX XX XX XX XX XX XX where XX is same for a game (Kane & Lynch: Dead Man has this sequence 00 A1 01 18 EE 90 7C, Mini Ninjas has this sequence 00 00 00 00 00 00 00) }; enum class STR_DataFormat_v2 : uint32_t { INVALID = 0x00, PCM_S16 = 0x02, IMA_ADPCM = 0x03, OGG_VORBIS = 0x04, UNKNOWN_MASTER = 0x1A }; // beware that this is really 2 different headers, as there is no padding... didn't know how to name things so left it like this for now.. struct STR_DataHeader_v2 { // PCM_S16, IMA_ADPCM, OGG_VORBIS and UNKNOWN_MASTER have following bytes STR_DataFormat_v2 format; // specifies how data should be read uint32_t samplesCount; // samples count uint32_t channels; // number of channels uint32_t sampleRate; // sample rate uint32_t bitsPerSample; // bits per sample uint32_t unk14 = 0; uint32_t unk18 = 0; uint32_t blockAlign; // block alignment // all IMA_ADPCM have following bytes on top uint32_t samplesPerBlock; // samples per block }; struct STR_Entry_v2 { uint64_t id; // probably some ID, is less than total entries count, does not match its index uint64_t dataOffset; // offset to beginning of data, beware of the distance-based records which alias the same index! uint64_t dataSize; // data size uint64_t dataHeaderOffset; // offset to table containing header uint32_t dataHeaderSize; // size of STR_DataHeader_v2 (unused fields from the structure are left out) uint32_t unk24; // unknown number uint64_t fileNameLength; // length of filename in string table uint64_t fileNameOffset; // offset to filename in string table uint32_t hasLIP; // 0x04 when LIP data is present for current entry, 0x00 otherwise uint32_t unk3C; // unknown number uint64_t unk40; // OLD INFO: if 0, entry is not distance-based, otherwise denotes data order of individual records in data block (or is simply non-zero for master record) };

Howdy modders! Not sure where else to post this, but I just wanted to share a small personal project with you all that I took a week or so to create. https://jenkinstr.github.io/JMD-Forza-Vehicle-Database/ The page itself takes a bit to load because of the thousands of elements, give it a second or two until it fully loads before using it, as the JavaScript to make the filters/search work loads last. It's not particularly mobile friendly either but that shouldn't be a problem for modders. I tested it on a range of screen sizes. This was created from all versions of Forza that are extractable on PC, with the only exception being Apex and the most recent Motorsport 2023. FM5 and FM6 are not included as they were never released for PC, and FM1 is excluded as it uses a different file system for vehicles than the rest. If you have any questions or suggestions or just want to discuss the crazy amounts of data, I'd love to hear it! 🙂