Jump to content

Overhauling the weapon rack scripts


Sclerocephalus

Recommended Posts

From now on papyrus is unknowable magic to me...makes more sense that way XD But you are proving yourself right you just keep finding new bugs

Link to comment
Share on other sites

I hate it when the engine throws mysterious obstacles in my way ... :crash:

 

[Horrible nonsense deleted]

 

Nevermind. This was all caused by a leftover placeitem command which was out of place and got cleaned up when the scripts were prepared to go live.

 

I hate it even more when I create the obstacles myself ... :facepalm:

Link to comment
Share on other sites

I wasnt able to follow everything but does this mean you are trying to fix the item not actually linked to the rack?

Link to comment
Share on other sites

No. I fixed (it already works ...) an issue with large items which overlap with the trigger volume of adjacent racks. Once these items are put on a rack, two (or even more) racks receive an OnTriggerEnter event and were disabled by the old script version, which made some racks inoperative even when they were empty. Even worse though when a large item was grabbed from an array of filled racks: this could turn all activators back on even when the racks were filled and there was no way to retrieve smaller items as they ended up entirely within the trigger volume of an enabled activator. All bows and crossbows and the Dragonbone battleaxe were causing this glitch, and it also happened far too often to the CoA racks, where placed shields overlapped with the trigger volumes of the adjacent plaques and weapons placed on these plaques overlapped with the trigger volume of the shield plaque. Shield plaque activators staying inactive when the shield was grabbed from a fully occupied rack (e.g. two weapons mounted on the adjacent plaques) was a very common bug in vanilla Skyrim.

 

To accomplish this, each activator will register (and continually update) the reference of the item mounted on the rack and store it in a property. When an OnLeave event fires, the trigger script compares the reference of the leaving item (the one that triggered the event) to the reference of the mounted item and only when they match it will turn the activator back on. Likewise, an activator will be turned off only after making sure that an item has been placed on its linked trigger and not on an entirely different rack.

Link to comment
Share on other sites

Kind of out of it and have a splitting headache (Advil, come one man, WORK) but that bit about the property variable. Let's stick to the name Bethesda gave it. If they're relying on it, others might be as well. Fixing it internally so it does what's expected would be best. Plus, we've not done any work on the next UHFP and I'm not going to issue an update just for that one script.

Link to comment
Share on other sites

Let's stick to the name Bethesda gave it.

 

As you like ... this was the last mssing detail to add.

 

