Jump to content

Overhauling the weapon rack scripts


Sclerocephalus

Recommended Posts

While I was preparing the weapon rack script updates for USKP 2.0, I felt that it is about time for a report of recent progresses. Let's start with a summary of the script versions:

For USKP 2.0 however, I would like to go one step farther (say, version 3.0 - tyrel has been waiting for this anyway). As you may know, I have been working for quite some time on a fix for the problem weapons (the ebony blade etc.) and finally gave up a while ago because there was no way to handle them. While doing this, I also developed a version of WeaponRackActivateScript that is capable of detecting itself whether or not an item can be placed on a rack. This script version is already included in my Extended Racks mod and has been playtested will all sorts of unique weapons from both Skyrim and the two DLCs. So far, there has been no failure.

 

Including this in USKP has the advantage of making the weapon rack scripts completely independent on external data. Presently, the problem weapons are handled by a form list which needs to be updated every time a new problem weapon has been identified (which doesn't happen too often, though). There would be no need to do this anymore, and at the same time, the scripts would also filter any items that have not yet been identified as problematic (even mod-added ones). The following items are required for this to work:

  • A game start-enabled quest with a single alias that holds a chest. This chest needs to be placed in a holding cell and force filled into the alias to make it permanently persistent (this is necessary for it to work).
  • Two small scripts attached to the quest alias and the quest itself. The quest script consists of a single function that is called by WeaponRackActivateScript and controls all of the "communication" between the rack and the chest.
  • A form list which holds the base objects of all items that cannot be handled.

The form list is already present in the USKP 1.3.3c version scripts and it can be used without further modifications. The new WeaponRackActivateScript script will add the base items of any weapons that it cannot handle to this list (thus, one might even start with an empty form list; the script in the Extended Racks mod is doing it that way). The list is checked each time a rack is activated by the player and prevents the problem items from having to run through the whole test procedure again.

 

The script modifications are limited to the HandlePlayerItem function (the following code was taken from the Extended Racks mod and the names of several variables are not the same as those of the corresponding variables in the USKP scripts):

FormList Property scWeaponRackExclusionList Auto
FormList Property scWeaponRackExceptionList Auto

Quest Property scWRItemHandlingQuest Auto

:

Function HandlePlayerItem (Form PlayerItem, ObjectReference TriggerMarker)

	Bool StaffNotExcluded = True

	ObjectReference PlayerItemRef
	ObjectReference ReferenceFromQuest = None

	scleroWRItemHandlingScript ItemHandler = scWRItemHandlingQuest As scleroWRItemHandlingScript


	ReferenceFromQuest = ItemHandler.CheckItemRef (PlayerItem)
	PlayerItemRef = PlayerRef.DropObject (PlayerItem, 1)
	
	If ReferenceFromQuest && (PlayerItemRef != ReferenceFromQuest)

		PlayerRef.AddItem (ReferenceFromQuest, 1, True)
		ToggleRack (TriggerMarker, True)

		scWeaponRackWeaponDisallowedMessage.Show()
		
		If (scWeaponRackExceptionList.HasForm (PlayerItem) == False)
			scWeaponRackExclusionList.AddForm (PlayerItem)
		EndIf

	Else

		If PlayerItemRef.HasKeyword (WeapTypeStaff) && TriggerMarker.HasNode ("WRDisplayCase01")
			If PlayerItemRef.HasNode ("Staff3rdPerson:0") || PlayerItemRef.HasNode ("3rdPersonStaff04:1")
				StaffNotExcluded = False
			EndIf
		EndIf

		If StaffNotExcluded
			PlaceItem (PlayerItemRef, TriggerMarker)
		Else
			scWeaponRackWrongStaffMessage.Show()
			PlayerRef.AddItem (PlayerItemRef, 1, True)
			ToggleRack (TriggerMarker, True)
		EndIf

	EndIf

EndFunction

The item handler transfers the item to be placed on the rack in the test container (i.e. the above mentioned chest), which fires an OnItemAdded event that is handled by the script on the container alias. The reference of the item added to the container (this is submitted by the event) is then returned to WeaponRackActivate Script.

 

If the player's item is not persistent, the test container receives a "none" reference and the script proceeds with the handling (anything that's not presistent has never been a problem). If not "none", the script compares the reference from the test container with the reference returned by the DropObject command. If the references match, the item can be handled; if not, the item cannot be handled.

 

Extensive testing has shown that this method is infallible. For problem weapons, the DropObject command always returns a nonsensical [item xx in container yy] reference, while the reference from the container is still valid. Actually, this only works because of the new [item xx in container yy] references which are otherwise virtual nightmares.

