Overhauling the weapon rack scripts

[Sclerocephalus]

I check the result of returns from native functions against None. So, you'd still get the log entry, but nothing should happen....

 

Nothing happening is the problem here.

 

The script names (WeaponRackTriggerScript & WeaponRackActivateScript) have never been changed, and I have never been using any empty returns either.

[tyrel68]

i just laugh cause arathmoor was askig where all the non values bugs were popping up, most likely just were hidden XD

[DayDreamer]

script names (WeaponRackTriggerScript & WeaponRackActivateScript) have never been changed, and I have never been using any empty returns either.

OK, I see that the main difference between 3.0 and 3.1 is the use of OnUpdate().

 

Added an unused variable TriggerScript in InitActivator(). Was it an oversight?

 

Also, as you moved the code from ...TriggerScript.OnLoad() to  ...ActivateScript, you lost a couple of tests:

 

PlacedItemiInit == False

player.GetParentCell() == Self.GetParentCell()

 

Finally, since OnCellAttach is always run before OnLoad or OnCellLoad, probably can move some of these to that timing. Then might not need to check both.

 

I've found the OnLoad is very very close after OnCellAttach. Basically, if you have any calls to another script, the script scheduler syncs with framerate (1/60 second) and that's enough time to load all the graphics anyway.

[DayDreamer]

Separately, I'm worried about the new state Inactive. There's no default state specified. I've never seen code that implemented just a few events like that, without another state containing those events.

 

My suggestion would be to lose the state. Just set a new property Inactive instead, and test for it at the top of each event.

[DayDreamer]

Then something must have regressed in the beta scripts.

Sorry, I tried reproducing with the latest on a save from 1.3.3c -- and all the weapons in Warmaidens stayed on the walls. Or at least the ones I could see. I thought I heard a drop, but there's nothing in the logs:

[10/19/2013 - 04:12:28PM] Cannot open store for class "dlc1scwispwallscript", missing file?
[10/19/2013 - 04:12:28PM] Cannot open store for class "DLC2BenthicLurkerFXSCRIPT", missing file?
[10/19/2013 - 04:12:31PM] VM is freezing...
[10/19/2013 - 04:12:31PM] VM is frozen
[10/19/2013 - 04:12:31PM] Reverting game...
[10/19/2013 - 04:12:41PM] Loading game...
[10/19/2013 - 04:12:41PM] warning: Variable ::USKPDB02VictimsMarker_var on script QF_DB02_0001EA51 loaded from save not found within the actual object. This variable will be skipped.
[10/19/2013 - 04:12:41PM] warning: Variable ::Retro103_var on script UHFP_VersionTrackingPlayerAliasScript loaded from save not found within the actual object. This variable will be skipped.
[10/19/2013 - 04:12:41PM] warning: Variable ::Retro110_var on script UHFP_VersionTrackingPlayerAliasScript loaded from save not found within the actual object. This variable will be skipped.
[10/19/2013 - 04:12:41PM] warning: Variable ::Retro111_var on script UHFP_VersionTrackingPlayerAliasScript loaded from save not found within the actual object. This variable will be skipped.
[10/19/2013 - 04:12:41PM] warning: Variable tourDriver on script tourcartsystemscript loaded from save not found within the actual object. This variable will be skipped.
[10/19/2013 - 04:12:42PM] VM is thawing...
[10/19/2013 - 04:12:42PM] UBG20MaintQuestPlayerAliasScript OnPlayerLoadGame
[10/19/2013 - 04:12:42PM] UBG20MaintQuestPlayerAliasScript Maintenance
[10/19/2013 - 04:12:42PM] UBG20MaintQuestPlayerAliasScript SKSE installed, release 44
[10/19/2013 - 04:12:42PM] [_SPLSkyUIConfig <_SPLSKConfigQuest (1300388D)>] INITIALIZED
[10/19/2013 - 04:12:42PM] UHFP 1.1.2 Retroactive Updates Complete
[10/19/2013 - 04:12:43PM] UHFP 2.0.0 Retroactive Updates Complete
[10/19/2013 - 04:12:43PM] InitWidgetLoader()
[10/19/2013 - 04:12:43PM] UDBP 1.0.5 Retroactive Updates Complete
[10/19/2013 - 04:12:43PM] UDGP 1.2.4 Retroactive Updates Complete
[10/19/2013 - 04:12:43PM] UDGP 2.0.0 Retroactive Updates Complete
[10/19/2013 - 04:12:43PM] USKP 2.0.0 Retroactive Updates Complete
[10/19/2013 - 04:13:33PM] VM is freezing...
[10/19/2013 - 04:13:33PM] VM is frozen
[10/19/2013 - 04:13:33PM] Saving game...
[10/19/2013 - 04:13:33PM] VM is thawing...
[10/19/2013 - 04:13:52PM] [_SPLSkyUIConfig <_SPLSKConfigQuest (1300388D)>]: Registered Splash of Rain at MCM.
[10/19/2013 - 04:15:03PM] VM is freezing...
[10/19/2013 - 04:15:03PM] VM is frozen

