Welcome
Ladies and Gents:

These forums are now closed and registration disabled.

Please join us at our new forum on Proboards. Our hope is that these new forums are more stable, provide more and better features, and allow continuation of the project forums in a safer, more secure, long term environment.

me3explorer.proboards.com

--The ME3Explorer Team

Ben | DirectX work on Meshplorer

Development board for ME3Explorer tools. Please try to keep discussions for each tool inside its own thread.

Re: Ben | DirectX work on Meshplorer

Postby Kinkojiro » 14 Dec 2016, 14:28

benji wrote:That's not a lot to go on. I had hoped that the variable "PackageFile" would be the location of the texture export, but no such luck (unless I am using Package Editor, which also says the Wall02_Diff should be in Engine.pcc, horribly wrong). I'm not sure what the "PackageFile" variable means for imports, but it's not where the connected export is stored, unless I'm looking in the wrong Engine.pcc. A brute force scan by my scanning code can find the matching exports, but it doesn't know which one is the correct one to load. How should this work? Help?

(I'm using the BioT_Normandy_Int.Wall02_Diff import in BioA_Nor_210CIC.pcc as a test case)


Ok this is a perfect example of what I am talking about. Imports are not referenced by package, any file loaded before that file will do. Wall02_diff is a blank wall texture used in a lot of pieces of the Normandy. So a copy used by BioA_Nor_123XYZ.pcc it is held in BioP_Nor.pcc (which is the master level loading file for the Normandy).

If the texture is an import in BioA/D_Nor you should scan the main game files (SFXGame etc) then BioP_Nor. That will pick up virtually all the imports because these are the only files guaranteed to be loaded before that specific file. There is no need to scan every file for every texture.

Similarly if the import happened to be in BioD_KroGar_920jkl.pcc you should scan SFXGame/Engine/etc then BioP_KroGar.pcc

If there are 2 copies of an export object loaded, only the first is in memory. So roughly the priority will be Engine -> SFXGame -> Startup -> Common -> BioP.

Kinkojiro has been thanked by:
User avatar
Kinkojiro
Modder
 
Posts: 578
Joined: 02 Dec 2013, 04:14
Has thanked: 233 time
Have thanks: 249 time

Re: Ben | DirectX work on Meshplorer

Postby giftfish » 14 Dec 2016, 14:44

benji wrote:That's not a lot to go on. I had hoped that the variable "PackageFile" would be the location of the texture export, but no such luck (unless I am using Package Editor, which also says the Wall02_Diff should be in Engine.pcc, horribly wrong). I'm not sure what the "PackageFile" variable means for imports, but it's not where the connected export is stored, unless I'm looking in the wrong Engine.pcc. A brute force scan by my scanning code can find the matching exports, but it doesn't know which one is the correct one to load. How should this work? Help?

(I'm using the BioT_Normandy_Int.Wall02_Diff import in BioA_Nor_210CIC.pcc as a test case)

I expect Kinko will ninja this post with more information than I'm capable of providing, but here are some key points:

1. All non-GUI game textures are stored in TFCs. The PCCs contain only the Unreal pointers -- the export Texture 2D objects. These always point to a TFC, either in the base game, BW DLC, or a DLC mod.

2. Texture2D objects also contain a certain number of the small mipmaps for the texture. The quantity varies. When we replace textures, these are replaced and a new TFC is created (or an existing one modified).

3. GUI textures you don't need to worry about, since they aren't associated with meshes. These are actually PCC-stored textures. Mentioning these for reference.

4. While it is unusual for localized (_INT) files to contain texture pointers, they sometimes do (think when you give Kaidan the bottle of booze in his hospital convo), so they can't be ignored completely.

5. Kinko should be the one to respond your question about Engine.pcc. Basically, that PCC needs to be referenced so the game knows how to process the information properly. There's something important in that file that you'll likely need to use.

6. As far as matching the correct one, that's also Kinko's area. I may have something to do with Engine.pcc. Otherwise, it's going to be one of the other core files that Kinko covered in his previous post.
User avatar
giftfish
Toolset Developer
 
Posts: 1247
Joined: 08 Jan 2016, 02:35
Has thanked: 129 time
Have thanks: 75 time

Re: Ben | DirectX work on Meshplorer

Postby giftfish » 14 Dec 2016, 14:44

And ninja'd as expected, lol.

giftfish has been thanked by:
User avatar
giftfish
Toolset Developer
 
Posts: 1247
Joined: 08 Jan 2016, 02:35
Has thanked: 129 time
Have thanks: 75 time

Re: Ben | DirectX work on Meshplorer

Postby benji » 15 Dec 2016, 09:16

Got a bit of coding in today and fixed the depth clipping issue. I hope to have time to get the texture load order corrections implemented over the holidays.

benji has been thanked by:
benji
User
 
Posts: 18
Joined: 07 Nov 2016, 05:24
Has thanked: 1 time
Have thanks: 6 time

Re: Ben | DirectX work on Meshplorer

Postby FemShep » 15 Dec 2016, 21:03

Just browsing the last page of this thread.

Startup files also override previously loaded items (through mount priorities). EGM used to have some GUIs in its startup files that broke controller mod even though controller mod had higher loading priority. I'm not sure it does all of them though. I'm pretty some textures are referenced in those...
Image
ME3Tweaks has modding guides, tools, forums for mods, a modding wiki, and ModMaker, an online mod creation tool.
ME3 Mod Manager, the civilized way of installing and managing ME3 mods.
ME3Tweaks Facebook Page
User avatar
FemShep
Modder
 
Posts: 1101
Joined: 18 Oct 2012, 20:48
Has thanked: 42 time
Have thanks: 76 time

Previous

Return to ME3Explorer Toolset Development

Who is online

Users browsing this forum: No registered users and 0 guests

suspicion-preferred