Overhauling the weapon rack scripts

[DayDreamer]

Hey guys:

For some reason these staffs [screenshot] appear upside down on the weapon racks in Vindrel Hall (in Markarth). One is a "Forsworn Staff" and the other is "Hevnoraak's Staff". I'm not sure if this is intentional or not.

What version? I thought that was fixed in Sclero's latest nif (after 2.0.0a) used in my Weapon Racks 4.6. But I could be wrong, as I've no deep understanding of the nif nodes....

[BlackPete]

What version? I thought that was fixed in Sclero's latest nif (after 2.0.0a) used in my Weapon Racks 4.6. But I could be wrong, as I've no deep understanding of the nif nodes....

I'm using whatever version was included in USKP v. 2.0.0a, so if it's been updated since then I don't think I'm using the 4.6 version.

[DayDreamer]

I'm using whatever version was included in USKP v. 2.0.0a, so if it's been updated since then I don't think I'm using the 4.6 version.

Does http://www.afkmods.com/index.php?/files/file/944-weaponrack/ fix it?

[BlackPete]

Does http://www.afkmods.com/index.php?/files/file/944-weaponrack/ fix it?

Yes, that fixes the upside down staff problem. It also fixes the problem with the weapons not staying on the weapon rack near Alvor's forge in Riverwood.

 

BTW:

I was doing a bit more testing with the version from the link you posted and noticed that the weapon racks in Vlindrel Hall seemingly do not hold maces correctly (screenshot). Here is a comparison (screenshot) with the weapon racks in Breezehome for maces; I'm unsure whether this is correct either and whether they are supposed to be upside down or not.

 

Also, I tried putting the Mace of Molag Bal on the weapon racks in Vlindrel Hall and it does the same thing as the ebony mace in the "first" screenshot, but when removed it makes that particular "slot" unusable (i.e. it can not longer be activated).

 

Edit: I also noticed these notifications in my papyrus log (or errors) when using the 4.6 version:

[01/20/2014 - 02:37:15PM] warning: Variable ::StartingItemHasBeenGrabbed_var on script weaponrackactivatescript loaded from save not found within the actual object. This variable will be skipped.
[01/20/2014 - 02:44:16PM] warning: Variable ::StartingItemHasBeenGrabbed_var on script weaponrackactivatescript loaded from save not found within the actual object. This variable will be skipped.
[01/20/2014 - 02:44:28PM] [WeaponRackTriggerSCRIPT < (0010EA45)>]OnCellAttach() ERROR: missing WRackActivator; set 'ActivatorBusy' state.
[01/20/2014 - 02:44:28PM] [WeaponRackTriggerSCRIPT < (0010EA45)>]OnLoad() ERROR: missing WRackActivator; set 'ActivatorBusy' state.
[01/20/2014 - 02:46:29PM] warning: Variable ::StartingItemHasBeenGrabbed_var on script weaponrackactivatescript loaded from save not found within the actual object. This variable will be skipped.
[01/20/2014 - 02:46:41PM] [WeaponRackTriggerSCRIPT < (0010EA45)>]OnCellAttach() ERROR: missing WRackActivator; set 'ActivatorBusy' state.
[01/20/2014 - 02:46:41PM] [WeaponRackTriggerSCRIPT < (0010EA45)>]OnLoad() ERROR: missing WRackActivator; set 'ActivatorBusy' state.

I am not experienced enough with papyrus to understand what they mean for sure though.

[DayDreamer]

Yes, that fixes the upside down staff problem. It also fixes the problem with the weapons not staying on the weapon rack near Alvor's forge in Riverwood.

Good, that's what I was testing.

 

BTW:

I was doing a bit more testing with the version from the link you posted and noticed that the weapon racks in Vlindrel Hall seemingly do not hold maces correctly (screenshot). Here is a comparison (screenshot) with the weapon racks in Breezehome for maces; I'm unsure whether this is correct either and whether they are supposed to be upside down or not.

Sclerocephalus tried to make the maces right side up in newest nif. I'd say he made them too high.

Upside down (vanilla) looks odd too. I remember spending a long time staring at one in the Helgen torture chamber, trying to figure out how it was hooked there. Of course, had no idea in those days about turning havok off.

 

Also, I tried putting the Mace of Molag Bal on the weapon racks in Vlindrel Hall and it does the same thing as the ebony mace in the "first" screenshot, but when removed it makes that particular "slot" unusable (i.e. it can not longer be activated).

This requires investigation!

 

Edit: I also noticed these notifications in my papyrus log (or errors) when using the 4.6 version:

[01/20/2014 - 02:37:15PM] warning: Variable ::StartingItemHasBeenGrabbed_var on script weaponrackactivatescript loaded from save not found within the actual object. This variable will be skipped.
[01/20/2014 - 02:44:16PM] warning: Variable ::StartingItemHasBeenGrabbed_var on script weaponrackactivatescript loaded from save not found within the actual object. This variable will be skipped.
[01/20/2014 - 02:44:28PM] [WeaponRackTriggerSCRIPT < (0010EA45)>]OnCellAttach() ERROR: missing WRackActivator; set 'ActivatorBusy' state.
[01/20/2014 - 02:44:28PM] [WeaponRackTriggerSCRIPT < (0010EA45)>]OnLoad() ERROR: missing WRackActivator; set 'ActivatorBusy' state.
[01/20/2014 - 02:46:29PM] warning: Variable ::StartingItemHasBeenGrabbed_var on script weaponrackactivatescript loaded from save not found within the actual object. This variable will be skipped.
[01/20/2014 - 02:46:41PM] [WeaponRackTriggerSCRIPT < (0010EA45)>]OnCellAttach() ERROR: missing WRackActivator; set 'ActivatorBusy' state.
[01/20/2014 - 02:46:41PM] [WeaponRackTriggerSCRIPT < (0010EA45)>]OnLoad() ERROR: missing WRackActivator; set 'ActivatorBusy' state.

I am not experienced enough with papyrus to understand what they mean for sure though.

 

StartingItemHasBeenGrabbed -- a 2.0.0 addition that doesn't actually do anything; Sclerocephalus agreed it should be removed, but that didn't happen. It's a 1 time thing.

ERROR: missing WRackActivator; set 'ActivatorBusy' state. My error message to help find the bad racks. We agreed earlier in this thread that it should display every time.

[kwc]

Hi all, I found this thread while investigating why something was preventing me from putting Keening in a display case (I guess it was USKP 2.0.0). I tried DayDreamer's WeaponRack 4.6 mod from a few posts up, and that let me put it in the case, but it appeared significantly off-center.

 

What's worse, if I restart the game (quit to desktop in between), it seems to migrate even more to the right:

 

Quicksaving and reloading doesn't seem to do it, nor does leaving the house and re-entering right away, but it gets worse with every restart:

 

Any ideas? Is this a known problem?

[DayDreamer]

Any ideas? Is this a known problem?

Excellent report. There have been mentions of other migrating weapons, but none with such good pictures.

All these special weapons were disallowed in 2.0.0. Since then, Talenden figured out how to make them work.

Allowing daggers in large display cases is also new. My guess is this simply hasn't been sufficiently tested, and the nif nodes are off a little. Does this happen with Keening in dagger display cases?

[kwc]

Allowing daggers in large display cases is also new. My guess is this simply hasn't been sufficiently tested, and the nif nodes are off a little. Does this happen with Keening in dagger display cases?

Actually, that is a dagger display case (one of the four in Vlindrel Hall). I haven't tried it with a bigger display case yet.

[Arthmoor]

My code was based on a reproducible error, tested against the reproducible error, demonstrating that the error was fixed.

If it was so reproducible, why am I unable to do so, despite your apparent claim that it should be 100% reproducible?

 

This is the essence of the post-Bacon scientific process.

Which also includes verifiable experimentation, does it not? Replication is key to the scientific method after all, and I can't replicate your results with the current iteration of the scripts.

 

ANYWAY.

Since the 3 files you attached have a different quest and only one script to attach to that, is it safe to assume that what's in the USKP now would need to be removed before this could be brought in?

[DayDreamer]

If it was so reproducible, why am I unable to do so, despite your apparent claim that it should be 100% reproducible?

 

Which also includes verifiable experimentation, does it not? Replication is key to the scientific method after all, and I can't replicate your results with the current iteration of the scripts.

 

ANYWAY.

Since the 3 files you attached have a different quest and only one script to attach to that, is it safe to assume that what's in the USKP now would need to be removed before this could be brought in?

It was reproduced by dozens of others. No known reason why you cannot reproduce in your environment. In my case, easily reproduced on both my i5 PC and my i7 MacBookPro.

 

It's designed to work with the old quest in, figuring it didn't hurt. It would just remain unused. BTW, that's Talenden's quest script (a combined version with some of his older debugging lines), not my usual coding style. It seems to work for me, so I left it verbatim! Presumably you'll rename the new quest and its script to match USKP conventions.

[Arthmoor]

I think the major point I was trying to convey is that my results were also affirmed by dozens of users. This wasn't simply a case of me and me alone protesting.

 

Yeah. I figured it out. Rather than leave a junk quest behind  I've defuncted the unused scripts and taken the old quest and the two formlists out that these scripts aren't using.

 