[Sclerocephalus]

There's no default state specified. I've never seen code that implemented just a few events like that, without another state containing those events.

 

Not true. There always is an "empty state". See the state reference on the CK Wiki.

[DayDreamer]

Not true. There always is an "empty state". See the state reference on the CK Wiki.

What I've personally seen is not true? My eyes deceived me?

 

I've read the state reference, and just read it again, and the 2 supplements -- States(Papyrus) and Using States in Papyrus -- and there's nothing about default state as empty. But that is neither here nor there. I think the design is flawed and hard to make backward and forward compatible.

 

Anyway, I've tried entering and leaving Warmaiden's repeatedly. I see the placed weapons flicker (the update timing is too long), but they do stay on the walls for me. So I'll leave it to somebody else to debug.

[Sclerocephalus]

Added an unused variable TriggerScript in InitActivator(). Was it an oversight?

 

Yes.

 

Finally, since OnCellAttach is always run before OnLoad or OnCellLoad, probably can move some of these to that timing. Then might not need to check both.

 

No, I need them both.

 

Consider the Hearthfires homes: when the player constructs a rack at the workbench, this rack is immediately enabled (i.e. while the player is in the same cell). In all other player homes, new items are never enabled while the player is in that cell. You have to buy the decorations while your off (i.e. from a yarl's steward or a merchant) and although they are immediately enabled when you buy them, you can't see them unless you actually return to your home.

 

Thus, for a weapon rack, we have to discern two cases:

(1) Racks acquired with the home decorations in non-HF homes:

Since the scripts react to an OnCellAttach() event, the racks can be used immediately after purchase. This is simply because the player has to return to that cell, which triggers an OnCellAttach event and the scripts start running.

(2) Racks in HF homes:

The racks are there from the beginning, but they are not enabled until actually constructed at the workbench. They receive an OnCellAttach event  just like all other objects in the cell when the player enters, but they don't handle it, because they are disabled. There was no event in the scripts to react on being loaded (because, as you correctly said, there usually is no need to handle the same topics in both events) and therefore, they were entirely inoperative. To make them work, the player had to leave the cell and return (for an OnCellAttach event to trigger).

 

Some part of what was added after v2.6, and everything that has been changed in v3.1 was only to make the Hearthfires racks usable immediately after their construction. This required an OnLoad event on the trigger script. Note that this could not be done from an OnLoad event on the activator script, because the activator cannot be enable parented (this would make the activator script stop working). Thus, when a rack is enabled, only the trigger is enabled (and receives an OnLoad event), while the activator stays disabled until it runs its initialization procedure where it checks for the enable state of the trigger and then enables itself (or even stays disabled when an item is already placed on the rack).

 

In v3.0, this was done in a rather simple way, by calling the activator script's InitActivator() function directly from the OnLoad event of the trigger. This turned out to be rather problematic though, for two reasons:

(1) The trigger script would become temporarily stuck in its OnLoad event, while waiting for InitActivator() to return. This could be for too long a time, because pre-placed items are handled from the InitActivator() function, and their handling requires to call the trigger script again.

(2) To prevent two instances of the InitActivator() function from running at the same time (one called from the OnLoad event on the trigger script and another from the OnCellAttach event of the activator script), I somehow had to discern an OnLoad event that fires after an OnCellAttach event in a HF home from any other OnLoad event, and to do this, I checked for the player being in the same cell (which was completely useless though, because the player is always in the same cell when an activator script in an interior cell starts running) and for PlacedItemInit on the activator script (which isn't unambiguous either). In the end, I had two instances of InitActivator() running most of the time anyway and the results (while unexpected) were rather detrimental. This is explained in detail in a previous post.

 

Therefore, v3.1 went one step further and controls the initialization procedure of the activator now entirely from the trigger script. To prevent two instances of InitActivator() from running, both OnLoad and OnCellAttach will register the activator for a single update. Single update registrations do not stack, but cancel any previous registrations and therefore, the activator only receives one event when the update time is chosen sufficiently long for the second registration to be carried out before the first event fires on the activator script. This has been tested extensively and works pretty well. In the end, I have chosen a somewhat longer delay than actually needed, which gives the additional benefit of reducing the workload on the engine. This should be most evident in mods that fill player homes with weapon racks to the brim, as now the activator scripts will start running when the trigger scripts have already completed their tasks.

 

 

Also, as you moved the code from ...TriggerScript.OnLoad() to  ...ActivateScript, you lost a couple of tests:

 

PlacedItemiInit == False

player.GetParentCell() == Self.GetParentCell()

 

They are not needed in v3.1 (and moreover, were rather useless even in v3.0). This is explained above.

[Sclerocephalus]

What I've personally seen is not true? My eyes deceived me?

 

I've read the state reference, and just read it again, and the 2 supplements -- States(Papyrus) and Using States in Papyrus -- and there's nothing about default state as empty. But that is neither here nor there. I think the design is flawed and hard to make backward and forward compatible.

 

Anyway, I've tried entering and leaving Warmaiden's repeatedly. I see the placed weapons flicker (the update timing is too long), but they do stay on the walls for me. So I'll leave it to somebody else to debug.

 

From the CK Wiki:

 

"Any function or event defined outside of a state block is said to be in the "empty state". This is the version of the function that is used when the script is not in any state, or when the current state does not implement an override for a function."

 

This can be taken literally, as this is exactly how papyrus works. Anything that is not in one of a number of defined states is considered as being (not only: "said to be") in the empty state. You may define a custom state to include all those events or leave them formally without a state; the result will be the same.

 

BTW, Beth has been using states in this manner quite excessively, and many of these scripts are working flawlessly.

 

 

EDIT:

We're obviously disagreeing on the script states, but  what I said was in no way meant to be offensive. I have been testing v3.1 for two full days before uploading, to make sure that the scripts run as expected. Two pages or so back in this thread, I have been posting several logs from my debugger versions of the scripts, and they are confirming this, as also do the logs posted by NightStar. The trigger script also contains a single event in a "single state", and has been working with it as expected since USKP 1.3.3.

 

Well, the flickering Weapons escaped me entirely, but my machine is not the fastest anymore.

[Sclerocephalus]

Anyway, I've tried entering and leaving Warmaiden's repeatedly. I see the placed weapons flicker (the update timing is too long), but they do stay on the walls for me. So I'll leave it to somebody else to debug.

 

The update time may be reduced to 0.2s while still being on the safe side, but this will cancel the added benefit. There were too many people to ignore complaining about weapon rack script error messages that were apparently caused by corrupted stacks, even if this problem is largely mod-related.

[Arthmoor]

Sorry, I tried reproducing with the latest on a save from 1.3.3c -- and all the weapons in Warmaidens stayed on the walls. Or at least the ones I could see. I thought I heard a drop, but there's nothing in the logs:

Trust me, it's there. 3 of us have now separately verified it in the same 3 locations. It's not logging anything when it happens, so I'll drop the debug versions of the scripts in and see what happens.

 

Make sure you're checking with the beta that was just updated on the 17th since it happened after the first beta.

[Arthmoor]

Threw in the debug copies of rack overhaul 3.1. No messages are thrown to the logs, yet Riverwood, Warmaidens, and Dawnstar's White Hall are still dropping objects to the floor when they weren't with the 3.0 cut that was in the previous beta.

[Arthmoor]

Triple post time! Just confirmed by reinstalling the 3.0 overhaul scripts that Riverwood, Warmaidens, and Dawnstar are back to operating normally.

 

Then put 3.1 back in, reloaded the same save, went to the same places, and all 3 failed again.

 

The retesting I did was in my clean USKP-only install so there was no chance of contamination from outside elements at all. Just Skyrim.esm, Update.esm, and the USKP.

 

Guess it's time to fire up Tortoise and see what changed between versions.

 

Diff from the activator script:

--- C:/Skyrim/Mods/USKP/Sound/weaponrackactivatescript.psc    Sat Oct 19 17:10:37 2013
+++ C:/Skyrim/Mods/USKP/Sound/WeaponRackActivateScript (2).psc    Fri Oct 11 22:00:46 2013
@@ -69,14 +69,40 @@ Weapon Property MG07StaffOfMagnus Auto
 
 ;----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
-Event OnCellAttach()
+State Inactive
 
-    InitActivator()
+    Event OnLoad()
+        If GetLinkedRef (WRackTrigger)
+            GotoState ("")
+        EndIf
+    EndEvent
 
+    Event OnUpdate()
+    EndEvent
+
+    Event OnActivate (ObjectReference TriggerRef)
+    EndEvent
+
+EndState
+
+;----------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
+Event OnLoad()
+
+    If (GetLinkedRef (WRackTrigger) == None)
+        GotoState ("Inactive")
+    EndIf
+
 EndEvent
 
 ;----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
+Event OnUpdate()
+    InitActivator()
+EndEvent
+
+;----------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
 Event OnActivate (ObjectReference TriggerRef)
 
     If (TriggerRef == PlayerRef)
@@ -102,7 +128,10 @@ Function InitActivator()
 
     ObjectReference StartingItem = GetLinkedRef()
     ObjectReference TriggerMarker = GetLinkedRef (WRackTrigger)
+    
+    WeaponRackTriggerScript TriggerScript
 
+
     If TriggerMarker
 
         If TriggerMarker.IsEnabled()
@@ -395,9 +424,9 @@ Function PlaceItem (ObjectReference ItemToPlace, O
     EndIf
 
     Utility.Wait (0.05)
-    ;Makes sure that the trigger has received all OnTrigger events related to the item placement procedure. Out of experience, they may fire with some delay, and the
-    ;last event fired immediately before an item is placed is always an OnLeave event for that item, which, when handled, would be interpreted as the item having been
-    ;grabbed again and the activator would be re-enabled although the rack is not empty.
+    ;Makes sure that the trigger has received all OnTrigger events related to the item placement procedure. Out of experience, they may fire with some delay, and
+    ;the last event firing immediately before an item is placed is always an OnLeave event for that item, which, when handled, would be interpreted as the item
+    ;having been grabbed again and the activator would be re-enabled although the rack is not empty.
     
     PlayersDroppedWeapon = ItemToPlace
     PlacedItemInit = True

 

Diff for the trigger script:

--- C:/Skyrim/Mods/USKP/Sound/weaponracktriggerscript.psc    Sat Oct 19 17:10:37 2013
+++ C:/Skyrim/Mods/USKP/Sound/WeaponRackTriggerScript (2).psc    Fri Oct 11 21:50:53 2013
@@ -11,21 +11,8 @@ Keyword Property WRackActivator Auto
 
 Event OnLoad()
 
-    ObjectReference ActivatorRef = GetLinkedRef (WRackActivator)
+    RegisterActivatorForUpdate()
 
-    WeaponRackActivateScript ActivatorScript
-
-
-    If ActivatorRef
-
-        ActivatorScript = ActivatorRef As WeaponRackActivateScript
-
-        If (ActivatorScript.PlacedItemInit == False) && (Game.GetPlayer().GetParentCell() == Self.GetParentCell())
-            ActivatorScript.InitActivator()
-        EndIf
-
-    EndIf
-
 EndEvent
 
 ;----------------------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -34,6 +21,8 @@ Event OnCellAttach()
 
     GoToState ("")
 
+    RegisterActivatorForUpdate()
+
 EndEvent
 
 ;----------------------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -55,6 +44,18 @@ EndState
 
 ;----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
+Function RegisterActivatorForUpdate()
+
+    ObjectReference ActivatorRef = GetLinkedRef (WRackActivator)
+
+    If ActivatorRef
+        ActivatorRef.RegisterForSingleUpdate (1.0)
+    EndIf
+
+EndFunction
+
+;----------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
 Function UpdateActivatorState (ObjectReference LeavingItem)
 
     Bool PlacedItemInit

[Sclerocephalus]

Threw in the debug copies of rack overhaul 3.1. No messages are thrown to the logs [...]

 

This means that none of the triggers ever received an OnLoad() event (at least none of those in any place you have visited while running your tests), since this is where the user log is opened (they don't print anything on the papyrus log). Which yet again means that all trigger scripts are running on nothing. This also means that you won't find the solution by comparing script versions.

 

One of many small differences between v3.0 and v3.1 is that the activators in v3.1 will do nothing on their own unless triggered by the player or from the trigger script. With v3.0, they still run their initialization on their own (but this can lead to complications, as previously discussed). It could well be that the trigger scripts were not properly working with v3.0 either, and that this has been overlooked because the activators would still run their initialization on their own and handle their pre-placed items as expected (they are handled by the InitActivator() function).

 

Thus, the most important thing to know now is whether the activators are also affected by this issue. Besides that, I also still would like to see some logs. Since I still could not reproduce the issue, I have uploaded a set of very slightly modified debugger versions (v3.1a). First, both scripts will try to open a user log in both their OnLoad and OnCellAttach events (to make sure you'll get a log). Second, handling of the OnUpdate event on the activator script has been suspended (it will still print a message when the event is received, but won't do anything else). Instead, the activator script will run its initialization independenttly, from the OnCellAttach event as in previous versions. This means that the trigger now effectively stops to control the activator. I have a vague idea, which lets me expect that the activator can still communicate with the trigger, but will call another script instance. If so, the logs will record this.

[DayDreamer]

 

Guess it's time to fire up Tortoise and see what changed between versions.

Yeah, already did that on the Mac. A bunch of those are just formatting. Heck, the big comment block has exactly the same words, with only a change in line. I do wish that would be re-formatted at 72 or 80....

 

Anyway, my suggestion was to do away with the state. It's set inside an if and other statements. The threading can interrupt at any point, and we don't know how fast states take effect.

 

Usually, the canonical method would be a simple semaphore instead of the states and OnUpdate:

 

Bool Property Inactive  Auto

 

bool wasInactive = Inactive

Inactive = false

if !wasInactive

...

 

Or whatever. That would keep the code from running twice.

[DayDreamer]

I have a vague idea, which lets me expect that the activator can still communicate with the trigger, but will call another script instance. If so, the logs will record this.

Yeah, well I cannot find the debug scripts. Next time, please leave the debug.trace lines. It's a good programming practice. Just comment them out. I've been using ;.\tdebug.trace -- easy to switch back and forth with a regexp.

[Sclerocephalus]

Yeah, well I cannot find the debug scripts. Next time, please leave the debug.trace lines. It's a good programming practice. Just comment them out. I've been using ;.\tdebug.trace -- easy to switch back and forth with a regexp.

 

I'm never doing that, but I always prepare a copy for debugging. Just ask.

 

You can't download them at the moment, because they are in the "files for fixes" section. Just wait two minutes.

 

Yeah, already did that on the Mac. A bunch of those are just formatting. Heck, the big comment block has exactly the same words, with only a change in line. I do wish that would be re-formatted at 72 or 80....

 

There was a spelling error. Sometimes, I'm picky.

 

Anyway, my suggestion was to do away with the state. It's set inside an if and other statements. The threading can interrupt at any point, and we don't know how fast states take effect.

 

I already got the point that the states appear suspect to you, but they work. I have been doing almost the same in the trigger script, and if that was an issue, the scripts wouldn't have worked from the beginning (see the handling of the OnTriggerLeave event). Out of testing experience for versions 2.5/2.6, the states take effect within less than 0.1 seconds. This is vital for the whole weapon rack stuff to work.

 

 

EDIT:

You can grab the v3.1 debugging versions here (they're not explicitely mentioned on the download page, but they are there):

http://www.afkmods.com/index.php?/files/file/843-extended-racks/

[Arthmoor]

Besides that, I also still would like to see some logs.

There were no logged messages anywhere to show you, or I would have

 

Anyway, grabbed your debug copied and will run them through right now.

[Sclerocephalus]

Will also start another round of testing to see whether I can reproduce the issue myself.

 

 

 

There were no logged messages anywhere to show you, or I would have

 

Yes, I understand that and I know why this happened (as explained above). That's why I have modified the scripts.

[Arthmoor]

Here's the user log (handy - I had no idea these existed)

 

Started with a save in Honeyside - no issues. There haven't been when loading in a player home.

Exited and fast traveled to Riverwood (where I keep getting interrupted by dragons). Weapons fell off with 3.1, stayed put with 3.1a.

Fast traveled to Whiterun, entered Warmaidens. Weapons fell off with 3.1, stayed put with 3.1a.

Exited, fast traveled to the watch tower north of Whiterun. No issues here - there weren't before either.

Fast traveled to Dawnstar, entered Jarl's longhouse. Checked rack in the legion guy's room. Weapons ok with 3.1a, were falling off with 3.1.

 

So it seems as though something you did different has worked?

WeaponRackLog.txt

[Sclerocephalus]

Well, but I didn't change anything noteworthy on the trigger script. I only added an OpenUserLog statement to its OnCellAttach event. And that the modifications on the activator script should make the trigger script work doesn't make much sense either.

 

 

There is a contradictory statement in one of DayDreamer's previous posts:

 

Finally, since OnCellAttach is always run before OnLoad or OnCellLoad, [...]

 

I've found the OnLoad is very very close after OnCellAttach. [...]

 

I wanted to ask him anyway which, in his experience, follows which. In my personal experience, OnLoad always follows OnCellAttach, at least in interior cells (in exterior cells, I have also seen them firing in the opposite order on very few occasions). Now, when I look at that log though, those triggers' OnLoad and OnCellAttach events are completely disordered. Some have OnLoad before OnCellAttach, some have it after OnCellAttach (thus, DayDreamer is always right), and there are also a few with an OnCellAttach event, but no OnLoad event. There's something wrong here.

[Arthmoor]

Don't know what to tell you there. The 3.1a script seems to be doing fine. Perhaps the added overhead of the traces has slowed things down just enough for it to trigger everything properly?

[VaultDuke]

Don't know what to tell you there. The 3.1a script seems to be doing fine. Perhaps the added overhead of the traces has slowed things down just enough for it to trigger everything properly?

 

you know, don't say this too lound.

while i know nothing about scripts and how to fix them; just quietly follow your discussions here: it seems more script problems cropped up in recent months, despite them having behaved fine most of the time before.

 

as i said i have no in depth knowledge, but i hope the explanation is my suspicion number one: those new errors found (you know all this stuff in the papyrus section of the tracker) are rather rare occurences, that before most scripts were silenced simply got overlooked.

 

but i have a dreadfull suspicion number two: the faster the script engine runs because of fixed issues with other scripts that were looping like crazy etc... the more unstable the other scripts become.

i read here about "oncellattach" "oncellload" "has3d" etc... and how one function doesn't work if the other functions proceeded too fast or too slow or what not. and then you would have to rewrite all scripts to put in delays, remove every "oncellsomething" function, that simply works too fast now etc.

more even: maybe it will all break on some users machines that are simply faster than our testing rigs...

 

long story short: i hope you didn't open up a big can of worms here. pandoras box so to speak...

i keep my fingers crossed.

 

carry on, nothing to see here

[Sclerocephalus]

The 3.1a script seems to be doing fine.

 

Sic. Emphasis on "seems".

 

This is because the activator script now operates independently on the trigger script, which obscures that the trigger script is doing strange things. The tests confirm at least, that the activators are working properly, i.e. the scripts are not running on none. This also implies that the activtaor script will find its linked trigger, and it also can access the trigger script: while placing items, it has to set the trigger in another state to prevent it from handling the OnLeave event that fires when the item temporarily loses its 3D as a result of the MoveToNode command, and this works.

 

Your log confirms that some triggers receive OnLoad before OnCellAttach, which means that they still have no parent cell when they already have 3D, and this is most likely the reason why the error messages on the papyrus log list them as running on none. As long as a cell has not attached, there is no way to obtain the reference of any object in that cell, and every attempt at doing so will return none (this also explains why the trigger is unable to find its linked activator at this point). Objects loading before cell attach is actually not expected to ever happen at all, and I have no idea why this happens on your machine nonetheless (it doesn't happen on mine). Maybe a side effect of modern high-end graphics cards which Beth couldn't foresee when they released the game two years ago ?

 

The following is an edited version of your log, which only lists the triggers' OnCellLoad and OnCellAttach events and the activators' OnUpdate events, grouped for the individual racks in the Warmaiden's and listed in the order in which they were printed on the log (while the log may print the messages with some delay, it usually does not modify the order in which they occur):

[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051BB)>]OnLoad : [WeaponRackActivateScript < (001051BC)>] registered for single update.
[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051BB)>]OnCellAttach : [WeaponRackActivateScript < (001051BC)>] registered for single update.
[10/19/2013 - 08:44:05PM] [WeaponRackActivateScript < (001051BC)>]: OnUpdate event received.

[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051B9)>]OnCellAttach : [WeaponRackActivateScript < (001051BA)>] registered for single update.
[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051B9)>]OnLoad : [WeaponRackActivateScript < (001051BA)>] registered for single update.
[10/19/2013 - 08:44:05PM] [WeaponRackActivateScript < (001051BA)>]: OnUpdate event received.

[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051BD)>]OnLoad : [WeaponRackActivateScript < (001051BE)>] registered for single update.
[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051BD)>]OnCellAttach : [WeaponRackActivateScript < (001051BE)>] registered for single update.
[10/19/2013 - 08:44:05PM] [WeaponRackActivateScript < (001051BE)>]: OnUpdate event received.

