Jump to content

Overhauling the weapon rack scripts


Sclerocephalus

Recommended Posts

OK, I'll take a breather from critters and poke at racks now,

Admiral Akbar says "ITS A TRAP"

 

Seriously though ya both do need loving ;)

Link to comment
Share on other sites

Ran into this one today:

[01/30/2014 - 05:49:23PM] Error:  (000F01EC): has no 3d, and so cannot have its motion type changed.
stack:
    [ (000F01EC)].ObjectReference.SetMotionType() - "<native>" Line ?
    [ (000F01E1)].weaponrackactivatescript.PlaceItem() - "WeaponRackActivateScript.psc" Line 576
    [ (000F01E1)].weaponrackactivatescript.CheckRackType() - "WeaponRackActivateScript.psc" Line 454
    [ (000F01E1)].weaponrackactivatescript.ActivatorSetup() - "WeaponRackActivateScript.psc" Line 286
    [ (000F01E7)].WeaponRackTriggerSCRIPT.ActivatorCheck() - "WeaponRackTriggerScript.psc" Line 190
    [ (000F01E7)].WeaponRackTriggerSCRIPT.OnCellAttach() - "WeaponRackTriggerScript.psc" Line 77

I checked. F01EC is disabled, but the script is still trying to move it into place despite that. The item is meant to be disabled at this point since it's in the DB Sanctuary after the place has been torched.

Link to comment
Share on other sites

[01/29/2014 - 10:39:27PM] [weaponrackactivatescript < (00084CF4)>]EmptyRack: OnCellAttach() ERROR: missing WRackTrigger. State now 'Inactive'.

(USKP 2.0.1 Beta)

USKP has already dropped this -30000 under the Riverwood Trader and disabled it. But being disabled is a normal condition. I don't know why it's attaching, as it's out of the "cell". Maybe all things interior do that?

Anyway, I've written some code to suppress the message. All you have to do is add the missing link, but to player instead of a rack.

 

These errors were from using the 2.0.1 beta(s), but not on a new game.

[01/30/2014 - 12:31:12AM] error: Cannot call GetTriggerObjectCount() on a None object, aborting function call
stack:
    [ (000A8B8C)].weaponrackactivatescript.ActivatorSetup() - "WeaponRackActivateSCRIPT.psc" Line 296
    [ (000A8B90)].WeaponRackTriggerSCRIPT.ActivatorCheck() - "WeaponRackTriggerSCRIPT.psc" Line 190
    [ (000A8B90)].WeaponRackTriggerSCRIPT.OnLoad() - "WeaponRackTriggerSCRIPT.psc" Line 66
[01/30/2014 - 12:31:12AM] warning: Assigning None to a non-object variable named "::temp18"
stack:
    [ (000A8B8C)].weaponrackactivatescript.ActivatorSetup() - "WeaponRackActivateSCRIPT.psc" Line 296
    [ (000A8B90)].WeaponRackTriggerSCRIPT.ActivatorCheck() - "WeaponRackTriggerSCRIPT.psc" Line 190
    [ (000A8B90)].WeaponRackTriggerSCRIPT.OnLoad() - "WeaponRackTriggerSCRIPT.psc" Line 66
[01/30/2014 - 12:31:12AM] error: Cannot call ActivatorDone() on a None object, aborting function call
stack:
    [ (000A8B8C)].weaponrackactivatescript.ActivatorSetup() - "WeaponRackActivateSCRIPT.psc" Line 301
    [ (000A8B90)].WeaponRackTriggerSCRIPT.ActivatorCheck() - "WeaponRackTriggerSCRIPT.psc" Line 190
    [ (000A8B90)].WeaponRackTriggerSCRIPT.OnLoad() - "WeaponRackTriggerSCRIPT.psc" Line 66
These are more of the spurious OnLoad() errors. I've tried to prevent them with every test known to mankind!

Until Sclero added that damn OnLoad(), nothing expected it. And although he's correct it's somewhat better than having to enter and leave a hearthfires house for newly built weapon racks to activate, it's a special case that really hasn't been worth the effort! What a mess!!!

Anyway, I've added a new state TriggerLoading, which is used during OnCellAttach(). That will also suppress spurious OnLoad() in yet another way....

