Overhauling the weapon rack scripts

[DayDreamer]

Does OnLoad() fire after loading a save? OnCellLoad() does not!

To answer my own question, after a weekend of testing various scenarios: no.

[Sclerocephalus]

AAAAAAAAAAARRRRRGGGGHHHH !!!!!!

 

I wondered why my logs tell me that the activators in Honeyside are placing X markers on the racks. Yes, X markers !!!

 

And who's the culprit ? Hearthfires !

 

Somebody has linked a fair number of player home activators (all ?)  to the player house enable markers! Fortunately though, this person was not only stupid but really dumb as a rock and didn't to it right: instead of linking the enable markers to the activators, he linked the activators to the markers, with the result of all markers being interpreted now as preplaced items.

 

BUT EVEN WORSE:

• All empty racks in player homes become inoperative when both Hearthfires and USKP are installed, because the activator "thinks" that the rack is occupied.
• all preplaced items that come with your home decorations will end up on the floor instead on the rack (well, there's a 50/50 chance that the script selects the weapon when it has to choose from two links without keyword, but anyway)

[Nico coiN]

 

And who's the culprit ? Hearthfires !

I warned you...

[Arthmoor]

So wait. What? HF is improperly linking XMarkers to the visible weapon rack objects?

 

Do we know which ones are to blame? Cause this obviously warrants being squashed before 2.0 goes live.

[Sclerocephalus]

 

 

I warned you...

 

 

Yes. And it's much more serious than you think:

 

With Hearthfires installed, every affected player home rack that is emptied and not refilled before you leave the cell will become inoperative !

No matter whether you're running USKP or not. The vanilla scripts have the same problem.

[Nico coiN]

Yes, I have a few unusable racks on my actual savegame.

[Sclerocephalus]

Do we know which ones are to blame? Cause this obviously warrants being squashed before 2.0 goes live.

 

All racks in the basement of Honeyside (seven in total), but - fortunately - nowhere else (checked all cells edited by Hearthfires.esm in TES5Edit).

 

Now, correcting this is simple, since only the links need to be removed. I have prepared a small esp with the fixes. This alone is not retroactive, though.

 

Because the problem persists since Hearthfires has been released and there are probably many people whose racks in Honeyside became unusable over time, I have prepared a small script to purge the data from the activator scripts. Attach to the UHFP retro quest and call its "ResetActivators" function from the UHFP retro script.

 

http://www.afkmods.com/index.php?/files/file/921-honeyside-activator-fix/

[Nico coiN]

Honeyside only ? I have some shield racks in Lakeview manor that corrupt and become unusable if I get back the shield from them.

[Sclerocephalus]

I have some shield racks in Lakeview manor that corrupt and become unusable if I get back the shield from them.

 

And why did you never say a word ?

 

What's the problem and which racks are affected (IDs would be best, but in the case of Hearthfires, I'll also accept a locality description).

[Nico coiN]