[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051C6)>]OnCellAttach : [WeaponRackActivateScript < (001051C1)>] registered for single update.
[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051C6)>]OnLoad : [WeaponRackActivateScript < (001051C1)>] registered for single update.
[10/19/2013 - 08:44:05PM] [WeaponRackActivateScript < (001051C1)>]: OnUpdate event received.

[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051C4)>]OnLoad : [WeaponRackActivateScript < (001051C3)>] registered for single update.
[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051C4)>]OnCellAttach : [WeaponRackActivateScript < (001051C3)>] registered for single update.
[10/19/2013 - 08:44:05PM] [WeaponRackActivateScript < (001051C3)>]: OnUpdate event received.

[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051C5)>]OnLoad : [WeaponRackActivateScript < (001051C2)>] registered for single update.
[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051C5)>]OnCellAttach : [WeaponRackActivateScript < (001051C2)>] registered for single update.
[10/19/2013 - 08:44:05PM] [WeaponRackActivateScript < (001051C2)>]: OnUpdate event received.

[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051C9)>]OnLoad : [WeaponRackActivateScript < (001051CA)>] registered for single update.
[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051C9)>]OnCellAttach : [WeaponRackActivateScript < (001051CA)>] registered for single update.
[10/19/2013 - 08:44:05PM] [WeaponRackActivateScript < (001051CA)>]: OnUpdate event received.

