Overhauling the weapon rack scripts

[DayDreamer]

After a reset, "StartingItemHasBeenGrabbed" must be false again. That's because the dummies (Beth has been using mostly dummies in exteriors) will draw an entirely new item from the leveled list when the cell resets. Even the link is renewed! The engine will set it to the new item.

That's what I thought, but you didn't have it in your 3.4 code. I'll add it to my 4.3.

 

 

The HasNode() isn't the problem, ... That in turn means LeavingItem.HasKeyword() will throw script errors and evaluate like False, ....

Yes I understood that. So I built a test to use the false to (&&) prevent the LeavingItem.HasKeyword() from being evaluated.

Again, we need a test case or two. As I said earlier, I'm not able to understand the need. The test seems superfluous to me. But Sclero insists, so let's do it. I marked it with a "NOTE" and as "(rare)". EDIT2: here's the code:

    ; NOTE: checks for the capacity to mount a shield here, to recover
    ; inexplicably invalid or mismatched PlayersDroppedWeapon (rare).

    If  (triggerRef == PlayersDroppedWeapon) || (PlacedItemInit && (PlayersDroppedWeapon == None)) || (iTOC == 0) || hasShieldNode && (triggerRef.GetBaseObject() as Armor) && triggerRef.HasKeyword (ArmorShield)
        ; When an item is grabbed from the rack, StartingItemHasBeenGrabbed must be true,
        ; no matter whether or not the grabbed item was the starting item.
        StartingItemHasBeenGrabbed = True
        PlayersDroppedWeapon = None
        PlacedItemInit = True
        EnableNoWait()

        Trace (Self + "RackHasBeenTriggered() StartingItemHasBeenGrabbed = True; TOC = " + iTOC)
        Return True
    EndIf

 

Therefore, I would like to postpone the discussion until later this day, or tomorrow.

OK. I'm testing my 4.3 anyway. I'll post it (EDIT here), and Taleden can tell me where I've made any stupid errors.

WeaponRack-4-3d.7z

[Sclerocephalus]

That's what I thought, but you didn't have it in your 3.4 code. I'll add it to my 4.3.

 

Sure I do.

 

On cell reset, all properties of scripts running on references in that cell are cleared or reset to their defaults, if they had one specified. StartingItemHasBeenGrabbed has its default value set as "False".

[DayDreamer]

Sure I do.

 

On cell reset, all properties of scripts running on references in that cell are cleared or reset to their defaults, if they had one specified. StartingItemHasBeenGrabbed has its default value set as "False".

I've never seen this specified. Where?

 

So I've been wasting my time resetting defaults on reset. As did the developer of WeaponRackTriggerSCRIPT:

 

EVENT OnReset()
    AlreadyInit = FALSE
    ;Trace("DARYL - " + self + " running OnReset() and AlreadyInit = " + AlreadyInit)
endEVENT

And no wonder scripts are failing all over the place. We often specify defaults for properties that are overridden on specific instances:

Bool Property IgnoreArmor = FALSE Auto

[PrinceShroob]

I didn't even think of dummies. I'll take a look and see where they're positioned and move them in closer if possible. Volkihar has quite a few racks in it.

Hmm... all the Volkihar weapons are dummies, and from what I remember, the ones that were falling off were placed rather far away...

Beta didn't restore the weapons to their racks, BTW.

[taleden]

Yes I understood that. So I built a test to use the false to (&&) prevent the LeavingItem.HasKeyword() from being evaluated.

 

Papyrus doesn't have operator short-circuiting, does it? If you want to avoid calling HasKeyword(), the condition has to be in a separate parent If block, I think, and not just before an "&&".

 

I'm also curious what test you use to decide whether to call HasKeyword. I don't know of a way to detect broken pointers other than to try to call a method on them and checking for a nonsensical result, like GetFormID()==0 or GetBaseObject()==None. But doing so still throws an error in the log, so if you're using that test regularly, we'll have to tell users to just please ignore all those errors because they're expected.

[Avenger665]

Hi all. Im having MASSIVE problems with the weaponrackscript 99% of my log is filled with this:

 

[10/27/2013 - 10:13:17PM] Warning: Assigning None to a non-object variable named "::temp24"
stack:
    [None].WeaponRackActivateScript.PlaceItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.HandleStartingItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.InitActivator() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.OnCellAttach() - "WeaponRackActivateSCRIPT.psc" Line 68
