Kfreon | ModMaker

Development board for ME3Explorer tools. Please try to keep discussions for each tool inside its own thread.
giftfish
Toolset Developer
Joined: 08 Jan 2016, 02:35

08 Jan 2016, 19:07 #1

This thread serves as an example of how this intended to be used. Each tool can have it's own thread and toolset coders can communicate with each other about changes to the tool.

In addition, Coders can start *new threads* for new tools they have in development, to get feedback from other coders and modders as to what features they'd like to see in the tool.

If at some point coders feel that multiple threads are necessary for each tool, that certainly can happen, but I'm sort of figuring b/c Git and this new section, one thread is probably enough.

@Kfreon -- Please go ahead when you're free and post the lingering issues with ModMaker and DLC that we were talking about, where input from other modders would be a good idea.

Then, maybe we can finally get this new stable out :D
Reply

KFreon
Toolset Developer
Joined: 16 Apr 2013, 00:57

09 Jan 2016, 01:27 #2

The issue I'm thinking about guys, is with Modmaker when people have a .mod that modifies a base game PCC.
The mod is likely old, so it's just basegame, but the user has DLC, whether it be Bioware or user made.

As I understand it, the DLC PCC overrides the Basegame one, thus rendering the mod installation pointless.
Unless the user obtains a mod that modifies the DLC PCC, they're wasting their time.

So I was chatting with Giftfish about how to fix it, and I wondered if it was possible to find any matching PCC's in DLC's. It'd go like this:
1) Search all extracted DLC files for a PCC that matches the name given in the mod script.
2) Get the Export entry name from the original PCC targeted by the script
---- Here's the bit I'm foggy on. Is the Export entry name the same across PCC's? Gift tells me it is, and that my original plan of using the export offset isn't going to work because they change in the various copies of PCC. I can believe and understand that.
3) Search the new PCC for the Export name found in the Original PCC.
4) If found, add the new PCC to the list of files to be edited.

This functionality is in the latest revision, BUT DOESN'T INSTALL YET. The script still only supports a single PCC, so at this time, it'll just list the pccs. Or it'll self destruct cos it tries to make a script with multiple PCC's where there's only space for one. Dunno yet...
Reply

giftfish
Toolset Developer
Joined: 08 Jan 2016, 02:35

09 Jan 2016, 03:55 #3

@K --

Okay, so... we have two sort of separate problems.

First the export location/naming thing. It was good we stopped that conversation when we did; I was really tired, lol. I'm not sure if this plan will work. The issue is that not only can exports change, but names can be identical.

For example, BioD_Nor_203aGalaxyMap.pcc exists in both the base game and Leviathan DLC.

Exports 148-153 look like this in the base game PCC:
148: biog_galaxymap.GalaxyMap.SFXCluster.SFXSystem.BioPlanet
149: biog_galaxymap.GalaxyMap.SFXCluster.SFXSystem.BioPlanet
150: biog_galaxymap.GalaxyMap.SFXCluster.SFXSystem.BioPlanet
151: biog_galaxymap.GalaxyMap.SFXCluster.SFXSystem.BioPlanet
152: biog_galaxymap.GalaxyMap.SFXCluster.SFXSystem.BioPlanet
153: biog_galaxymap.GalaxyMap.SFXCluster.SFXSystem.BioPlanet
All 6 exports have the same name and packages (but contain different data).

Exports 148-152 in the Leviathan PCC look like this:
148: SFXGameContentDLC_Shared.SFXPlanetFeatureGAWUpdate.GetGalaxyCamera.oPC
149: SFXGameContentDLC_Shared.SFXPlanetFeatureGAWUpdate.GetGalaxyCamera.ReturnValue
150: SFXGameContentDLC_Shared.SFXPlanetFeatureGAWUpdate.GetGalaxyCamera
151: SFXGameContentDLC_Shared.SFXPlanetFeatureGAWUpdate.FeatureProbed
152: SFXGameContentDLC_Shared.SFXPlanetFeatureGAWUpdate
153: SFXGameContentDLC_Shared.Default__SFXPlanetFeatureGAWUpdate
Obviously totally different types of exports.


