Overhauling the weapon rack scripts

[DayDreamer]

Having heard nothing over the past 2 days, updated to 4.6. Will release beyond AFK.

 

Vanilla cleared its counterpart pointers before returning on errors, and I'd missed a few error conditions. I don't know whether this actually is needed, but it's semantically cleaner.

 

Also, trivial reordering of the rack type tests allowed removal of a repetitious false test added by vanilla patch 1.4. It should be ever so slightly faster now.

 

Happy Holidays!

[Arthmoor]

Holidays bro, be a little more patient or something

[taleden]

Holidays bro, be a little more patient or something

Indeed, I've been busy with holidays and getting my own mod out for beta testing, so I haven't had a chance to respond to your questions. Istill won't be able to look at the code until tomorrow, but offhand I think what you're seeing is sclero's code from USKP 2.0.0 that I didn't change. At least I don't remember doing anything with bows or reequipping, but its been awhile since I posted my versions.

[taleden]

With our holiday rush over, I'm finally catching up on some threads:

 

I'm not the positioning expert. The handles are at the actual positioning nodes, and look OK.

 

It looks to me like the right side is doing a good job. But the left side would need to somehow flip the sword over. Then it would be good, too. I've got no idea whether it's possible to tell swords/sabres to flip over....

 

Yeah, Sclero would probably have the easiest time answering this, since it might require an edit to the nodes in the .nif file which he's already dug into once.

 

But offhand my guess is that, if you picture the effective axes for the right-hand node, you'd see something like positive-y pointing up and to the right along the wall, positize-x pointing down and to the right, and positive-z pointing out from the wall toward the viewer. Then the left-hand node was probably made by rotating 90' around the effective z axis, so that pos-y ends up pointing up-left, pos-x pointing up-right, and pos-z still pointing out from the wall. In the case of straight swords that looks fine, but for this curved sword (curved! sword!) what you really want instead is to rotate 180' around the viewer's vertical axis, so that the node's pos-y is still up-left, but pos-x is down-left and pos-z is pointing into the wall instead of out from it. I know that's an awfully convoluted description and it's just a guess, but hopefully if Sclero ever returns to this thread he could parse it, or just look at the mesh and fix it.

 

This may be a known issue, but Volendrung seems to shift around on a weapon plaque over time. Does the placement look a bit off to anyone else or is it just me? See this screenshot.

 

I've seen this happen too, and in my experience it's related to things falling off the racks and being put back. Or more generally, it's related to the item bouncing and clattering after being dropped, either from the rack or by the player. It seems that some aspect of the transformations that the physics engine applies during bouncing are not reset when the item is eventually racked again, so the visible mesh ends up offset from its logical centerpoint, which is what's actually being positioned.

 

I've done the same thing.
 
Although I've tried to minimize the number of log entries in my latest, I did leave the ERROR message for bad linkage. It will show up every time you enter the cell. That seemed to be the consensus of the discussion earlier in the month.
 
I have a question for Talenden (and others): in HandlePlayerItem(), for USKPWeaponRackWrongStaffMessage, you add the staff back into the inventory, and try to re-equip it:
 

PlayerRef.AddItem (PlayerItemRef, 1, True)
PlayerRef.EquipItem (PlayerItem)

 
When I already had an sword of the same kind, my tests didn't always seem to equip the added sword. So I removed the EquipItem line, figuring that the player should have control over choosing it.
 

PlayerRef.AddItem(PlayerItemRef, 1, True)
; do not equip item, in case carrying multiple items of same form!

 
But then more testing showed that as I was carrying an equipped iron sword and take the iron sword off the rack in HoneySide, and then put an iron sword back on the rack, and then take it down again, the sword always seems to be the original starting item.
 
My conclusion is that the game substitutes the most recent taken item as equipped. Could somebody else confirm? Because in that case, Talenden's code should work fine!

 

Ah, you're right, I did add an EquipItem() after AddItem() in case the dropped staff fails the node test. I guess my thinking was that, ideally, if an item cannot be racked, then it should not even be removed or unequipped from the player. For the staff test we do have to get it into the world before we can test it, so at the very least, when we put it back we should try to equip it again, so that it's as if it never left the player. But you may be right that in certain cases, the copy of the staff that gets reequipped might not technically be the same one which was originally removed, and that would be awkward.

 