[10/27/2013 - 10:13:17PM] Error: Unable to call Is3DLoaded - no native object bound to the script object, or object is of incorrect type
stack:
    [None].ObjectReference.Is3DLoaded() - "<native>" Line ?
    [None].WeaponRackActivateScript.PlaceItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.HandleStartingItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.InitActivator() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.OnCellAttach() - "WeaponRackActivateSCRIPT.psc" Line 68
[10/27/2013 - 10:13:17PM] Error: Unable to call Is3DLoaded - no native object bound to the script object, or object is of incorrect type
stack:
    [None].SilverSwordScript.Is3DLoaded() - "<native>" Line ?
    [None].WeaponRackActivateScript.PlaceItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.HandlePlayerItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.RunPlayerActivation() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.OnActivate() - "<savegame>" Line ?
[10/27/2013 - 10:13:17PM] Error: Unable to call Is3DLoaded - no native object bound to the script object, or object is of incorrect type
stack:
    [None].ObjectReference.Is3DLoaded() - "<native>" Line ?
    [None].WeaponRackActivateScript.PlaceItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.HandleStartingItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.InitActivator() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.OnCellAttach() - "WeaponRackActivateSCRIPT.psc" Line 68
[10/27/2013 - 10:13:17PM] Warning: Assigning None to a non-object variable named "::temp24"
stack:
    [None].WeaponRackActivateScript.PlaceItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.HandleStartingItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.InitActivator() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.OnCellAttach() - "WeaponRackActivateSCRIPT.psc" Line 68
[10/27/2013 - 10:13:17PM] Warning: Assigning None to a non-object variable named "::temp24"
stack:
    [None].WeaponRackActivateScript.PlaceItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.HandleStartingItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.InitActivator() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.OnCellAttach() - "WeaponRackActivateSCRIPT.psc" Line 68
[10/27/2013 - 10:13:17PM] Warning: Assigning None to a non-object variable named "::temp24"
stack:
    [None].WeaponRackActivateScript.PlaceItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.HandleStartingItem() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.InitActivator() - "<savegame>" Line ?
    [None].WeaponRackActivateScript.OnCellAttach() - "WeaponRackActivateSCRIPT.psc" Line 68

 

 ...

 

already tried to use the download that at start of this thread but it doesnt help me

Is there anything i can do?

[DayDreamer]

Papyrus doesn't have operator short-circuiting, does it? If you want to avoid calling HasKeyword(), the condition has to be in a separate parent If block, I think, and not just before an "&&".

http://www.creationkit.com/Operator_Reference

The OR operator (||) will be true if one of the expressions to its left and right are true, and will short-circuit if the left expression is true (it will not evaluate the right expression at all).

The AND operator (&&) will be true if both of the expressions to its left and right are true, and will short-circuit if the left expression is false (it will not evaluate the right expression at all).

I'm also curious what test you use to decide whether to call HasKeyword. I don't know of a way to detect broken pointers other than to try to call a method on them and checking for a nonsensical result, like GetFormID()==0 or GetBaseObject()==None. But doing so still throws an error in the log, so if you're using that test regularly, we'll have to tell users to just please ignore all those errors because they're expected.

I posted that code in the earlier message as an edit, here it is again. Do you see something wrong?

|| hasShieldNode && (triggerRef.GetBaseObject() as Armor) && triggerRef.HasKeyword (ArmorShield)

[DayDreamer]

already tried to use the download that at start of this thread but it doesnt help me

Is there anything i can do?

Try the download a few messages back:

http://www.afkmods.com/index.php?/topic/3669-overhauling-the-weapon-rack-scripts/page-23#entry148065

Copy the .esp to your Data folder, the .pex to the scripts folder and the .psc to the scripts/source folder. Restart Skyrim, and check the new .esp in the Data tab.

Let us know how the logs look now.

[Sclerocephalus]

I've never seen this specified. Where?

 

http://www.creationkit.com/Cell_Reset

 

There are other places on the Wiki where this is mentioned in the text, but as you know, the search function there is just plain horrible ... When I manage to find it, I'll post the links.

[Sclerocephalus]