This is a very recent problem. And (believe me or not, it's your choice) I haven't really played Skyrim since weeks (perhaps months). I haven't even played Dragonborn at all...

 

I have been focused on mesh fixes that I posted here, and various 3rd party tools, datas and dictionaries to improve accuracy and time efficiency when translating USKP/UDGP/UHFP/UDBP to french. I have a nice part of the french community to support, even if it's much less active nearly 2 years after the game's release... 

 

Well, I guess savegames will avoid complex and boring explanations. Here's the first, and here's the second. In each one you're just in front of the affected racks. Try to take/put-back shields or weapons on them and you'll understand... I don't know what happened to them, I can't remember right but the rack on top of the front door in Breezehome may also be affected.

 

I should also point out that the actual USKP and bros' active plugins on these savegames are the latest publics, not the actual betas.

[maboleth]

Woa! Lots of respect for you Nico and your contributions, but please take a break once in a while and play the game! You'll like it, you'll see. :grin: You reminded me of the hard-working guys that never got the time to actually look and appreciate their work.

[Sclerocephalus]

I can't remember right but the rack on top of the front door in Breezehome may also be affected.

 

That's a single weapon plaque and there was something wrong with it, but this should be fixed now.

[Arthmoor]

Looks like there's a new problem that's cropped up with the updated scripts that are now out in the latest beta.

 

Shroob and I have both verified that pre-placed weapons on the racks in Warmaidens and in Dawnstar's White Hall fall off the racks as soon as you enter the room.

 

It's probably somehow relevant, but this is now showing up in the logs (buried under tons of critter spam too, bleh):

[10/18/2013 - 08:34:45PM] Error: Unable to call GetLinkedRef - no native object bound to the script object, or object is of incorrect type
stack:
    [None].WeaponRackTriggerSCRIPT.GetLinkedRef() - "<native>" Line ?
    [None].WeaponRackTriggerSCRIPT.RegisterActivatorForUpdate() - "WeaponRackTriggerScript.psc" Line 49
    [None].WeaponRackTriggerSCRIPT.OnCellAttach() - "WeaponRackTriggerScript.psc" Line 24

 

Chances are this is affecting plenty of other pre-placed racks not owned by the player. This was not the case prior to the most recent script update.

[BlackPete]

I remember that on vanilla Skyrim with no USKP, most every non-player owned rack would have the weapons fall off. Examples are outside Alvor's House in Riverwood, at the Whitewatch Tower, and at Shor's Watchtower. I was really amazed when I started using the USKP v.1.3.3c that you guys had fixed all of these.

[Arthmoor]

Then something must have regressed in the beta scripts.

[BlackPete]

Then something must have regressed in the beta scripts.

That's what I would suspect. By the way, these non-player owned racks actually worked a long time ago with vanilla Skyrim, but Bethesda broke them with one of their patches somewhere along the way. I hope it isn't too hard for you guys to narrow down the problem in the beta. Also, if it would be helpful to have a save file using USKP 1.3.3c, let me know and I would be glad to upload one.

[Sclerocephalus]

Looks like there's a new problem that's cropped up with the updated scripts that are now out in the latest beta.

 

Shroob and I have both verified that pre-placed weapons on the racks in Warmaidens and in Dawnstar's White Hall fall off the racks as soon as you enter the room.

 

It's probably somehow relevant, but this is now showing up in the logs (buried under tons of critter spam too, bleh):

[10/18/2013 - 08:34:45PM] Error: Unable to call GetLinkedRef - no native object bound to the script object, or object is of incorrect type
stack:
    [None].WeaponRackTriggerSCRIPT.GetLinkedRef() - "<native>" Line ?
    [None].WeaponRackTriggerSCRIPT.RegisterActivatorForUpdate() - "WeaponRackTriggerScript.psc" Line 49
    [None].WeaponRackTriggerSCRIPT.OnCellAttach() - "WeaponRackTriggerScript.psc" Line 24

Chances are this is affecting plenty of other pre-placed racks not owned by the player. This was not the case prior to the most recent script update.

 

That's not a script problem. Something else is going on here. Somehow, you made it that "detached" scripts are running: there should be a valid trigger reference in the square brackets, not a "none". A none object cannot have a linked reference, so the script will fail. The error occured much earlier, when the script was "stripped" from the trigger. That's usually an engine level issue.

 

BTW, I've not been getting these so far.

[Sclerocephalus]

By the way, these non-player owned racks actually worked a long time ago with vanilla Skyrim, but Bethesda broke them with one of their patches somewhere along the way.

 

That's entirely new to me, and it's actually not likely. All non-player racks are using different base objects for both the triggers and the activators (which are not player-activatable), so it's rather obvious that they didn't want them to be usable by the player.

 

BTW, making them usable is very easy, as it would only require to replace the triggers and activators with the player-home versions (although it is much work, because there are far more than 300 racks affected).

[BlackPete]

That's entirely new to me, and it's actually not likely. All non-player racks are using different base objects for both the triggers and the activators (which are not player-activatable), so it's rather obvious that they didn't want them to be usable by the player.

 

BTW, making them usable is very easy, as it would only require to replace the triggers and activators with the player-home versions (although it is much work, because there are far more than 300 racks affected).

When I said non-player racks were working a long time ago, I was actually talking about the weapons not falling off the racks (see post #188 and #189 above) rather then the player character being able to use them. Sorry for the confusion, you are correct, non-player racks have never been usable without mods.

[Arthmoor]

That's not a script problem. Something else is going on here. Somehow, you made it that "detached" scripts are running: there should be a valid trigger reference in the square brackets, not a "none". A none object cannot have a linked reference, so the script will fail. The error occured much earlier, when the script was "stripped" from the trigger. That's usually an engine level issue.

 

BTW, I've not been getting these so far.

Well, whether there should or shouldn't be a valid reference there is immaterial. It happened or it would have been logged that way

 

And stuff is falling off of racks that are not player usable (Alvor's, Warmaidens, Dawnstar, probably others) where they weren't with the previous iteration of the scripts.

 

It was also not me who initially spotted this. Sharlikran brought it up in our chat since it also affected a mod he's building which means it's happening even on references never before seen.

[Sclerocephalus]

Well, whether there should or shouldn't be a valid reference there is immaterial. It happened or it would have been logged that way

 

While I understand your point, there's nothing I can do.

 

It's not in the scripts. No script (neither vanilla, nor overhauled vanilla, nor mod-added) will continue to work when the engine forgets which running instance is attributed to which object reference. This script starts running on nothing on cell attach.

 

Remember that we had plenty of such issues reported on the papyrus tracker, and nobody knows why this is happening. The only point everybody agrees on is that it actually should not be happening, and that there's no way to do something with the scripts that could prevent it from occurring.

 

I can set up the activator to run its initialization independent from the trigger (i.e. revert to version 2.6), but there's no guarantee that the activator script is not affected by this issue. If it is, it won't find the pre-placed item and the result will be the same.

 

Maybe the logs will tell more. The debugger version 3.1 scripts are still available for download from the overhaul page. Drop into your data/scripts folder, then return to the Warmaiden's and show me the log. I don't have this bug yet, so cannot do this myself.

[Arthmoor]

I'll drop those in and find out. Best I can tell you before I get the chance is that I heard the weapons fall down upon entering the shop. So I know they were mounted correctly before that.

[Sclerocephalus]

Is there some reason for the engine to be particularly busy in Whiterun after installing the latest 2.0.0 beta ? Perhaps it's forced to do some major clean-up after your modifications to the companions quests scripts ? Or Sharlikran fell victim to that tweak guide ?

 

The only reason I know for this to happen is still an engine overload.

[Arthmoor]

The bloat fix for the Companions isn't that big of a deal. On the char I checked Warmaidens with it wouldn't have kicked in at all since he hasn't joined and wasn't going to. Even so, it's just cleaning out one spawn chest and/or deleting an NPC or two. Nothing particularly taxing.

 

I certainly haven't done any ini tweaking either, beyond a couple of bits for shadows here and there. Nothing that should be causing Papyrus any grief.

[DayDreamer]

What are the script names? I've saved the various USKP versions, I can browse the scripts and eyeball the changes.

 

Were the script names changed? This is the kind of problem I reported in another thread upon removing some package script fragments. They run without being attached to anything!

 

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