The new version is up:

 

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

 

  1. Eliminated all issues with cross-activation of racks by large weapons placed on adjacent racks, which led to all sorts of glitches (racks becoming inoperative although empty, activators getting enabled although the racks were filled and making it impossible to retrieve the weapons placed on them, etc.). Cross-activation was notoriously an issue on with crossbows and large battleaxes on wooden racks, and with pretty much every item on the red wall-mounted three-in-one racks ("CoA racks"); shield plaques staying inactive when the shield was grabbed from an otherwise fully occupied rack was a common issue.
  2. Fixed an issue with pre-placed shields and weapons, which were moved back to their starting position upon reload whenever they were placed somewhere else (not even necessarily on a rack) in the same cell. This was because the starting item is never unlinked from the rack it was placed on and because the scripts never checked whether the starting items had been grabbed but repeated to handle (and place) them on every cell attach.
  3. Fixed an issue where the activator would stay enabled when the trigger was disabled. It will now properly disable itself when its linked trigger is disabled (this happens e.g. to most of the racks in military camps).
  4. Caught all mistakenly enable-parented activators and fixed them (53 in total)
  5. Fixed also an issue where some of these racks were linked to a wrong enable parent (bug #13189)
  6. Items that should not be put on any racks are now handled by a form list. This makes it a lot easier to add or remove items in the future, as it will not require to modify the scripts again.

  7. Added full support for crossbows.

  8. Added collision flags to all new item placement nodes that were missing them.

  9. Adjusted placement of the Falmer staff on wooden racks (rotated it slightly out of plane) since there was clipping when another Falmer staff was mounted on an adjacent rack.

  10. Modified the position of other staves on wooden racks, since some of them were ending up much higher on the rack than planned originally.

  11. Fixed clipping issue with the Falmer stavess on both plaques (left and right) of the CoA racks, which required modifications to another two trigger meshes (Meshes\Clutter\WeaponRack\WRPlaqueLeft01.nif and WRPlaqueRight01.nif)

  12. Fixed placement of the forsworn staves on the red wall-mounted single-weapon plaques, but had to exclude them from being placed in the large display cases (temporarily at least, until I have found out why they ignore the rotation values I set on their pivot and always end up in the same wrong position).

     

Alll additions and modifications have been playtested extensively during the last week, including the latest additions during the last 24 hours. Everything works as expected. I have included the script versions which I used for debugging, in case you would like to find out which items really end up on the rack.

 

EDIT:

Forgot to add two important things:

  1. All fixes are retroactive (tested with this version on my last save in the actual game)
  2. The scripts need some time to initialize their new properties now.  Grab all weapons from your racks (they will all end up inactive although empty - that's normal at this point), then leave the cell. Upon returning, the cell attach event running on the activator will do everything else for you and you can start using the racks immediately (there is no need to wait until the cell has undergone an unload and reload).
Link to comment
Share on other sites

yes, these keywords have been asigned to many uniques so that they may benefit from smithing perks (2* increased tempering strength from dwarven smithing in the case of the spellbreaker.)

 

so... would this potentially cause bugs with other uniques as well?

Link to comment
Share on other sites

No. This was the only case where a matching unique item had a keyword which is checked by the script (as far as I know, there are no unique Daedric shields and unique Dragonbone shields in the game with a geometry that markedly differs from those of the standard items).

Link to comment
Share on other sites

It is debatable whether the following is a bug or not:

 

The non-player house activators cannot be activated, but have the same scripts running on them and the same functionality. You only can grab items from them but not put any items on them. Though, only to grab items from them and to move pre-placed items in the right position would not require any script running on them (and not even an activator) but can all be arranged properly in the CK. Of course, there is a fairly large number of "dummy" racks with no activators that serve as display containers in NPCs' houses, but there is also a large number of racks that are fully configured. They have all triggers and activators properly linked together (what a waste of performance ...), but cannot be activated BECAUSE THEY ARE NOT NAMED ....

Link to comment
Share on other sites

Personally i would make all the scripts work properly iregardless if its the players house or not.

 

If everything is there then it only makes sense instead of making savegame bloat

Link to comment
Share on other sites

Hello Sclerocephalus (I hope I spelled the name right),

In the case of Ebony Blade, Keening, and other problematic items, you may want to look at this mod: Weapon Display FIX.

I believe I have read the whole thread, and I don't think persistent reference status of Ebony Blade and Ghostblade is being discussed here.

Link to comment
Share on other sites

possibly a fix but you have to remember the scripts we are dealing with are now vastly differant then the scripts they are dealing with

Link to comment
Share on other sites

In the case of Ebony Blade, Keening, and other problematic items, you may want to look at this mod: Weapon Display FIX.

I believe I have read the whole thread, and I don't think persistent reference status of Ebony Blade and Ghostblade is being discussed here.

 

This is the fix that had already been included in USKP 1.3.2c. I have tested a script modification with and without this fix in place and eventually removed it because it did NOT fix the issues with the ebony blade, Keening and the ghostblade (these weapons simply refuse to cooperate), and because all other issues which it claims to fix are fixed as well by just removing the logics bugs from the vanilla scripts.

 

Most issues with weapons falling to the ground had nothing to do with persistent references but were caused by (1) a fat bug in the item placement handling of the WeaponRackActivateScript, where the Is3DLoaded check was nestled within an if-then statement which was never carried out for pre-placed weapons (the results could be observed at the northern watchtower of Whiterun and on the roofs of Fort Dawnguard), and (2) by overloading the trigger script with a vast number of events which it was unable to evaluate properly.

Link to comment
Share on other sites

:celebration:

 

I have been running the last uploaded version for almost two full days now. Everything works as expected and I did NOT find any NEW BUGS.

Nonetheless, there will be a final update later this day to make the scripts perfect. That is, you won't even have to grab the weapon from a rack, leave the cell and return until it works properly with the new script. Actually, most of the racks have this functionality already, except for the shield plaque, so I will have to modify a condition check in the trigger script one last time.

 

Thus, it is pretty much unlikely that I may start rambling like a madman eventually ...

 

I will be mostly offline during the next two weeks or so, because my actual hobby requires at least one full week of attention:

http://www.mindat.org/user-600.html#2_0_0_0_0__

:miner:

Link to comment
Share on other sites

Some final comments:

 

While the latest modification helped to get the shield plaques' parameters more quickly initialized when the new scripts run for the first time, I cannot guarantee that all plaques will flawlessly work on a first visit to the cell. There simply are some racks whose state (i.e. whether they have a weapon placed on them or not) cannot be checked with certainty (the trigger object count used by the old scripts for that purpose is too ambiguous - for empty racks, it may vary from 0 to 2!). Thus, a few things will be important to make the new scripts work properly as quickly as possible (EDIT: see below).

 

There will be no more updates, except somebody else spots a bug ...

I also may work again on the item placement nodes, but this is neither urgent nor will it require to modify the scripts again.

 

EDIT:

I feel that I need to explain this in more detail:

  • Don't install the new USKP version on a save where your character is in a cell with usable racks (e.g. in a player home). Leave the cell, save, quit, then upgrade, restart the game amd reload. When you enter the same cell now, it will have to be reloaded and the new trigger script will be already active.
  • The new activator script will be running too already, but this doesn't mean that the racks are fully functional at this point. This is because two new properties were added to handle all tasks without glitches, and one of these properties has the same name as a property on the old script, although it is in fact a new variable (or, more precisely, it will be regularly updated which the property on the old script was not). We had to leave the name, because one of the Hearthfires scripts is accessing this property and relies on it being there (amusingly, said Hearthfires script actually requires the functionality of the variable on the new script and did not work as intended with the old script anyway ...), but the value of this property (which is baked in your save and will be loaded into the new script) may be misleading and therefore will be considered as meaningless by the new script when it runs for the first time.
  • In other words, the new script will try to reinitialize the racks. That's easy for most empty racks, and they will start enabled on your first visit to the cell and can be used immediately. Others, however, will remain disabled although they are empty. This is because they are cross-activated by oversized weapons on adjacent racks, which extend into their trigger volume. Once the rack is initialized, the script will permanently hold the reference of the item that is actually placed on the rack i(none, if the rack is empty) in the new property already mentioned, and it will ignore all sorts of cross-activation (which the old scripts could not). To make this work, however, this property needs to be properly initialized. That is, it needs a reliable start value, and the most reliable start value (and also the one which is most easily detected unambiguously) is an empty rack. Therefore, grab ALL weapons from your racks and leave the cell. Upon returning (because the activator script will run its initialization on cell attach), all racks will work as expected.
Link to comment
Share on other sites

  • Don't install the new USKP version on a save where your character is in a cell with usable racks (e.g. in a player home). Leave the cell, save, quit, then upgrade, restart the game amd reload. When you enter the same cell now, it will have to be reloaded and the new trigger script will be already active.

Will those racks script affect any item that's already attached to a rack or to a wall shield whatever it was called?

Link to comment
Share on other sites

No. They do what the vanilla scripts did - only better ... :grin:

Link to comment
Share on other sites

It appears that some things are never fully done ....

 

(1) I made a mistake. Somehow, the activator script packed in the 2.40 all-in-one version is still version 2.3. Only the trigger scripts should remain at 2.3 (because they were not modified again), but I made a final edit to the activator script. Unfortunately, this very slight difference decides on whether or not the script will be able to restore pre-placed weapons on racks that were messed up by the vanilla scripts ...

I'm very sorry for the inconvenience and have already replaced the archive.

 

(2) For my own convenience, I did add a few lines of extra code to the activator script some while ago to reset its properties. Thinking now about all the states the beta went through, it would probably not harm if you include this in the final and make it so that all racks are forced to reset. For racks that have not run their initialization, it makes no difference whether they start as normal or with a reset, because their properties are still at their default values anyway. It makes a difference though when someone did install one of the beta versions and then upgrades to final on the same save (it's out of the question that this will happen although everybody should know better). I have uploaded this modification as version 2.50.

 

The reset procedure works as follows: There is a new global in the esp file (USKPRackResetGlobal), which has a default value of zero,  and a new boolean property on the script (RackResetDone). Once USKPRackResetGlobal is set to anything else than zero, the script will reset its properties to their default values and re-evaluate them again (in other words, it repeats the initialization procedure). Once this is done, RackResetDone will be set to true, which makes sure that the reinitialization runs only once. Now, if USKPRackResetGlobal is reset to zero, the script will reset RackResetDone to false (but won't do anything else because the properties don't get reset when USKPRackResetGlobal = 0) and I can repeat the whole process if that should become necessary. Therefore, if this version will be implemented rather than version 2.4, I recommend to set the global to one from the beginning.

Link to comment
Share on other sites

It appears that some things are never fully done ....

 

(1) I made a mistake. Somehow, the activator script packed in the 2.40 all-in-one version is still version 2.3. Only the trigger scripts should remain at 2.3 (because they were not modified again), but I made a final edit to the activator script. Unfortunately, this very slight difference decides on whether or not the script will be able to restore pre-placed weapons on racks that were messed up by the vanilla scripts ...

I'm very sorry for the inconvenience and have already replaced the archive.

 

(2) For my own convenience, I did add a few lines of extra code to the activator script some while ago to reset its properties. Thinking now about all the states the beta went through, it would probably not harm if you include this in the final and make it so that all racks are forced to reset. For racks that have not run their initialization, it makes no difference whether they start as normal or with a reset, because their properties are still at their default values anyway. It makes a difference though when someone did install one of the beta versions and then upgrades to final on the same save (it's out of the question that this will happen although everybody should know better). I have uploaded this modification as version 2.50.

 

The reset procedure works as follows: There is a new global in the esp file (USKPRackResetGlobal), which has a default value of zero,  and a new boolean property on the script (RackResetDone). Once USKPRackResetGlobal is set to anything else than zero, the script will reset its properties to their default values and re-evaluate them again (in other words, it repeats the initialization procedure). Once this is done, RackResetDone will be set to true, which makes sure that the reinitialization runs only once. Now, if USKPRackResetGlobal is reset to zero, the script will reset RackResetDone to false (but won't do anything else because the properties don't get reset when USKPRackResetGlobal = 0) and I can repeat the whole process if that should become necessary. Therefore, if this version will be implemented rather than version 2.4, I recommend to set the global to one from the beginning.

 the life version of 1.3.3 seems to still have issues.

 

several reports on the Bethesda forum thread meantion floating weapons in many places even with a new game (places mentioned among others Jorrvaskr and Warmaidens.

just posting here, too because the change log mentiones this discussion thread specifically.

Link to comment
Share on other sites

 the life version of 1.3.3 seems to still have issues.

 

several reports on the Bethesda forum thread meantion floating weapons in many places even with a new game (places mentioned among others Jorrvaskr and Warmaidens.

just posting here, too because the change log mentiones this discussion thread specifically.

 

Not a surprise. That version had two condition checks in the wrong order.

 

The script must handle the starting item first. The script version in USKP 1.3.3 does the initialization first and in this process, new values may be set that are used when it checks whether the starting item was grabbed or not. In the case of pre-placed weapons (because they were placed in the CK way off the rack and its activator), this leads to the StartingItemHasBeenGrabbed property being always set to true. In other words, that script version actually never handles any pre-placed weapons (although it has the code to do it).

 

Again, this was my fault because I packed the wrong script in the archive. On the other hand, I did report this mistake three days ago. The new script (more precisely, the correct one) does even restore previously messed-up racks retroactively. It's really just the order in which the tasks are carried out that makes an enormous difference here.

 

To complete this, I also did upload a version 2.4e two days ago, which has the correct script in it as well. There's otherwise nothing new in that version; I just removed a few lines of code from both scripts that had become superfluous.

 

Please add a link to this comment on the Bethesda forum (if that's convenient), so people get at least an explanation for this issue.

Link to comment
Share on other sites

i did so.

i thin it was a bit confusing with the versions in the end. 2.5 is this in the 1.3.3 release now?

 

2.4e is what should go into the patch now, and it will fix the issue?  i would give it a quick look, but i can not download it.

good thing is: with the DDoS on the Nexus, bug reports and downloads have been relativelly low still. :-D

Link to comment
Share on other sites

Not a surprise. That version had two condition checks in the wrong order.

 

The script must handle the starting item first. The script version in USKP 1.3.3 does the initialization first and in this process, new values may be set that are used when it checks whether the starting item was grabbed or not. In the case of pre-placed weapons (because they were placed in the CK way off the rack and its activator), this leads to the StartingItemHasBeenGrabbed property being always set to true. In other words, that script version actually never handles any pre-placed weapons (although it has the code to do it).

 

Again, this was my fault because I packed the wrong script in the archive. On the other hand, I did report this mistake three days ago. The new script (more precisely, the correct one) does even restore previously messed-up racks retroactively. It's really just the order in which the tasks are carried out that makes an enormous difference here.

 

To complete this, I also did upload a version 2.4e two days ago, which has the correct script in it as well. There's otherwise nothing new in that version; I just removed a few lines of code from both scripts that had become superfluous.

 

Please add a link to this comment on the Bethesda forum (if that's convenient), so people get at least an explanation for this issue.

I think Arathmoor took the fix down thinking it was completed, maybe he made a mistake copying either way the fix isnt online anmore

Link to comment
Share on other sites

To complete this, I also did upload a version 2.4e two days ago, which has the correct script in it as well. There's otherwise nothing new in that version; I just removed a few lines of code from both scripts that had become superfluous.

 

i thin it was a bit confusing with the versions in the end. 2.5 is this in the 1.3.3 release now?

 

2.4e is what should go into the patch now, and it will fix the issue?  i would give it a quick look, but i can not download it.

good thing is: with the DDoS on the Nexus, bug reports and downloads have been relativelly low still. :-D

He's not clear. I think the final version belongs in 1.3.3 -- that is, 2.5.

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