You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Was just looking at a few examples and this came to mind. There's a case where EasyNPC is doing nothing interesting with an NPC, and in this case it should skip them: When the default plugin is the last plugin in the load order to modify that NPC, and either of the following are true:
The face plugin is the same as the default plugin
The face plugin is the originating master and the default plugin doesn't modify face attributes (has same face as the originator)
In this case, EasyNPC would just be creating an ITM, and possibly a useless facegen to boot. Even if the default plugin has a facegen, despite not having face edits in the plugin, EasyNPC still doesn't need to copy it because, as a master, the default plugin/mod is going to remain installed.
It's minor, but this would have helped with workarounds for some of the children issues in #60, could have been a way to prevent those children from ever being added to the output mod, but without this feature that won't work.
This is separate from the request to manually exclude NPCs. This would automatically exclude NPCs that aren't being modified in any interesting way.
The text was updated successfully, but these errors were encountered:
The component will be used for top level info in new reports e.g. pre- and post-build reports (#37, #17, #51, #61, #78, etc.)
This is especially for the pre-build report, for which the flow is becoming too unwieldy and needs to be redesigned.
If one npc template has another npc, using a different face in this case may cause problems. I'm not quite sure how the template works exactly but it should be a point worth noting, maybe skipping them or giving them the same face automatically
This is the minimum required to display and interact with a profile based on the new analysis and mod repository code, not counting the XAML changes to the main Profile page. Most of the WPF components are just extracted from the original Profile page, but made standalone in order to provide better view/viewmodel encapsulation.
Not "fully" tested but all of the basic flows seem to work when integrated with the main app (TBD in a later commit).
#85#64#61#51#49#37#26#22 (doesn't complete any of these, but advances all of them)
Was just looking at a few examples and this came to mind. There's a case where EasyNPC is doing nothing interesting with an NPC, and in this case it should skip them: When the default plugin is the last plugin in the load order to modify that NPC, and either of the following are true:
In this case, EasyNPC would just be creating an ITM, and possibly a useless facegen to boot. Even if the default plugin has a facegen, despite not having face edits in the plugin, EasyNPC still doesn't need to copy it because, as a master, the default plugin/mod is going to remain installed.
It's minor, but this would have helped with workarounds for some of the children issues in #60, could have been a way to prevent those children from ever being added to the output mod, but without this feature that won't work.
This is separate from the request to manually exclude NPCs. This would automatically exclude NPCs that aren't being modified in any interesting way.
The text was updated successfully, but these errors were encountered: