Structure

Folder Structure

Tekken 7 Folder Structure

1. In-Game: Game/Content
2. UE4: Content
3. .pak/Mod: Mod_Title_P/TekkenGame/Content

Tekken 8 Folder Structure

1. In-Game: Polaris/Content
2. UE5: Content

T8 like all games is a program and as such has a specific manner to search and find data to load for use in the game. Since we are modding it is important to note we must understand this process in order to insert our modifications. The simple explanation is we are either replacing information at the destination or rerouting to a new destination.

The T8 structure can be viewed using programs like fmodel and umodel. In T7 we relied solely on .pak files and created folders that mimicked the setup of the game in the pak folder and in the custom ue engine but with a small change. For example, if u look up stg01_geom.umap in umodel the path is Game/Content/Maps, in UE the folders are Content/Maps and in your mod/pak folder it would be ModTitle/TekkenGame/Content/Maps. The only difference is the initial folders up to the Content folder. In T8, we cannot currently use an external packing tool and must also include a .ucas and .utoc file along with the .pak. The good news is that we only need to know the file structure of the game and ue which follows the same logic as it did for T7 except in game its Polaris/Content/ and in ue its Content/.

Heirarchy

Aside from folder structure there is a hierarchy of how data is read which helps us know where to find assets and then modify the appropriate assets to create the mods. This hierarchy is essentially two concepts: standard practice and developer setup.

Standard practice relates to the flow of info for assets that is used universally for assets. For example, a 3d model (skeletal mesh) will hold a reference to its base skeleton and the materials it uses to provide color and details. The materials reference specific texture maps and parameters. The 3d models also reference uv maps which tell where and how the textures will ne applied to the model.

Developer setup relates to how the assets are organized in the game. For example, a base item references multiple assets including the skeletal mesh, the skeletal mesh asset references the location of the skeleton(s) and the materials, the material assets reference the location of material instances and any base parameters, the material instances reference the location of the textures and any specific parameters.

You may notice I didn't say material instances for the standard procedures. This is because most 3d models only use base materials. In the game industry it doesnt make sense to create individual materials for every model, instead, they create a master material with multiple parameters and then use instances of those materials and pick which textures or parameters to apply/change. For example, to make a gold material i may need to setup a network of complicated nodes and functions to get desired effect. Since most metals share similar properties they base the material on that base look. The material instances can then reference and change parameters to make ut look like gold, silver, bronze, chrome, etc.

Why does this heirarchy matter?

If for example i want to change the look of a character skin. I may want it to have some cool tattoos or scars. I know its controlled by a texture so i just edit the texture and put it in the game. I then notice that all the characters now have this change. If that's the case i can assume that the texture is in a place within the structure that is used by all of the characters which is common to reduce the size of the game. But i dont want this effect so what do i do? In looking at the heirarchy i know that each character references the texture thru thier own unique material instance. In order to isolate my mod i need to redirect the game away from its original destination to a new one; my custom texture. To do this i will need to figure out what material instance to change and follow the path till i find the reference then change that specific reference to the location of my new texture. Vice versa if I followed a guide on how to change a unique material instance tmbut wanted to chanfe them all if i dont understand the heirarchy id have to make a lot of individual changes when all i needed eas to replace the base texture.

Another issue i might run into is that the game may have a unique way of loading an asset. I might want to edit a hat to be loaded on a characters preset and not manually via customization. I may have seen a guide to do it for customization but not for presets. Since i understand hierarchy i need to find the top of the chain and follow it down to find the correct asset. The game may have made a preset based on a story mode asset that isn't located with the common assets. I first find the preset asset then follow the developer setup hierarchy until I locate the correct asset.

Emulation

The Dirty MI / Material Emulation

BLUF: A "Dirty MI" is a MI that contains only the parameters you want to change with a reference to a base material that will work in game but may not look correct in the editor.

In ue the game uses inheritance when processing materials and material instances. Inheritance works by creating a parent/base material with various functions and parameters. You can then make a child/material instance from the base material which inherits all that the parent has to offer. The good thing is that u can make changes to the parameters in the material instance and have access to countless variations. As modders we may not know how to build the base material exactly like the devs but its good because we don't have to; we just build a mi that references a base material and then change the parameters. But we must understand a few things 1st. 1. An mi in ue has to have a parent with parameters in order to make a change. 2. We need to know what parameters we want to change. And 3. How do we do this if we dont know how to build the original base material?

Example process

1. Create a dummy M. Name it exactly as it is in game and place it in your UE exactly where it would be in game. 
2. In an asset viewer (Fmodel/Umodel), identify what you want to change and see if it has a corresponding parameter. In this example the M has a BaseColor parameter for the texture and a Roughness scalar parameter.
3. Open up ur material and add a node for scalar parameter and the texture parameter. U can use default info/texture because we will be referencing it but won't be adding it to the mod.
4. Right-click the Material, create the Material Instance, adjust the parameters.

MI Parent Swapping

In some cases, you may want to change the properties of a MI, like make it glow or make a metal object look like wood, but there is no way to do that with the current parent material. This will be the case if you want to swap out a material on an existing in-game model but the technology to use custom models (including re-imports of game assets) is not yet realized. The process is similar to a dirty MI and must consider the way the game thinks and processes info.

Situation:

1. You want to make a character's shirt glow with a pulsing light like what is found on a different character but the base MI for the shirt has no pulsing emissive parameters to use or reference. 
2. Use of custom materials and custom mesh is not yet realized so you can't replace the base material and you can't change the reference to a material instance without the custom mesh.
3. Proper Emulation of the base material requires more knowledge or elements than anybody currently has and all other attempts by the community have failed.

How do you proceed to still get the mod that you want?

Solution:

1. Find the asset you want to change. Let's call it "MI_CH_bab_bdl_ThotSkirt_outer". Find an existing asset that has the property you want (pulsing light). Let's call it "MI_CH_ape_bdu_HyperRizz_shirt".
2. Create a material but name it the same as the MI you found and make sure its folder placement matches what is in-game.
3. In the material (MI_CH_ape_bdu_HyperRizz_shirt), create the nodes you want to pass thru. In this case you likely want the node that assigns color to the light, changes its speed or intensity, and all of the texture parameters. NOTE: If the developers misspelled a parameter name then you must misspell it too or it won't work.
4. Create a material instance from the material so that the MI you are referencing will be the new parent and name it the same as the MI (MI_CH_bab_bdl_ThotSkirt_oute) you found and make sure its folder placement matches what is in-game.
5. In the material instances make whatever changes you want to. 
6. Pak the mod to a chunk but make sure to not include the referenced MI you are using as a parent. We only need the material MI so that the MI you are paking contains a reference to it and contains the parameters you need to change. When you don't include it in the mod the game just follows the path which leads to the working version in game, confirms the parameters match, then grabs the items you modified or referenced.

Proper Emulation

If you know how to setup a proper material in UE5 you may find that you can adequately re-create a game material within the engine. If done correctly you will have both access to the necessary parameters and it will look proper in the engine. The goal for this type of emulation is 1 to 1 which will reduce the need for going back and forth between the game and the engine while modding. Many guides exist on YouTube and on the internet that explain how materials are properly set up. At this time, we have no access to create fully custom materials so this is the next best thing.