Overhauling the weapon rack scripts

[Nico coiN]

Too bad. I have no more ideas... 

[Sclerocephalus]

Too bad. I have no more ideas... 

 In the end, I hadn't either - and I tried a lot more.

[Arthmoor]

Silly idea again : could dead and hidden NPCs in the same cell as the racks be considered as chest storages for this purpose ?

Not so silly as you might think. Bethesda stashes what you give to Malborn for MQ201 onto a fake copy of him in the dead body cleanup cell.

Though I'm pretty sure for that they're not using specific temporary references.

[Sclerocephalus]

Bethesda stashes what you give to Malborn for MQ201 onto a fake copy of him in the dead body cleanup cell.

 

There are some funny comments (and weird speculations) on Malborn's copy on the UESP website:

 

http://www.uesp.net/wiki/Skyrim_talk:Malborn

 

EDIT:

A must read for everyone who's still unsure about the general credibility of that site.

[BlackPete]

There are some funny comments (and weird speculations) on Malborn's copy on the UESP website:

 

http://www.uesp.net/wiki/Skyrim_talk:Malborn

 

EDIT:

A must read for everyone who's still unsure about the general credibility of that site.

What would Malborn possibly have to with Rogvirr's execution?

 

Wikis, from my experience, are not know for high credibility, because almost anybody can put information into them without a reliable source; I guess that's basically the point you're trying to make about the UESP though.

[Vardis]

To be fair, that's on the talk page for Malborn.

[lmstearn]

Here's another one out of left field viz an OpenMP threading issue in Havok:

 

I hook Skyrim to one core with Process Lasso and manipulate objects on the Breezehome weapon rack (Activator Hotfix for USKP 1.3.3c installed).

 

The only unusual thing was:

2 glass daggers and an ebony dagger are in player's inventory.

Activating two racks in turn and the two glass daggers are unloaded nicely on the racks.

But in activating the third rack, I need to equip the ebony dagger first.

It is then nicely unloaded.

 

All my other light weapons and staffs came off and on no problem, saved, fast traveled, returned, reloaded, they are still there and are usable.

Any one suggest another range of weapons to try and reproduce this bug. But if weapons are acquired through the console, will the duplications render the test redundant?

[DayDreamer]

Stuck my version WeaponRack 4.0d source in the download area for fixes.

 

http://www.afkmods.com/index.php?/files/file/944-weaponrack/

 

Correctly handles OnLoad() and successfully updates from a very old (USKP 1.05c) save. Works in Warmaidens -- so far the only place I've tested. I've tested with USKP 1.3.3 and most recent 2.0.0 too.

Fixed the state problem by having both the vanilla named states and the 3.x recent newly named states.

Also fixed a few other small errors. Re-organized it so that I could diff against the original and the errors stood out.

However, the 3.4 RegisterForSingleUpdate is set to 0.0 wait. Basically, that idea of using OnUpdate to merge the OnCellAttach and OnLoad isn't happening. The whole update thingy is superfluous until I raise the timeout to 0.2 -- 0.14 seems to be the crossover point where about half of the racks get their signals merged. But then you see the starting weapons blink.

Should I simply remove the OnUpdate? All it does is add more complexity and overhead, with no real benefit.

[BlackPete]

I made a post about a possible bug with the weapon racks and plaques in the Honeyside Manor basement on this thread. I apologize if this is already being looked into. Thanks.

[Nico coiN]

Another (and probably last) absolutely crazy and maybe impossible idea  concerning problematic weapons :

 

Why not considering the other side of the problem ? I mean, the player inventory side ? If these weapons were absolutely script-free they wouldn't be a problem for weapon racks, right ?

 

So, when you get one of these weapons in your inventory (from a corpse, any container or directly from the environment) why not putting a fake and unscripted one in the player inventory ? That would solve the issue, right ? Then, only (and ONLY) when the player (or the follower equipped with this weapon) unsheathes it, we swap it with the original and fully operational one ? In this optic the problem is no more on the weapon racks, but on the player/followers inventories. What's technically the viability of such a tortured idea ? Beware : this is only a concept idea made with nearly zero scripting knowledge. Please, don't flame me if I'm telling nonsense.

 

And more specifically about the Ghost blade, if I don't confuse it with another weapon, it has its own rack (or exposure base) ?   EDIT : Sorry, confusing with the Pale Blade.

[Sclerocephalus]

Stuck my version WeaponRack 4.0d source in the download area for fixes.

 

http://www.afkmods.com/index.php?/files/file/944-weaponrack/

 

Correctly handles OnLoad() and successfully updates from a very old (USKP 1.05c) save. Works in Warmaidens -- so far the only place I've tested. I've tested with USKP 1.3.3 and most recent 2.0.0 too.

Fixed the state problem by having both the vanilla named states and the 3.x recent newly named states.

Also fixed a few other small errors. Re-organized it so that I could diff against the original and the errors stood out.