So... this is problematic. MOD files are incredibly handy for mesh mods, as well as small content mods that only edit a file or two -- especially a file that might be used by other content mods. BackOff, for example, is a huge animal. The best way for other folks to handle compatibility if they're releasing a mod that only edits a file or two, would be to just release their mod as a MOD file.

But, as far as I can tell, that can't work, unless the MOD is specifically created for base game versus BW DLC/DLC mod, there's no way to ensure the proper objects are being replaced. Or... is there some way that I'm not seeing?


Second, we have the DLC extraction thing which you commented on the new release thread:
--- Modmaker was extracting all ME3 DLC's whenever a mod was installed, regardless of whether DLC was modified or not. Now it only does it when DLC is modified.
A message has also been added to indicate that it could take a great deal of time to do so.
Cancelling will result in TOC's not being updated and the game likely won't start.
I hope Fob and Heff read this since all 3 of us were really active in that thread back when we were working this out for Texplorer. They might very well have implemented that code for the change in ModMaker.

I think the key point back then is TOCing wasn't working properly b/c the TOCs weren't being extracted from the BW DLC. As a result we had TOCs inside the SFARs in BW DLC and TOCs outside the SFARs in DLC mods. That's when we decided that for texture replacement to be handled appropriately with BW DLC *and* DLC mods, all BW DLC needed to be extracted. This ensured all the TOCs were in the same place (outside the SFAR), since attempting to update TOCs inside and outside the SFAR failed.

So, my impression is that Fob and Heff likely made DLC extraction the norm any time a TOC was run with DLCEd2. If this functionality can be amended so when it runs via MM it doesn't extract and TOC anything that wasn't modded, I'd say that's probably fine. The user should have the choice, and it would be nice if it didn't bork their game if it they decide not to.

I'm not understanding about that last part, K. If a user says to not apply the changes to the SFAR, with their game get borked?
Reply

KFreon
Toolset Developer
Joined: 16 Apr 2013, 00:57

09 Jan 2016, 23:52 #4

