z-edit / zedit-unified-patching-framework Goto Github PK

We need to be able to reload controllers/settings tabs, among other things.

So developers don't have to store their patchFile on locals or pass it around.

I've got a patcher that supports only gmFO4, but it is allowed to (attempt, and fail) to be applied to gmSSE and gmTES5.

I figure it should either be hidden entirely, given that it does not apply to the game mode at all, or it should be marked in red, similar to the patchers that do not have their required mods installed.

zEdit doesn't remember my layout of patches in the "build patches", I might have a zPatch.esp, and a True Unleveled skyrim.esp but when i restart zEdit it goes back to just zPatch.esp.

Found by praecipitor, occurs when not using customProgress.

Thinking it could either be using load as a function and returning an array of record handles OR adding a new syntax like getRecords which would do the same thing. The great advantage of this is it will support patchers which need to patch records based on how they are referenced from other records without developers having to resort to doing everything in initialize and manage customProgess.

The order of individual patchers within a patch file is not preserved between sessions. Every time you re-open the "Build Patches" dialogue, the order is reset to what appears to be asciibetical order.

Perhaps something like the following in patcherSevice's getPatchPlugins:

        patchPlugins.forEach(patchPlugin => {
            patchPlugin.patchers = patchPlugin.patchers
                .map((patcher) => [service.settings[patcher.id].order || 0, patcher])
                .sort((a,b) => (a[0] - b[0]))
                .map((e) => e[1]);
        });

And the following in buildPatchesController's updatePatchStatuses:

            patchPlugin.patchers.forEach((patcher, i) => {
                $scope.settings[patcher.id].order = i;
            });
            patcherService.saveSettings();

It looks like the repository no longer exists unfortunately.

Use angular.toJson.

From the point of view of maximum laziness, it would be nifty if settings.label were to default to info.name, and a <h2> with the value info.name were to be supplied at the top of the settings page, instead of having to specify.

I don't know of any existing patcher where these are not all the same (except where the author has made a typo, or left the value from the template in place).

Hi,
I've downloaded your utility, which seems to do a lot of great stuff, but I have a few perplexities:
a) I have made a zPatch.esp with all my files, but your patch is completely invisible to the Vortex mod manager...how I make it visible?
And, moreover, where is it stored? I am asking because the usual place ("C:\Users\Jashkar[user]\My Games\Fallout4") has no
reference whatever to mods, the mod folder inside the game folder is empty, the folders* used by Vortex seems to only have the
stuff that Vortex sees...in essence the zPatch.esp seems to be just the "imaginary friend" of your zEdit app! :-/
Do you have any idea of where it could be stored or how to force Vortex to see it?
b) How I can see if there are conflicts between mods? In the old-time editors (i.e., Wrye Bash, etc...) I remember there was the "filter
for cleaning" and I'd use that, but your utility seems to have moved away from that logic, the documentation isn't so clear about
that part and I couldn't find any tutorial about this... :( ...what is the equivalent of "filter for cleaning" in your utilty?
Or there is nothing as it is all automated?

( Moreover I was wondering if there is some way to understand which mods are better to patch and which ones aren't
good to patch...while I like a lot having automated things, not having any kind of information or suggestion from the utility about
what is better to merge or not feels worrisome... there is any way or any doc in which I could find more info about merging?
I am trying to play with a lot of mods, but, as I have Horizon, I notice that the number of individual patches is getting simply
ludicrous and each patch means one less esp available for other things... with Wrye Bash I remember that at a certain point, after
making the patch, you'd be suggested which mods you could simply remove... but there is no such a suggestion here or I can't find
it...there is a way to get this info from your new utility? )

Thanks,
Skarm

• = Frankly I don't get why Vortex needs to have 3.000.000 of bloody mod folders, but that has nothing to do with your utility...but...
  I am truly afraid that your utility isn't supposed to work with Vortex, but instead to work with more normal mod managers with less "geeky" crap...but I really hope there is a way to make it work with Vortex...which is why I am asking! :-/

The reduce doesn't add custom progress to the sum, so it will be 1 off when building a patch plugin with a single patcher with customProgress set, and very off when building a patch plugin with more than 1 patcher, where one or more has customProgress set.

It makes sense to let them do this given the nature of how customProgress usually works.

At present, there is a distinction between:

• zPatch.esp
  • Patcher 1
  • Patcher 2

and:

• zPatch.esp
  • Patcher 1
• zPatch2.esp
  • Patcher 2

The difference being that if Patcher 1 adds a new record, in the first scenario, that record will not be visible to Patcher 2, while in the second scenario it will not.

This is arguably a bug, as the documentation suggests that there should be no distinction between the two scenarios, other than the second one consuming two entries in the user's load order.