Jump to content

New idea for lvlPredatorScript by Inki


VaultDuke

Recommended Posts

(I'm posting this here because Inki wanted to get the word around, but had no time to pursue the idea any further himself. Maybe this is interesting for the script gurus around here)

Ok, I may be on thin ice here with the USKP team, but since I already brought up one thing I noticed a long time ago, I might just as well also comment on the LvlPredatorScript fix. I don't doubt that it works, but I think you might eventually wish to streamline it.

 

As I see it, there are two classes of predator references, that the script applies to:

- Those without the Solopredator keyword. I would call these "primary" predators, and they are intended to be always spawned, unless disabled by an enable parent. (Typically they are disabled in order to clear the area for a Civil War scenario.)

- Those with the Solopredator keyword. I would call these "secondary" predators, which are always linked to a primary predator, and the essential purpose of LvlPredatorScript is to ensure, that they are enabled only when they are compatible with their primary partner, so that we dont get skeevers roaming together with cats or two solo-type predators roaming together. The fundamental conflict in the vanilla game arises when these are also made subject to an enable parent, as that precludes the use of scripted disablement.

 

In addition, the vanilla LvlPredatorScript creates a purely artificial conflict in that it is written to always either disable or enable its host, even when it is attached to a primary predator, for which the purpose of the script is completely irrelevant. Thus we get the conflict with enable parents even with these, although there is no fundamental reason for that conflict to arise.

 

The natural first fix for the LvlPredatorScript would be to restrict its activities to only the secondary predators, for which it is relevant, and the information to do so is readily available in the script. Just simply stop systematically enabling all the primary predators, who have no need for it. That would readily eliminate the conflict for all the primary predators, who would then happily just track their enable parent, if one exists. The conflict would then be limited to only those secondary predators, which also have an enable parent set, and the natural second fix is then to unset their enable parents and replace them with an overall scripted solution. If I remember correctly, there are only 21 (or was it 22?) such secondary predator references in the Skyrim game world (I once looked them all up).

 

The current USKP fix does not implement the natural first fix described above, and as a consequence, it has to implement the second fix for a much larger crowd of both primary and secondary predators with an enable parent, (there was a larger number of those than I cared to start counting).

 

Essentially, then:

- A larger number of world references are currently edited, than would necessarily have to be.

- For a large number of primary predators, the inbuilt and efficient enable parent mechanism is needlessly replaced by a less efficient scripted mechanism.

 

I can fully understand, if you don't appreciate this comment, especially if there are many essential issues still to be covered, as no doubt the current LvlPredatorScript fix does work, even if perhaps not optimally in some sense. However, I hoped, that you might wish to be informed about this, and perhaps later have a closer look at it.

 

Then again, it may also be your design choice to systematically use the same approach to both primary and secondary predators, and that is fine, in which case I guess I should apologize for intruding on it like this.

 

P.S. Perhaps I might add: Approaching this issue from the perspective of first stripping to a bare minimum what LvlPredatorScript actually does, as in not allowing it to needlessly enable/disable primary predators, and perhaps even then restricting it to only touching on secondary predators when necessary, might be good from a general performance point of view. The script is run when a cell loads, which is probably a busy time, and any explicitly scripted redundant actions just add to overall system loading, which may or may not be relevant on a marginally capable system. [Also fixed a couple of typos.]

original post: http://forums.bethsoft.com/topic/1497829-relz-unofficial-skyrim-patch-thread-41/?p=23637592

A couple of posts back, I made some noises about the LvlPredatorScript script fix, as I had too much time on my hands.
 
Unfortunately, I ended up making some additional remarks, which I did not originally intend to do. So, in order to not leave my current incursion in this thread at that, I dug into my archives a year back and found an alternative version of the LvlPredatorScript, which I am attaching below, just in case it might be of any interest to anybody out there. Since it is a bit old and I haven't looked at it since, I cannot entirely vouch for it now, but at least it demonstrates a slightly different approach to the issue.

Scriptname LvlPredatorScript extends Actor

Faction Property SoloFaction1 Auto
Faction Property SoloFaction2 Auto
Faction Property SoloFaction3 Auto
Keyword Property SoloKeyword Auto

EVENT OnCellLoad()
    ObjectReference ORef = GetLinkedRef(SoloKeyword)
    if ORef
    else
        GoToState("Doze")
        return
    endif
    bool Off = IsDisabled()
    if IsInFaction(SoloFaction1) \
    || IsInFaction(SoloFaction2) \
    || IsInFaction(SoloFaction3) \
    || (Self.GetRace() != (ORef as Actor).GetRace())
        GoToState("Doze")
        if Off
        else
            DisableNoWait()
        endif
        return
    endif
    GoToState("Poll")
    if ORef.IsDisabled()
        if Off
        else
            DisableNoWait()
        endif
    elseif Off
        EnableNoWait()
    endif
endEVENT

STATE Poll
    EVENT OnCellLoad()
        bool Off = IsDisabled()
        if GetLinkedRef(SoloKeyword).IsDisabled()
            if Off
            else
                DisableNoWait()
            endif
        elseif Off
            EnableNoWait()
        endif
    endEVENT
endSTATE

STATE Doze
    EVENT OnCellLoad()
    endEVENT
endSTATE

;/
COMMENTS

For Primary predators:

The original script invariably enables primary predators. This is unnecessary and causes
an error in those cases, where they already have been assigned an enable parent.

This script begins by checking whether the predator is a primary one (it does not link to
another). If this is the case, the script places itself in a passive "Doze" state, which
stays valid until the cell resets.

For Secondary predators:

In the second phase, the script checks whether the secondary predator is incompatible with
the linked primary one (it is of a different race or it is defined as a solo predator by
the script properties).

If the secondary predator is found to be incompatible with the primary one, the script
disables the secondary predator and places itself in the passive "Doze" state, as this
situation will remain unchanged until the cell resets.

If the secondary predator is found to be compatible with the primary one, the script
places itself in a re-checking "Poll" state, where the enable state of the secondary predator is
adjusted to match that of the primary predator each time the cell is loaded. No redundant
re-checking of predator compatibility is done, as once per cell reset is enough.

One underlying assumption made in this script concerning secondary predators is, that the
corresponding primary predator, even if it gets killed, still "is there" and responds to its
possible enable parent. At any rate, the primary predator is a CK-placed reference, which even
is linked to, so it certainly can't be deleted from the game. This assumption allows one to simply
check the primary predator's enable state rather than having to construct an additional means to
link back to the original enable parent. This assumption may perhaps need some more rigorous
testing for absolute certainty.
/;


P.S. Just glancing over the script myself, after not having looked at it for a long while, brought to mind, that if one were to use this approach, one might also consider adding an additional branch in the script to move killed secondary predators to the passive "Doze" state. Also, it is left unstated in the script's comments, that the script requires the removal of enable parents for secondary predators, but not for primary ones. Well, that should do it for now.

 

original post: http://forums.bethsoft.com/topic/1497829-relz-unofficial-skyrim-patch-thread-41/?p=23639713

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...