Suggestion: Popping up warning if user is generating a group and has its own esp/name blacklisted

[Xetaxheb]

Don't know if it's a bug or intended behavior, but I don't advocate blocking or circumventing it outright because there could be use cases? But a warning that "you have set this group to ignore its own esp and so patchers will not base their data off the previous patchers results, only pre-patched data" might be helpful.

[Noggog]

Not sure what you're suggesting. All patchers automatically ignore their "own" esp and any esps that come after themselves in the load order. They only ever consider esps that come before their output esp. So adding a patchers own esp to its blacklist shouldn't change its behavior (as it always is doing this anyway)

Here's some reading on what patchers consider and how: https://github.com/Mutagen-Modding/Synthesis/wiki/Load-Order-and-Previous-Patchers

[Xetaxheb]

Unless i'm wildly deluded, i'm experiencing different nuance and function than "adding a patchers own esp to its blacklist shouldn't change its behavior (as it always is doing this anyway)". That statement should only apply to the first patcher in a group, as it basically deletes and creates anew the group esp, and subsequent patchers build off of the saved esp from the prior patcher... unless it's blacklisted in the group header, sort of breaking interoperability. (technically it's doing exactly what it's been told and honestly should be kept for unique usage reasons)

premise: group named Xeta Normal synthesis usage: If I run a group,

1. patcher a starts
2. patcher a creates and saves Xeta.esp,
3. patcher b (in the same group) starts,
4. patcher b sees the Xeta.esp from patcher a, makes changes based on patcher a's output,
5. patcher b saves the new version of Xeta.esp,
6. patcher c (still in the same group) starts, sees the Xeta.esp from patcher b, makes ch[anges based on patcher b's output,
7. patcher c saves the new new version of Xeta.esp,
8. etc in sequence

The problem:

Essentially: If I have a group named Xeta, and in that synthesis group header I blacklist Xeta.esp, patcher b does not see patcher a's modified (newly created, whatever) esp. Whether this is a bug is open to interpretation, but judging from your response is probably a bug ? This part on that documentation is not happening. They are operating on the unpatched data because they are being told to ignore the patched data Xeta.esp. https://github.com/Mutagen-Modding/Synthesis/wiki/Load-Order-and-Previous-Patchers#within-a-group

What I'm suggesting: Changing nothing but adding a warning popup when "Group Xeta has Xeta.esp blacklisted" because it breaks patcher b seeing patcher a's changes, patcher c seeing patcher b or a's changes, etc

[Xetaxheb]

You can reproduce this yourself with any patchers that modify the same data in some way, easier to see with relative changes. As I said in discord #.synthesis I was having struggles with leveledlistresolver+synnomoreeasyenemies as well as speedandreachfixes when being used twice.

But a potentially simpler example: -putting skyrim.esm alone into synthesis, and potions in skyrim weigh 0.5 by default

1. If you had synpotionweight (sets all potions to exactly x weight) setting potions to 100 weight
2. Itemweightcustomizer (multiplies weight values) setting potions to *0.1 weight

if not blacklisted, first spw sets weights to 100, then iwc multiplies that by 0.1 and gets... 10 weight per potion if blacklisted, first spw sets weights to 100, then iwc only sees skyrim.esm and multiplies that by 0.1 and gets... 0.05 weight per potion.

iwc doesn't see / actively ignores spw's changes because it was told to ignore the group esp.

and yes i just tested this on a clean install exactly as described

update: annnd now i can't figure out how to reproduce this anymore so i'm not sure how I was managing it before but I definitely had a marked difference between blacklisted and non-blacklisted.... maybe there's some weird edge case or quirk going on or i'm just incredibly delusional but I guess if it's not happening in your test then can close and ignore for now ¯\_(ツ)_/¯