Jump to content

Overhauling the weapon rack scripts


Sclerocephalus

Recommended Posts

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.

We tested this earlier (please have a look at the discussion on the previous page): A clone of the ebony blade (i.e. a custom weapon with the ebony blade model) will stick to racks just fine, but the ebony blade itself falls off. If you have an idea why this happens or even know how to fix this, please let us know. In the meantime, we prefer to disallow putting the ebony blade on any racks.

Link to comment
Share on other sites

More precisely, there are two ebony blades, both of which are in possession of the player at some point in the game, and both of them have a script attached. The mere fact that a script is attached should not matter, but the scripts react on container change events (thus, they will also react when the weapon is placed on a rack or in a container) by setting stages on the DA14 quest. It remains the question why it can be put in a container without problems then ...

 

With the new code and the USKP 1.3.2c fix removed, something funny is happening: an angry engine god throws it back to the ground at the player's feet ... Now, it doesn't even stick temporarily to a rack. To circumvent all this, I have added a check to the WeaponRackActivateScript. Placing either one of the ebony blade versions or Keening on any rack is now simply disallowed - at least until someboy finds out what the problem is.

 

If you want to further think about it, start with the "Jade Blade" from JaySuS Swords and find out what the hell he did to make it drop from any rack. It behaves exactly like the ebony blade (it has NOT been built on that mesh - it's not that simple ...), but has no script attached, is not a quest item and its reference in the game is not persistent. Perhaps a mesh problem after all ?

Link to comment
Share on other sites

If you construct a custom weapon rack which is supposed to be enabled later in the game, do NEVER, NEVER, NEVER, NEVER, NEVER link the activator to the enable parent. The activators are scripted to enable themselves once their linked triggers are enabled (so it is entirely sufficient to link the triggers to the enable parent). Moreover though, they do so on every cell attach and enable themselves to be ready for player activation when there's no weapon placed on the rack. When linked to an enable parent, the whole initialization procedure fails and the rack may totally glitch out.

 

Unfortunately, some idiot has been doing it anyway, and this was the simple reason why two dagger cases in Hjerim refused to cooperate with the script ....

 

EDIT:

Meanwhile, I have checked all activators in all player houses, and they are all properly configured, except for the two cases in Hjerim already mentioned. Eventually, somebody should also check the Hearthfires racks (I don't have that plugin).

Link to comment
Share on other sites

Finally, everything works!

 

http://www.afkmods.com/index.php?/files/file/785-weapon-rack-overhaul/

 

EDIT:

One more screenshot to demonstrate the benefit of the new script:

http://www.afkmods.com/index.php?/gallery/image/1065-a-rack-on-the-roof-of-fort-dawnguard/

 

 

A few remarks nonetheless:

 

(1) Occupied racks will not immediately switch to the new script (they also will not immediately adopt the new item placement). This is because the activators are disabled as long as there are weapons on the rack. To make them work, grab the weapons from the racks, then leave the cell. Upon returning, the racks will mostly work already (the activator runs its initialization on cell attach). Even better though if you leave the area and come back after some time (to make sure the cell has unloaded in the meantime - the trigger runs its initialization on load).

 

(2) The following activators had their rack type changed:

 

(a) WeaponRackCOALeftACTIVATORPlayerHouse and WeaponRackCOARightACTIVATORPlayerHouse: new rack type = 3 (was erroneously set to 1)

(b) WeaponRackDisplayACTIVATORPlayerHouse: new rack type = 5 (previously set at 1; I needed to discern it from the other type 1 racks)

 

I noticed however that the racks refuse to accept a new rack type value, and I cannot even say whether they will eventually accept it at all, so I had to conceive a workaround. Case (a) is already handled by the "Patch14CoARacks" bool, which was obviously introduced to handle this very misconfiguration after the developers seem to have run into the same problem. Case (b) is handled by checking the presence of a particular node in the trigger mesh (i.e. by running the HasNode function on the trigger marker reference), which I did add only for this purpose (I had to add six staff nodes to this mesh anyway). All racks will now behave properly, irrespective of whether they have a matching rack type value set or not.

 

(3) Enable parents were removed from activators 00102A22 and 00102A25:

As already mentioned, this will prevent the scripts from setting the activator's enable state and turns the whole rack perfectly useless. Two error messages complaining about not being able to enable a reference with an enable state parent, which always occurred upon entering Hjerim, are now gone forever.

 

(4) Placement fixes:

 

(a) The shield rack trigger mesh WRPlaqueShield01.nif had 4 new nodes added for Daedric, Dragonbone, Dwarven and Ysgramor's shields.

 

(b) The display case trigger mesh WRDisplayCase01.nif had seven new nodes added - six to handle the various staffs (note that this mesh was missing any staff nodes entirely), and another one (the "BogusPivot") to allow the scripts for unambiguously discerning this trigger from other type 1 rack triggers. In addition, I slightly moved the bow pivot, which was not properly centered and made large bows clip through the case on one side.

 

A minimum of six staff nodes was needed because most staffs are barely fitting into the display, so each staff geometry had to be taken care of separately. Unfortunately, the MoveToNode command disregards any scaling factors set for the pivots on the trigger meshes, so I had to exclude the very large staffs (the conjuration school staffs and the Dawnguard-added Falmer staffs) from being put in this rack (an error message will display if the player tries to do it anyway). Since discerning the staffs required to have the object reference, which is not known until the player's weapon is actually dropped, the related checks are carried out when the staff has already been removed from the player's inventory. If it is not allowed on the rack, it is put back in his inventory silently. Although this process runs pretty fast, you may still see the staff in front of you for a fraction of a second before it disappears again. You'll have to live with that; scripting it otherwise is pretty complicated (although not impossible - maybe I'll have a look into this later). A consequence of this restraint was that I had to make this rack discernible from other type 1 racks (previously, they were all handled by the scripts in the same manner).

 

© The display case trigger meshes WRPlaque01.nif and WRSingle01.nif had the same six staff nodes added as WRDisplayCase01.nif.

This was done before the script was modified to handle the large display cases (to which WRDisplayCase01.nif belongs) separately. With this distinction made, modifications to WRPlaque01.nif and WRSingle01.nif actually became obsolete, but I decided to leave the new nodes in. After all, they provide improvements since they react to the various staff geometries more specifically than a single node could do (for example, some staffs were previously displayed with the handle up on single-weapon plaques; they all display now properly with the handle down).

 

 

(5) I ran into an engine bug:

This only affects the skull of corruption and the Dawnguard-added Falmer staffs: While they are displayed properly on standard racks in Hjerim, they appear upside down on the same rack type in Honeyside. Meanwhile, I know how to modify the nodes so as to make them properly display in Honeyside, but then, they will be displayed upside down in Hjerim ... This behaviour is perfectly repeatable on my PC. I believe that this is also reproducible, but others will have to confirm this yet. For the same reason, I did not touch the placement of the Falmer staffs on the CoA (three-in-one) racks: after modifying the nodes appropriately (or, what I thought to be appropriate), I ended up with both staffs floating upside down in thin air above the racks ...

 

Thus, it seems that the Hearthfire shield bug is in fact rotation-dependent (as originally thought), but it appears to depend not only on the rotation of the plaques themselves. The rotation of the node, which has been not considered yet, seems to play an important role as well. I need a further look into that.

Link to comment
Share on other sites

EDIT:

Meanwhile, I have checked all activators in all player houses, and they are all properly configured, except for the two cases in Hjerim already mentioned. Eventually, somebody should also check the Hearthfires racks (I don't have that plugin).

Do you have Skyrim Legendary Edition?

Link to comment
Share on other sites

Legendary edition has no differences from just having all the dlc's(basically a GOTY edition)

Link to comment
Share on other sites

I was hoping that you already had Skyrim LE.  I suggest that buy Skyrim LE asap or you can buy Hearthfire on Steam for less than 5 €uro.

Link to comment
Share on other sites

There should be nothing special needed to support Hearthfire anyway. It uses all of the same vanilla racks and stuff.

 

As for the changing rack types not taking, that's because that information bakes into the save and can't be updated by simply changing the value. Starting a new game would pull those changes in properly though.

Link to comment
Share on other sites

Still getting some stuff like this but I assume that's because the enable parenting is fubar?

[07/08/2013 - 04:40:50PM] Error:  (000FC870): cannot disable an object with an enable state parent.
stack:
    [ (000FC870)].WeaponRackActivateSCRIPT.Disable() - "<native>" Line ?
    [ (000FC874)].WeaponRackTriggerSCRIPT.OnTriggerEnter() - "WeaponRackTriggerScript.psc" Line 53
[07/08/2013 - 04:40:50PM] Error:  (000FC870): cannot enable an object with an enable state parent.
stack:
    [ (000FC870)].WeaponRackActivateSCRIPT.Enable() - "<native>" Line ?
    [ (000FC874)].WeaponRackTriggerSCRIPT.OnLoad() - "WeaponRackTriggerScript.psc" Line 29

Those are from the racks outside at the watchtower just north of Whiterun.

 

Otherwise the updates are working flawlessly. No other errors, no stuff falling off, no polysplosions, no floaters, and best of all, properly rejecting the placement of quest items. Or at least the Ebony Blade since it's the only one I had ready access to test with.

Link to comment
Share on other sites

I really wonder how the heck any of the scripts worked as well as they did with all these errors XD

Link to comment
Share on other sites

May I suggest to display a specific message or notification explaining why the ebony blade can't be mounted on a weapon rack ? Something fakely lore-friendly like "Mephala doesn't allow her sword to be in everyone's sight" ? or "The ebony blade is bound to its owner and cannot be left to everybody's access" ?

Link to comment
Share on other sites

Still getting some stuff like this but I assume that's because the enable parenting is fubar?

[07/08/2013 - 04:40:50PM] Error:  (000FC870): cannot disable an object with an enable state parent.
stack:
    [ (000FC870)].WeaponRackActivateSCRIPT.Disable() - "<native>" Line ?
    [ (000FC874)].WeaponRackTriggerSCRIPT.OnTriggerEnter() - "WeaponRackTriggerScript.psc" Line 53
[07/08/2013 - 04:40:50PM] Error:  (000FC870): cannot enable an object with an enable state parent.
stack:
    [ (000FC870)].WeaponRackActivateSCRIPT.Enable() - "<native>" Line ?
    [ (000FC874)].WeaponRackTriggerSCRIPT.OnLoad() - "WeaponRackTriggerScript.psc" Line 29

Those are from the racks outside at the watchtower just north of Whiterun.

 

Otherwise the updates are working flawlessly. No other errors, no stuff falling off, no polysplosions, no floaters, and best of all, properly rejecting the placement of quest items. Or at least the Ebony Blade since it's the only one I had ready access to test with.

 

These are misconfigured activators that have been erroneously linked to an enable parent. I have checked only those in the player houses (they were of paramount importance because this bug can prevent them from being player-activated!); there are many more left to check elsewhere (they are best spotted on the log, just as you did here).

 

To correct them, make sure that the "initially disabled" flag is set, then remove the enable parent (in TESVEdit) or set the enable parent to "none" (in the CK). The scripts won't work properly if they can't freely enable/disable the activator.

 

EDIT:

Forgot to add that there are six more of these in the Ragged Flagon: 000DB7C8, 000DB7C9, 000DB7CA, 000DB7E1, 000DB7F9 and 000DB7FA. Since I'm still working on the racks (there are some lower priority issues left and not all item placements are perfect), you can get an updated esp file from me, which includes the fixes to all those that I have spotted in the meantime.

Link to comment
Share on other sites

I really wonder how the heck any of the scripts worked as well as they did with all these errors XD

 

None of the scripts was actually causing any critical errors, i.e. they did not break any quests and did not cause CTDs, but they filled the logs with error messages from the beginning. Thus, saying that they worked well is far from the truth.

 

Also, there were many minor bugs that never ocurred in the game because they were blocked from doing so by major overlying bugs. It's amazing how many bugs I ran into when I started to dig deeper. We have a saying which approximately translates as follows: "When you start digging in a pile of shit, it will start smelling ..."

Link to comment
Share on other sites

Here's an overview of the items that still are on my to-do list:

 

(1) Fix misconfigured activators:

Remove the enable parent from all those that are erroneously linked to one.

 

(2) Improve the trigger script:

It still can be improved a little by moving the activator enable/disable procedure in a separate function. This reduces the size of the script and saves a very small amount of memory. Admittedly, not a big leap forward.

 

(3) Fix the "USKPWeaponRackWeaponDisallowedMESSAGE":

When creating this, I had more than one item in mind, so it reads "You can't put these weapons on a rack". In the game, however, it always relates to attempts at placing a single weapon, so it should read "You can't put this weapon on a rack" instead.

 

(4) Add the ghostblade to the exclusion list:

Before excluding the ebony blade and Keening from being put on racks, I checked their behaviour with the new scripts, but somehow I forgot the ghostblade. All attempts to put it on a rack were unsuccessful. The DropItem command will not even create a reference and the script already fails the Is3DLoaded check. With the DropIt function from USKP 1.3.2c, it is dropped at least, but it can't be put on any rack (with the new script, all of those droppers won't even stick temporarily to a rack anymore). Repeated attempts at trying this filled my papyrus log with a little over 300KB of error messages within less than a minute (!) and suddenly, the ghostblade was gone - deleted from my inventory and also nowhere to be found in the house. Not even the log could enlighten me as to why this happened. Thus, the ghostblade needs to be added to the list.

 

(5) Set the collision flags on the new item placement pivots:

I did this for the shield plaque mesh, but forgot to do it for the other meshes. They may have an impact on whether items can be grabbed from a rack. Better safe than not.

 

(6) Handle crossbows:

At present, the crossbows are not allowed to be placed on racks. When I started working on the script fixes, I had Dawnguard not even installed and no idea of how they would have to be handled. Though, since they have the WeapTypeBow keyword attached, the scripts already have full functionality to handle them and would move them to the bow pivots. Preliminary test have shown that they look fine on those pivots, which makes blocking them superfluous.

 

(7) Take care of weapon dummies:

There are a few racks in vanilla Skyrim with weapon dummies placed on them as starting weapons. Since dummies (which are essentially markers that refer to leveled lists) have no 3D and cannot be moved, the scripts will fail the Is3DLoaded check and the MoveToNode command - at least as long as the activator is linked to the dummy, which is was seems to be the case because the dummies throw errors on the log. Dummy objects don't have scripts running on them, so the process of chosing an item from the leveled list the dummy refers to and loading it is entirely engine-handled. This makes things difficult because I can only guess what happens. Eventually, an item reference will be created at the dummy position and there are two possibilities for the next thing to happen:

 

(a) Nothing happens.

That is, the activator will still be linked to the dummy. In this case, placing dummies on racks was a crackpot idea from the beginning, since there is no way to get hold of the reference of the created item. There are no Papyrus functions to handle dummies, so there's also no way to conceive a workaround by reading the leveled list from the dummy. In this case, I can add a block to the script which prevents dummies from being handled at all and eliminates any related error messages, but this alone won't solve the problem because the dummies will continue to create floaters which eventually are dropped in front of the racks. To fix the bug entirely, we would also have to remove all dummies from their racks.

 

(b) The engine automatically links the activator to the created reference (after checking whether the dummy is linked from another reference):

Not likely to happen as it would unlink the dummy and make it stop working (unless there's another engine process running to take care of it - apologies if that sounds harsh, but I don't believe that the developers were smart enough to think of that), but it is worth to be tested, since it would open up a way for handling the dummies after all (one would only have to wait for the dummy keyword disappearing from the linked reference).

 

EDIT:

The error messages from dummies typically look as follows:

 

[07/08/2013 - 05:43:47PM] error:  (000ACD7E): does not have any 3d and so cannot be moved to.
stack:
    [ (00035514)].ObjectReference.MoveToNode() - "<native>" Line ?
    [ (000ACD7F)].WeaponRackActivateSCRIPT.PlaceItem() - "WeaponRackActivateSCRIPT.psc" Line 228
    [ (000ACD7F)].WeaponRackActivateSCRIPT.HandleStartingItem() - "WeaponRackActivateSCRIPT.psc" Line 286
    [ (000ACD7F)].WeaponRackActivateSCRIPT.OnCellAttach() - "WeaponRackActivateSCRIPT.psc" Line 85
 

 

(8) Fix placement bugs:

Apart from a few minor fixes to the new nodes, this is mainly aimed at fixing the engine bug previously mentioned. Unless I have an ingenious idea, this is unlikely to get solved anytime soon.

 

 

I will continue to upload updates.

Link to comment
Share on other sites

Would you mind if I used some of the images from the file entry to put up on Nexus etc when we're ready to go live?

Link to comment
Share on other sites

Would you mind if I used some of the images from the file entry to put up on Nexus etc when we're ready to go live?

 

Take whatever you want. All of my uploads are intended for sharing.

 

 

We have a saying which approximately translates as follows: "When you start digging in a pile of shit, it will start smelling ..."

 

I'm usually not quoting myself, but ... a look at the misconfigured activators which you spotted at Whiterun led me directly to another two bugs:

 

(1) These racks have the wrong enable parent. This bug has its own entry now:

http://www.afkmods.com/index.php?/tracdown/issue/13189-weapon-racks-and-other-items-at-the-northern-watchtower-of-whiterun-are-linked-to-the-wrong-enable-markers/

 

(2) Something I should have been thinking about earlier:

The activators check the enable state of the triggers and enable themselves when the triggers are enabled. Therefore, you can safely flag all activators that are linked to enable-parented triggers as "initially disabled" and don't have to dig through a chain of linked markers to find out which state it was supposed to be in at game start. Unfortunately, Beth totally forgot to update the activators when a trigger is disabled ... This has been added to my to-do list and will be implemented as soon as possible.

 

EDIT:

Issue (2) is obsolete. I have checked the behaviour of enabled activators that are linked to disabled triggers in a test setup, and they have no effect whatsoever. Noneheless, disabling activators once their linked triggers have been disabled may save a little performance, because the script doesn't need to run on them when they are inoperative. Nevermind, this is already handled by the scripts (same in the old version).

Link to comment
Share on other sites

Some good news:

 

I had to adjust the placement of the Falmer staffs on wooden racks to prevent clipping that occurred when another Falmer staff was placed on an adjacent rack. To accomplish this, I did rotate the staff slightly (10°) out of the plane of the rack - and this mysteriously solved that mystery engine bug which made this staff appear upright on some racks (e.g. Hjerim) and upside down on others (e.g. Honeyside) ...

 

The engine seems to dislike overall rotations (rack position plus node rotation data) of exactly +90° or -90° around any axes. This may have something to do with the nifs using a different format for rotation data (-180° to 180°) than the Skyrim engine (0-360°), but to be sure about that requires further testing.

Link to comment
Share on other sites

Just a remark (and pure supposition) about all these weapons that are placed upside-down or 180°-rotated on racks : perhaps the engine processes their geometry through trigonometric equations. I'm not yet very aware of this (I only have far remains from university) but, in trigonometry, when you are searching (for example) the angle corresponding to a cosine equal to 0 you obtain 2 primary possibilities : 90° and -90°. Basic calculators although often give only one, and if they can find both they need to know which value to use for further calculations... That would explain this not-so-strange behaviour, don't you think ?

Link to comment
Share on other sites

There's a slight problem, but I'm thinking it's easily fixed. Hearthfire has this function in BYOHDivertPrefabsScript. I went to silence the non-error debug messages and got back an error saying "PlayersDroppedWeapon is not a property on script weaponrackactivatescript or one of its parents"

 

Event OnCellAttach()
    bool shouldBeDisabled = Self.GetLinkedRef().IsDisabled()
    ;Is this object a bookshelf?
    PlayerBookshelfContainerScript bcs = ((Self as ObjectReference) as PlayerBookShelfContainerScript)
    if (bcs != None)
        ;Yes, so update the state of the books.
        if (shouldBeDisabled && !Self.GetLinkedRef(LinkCustom01).IsDisabled())
            MoveBooks(bcs)
        EndIf
        ;Debug.Trace("Bookshelf processed. Object state was: " + shouldBeDisabled)
    Else
        ;Is this object a Weapon Rack?
        WeaponRackActivateScript wras = ((Self as ObjectReference) as WeaponRackActivateScript)
        if (wras != None)
            ;Yes, so update the state of the weapon and the trigger.
            if (shouldBeDisabled)
                Self.Disable()
                if (wras.PlayersDroppedWeapon != None)
                    wras.PlayersDroppedWeapon.Disable()
                EndIf
            Else
                if (wras.PlayersDroppedWeapon != None)
                    wras.PlayersDroppedWeapon.Enable()
                    Self.Disable()
                Else
                    Self.Enable()
                EndIf
            EndIf
            ;Debug.Trace("Weapon Rack processed. Object state was: " + shouldBeDisabled)
        Else
            ;That's all the prefabs we need to disable, at least for now.
            Debug.Trace("Unidentified Prefab.")
        EndIf
    EndIf        
EndEvent

 

It appears as though that variable name has been changed in your overhauled script and is instead called "PlayerItemRef". This makes me a bit nervous as it indicates other scripts may be relying on this hidden property as well. Is it safe to simply change that variable name back to "PlayersDroppedWeapon" instead so this won't be a problem?

Link to comment
Share on other sites

That's the problem with me not having Hearthfires ... Skyrim, Dawnguard and Dragonborn have no scripts running that access the weapon rack scripts in any way. I can rename this property (and add it back in - it's not a big deal), but there's an easier way to check whether there's an item on the rack (if it's just this single script ...):

 

ObjectReference WeaponRackActivatorRef = Self As ObjectReference

ObjectReference PlacedItemRef = WeaponRackActivatorRef.GetLinkedRef()

 

If PlacedItemRef != None ... -> item on the rack,

If PlacedItemRef == None ... -> no item on the rack

 

I simply didn't see the necessity for making a script-generated object reference a hidden property, when it's permanently linked to the activator (as long as it is on the rack, but that's everything that counts) and therefore cannot get lost: that's what I call savegame bloat. I had a detailed look at the OnTriggerLeave events with debug infos added, and the results confirm that the link between the activator and the item that was placed on it is already resolved when this event fires. That is, the engine unlinks the item as soon as it is grabbed by the player.

 

 

EDIT:

It's back in the script now as "PlayersDroppedWepon" (and may be renamed, if absolutely necessary, but read on).

Please keep me up to date of your Hearthfires findings.

 

EDIT2:

(1) I just checked Beth's weapon rack script versions and they indicate that this Hearthfires script won't work as expected: "PlayersDroppedWeapon" is NOT reset when the item is grabbed from the rack! Grabbing the weapon is not registered by the activator, because it is disabled at this point (if the scripts work properly). It fires an OnTriggerLeave event, which is handled by the trigger script, but this does nothing except for re-enabling the activator (and even this did not work properly, because they forgot to make that script multi-threading safe, but that's a different story). The new script versions do the same, so "PlayersDroppedWeapon" will always hold an item reference when there has been an item on the rack at least once. The new script versions have a property now that gets properly updated (but it's in fact a different variable).

(2) In addition, this Hearthfires script does obviously nothing else than adapting the activator's enable state to the trigger's enable state. Though, the enabling process is already fully integrated in the weapon rack scripts (it also was in the old scripts), and the disabling procedure has been added to the new scripts (I have been explaining this partial omission in one of my previous posts). The disabling procedure will take place on cell attach, just like in the Hearthfires script above, but this should work for all activators, not only for the Hearthfires ones. Therefore, I propose to omit the weapon rack handling from the above script entirely.

Link to comment
Share on other sites

hey, sclerocephalus,

 

i have a few bugs to burn on my steam wallet, i never gave a gift through steam; but if you want, i could send you a hearthfire code. do you know what i would have to do for that?

 

i just got it myself yesterday, it was on sale for 2,5 €. sadly it will be back to 5€, but i thought it might be worth it, considering the hazzle you go through to get this mess sorted out.

 

btw: i feel bad for you Arthmoor, so, uhm. is there some way i could contribute without me having to get a credit card?

do you still lack those New Vegas DLC?

 

:-)

 

edit: ok, they are all still on sale. if it's ok for you, let me know your steam account details (PM will suffice), i'd really like to do some good to you today :-)

