Overhauling the weapon rack scripts

[Sclerocephalus]

We have another small issue:

 

Imagine that somebody links an activator to an x-marker, or even worse, links several activators to the same x-marker. This would be misinterpreted as a pre-placed item and moved onto the rack. Moreover though, since all activators are linked to the same x-marker, the marker would be moved on from rack to rack, in the order of the activators running their initialization procedure, and end up on the last rack in the line.

 

All activators would then have the same x-marker reference in PlayersDroppedWeapon, all but one rack would be empty, and all racks would be disabled. There would be no way to restore them, not even the occupied one since nobody can grab an x-marker.

 

Unless the x-marker is unlinked from the activators, there's no way to prevent this from happening since an x-marker has no 3D, and even if the trigger was active, it never would receive an OnTriggerLeave event while the x-marker is moved on from rack to rack.

 

You probably think now that this should actually be impossible, because the x-marker has no 3D and wouldn't pass the 3D check - but it did!

Hearthfires does this with the racks in Honeyside, and once you install it, all racks become inoperative at once. UHFP 2.0 has removed the links, but this wasn't retroactive (as expected). Thus, although UHFP runs a small script to clear the properties on the activator scripts, this doesn't last any longer than until the next cell attach on a running game. During the last couple of days, I have been asked by several people for a lasting solution, but there's not much one can do other than running the rescue script on every cell attach, or starting a new game.

 

Anyway, what I would like to do is to include a check in the InitActivator function that prevents anything unexpected from being handled once and for all. The check we previously had in the trigger script for checking the leaving item should be sufficient:

;				Prevent handling of invalid items that have been linked to the activator mistakenly:		
				If (StartingItem As Weapon) || (StartingItem.HasKeyword (ArmorShield)

Sorry for the inconvenience.

[Sclerocephalus]

If my code fails, your code fails. They are functionally identical

 

Phhhew, ... I saw that "[...] unused blocked racks [...]" note of yours and my only thought was "hopefully, he hasn't ...", so this was important for me to make absolutely sure. I don't want your code to fail! (and even less so if had overlooked an own mistake)

 

Thank you very much.

 

 

Thanks muchly. Now where are those meshes?

 

It's only 2:00 AM in the morning here and I won't be going to bed before 9:00AM (not after that adrenaline rush from a while ago, and anyway, I had a good long nap on Monday ...), so .. well, expect that I upload them within the next few hours.

[DayDreamer]

We have another small issue:

 

You probably think now that this should actually be impossible, because the x-marker has no 3D and wouldn't pass the 3D check - but it did!

We all know about the Xmarker thing.

Since I've never played Hearthfires, obviously I haven't checked this. But surely you and Arthmoor did before release....

 

Hearthfires does this with the racks in Honeyside, and once you install it, all racks become inoperative at once. UHFP 2.0 has removed the links, but this wasn't retroactive (as expected).

Which you didn't notice during testing?

What wasn't retroactive? I'd expect removal of the GetLinkedRef() was certainly retroactive, otherwise a lot of stuff wouldn't be working today.

Are you saying the removal of the pointers wasn't retroactive? Why would it be. That's what retro-scripts are for....

 

Thus, although UHFP runs a small script to clear the properties on the activator scripts, this doesn't last any longer than until the next cell attach on a running game.

That doesn't make sense either. Could you point to the script involved?

 

During the last couple of days, I have been asked by several people for a lasting solution, but there's not much one can do other than running the rescue script on every cell attach, or starting a new game.

 

Anyway, what I would like to do is to include a check in the InitActivator function that prevents anything unexpected from being handled once and for all. The check we previously had in the trigger script for checking the leaving item should be sufficient:

;				Prevent handling of invalid items that have been linked to the activator mistakenly:		
				If (StartingItem As Weapon) || (StartingItem.HasKeyword (ArmorShield)

Sorry for the inconvenience.

Seems kinda ad hoc. Will it allow brooms and rakes to be racked?

The lasting solution, of course, would have been to run my scripts. Since I clear the pointers OnReset and OnCellDetach. But wait, don't I remember a certain somebody saying none of that was necessary???

[Sclerocephalus]

We all know about the Xmarker thing.

Since I've never played Hearthfires, obviously I haven't checked this. But surely you and Arthmoor did before release....

 

I wasn't sure whether you did. But you really should start playing Hearthfires. Big fun - in a macabre sense ...

 

 

Which you didn't notice during testing?

 

I was the first one to report it. Soon after installing Hearthfires for the first time, they showed up in my logs.

 

 

Seems kinda ad hoc. Will it allow brooms and rakes to be racked?

 

It covers the scope of items allowed on vanilla racks (and thus is appropriate for USKP).

Well, personally, I wouldn't mind to include other items, but I don't believe that Arthmoor's going to accept it. Perhaps you can convince him ?

 

 

The lasting solution, of course, would have been to run my scripts. Since I clear the pointers OnReset and OnCellDetach. But wait, don't I remember a certain somebody saying none of that was necessary???

 

I still do, because anything linked to the racks is not only persistent but had its link set up in the CK, and you cannot get rid of those by a script command. Same with the starting item: the link remains forever and you still get the reference when you check it even when the item has long gone.

 

The x-marker is linked just like a starting item: simple link with no keyword, and since we have to handle the starting items on every cell attach (if they were real weapons they would fall off otherwise ...) ...

 

Nonetheless, perhaps we can talk about this some day (I would appreciate it).

[DayDreamer]

I was the first one to report it. Soon after installing Hearthfires for the first time, they showed up in my logs.

Obviously, you misunderstood my question. It wasn't "who first noticed the original problem" -- it was who didn't notice that 2.0.0 wasn't fixing the problem during the extensive testing of the patch. Because whomever wrote and tested that patch during one of the 4 beta releases would have known.

OK, I noticed that you didn't answer some of my other questions. Like that actual problem with the fix....

 

 

What wasn't retroactive? I'd expect removal of the GetLinkedRef() was certainly retroactive, otherwise a lot of stuff wouldn't be working today.

Are you saying the removal of the pointers wasn't retroactive? Why would it be. That's what retro-scripts are for....

So, I've taken a look. And see a badly written UHFPHoneysideActivatorScript quest script that should be attached to a quest of some sort.

 

Arthmoor, What quest is that attached to? And why wasn't it done in the retro-script?

I'm looking at the list of Quests, the only new ones all start with UHFP, and don't see one that has this script attached.

Also, I see the BYOHdivertPrefabsScript was slightly altered. But TES5Edit won't tell me who uses this script. I've found the rack uses in Honeyside, but there should be bookshelf uses somewhere? And maybe other racks? How do I search this?

[Sclerocephalus]

Obviously, you misunderstood my question. It wasn't "who first noticed the original problem" -- it was who didn't notice that 2.0.0 wasn't fixing the problem during the extensive testing of the patch. Because whomever wrote and tested that patch during one of the 4 beta releases would have known.

OK, I noticed that you didn't answer some of my other questions. Like that actual problem with the fix....

 

Yes, I did misunderstand your question. In such cases, please don't worry and ask again; eventually I'll get the point (as already mentioned, this happens occasionally, but doesn't have any particular meaning - usually, it's because I'm doing things while I'm lost in thoughts about entirely different things), so please bear with me.

 

I asked Arthmoor to include a little fix to hook up to his retro quest. A couple of days ago, I was asked by somebody whether this fix was in the beta, then had to ask Arthmoor myself (because I couldn't find it in the beta I was running). He said it was included, to his knowledge, but also that there had been other stuff included in the meantime and did upload a new UHFP 2.0 beta version to have a look at. Shortly after, I got another message from him, asking for the mesh fixes, and Taleden reminded me of the script update. The latter stuff had priority, and that alone turned out to be almost too much for the remaining time, so I never had another look at the UHFP. If the script is really not in though, it's not a big loss, because there's no way to permanently fix this from an external script anyway; this would have to be done from the propsed check in "WeaponRackActivateScript". On the other hand, there always is a disclaimer on the beta download pages which is hard to miss and tells people that they shouldn't run it on saves they intend to keep. Thus, this guy would actually do best to start a new game which would fix it for him (since the links are removed by UHFP).

 

So, I've taken a look. And see a badly written UHFPHoneysideActivatorScript quest script that should be attached to a quest of some sort.

 

Yep. When I have no idea which format he prefers for specific fixes, I give him something like a "draft" (or "proposal") with a few written details (this time in a message), and if it takes him too much time (I actually expected it would), he usually gets back to me after a couple of days to tell me how he would like it to be done, and only then I start to finalize everything. This time he didn't and I pretty much forgot about it because there was a lot of other stuff to do.

 

 

Also, I see the BYOHdivertPrefabsScript was slightly altered. But TES5Edit won't tell me who uses this script. I've found the rack uses in Honeyside, but there should be bookshelf uses somewhere? And maybe other racks? How do I search this?

 

The modification to the BYOHDivertPrefabsScript is explained here (to explain my proposal for modification, this post contains also a brief description of what the script does and who's using it):

http://www.afkmods.com/index.php?/topic/3669-overhauling-the-weapon-rack-scripts/?p=147734

[DayDreamer]

Tomorrow I'll make an Unofficial Unofficial patch for Honeyside. Have to find out whether there are any other places that bad script is used, too.

[Sclerocephalus]

Tomorrow I'll make an Unofficial Unofficial patch for Honeyside. Have to find out whether there are any other places that bad script is used, too.

 

BYOHDivertPrefabsScript is otherwise only used in Breezehome, but there, the activators have not been edited. Thus, it affects only Honeyside.

If you really get this to work, you're my hero.

 

In the meantime, I have some goodies here (also packed in some extras for connoisseurs):

 

v3.5.7z

 

 

EDIT:

I also have some very interesting logs, but more on that later.

[Arthmoor]

So yeah. I forgot to hook up that script to anything in the UHFP. I'm pretty sure than when I went back to Honeyside and wasn't assailed by log messages saying there were problems, I forgot to provide a quest for it or to merge it with the retro script.

 

Honeyside SEEMS to be working fine for me though without it. Is the script that absolutely necessary?

[Sclerocephalus]

So yeah. I forgot to hook up that script to anything in the UHFP. I'm pretty sure than when I went back to Honeyside and wasn't assailed by log messages saying there were problems, I forgot to provide a quest for it or to merge it with the retro script.

 

Honeyside SEEMS to be working fine for me though without it. Is the script that absolutely necessary?

 

As long as your racks are occupied, nothing's going to happen. When you take an item from a rack, then replace it before leaving the cell, all is fine either (when a rack is occupied on cell attach, the activator won't make any stupid things). However, when you leave it empty, then leave the cell, it will be inoperative upon return.

 

Don't worry about the script, this would have cured matters only once. If somebody had forgotten then to fill up his racks, they would have gotten unresponsive again.

 

PS:

Don't miss the download. Those new meshes are crazy!

[Arthmoor]

Odd, because I have one empty rack in Honeyside which is readily able to take items and always has been. Maybe only an issue for new games started with HF installed?

[Sclerocephalus]

Which one ? Those on the first floor are not affected, only those in the basement.

[Arthmoor]

Basement area, by the enchanter's table. Bottom one of the set of 3.

[Sclerocephalus]

Seems kinda ad hoc. Will it allow brooms and rakes to be racked?

 

As for brooms and shovels: Why not carrying this check out in a small function, so any rack with extended functionality may extend WeaponRackActivateScript and only has to override this function (and the item handling functions of course) ? Given the similarity of the various rack types, even mod-added ones, that is probably the best solution anyway.

 

Like so:

If StartingItem && StartingItem.IsEnabled() && ItemAllowed (StartingItem)

---------

Bool Function ItemAllowed (ObjectReference AnyItemRef)

;Utility function to perform a quick check on whether an item is allowed on the racks at all 
;(to prevent handling of invalid items that have been linked to an activator mistakenly)		


	If (AnyItemRef.GetBaseObject() As Weapon) || AnyItemRef.HasKeyword (ArmorShield)
		Return True
	Else
		Return False
	EndIf

EndFunction

Another proposal for a small improvement:

 

In the OnLoad event of the trigger script, add "GetParentCell().IsInterior()" to the checks. Since the only situation where we really need the OnLoad event to start the activator's initialization procedure never occurs in an exterior, this might save a little performance.

[Sclerocephalus]

Which one ? Those on the first floor are not affected, only those in the basement.

 

Strange. Will have a look.

[DayDreamer]

Don't worry about the script, this would have cured matters only once. If somebody had forgotten then to fill up his racks, they would have gotten unresponsive again.

Please indicate a factual basis for this statement.

[Sclerocephalus]

In the latest tests with the new triggers, all empty racks had TOC = 0, and all occupied racks TOC = 1. No exceptions. I had previously tweaked the havok "radius" of the shield plaque trigger, and that was obviously the culprit because all problems were gone afterwards.

 

Then, I did some tests with "TOC settling", i.e. I ran a loop in 0.05 second intervals (100 x), starting immediately after an item had been grabbed from a rack while the trigger was still active and the activator disabled. During this time, Serana was busily walking forth and back in front of the racks, and I tried busily to interfere by jumping up and down in front of CoA racks and single-weapon plaques. Even when I went really close though, the result was always the same: the TOC was zero immediately after grabbing an item from a rack and remained zero throughout the test (I have the log attached). That's actually not surprising because the player and all NPCs have a capsule shape collision box in front of them which is essentially empty. Causing an interference would require to hit the rack with a weapon or your fists, but this qualifies as a deliberate act and would also never happen with NPCs. Even then however, there is no way to interfere so as to provoke a wrong TOC reading when the item is grabbed, because the trigger is too fast, and the OnTriggerLeave event will be essentially handled before you even can box at or hit the rack for the first time.

 

Thus, there's obviously no need to wait for the TOC to settle when an item is grabbed, and I threw this check out. Subsequent tests were all run with the following UpdateActivatorState function:

Function UpdateActivatorState (ObjectReference LeavingItem)

;This function does the handling of valid OnTriggerLeave events (i.e. OnTriggerLeave events received while the trigger is in the empty state). Valid OnLeave events
;are attributed to items that have been grabbed from the rack. It updates the properties on the activator script, i.e. resets PlayersDroppedWeapon to "none" and marks
;any pre-placed items as grabbed.


	Int TOC = GetTriggerObjectCount()

	ObjectReference ActivatorRef = GetLinkedRef (WRackActivator)

	WeaponRackActivateScript ActivatorScript = (ActivatorRef As WeaponRackActivateScript)


	If (TOC == 0) 

		ActivatorScript.PlayersDroppedWeapon = None
		ActivatorScript.PlacedItemInit = True

		GoToState ("ActivatorBusy")
		ActivatorRef.Enable()

		Debug.TraceUser ("WeaponRackLog", ActivatorRef + " enabled; Trigger in 'ActivatorBusy' state; TOC = " + TOC)

	Else
		Debug.TraceUser ("WeaponRackLog", ActivatorRef + " remains disabled; TOC = " + TOC)
	EndIf

EndFunction 

And this worked. No failures so far.

 

Nonetheless, while unimportant when grabbing an item, the "TOC settling break" in the InitActivator() function should be left in. This is because this runs very early, around cell attach, and there are many cells where "havok explosions" (i.e. uncontrollably havoking items) immediately after entering are quite common and often have unique results (no, that's not photoshopped):

http://www.afkmods.com/index.php?/gallery/image/799-mavens-new-necklace-the-result-of-a-havok-explosion/

Thus, risk of interferences is significantly higher during the initialization procedure.

 

Log_TOCSettling.7z

 

[DayDreamer]

BYOHDivertPrefabsScript is otherwise only used in Breezehome, but there, the activators have not been edited. Thus, it affects only Honeyside.

If you really get this to work, you're my hero.

Found the bookshelves in Breezehome. You broke them by changing the script to use WRackTrigger. They have no WRackTrigger.

[Sclerocephalus]

Found the bookshelves in Breezehome. You broke them by changing the script to use WRackTrigger. They have no WRackTrigger.

 

The script is attached individually to each reference. The racks have the WRackTrigger property initialized with the WRackTrigger keyword, but the bookshelves have not. They have a "null" keyword in this property instead. Checking the link with a "null" keyword evaluates to the same result as the commented out line.

 

 

EDIT:

For info: default corresponds to none:

http://www.creationkit.com/GetLinkedRef_-_ObjectReference

[DayDreamer]

The script is attached individually to each reference. The racks have the WRackTrigger property initialized with the WRackTrigger keyword, but the bookshelves have not. They have a "null" keyword in this property instead. Checking the link with a "null" keyword evaluates to the same result as the commented out line.

Did you test it? There is no evidence (in TES5Edit) that the bookshelves were ever initialized with a WRackTrigger property that could be left uninitialized. Please don't depend on obscurity. There was no efficiency to be gained here. And anything non-obvious should always be documented thoroughly.

 

I've written a better fix, not dependent on uninitialized properties. It involved merely moving the lines into their respective if blocks. What a concept -- locality of reference....

 

Also, I'm finding a bunch of "fixes" in Honeyside that are just nonsense. Yes, there were incorrect scripts assigned to activators. But the answer wasn't deleting them. The triggers have the correct scripts and links, so the activators should too!

 

I'll have a set of replacements done later today. Between thunderstorms.

[Sclerocephalus]

Please indicate a factual basis for this statement.

 

That's because of how WeaponRackActivateScript and the script I am referring to work. My script does only reset properties on the activator script; in the Honeyside case, it would specifically check for each rack whether the base object of PlayersDroppedWeapon is an x-marker and, if true, reset PlayersDroppedWeapon to "none" and PlacedItemInit to "false". Running this from anywhere when UHFP loads has no effect unless the offending link has been removed (but the chances for this to happen are bad within a running game). Otherwise, the activators will check their link when they run their initialization procedure on next load/cell attach, will find the x-markers and get stuck again.

[Sclerocephalus]

Did you test it? There is no evidence (in TES5Edit) that the bookshelves were ever initialized with a WRackTrigger property that could be left uninitialized. Please don't depend on obscurity. There was no efficiency to be gained here. And anything non-obvious should always be documented thoroughly.

 

That's something that is better checked directly in the CK, because TES5Edit does only show you what's in the esp. When the esp does not initialize a property, it doesn't show you anything, but the CK will.

 

Also, I'm finding a bunch of "fixes" in Honeyside that are just nonsense. Yes, there were incorrect scripts assigned to activators. But the answer wasn't deleting them. The triggers have the correct scripts and links, so the activators should too!

 

Activators never had incorrect scripts running on them; at least this has not yet been documented, but we have certainly never touched any scripts on activators. Only on triggers.

 

EDIT:

Just had a look again to make sure: the four objects that got scripts removed are all triggers. They should not be linked to an activator and run an extra activator script at the same time.

 

EDIT2:

And what you also don't see in TES5Edit (but in the CK) is that those four activator scripts have none of their properties set, except for the rack type, so they could barely run properly.

 

EDIT3:

Forgot to add this: the names of the rack objects are somewhat confusing, but all activators have an "activator"  (in capitals) in their name. Everything else are triggers.

[BlackPete]

You guys are probably well aware of this and have probably worked it out already, but some non-player owned weapon racks have started not holding weapons again since v. 2.0.0. One example of this is at the Whitewatch Tower (screenshot), where the weapons were staying on the rack (as they should) with v. 1.3.3c.

[Sclerocephalus]

Yes, have heard this from various people. The initialization routine of the racks is too slow (it can be improved), but I would really like to understand what's causing it with some people while others are not affected, because I still cannot reproduce it in my game.

 

Daydreamer has been working on this particular issue, as he's one of the persons who are affected, and by now, has the performance of the scripts greatly improved (he also made a few other remarkable additions, by the way), while I am still a bit clueless as to where that comes from.

 

 

EDIT:

 

GOT IT!

 

While looking at your screenshot, I got an idea and now I know what's happening: It's the High Res texture pack!

 

When I turn it off, the problem is immediately gone, but when it is active, the scripts slow down incredibly. Surprisingly, my fps drop was not even that significant, but It almost seems as if the rendering engine tries to keep up a minimum framerate at the cost of the papyrus engine and who knows what else - and that's not good, because it appears to affect all scripts!

 

To check this, I turned the HR pack on on my install for playing, with several mods active, and now I get plenty of "none" errors from mods that never threw errors before:

[10/31/2013 - 02:25:24PM] Error: Unable to call RegisterForSingleLOSLost - no native object bound to the script object, or object is of incorrect type
stack:
	[None]._WetEquipCold.RegisterForSingleLOSLost() - "<native>" Line ?
	[None]._WetEquipCold.onBeginState() - "_WetEquipCold.psc" Line 214
	[None]._WetEquipCold.GotoState() - "ActiveMagicEffect.psc" Line ?
	[None]._WetEquipCold.check() - "_WetEquipCold.psc" Line 177
	[None]._WetEquipCold.OnEffectStart() - "_WetEquipCold.psc" Line 203
[10/31/2013 - 02:25:24PM] Error: Unable to call RegisterForSingleLOSLost - no native object bound to the script object, or object is of incorrect type
stack:
	[None]._WetEquipCold.RegisterForSingleLOSLost() - "<native>" Line ?
	[None]._WetEquipCold.onBeginState() - "_WetEquipCold.psc" Line 214
	[None]._WetEquipCold.GotoState() - "ActiveMagicEffect.psc" Line ?
	[None]._WetEquipCold.check() - "_WetEquipCold.psc" Line 177
	[None]._WetEquipCold.OnEffectStart() - "_WetEquipCold.psc" Line 203
[10/31/2013 - 02:25:24PM] Error: Unable to call RegisterForSingleLOSLost - no native object bound to the script object, or object is of incorrect type
stack:
	[None]._WetEquipCold.RegisterForSingleLOSLost() - "<native>" Line ?
	[None]._WetEquipCold.onBeginState() - "_WetEquipCold.psc" Line 214
	[None]._WetEquipCold.GotoState() - "ActiveMagicEffect.psc" Line ?
	[None]._WetEquipCold.check() - "_WetEquipCold.psc" Line 177
	[None]._WetEquipCold.OnEffectStart() - "_WetEquipCold.psc" Line 203
[10/31/2013 - 02:25:24PM] Error: Unable to call RegisterForSingleLOSLost - no native object bound to the script object, or object is of incorrect type
stack:
	[None]._WetEquipCold.RegisterForSingleLOSLost() - "<native>" Line ?
	[None]._WetEquipCold.onBeginState() - "_WetEquipCold.psc" Line 214
	[None]._WetEquipCold.GotoState() - "ActiveMagicEffect.psc" Line ?
	[None]._WetEquipCold.check() - "_WetEquipCold.psc" Line 177
	[None]._WetEquipCold.OnEffectStart() - "_WetEquipCold.psc" Line 203
[10/31/2013 - 02:25:24PM] Error: Unable to call RegisterForSingleLOSLost - no native object bound to the script object, or object is of incorrect type
stack:
	[None]._WetEquipCold.RegisterForSingleLOSLost() - "<native>" Line ?
	[None]._WetEquipCold.onBeginState() - "_WetEquipCold.psc" Line 214
	[None]._WetEquipCold.GotoState() - "ActiveMagicEffect.psc" Line ?
	[None]._WetEquipCold.check() - "_WetEquipCold.psc" Line 177
	[None]._WetEquipCold.OnEffectStart() - "_WetEquipCold.psc" Line 203

And it's not arbitrary "none" errors ... no, it's those infamous "no native object bound to the script object, or object is of incorrect type" errors of which nobody knows where they come from, and which balefully indicate that your system is running towards a stack overflow.

I wonder how many people have the same issue because they think their system goes along well with high-res textures, although it actually doesn't and it's only their impression that the game is running fluently while everything else goes fubar in the background.

 

Without the HR pack, all racks in Hjerim finish their initialization routine within 1-2 seconds, with the pack active it takes 4 seconds, and the three lousy racks at the western watchtower were not even halfway through in 5 seconds and then fail to load the preplaced weapons (that's technically why they are falling off):

[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC871)>] OnUpdate: Starting InitActivator.
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC870)>] OnUpdate: Starting InitActivator.
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC86F)>] OnUpdate: Starting InitActivator.
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC863)>] OnUpdate: Starting InitActivator.
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC862)>] OnUpdate: Starting InitActivator.
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC861)>] OnUpdate: Starting InitActivator.
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC871)>] disabled, because trigger is disabled.
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC870)>] disabled, because trigger is disabled.
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC86F)>] disabled, because trigger is disabled.
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC863)>]: Parent cell of starting item = [Cell <Wildnis (0000917E)>]
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC862)>]: Parent cell of starting item = [Cell <Wildnis (0000917E)>]
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC861)>]: Parent cell of starting item = [Cell <Wildnis (0000917E)>]
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC863)>]: Checking 3D of [ObjectReference < (000FC86A)>]
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC862)>]: Checking 3D of [ObjectReference < (000FC869)>]
[10/31/2013 - 02:28:42PM] [weaponrackactivatescript < (000FC861)>]: Checking 3D of [ObjectReference < (000FC86B)>]
[10/31/2013 - 02:28:43PM] [weaponrackactivatescript < (000FC862)>]: [ObjectReference < (000FC869)>] failed to load.
[10/31/2013 - 02:28:43PM] [weaponrackactivatescript < (000FC863)>]: [ObjectReference < (000FC86A)>] failed to load.
[10/31/2013 - 02:28:43PM] [weaponrackactivatescript < (000FC861)>]: [ObjectReference < (000FC86B)>] failed to load.
[10/31/2013 - 02:28:43PM] [weaponrackactivatescript < (000FC862)>] enabled on cell attach; PlacedItemInit = True; TOC = 0
[10/31/2013 - 02:28:43PM] [weaponrackactivatescript < (000FC863)>] enabled on cell attach; PlacedItemInit = True; TOC = 0
[10/31/2013 - 02:28:43PM] [weaponrackactivatescript < (000FC861)>] enabled on cell attach; PlacedItemInit = True; TOC = 0