Ran into this one today:

 

[01/30/2014 - 05:49:23PM] Error:  (000F01EC): has no 3d, and so cannot have its motion type changed.
stack:
    [ (000F01EC)].ObjectReference.SetMotionType() - "<native>" Line ?
    [ (000F01E1)].weaponrackactivatescript.PlaceItem() - "WeaponRackActivateScript.psc" Line 576
    [ (000F01E1)].weaponrackactivatescript.CheckRackType() - "WeaponRackActivateScript.psc" Line 454
    [ (000F01E1)].weaponrackactivatescript.ActivatorSetup() - "WeaponRackActivateScript.psc" Line 286
    [ (000F01E7)].WeaponRackTriggerSCRIPT.ActivatorCheck() - "WeaponRackTriggerScript.psc" Line 190
    [ (000F01E7)].WeaponRackTriggerSCRIPT.OnCellAttach() - "WeaponRackTriggerScript.psc" Line 77
I checked. F01EC is disabled, but the script is still trying to move it into place despite that. The item is meant to be disabled at this point since it's in the DB Sanctuary after the place has been torched.
Well, I don't know how!?!? It's the very first StartingItem test:

ObjectReference StartingItem = GetLinkedRef()
If StartingItem && StartingItem.IsEnabled()
Link to comment
Share on other sites

And yet it doesn't seem to care :P That test for IsEnabled() is obviously not doing the job.

 

Welcome to our world btw, where shit we swore up and down as fixed simply isn't and there's no explanation for it.

Link to comment
Share on other sites

Here's the current state of the code. More for Arthmoor, but anybody can take a gander.

In addition to the simple additional checks, I've started laboriously finding and flagging the bad racks.

For the backwards backing racks, it tells you the ERROR, and you bring up the linkref dialog box, select cell "(any)", it fills in Player for you, you type keyword "WR" and it finishes with "WRActivator", hit enter, and OK, you're done.

For the others, it gets more complicated. The script tells you the error. But sometimes you have to add more. Where USKP tried to remove a script, that doesn't work -- the script is still there somehow. But the keyword properties have been erased!!! :cry:  So you have to add keyword NONE as well as the usual. In some cases, you end up with 3 links.

Take a look at the esp with TES5Edit, you'll see what I mean.

Link to comment
Share on other sites

And yet it doesn't seem to care :P That test for IsEnabled() is obviously not doing the job.

 

Welcome to our world btw, where shit we swore up and down as fixed simply isn't and there's no explanation for it.

Is it the same object moved to a different rack?

 

Anyway, is there a faster way to discover which racks are backwards? And whatever other racks need to be fixed? Can we divvy up the task?

 

If you are anywhere near another beta, this code is the candidate. And the critter code, too.

Link to comment
Share on other sites

At the end of the day, a summary of what's fixed in the latest code:

 

CheckFor3D is slightly faster, using my improved version from Critter.

 

Checking that the visible rack itself 3D has loaded. No version previously bothered, as it usually takes no more time than the weapons to be loaded. But an error was reported....

 

Ensure that the PlayerRef property is set on old savegames.

 

Test for special Linked References to PlayerRef, used solely to signal that errors have been examined and mitigated (eliminating error log lines).

 

Under the hood, add some more states (ActivatorMissing, TriggerDisabled, TriggerLoading) that manage error reporting. They should have no affect on actual operation, but may reduce occasional spurts of papyrus logging.

Link to comment
Share on other sites

So what are we doing with the PlayerRef property anyway? I think I missed that somewhere.

 

This "linked refs to PlayerRef" thing sounds ominous to me. I'm not sure I like the sound of that.

Link to comment
Share on other sites

"linked refs to PlayerRef" explained. I'd mentioned it a couple of times above.
 
The Trigger script (visible rack) is looking for:

ObjectReference myActivatorRef = GetLinkedRef(WRackActivator)
If myActivatorRef == None
    Trace(Self + "OnTriggerLeave() ERROR: missing WRackActivator; set 'ActivatorMissing' state.")
    return
EndIf