I also silenced a few of the debug messages that were producing annoying spam for vanilla rack pieces that aren't technically set up right. I already tried removing the scripts entirely from the bogus ones being used as backplates and such but the game will not disconnect those scripts retroactively and the amount of log spam from it would be rather annoying for routine play. Other ones that appear to represent genuine setup errors I've left intact and so far the game hasn't complained anywhere I've gone that I can think of that has racks.

[DayDreamer]

Yeah, I'd thought we talked about replacing the backplates with new objects (unscripted versions) instead. And left the ERROR lines in so we could find them all.

 

I'd also tried adding a new variable "backplate" that stops it from trying to connect to the non-existent activator. But it wouldn't initialize on old backplates.

[Arthmoor]

    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.

 

And now the stumper:

[01/24/2014 - 02:30:12AM] Error: Cannot call GetTriggerObjectCount() on a None object, aborting function call
stack:
    [ (000B6F6A)].weaponrackactivatescript.ActivatorSetup() - "WeaponRackActivateScript.psc" Line 296
    [ (000B6F69)].WeaponRackTriggerSCRIPT.ActivatorCheck() - "WeaponRackTriggerScript.psc" Line 190
    [ (000B6F69)].WeaponRackTriggerSCRIPT.OnLoad() - "WeaponRackTriggerScript.psc" Line 66

How is that possible when the Triggermarker property was properly sanitized before getting this far?

 

This happened at the racks outside Alvor's place in Riverwood.

[tyrel68]

How is that possible when the Triggermarker property was properly sanitized before getting this far?

 

This happened at the racks outside Alvor's place in Riverwood.

 

Just FYI i did notice the racks outside alvors tossing the steel mace to the ground fairly soon after entering riverwood

[DayDreamer]

    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.

Correct. Usually those backing plates I mentioned earlier. But in some cases, visible racks have no invisible part, and invisible parts aren't properly linked to their visible part. By leaving these ERROR lines, I'm expecting we can find and fix all of 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.

I thought getting rid of enable parents would have immediate effect.

I've already mentioned that removing scripts doesn't seem to work. Maybe it works for you after re-loads? But my (by now repeated) suggestion was to replace all those with a NEW OBJECT (probably injected into Update) that has no script on it -- deep 6'ing (-30000) the old objects.

Another possibility is to add a variable flag backplate on those scripts, and set it with the retro-script, because it doesn't seem to set by just adding it.

 

And now the stumper:

 

[01/24/2014 - 02:30:12AM] Error: Cannot call GetTriggerObjectCount() on a None object, aborting function call
stack:
    [ (000B6F6A)].weaponrackactivatescript.ActivatorSetup() - "WeaponRackActivateScript.psc" Line 296
    [ (000B6F69)].WeaponRackTriggerSCRIPT.ActivatorCheck() - "WeaponRackTriggerScript.psc" Line 190
    [ (000B6F69)].WeaponRackTriggerSCRIPT.OnLoad() - "WeaponRackTriggerScript.psc" Line 66

How is that possible when the Triggermarker property was properly sanitized before getting this far?

 

This happened at the racks outside Alvor's place in Riverwood.

 No idea. You have all my sanity checks in place? Including:

    If !parentCell.IsAttached()
        Trace(Self + "OnLoad() ERROR: !IsAttached()")
        return
    EndIf

 

 

Just FYI i did notice the racks outside alvors tossing the steel mace to the ground fairly soon after entering riverwood

thanks for verifying a known problem with 2.0.0.

[Arthmoor]

Correct. Usually those backing plates I mentioned earlier. But in some cases, visible racks have no invisible part, and invisible parts aren't properly linked to their visible part. By leaving these ERROR lines, I'm expecting we can find and fix all of them.

Maybe I didn't explain myself adequately. The problem in the case I'm showing you is that it's a visible part with a properly configured link to its activator, but the vanilla game ALSO attached a script that belongs on one of the INVISIBLE parts. So your check is attempting to disable a completely legitimate piece of clutter. The only reason it failed is because the house's enable marker settings prevented it.

 

I've already mentioned that removing scripts doesn't seem to work. Maybe it works for you after re-loads? But my (by now repeated) suggestion was to replace all those with a NEW OBJECT (probably injected into Update) that has no script on it -- deep 6'ing (-30000) the old objects.

That's not something I'm willing to do though. Dropping the existing object and replacing it with a new one will reek havoc on existing games. I already tried it. The racks get themselves into a pretty confused state, not to mention these are also persistent objects due to property references and in several cases don't disappear. So you end up with z-fighting on top of everything else.

 

No idea. You have all my sanity checks in place? Including:

    If !parentCell.IsAttached()
        Trace(Self + "OnLoad() ERROR: !IsAttached()")
        return
    EndIf