Even with Daydreamer's code active, which is faster than mine, there is no way for me to get the racks to work - well, not a great tragedy because I'm usually not using the HR pack on my slow machine for good reasons.

 

And by the way, I'm cured of high-res textures for a good while now.

[taleden]

When I first installed the beta and tested a bit before changing the scripts, it wouldn't even let me pick a pre-placed iron sword off a rack and put it right back

 

So I guess this was not fixed before 2.0.0 was released? I just tried it again with the final release: grabbed a pre-placed iron sword off a rack (while having another one in inventory), tried to put it back on the rack, was told "This weapon cannot be placed on a rack" and then could never place an iron sword again. Sclero mentioned something about an "exception list" to the "exclusion list" but it doesn't seem to be working, or maybe it was just forgotten in packaging the final release.

 

I remember noticing a few times that it was possible to get a weapon to mount at the wrong angle. I think what I did was I mounted a sword (it was lined up correctly at this point), then picked it off the rack again, dropped it on the ground, z-key "grabbed" it and waved it around a little, let it fall on the ground again, then picked it up and mounted it. That second time, the angle was wrong, as if something about its rotation from being bounced around earlier had been retained and the model was therefore still offset from its "anchor" point (the point whose coordinates are set by MoveTo, I guess).

 

I was just able to reproduce this on the 2.0.0 release, but my memory was off a little: it wasn't the angle that was wrong this time, it was the offset. As in, when first placing a sword on a plaque, it was lined up straight and centered. Then I picked it up, dropped it, grabbed it by the handle and swung it around a bit, dropped it to lean on a wall and picked it up again. When I put it on a rack after that, it was off-center, so the tip of the blade was near the middle of the rack and the handle was hanging off the side.