Link to comment
Share on other sites

Sounds good to me. I dropped version 2.6 into the USKP 2.0 batch already but if you've got updates and they're as good as this sounds, we can definitely wait until those are ready.

Link to comment
Share on other sites

I have been sidetracked by papyrus log errors during the last couple of days, but 3.0 is online now:

 

http://www.afkmods.com/index.php?/files/file/785-weapon-rack-overhaul/

 

The esp file has all placement and item fixes, including the four triggers with out-of-place activator scripts reported recently (bug #13578).

Link to comment
Share on other sites

The formlist is still needed, but it can start empty. Moreover, we need two formlists now, an exception formlist and an exclusion formlist. Though, we won't need to update them again. I'll try to explain it very briefly:

 

The source of all evil is the DropObject function, but weapon racks won't work without it because they aren't containers and the item to be placed needs to be removed from the player's inventory first. Running DropObject on a problem item will return an IxCy reference which behaves in many situations as if the item had never left the inventory, although it is physically dropped. The first thing to do when a problem item has been identified is to add this item back to the player's inventory. AddItem does not work with an IxCy reference, but it does work with the reference previously submitted by the test container. However, once this is done, the reference is "borked": trying to repeat the whole procedure will cause a mess with results varying from disappearing weapons to "exploding" script logs (depending on the item in question).

 

In other words: the procedure will only work once (actually, it eventually works again after the item has been placed in a container and taken out of it later; in the worst case however, a player will try to place an item again after the first trial failed and in this case, he'll risk to loose the item - there's one exception though, as will be explained below). Thus, I had to make sure that the procedure is never performed again when it fails (i.e. when the item in question was found to be not placeable).

 

Once a problem item has been identified, the script will add its base object to the exclusion list. Every time the player activates a rack, the script will check this list first, and when an item is on the list, it will not even call the item handling procedure.

 

There's one problematic item though, which can be submitted to the procedure an infinite number of times without the engine freaking out. This is Wuuthrad, and I have already been reporting earlier that it behaves rather strangely in that it fails to be placed on a rack when it was on a rack before, but can be placed again without problems after a failure. This is what the the exception list is needed for: objects on this list will not be added to the exclusion list when their placement fails.

Link to comment
Share on other sites

And what about USKPWeaponRackForswornStaves? Should that get emptied out too like USKPWeaponRackExclusionList? Will the automated methods you're using account for staves?

Link to comment
Share on other sites

The method accounts for all items. The staves list is only used to prevent forsworn staves from being put into large display cases, as they would end up there in a vertical instead the expected horizontal position (due to that engine bug). Using the list spares me two lenghty if-then cascades.

Link to comment
Share on other sites

Beta will be out Saturday. When that turns into a live release all depends on how smoothly testing goes.

Link to comment
Share on other sites

Beta will be out Saturday. When that turns into a live release all depends on how smoothly testing goes.

Great, will test it for sure.

Seen The Hobbit pt.1 several days ago and since then I cannot stop playing Skyrim ... and now with the Desolation of Smaug trailer being released... whooaa, Darkfall Cave here I come.

Link to comment
Share on other sites

So I'm getting a lot of crashes lately. I think it started after I built one of the Hearthfire houses. I haven't even put any weapon racks or much of anything inside yet, just a fire pit. I started it just a little bit and went off to do other things. I get the crashes pretty frequently yet randomly. Sometimes it takes about 20 or 30 minutes, most of the time just about 5 minutes. And I'm no where near a weapon rack. Yet I see a lot of these "WeaponRackActivateScript" messages. Don't know if it's even related to my crashes, but I figured I'd ask for help here. I've already tried increasing my iMaxAllocatedMemoryBytes to ~100MB. No change. Do I need to go higher? I've also downloaded the Extended Racks mod. I'll post again after testing that out. Below are my Skyrim.ini and Papyrus log from my latest crash. Any help or advice is greatly appreciated. 

 

Skyrim.ini

http://pastebin.com/hLdwHuAp

Papyrus.0.log

http://pastebin.com/qve8Lvet

http://pastebin.com/ZgTeShFn

Link to comment
Share on other sites

I increased iMaxAllocatedMemoryBytes to ~1GB and still got frequent crashes.

However, after installing the Extended Racks mod, the crashes stopped :D

I played for about an hour with no crashes at all (except on exiting the game, but it's always crashed on exit with Dawnguard enabled...)

 

Thanks for the great work you guys do.

Link to comment
Share on other sites

I increased iMaxAllocatedMemoryBytes to ~1GB and still got frequent crashes.

You really don't want to do that, because as illogical as it may seem, that will inevitably lead you to a lot MORE crashes in the future. Best to reset yourself to the default values before things get out of hand.

 

Guides that suggest people tweak this are doing serious damage and need to be told to stop.

Link to comment
Share on other sites

Well, I'm still getting crashes, apparently, though they are far less frequent. As for the iMaxAllocatedMemoryBytes setting, I changed it back to default almost immediately after changing it. Hopefully it didn't hurt my save. I only saved once or twice with it set to 1GB.

I've uninstalled and re-installed the extended weapon racks mod, still getting tons of "is3DLoaded" errors with messages about WeaponRackActivateScript. I swear I'm nowhere near a weapon rack when the crashes occur. I just don't understand what is causing these crashes. At least they don't happen as frequently though. 

Link to comment
Share on other sites

I've uninstalled and re-installed the extended weapon racks mod

That alone is enough to foul things up on that save. Nothing you're doing to it at this point is going to correct it. You'll either have to live with what you have or start over with a new save. Papyrus does not forgive the removal and reapplication of a mod, no matter the conditions.

Link to comment
Share on other sites

That alone is enough to foul things up on that save. Nothing you're doing to it at this point is going to correct it. You'll either have to live with what you have or start over with a new save. Papyrus does not forgive the removal and reapplication of a mod, no matter the conditions.

Please explain. For Touring Carriages, I'd hoped that folks could remove it and re-add it later. Heck, it was a design goal from the get-go.

 

I used all new form numbers for every object, essentially layering them on the existing base forms. That is, the horses are new forms, but they have an existing form (HorseForCarrriageTemplate) as a base. I'm having to change the underlying form to pick up your new UDGP 2.0 factions, that you put in HorseForCarriageNew -- so I have to use that too. Thus, this is of immediate concern to me....

 

Anyway, everything disappears after removing the mod. Doesn't that include scripts attached to the objects that disappeared?

Link to comment
Share on other sites

Pretty simple really. Removing a mod that has scripts causes script data to become abandoned in the save. You will see log errors being generated by this. Even from objects that no longer exist. Scenic Carriages had loads of the same kinds of things you're doing with Touring Carriages. Scripts that were newly minted, assigned to objects which only existed in his mod, and yet when the mod was removed they generated garbage in the logs. One of the scripts had even caused carriage drivers to lose their vanilla topics once the mod was gone.

 

Reinstalling the mod did not help either. The logs began complaining about things that didn't match up and that it was going to use copies from the save game instead of the ones from the mod, and the drivers still had their topics lost.

 

I only ended up able to free myself from it by compiling every script from the mod down to nothing but dummy stubs - files with just a script name in them. The game then suddenly realized that all of the script data was missing and dumped it all into Oblivion. Except for the ones that were picking up from the save, but that stopped complaining too once I got near each driver.

 

Even after having done that though, I cannot get rid of the dummy scripts without a bunch of errors returning. Not just the usual "this script is missing" complaints. Actual errors that resurface from God knows where.

 

This sort of thing is why I an understand how people gravitate toward save cleaners. I just wish one existed that was actually safe.

Link to comment
Share on other sites

Would love to try this patch out... but for some reason, i don't have permission to download.  Emailed the admin on the site too yday, but no response yet.  Anyway to have this file on mediafire or something like that for us poor plebes?  thanks.

Link to comment
Share on other sites

Would love to try this patch out... but for some reason, i don't have permission to download.  Emailed the admin on the site too yday, but no response yet.  Anyway to have this file on mediafire or something like that for us poor plebes?  thanks.

 

Yep. As tyrel68 said, files in the "Files for Fixes" category are for the Unofficial Patch team to work on patch updates. They are the only ones who have access. However, v3.0 of the weapon rack overhaul is fully integrated into the 2.0 beta version of USKP, and this IS available for public download:

http://www.afkmods.com/index.php?/files/category/97-unofficial-patch-betas/

 

 

EDIT:

Alternatively, you can try the "Extended Racks" mod:

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

The scripts in there are at the same state-of-the-art as the USKP 2.0 scripts, but have been enlarged so as to provide additional functionality that goes beyond the bug fixes. They also support a new rack type (which is included with the mod). The mod has been designed as a standalone mod and will work whether or not you have USKP installed (because it uses its own set of properties). Note however, that it is not compatible with mods that alter the vanilla player homes (because it modifies some racks and adds new ones there).

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...