Once we find the racks with None, we can fix the rack itself (as some needed). However, others aren't fixable (reversed backplates), so we need something to suppress the message:

If myActivatorRef == Game.GetPlayer()
;~    Trace(Self + "OnTriggerLeave() CHECK: deactivated == PlayerRef; set 'ActivatorMissing' state.")
    myActivatorRef = NONE
    return
EndIf

Yes, I've got a debugging message there, but it's turned off.
 
But there's another case, where the keyword link is there, but the other part is missing its script instead:

WeaponRackActivateScript myActivatorScript = myActivatorRef As WeaponRackActivateScript
If myActivatorScript == None
    Trace(Self + "OnTriggerLeave() ERROR: missing WeaponRackActivateScript; set 'ActivatorMissing' state.")
    myActivatorRef = NONE
    return
EndIf

That has to be fixed. Therefore, we have to leave "ERROR" traces on to find them.
 
There is similar code for Activators. The PlayerRef is perfect for this because the player is already persistent, and because the New linkref dialog box automatically provides it as default.

 

UPDATE: I've reattached the source-only with a separate esp showing some examples: Honeyside, Warmaiden's, Riverwood trader, so far.

 

UPDATE AGAIN: Source is now in beta, so removed.

Link to comment
Share on other sites

    EVENT OnCellAttach()

        If GetLinkedRef(WRackTrigger) == None
            DisableNoWait()
            GotoState("Inactive")
            Trace(Self + "EmptyRack: OnCellAttach() ERROR: missing WRackTrigger. State now 'Inactive'.")
        EndIf

    endEVENT

This check is generating errors (legit ones) when triggers (the visible part) erroneously have WeaponRackActivateSCRIPT on them.

[01/24/2014 - 02:57:37AM] Error:  (00102AFB): cannot disable an object with an enable state parent.
stack:
    [ (00102AFB)].weaponrackactivatescript.DisableNoWait() - "<native>" Line ?
    [ (00102AFB)].weaponrackactivatescript.OnCellAttach() - "WeaponRackActivateScript.psc" Line 358
[01/24/2014 - 02:57:37AM] [weaponrackactivatescript < (00102AFB)>]EmptyRack: OnCellAttach() ERROR: missing WRackTrigger. State now 'Inactive'.

Needless to say that's highly confusing, but it SEEMS to go away if you leave the cell and come back later. I realize it's attempting to disable what it thinks is an invisible activator but there's enough of these floating around that might NOT have enable parents that could end up vanishing because of this.

 

Also, this is definitely an edit the USKP did, to remove all these bogus triggers with the activator script on them, but it's also clearly not removing the scripts retroactively.

Do you want to try adding the WRackTrigger PlayerRef to these racks?

 

As you note, for enable parented racks, you just get an error once, and then they are silent ever after.

 

But for normal racks, they will disappear? So I think we really want to add my flag.

 

There's an additional problem where you've deleted the script, but it runs anyway. I see that some you simply removed (in TES5Edit?) while others the CK reports as deleted. That seems to be unknown flag 3.

 

In any case, the properties are lost, WRackTrigger becomes NONE, so you have to add NONE PlayerRef instead (or in addition).

 

How do we find all the racks with the Activator script on them?

Link to comment
Share on other sites

How do we find all the racks with the Activator script on them?

 

Zilav provided a script to do this here but you need the SVN version of tes5edit - link in the 1st post of this thread - not the version from the Nexus.

Link to comment
Share on other sites

Zilav provided a script to do this here but you need the SVN version of tes5edit - link in the 1st post of this thread - not the version from the Nexus.

Thanks Screwball! I'm on it.

 

And thanks Zilav.

 

That script is a marvel. I've found a bunch that USKP hadn't yet touched.

 

Attaching fixes for spurious activators. I'll make separates for DG (none), HF (none), and DB (none).

 

The back plates will be harder, as the front plates are legitimate and the names of the back plates are the same. Need to modify the script to check for linked ref, too.

 

[redoing attachment]

Link to comment
Share on other sites

Arthmoor questions:

 

In some places where there are spurious activate scripts (on visible plates), you removed them. In others you left them. Should I remove all of them?

 

