Jump to content

Overhauling the weapon rack scripts


Sclerocephalus

Recommended Posts

Thank you.

 

USKP 1.3.3. has the wrong activator script version from the first v2.40 upload. The re-upload of v2.40 (three days ago) had the correct script, and the script from v2.40e (two days ago) is pretty much the same (the main change in v2.40e was to remove the OnReset event from the trigger script, because it was entirely superfluous).

 

Version 2.5 was no update at all, but had a property reset integrated, i.e. by setting a global, the script would clear its properties and perform a complete re-initialization upon its next run. I used this for my own purposes (because it was quite time-consuming otherwise to make the scripts behave again as if they would run for the first time) and wanted to share it, but it's pretty much obsolete now. I have deleted it from the upload page, so it won't confuse anyone again.

 

 

For comparison, this is InitActivator function of the version packed with USKP 1.3.3:

Function InitActivator()

	Int TOC

	ObjectReference StartingItem = GetLinkedRef()
	ObjectReference TriggerMarker = GetLinkedRef (WRackTrigger)

	If TriggerMarker

		If TriggerMarker.IsEnabled()

			TOC = TriggerMarker.GetTriggerObjectCount()
		
			If (PlacedItemInit == False) && (TOC == 0)
				PlayersDroppedWeapon = None
				PlacedItemInit = True
			EndIf

			If PlacedItemInit && (PlayersDroppedWeapon == None)
				Self.Enable()
			Else
				Self.Disable()
			EndIf

			If StartingItem

				If (StartingItemHasBeenGrabbed == False) && StartingItem.IsEnabled()
					If (PlacedItemInit && (PlayersDroppedWeapon != StartingItem)) || (StartingItem.GetParentCell() != Self.GetParentCell())
						StartingItemHasBeenGrabbed = True
					Else
						HandleStartingItem (StartingItem, TriggerMarker)
					EndIf
				EndIf

			EndIf

		Else
			Self.Disable()
		EndIf

	EndIf

EndFunction

This is the same function in version 2.4e. The main difference is that the "If StartingItem ..." block is now carried out before everything else is handled:

Function InitActivator()

	Int TOC

	ObjectReference StartingItem = GetLinkedRef()
	ObjectReference TriggerMarker = GetLinkedRef (WRackTrigger)

	If TriggerMarker

		If TriggerMarker.IsEnabled()

			TOC = TriggerMarker.GetTriggerObjectCount()

			If StartingItem

				If (StartingItemHasBeenGrabbed == False) && StartingItem.IsEnabled()
					If (PlacedItemInit && (PlayersDroppedWeapon != StartingItem)) || (StartingItem.GetParentCell() != Self.GetParentCell())
						StartingItemHasBeenGrabbed = True
					Else
						HandleStartingItem (StartingItem, TriggerMarker)
					EndIf
				EndIf

			EndIf

			If PlacedItemInit
				If (PlayersDroppedWeapon == None)
					Self.Enable()
				Else
					Self.Disable()
				EndIf
			ElseIf (TOC == 0)
				PlayersDroppedWeapon = None
				PlacedItemInit = True
				Self.Enable()
			Else
				Self.Disable()
			EndIf

		Else
			Self.Disable()
		EndIf

	EndIf

EndFunction

Now, let me explain the problem. If the script runs for the first time, all properties are at their default values: PlayersDroppedWeapon = None (the name is misleading; this is the object reference of the item placed on the rack), PlacedItemInit = False and StartingWeaponHasBeenGrabbed = False. Within the InitActivator function, the script tries to get these properties initialized as quickly as possible:

 

