|
Post by mariokart64n on Aug 5, 2020 3:36:36 GMT -5
The game uses many forms of configuration files which are not assets, like .txt, .csv and .bin I did not experiment on these files but it would not be surprising if they are configurable as they are uh config files..
|
|
|
Post by mariokart64n on Aug 5, 2020 2:37:11 GMT -5
You may re-arrange data but not create new data and enabling DLC in your profile has nothing to do with file editing/modding I imagine that all data is read and a checksum is generated providing type of "footprint" for each file, this footprint is then checked against a list in the game. If the footprint doesn't match because the data was altered then the game terminates immediately. In the case you rearrange the data, it doesn't matter... as the foot print remains the same. To clarify the .big, .mdl, .tex are all the same archive format, the checksums are generated on the files within each respective archive not on the entire archive as whole. This means you can swap data within each archive across each other which you may mistake as creating new data.. However you are NOT creating new data your just swapping (re-arranging) the files contained in the archive. Please watch the video provided if you want a more in-depth understanding of the sort of protection we are facing. Sadly this is the reality with the game, and I'm annoyed that no one had bothered to identify this clearly in the past several years. As devastating as this news is this needs to be clear because it informs everyone so future modders don't waste their time and we can now focus on locating an individual that can bypass the built-in protection of the game executable.
|
|
|
Post by mariokart64n on Aug 4, 2020 23:47:52 GMT -5
|
|
|
Post by mariokart64n on Mar 1, 2015 23:37:20 GMT -5
right, ok looked at the weapons and yeah that complicates things but is doable the vertex buffer is described in a VertexDesc file, it explains what components are in the buffer and where. position, normals, Uvs, weights etc... however the weapons split the components into different buffers.. this seems soo utterly stupid I can't even see the logic in it. per example they have a separate buffer for position only, then a separate buffer for UV only. it complicates thing because now I have to re-write how I'm reading the files yet again lol geez I'll look at it next weekend I think, I'll keep you posted if there is any new updates I believe adding weapon support to be important
|
|
|
Post by mariokart64n on Feb 25, 2015 22:29:42 GMT -5
where are the weapons located?
|
|
|
Post by mariokart64n on Feb 25, 2015 2:46:42 GMT -5
yeah there is alot of hashing, the model's texture list contains more then what is in the actual texture container. I reckon shared textures such as eyes, mouth etc are linked somehow with the hashes they have written everywhere. anyway UV's work, gonna have to test because my D3DVertexDesc isn't very well flushed out yet. comp ( 0x00: #position 0x01: #weight 0x02: #boneid 0x03: #normal 0x04: #binormal -- not confirmed 0x05: #texture 0x06: #tangent -- not confirmed )
datatype ( 0x06: #point3 -- 3 32bit floats 0x0D: #pack4 -- packed normal (4bytes) 0x1E: #point4b -- 4bytes, for bone ids and weights 0x25: #point2f -- 2 shorts (4bytes) ) anyway enjoy your time in brazil man
|
|
|
Post by mariokart64n on Feb 23, 2015 21:34:56 GMT -5
alright like 99% of the NPC models appear to import correctly (uvs aside) so I'm considering just moving forward with what I got. ? any thoughts, I need input and testers if I move forward I'll dig out more of the other files so that I can start to re-write data into the game latest maxscript: pastebin.com/uCfRTU1h
|
|
|
Post by mariokart64n on Feb 22, 2015 14:00:35 GMT -5
A dozen NPC's continue to defy me! still working towards swiftly delivering them to their miserable demise before revealing the true colours of their texture maps!!!!!!! Lastest Maxscript: pastebin.com
|
|
|
Post by mariokart64n on Feb 21, 2015 3:56:47 GMT -5
oh man this format is such a headache, they dynamically jump around files and use different vertex definitions. but each time they do that they must actively store a pointer and address for each different vertex type. my code is quickly getting very messy, and I havent found a very efficient way to do it. .. I tell yah, you think you seen it all then some silly format tosses you on your head and you feel like an idiot all over again anyway here's the latest "Beta Script" and no I haven't bothered to add UV's yet Download: pastebin.com/YHwDmg57
|
|
|
Post by mariokart64n on Feb 10, 2015 14:13:19 GMT -5
sorry I should probably update: started writing my script from scratch in JAN but since this FEB I've had bad luck for concentration.
I said before that I felt my implementation was wrong, and I think that was because I was reading the command buffer in a strange way, I only parsed for one instance of certain data stored in it and then read the entire vertex buffer and used the stored crap from the command buffer to build faces.
I know that i did that entirely wrong, I basically have to store the entire command buffer in a multi dimensional array then only read what the command tells me to and once the commit or RET(0x01) command is supplied
..anyway I feel REAL bad about the time frame, usually I'm up and going with a script within a month or two. :\ but its been like half a year! thats unforgivable in any situation, I'm sorry about that
I want to pay you back since I've been mostly absent in accomplishing what I said I would do. please let me know if your interested in something on steam and I'll gift you a game, as you did for me with dr3
I'm not giving up on creating a tool for DR3, its just not ontop of my list of top priorities right now
cause right now I've got the flu with splitting headache and a comfy bed that I'm going to be hibernating in for the next week >_< lol
|
|
|
Post by mariokart64n on Jan 21, 2015 23:18:29 GMT -5
commandbuffer
credits to SirKane for sharing the field names
command{ UINT8:magic }
commandcodes{ 0x01:CMD_RET 0x08:CMD_DRAW_INDEXED 0x09:SET_VERTEX_DECL 0x0C:SET_TEXTURE 0x0D:SET_TEXTURE_STATE 0x0E:SET_DRAW_STATE 0x25:SET_OFFSET_VERTEX_BUFFER 0x35:SET_SHADER_RUNTIME_PASS 0x41:SET_OFFSET_INDEX_BUFFER 0x73:SET_TEXTURE_UNRESOLVED 0x74:SET_TEXTURE_STATE_UNRESOLVED }
... need to complete structs for each code
|
|
|
Post by mariokart64n on Jan 21, 2015 23:04:47 GMT -5
convexhullvertices PLACEHOLDER not documented yet..found in a stage file
|
|
|
Post by mariokart64n on Jan 21, 2015 23:04:33 GMT -5
convexhullplanes PLACEHOLDER not documented yet..found in a stage file
|
|
|
Post by mariokart64n on Jan 21, 2015 23:04:13 GMT -5
convexhull PLACEHOLDER not documented yet..found in a stage file
|
|
|
Post by mariokart64n on Jan 21, 2015 23:03:23 GMT -5
_collisionlist2_ PLACEHOLDER not documented yet..found in a stage file
|
|
|
Post by mariokart64n on Jan 21, 2015 23:03:09 GMT -5
_collisionlist2instances_ PLACEHOLDER not documented yet..found in a stage file
|
|
|
Post by mariokart64n on Jan 21, 2015 23:01:52 GMT -5
_boundingbox_
bounding box for the model, donno whats this is used for, camera, or mesh scaling basically you get two 3D points that create a cage around the model.
boundingbox{ FLOAT32:MinPositionX FLOAT32:MinPositionY FLOAT32:MinPositionZ FLOAT32:MaxPositionX FLOAT32:MaxPositionY FLOAT32:MaxPositionZ }
|
|
|
Post by mariokart64n on Jan 21, 2015 23:00:16 GMT -5
_animlib_skeleton_
header{ UINT32:unknown1 // version? UINT16:count // UINT16:unknown2 // flag? }
position_table{ FLOAT32:RotationX // quat rotation FLOAT32:RotationY FLOAT32:RotationZ FLOAT32:RotationW FLOAT32:PositionX // position FLOAT32:PositionY FLOAT32:PositionZ FLOAT32:UNKNOWN1 // ?position scalar value? UINT16:UNKNOWN2 UINT16:string_offset }
hierarchy_table{ UINT8:index }
name_table{ STRING:bone_name }
|
|
|
Post by mariokart64n on Jan 21, 2015 22:59:34 GMT -5
_attribute_
yup no idea what this does
attribute{ UINT:unknown }
|
|
|
Post by mariokart64n on Jan 15, 2015 2:32:38 GMT -5
The Model Package
Geometry is stored obviously within BIG containers, which were explained above... But BIG's are not a standalone model file, they are just for storing files, among whatever else they're used for... The BIG's I see that work as models contain a breakup of multiple sub file model components.
so we have to pick apart and understand each of these sub files within the big in order to successfully read and write new model BIG's
First I'll list known subfiles, then I'll start to document them. bare in mind I do not know the hierarchy of each file. What that means is some files are read first, or last some are required or included by earlier files etc.. but without knowing that its messy guess work :\
Last thing to note, there is a unknown ID given to each subfile that works as a category identifier of sorts. 0x04 seems to caontain most of the files, so I'll be covering those first, before the other ones
List of Discovered (0x04)BIG SubFiles *(List subject to change)
_attribute_ // single integer, not known what it does _animlib_skeleton_ // skeleton _boundingbox_ // model bound box _collisionlist2instances_ // _collisionlist2_ // convexhull // convexhullplanes // convexhullvertices // commandbuffer // array of commands needed to parse geometry desc2 // ibheader // vbheader // vdheader // maskrenderstrip // combined_ibheader // combined_vbheader // matarray // matparameterarray // matsamplerinfoarray // mattextureinfoarray // scenedescription // sceneheader // sharedopaquecommandbuffer // sharedtransparentcommandbuffer // sharedzpasscommandbuffer // sharedzpassfirstcommandbuffer // sharedzpasssecondcommandbuffer // texturenames // array of texture names totalibsize // total size of index buffer in bytes totalvbsize // total size of vertex buffer in bytes
|
|
|
Post by mariokart64n on Jan 13, 2015 19:27:05 GMT -5
The Archive "BIG" files are stored in the archive and can be compressed using zlib(inflate?), based on platform of the game the archive may adopt that platforms native compression library. Files are kept with there full name including there extension. However there seems to be no folder structure. An unknown ID is specified for each file, which could be interpreted as a data type ID or perhaps a predetermined folder name. As the archive stores a large range of game binaries, sound, animation, geometry, textures, etc An odd thing is some archives contain valid header data as to retrieve sub files, but then the archive ends short. It’s thought that the archive may be used in memory and can be used to address raw packages in RAM. However that is a guess, what is known is that some archives do not contain any readable files. Such a thing causes issues with parsing as specific data files are found within the structure of the archive but then that data simply does not exists All files in the archive are given a 32bit SDBM hash code, used for file linking and likely other data lookups by the game. my implementation of SDBM was derived from the following article: www.cse.yorku.ca/~oz/hash.htmlData Structure *all address offsets are absolute from the starting of the file, unless otherwise noted HEADER { UINT32:fileid // PC DR3, always seems to be 0x03040506 UINT32:data_offset // jumps to file raw data UINT32:filesize // entire archive size, including header UINT32:filecount // number of files in archive UINT32:filetable_offset // jumps to table that describes archive files UINT32:stringtable_offset // jumps to table that contains strings used by files } STRINGTABLE{ STRING:filename //dynamic size, delimited with white space 0x00 } FILETABLE{ UINT32:filename_offset // jumps to the string contained in the stringtable UINT32:hash // SDBM hash generated from filename UINT32:csize // compressed size UINT32:usize // uncompressed size UINT32:offset // jumps to file data UINT32:type // can be used to sort archive files? UINT32:cflag // compression flag, if not 0 then file is compressed, 1=zlib } CFLAG_ENUM{ 0x00: raw 0x01: zlib } TYPE_ ENUM { 0x0004: headerinfo 0x0010: texturedata // also includes HavokData 0x0020: modeldata 0x0100: bigfile 0x0200: audiodata 0x0800: compressed }
|
|
|
Post by mariokart64n on Jan 13, 2015 19:26:53 GMT -5
Format Study of Blue Castle’s BIGs engine
Article By: mariokart64n (January 2015)
Intro Hi I’ve been doing amateur scripting/reversing for 6 years now. I seem to work on model extraction the most, just from its popularity. All of what I figure out is from pure visual observation, no debuggers/listeners/monitors/disaasemblers were used in my findings. Please feel welcome to correct and build upon any of my observations
Terms/Def INT8: 1byte signed integer value UINT8: 1byte unsigned integer value INT16: 2byte signed integer value UINT16: 2byte unsigned integer value INT32: 4byte signed integer value UINT32: 4byte unsigned integer value FLOAT16: nvidia’s 16bit encoded half-float FLOAT32: typical 32bit encoded float STRING: 1 dimensional array of characters
Overview Assets are stored in archive files with the extension (.BIG) some other extensions are used but still follow the same archive structure.
|
|
|
Post by mariokart64n on Jan 13, 2015 19:26:24 GMT -5
I'm gonna try to post something everyday even if its small just to keep myself focused and motivated.
After christmas I ended up blankly starring at my script code getting lost then confused then frustrated. so gonna hammer below the structures I know, aswell write some notes so that others can follow along.
at the end of it we'll all have an idea of how the files work, then I hope I can finally give you guys a stable model importer.
|
|
|
Post by mariokart64n on Mar 7, 2012 19:44:43 GMT -5
what version of 3dsmax? 2012 is bugged, you need to install there fixes.. there are like 3 big service packs you need....
this was a BIG issue when 2012 first released.. everyone was pissed, cause the paid alot of money for a license it the software was basically broke
|
|
|
Post by mariokart64n on Mar 7, 2012 19:08:25 GMT -5
i have like 5 "mariokart64n" email accounts on different hosts.... hotmail, gmail,yahoo,aol,rog, and a few random ones
|
|
|
Post by mariokart64n on Mar 7, 2012 17:48:35 GMT -5
you PM me? I used pastebins cause I would update maybe a dozen times before a final is decided. its just a copy and paste away to use paste bines. over saving and uploading files to like mediafire.. the down side is pastebins deletes your pastes after XX amount of time. and sadly my PC got hit by a virus, so I have like random backups.. I dont know where the work left off. but if you guys need a script I can throw a search on my backup and see what I get? the scripts aren't finished anyway, but were a delightful eye opener to how some data works in 3d files. PS, I'll revisit here before bed, so post up your request. I'll be playing mass effect 3 most of the week
|
|
|
Post by mariokart64n on Jan 12, 2012 19:04:53 GMT -5
noesis is straight forward, the problem is extracting the files. noesis may look for the extension MOD or DOM. in computers numbers can be represented either forward or backwards... some Einstein must have forgot this. and there is some misconception about the extracted extensions. some extractors may output the models as DOM, some MOD.
I cant recall which noesis is built for. but you may need to make name changes in order for noesis to pickup files
|
|
|
Post by mariokart64n on Jan 11, 2012 16:52:05 GMT -5
I had a HUGE computer virus, and basically lost everything. I backed up what I could, but I donno whats what. anyway someone said the link to the script was expired? pastebin.com/Er75t3Vvalso if the arms don't assign right that means the bones are bad. you'll need to run a quick test. first extract fresh files (original files, not modded) import the model and export the arms only, and test in game. older scripts may have had bugs which would cause a bad import, and thus a bad export.
|
|
|
Post by mariokart64n on Dec 28, 2011 19:50:46 GMT -5
hm, this is about items again right?
edit provide samples of the files that your getting problems on.
don't send corrupt files, send the files that eventually lead into problems (the original files)
I'll look at it and rescript the packer. its the packer which is the problem?
I wish I could recode the tools into a program language or application. but thats beyond my knowledge. sucky there that gibbs guy hasnt returned huh
anyway I only know 3dsmax, but if you'd like some basics about reading and writting a file. I'd be more then happy to explain how.
|
|
|
Post by mariokart64n on Dec 25, 2011 10:02:10 GMT -5
wow I guess I took it forgranted that you guys aren't familiar with scripting...
not much that can be said though, you really cant create a tutorial for that. a script needs an interpreter to work. BMS > quickBMS BAT > DOS Command Prompt MS > MaxScript
|
|