However, the 3.4 RegisterForSingleUpdate is set to 0.0 wait. Basically, that idea of using OnUpdate to merge the OnCellAttach and OnLoad isn't happening. The whole update thingy is superfluous until I raise the timeout to 0.2 -- 0.14 seems to be the crossover point where about half of the racks get their signals merged. But then you see the starting weapons blink.

Should I simply remove the OnUpdate? All it does is add more complexity and overhead, with no real benefit.

 

 

Test in a Hearthfires home!

Construct a rack at the bench and see whether you can use it.

[DayDreamer]

Test in a Hearthfires home!

Construct a rack at the bench and see whether you can use it.

I'm sorry, test what?

 

I've now tested updates from USKP 1.0.5c in Riverwood and Warmaidens and Dawnstar Jarl's. Saved the logs, they all look OK, other than the OnUpdate is fired twice.

 

Although I've bought Hearthfires, I've never run it. So you're welcome to test your saves there. Thanks.

[DayDreamer]

As to fixing the scripted weapons problem, the canonical method is:

ObjectReference pDriver = currentDriver as ObjectReference

It seems really redundant and silly when the object reference is already an object reference, but there's code like this all over the place.

[taleden]

As to fixing the scripted weapons problem, the canonical method is:

ObjectReference pDriver = currentDriver as ObjectReference

It seems really redundant and silly when the object reference is already an object reference, but there's code like this all over the place.

 

If you're talking about the broken pointer problem, that doesn't work. The cast seems to work at first (the result is not None), but when you try to call a method on it after casting, it still throws the "no native object ... or incorrect type" error just like it did initially. I even tried casting to Form first and then back to ObjectReference in case the compiler was optimizing it away, but still no dice.

 

I think this reveals the separation between the scripting and game engines: on the Papyrus scripting engine side, it has a script object which is of type ObjectReference and that's fine, Papyrus will even cast this script object to Form and back again. But the script object is linked to a native object on the game engine side, and one or both engines seem to think the native object is not of a type that ought to be linked to an ObjectReference script object. So as long as you're just doing script-engine stuff with the pointer (comparing it to None, casting it to other script types, etc) there's no problem, but as soon as you want to call a native method (which must call over to the game engine to get the data back) it chokes.

[Sclerocephalus]

I'm sorry, test what?

 

I've now tested updates from USKP 1.0.5c in Riverwood and Warmaidens and Dawnstar Jarl's. Saved the logs, they all look OK, other than the OnUpdate is fired twice.

 

Although I've bought Hearthfires, I've never run it. So you're welcome to test your saves there. Thanks.

 

(1) When you modify the OnCellAttach/OnUpdate events, you have to make sure that the scripts still work in all instances where they are needed. Thus, run the following test in a Hearthfires home:

 

• Construct a rack at the workbench
• Try to activate it

If it works at once, you are probably safe to remove the OnLoad event from the trigger script.

 

 

And even more important:

 

(2) When you have modified the states, you have to make sure that the scripts will work in all instances where states are important. They are pretty meaningless for mounting pre-placed weapons though. They are only needed for handling weapons on player-activatable racks. Therefore, run the following tests:

 

• Go to Hjerim (or any other place with a standard wooden rack with at least three slots).
• Empty the rack, then place a crossbow somewhere in the middle. Now, check the functionality of the adjacent slots.
• Empty the rack again and place two daggers, so that there is an empty slot between them. Place a crossbow in that slot. Now, try to retrieve the daggers.

 

• Go to Honeyside. There is a wall with three single-weapon plaques mounted on top of each other. Empty them.
• You need an oversized weapon for this test; best use a 2H dragonbone axe. Place this on the uppermost plaque. Then check the functionality of the plaque below (i.e. the middle plaque)

 

• Finally, check a CoA rack (a plaque for two weapons plus a shield). Fill the rack two greatswords and a shield of your choice.
• Grab the shield from the rack and check whether the shield rack is active (as it should be).

 

(3) Lastly, a few minor checks, depending on how far you did regress to the vanilla scripts:

 

• Have you made sure that "PlayersDroppedWeapon" is reset to "none" when the item is grabbed from the rack ? The vanilla script doesn't, but the Hearthfires script that checks this property won't work if you don't.
• Have you made sure that your scripts cooperate properly with the new meshes ?

[Sclerocephalus]

I made a post about a possible bug with the weapon racks and plaques in the Honeyside Manor basement on this thread. I apologize if this is already being looked into. Thanks.

 

The fix was included in the latest beta update (see my reply to your post in the other thread). Well, at least one part of the fix. It turned out that one of the Hearthfires scripts was unhappy with our solution, so this had to be fixed as well.

[Sclerocephalus]

So, when you get one of these weapons in your inventory (from a corpse, any container or directly from the environment) why not putting a fake and unscripted one in the player inventory ? That would solve the issue, right ?

 

Yes, it would.

 

Problem is that you only know the form of the item in your inventory (i.e. the base object or "object type"). To manipulate it (including replacing it), you need to know its reference. But there's no way to check the reference of an item in a container (or actor inventory, actors are containers as well). Once an object reference is inside a container, you can't run any member functions on it.

 