[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051CB)>]OnLoad : [WeaponRackActivateScript < (001051CC)>] registered for single update.
[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051CB)>]OnCellAttach : [WeaponRackActivateScript < (001051CC)>] registered for single update.
[10/19/2013 - 08:44:05PM] [WeaponRackActivateScript < (001051CC)>]: OnUpdate event received.

[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051CF)>]OnLoad : [WeaponRackActivateScript < (001051D0)>] registered for single update.
[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051CF)>]OnCellAttach : [WeaponRackActivateScript < (001051D0)>] registered for single update.
[10/19/2013 - 08:44:05PM] [WeaponRackActivateScript < (001051D0)>]: OnUpdate event received.

[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051D1)>]OnCellAttach : [WeaponRackActivateScript < (001051D2)>] registered for single update.
[10/19/2013 - 08:44:04PM] [WeaponRackTriggerSCRIPT < (001051D1)>]OnLoad : [WeaponRackActivateScript < (001051D2)>] registered for single update.
[10/19/2013 - 08:44:05PM] [WeaponRackActivateScript < (001051D2)>]: OnUpdate event received.

For comparison one of my logs (with v3.1 proper; this doesn't matter because the only difference between v3.1 and v3.1a is that v3.1a doesn't handle the OnUpdate event while v3.1 does). Ordering was not necessary:

[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051B9)>]OnCellAttach : [WeaponRackActivateScript < (001051BA)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051BB)>]OnCellAttach : [WeaponRackActivateScript < (001051BC)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051BD)>]OnCellAttach : [WeaponRackActivateScript < (001051BE)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051C4)>]OnCellAttach : [WeaponRackActivateScript < (001051C3)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051C5)>]OnCellAttach : [WeaponRackActivateScript < (001051C2)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051C6)>]OnCellAttach : [WeaponRackActivateScript < (001051C1)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051C9)>]OnCellAttach : [WeaponRackActivateScript < (001051CA)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051CB)>]OnCellAttach : [WeaponRackActivateScript < (001051CC)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051CF)>]OnCellAttach : [WeaponRackActivateScript < (001051D0)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051D1)>]OnCellAttach : [WeaponRackActivateScript < (001051D2)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051B9)>]OnLoad : [WeaponRackActivateScript < (001051BA)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051BB)>]OnLoad : [WeaponRackActivateScript < (001051BC)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051BD)>]OnLoad : [WeaponRackActivateScript < (001051BE)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051C4)>]OnLoad : [WeaponRackActivateScript < (001051C3)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051C5)>]OnLoad : [WeaponRackActivateScript < (001051C2)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051C6)>]OnLoad : [WeaponRackActivateScript < (001051C1)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051C9)>]OnLoad : [WeaponRackActivateScript < (001051CA)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051CB)>]OnLoad : [WeaponRackActivateScript < (001051CC)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051CF)>]OnLoad : [WeaponRackActivateScript < (001051D0)>] registered for single update.
[10/20/2013 - 03:23:56AM] [WeaponRackTriggerSCRIPT < (001051D1)>]OnLoad : [WeaponRackActivateScript < (001051D2)>] registered for single update.
[10/20/2013 - 03:23:57AM] [WeaponRackActivateScript < (001051BE)>]: OnUpdate event received. Starting InitActivator.
[10/20/2013 - 03:23:57AM] [WeaponRackActivateScript < (001051BA)>]: OnUpdate event received. Starting InitActivator.
[10/20/2013 - 03:23:57AM] [WeaponRackActivateScript < (001051BC)>]: OnUpdate event received. Starting InitActivator.
[10/20/2013 - 03:23:57AM] [WeaponRackActivateScript < (001051C1)>]: OnUpdate event received. Starting InitActivator.
[10/20/2013 - 03:23:57AM] [WeaponRackActivateScript < (001051CC)>]: OnUpdate event received. Starting InitActivator.
[10/20/2013 - 03:23:57AM] [WeaponRackActivateScript < (001051C2)>]: OnUpdate event received. Starting InitActivator.
[10/20/2013 - 03:23:57AM] [WeaponRackActivateScript < (001051D0)>]: OnUpdate event received. Starting InitActivator.
[10/20/2013 - 03:23:57AM] [WeaponRackActivateScript < (001051CA)>]: OnUpdate event received. Starting InitActivator.
[10/20/2013 - 03:23:57AM] [WeaponRackActivateScript < (001051D2)>]: OnUpdate event received. Starting InitActivator.
[10/20/2013 - 03:23:57AM] [WeaponRackActivateScript < (001051C3)>]: OnUpdate event received. Starting InitActivator.