Link to comment
Share on other sites

Some updates (more bugs, but also more solutions):

 

I have been testing the racks very extensively during the last couple of days. There were still too many glitches for my taste, so I have loaded the scripts with debugger notes to find out how the racks exactly work:

 

(1) What items can activate a rack?

It's half Tamriel ... the player, any NPC passing by, any loose clutter thrown on it, even nearby furniture with too large a collision box and, last but not least, an item placed on an adjacent rack! This is the reason for one of the most annoying glitches: weapons overlapping with the trigger volume of an adjacent rack will make that rack inoperative because it receives an OnTriggerEnter event when the weapon on the other rack is placed. Though, it's not only the final position of a weapon on a rack that's causing this glitch; it's predominantly the MoveToNode command (and how it works) which makes adjacent racks inoperative.

 

A good place to test this are the three red plaques mounted on a wall in Honeyside: take a large weapon, such as an ebony battleaxe, or, even better, one of the new Falmer staves, and place it on the uppermost rack. Watch as the invisible redguard performs his sabre dance in front of you until the item is safe on its rack. Until it is placed, ALL THREE racks have received multiple OnTriggerEnter and OnTriggerLeave events, because the weapon swings through them, and in the end, at least one of the two unoccupied racks stays inactive. It does not matter that the weapon's motion type was set to "all physic interaction disabled" before it was moved to its node: my tests confirm that the trigger events fire anyway! Another fine example are the CoA ("three-in-one") racks: when fully loaded with two swords and a shield, the shield rack would stay inactive most of the time after the shield was grabbed, because both swords are inside its trigger volume. Likewise, the shields extend into the trigger volume of the adjacent plaques on both sides.

 