On the other hand, in the case of staves I'm not sure how the player could even tell the difference between two staves with the same base FormID, since they can't be further tempered or enchanted. Maybe it could be a problem for the custom staves in Dragonborn though. If the consensus is to not try to re-requip and just let staff errors result in the player being disarmed, I'm fine with that.

 

 

Another Talenden question:

        ElseIf ItemToPlace.HasKeyword (WeaponTypeBow)
            ItemToPlace.MoveToNode (TriggerMarker, "BowPivot01")

But I have from some version of Sclero's stuff:

elseif PlayersDroppedWeapon.HasKeyword(WeaponTypeBow)
    ; Bow
    PlaceBow()

...
 
Function PlaceBow()

    If PlayersDroppedWeapon.HasNode("CrossbowRoot") && TriggerMarker.HasNode("CrossbowPivot01")
        If PlayersDroppedWeapon.HasNode("DwarvenCrossbow.nif")
            PlayersDroppedWeapon.MoveToNode(TriggerMarker, "CrossbowPivot02")
        Else
            PlayersDroppedWeapon.MoveToNode(TriggerMarker, "CrossbowPivot01")
        EndIf
    Else
        PlayersDroppedWeapon.MoveToNode(TriggerMarker, "BowPivot01")
    EndIf

EndFunction

 

I made my edits based on the officially released USKP 2.0.0 scripts, which do not include PlaceBow(). If that was part of earlier Sclero scripts then I'm not sure why it was removed, you'd have to ask him or Arthmoor. But my edits did not touch anything at all in PlaceItem(), except a comment.

[Arthmoor]

There was no PlaceBow() function in the USKP 2.0.0 release scripts, or in any dev copy I've seen either.

 

Also, as it's getting close to the new year and we'll be gearing back up soon, if you guys could settle on something you want included with the next beta for testing please get that together and let us know.

[taleden]

There was no PlaceBow() function in the USKP 2.0.0 release scripts, or in any dev copy I've seen either.

 

Also, as it's getting close to the new year and we'll be gearing back up soon, if you guys could settle on something you want included with the next beta for testing please get that together and let us know.

 

I just tried to look at DayDreamer's 4.6 but it doesn't diff cleanly against anything else I have (vanilla, USKP 2.0.0, my v4) so it would take me a long time to dig through it by hand and understand how it actually differs from the other options, whether it could introduce any new bugs, and whether it fixes any bugs still present in the others. I might have time for that before the new year but I doubt it, so failing that, I'd have to vote for something based on my v4 (which does diff fairly cleanly against USKP 2.0.0), or if you guys are interested in the positioning workaround to enable-parented activators that I mentioned a few pages back, then I have a v5 which implements that idea. Obviously DayDreamer will recommend his own 4.6 because he understands what it does differently and presumably wouldn't have bothered if he didn't think it had some value added.

 

So I'd really love to get Sclero's take on all of the developments in the last month, since I think he still has more experience with weapon rack scripting than either myself or DayDreamer. He hasn't posted in awhile, but I don't know if he's just taking a break for the holidays or if he's finally burned out from working on this stuff for so long. If you think he's likely to return then I'd suggest waiting for his input, but if you think he's gone for good then I'll try to find time to examine DayDreamer's stuff, or maybe he can write up a guide that explains how and why it differs from the other scripts on basically every line in every file.

[BlackPete]