(1) PlayersDroppedWeapon is a property that already existed on the vanilla script, and while it was intended that it should hold the object reference of the item placed on the rack, it never got properly updated (it didn't get reset to none when the item was grabbed from the rack). That is, when the new script runs for the first time, this value is regarded as meaningless (because it was set on the vanilla script and is therefore not reliable).

(2) PlacedItemInit: This bool tells whether PlayersDroppedWeapon has been reliably determined by this script version (either in this or in a previous run). Once set to true, the object reference held by PlayersDroppedWeapon will be considered as reliable.

(3) StartingItemHasBeenGrabbed: This should be self-explaining.

 

The tools for determining appropriate values are very limited. In general, PlacedItemInit can only be determined in the running game, when an item is put onto or grabbed from a rack, but there is another situation in which it is safe to assume that the rack is empty: this is when the trigger object count is zero, and in this case, the script will set PlayersDroppedWeapon to none and PlacedIteminit to true. So far so good. Though, when the condition "(PlacedItemInit && (PlayersDroppedWeapon != StartingItem))" is checked afterwards, it will always be true and StartingItemHasBeenGrabbed will always be set to true without ever handling any pre-placed weapons ...

 

While working on the more recent updates to the scripts, I have been using a version with the checks in the wrong order, because I wanted to find out what happens with the links between the racks and the pre-placed weapons when they are removed from the racks, and whether it makes any difference whether they still are in the same cell as the rack or not (the answer is that it doesn't and that the links are never removed, but that wasn't clear from the beginning). Before uploading a new version, I used to swap the condition blocks, but did forget it on that occasion ...

Link to comment
Share on other sites

Again, sorry for having been confusing during the last couple of days. As already mentioned a couple of days ago, I actually wanted to take a week or so off, because I had to get some things done pretty urgently.

 

I recently moved back to my father's house, where several rooms are empty after my mother and my aunt died a couple years ago. One of the rooms will house my mineral collection, so I arrived with about 40 bulky crates which were placed almost everywhere, except in the cellar, where there is enough space but also a humid atmosphere which is detrimental to the stability of sulphide minerals. Not to talk about the general nuisance imparted by the obstacles he always had to dodge around on his ways in the house, he also slowly got the impression that I didn't take his concerns serious because I spent my time on the computer instead of sorting out the crates ("WHAT are you doing ??? Are you crazy ... ? I want those crates out of my way !!). As the collection has been carefully assembled in over 35 years, it's worth a small fortune and only this prevented him so far from grabbing the stuff himself and carting it to the scrapyard, but in the end (more precisely, early last week), I had to take care of the crates very urgently to calm down the situation. Unfortunately, the scripts were still not completely done then ...

Link to comment
Share on other sites

ah, sorry to hear this has caused you more troubble than expected.

 

seeing the link you posted i hoped you would have taken the week off for a hiking tour to collect minerals, not move all those heavy crates around.

i hope your father is pleased now with the mineral collection on display.

Link to comment
Share on other sites

Everything's been sorted out now. Version 2.3 of the scripts managed to worm its way back into the distro package before the final release. Not sure how I managed that, but what's done is done and it's fixed now.

Link to comment
Share on other sites

Sclerocephalus;

 

Thank you very much for putting in such hard work for this fix. It's easily one of the more invaluable fixes in the USKP. :)

 

Maybe now I'll actually use the plaques. :lmao:

Link to comment
Share on other sites

Although I did explain this several times before, there still appears to be a need for some sort of a manual on how to make the new scripts work. Here we go (Let's hope that the people who keep on nagging on the Bethesda forum take the time to follow the link and read this eventually):

 

 

THE RACKS WILL NOT WORK AT ONCE (unless you start a new game).

There are simple reasons for this:

  • The new scripts have new properties added, which are needed to discern e.g. whether the "starting item" has been grabbed or not (the "starting item" is an item that has been pre-placed in the CK; a previously placed player item is NOT a "starting item"), whether a rack is really filled or whether the objects in its trigger volume are really just overlaps from items placed on adjacent racks, etc. These properties must be initialized before the racks will work properly.
  • The only way to get these properties initialized is by starting with an empty rack. This is because the possibilities for checking a rack's status are very limited (that's not a scripting problem but has to do with Beth's conception of the racks. For example, there's no way to say which item is placed on a rack if its object reference has not been stored in a variable in the moment it has been placed - incidentally, this is just one of the properties that need to be initialized). The vanilla scripts were checking the rack's trigger object count for that purpose (i.e. the number of objects in its trigger volume), but this is insufficient, because there is a cross-activation when large items are placed on adjacent racks (consider a fully occupied CoA rack for example: the trigger object counts of all three activators will be three, because the shield overlaps with the trigger volumes of the plaques on either side and the weapons on each side overlap with the trigger volumes of both the shield plaque and the plaque on the opposite side). Thus, a rack is not "empty" in this context when you grab the item that was placed on it. You also have to make sure that there are no items on adjacent racks that overlap with its trigger volume. In other words, you have to grab all items from all racks.

 

WHAT TO DO TO MAKE THE RACKS WORK ?

Very simple: Grab all items from all racks, then leave the cell. Enter again, leave again (yes, you need to leave and enter twice! I will explain this hereinafter). Then enter again and your racks will work. Upon first re-entering the cell, the script forces the activator to handle the starting items (this was the only way to restore messed-up racks, i.e. to place all items that fell to the ground with the vanilla scripts on the racks where they belong), but in the process of doing this, some triggers in the player homes may glitch out (this has to do with the way the trigger works - the whole conception of the racks is the second worst of all bad ideas the devs ever had anyway). That's not a problem though, because the activator script will reset them on the next cell attach. To make this happen, you only have to leave and enter again (there's nothing else you have to do, just go through the door).

 

I have spent two full days with testing attempts at making the racks work immediately, but thay all failed. In the game, the racks will work most of the time when you leave (after grabbing all items) and enter once. Nonetheless, the safe way is to do it twice.

 

If you have been running USKP 1.3.3 and did upgrade to 1.3.3a., you will have to wait for a cell reset until the messed-up racks get restored (for racks in player homes, it shouldn't make any difference if you keep to the procedure outlined above). Also note that it is not a good idea to upgrade the USKP while you're in a room with player-activatable racks (not with this specific upgrade).

 

 

Remarks on a few other glitches that were reported by several people:

 

(1) Racks are unusable:

That's not a bug. In fact, most racks in the game are not usable by the player. While weapons can be grabbed from them, it is not possible to put anything back on them. This was intended by Bethesda, and they have also been using different rack objects in player houses and elsewhere. In the CK, you will find two objects for each rack type, one of them with "PlayerHouse" in its name and only this can be activated by the player. Most racks placed in the game are using the other rack object, though, which does not have "PlayerHouse" in its name and cannot be activated by the player. Thus, this was clearly intended and we did not make any racks usable that weren't usable before.

(2) Shields become invisible:

Since large shields, which were previously clipping through the rack and the wall behind, are now mounted at a greater distance from the rack, you may get closer to them when you approach the rack than you could get before, and like all objects in the game, it will become invisible upon doing so (even parts of your followers turn invisible when you approach tem too closely). We did nothing to enforce this behaviour, though.

(3) The right and left plaques of the CoA rack become unusable when a large shield has been placed:

Not true. The collision box of a large shield will cover the plaques' trigger volumes so that they are out of reach if you are standing in front of the rack. Make a step to the side, i.e. approach the rack from the right if you want to use the right plaque or from the left if you want to use the left plaque, and you will see that they still work.

Link to comment
Share on other sites

I get what you mean but didnt you say that some racks had all the functionality aside one little naming issue? Personally that would lean towards something bethesda intended to finish but messed up at the last bit

Link to comment
Share on other sites

I get what you mean but didnt you say that some racks had all the functionality aside one little naming issue? Personally that would lean towards something bethesda intended to finish but messed up at the last bit

If this were the case there would not have been a need for two distinct types of racks.

Link to comment
Share on other sites

I get what you mean but didnt you say that some racks had all the functionality aside one little naming issue? Personally that would lean towards something bethesda intended to finish but messed up at the last bit

 

Whether an object is named or not certainly makes a difference. Unnamed objects can't be grabbed nor activated. In the case of those racks, however, there are apparently more differences than just the missing names. In an attempt to make them fully interactive, I added names to the base objects, but they remained as static as they were before. I did not further investigate why.

Link to comment
Share on other sites

If this were the case there would not have been a need for two distinct types of racks.

Whether an object is named or not certainly makes a difference. Unnamed objects can't be grabbed nor activated. In the case of those racks, however, there are apparently more differences than just the missing names. In an attempt to make them fully interactive, I added names to the base objects, but they remained as static as they were before. I did not further investigate why.

I think this is similar to what I mention here and it could be related to what Bethesda had included on their E3 demo for Skyrim.

Link to comment
Share on other sites

He Sclerocephalus, just to let you know:

 

currently there is the Author of the "old" fix that was apparently in 1.3.2 discussing some ideas on the incompatible weapons.

of course he claims his solution better, but i think the main point is this:

 

you two are probably the only ones around to be still able to improve on this, it looks like any other is not even remotetly deep into the matter to contibute anything (aside from crossposting links :-P).

 

so if you could get your heads together, who knows, maybe an even better solution will come up, about how the weapon rack scripts handle those weapons in the exclusion list.

i think LukeH has some ideas about what might be the cause of them being dropped.

 

i'll keep my fingers crossed

Link to comment
Share on other sites

oh, yes. sorry. i had intended to do that actually. NightStar saves the day (or is it night?) :-)

Link to comment
Share on other sites

:wallbash:

 

 

Another bug spotted (does this ever stop ?):

 

All of the player home CoA rack left & right TRIGGERS have an additional ACTIVATOR script attached (in addition to the trigger script inherited from their base object). It's difficult to predict whether they may cause any glitches: when they aren't linked to another trigger (i.e. another trigger linked to this trigger), which they aren't, they will never run their initialization procedure. They can be activated though ...

 

Better delete them. I will upload a fix for the next USKP.

Link to comment
Share on other sites

Sheesh we expect better quality work from you :P kidding  :D Anyway like you told me its a rabbit hole XD

Link to comment
Share on other sites

:wallbash:

 

 

Another bug spotted (does this ever stop ?):

 

Better delete them. I will upload a fix for the next USKP.

Probably never. :teehee:

 

Although I admire your patient for trying to fix those activator scripts.  Thanks and keep up the good work! :D

Link to comment
Share on other sites

I hate to say this, but there is another update:

 

The reason is that some racks stopped working for no obvious reason after a few in-game days. This was horribly difficult to repeat, as it only affects those racks that come with pre-placed starting items and whether or not the rack keeps on working depends on what you have done wit those items. Putting them in a chest is fine, but selling them will make the rack stop working within two in-game days. Alternatively dropping them somewhere outside (after all, they're all crap) will make the racks stop working when that cell resets. I have reported all the background here, because the findings are important for everyone who writes papyrus scripts:

 

http://www.afkmods.com/index.php?/topic/3717-skyrim-the-papyrus-function-getparentcell-and-what-may-happen-when-it-runs-on-a-persistent-reference/

 

A positive side effect of this fix is that it also eliminates some of the limitations in the initialization procedure that were due to the handling of the starting item. Most racks are now working properly with the new script upon first visiting the cell. The few that don't (because of ambiguous property values inherited from vanilla scripts that ran on the same racks earlier) will be ready by leaving and returning once.

Link to comment
Share on other sites

Thanks Sclero, since we've been forced to do another quickie update I've included the trigger fix along with it. Should have injected those predator script keywords when I merged your fix in. Ah well, live and learn, right? :P

Link to comment
Share on other sites

Actually, it would have been better to include the full 2.6 update (i.e. the fix to the activator script, which replaces the inappropriate GetParentCell() check; the esp packed with this version has the trigger fix already included). Those out-of-place activate scripts do only minor harm, if at all (they may affect the vanilla scripts, though), but the GetParentCell() issue will affect all player-home racks that came with pre-placed weapons in the long run. I have the 2.6 version running in my playthrough now (still the debugger version) and I had no rack hooking up in an endless loop ever since.

 

Also, a big thanks to everyone who helped catch the predators I overlooked.

Link to comment
Share on other sites

I wish you'd made it more clear that there was more than just the out of place trigger scripts thing that needed to go. We'll just have to remember to take care of that with the next major update because I REALLY don't want to throw another hotfix for the USKP. It doesn't sound like this is going to be an especially bad thing for now.

 

Either way, massive thanks for the work you've done on these, I don't think anyone was even aware of just how badly messed up they were.

Link to comment
Share on other sites

I hate to say this, but there is another update:

 

The reason is that some racks stopped working for no obvious reason after a few in-game days. This was horribly difficult to repeat, as it only affects those racks that come with pre-placed starting items and whether or not the rack keeps on working depends on what you have done wit those items. Putting them in a chest is fine, but selling them will make the rack stop working within two in-game days. Alternatively dropping them somewhere outside (after all, they're all crap) will make the racks stop working when that cell resets. I have reported all the background here, because the findings are important for everyone who writes papyrus scripts:

 

http://www.afkmods.com/index.php?/topic/3717-skyrim-the-papyrus-function-getparentcell-and-what-may-happen-when-it-runs-on-a-persistent-reference/

 

A positive side effect of this fix is that it also eliminates some of the limitations in the initialization procedure that were due to the handling of the starting item. Most racks are now working properly with the new script upon first visiting the cell. The few that don't (because of ambiguous property values inherited from vanilla scripts that ran on the same racks earlier) will be ready by leaving and returning once.

 

its only the player house racks that have that problem right? the other ones are fine to just sell/drop?

i just started a new game (upgraded from 1.3.2 to 1.3.3c) and don't want to wait for the next major update(apparently the weapon rack overhaul esp fixfile can't be downloaded by the public or i'd merge it my self as a temp fix)

Link to comment
Share on other sites

its only the player house racks that have that problem right? the other ones are fine to just sell/drop?

 

Less than that. It's only those player home racks that came with pre-placed weapons (mostly the so-called "CoA racks" with one shield and two greatswords). All others (e.g. the standard wooden racks) are fine. Plus: you do not risk to lose any weapons! (the conception of the new scripts does not allow for this to happen).

 

When you start a brand new game, this bug won't affect you at all (this bug only appears when the pre-placed weapons have been removed BEFORE the new scripts run for the first time).

 

When playing around with the wooden racks, you'll notice that all the glitches with racks becoming inoperative when another weapon is placed on an adjacent rack are gone. I recently found this site which provides a nice summary of the most common glitches:

 

http://elderscrolls.wikia.com/wiki/Weapon_Rack

 

They are all history now!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...