To handle this, Beth did let the left and right plaques of the CoA rack ignore armor, so the trigger events would be skipped when fired by moving a shield onto the shield plaque, but this was entirely insufficient. They should also have set up the shield plaque to ignore weapons, and they didn't care about the other racks at all. This script tried helplessly to find out whether its linked activator should be disabled or not and failed most of the time. Moreover, the sheer amount of trigger events firing while placing a single weapon demanded too much of the trigger script, and it reported wrong properties for specific racks on the log - appearingly a multi-threading issue. Therefore, the first thing to do was to move all the code in the events into separate functions (functions are safe, but events are apparently not).

 

The fix to this was very simple, since there is always one instance who knows exactly whether an item has been placed on a specific rack: it's the activator itself. After successfully completing an item placement, it will disable itself now, and because this is what all the handling of the OnTriggerEnter event was actually aimed at, it became entirely superfluous and I have deleted it. This constellation has been working perfectly during the last two days and it passed all stress tests: a staff placed horizontally on a five-slot wooden rack (on a node added specifically for this purpose) and clipping through all of their trigger volumes left all racks active except for the one on which it was actually placed.

 

Now, all left to do is to make the OnTriggerLeave event do what it is supposed to.

 

(2) At which time in the process does the player item get linked to and unlinked from the rack ?