What I can do is removing it from the inventory. This command accepts the form (this also reveals another problem by the way: by accessing the form instead of the specific reference, the script may choose the "wrong" item, when you have more of one items of this type in your inventory - that's a problem we all know pretty well).  And I must remove it from the inventory to manipulate it.

[BlackPete]

The fix was included in the latest beta update (see my reply to your post in the other thread). Well, at least one part of the fix. It turned out that one of the Hearthfires scripts was unhappy with our solution, so this had to be fixed as well.

Thanks, I'll take your word for it. By the way, the 2.0.0 beta version that I tested it on was the version released on Oct 17th, however, this saved game I was using was created with v. 1.3.3c.

[Sclerocephalus]

Thanks, I'll take your word for it. By the way, the 2.0.0 beta version that I tested it on was the version released on Oct 17th, however, this saved game I was using was created with v. 1.3.3c.

 

This is a Hearthfires issue and therefore addressed in the UHFP!

[BlackPete]

This is a Hearthfires issue and therefore addressed in the UHFP!

Okay, sorry. I think I had the Oct 17th [2.0.0] version of UHFP installed, but perhaps that didn't include the fix yet or I didn't have the correct version in my data folder after all. Thanks for clearing that up. I hope I'm not irritating you by my lack of understanding of some of these things.

[Sclerocephalus]

Okay, sorry. I think I had the Oct 17th [2.0.0] version of UHFP installed, but perhaps that didn't include the fix yet or I didn't have the correct version in my data folder after all. Thanks for clearing that up.

 

Well, at this point we should ask Arthmoor what was included at which point and what will be implemented in the final release.

 

Problem with those activators is that they remain borked once Hearthfires does mess them up. Removing the offending links has no retroactive effect; it only prevents the issue from occurring again on a new game. To solve this, I have written a small script that is supposed to run after UHFP has been installed and does reset the properties on the affected racks to make them usable again.

[BlackPete]

Well, at this point we should ask Arthmoor what was included at which point and what will be implemented in the final release.

 

Problem with those activators is that they remain borked once Hearthfires does mess them up. Removing the offending links has no retroactive effect; it only prevents the issue from occurring again on a new game. To solve this, I have written a small script that is supposed to run after UHFP has been installed and does reset the properties on the affected racks to make them usable again.

 So, I would probably have to start a new game to see that fixed, unless this script you speak of is included in the final release? I have no idea when these patches are coming out of beta for sure (no need to rush them by the way), but I don't intend to use beta 2.0.0 on my current game until it is finalized for obvious reasons. If this "script" can be used to reset the racks (or whatever) when 2.0.0 is out of beta, that would definitely be something I would be interested in.

[Sclerocephalus]

Here's another one out of left field viz an OpenMP threading issue in Havok:

 

I hook Skyrim to one core with Process Lasso and manipulate objects on the Breezehome weapon rack (Activator Hotfix for USKP 1.3.3c installed).

 

The only unusual thing was:

2 glass daggers and an ebony dagger are in player's inventory.

Activating two racks in turn and the two glass daggers are unloaded nicely on the racks.

But in activating the third rack, I need to equip the ebony dagger first.

It is then nicely unloaded.

 

All my other light weapons and staffs came off and on no problem, saved, fast traveled, returned, reloaded, they are still there and are usable.

Any one suggest another range of weapons to try and reproduce this bug. But if weapons are acquired through the console, will the duplications render the test redundant?

 

I'm not entirely sure whether I do fully understand what you did with the daggers. So you equipped a glass dagger (with two glass daggers in your inventory) and activated two racks in succession, with the result of both daggers being placed on the rack ?

 

That's a known problem, but there's not much we can do about it:

 

Even when you equip an item, it is physically still in your inventory, which means that all the usual restrictions apply: we know the form (i.e. the object type), but not the specific reference. To place the weapon on a rack, the script removes it from the player's inventory by dropping it into the game world with the DropObject function, like so:

PlayerItemRef = PlayerRef.DropObject (PlayerItem, 1)

PlayerItem is the form to remove, in your case "glass dagger". This function cannot discern between the equipped and the unequipped glass dagger, so it may choose the unequipped dagger (actually, it "may" not, but it does: this function has a preference for unequipped items).

 

As a result, you still have the dagger equipped when you activate the second rack. It's obvious now why this doesn't work a third time, with the ebony dagger: this is another form.

[Sclerocephalus]

 So, I would probably have to start a new game to see that fixed, unless this script you speak of is included in the final release? I have no idea when these patches are coming out of beta for sure (no need to rush them by the way), but I don't intend to use beta 2.0.0 on my current game until it is finalized for obvious reasons. If this "script" can be used to reset the racks (or whatever) when 2.0.0 is out of beta, that would definitely be something I would be interested in.

 

OK. If it is not included in the release for whatever reason, I will upload it for general use.

[BlackPete]

OK. If it is not included in the release for whatever reason, I will upload it for general use.

Thanks. I appreciate your help.