r742, ModMaker, Install error when DLC isn't unpacked

[giftfish]

This directly relates to the new DLC extraction procedure, but I figured it's easiest to create a new issue for this problem, specifically.

Something I pointed out prior to the change to extraction was that tools that depend on it should be disabled if the extraction isn't allowed. Not doing this would create problems, which it does.

Here's what happens if you exit out of the extraction, run ModMaker, then try to run a .mod file that modifies the unextracted DLC:

The tool will throw the error b/c it can't install to the SFAR, but what's really funny is that it will then proceed to unpack the SFAR and TOC the DLC.

W.t.f.

Yeah, so we created this situation and it's not something we want in place. I supplied multiple suggestions when we first talked about it and they all still apply. We need a better system of checks in place to prevent these issues. Making extraction 100% mandatory was the initial plan, but we're now allowing for exceptions. Exceptions makes things a lot harder to foolproof. I'm open to discussing how to do it, but we are shooting ourselves, users, and modders in the foot if we ignore this before the stable.

One example of a solution. If DLC are still packed and the user loads a .mod file that alters DLC, MM should throw an error message. It should say something like...

"This .mod contains jobs for an unpacked DLC. Please re-open the toolset and allow for DLC extraction before proceeding. If you permanently disabled DLC extraction in the Advanced Options Menu, you will need to re-enable it to allow for the extraction."

Then, the tool should not allow the .mod to be installed. If we want to give users the option to install other jobs for the base game (or whatever) in that same .mod file, then MM should trigger a slightly different message and act accordingly:

"This .mod contains jobs for an unpacked DLC. Please re-open the toolset and allow for DLC extraction before proceeding. If you permanently disabled DLC extraction in the Advanced Options Menu, you will need to re-enable it to allow for the extraction. You may also proceed with installation, but this will only affect base game and unpacked DLC files."

---

ANOTHER EXTRACTION IDEA

I'll throw out one other idea related to extraction, and place it here for convenience. Also see #132 .

There are two reasons we wanted to pull out extraction to the forefront of the toolset:

1. Most of our users install textures, which requires DLC extraction for them to modded.
2. The extraction code is integrated into both ModMaker and Texplorer. Pulling it outside of these two tools and placing it at the beginning as part of the initial toolset setup process makes sense. Most users need to do this before they do anything else.

However, another way we could achieve both of these is via the following:

1. Remove the initial DLC extraction check and the option to turn it off.
2. Make a new interface/tool, called "DLC Configurator" that is placed in the Options Menu.
3. It has the ability to recognize ME3 DLC and displays a list of what's present -- BW and DLC mods.
4. It will extract all DLC with a single click.
5. It it checks for proper DLC format by checking the location of the TOC and ensuring it isn't in the SFAR. It will extract the TOC if necessary. Once properly unpacked the DLC is flagged as "Active".
6. I integrate the setup of the new Configurator into the toolset's initial setup on the wiki.

To accompany this, ModMaker, TPF Tools, and Texplorer contain an additional menu element:

Active ME3 DLC

Clicking on it shows which DLC will be affected by changes and reminds users that only those DLC and the base game will be affected. If a user tries to install something for a DLC that isn't Active, then one simple error message suffices for all situations in all 3 tools:

Certain modifications should affect DLC that are currently Inactive. These changes will not be applied. Do you wish to continue? Y/N

If the user clicks "yes", then all 3 tools ignore any textures/jobs that affect "inactive" unpacked DLC. They don't automatically unpack it; they don't do anything. They just act like it isn't there and leave it alone.

Finally, Texplorer's scanning setup only applies to unpacked, Active DLC, as well. Scanning no longer unpacks things in itself, it only scans what's been unpacked by the Configurator (and what the user tells it to scan). We'd likely need a new check before the initial scan, to be sure folks have done this, so they don't end up just scanning on base game.

This is just an idea, but it seems like a more streamlined system with less room for error. Btw, unpacking of individual DLC can stay a "power user" feature, native only to DLC Editor 2. We'd need to keep things simple for the configurator, since texture folks can't be mixing extracted and unextracted DLC.

@KFreon , @MrFob , @SirCxyrtyx , please share your thoughts.

[KFreon]

@giftfish Gonna need the script used there.

I removed the DLC extraction thing in Modmaker too.
During TOC if DLC isn't extracted i.e. any pcc in any DLC folder, then it won't TOC DLC's.

As for your idea, I kinda like it, but I feel it's that "put a bunch of things in the way of progress" vibe.
I suppose I like the window bit, where you can see details about all the DLC's, something I've tried to put into the WPF rewrite.
But I don't like having to enable a thing to have the toolset use DLC for two reasons.

1. Puts another thing in there a user has to do before they can do what they want, and adds something for them to forget.
2. DLC overrides basegame stuff, so if they do forget or decline DLC extraction, they might as well quit and play another game, cos half of their stuff is going to be missing.

[giftfish]

@KFreon -- Any idea what the deal is with Git and zip files? Happy to give you the script, but 'd be nice if Git's upload worked like it was supposed to.

