lvlPredatorScript -- Please explain

[IsharaMeradin]

I can understand not going backwards since it is now working the way it is.  Using an existing Bethesda keyword designed for the purpose rather than creating a new one does make sense.

 

Just to get the workings behind it straight... 

 

The bool would be false if no enable parent was present and set to true if there was an enable parent present, thus effectively stopping the script when the bool was true.  Since objects tied to an enable state parent do not load unless the enable state parent is enabled or disabled according to settings, there would be no instance of objects loading outside the scope of the enable parent's control.

 

USKP keywords replace the enable state parent and act as a middle man between enable state parent and the creature.  Thus the creature always loads and has to have the former enable state parent examined through the keyword in order to determine if it can stay alive or needs to be disabled.  Any other creature as well as those determined not needed to be disabled go on to determine if they need to be disabled due to faction or race.

 

The status of the enable parent (opposite or not) is not the reason the bool would fail.  The bool works in that regards.  The bool does not allow those creatures that are enabled by a parent (opposite or not) to be disabled if their faction or race was determined inappropriate.

 

In a nutshell, the bool does solve the commonly reported problem but allows for some unintended instances.  However, the game itself allowed for those unintended instances and no player would see a difference (when the script failed to disable the creature, the creature would still be enabled -- same result as the bool).  The USKP goes a step further and passes the creatures that otherwise would remain enabled through the rest of the script and disables them if necessary.  End result is with a USKP game there may be less creatures about under specific scenarios.

 

To answer my own question, the keywords were used as a link to the enable parent so that the enable parent would not be directly on the creature reference thus allowing it to be disabled if it met all the appropriate qualifications within the script.  Then new code needed to be added to handle the fact that the creature would be loaded and enabled despite the status of the enable parent.

 

I am fine with this, maybe it will prevent the frost troll from spawning that wiped out half the imperial force that was grouped and ready for me to assist in taking out the fort in Dawnstar's hold during the Civil War quest line.

 

FYI - I had a nightmare of a time trying to find modified records in the USKP.  False flagged ESPs are treated like ESMs and don't have their modified records marked with the *. Loading USKP in TES5Edit allowed me to scan the references for predators and see the changes made.  Then I could look up modified ones in the CK with the Find Text option.

 

BTW, I've seen the numerous issues that have cropped up have been flagged as corrected in 2.01.  

 

Is there a way to scan or search the track down for issues marked fixed for a yet unreleased version?

[Arthmoor]

Yeah. Pretty much what we've got here is this:

 

All of the predators that have this script have a linked reference pointing to an XMarker somewhere nearby. Bethesda, for other reasons, attached enable parents to SOME of these markers. Usually for the purpose of disabling them during the Civil War battles in a particular area.

 

The problem comes from the fact that their method is incapable of changing the enable status via the script when enable parents are involved. Papyrus simply won't allow it.

 

So keywords were brought in. One keyword is used to distinguish references where it has the same enable state as the marker: USKPPredatorEnableParentInjected

 

The other is used to distinguish those references marked as enable opposite of parent state: USKPPredatorInverseEnableParentInjected

 

The bool is insufficient here because it can only tell that it has an enable parent, not what state it's supposed to be in. Plus, regardless of whether a bool gets used or keywords get used, the enable parent setting has to be removed before the script can act on it. So no matter what option gets pursued, the references need to be edited.

 

Injected records DO carry some small amount of risk of ID collisions with other mods doing the same kind of thing (and they do exist) so it's definitely safer to switch these off to vanilla provided keywords instead while keeping the current working structure intact.

 

Sorry, no, the tracker has no means to scan for what's being closed for a certain version. It's only possible to tag that in a comment and tracker search doesn't look there.