I would assume you guys have taken care of this by now, but as of USKP 2.0.0a, there are three locations that I know about that often have weapons that fall off of the rack(s). They are Riverwood (outside of Alvor's house), Shor's Watchtower (the Rift), and Whitewatch Tower (Whiterun Hold).

[Arthmoor]

All of those instances should have been fixed with the currently released scripts. They tested out perfectly fine in every run I've made with them.

[taleden]

It sounds like a timing problem -- if you were testing with a mostly clean load order (i.e. no mods besides USKP) and/or your machine is fairly powerful, then maybe those dummy objects were filled in by the engine and got their 3D loaded quickly enough to work. But if BlackPete has lots of other script-heavy mods and/or a slower CPU, then maybe the weapon rack scripts timed out waiting for Is3DLoaded on the pre-placed dummy items.

[BlackPete]

All of those instances should have been fixed with the currently released scripts. They tested out perfectly fine in every run I've made with them.

By currently released scripts, I'd assume you mean the ones that are being worked on for the next USKP 2.0.1. I only use the scripts that were included in USKP v. 2.0.0, which may be why the weapons are still falling off in the three locations I mentioned above.

[taleden]

By currently released scripts, I'd assume you mean the ones that are being worked on for the next USKP 2.0.1. I only use the scripts that were included in USKP v. 2.0.0, which may be why the weapons are still falling off in the three locations I mentioned above.

 

I think he meant 2.0.0, since 2.0.1 is not currently released (to the public anyway). That's why I wondered if it was a timing issue, since that might explain why they looked fixed during testing but you're still having trouble. How many other mods are you using and how beefy is your CPU/GPU?

[BlackPete]

 

I think he meant 2.0.0, since 2.0.1 is not currently released (to the public anyway). That's why I wondered if it was a timing issue, since that might explain why they looked fixed during testing but you're still having trouble. How many other mods are you using and how beefy is your CPU/GPU?

Strangely, prior to installing the 2.0.0 patch, the weapon racks at those three locations (Alvor's Forge, Shor's Watchtower and Whitewatch Tower) were keeping the weapons on them just fine. My PC seems to handle Skyrim really well considering it is an old computer model (Dell XPS 630i). Below are the mods I use and the specifications of my CPU and GPU.

 

Mod List:

Skyrim.esm

Update.esm

Unofficial Skyrim Patch.esp

Dawnguard.esm

Unofficial Dawnguard Patch.esp

HearthFires.esm 

Unofficial Hearthfire Patch.esp 

Dragonborn.esm 

Unofficial Dragonborn Patch.esp 

HighResTexturePack01.esp 

HighResTexturePack02.esp 

HighResTexturePack03.esp 

Unofficial High Resolution Patch.esp 

Cutting Room Floor.esp 

Bring Out Your Dead.esp 

HoldBorderBanners.esp 

Point The Way.esp 

Run For Your Lives.esp 

When Vampires Attack.esp 

Storefront.esp 

Provincial Courier Service.esp 

 

My CPU is an Intel Core 2 Duo E8400 @ 3.00 GHz, 3.01 GHz

My GPU is an Nvidia GeForce GTX 650 (2 GB)

[DayDreamer]

I just tried to look at DayDreamer's 4.6 but it doesn't diff cleanly against anything else I have (vanilla, USKP 2.0.0, my v4) ... Obviously DayDreamer will recommend his own 4.6 because he understands what it does differently and presumably wouldn't have bothered if he didn't think it had some value added.

 

... maybe he can write up a guide that explains how and why it differs from the other scripts on basically every line in every file.

My stuff diffs very cleanly against vanilla 1.9! The events and functions are in the same order, the comments were retained, such as vanilla:

PlayersDroppedWeapon.SetMotionType(Motion_Keyframed, false)
; Tell the weapon to ignore all forms of physic interaction
Trace("DARYL - " + self + " Disabling physics on " + PlayersDroppedWeapon)

TriggerMarker = GetLinkedRef(WRackTrigger)

; Handle the placement of the weapon
if PlayersDroppedWeapon.HasKeyword(WeaponTypeSword)
    ; 1H Sword
    Trace("DARYL - " + self + " Moving " + PlayersEquippedWeaponType + " to the SwordMarker")
    PlayersDroppedWeapon.MoveToNode(TriggerMarker, "SwordPivot01")

versus my

PlayersDroppedWeapon.SetMotionType(Motion_Keyframed, false)
; Tell the weapon to ignore all forms of physic interaction
; (this won't stop OnTriggerLeave events from firing though)

; Handle the placement of the weapon
if PlayersDroppedWeapon.HasKeyword(WeaponTypeSword)
    ; 1H Sword
    PlayersDroppedWeapon.MoveToNode(TriggerMarker, "SwordPivot01")

 

Standard diff even winnows out (leading -) individual lines that were removed, such as:

Trace("DARYL - " + self + " Moving " + PlayersEquippedWeaponType + " to the SwordMarker")

(which never worked, because that field isn't set in vanilla for starting items.)

 

The latter comment is FUD. I even kept the same tabbing levels as vanilla, so that block comments line up, such as:

;---------------------------------------------------
;START------------------Standard Rack
;-----------------------------------------

If you want to compare your v4 against either vanilla or my 4.5, put your events and functions back in the same original order. Sclero had a penchant for renaming everything and re-writing comments.

 

By currently released scripts, I'd assume you mean the ones that are being worked on for the next USKP 2.0.1. I only use the scripts that were included in USKP v. 2.0.0, which may be why the weapons are still falling off in the three locations I mentioned above.

I've not seen 2.0.1 as yet. USKP 2.0.0 very reliably drops Riverwood and other exteriors on the ground. Use my code.

 

In fact, BlackPete has already confirmed weeks ago that my code works on his setup. Not surprising, because we are running similar plugins.

[DayDreamer]

As to explaining line-by-line the improvements of my weapon racks 4.6, they are already commented in the code. Each function has a nice little block header. Each section of code has a short explanation.

 

My code has considerably more error condition checking than either vanilla or USKP 2.0.0. Some of my earlier suggestions made their way into 2.0.0, but inexplicably missing crucial elements. For example,

EVENT OnLoad()

    If Self == None
        Trace(Self + "OnLoad() ERROR!")
        return
    EndIf

    Cell parentCell = GetParentCell()

    If parentCell == None
        Trace(Self + "OnLoad() ERROR: GetParentCell == None")
        return
    EndIf

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

    ActivatorCheck("OnLoad")

endEVENT

Note that all the checks lead up to checking the parent cell is attached. Note that each error is clearly logged.

[DayDreamer]

For some inexplicable reason, USKP stopped using the vanilla AlreadyInit variable. My code uses it to speed the interlock:

; The vanilla AlreadyInit is/was unreliable. Here it is used only to
; speed the first comer past the slower cross-script variable test.
If AlreadyInit
    ; double check; this is less than ideal, as get/set is interruptible.        
    If myActivatorScript.OnUpdateHandled
    ;~    Trace(Self + CallingEvent + "() " + myActivatorRef + " already handled.")
        myActivatorRef = NONE
        return
    EndIf
EndIf
AlreadyInit = True
GoToState("ActivatorBusy")

;myActivatorRef.RegisterForSingleUpdate(0.0)
;~    Trace(Self + CallingEvent + "() " + myActivatorRef + " update setup.")
myActivatorScript.ActivatorSetup()

Note the AlreadyInit test bypasses the cross-script locking. The next call (usually OnLoad) will take the longer path.

 

Note the USKP RegisterForSingleUpdate(0.0) is commented out, and ActivatorSetup() is called directly. This results in a considerable speed increase!

 

This is a simple double semaphore situation. The myActivatorScript.OnUpdateHandled access is locked until the previous myActivatorScript.ActivatorSetup() releases its lock on myActivatorScript, where OnUpdateHandled is done at the onset:

Function ActivatorSetup()

    Bool wasHandled = OnUpdateHandled
    OnUpdateHandled = True
    If wasHandled
    ;~    Trace(Self + "ActivatorSetup() was handled.")
        Return
    EndIf

Again, note the proper semaphore test and set procedure. This carefully coded awareness of the cross-script interlock timing is the secret to its success.

[Arthmoor]

I've not seen 2.0.1 as yet. USKP 2.0.0 very reliably drops Riverwood and other exteriors on the ground.

No, it does not. I don't care what kind of EXTRA stuff you're throwing at the game. When tested in a vanilla setup, on a rig that's not exactly top of the line these days, it NEVER drops its stuff and neither do any of the other test cases.

It also does no such thing when I play on my normal load order game of ~95 mods, some of which are rather intensely scripted (wet & cold, footprints, etc) so if you're still seeing this happen it's because of baked in data. Which we can do nothing about. Hence why this rack update stuff seems to behave differently for everyone.

[BlackPete]

<>.... so if you're still seeing this happen it's because of baked in data. Which we can do nothing about. Hence why this rack update stuff seems to behave differently for everyone.

Most of this stuff is way over my head in terms of understanding, so that would make sense. The current save that I'm using was started with USKP v. 1.3.3 (which didn't have any of these issues prior to updating to 2.0.0), so I have no idea what is going on exactly, but it very well could be due to data retained in my save file. I'll have to start a new game and see the locations discussed above still have problems occurring with those weapon racks at some point in the near future.

 

I realize my computer system is quite "outdated" compared to what is available nowadays, but it is more than sufficient for running Skyrim at a minimum of high settings with very little (if any) performance issues. If I'm understanding correctly, the specifications of my PC probably have little to nothing to do with this issue though.

 

Edit: I just wanted to say that I started a new game using the 2.0.0 version of the USKP and noticed the same issue at Alvor's Forge in Riverwood, so I think it's safe to say that the issue may not be due to data baked into a save file. [screenshot]

[DayDreamer]

No, it does not. I don't care what kind of EXTRA stuff you're throwing at the game. When tested in a vanilla setup, on a rig that's not exactly top of the line these days, it NEVER drops its stuff and neither do any of the other test cases.

Proof by assertion is never a good argument, especially in the face of contrary empirical evidence. I got involved in this thread because they were falling on the ground in 2.0.0 beta. IIRC, BlackPete posted pictures some time ago.

 

... so if you're still seeing this happen it's because of baked in data. Which we can do nothing about. Hence why this rack update stuff seems to behave differently for everyone.

Baked in data isn't the problem, as you'd know by reading my previous posts and looking at my code. I reset everything to vanilla empty state OnCellDetach. Every new attach re-mounts all the starting items from scratch. Of course, that was originally to clear out the problematic marker pointers, but it's still vanilla empty state. There is no baked in data.

Unless I'm missing something. In which case, detailed technical evidence would be helpful.

 

Most of this stuff is way over my head in terms of understanding, so that would make sense. The current save that I'm using was started with USKP v. 1.3.3 (which didn't have any of these issues prior to updating to 2.0.0),

Same here.

 

I realize my computer system is quite "outdated" compared to what is available nowadays, but it is more than sufficient for running Skyrim at a minimum of high settings with very little (if any) performance issues. If I'm understanding correctly, the specifications of my PC probably have little to nothing to do with this issue though.

Agreed. I know I'm pushing it by running on Ultra with HiRes DLC ( earlier vanilla versions limited me to High, but 1.8 and 1.9 both calibrate to Ultra, so I'm on the bleeding edge). That's not the underlying problem.