In some places where there are spurious trigger scripts (on backing plates), you removed them. In others you left them. Should I remove all of them?

Link to comment
Share on other sites

Find them all and nuke em. The only reason that hadn't been done is because nobody had found them all yet.

Link to comment
Share on other sites

Find them all and nuke em. The only reason that hadn't been done is because nobody had found them all yet.

Working on it. Found a good rack with no activator on a ship. Should I add the activator? It's not a player room, but the Icerunner is "safe storage".

Link to comment
Share on other sites

Yeah, if there are visible racks with no activators those should be made usable (or at least decorated) since that's expected.

Link to comment
Share on other sites

Yeah, if there are visible racks with no activators those should be made usable (or at least decorated) since that's expected.

OK. Finished regular plaques. I made the 1 plaque in Icerunner and 1 plaque in Commander Caius' have a matching activator. Didn't know what you wanted me to use to decorate. But the 4 in Jorrvaskr already had static swords displayed on top of them, so told their scripts to shut up (but not deleted, left them available for the future just in case).

Also finished W R Plaque Player House. Left W R Mids for last, because there are 32 mismatched.

UPDATE: Here's the final source. And the updated racks.

In several cases, I didn't add activators, such as racks in stores, using the silencer instead. However, they are easy to upgrade.

I didn't touch Helgen, afraid of a conflict with Helgen Reborn. Needs study.

Also Angi's Camp has 3 racks where the scripts were deleted in Skyrim.esm, so nothing I could do with them. Makes no sense, as there's a bow just begging to be placed, and storage there is safe.

WeaponRack 4-8.7z

Link to comment
Share on other sites

In the previous post, I've done all I could figure out for the main Skyrim game. And didn't find any issues with DawnGuard.

 

But DragonBorn has a player house, and half the racks there are duplicates -- the originals have their activators, the duplicates are missing their activators. Since this is deliberate, I'm sure that something can be worked out. But I'm not willing to delay 2.0.1 for that long. It does mean the ERROR listings will occur every time you enter.

 

And Hearthfires is simply incomprehensible. It's going to take a lot of experimentation to get it right.

 

Just go ahead on release.

Link to comment
Share on other sites

I see that after all the hours I put in tracking down the bad racks, version 4-8 didn't make it into the 2.0.1 release.

Link to comment
Share on other sites

"Just go ahead on release."

 

Well, we did - as I recall that download you're referring to wasn't there when I last looked in here. So it'll have to wait until next time now. Or get slipped in with a hotfix in the event something didn't go as planned elsewhere.

Link to comment
Share on other sites

It was there. That's what I get for Updating messages instead of doing new ones. I'd assumed you were 1 of the then 2 downloads (3 ATM). It doesn't tell me who.

 

The next message was after I gave up on trying to figure out DragonBorn and HearthFire in time for release. I'd started making 2 additional separate files for them. "Just go ahead" meant don't wait for them (as they were the topic of the message).

 

The main thing is the warning messages that are now not suppressed. I'd fixed a state interaction bug, and tweaked a couple of other things for speed, too. I'll keep my fingers crossed for needing a fast bug release....

Link to comment
Share on other sites

Heh, with the way things have gone the last few times, something is sure to come up. Hoping not, but there always seems to be something that gets by no matter how long shit's in testing.

 

That 3rd download was me after your previous post, and yeah, merely editing a post doesn't update it to flag as new again.

Link to comment
Share on other sites

I'll keep my fingers crossed for needing a fast bug release....

Yeah, I've re-checked, and 4.7 wasn't sufficiently release quality.

There's a problem with state interlocking whenever OnCellAttach() is called for the activator after the trigger. It only happened to me once during testing, but I've fixed it. I'm sure it will happen a lot more in the field. The key was to ensure that code happening in parallel always gives exactly the same outcome. I'd added a quick test at the top, just in case there's enough time passing for the OnUpdateHandled to be set -- but it wasn't enough by itself.

There's a problem that the scripts can be (are in fact) deleted, but still somehow call OnCellAttach() -- so they have no properties! So I had to test for properties existing before anything else.

And I'd boosted the wait for 3D from 5 to 8 seconds. I'd mentioned this on several threads. It's just not long enough.

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...