Search the Community

It has been over a decade since several different attempts by several programmers. Having just reviewed and repaired them again, best to write things down for posterity. Weapon racks have 2 main parts: a visible part. It uses WeaponRackTriggerSCRIPT. Unlike most visible actuators (such as seats), it does not cause any action. Instead, it merely triggers as a weapon is passed near it. Usually, that trigger is something being added to the rack, or to another rack nearby, and must be ignored. Sometimes, that trigger is a player removing a weapon or armor item from the rack. an invisible trigger marker placed directly in front of the visible part. It uses WeaponRackActivateSCRIPT, and has ACTIVATOR in its name. When triggered, the script places a weapon into the front of the visible part using MoveToNode(). The visible part has many such named attachment "nodes". Because of the unusual design, there were many locations that simply had the wrong script on the objects. It became apparent that various designs were attempted, and some old designs with the wrong scripts or variables remained in the files. So a significant US*P change to the scripts was adding a CheckConfiguration() function to log places with bad setup so that they could be repaired later. Although the design expects that the visible part has a pointer to the invisible part, and vice versa, there was no check. (A check was added.) Many locations have no invisible part. Others had/have the invisible part in front of the wrong rack, or even underground. Again, there is no easy check. There are many flavors of racks. Most do not actually allow a player to add a weapon to the rack. But they use the same scripts, so the scripts have to account for all possibilities. Some have PlayerHouse in the name, and allow a player to add a weapon to the rack. Others are specific to locations. A few OLD and Nor designs are unused. Some are used as backing plaques, or as decorations, and their scripts were deleted from them. Others used another technique to disable the rack parts, such as pointing the rack to itself, or to the player object. There is not much implementation consistency. Finally, the ACTIVATOR can point to a StartingWeapon. This can also be armor. All of the item pointers are stored in the invisible WeaponRackActivateSCRIPT property PlayersDroppedWeapon, instead of the visible rack itself. Therefore, every rack with a starting item requires an invisible ACTIVATOR, even though most racks do not accept player weapons so the activator is otherwise unused. Inefficient and cumbersome, and not all Bethesda developers understood the design. Many racks were missing an ACTIVATOR. Many more have an unused ACTIVATOR that does nothing. Unfortunately, there were originally two methods of pointing to the StartingWeapon: GetLinkedRef() or GetLinkedRef(WRackStartingWeapon). However, only the rare WeaponRackDaggerDisplayACTIVATORPlayerHouse specified the latter, and it was never used. So that complication was removed from the scripts.

I was farming for the Dawnguard cache random encounters and was able to find Saliah and Lynoit, but not Hakar. I checked the corresponding quest (DLC1_WESC06) and its entries in the Story Manager in the CK, to see if there were any specific conditions I wasn't meeting. I found out that this particular encounter is classified both as a wilderness encounter (WEQuests) and a road encounter (WERoadQuests), and that can only be found in the hold of Whiterun from 0:00 to 8:00 AM. After a while of still not being able to find it (I was also checking Frosfruit Inn in Rorikstead just in case, since it's supposed to be Hakar's destination), I went into the CK and deleted all the other road encounters from the Story Manager, only to find no random encounters at all in those WETriggers that are only associated with road encounters (which means that wilderness encounters can't be spawned). I tried to, instead of leaving only the Hakar encounter, leaving instead one with no conditions, such as Drinking Companions, that one in which you find three Revelers drinking Honningbrew Mead. After testing it in-game, every road encounter was either this one, or nothing at all. So, my next step was checking the quest stages for the Hakar encounter in the CK, to then use the command getstage only to find out that it was set to 255, which is the "shutdown stage". I waited for 10 in-game days to see if the stage would reset back to 0, but it didn't. Then, I checked out the DLC1_WESC06 main script, and I compared it with the scripts for the other two Dawnguard cache encounters: Saliah and Lynoit. Now, I have no idea about Papyrus and scripting in this game, but this particular line of code: (Alias_Trigger.GetReference() as WETriggerScript).ReArmTrigger() seems to be related to restarting the quest. I've found it to be preceded (or followed) by the use of the DeleteWhenAble() method on the references of the various aliases that form the quest. Now, when I used the resetquest command, the quest stage changed back to 0, which allowed me to find the random encounter on my first try (after deleting all the other road encounters from the Story Manager, as I did previously). At first, I thought that stage 255 had been set in my game at some point because the random encounter happened but I didn't notice it, and Hakar died. But, looking at the script, it seems that stage 10, not 255, is the one set when Hakar dies, stage 20 when one of the vampires dies, stage 30 when both vampires die and stage 40 after Hakar greets you and drops his armor, note and key. So, my questions are: 1. How does the quest reach stage 255? 2. Does this quest reset at some point or is it a one-time encounter that you can just miss forever if you don't realize that the game loaded it at some point?

It's been out over a year, which was about how long it took for SKSE64 to be finished. SKSE VR has been out for awhile, and also SkyUI VR. What do we need to get USVRP/USSEP working? Creation Kit 2 can be made to work (according to forum posts), but the scripts don't match. Do we have a good direct contact at Bethesda? The reason that I'm asking is dozens of folks have asked for Touring Carriages VR. So I've recently purchased a Valve Index. OTOH, Steam Charts says that only hundreds of folks are running VR (280 at this moment), relative to the tens of thousands still running LE (7109) and SE (13788).

During the last week, I have been going through the weapon rack scripts and found many bugs and glitches that have not yet been adressed. The fixed versions can be downloaded here: http://www.afkmods.com/index.php?/files/file/701-overhauled-weapon-rack-scripts/ The download also contains two comments files (one for each script) where I explain what was changed and why I'm convinced that it had to be done. As usual, I am not sure that I have spotted all of the bugs, but I am pretty confident that the scripts will provide some improvement. Since this is a pretty "fresh" work, I haven't had the time yet to do much testing myself. You can be assured however, that I wouldn't have uploaded the files if was aware of a risk of them ruining your game or resulting in immediate crashes. Thus, if someone's interested in doing some testing, I really would appreciate your help (before installing the new scripts, please read the notes on the "dwarven shield bug" below). Also, it would be fine if someone could go through my comments to see whether anything else can be spotted which I might have overlooked or misinterpreted. The Dwarven shield bug: ==================== If a Dwarven shield is placed on a shield rack, it will horribly clip through the rack and the wall behind it. This bug was reported on the tracker a long time ago, but hasn't been resolved yet. There's actually not much that can be done about it: modifying the shield's pivot is out of the question because it will break a lot of other things. However, we could add a new node to the shield rack, for use by Dwarven shields specifically (it apperas that this can be rather easily done in nifskope). The placement is very easily handled in the WeaponRackActivatorScript as it requires only three extra lines and while I was at it anyway, I have added this code to my modified version of the script (before testing the scripts, please delete the respective lines; the comments file for the WeaponRackActivatorScript explains how to do this - EDIT: This doesn't need to be done anymore: the download now includes "ready for testing" versions with all the necessary modifications already implemented). Of course, this solution is debatable and I don't even know whether the USKP wants to address it at all.