Jump to content

Overhauling the weapon rack scripts


Sclerocephalus

Recommended Posts

During the last week, I have been going through the weapon rack scripts and found many bugs and glitches that have not yet been adressed. The fixed versions can be downloaded here:

 

http://www.afkmods.com/index.php?/files/file/701-overhauled-weapon-rack-scripts/

 

The download also contains two comments files (one for each script) where I explain what was changed and why I'm convinced that it had to be done. As usual, I am not sure that I have spotted all of the bugs, but I am pretty confident that the scripts will provide some improvement.

 

Since this is a pretty "fresh" work, I haven't had the time yet to do much testing myself. You can be assured however, that I wouldn't have uploaded the files if was aware of a risk of them ruining your game or resulting in immediate crashes. Thus, if someone's interested in doing some testing, I really would appreciate your help (before installing the new scripts, please read the notes on the "dwarven shield bug" below). Also, it would be fine if someone could go through my comments to see whether anything else can be spotted which I might have overlooked or misinterpreted.

 

The Dwarven shield bug:

====================

If a Dwarven shield is placed on a shield rack, it will horribly clip through the rack and the wall behind it. This bug was reported on the tracker a long time ago, but hasn't been resolved yet. There's actually not much that can be done about it: modifying the shield's pivot is out of the question because it will break a lot of other things. However, we could add a new node to the shield rack, for use by Dwarven shields specifically (it apperas that this can be rather easily done in nifskope). The placement is very easily handled in the WeaponRackActivatorScript as it requires only three extra lines and while I was at it anyway, I have added this code to my modified version of the script (before testing the scripts, please delete the respective lines; the comments file for the WeaponRackActivatorScript explains how to do this - EDIT: This doesn't need to be done anymore: the download now includes "ready for testing" versions with all the necessary modifications already implemented).

 

Of course, this solution is debatable and I don't even know whether the USKP wants to address it at all.

Link to comment
Share on other sites

When you did this, were you working from the copy in 1.3.2c or is this handled differently? I ask because the script in 1.3.2 attempts to address the issue of certain items not sticking to the racks like they should. Such as the Ebony Blade.

Link to comment
Share on other sites

Yes and no.

 

As for the WeaponRackTriggerScript, the USKP only corrected a missing sanity check, and this has already been included in my modification.

 