And my script is so much faster, it's clearly a script timing and inter-script inter-locking issue. Since I've included my debug lines from the get-go, I know what's slow, and how long the 3D takes to load, etc.

 

Edit: I just wanted to say that I started a new game using the 2.0.0 version of the USKP and noticed the same issue at Alvor's Forge in Riverwood, so I think it's safe to say that the issue may not be due to data baked into a save file. [screenshot]

Bingo!

[Arthmoor]

Proof by assertion is never a good argument

Then don't use one while at the same time of accusing me of using one. My evidence is my own two eyes, which I am not inclined to discount as invalid sources of information.

[BlackPete]

I encountered something else with weapons racks that I thought I would share. This involves placing the "Staff of the Frost Atronach" on to a weapon rack. I noticed that when I place it on a weapon rack that in the process of it being removed from my inventory and moved to the rack that it damages my health "a few" points. This may happen with several other staffs as well and may or may not happen all weapon racks (I was testing on the ones in the Enchanting Lab addition to one of my Hearthfire homes). I will have to do some more testing and report back.

 

Edit: I did some further testing and does seem to be most (if not all) staffs.

[Nico coiN]

When placing any weapon on a weapon rack, it is unequiped from the player. It can be briefly seen on the top right edge of the screen and swirls very quickly. Could it be the source of the problem for large weapons ? If so, is it worth to implement a 'tgm 1' feature before unequipping, and a 'tgm 0' one once placing is done ? (Or let's say, one second later ?)

[maboleth]

I have encountered a rack with a sword that disappeared when I came close and then reappeared beneath the rack, without me doing anything else except coming closer.

[Arthmoor]

We're making headyway toward another beta. Gentlemen, do we have something ready to go for that?

[DayDreamer]

Then don't use one while at the same time of accusing me of using one. My evidence is my own two eyes, which I am not inclined to discount as invalid sources of information.

Please look up proof by assertion fallacy. Your not seeing something is not proof of anything.

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

It was further reproduced by other parties, including pictures for your eyes, and independently verified that my code fixed their problem.

 

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

 

We're making headyway toward another beta. Gentlemen, do we have something ready to go for that?

My code has long been submitted.

[Edited to include quotations for clarity]

 

[Components attached]

UHFPWRscript.7z

USKPWRscripts.7z

USKP - taleden esp.7z

[BlackPete]

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.