Yes. The code is 100% intact except for some trace statements that were commented out because they were coming up without doing anything out of the ordinary.

[DayDreamer]

Maybe I didn't explain myself adequately. The problem in the case I'm showing you is that it's a visible part with a properly configured link to its activator, but the vanilla game ALSO attached a script that belongs on one of the INVISIBLE parts. So your check is attempting to disable a completely legitimate piece of clutter. The only reason it failed is because the house's enable marker settings prevented it.

Ah, the visible part has two (2) scripts on it? Where? Maybe we need yet another state: "FOOBAR".

That's not something I'm willing to do though. Dropping the existing object and replacing it with a new one will reek havoc on existing games. I already tried it. The racks get themselves into a pretty confused state, not to mention these are also persistent objects due to property references and in several cases don't disappear. So you end up with z-fighting on top of everything else.

OK. If you tried it and it didn't work, I'll try to think of something more. For example, a new inactive invisible part with a new script, which the visible backing plate could link. I'll test something in Honeyside, hopefully later today. (I'm on the road at the moment.)

Yes. The code is 100% intact except for some trace statements that were commented out because they were coming up without doing anything out of the ordinary.

Well, that really is puzzling. Having a None where the code has already tested for None is a serious game engine bug. I'll try to find those references (000B6F6A & 000B6F69) and see whether there's anything special about them.

[DayDreamer]

I already tried it. The racks get themselves into a pretty confused state, not to mention these are also persistent objects due to property references and in several cases don't disappear.

OK, another idea. The missing WRActivator link can be added. AFAIK, unlike properties prior existence/persistence isn't a problem, they always get added by our plugins. The default value for a new link in the CK is (any), PlayerRef (00000014). We add this default value to the backplate racks.

It's easy to test for in a script, we don't even need to bother with a formal PlayerRef property.

[tyrel68]

Any chance Sclero's Extended Weapon rack mod can be patched for the new system?

 

Using it throws thousands of errors now

[NightStar]

Seen this at the Beth forum? It's with the betas. (USKP#39.87)

 

[01/27/2014 - 01:05:07PM] error:  (00100DD9): does not have any 3d and so cannot be moved to.

stack:

[ (00100DDC)].ObjectReference.MoveToNode() - "<native>" Line ?

[ (00100DD8)].weaponrackactivatescript.PlaceItem() - "WeaponRackActivateSCRIPT.psc" Line 587

[ (00100DD8)].weaponrackactivatescript.CheckRackType() - "WeaponRackActivateSCRIPT.psc" Line 454

[ (00100DD8)].weaponrackactivatescript.ActivatorSetup() - "WeaponRackActivateSCRIPT.psc" Line 276

[ (00100DD9)].WeaponRackTriggerSCRIPT.ActivatorCheck() - "WeaponRackTriggerSCRIPT.psc" Line 190

[ (00100DD9)].WeaponRackTriggerSCRIPT.OnCellAttach() - "WeaponRackTriggerSCRIPT.psc" Line 77

[DayDreamer]

Seen this at the Beth forum? It's with the betas. (USKP#39.87)

 

[01/27/2014 - 01:05:07PM] error:  (00100DD9): does not have any 3d and so cannot be moved to.

stack:

[ (00100DDC)].ObjectReference.MoveToNode() - "<native>" Line ?

[ (00100DD8)].weaponrackactivatescript.PlaceItem() - "WeaponRackActivateSCRIPT.psc" Line 587

[ (00100DD8)].weaponrackactivatescript.CheckRackType() - "WeaponRackActivateSCRIPT.psc" Line 454

[ (00100DD8)].weaponrackactivatescript.ActivatorSetup() - "WeaponRackActivateSCRIPT.psc" Line 276

[ (00100DD9)].WeaponRackTriggerSCRIPT.ActivatorCheck() - "WeaponRackTriggerSCRIPT.psc" Line 190

[ (00100DD9)].WeaponRackTriggerSCRIPT.OnCellAttach() - "WeaponRackTriggerSCRIPT.psc" Line 77

Hadn't seen this one before. My guess, and it's only a guess, is that the startup item somehow managed to load 3d before the rack itself. Must be a timing issue with other things in the area. No prior script checked for 3D of the rack itself.

When I get a chance, I'll try to figure out where this is happening.

[Screwball]

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

[Arthmoor]

Oh geez, that's a nice one. Beth placed an activator with no visible rack to go with it.

[DayDreamer]

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

(USKP 2.0.1 Beta)

 

 

Oh geez, that's a nice one. Beth placed an activator with no visible rack to go with it.

My new code to check the faux reference links should handle that case. I'll post that as soon as I get more testing done. But I've been poking at critters instead.

[BlackPete]

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