As for the WeaponRackActivatorScript, I have checked what modifications were added in 1.3.2c and left this part untouched, but started work from the vanilla script. My modifications are aimed at solving issues with the starting weapons not handled properly (e.g. the weapons supposed to be placed on the rack at the northern watch tower which are floating in mid-air in front of the rack instead, or those on the rack in front of Alvor's house which fall to the ground when the player approaches) and with individual racks that occasionally stop working properly for no obvious reason. Though, I also made some arrangements to make the combination with the 1.3.2c modifications as easy as possible. Well, actually, said arrangements were made in the first place to optimize the code a little and to avoid confusion stemming from Bethesda's misleading variable names (because it appeared to me that one fat bug in the HandleWeaponPlacement function is a result of them falling victim to their misleading variable names themselves): In the same way as all of the code specifically related to the starting weapon is included in the HandleStartingWeapon function, I have created a new HandlePlayerItem function which includes all of the code that is specifically related to the player's weapon. The PlaceItem function (previously the HandleWeaponPlacement function) now only contains the code that has to be carried out for both weapons. At present, the HandlePlayerItem function only contains two lines of code: the DropItem command and a call of the PlaceItem function. This is where the modifications from 1.3.2c should be put in (this is also explained in the "WeaponRackActivatorScript_Comments.txt" file, which is included in the download).

 

 

Edit:

 

I have uploaded a new archive which does contain script versions with all modifications from USKP 1.3.2c already implemented.

Link to comment
Share on other sites

I don't know if it is related to the same problem but I had a bug a few weeks ago with USKP 1.3.2 : Wuuthrad didn't stay in Ysgramor's statue hands.

 

It fitted fine the first time, then I left the interior. The axe was lying on the ground when I came back later, it could be grabbed and the statue was totally unactivable. The linked door remained opened, however.

 

I didn't keep a savegame to check this one more time, but as the main plot of the companions quest is rather short it shouldn't be too long to verify on a new game.

 

 

 

Edit : BTW, I don't know if it's a bug from the forum but I can't download any uploaded file here.

Link to comment
Share on other sites

It's not a bug if you're referring to the Files for Fixes area. Only those in the USKP team can download files from there.

Link to comment
Share on other sites

I don't know if it is related to the same problem but I had a bug a few weeks ago with USKP 1.3.2 : Wuuthrad didn't stay in Ysgramor's statue hands.

 

I can confirm that this happens in my game as well (tested it just today), but I doubt that it has anything to do with the USKP. I had a look at the script (C06YsgramorStatueScript) which left me somewhat puzzled, because I couldn't see any reason for Wuuthrad falling to the ground - at least not at a first glance. The situation with the weapon racks is similar in some aspects: instead of staying attached to the racks as expected, some items fall to the ground for no obvious reason, and although I have found quite a number of bugs in the respective scripts, I cannot say that I did find a direct relationship between any of these bugs and this strange behaviour which remains a big mystery (well, at least for the "conventional" items; as far as unique weapons such as Keening and the ebony blade are concerned, which were notoriously refusing to stay on any rack, the USKP team had an idea and implemented this in patch 1.3.2.).

 

Thinking further about this, I also remembered that we often had issues with floating weapons in earlier versions of the game (at least up to official patch 1.4.). After the possessive corpses fix had been implemented, those problems seemed to have largely gone, but they were actually just less frequently observable, since the possessive corpses fix only cleaned up left-over items and did not really touch the aforementioned problem. Interestingly, this was just the opposite situation: things were floating when they shouldn't. And even more interesting: I was to Ysgramor's tomb in two playthroughs around that time and don't remember any problems with the statue. I'm also quite sure that I did never see a problem with the weapon rack in front of Alvor's house in earlier playthroughs - until quite recently. I wonder therefore, whether Bethesda might have made specific modifications to the game engine to take care of the floating weapons problem in one of the post-1.4. official patches, and whether some of the problems we're discussing now are not just side effects (oversights, so to say) of that fix. More precisely, I suspect that the engine has been tweaked so as to enable physics on all armor and weapon items in a cell when this cell unloads or detaches (can't say exactly which one of these two options). This would perfectly explain the behavior we see both with the weapon racks and Ysgramor's statue:

 

(1) The weapons supposed to be attached to racks are still linked to the racks. Provided that the starting weapons are handled as expected, the WeaponRackActivateScript (which runs on cell attach) will clear the situation by moving the respective items onto the rack and disabling their physics again. Unfortunatley though, due to inappropriate condition checks in said script, the starting weapons are not handled at all most of the time, resulting in them falling to the ground. When a cell loads for the first time and thus has never before unloaded or detached, the items would be hovering above ground at the positions where they have been placed in the CK: this can be observed at the northern watchtower of Whiterun.

 

(2) The situation is somewhat different with Ysgramor's statue, because Wuuthrad is not linked to the statue. In fact, it is not even Wuuthrad that is not linked to the statue, but another instance of Wuuthrad: upon activating the statue, Wuuthrad is removed from the player's inventory and said instance (which has been there all the time) is enabled (this also explains why any tempering done to Wuuthrad is lost in the process: what is put back in the player's inventory is yet another instance of Wuuthrad, while the weapon initially carried by the player is lost; to fix this, the script would have to be rewritten to use an appropriate container as a temporary storage for that copy of the weapon that is initially removed from the player's inventory). Once the cell unloads or detaches, the Wuuthrad copy gets physics enabled, and when the player returns, it will have fallen to the ground. Unlike for the weapon racks, there is no code running to make sure that Wuuthrad's staying in the place it was supposed to be.

Link to comment
Share on other sites

Wow, thanks, good explanations ! My understanding is now slightly better.

 

That leads me to a specific and different trick intended for Ysgramor's statue. We should first make a brand new mesh : Ysgramor's statue WITH Wuuthrad in hands (can be achieved with nifskope, but the mesh may already exist as it can be seen in a loadscreen). Let's call it Ysgramor2, whereas the original  statue with empty hands is Ysgramor1. Now let's place this new static at the same place and coordinates as Ysgramor1, but with the flag 'initially disabled'.

 

The process should become :

 

When placing Wuuthrad in statue's hands :

-Remove Wuuthrad from player's inventory and store it in a hidden container.

-Enable Ysgramor2, open locked door, disable Ysgramor1.

 

When taking Wuuthrad from statue's hands :

-Enable Ysgramor1, get Wuuthrad from hidden container and add it to player inventory.

-Disable Ysgramor2, close the door.

 

Now the bad news : as the process looks rather simple, I'm a total noob about scripting in Skyrim !  :P

Link to comment
Share on other sites

Sclerocephalus,

 

Would you mind opening a tracker issue for that Wuuthrad bug? I wasn't aware that it's eliminating the player's actual copy of that and I can't believe doing so is intentional design behavior.

Link to comment
Share on other sites

  • 4 weeks later...

Finally got around to testing this script overhaul.

 

Weapon racks no longer drop their stuff like was happening on that batch north of Whiterun. I never had issues with the stuff at Alvor's shop, so I can't comment on that.

 

The WeaponRackActivateScript script would not compile as uploaded, was missing the WRackTrigger keyword property, and had some parenthetical errors.

 

So what it set out to do appears to have been a complete success. Sadly, we're still no closer to getting it to stop dropping the Ebony Blade. I can't figure out why that is because the other changes that got made were supposed to solve that.

 

Also, the Wuuthrad issue is fixed as well.

Link to comment
Share on other sites

This adds some missing bits of information, though:

 

The problem with the ebony blade is possiblly not that it falls off the rack. The actual problem appears to be that it never gets actually attached to the rack!

 

There are two noteworthy facts about racks, havok and the link between the rack and the weapon:

(1) Havok: When the player grabs a weapon from the rack, the weapon is havok-enabled. Though, the weapon rack scripts disable havok before the weapon is placed on the rack and there are no scripts running when the weapon is grabbed, neither on the rack nor on the weapon. Consequently, there must be a background process which turns on havok at some point, probably on cell detach or on cell unload (as pointed out earlier). Thus, if a weapon falls to the ground, this may be simply the result of havok being turned on. This observation alone won't tell us whether the weapon was ever "on the rack" (i.e. whether it was ever linked to it or not).

(2) The link: There are no script commands to establish a link between two objects. Nonetheless, when the rack is loaded, it finds the attached weapon through a link. This is remarkable, since there is certainly no link when an arbitrary weapon is placed on the rack, and the script doesn't (and cannot care about this. Thus, there must be another background process that establishes the link, and this is almost certainly the MoveToNode command (although I did not find any documentation, it appears that this command does not simply move an object to a specific place, but also creates a linked reference). Now, when creating the link would fail for some reason, the weapon would still appear to be attached to the rack (because havok is turned off), although it is actually not.

 

After correcting the bugs that affected the handling of the starting weapon, it is relatively safe to assume that any weapon linked to the rack will be handled properly now. However, this also means that a weapon which still doesn't stay on a rack behaves in this way because it isn't linked to it. I also cannot imagine how a link could be broken or a linked reference lost. It is more likely that the link wasn't there from the beginning.

 

Investigation of this phenomenon would be much easier if we had a reliable list of the affected weapons. So far, I know for sure only of Keening and the ebony blade. In addition, I found a mod-added weapon with the same problem: the so-called "Jade Blade" from JaySuS Swords. It has been placed in a dungeon, but the reference (according to TES5Edit) is not persistent. Investigation in nifskope showed that the guy used the silver sword as a template. It would be extremely interesting now to know whether a silver sword stays on a rack. If it does, we would have proof that the phenomenon can be caused by a mesh edit.

Link to comment
Share on other sites

A silver sword... hmmm. Ok. I'll give that one a try then.

 

So far as we've ever had reported, Ebony Blade and Zephyr (from Dawnguard) wouldn't stick. They'd fall off upon returning to the cell. Ghostblade would get thrown off into Oblivion or something.

 

Last I checked (before your version) Zephyr and Ghostblade were both working fine, but Ebony Blade refuses to cooperate, always falling to the floor upon coming back.

 

Bug #193 has been in the tracker since about the first week of the game's lifespan. Ebony Blade *IS* a quest item though, and weapon racks don't seem to care if they take those from you either which is a separate issue that was raised in Bug #148. Solving the issue of blocking quest items from being placed on the rack would probably end this once and for all.

Link to comment
Share on other sites

You can add Keening to the list. This was observed in my first playthrough with no mods active, more than a year ago. I also did report this on the old tracker at 16bugs.

 

 

EDIT:

 

Just a thought: Why not create a custom copy of the ebony blade and see whether this will stick to the rack ?

- If it does, the problem is proven to be due to the blade being a quest object, and all we can do is exclude it from being placed on any rack.

- If it does not stick, however, we would know at least that we have to look elsewhere for the reason of this bug.

Link to comment
Share on other sites

You can add Keening to the list. This was observed in my first playthrough with no mods active, more than a year ago. I also did report this on the old tracker at 16bugs.

 

 

EDIT:

 

Just a thought: Why not create a custom copy of the ebony blade and see whether this will stick to the rack ?

- If it does, the problem is proven to be due to the blade being a quest object, and all we can do is exclude it from being placed on any rack.

- If it does not stick, however, we would know at least that we have to look elsewhere for the reason of this bug.

Ok. Not sure why I didn't think to try that before, but I did. The cloned copy of the weapon sticks to the rack just fine. So it's due to it being a quest item, and the racks shouldn't be accepting those anyway.

 

To come back to the shield placement bug:

I have added a shield plaque mesh with extra nodes for those shields that show some clipping due to their geometries:

http://www.afkmods.com/index.php?/files/file/757-shield-plaque-mesh-with-extra-nodes/

Cool. I'll take a look at this now.

Link to comment
Share on other sites

Ok. The extra nodes thing works good for Daedric and Dragonplate, but the Dwarven shield still clips through like crazy.

 

GAH. Nevermind. Looks like there's some save baking going on here. I stuck a brand new rack in Breezehome and the shield doesn't clip, I just need to fiddle with the node positions to get it right.

 

Um. Ok. Makes no sense. I sure hope this isn't another one of these damned "your rack is on the wrong wall" things like with that Hearthfire bug.

Link to comment
Share on other sites

Arthmoor,

 

Before you go live with the 1.3.3. patch, one final modification should be included. The shield of Ysgramor needs its own node:

 

http://www.afkmods.com/index.php?/gallery/image/1014-rackproblem-1/

 

The shield is obviously rotated out of plane, making one side clip horribly while the other side looks fine. Without the rotation, the arms of every actor carrying it would clip through the mesh, so this can't be solved by rotating the shield mesh itself. The distance from the plaque needed to mount it properly without giving the impression that it's actually floating is about halfway between the pivots for the Dragonbone and Daedric shields and therefore, a new node had to be added rather than trying to move it to either of the aforementioned pivots. The new shield plaque mesh has alredy been uploaded (the name of the new node is "ShieldPivotYsgramor"):

 

http://www.afkmods.com/index.php?/files/file/778-shield-plaque-mesh-with-extra-nodes/

 

While testting, I stumbled upon another bug which counteracts to many benefits of the new script: the rack type (an integer property on the script), which has to be specified individually for each rack the script is attached to, has been given a wrong value for some racks. EDIT: Arrrgghhhh - I should have checked this immediately, but I didn't imagine that it was that bad. The rack types are all set up correctly (all references inherit the script with all the properties from their base objects). They simply forgot to add a staff pivot to this mesh! (thanks god this is an easy fix). As a result, you may end up with floating weapons:

 

http://www.afkmods.com/index.php?/gallery/image/1014-rackproblem-2/

 

This is because the script will work up to the point where the weapon has been dropped from the player's inventory, but then, the MoveToNode command fails because it specifies a node which doesn't exist on the rack. I'm presently checking all racks in vanilla Skyrim and will open a bug on the tracker with all the details when I'm done. Later on, the same will also have to be done for the DLCs.

Link to comment
Share on other sites

This fix is going more and more accurate and these are good news. Well, I'd like to make a suggestion about a slightly linked problem (well, I may be wrong but I don't really know). Too bad that Bethesda didn't make a generic rigging for these racks and then made all clothes, armors and weapons to fit it. Maybe racks and mannequins were late addons during the making process of the game, once nearly all was already done. We'll probably never know...

 

Fine, the problem is about bolt quivers introduced with Dawnguard and 3rd person view. There may certainly have an entry in the bugtracker but I can't find it. The quivers fit pretty well on female characters but seem to be floating with male ones. There are already various mods such as this one or this one that 'pretend' to fix the problem. But as they fix it for males, they break it for females (quivers are now embedded)...

 

Well, the bolt quivers seem to align themselves in the same geometric plane as the bow ones. But could the entire body of the player and NPCs be considered as racks/mannequins (which are basically a specific race) ? Is it possible to attach nodes to it in order to delete this gap specifically for males (that could probably be more elaborated depending on races) ?

Link to comment
Share on other sites

Mechanics of items mounted on an actor's back are a bit different from how a weapon rack is working. In this case, the pivot on the item is moved to a fixed position on the actor. There is no way to tell the engine to move specific items to different positions depending on race and/or gender. Therefore, the only solution to this problem is to define separate male and female quiver models.

Link to comment
Share on other sites

Did I say that this fix was simple ?

 

Well, there are five nodes needed to accommodate all staffs. It's not that they are particularly difficult to fit into the cases, it's just that they take all the available space - unlike the weapons which leave enough room so that adjustments depending on their 3D models are not needed. The modified mesh is here:

 

http://www.afkmods.com/index.php?/files/file/780-display-case-mesh-with-staff-nodes-added/

 

The necessary modifications to the WeaponRackActivateScript should look as follows (this is also included in the download):

 

 

    :
    ElseIf ItemToPlace.HasKeyword (WeaponTypeStaff)

 

        If (RackType == StandardRack)

            If (ItemToPlace.GetBaseObject() As Weapon == DA16SkullOfCorruption)
                ItemToPlace.MoveToNode (TriggerMarker, "StaffPivotCorruption")
            ElseIf (ItemToPlace.GetBaseObject() As Weapon == DA14SanguineRose)
                ItemToPlace.MoveToNode (TriggerMarker, "StaffPivotSanguine")
            ElseIf ItemToPlace.HasNode ("Staff3rdPerson:0")
                ItemToPlace.MoveToNode (TriggerMarker, "StaffPivotFalmer")
            ElseIf ItemToPlace.HasNode ("DragonPriestStaff3rd:0") || ItemToPlace.HasNode ("MQ_DragonPriestStaff3rd01:0")
                ItemToPlace.MoveToNode (TriggerMarker, "StaffPivot03")
            ElseIf ItemToPlace.HasNode ("Staff01:0") || ItemToPlace.HasNode ("Staff03:1") || (ItemToPlace.GetBaseObject() As Weapon  == MG07StaffOfMagnus)
                ItemToPlace.MoveToNode (TriggerMarker, "StaffPivot01")
            Else
                ItemToPlace.MoveToNode (TriggerMarker, "StaffPivot02")
            EndIf

 

       Else

          ItemToPlace.MoveToNode (TriggerMarker, "StaffPivot01")

       EndIf
        :

 

 

EDIT: For clarification:

 

- Staffs with 3D models Staff01.nif or Staff03.nif and the Staff of Magnus are placed on "StaffPivot01",

- Staffs with 3D models Staff02.nif or Staff04.nif and the Wabbajack are placed on "StaffPivot02" (EDIT3: this is now also the default node for all staffs that do not fit in any of the new categories),

- Dragon priest staffs (3D models DragonPriestStaff.nif and MQ_DragonPriestStaff.nif) are placed on "StaffPivot03",

- Falmer staffs from Dawnguard are placed on "StaffPivotFalmer"

- the Skull of Corruption is placed on "StaffPivotCorruption",

- the Sanguine Rose is placed on "StaffPivotSanguine"

 

EDIT2: IMPORTANT:

 

In case you get the impression now that all those mesh edits finally went over the top and consider to just disallow staffs being placed in those display cases instead, the simple answer is: you can't! This is because Bethesda didn't make any difference in the handling of the large display cases, the wall-mounted racks and the single weapon plaques: they all are type 1 racks and they are not further discerned in the scripts. To make them discernible to have the chance to handle them in a different manner, you would have to invent new keywords, and in the end, the script modifications would not be much less invasive. To keep it simple, your only alternative would be to generally disallow staffs on any rack, but this is not a good solution either.

 

A side effect of this is that I'm not done now: I'll have to add the same new staff pivots also to WRPlaque01.nif andWRSingle01.nif in order to prevent the scripts from failing. The good news is that I am already working on this and that I will be able to eliminate a number of minor clipping and positioning problems in this process. I'm also taking care of the Dawnguard-added Falmer staffs which presently clip horribly on any rack (only God and Bethesda know why these staffs, unlike all other staffs, have been constructed in the y-z plane instead of the x-y plane). Since we discern the staffs via the HasNode command (much easier than to check every single staff separately), this addition will work even if Dawnguard is not installed.

 

EDIT3:

 

All done now!

Have also updated the script modifications above.

Link to comment
Share on other sites

Oh my God ... they did not leave a single bug out ...

 

Type 1, 2 and 4 racks are all properly configured, but some of the type 3 racks are not. While WeaponRackCOALeftACTIVATOR and WeaponRackCOARightACTIVATOR are properly specified as type 3 racks, the player house analogues WeaponRackCOALeftACTIVATORPlayerHouse and WeaponRackCOARightACTIVATORPlayerHouse have been specified as type 1 racks instead, and this will leave you with floating bows and daggers because the corresponding nodes do not exist on type 3 rack meshes.

 

Now, this is really an easy fix, because this only has to be corrected for the base objects, from which all references are inheriting their data.

Link to comment
Share on other sites

Status Update:

 

Since yesterday morning, I'm testing all fixes in the running game. Due to the mechanics of the MoveToNode command - it ignores the translation on a weapon's 3D model node, but it preserves its rotation - I had to modify some of the node positions again (this was also the actual reason why the placement of Ysgramor's shield was broken, so I assume that some of the developers weren't aware of this detail either). Good news is that the HasNode command works even better than I thought on discerning the weapon models. Here's a preview of a former "clipper":

 

The Falmer staff before the fix (it also clips through the plaque when mounted on it):

(EDIT: Link removed - new screenshots are in the most recent upload)

 

The Falmer staff after the fix:

(EDIT: Links removed - new screenshots are in the most recent upload)

 

I also had to modify the trigger script a little, since the rack status took a long while to update when the player remained in the cell (i.e. after grabbing a weapon from a rack, it would take up to a minute until the rack could be activated again) and I could nail this glitch down to the OnTriggerLeave event firing out of sync with the OnTriggerEnter event, which messed up the enable state of the linked activator.

 

I propose that you wait until this evening (for me, this will be tomorrow morning) before taking any further actions. Until then, I will have uploaded a final all-in-one package (scripts plus meshes).

 

One more:

http://www.afkmods.com/index.php?/gallery/image/1040-staff-in-showcase/

Link to comment
Share on other sites

Well if you're going to go ahead and do that, would you please also undo all that "helper alias" stuff? I've lost track of exactly what needs to go away with that.

 

It was put together as an attempt to solve the problem with Ebony Blade, but since that's a quest item and only quest items continue to fail to stick, that whole setup doesn't even need to be there now. Unless I'm seriously missing something anyway.

 

BTW, wish I'd seen this post sooner since I already updated everything with the information you had posted despite it becoming quite difficult to keep track of :P

 

Oh, and an ESP with all of the properties correctly set would be HUGELY appreciated because I've most likely missed some stuff since which activators need what properties to be set was never specified to begin with.

Link to comment
Share on other sites

It was put together as an attempt to solve the problem with Ebony Blade, but since that's a quest item and only quest items continue to fail to stick, that whole setup doesn't even need to be there now. Unless I'm seriously missing something anyway.

The Ebony Blade isn't a quest item; the quest is removed from the log as soon as its acquired and the player may drop it after that if they wish, even if it isn't powered up.

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