already tried to use the download that at start of this thread but it doesnt help me

Is there anything i can do?

 

Since ALL lines in your lolg are starting with a [None], there may be something else wrong with your game.

Can you provide a full log ?

[Sclerocephalus]

Hmm... all the Volkihar weapons are dummies, and from what I remember, the ones that were falling off were placed rather far away...

Beta didn't restore the weapons to their racks, BTW.

 

Quoting one of the thugs from the Vilja mod: "Please ... please ... please" .. err.. I need to see a log!

 

EDIT:

Do I get this right ? They fell of earlier (I assume with an earlier beta version), then you played on ... and now they are not getting restored ?

This would be entirely normal, because the racks believe that they have been grabbed since the first incident happened.

 

If you feel that you still need your save (although you're running a beta),  I'll post a small script for you later to restore them (@DayDreamer: That's what "(PlacedItemInit && (MountedItem == None))" is for ... I hook up my rescue script there, so to say ...)

[Avenger665]

With new esp and scripts running:

 

[10/27/2013 - 11:38:31PM] Error: Unable to call Is3DLoaded - no native object bound to the script object, or object is of incorrect type
stack:
    [None].ObjectReference.Is3DLoaded() - "<native>" Line ?
    [None].weaponrackactivatescript.PlaceItem() - "<savegame>" Line ?
    [None].weaponrackactivatescript.HandleStartingItem() - "<savegame>" Line ?
    [None].weaponrackactivatescript.InitActivator() - "<savegame>" Line ?
    [None].weaponrackactivatescript.OnCellAttach() - "<savegame>" Line ?
[10/27/2013 - 11:38:31PM] Warning: Assigning None to a non-object variable named "::temp24"
stack:
    [None].weaponrackactivatescript.PlaceItem() - "<savegame>" Line ?
    [None].weaponrackactivatescript.HandleStartingItem() - "<savegame>" Line ?
    [None].weaponrackactivatescript.InitActivator() - "<savegame>" Line ?
    [None].weaponrackactivatescript.OnCellAttach() - "<savegame>" Line ?

 

IDK if it is cuz of this script spam but i have tons of game freeze and CTD's since i have this bug...
 

[DayDreamer]

With new esp and scripts running:

 

IDK if it is cuz of this script spam but i have tons of game freeze and CTD's since i have this bug...

 

Hi, It seems very odd that you are still getting the names of old script functions and not the line numbers in the current scripts I gave you.

 

But you have an infinite loop, so it must not be loading the new script. Sorry, nothing I can do.

 

What version USKP are/were you running?

 

My guess is you'll have to go back to a save from before those started showing up in your log.

[DayDreamer]

http://www.creationkit.com/Cell_Reset

I'm already familiar with that page. Especially where it says:

Scripts reset to their initial state, clear all of their variables, and re-initialize.

Since variables are different than properties....

That's one reason I have a different section for variables, instead of sorting everything by alphabetizing by type.

 

There are other places on the Wiki where this is mentioned in the text, but as you know, the search function there is just plain horrible ... When I manage to find it, I'll post the links.

Well, that would be great!

But it's probably more important that you tell us where to test the shield issue:

&& triggerRef.HasKeyword (ArmorShield)

Since that's going to be an issue with Taleden's code.

[taleden]

With new esp and scripts running:

 

[10/27/2013 - 11:38:31PM] Error: Unable to call Is3DLoaded - no native object bound to the script object, or object is of incorrect type

stack:

    [None].ObjectReference.Is3DLoaded() - "<native>" Line ?

    [None].weaponrackactivatescript.PlaceItem() - "<savegame>" Line ?

    [None].weaponrackactivatescript.HandleStartingItem() - "<savegame>" Line ?

    [None].weaponrackactivatescript.InitActivator() - "<savegame>" Line ?

    [None].weaponrackactivatescript.OnCellAttach() - "<savegame>" Line ?

[10/27/2013 - 11:38:31PM] Warning: Assigning None to a non-object variable named "::temp24"

stack:

    [None].weaponrackactivatescript.PlaceItem() - "<savegame>" Line ?

    [None].weaponrackactivatescript.HandleStartingItem() - "<savegame>" Line ?

    [None].weaponrackactivatescript.InitActivator() - "<savegame>" Line ?

    [None].weaponrackactivatescript.OnCellAttach() - "<savegame>" Line ?

 

IDK if it is cuz of this script spam but i have tons of game freeze and CTD's since i have this bug...

 

 

I had a similar problem and unfortunately I think there is probably no way to stop this in your current save, unless you have an earlier save from before it started happening. Older versions of the weapon rack scripts contained a loop which checks Is3DLoaded() but has absolutely no fail-safe, so in the event that a rack tries to process an item that no longer exists (such as a pre-placed item that you picked up and sold to a merchant and their chest reset), that loop will go on forever spewing that error. Because the function is still running in your save, you cannot update the script underneath it, because the game will restore the copy baked into your save.

 

In theory it should be possible to temporarily modify the ObjectReference base script to break you out of this loop, but in practice that script cannot be overridden (at least I have never gotten a modified copy to take effect on game reload).

[taleden]

|| hasShieldNode && (triggerRef.GetBaseObject() as Armor) && triggerRef.HasKeyword (ArmorShield)

So Papyrus does have operator short-circuiting; I stand corrected.

 

That logic will reduce the problem somewhat because it will only happen for racks with shield nodes, but I think you will still get errors if a scripted item is grabbed from a CoA rack. Since (as far as I know) the weapons on CoA racks pretty much always cross-activate the shield trigger in the middle, that shield trigger will notice the scripted item leaving and run this code. Since hasShieldNode would be true for the shield trigger, the clause will next attempt to call triggerRef.GetBaseObject(), but if the item picked up was scripted then triggerRef is probably broken, so that call will throw an error and evaluate as None. But at least you only get the one error, because "(None as Armor) &&" will prevent HasKeyword() from failing the same way.

[taleden]

Since variables are different than properties....

 

Was that meant to be facetious? I always thought properties really were pretty much just variables under the hood, except with some implicit (or explicit) get/set functions that are accessible from outside and in turn get/set the corresponding local variable.

[Sclerocephalus]

|| hasShieldNode && (triggerRef.GetBaseObject() as Armor) && triggerRef.HasKeyword (ArmorShield)

So Papyrus does have operator short-circuiting; I stand corrected.

 

That logic will reduce the problem somewhat because it will only happen for racks with shield nodes, but I think you will still get errors if a scripted item is grabbed from a CoA rack. Since (as far as I know) the weapons on CoA racks pretty much always cross-activate the shield trigger in the middle, that shield trigger will notice the scripted item leaving and run this code. Since hasShieldNode would be true for the shield trigger, the clause will next attempt to call triggerRef.GetBaseObject(), but if the item picked up was scripted then triggerRef is probably broken, so that call will throw an error and evaluate as None. But at least you only get the one error, because "(None as Armor) &&" will prevent HasKeyword() from failing the same way.

 

 

 

Sorry, I was - and am still somewhat - busy with my mesh fixes.

 

You don't have to check the object reference for the keyword; you can as well check the base object. HasKeyword() is a member function of the Form script!

[DayDreamer]

|| hasShieldNode && (triggerRef.GetBaseObject() as Armor) && triggerRef.HasKeyword (ArmorShield)

So Papyrus does have operator short-circuiting; I stand corrected.

 

That logic will reduce the problem somewhat because it will only happen for racks with shield nodes, but I think you will still get errors if a scripted item is grabbed from a CoA rack. Since (as far as I know) the weapons on CoA racks pretty much always cross-activate the shield trigger in the middle, that shield trigger will notice the scripted item leaving and run this code. Since hasShieldNode would be true for the shield trigger, the clause will next attempt to call triggerRef.GetBaseObject(), but if the item picked up was scripted then triggerRef is probably broken, so that call will throw an error and evaluate as None. But at least you only get the one error, because "(None as Armor) &&" will prevent HasKeyword() from failing the same way.

 

and remember, this is at the end of a very long set of earlier tests:

(triggerRef == PlayersDroppedWeapon) || (PlacedItemInit && (PlayersDroppedWeapon == None)) || (iTOC == 0) ||

that 1st clause will be most likely, because in almost all cases the thing will be recorded. So far so good. The 4 lines after reset all those flags to a consistently empty state.

 

the 2nd clause seems somewhat likely, as PlacedItemInit certifies that PlayersDroppedWeapon is good, yet you've removed something that's certified as not being there. So you must be removing something adjacent, but the enable state was wrong. The 4 lines after reset all those flags to match.

 

the 3rd clause is possible that you've removed something adjacent that's blocking -- sorta a backup to the 2nd clause.

 

and then the inexplicable 4th clause for shields.

 

Was that meant to be facetious? I always thought properties really were pretty much just variables under the hood, except with some implicit (or explicit) get/set functions that are accessible from outside and in turn get/set the corresponding local variable.

Actually, it is my understanding that the VMAD underneath records properties differently than variables. So they don't reset to "default", which would be very bad for stored properties. All the racks would be type 1 after a reset.

 

And there are 90 OnReset (quick grep) that would belie the claim that properties don't need to be reset by hand. But then, maybe they were designed for older versions of the machine. Although 17 are Dawnguard and 11 are Dragonborn, so not that old of a machine.

 

Now, it's entirely possible that Sclero has discovered something that none of us knew. He did find loguser, after all....

[DayDreamer]

You don't have to check the object reference for the keyword; you can as well check the base object. HasKeyword() is a member function of the Form script!

As already noted, trying to get the base object can blow up -- which I'm using as a test for None. We don't know the base object here:

(triggerRef == PlayersDroppedWeapon) || (PlacedItemInit && (PlayersDroppedWeapon == None)) || (iTOC == 0) ||
(hasShieldNode && (triggerRef.GetBaseObject() as Armor) && triggerRef.HasKeyword (ArmorShield))

EDIT: Why isn't the TOC test first? That would be a simpler and surer way to detect nothing there.

[taleden]

(triggerRef == PlayersDroppedWeapon) || (PlacedItemInit && (PlayersDroppedWeapon == None)) || (iTOC == 0) ||

that 1st clause will be most likely, because in almost all cases the thing will be recorded. So far so good. The 4 lines after reset all those flags to a consistently empty state.

 

the 2nd clause seems somewhat likely, as PlacedItemInit certifies that PlayersDroppedWeapon is good, yet you've removed something that's certified as not being there. So you must be removing something adjacent, but the enable state was wrong. The 4 lines after reset all those flags to match.

 

the 3rd clause is possible that you've removed something adjacent that's blocking -- sorta a backup to the 2nd clause.

 

and then the inexplicable 4th clause for shields.

 

Yeah, the problem with the 4th clause is really just the shield component of CoA racks, because that trigger will always be cross-fired by the two weapons on the sides. So any time a CoA rack has a shield on it, and a scripted weapon is retrieved from the same rack, I think the current test will throw a script error unless the 4th clause is disabled:

• (triggerRef == PlayersDroppedWeapon) is false, because triggerRef is one of the two crossed weapons while PlayersDroppedWeapon is the placed shield
• PlacedItemInit should be true by the time a scripted item could be on the rack at all, but PlayersDroppedWeapon will not be None if a shield is on the rack
• iTOC will also not be 0 if a shield is on the rack (or the other weapon is still in place)

That said, once the player starts working with a rack after installing the new scripts, PlacedItemInit should be True which means the first clause is really the only one needed in order for a trigger to know when to re-enable its activator. I was therefore assuming that the only purpose of the other clauses is to get racks into that fully-initialized state sooner, and for that purpose the 4th clause is handy in order to get the shield trigger initialized as soon as the player grabs a pre-placed shield, without having to empty the whole rack.

[Sclerocephalus]

I was therefore assuming that the only purpose of the other clauses is to get racks into that fully-initialized state sooner, and for that purpose the 4th clause is handy in order to get the shield trigger initialized as soon as the player grabs a pre-placed shield, without having to empty the whole rack.

 

Exactly.

 

That's what I try to tell DayDreamer for days now.

 

After all this time, we still have many new users, who never used UxxP before and install the patches on a running vanilla game.

 

Take the checks out and guess what happens. Or better, go to the Nexus and browse through the pages of endless complaints from users who are upset because we told them that we did fix a ton of bugs (what we did), but after installation of the patch, no rack is working. And they are right!

[DayDreamer]

Yeah, the problem with the 4th clause is really just the shield component of CoA racks, because that trigger will always be cross-fired by the two weapons on the sides. So any time a CoA rack has a shield on it, and a scripted weapon is retrieved from the same rack, I think the current test will throw a script error unless the 4th clause is disabled:

I believe we are in vehement agreement.

I was therefore assuming that the only purpose of the other clauses is to get racks into that fully-initialized state sooner, and for that purpose the 4th clause is handy in order to get the shield trigger initialized as soon as the player grabs a pre-placed shield, without having to empty the whole rack.

Exactly.

That's what I try to tell DayDreamer for days now.

And I understand that impulse. However, not that I understand it better, I do not believe the 4th shield clause is needed.

We are all in agreement it's going to throw a log error in the worst case: player has stored a scripted object into a rack with an existing shield, then loads the new patch, then removes the scripted object first.

That's not so bad, but working through all the possibilities seems to me a "premature optimization" -- there's no scenario where having this test is better than not having it. If they really are taking the shield, then there's no reason for the test (the first test should do it).

Really, we're doing all this work-around because of the OnAttach initialization failures, and I think that Tal's stuff fixes that!

After all this time, we still have many new users, who never used UxxP before and install the patches on a running vanilla game.

Take the checks out and guess what happens.

Nobody is saying take all the tests out. We're saying that we could test TOC sooner (maybe #2 would be best), and throw out #4 -- which is known to be broken in some obscure cases.

And I'm saying I think the OnAttach tests are working pretty well. Admittedly, I've only been able to test normal racks, as I don't have any scripted weapons in any of my test saves.

So I think we just need more eyeballs to test the oddball scripted weapons cases and Tal's new patch!

[taleden]

Exactly.

 

That's what I try to tell DayDreamer for days now.

 

After all this time, we still have many new users, who never used UxxP before and install the patches on a running vanilla game.

 

Take the checks out and guess what happens. Or better, go to the Nexus and browse through the pages of endless complaints from users who are upset because we told them that we did fix a ton of bugs (what we did), but after installation of the patch, no rack is working. And they are right!

 

And yet, even with that shield rack shortcut in place, a user who newly installs USKP with a set of wooden racks full of battleaxes will have the same problem: those activators will not re-enable until they empty the rack so that iTOC==0. So we're not eliminating that issue, only reducing it slightly in the particular special case of picking up a shield off a CoA rack that hasn't been initialized for USKP yet.

 

I wonder if there's another way to get racks properly initialized after installation, without waiting for one or more OnTriggerLeave()s until the trigger is convinced that the rack really is unoccupied. For example, in OnLoad/Attach/whatever, if PlacedItemInit==False, could we put the trigger into a state where it monitors OnTrigger() for a little while to see what references are inside its volume, and then decide (based on distance maybe?) which of those (if any) is most likely to be the item mounted to this trigger, and then initialize with that reference?

[taleden]

And I'm saying I think the OnAttach tests are working pretty well. Admittedly, I've only been able to test normal racks, as I don't have any scripted weapons in any of my test saves.

 

The items I've been using for testing are commented-out at the top of my reference alias script. For convenience:

	Actor player = Game.GetPlayer()
	player.AddItem(Game.GetForm(0x09fd50)) ; Red Eagle's Fury
	player.AddItem(Game.GetForm(0x10c6fb), 5); Silver Greatsword
	player.AddItem(Game.GetForm(0x10aa19), 5); Silver Sword
	player.AddItem(Game.GetForm(0x0956b5)) ; Wuuthrad
	player.AddItem(Game.GetForm(0x08adfd) As ObjectReference) ; Ceremonial Axe (Volunruud01)
	player.AddItem(Game.GetForm(0x04a39d) As ObjectReference) ; Ebony Blade (WhiterunDragonsreach)
	              (Game.GetForm(0x094a2c) As ObjectReference).Enable()
	player.AddItem(Game.GetForm(0x094a2c) As ObjectReference) ; Ghostblade (Ansilvund02)
	              (Game.GetForm(0x10e94c) As ObjectReference).Enable()
	player.AddItem(Game.GetForm(0x10e94c) As ObjectReference) ; Keening (WinterholdCollegeHallofCountenance)
	              (Game.GetForm(0x02e526) As ObjectReference).Enable()
	player.AddItem(Game.GetForm(0x02e526) As ObjectReference) ; Volendrung (LargasburExterior04)