I have checked all references in TES5Edit to find out whether there's a relationship between the rack types and their triggers' tendency to load before cell attach, but there isn't. For some reason, the triggers on your computer load and attach arbitrarily.

 

Anyway, since this is the most likely reason for the problems, I will add a check for the parent cell to the trigger's OnLoad event. If none, event handling will be skipped and the activator script will be called from the OnCellAttach event instead. If this doesn't work either, we will have to regress the trigger script to v2.6 (the activator script will stay at v3.0, i.e. with the problem weapon detection implemented, as this obviously doesn't cause any problems) and find a separate solution for the Hearthfires racks.

 

EDIT:

Version 3.2 is available for download now. For testing purposes, just install the mod as is. Since it was conceived as a stand-alone, the esp has everything needed for the scripts to run, irrespective of whether USKP is installed or not. This saves you the trouble of including it in the beta before you can start your test runs.

 

EDIT2:

If I'm right, the scripts will spill the papyrus logs with "Cannot run GetParentCell() on a none object" messages, but this won't have any impact on functionality as it justs aborts the event that should be aborted at this point anyway. In the final, we'll probably have to use the seemingly entirely nonsensical condition check "If Self ..." (sic!).

 

Also, I will be off-line for testing during the next two hours.

[Sclerocephalus]

but i have a dreadfull suspicion number two: the faster the script engine runs because of fixed issues with other scripts that were looping like crazy etc... the more unstable the other scripts become.

 

I have been analyzing competitors' products (incl. structure elucidation and all the stuff) for an international chemical company for 15 years, and in many cases where one product had a superior performance, this was because it was dirty. Same constituents, same impurity profiles, but more of the latter in some than in others. In some fields of application, purity is detrimental to performance ...