Generally mods have to be built to replace the required objects by the creator. So if it was you for BO (which is DLC right?) you'd make a mod replacing the object in the DLC PCC so it overrode the basegame, then you wouldn't have to do it in basegame (generally...sometimes this isn't right).

I'll try to clarify the last part regarding what was happening and what should happen.
What was happening, was that anytime TEXPLORER (not DLCEd2) updated TOC's, it'd extract all DLC and update them too. This happened regardless of the need to actually update the DLC. You could replace a basegame only texture and it'd extract DLC.
That's obviously not required.

What should happen (and now does) is when TEXPLORER updates TOC's, it checks to see if a DLC was modified (by making a list of the changes before it even does anything) and then extracts all the DLC if necessary. Ideally it should only extract the DLC's that need updating, but that'd take extra work, and this way, it's only painful once.

TL;DR It was Texplorer's fault for extracting DLC's all the time, it does it smarter now, SFAR's are still irrelevant.

I'd love to take another crack at the weird TOC/DLC thing, cos that really annoys me. Likely not before the stable though.
Reply

giftfish
Toolset Developer
Joined: 08 Jan 2016, 02:35

10 Jan 2016, 01:25 #5

KFreon wrote:Generally mods have to be built to replace the required objects by the creator. So if it was you for BO (which is DLC right?) you'd make a mod replacing the object in the DLC PCC so it overrode the basegame, then you wouldn't have to do it in basegame (generally...sometimes this isn't right).
I understand how it works and I'd never use it for BO. My point was that it would be nice if MM could instantly recognize PCCs with the same in multiple locations, including BW DLC and DLC mods, if that PCC is supposed to be modified.

However, the DLC mod issue us particularly difficult to address, since you can't be sure if it's PCC files are from the base game or BW DLC.

KFreon wrote:I'll try to clarify the last part regarding what was happening and what should happen.

What was happening, was that anytime TEXPLORER (not DLCEd2) updated TOC's, it'd extract all DLC and update them too. This happened regardless of the need to actually update the DLC. You could replace a basegame only texture and it'd extract DLC.

That's obviously not required.

What should happen (and now does) is when TEXPLORER updates TOC's, it checks to see if a DLC was modified (by making a list of the changes before it even does anything) and then extracts all the DLC if necessary. Ideally it should only extract the DLC's that need updating, but that'd take extra work, and this way, it's only painful once.

TL;DR It was Texplorer's fault for extracting DLC's all the time, it does it smarter now, SFAR's are still irrelevant.

I'd love to take another crack at the weird TOC/DLC thing, cos that really annoys me. Likely not before the stable though.
Huh, okay. I thought Texplorer used DLCEd2 to do both the extraction and TOCing.

I'm now confused though, Texplorer extracts all DLC when treebuilding, not when TOCs are being updated... why would it extract then? Or... do you mean ModMaker?

The issues with ModMaker and DLC aside, Texplorer's new method of DLC extraction and TOCing the PCConsoleTOC.bin files outside of the SFAR has been working perfectly. Don't mess with it unless you really need to, lol.
Reply

giftfish
Toolset Developer
Joined: 08 Jan 2016, 02:35

08 Feb 2016, 17:40 #6

I wanted to revisit this discussion, since I'm already getting questions about BackOff, ME3Recalibrated, and how they are "incompatible" with Ashley Legacy Project, which is a very popular mod.

Of course, they really aren't incompatible, per se. But, there's two problems:


1. The .mod files were not made with DLC mods installed, so the exports inside DLC mod files can't be modified, since the .mod doesn't point to them, specifically.
2. ModMaker doesn't have the ability to see DLC mods or replace inside of them. It remembers a static collection of files, only the base game and BW DLC.


So, basically, the issue is that .mod files cannot be used with DLC mods. This is problematic.


K discusses the problems with trying to force MM to locate the correct objects in DLC mod PCCs, so I'm not sure #1 is feasible. The solution to #1 might simply be that the author (or someone else) has to make a compatible mod file.

However, #2, could be feasible. It would mean that ModMaker would need a "treebuilding" mechanic similar to Texplorer. Upon first use it would scan all files inside BIOGame. This would allow DLC mods to be affected by the changes in .mod files, just like .tpf files.


Obviously this would be a big change, and I'm sure it would take a lot of time and effort to implement. With this being the final stable for the foreseeable future, it probably isn't practical. But, this is the only solution I see.

Without this, I think we'll need to start being more up front that .mod files and DLC mods are not compatible in a practical sense, and that the only way mods like ALP can be compatible with DLC mods is if explicit patches are made for them. Patch files would only need to include the mesh edits, which can be done just by extracting all the jobs via ModMaker, and then using the Replace w/BIN feature inside PCCEd2. From here, users can just make their Texplorer tree with the DLC mod installed, and then the textures associated with the mod can be applied to the mesh/DLC-modded files.
Reply

KFreon
Toolset Developer
Joined: 16 Apr 2013, 00:57

09 Feb 2016, 07:33 #7

I toyed with the idea of a tree of all game objects and have each tool pull out the bits they need. i.e. Texture tools pull out textures, mesh tools/modmaker pull out meshes.

In the short term, someone could just adjust the most popular incompatible mods to work on the DLC files they need to.
Reply

giftfish
Toolset Developer
Joined: 08 Jan 2016, 02:35

09 Feb 2016, 14:43 #8

KFreon wrote:I toyed with the idea of a tree of all game objects and have each tool pull out the bits they need. i.e. Texture tools pull out textures, mesh tools/modmaker pull out meshes all other exports.

In the short term, someone could just adjust the most popular incompatible mods to work on the DLC files they need to.
Fixed :P
Reply