As far as extraction, like I said, I'm open to suggestions, but we need to address the problems with the new system. What we initially discussed and put in place was a 100% foolproof, mandatory system. It was impossible for folks to fuck up, and was easy to explain on the wiki. That is no longer the case.

The wiki is something I'm particularly concerned about. The more complicated we make the new procedure, the more difficult it will be to explain on the wiki. We really need to keep it as simple as possible.

"Putting a bunch of things in the way of progress" is sometimes necessary. It isn't a bad thing. Like satisfying prereqs in college. We're saying, "Look, you can't do B until you've done A first, since B requires A. If you try to B first anyway, you're going to have problems, so we're going to take steps to prevent you from doing that."

Again, this is not a bad thing.

At any rate, #200 is the main part for the whole DLC extraction thing. I'll make more specific comments once you respond there :)

[KFreon]

I don't know git's deal with zips. I haven't tried to put them in here, but Creeper hasn't had an issue.
He has been using 7z though.

Maybe just on pastebin?

Putting things in the way isn't always bad, but I feel like this would be like saying "you can do A if you wear clothes". It's something that basically has to be done and doesn't need to show the user anything specific.
"We're extracting DLC's upon toolset open", that's all they need to know.

[KFreon]

Fixed that script error. One little semicolon...

[giftfish]

@KFreon -- Pastebin is a good idea. I'll try 7z in the future, but if that doesn't work (and I don't catch you on Skype), pastebin will be the way to go.

Putting things in the way isn't always bad, but I feel like this would be like saying "you can do A if you wear clothes". It's something that basically has to be done and doesn't need to show the user anything specific.
"We're extracting DLC's upon toolset open", that's all they need to know.

And if DLC extraction was indeed mandatory, I would 100% agree with you. But it's not. We have to expect that new, inexperienced users will waffle on the extraction, decide to bypass it, and then later on in the same session, try to install a .mod file. I can guarantee it will happen.

But, the "new" extraction idea aside, what about the first part of the OP above? We need some type of warning if folks try to install a .mod file that affects DLC, if they've bypassed the extraction. I know it means another dialog -- which you don't want and will hate -- but I don't see a way around it. If we're going to allow people to bypass, this warning is the cost of us allowing that flexibility.

[KFreon]

I've got a message in there if a mod operates on DLC but the DLC isn't extracted. Might only be on Run All now that I think about it...

I think it's more likely that people would forget to click the button, and be not modifying DLC, thus making their modifcations mostly worthless.
Anyway, more input/new ideas might be useful.

[giftfish]

@KFreon -- Are these changes in rev744? Before I can provide more feedback, it's probably useful if I can see how it's currently working.

[giftfish]

@KFreon -- Reviewing the release notes for r744, and I'm guessing that this hasn't been implemented yet. I'll do my best with what you've explained so far:

If the warning message is only tied to "Run All", then it definitely needs to be tied to "Run Selected", as well. Those are the only two ways to run a .mod as far as I can tell, but it's important that any way to run a .mod file will trigger the warning when DLC are unextracted and a DLC job is present.

Could you please copy/paste the text for the warning here? That way I can review it and provide some feedback on whether it includes enough information, and we're not having to wait for the next release for me to see it :)

[KFreon]

It should be in there by now.
EDIT: Just checked. Was in 744 for sure.

Basically says:
"Some jobs contain DLC references, but you don't have DLC extracted. You should restart the toolset and allow DLC Extraction.
Continue installing anyway? If you do, only basegame will be affected."

[giftfish]

@KFreon -- Okay cool. I'll do testing on 744 today.

Thanks for posting the message. Basically, it says exactly what I posted in the OP (just in your way). It is missing the reminder about if extraction was permanently disabled, though, so you might want to toss that in there. If you don't, I'll be sure to put a reminder on the wiki about it when I update the article with new procedure.

[giftfish]

FYI, I'm getting this message when I shouldn't. See #140 .

Also, getting the exact same error as in the OP with rev744.

EDIT: And, can verify that the "no DLC extraction" message does not pop up when using "Run Selected". It should, though.

[KFreon]

I didn't want any unnecessary text on that message, my thinking being that anyone who knows about the disabling would be jogged about it by the message.

The Run selected message wasn't in 744, I just added it.
I'll check the the other stuff when I get home.

[KFreon]

I'll get you to try on the OP error on the next rev cos it might mean the script isn't getting uploaded to git or updated by VS properly.

[giftfish]

I think this issue can be closed, @KFreon .

This was actually an amalgam of five issues:

1. "Run Selected" wasn't providing a DLC warning, like "Run All". This has been fixed.
2. After failing to install to packaged DLC, Mod Maker unpacked it after the fact. This has been fixed.
3. Then, it was TOCing all DLC (and the base game). The former has been fixed, the latter has been moved to a separate issue.
4. The script for the mod I was testing didn't work. Also moved to a different, ongoing issue.
5. I presented an alternate idea for DLC extraction/pathing. This has been vetoed for now.

Since 1-3 above were the main parts, have been resoled, and other related issues have been relocated, I think we can close when you're ready, K.