Overhauling the weapon rack scripts

[DayDreamer]

Sclerocephalus thought that the fix in 2.0.0 was not retroactive, but I have to say I'm thoroughly confused at this point

It turns out that part of Sclerocephalus' fix in 2.0.0 wasn't actually done. A file was provided, and is in the release, but not actually linked in.

 

However, it may not be necessary. Proper programming can clean up the problem.

 

Have you tried my fix?

[taleden]

What problems were/are you having in Honeyside? I haven't had any trouble there except the glitch in scripted item detection, but that's not specific to any particular racks. Is this on a new game? If not, what version of USKP did you start with on that save?

[BlackPete]

(a) What problems were/are you having in Honeyside? I haven't had any trouble there except the glitch in scripted item detection, but that's not specific to any particular racks. (b)Is this on a new game? If not, what version of USKP did you start with on that save?

(a) The weapon rack (set of five I think) in the basement and then the three display plaques cannot be activated (i.e. there's no option appearing to "place or activate the weapon racks/displays").

 

(b) No, the game I'm talking about regarding the Honeyside basement problem was created with v. 1.3.3c. They were not working in that version either, as I think I mentioned in one of my prior posts. Thanks for helping me, I appreciate it.

 

 

It turns out that part of Sclerocephalus' fix in 2.0.0 wasn't actually done. A file was provided, and is in the release, but not actually linked in.

 

However, it may not be necessary. Proper programming can clean up the problem.

 

Have you tried my fix?

No, I haven't tried your fix, but since I not really good at this stuff, I have a few questions. First, is it just a matter of loading these scripts (mod files) one time into the game and then removing them, or does it need to stay in my data folder permanently? Also, just say I was to start a new game, should these "mod files" be deactivated (in the game launcher) on a new game to avoid problems? Thanks for the help.

[DayDreamer]

No, I haven't tried your fix, but since I not really good at this stuff, I have a few questions. First, is it just a matter of loading these scripts (mod files) one time into the game and then removing them, or does it need to stay in my data folder permanently? Also, just say I was to start a new game, should these "mod files" be deactivated (in the game launcher) on a new game to avoid problems? Thanks for the help.

It's a regular old mod file. Just copy 3 files to the game Data folder (esp, bsa, bsl), and check the box in the launcher. I haven't tested removing it yet.

 

Once added, you keep it for the rest of the game, just like any other. Of course, it's still in beta, so I'd not use it on a game you are planning on keeping. we just need testers for now. But hopefully will be confident for permanent installation in a few days (with enough testers).

 

But it is very important to know whether it fixes your USKP 1.3.3 game.

 

I'm testing it on a 1.2.5 to make sure it works for older games. So far so good.

[BlackPete]

It's a regular old mod file. Just copy 3 files to the game Data folder (esp, bsa, bsl), and check the box in the launcher. I haven't tested removing it yet.

 

Once added, you keep it for the rest of the game, just like any other. Of course, it's still in beta, so I'd not use it on a game you are planning on keeping. we just need testers for now. But hopefully will be confident for permanent installation in a few days (with enough testers).

 

But it is very important to know whether it fixes your USKP 1.3.3 game.

 

I'm testing it on a 1.2.5 to make sure it works for older games. So far so good.

I'll try it out and let you know if it fixes any of the issues that I've been having. Hopefully, if it's successful it can be put into the next version of the USKP, so that weapon racks will work and hold weapons properly again.

[DayDreamer]

 

However, it does not consult the exception list when deciding if the player's placed item is allowed to be placed. So if I have an Iron Sword, and I grab a pre-placed Iron Sword, then equip it and try to place it again, it will print the message and let the sword drop on the floor every time. This is due to your test container receiving the persistent copy, but then when it sends that copy back to the player, DropObject() drops the other copy instead. We discussed it a few pages back.

 

Can anyone else reproduce this? Here's what I'm doing:

1. 'coc riftenmistveilkeep' from the menu (usually not advised for testing I know, but in this case, quest initialization shouldn't matter for the rack scripts)
2. 'setstage a7b33 10' to get honeyside
3. 'player.additem f 10000' for some cash
4. buy the bedroom upgrade
5. make sure you have an iron sword in inventory, but don't equip it yet
6. go in and take the iron sword off the rack over the bed
7. equip an iron sword
8. try to place it again
9. watch it fall on the floor
10. pick it up, equip it, try to place it again
11. goto step 9

I started with a v1.8+USKP 1.2.5 save that happened to be in front of the Jarl. Did steps 2, 4, 5, 6, 7, 8. It did not fall. Left the building, went back in, all OK.

 

Unfortunately, my patch is backward from what I'd intended; it uses Sclero's chest. So I swapped files and tried your non-chest variant, too.

 

The obvious difference is that Sclero's puts the other sword on the rack. Yours puts the original starting weapon on the rack. My code then continues to recognize it as the starting item.

 

But I've got a nice set of logs for comparison. Since we are all doing the same steps, we should be able to compare notes. (But I'm typing on the Mac, so I'll have to copy logs from the PC.)

[BlackPete]

It's a regular old mod file. Just copy 3 files to the game Data folder (esp, bsa, bsl), and check the box in the launcher. I haven't tested removing it yet.

 

Once added, you keep it for the rest of the game, just like any other. Of course, it's still in beta, so I'd not use it on a game you are planning on keeping. we just need testers for now. But hopefully will be confident for permanent installation in a few days (with enough testers).

 

But it is very important to know whether it fixes your USKP 1.3.3 game.

 

I'm testing it on a 1.2.5 to make sure it works for older games. So far so good.

  

I'll try it out and let you know if it fixes any of the issues that I've been having. Hopefully, if it's successful it can be put into the next version of the USKP, so that weapon racks will work and hold weapons properly again.

Okay, I tested this fix out (with the 1.3.3c created save) and it does indeed fix the issue in the Honeyside basement. It also fixes the problem with certain non-player racks not holding weapons (example: Whitewatch Tower, Shor's Watchtower, and outside Alvor's House in Riverwood). I know this probably wasn't recommended, but I tried taking the files out after loading them into my game once and the weapon racks as mentioned above function again as they should still, even though the fix files are gone. I hope this helps you guys get this sorted out and perhaps get this into the next USKP or UHFP version.

 

Edit: Also, if you would like one of my 1.3.3c created saves for working this problem out for some reason, let me know and I'll provide one for you.

[DayDreamer]

I've added 4.4td for Talenden's v3 weapons test. This is for the weapons that weren't staying on the racks.

 

EDIT: I meant to attach it to this entry, but it didn't show up. You can find it at: http://www.afkmods.com/index.php?/files/file/944-weaponrack/

[BlackPete]

I've added 4.4td for Talenden's v3 weapons test. This is for the weapons that weren't staying on the racks.

 

I meant to attach it to this entry, but missing. You can find it at: http://www.afkmods.com/index.php?/files/file/944-weaponrack/

Is this a stable (non-beta release)? If not, I will wait until it is added into the next USKP or a final release is available, since I'm playing on a game I want to keep. As mentioned above, the mods you provided did solve the issues with the 1.3.3 save (which is awesome!), but I'm hesitant to add them permanently until the issues are completely ironed, out of fear of it causing bad or non-reversible things to happen in my save file.

[DayDreamer]

Is this a stable (non-beta release)? If not, I will wait until it is added into the next USKP or a final release is available, since I'm playing on a game I want to keep. As mentioned above, the mods you provided did solve the issues with the 1.3.3 save (which is awesome!), but I'm hesitant to add them permanently until the issues are completely ironed, out of fear of it causing bad or non-reversible things to happen in my save file.

Nope, it's the same thing with a different test for putting weapons on the rack.

 

I'll let you know when the final release is available. Arthmoor has stated the next USKP isn't for another 3-4 months.

 

But I really thank you for your help testing.

[DayDreamer]

Question: Many places with the 3 part CoA racks actually have 5 parts on the wall. A second set of left and right are present, but reversed.

 

They don't attach to anything. Are they there for beauty? Or are they a mistake that should Z -32000?

[Arthmoor]

If you mean like the ones in Honeyside that are turned backward and face the wall I think they were put there because they were floating too far from the wall otherwise.

[taleden]

Sclero, what is the reason for handling the starting item totally separately from the player item in InitActivator() ? Was that done because you had to re-PlaceItem() on attach to keep starting items from falling, but player items seemed to stay put without that?

 

Since all persistent references have to be re-placed to keep from falling after cell reset, I'm wondering if it would make sense to just test for the starting item once when it first loads, and then put that pointer into PlayersDroppedWeapon so that afterward it will be handled (including re-positioning) just like the player item. What do you think?

[DayDreamer]

If you mean like the ones in Honeyside that are turned backward and face the wall I think they were put there because they were floating too far from the wall otherwise.

OK, beauty then. Shouldn't we just adjust the plaques to be closer to the wall? The center rack doesn't have a reverse component, so it must be OK.

 

Since all persistent references have to be re-placed to keep from falling after cell reset, I'm wondering if it would make sense to just test for the starting item once when it first loads, and then put that pointer into PlayersDroppedWeapon so that afterward it will be handled (including re-positioning) just like the player item. What do you think?

Since the dummy items are given new temporary object identifiers, you have to update the PlayersDroppedWeapon every time. Meanwhile, player's racks are only working properly in no-reset areas.

I go one step further and clear the starting items out OnCellDetach -- so that every attach is like entering the room for the first time. This fixed the reset problem I noticed at Alvor's, where dummy items weren't always handled correctly. And as a (planned) side effect, cleared out the bad pointers in Honeyside.

[DayDreamer]

Talenden, you mentioned earlier that you weren't able to use a player alias on the chest quest to integrate your alias script. Any details?

Arthmoor, the two quests (Sclero and Talenden) are both SEQ and Run Once. SEQ is probably OK, but should they be Run Once? Might that be the cause of the problem integrating the two?

[taleden]

Talenden, you mentioned earlier that you weren't able to use a player alias on the chest quest to integrate your alias script. Any details?

 

When I added a reference alias (specific -> player) to the chest quest and loaded a save which already had that quest running, the alias didn't seem to fill -- at least, the alias script didn't get the player events it was supposed to. I didn't investigate further than that because I wanted to get the proof of concept out, so I just made a new quest to put the alias in and that worked fine.

[taleden]

Is it necessary to have two separate functions that decide if a particular item is allowed on a particular rack? HandlePlayerActivation() does it using GetEquippedItemType(), while HandleStartingItem() does it with HasKeyword. Are the two not equivalent? Could we just make one function that checks the rack type and form keywords and returns an appropriate Message on error, or None on success? Then both Handle...() functions could just call that and either display the error for the player, or silently ignore the starting item.

[DayDreamer]

The obvious difference is that Sclero's puts the other sword on the rack. Yours puts the original starting weapon on the rack. My code then continues to recognize it as the starting item.

Other than the above, do we have any other technical reasons why the alias method is better than the chest method?

The alias method seems to handle scripted swords.

Is the chest method able to handle all the scripted swords?

[DayDreamer]

Is it necessary to have two separate functions that decide if a particular item is allowed on a particular rack? HandlePlayerActivation() does it using GetEquippedItemType(), while HandleStartingItem() does it with HasKeyword. Are the two not equivalent? Could we just make one function that checks the rack type and form keywords and returns an appropriate Message on error, or None on success? Then both Handle...() functions could just call that and either display the error for the player, or silently ignore the starting item.

It was called RunPlayerActivation() in 2.0. HandlePlayerActivation() might be a better name, tho.

That's original code. I have no idea whether the GetEquippedItemType() are exact matches for the HasKeyword().

Is there any known error in this code (other than the missing Else where I've already added an error log), or was it for personal satisfaction?

[taleden]

Other than the above, do we have any other technical reasons why the alias method is better than the chest method?

The alias method seems to handle scripted swords.

Is the chest method able to handle all the scripted swords?

 

I think the only advantage of the chest method is the guarantee that the exact instance which the player had equipped is the one that goes on the rack, by virtue that RemoveItem() will take the equipped instance first. Using the player alias, if the equipped item is not persistent (so OnObjectUnequipped() receives no ref pointer) and the player has another copy in inventory, then I'm not sure if DropObject() will decide to drop the instance which was equipped, even if you explicitly unequip it first.

 

In my current streamlining, I'm going with the player alias because the code is simpler and requires no chest. I think the only danger to this is that if the player has two copies of the same base item which they can actually tell apart (i.e. one is tempered or enchanted) and equips one of them to mount, its possible that the other one will be taken instead. But maybe not, needs some testing.

 

Is there any known error in this code (other than the missing Else where I've already added an error log), or was it for personal satisfaction?

 

It mostly just seems dubious and error-prone to have two copies of the same logic (rack -> itemtype compatibility) implemented in two different ways. But I've also improved the player activation routine to try the left-hand item if the right-hand fails, and for that purpose it is also convenient to just have one compatibility test function that can be called on each candidate, rather than having to duplicate all of those tests a third time.

[DayDreamer]

That's original code. I have no idea whether the GetEquippedItemType() are exact matches for the HasKeyword().

GetEquippedItemType() is not an exact match for the HasKeyword(). There are more Keywords.

 

It mostly just seems dubious and error-prone to have two copies of the same logic (rack -> itemtype compatibility) implemented in two different ways. But I've also improved the player activation routine to try the left-hand item if the right-hand fails, and for that purpose it is also convenient to just have one compatibility test function that can be called on each candidate, rather than having to duplicate all of those tests a third time.

Well, since it is a separate function, we could rename it TestPlayerActivation() and make it boolean. So you could test the right hand and then the left.

But the shield will always be left hand....

When I tested, I tried equipping an iron sword in both hands. It always took the right hand. (That was the chest version.)

But this seems less of a bug fix and more of an enhancement. I say avoid complications.

[taleden]

GetEquippedItemType() is not an exact match for the HasKeyword(). There are more Keywords.

 

Yeah, but the extra keywords are WeapTypeBattleaxe and WeapTypeWarhammer, which GetEquippedItemType() lumps together under 6. The others are all 1:1 as far as I can see.

 

Do we even know what makes GetEquippedItemType() return a given number for a given form? Looking at the Weapon interface in the CK, it seems like it might be returning the Anim Type (since that also conflates 2h axes and maces). So the next question is, which do we consider more reliable? Presumably the whole point of this test is to not put something on the rack whose 3d model won't fit nicely (like daggers hidden behind shields), but we're not testing the 3d model, so is there some reason to believe that Anim Type is a more or less reliable approximation than the Keywords?

 

When I tested, I tried equipping an iron sword in both hands. It always took the right hand. (That was the chest version.)

But this seems less of a bug fix and more of an enhancement. I say avoid complications.

 

When I said "I have" I meant in my working copy, not the last one I posted. All released scripts take the right hand or bust (except shields) as far as I know.

 

Whether the left-hand check is a fix or an enhancement could be debated I guess. I know as a player it sure felt like a bug that I couldn't mount both dual-wielded weapons in a row, I had to mount the mainhand and then move the offhand to the mainhand before mounting that. Or activating a dagger case with an offhand dagger, and being told I need a dagger (I have a dagger! It's right here!).

[DayDreamer]

Whether the left-hand check is a fix or an enhancement could be debated I guess. I know as a player it sure felt like a bug that I couldn't mount both dual-wielded weapons in a row, I had to mount the mainhand and then move the offhand to the mainhand before mounting that. Or activating a dagger case with an offhand dagger, and being told I need a dagger (I have a dagger! It's right here!).

Hmmm, I see your point. I didn't know that you could activate with an off-hand. I don't remember trying it.

I'm trying to find the papyrus that returns the hand on activation and am not finding it.

GetEquippedItemType - Actor needs to know the hand.

[taleden]

Hmmm, I see your point. I didn't know that you could activate with an off-hand. I don't remember trying it.

I'm trying to find the papyrus that returns the hand on activation and am not finding it.

GetEquippedItemType - Actor needs to know the hand.

 

I didn't mean that you can activate "with an off-hand", you're right that activation is just activation, the player doesn't choose which hand to activate "with".

 

But if you have a sword in your right hand and a dagger in your left hand, and then you activate a dagger case, won't it currently tell you that you need a dagger because it only looks for one in the right hand? Likewise if you have an empty right hand and a weapon in your left hand, any weapon rack currently says that you must have a weapon equipped. I think in both of those cases it would be reasonable for the rack to just take your left hand item instead, since that's probably what the player intended when they activated the rack with an empty/invalid right hand.

[DayDreamer]

I think in both of those cases it would be reasonable for the rack to just take your left hand item instead, since that's probably what the player intended when they activated the rack with an empty/invalid right hand.

OK, I can see that. It actually isn't very hard code.

 

However, I have a guess as to the reason for using GetEquippedItemType (1) and GetEquippedShield() instead of Keywords. The object is still in inventory, and not a real object. It doesn't test Keywords until the object has been removed from inventory.

 

Or as vanilla code says: "; Force the weapon to be dropped, and get it's reference" [sic]