Never! The sad truth is that the starting item gets never unlinked and that the player item does never have any "true relationship" with the rack (forget what I said previously; I have been mixing up some hexcodes in the evaluation of the logs). This also means that there's no way to find out retroactively which item (if not the starting item) is on a rack, unless its reference is stored in a script property and gets updated each time an item is grabbed from or put on a rack. Since the OnTriggerLeave event is unable to work properly when it can't compare the item that triggered the event with the item that is/was on the rack, I had to add this property back in, but as a modified version which is properly updated (and renaming this to match up with the Hearthfires script is not a big deal, as Arthmoor expected).

 

THIS: http://www.afkmods.com/index.php?/gallery/image/1093-after-returning-to-hjerim-2/

has nothing to do with persisitent references, but IS ANOTHER BUG (it's a pity since it would have been a good explanation for the ebony blade problem, but it isn't, unfortunately). This happens because the starting item is never unlinked from the rack on which it was originally placed and because Beth's activator script has been set up to handle the starting item on every cell attach. Obviously, they simply forgot to skip this evantually and all they could do is to check whether the starting item is at least in the same cell as the rack, so it's not quantum travelling across the country. The items are still moved back to their original place though when they are still in the same cell (that's probably also the reason why they did put only crap items on those racks, irrespective of the player's level, as these would not likely be used by anyone to decorate his home ...).

 

I have solved this by adding a bool property, which is set true when the OnTriggerLeave event detects that the starting item has been grabbed (which it does now reliably), and in all future cell attach events, the handling of the starting item will be skipped (this possibly doesn't work retroactively, though).

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