Devious Device Scripting Question

[scoul73]

I have a question on Devious Device scripting. Unforgiving Devices, actually, but I can probably figure out one from the other. I am still pretty new to Papyrus scripting, but have experience with other scripting. And my question is probably more about Papyrus scripting in the end anyway.

 

Basically, I want a SPECIFIC item to carry a "charge" that changes in response to conditions and events. I don't mean the device type, but a specific one in inventory. I can figure out how to do that with a regular item, but the zad/DD/UD system with separate inventory and render devices confuses me.

 

I think that the DD system works by having the inventory device create the render device when equipped, and destroying it again when unequipped. Attempts to interact with the device are routed from the inventory device to the render device, and the render device handles events. This works fine because there is a 1-to-1 correspondence between the type of inventory device and the type of render device. But to make a charged item work, I would need to get/set the charge value on the inventory item, from the render item.

 

I don't think that there is a simple way to do this, because I think the inventory item is only ever a base item, and not a persistent item that I can get a reference ID on. I don't want to change core zad/DD/UD scripts for obvious reasons, so can anyone give me a pointer on how to make this work?

 

I know that I can make a NEW persistent inventory item with a Papyrus "placeatme" command, but I don't think this helps me. I guess I could have any non-persistent version immediately create a persistent version in its place (on init, or on container change, or something) and delete itself? Otherwise, I think I can make an item temporarily persistent by registering it to receive an event, or pointing a quest reference alias at it?

 

And after that, how do I actually get the reference ID into the render script? Script properties get me access to the base object, but not a specific object, right? Because the system is designed to work with base objects only? The first solution I have for that is to pass the reference ID through StorageUtil, by extending the equip script (or adding a second script) to drop it in with a custom key, and the render script plucking it out again with that key.

 

Any advice? I will start experimenting with the above (after several previous attempts didn't pan out), but I hope I am overcomplicating it, and someone can say "just do it this way, you dolt".

 

[khenapart]

Hi! Did you ever find a fix for this issue? I believe I’ve got the exact same problem with same versions of the mods
 

[Frayed]

You're not overcomplicating things, unfortunately. I've burned my fingers on similar things when I first started making mods involving DD. You might be able to associate your state with the inventory device, though. That's the persistent one, it carries scripts that themselves already track state, and it's also the one that can be dropped into the game world. The rendered device only exists while it's equipped on the player, but it's the one that actually counts as equipped for the purposes of visuals, slot masks, armor values, keywords and enchantments. You could consider adding an extra script for your charge state on an inventory device. Best if you add your own devices for that though (you can just duplicate DD's) - modifying DD's items directly will be tricky with conflict resolution.

 

A word of caution, though: Skyrim is a little bit weird about items when they move between the game world and the player's inventory. Consider for example stacking two items with scripts on them: if you drop or equip one, which one is it? The two script instances may not have the same property values, so you'd have to dig into how the game resolves that, which is a nasty can of worms. I don't actually know the specifics of how the game resolves it.

 

If possible, it might be preferable to avoid associating your state with an actual item instance. If you don't care about tracking the "charge" state of multiple items, you can store state on a Quest or ReferenceAlias script, and just have the item scripts refer to that script to get the state. For instance, you can store the state on a Quest or ReferenceAlias script. If you want to track multiple of the same type of item but each with their own charge state, you'll probably have to experiment a bit, though.

 

Also, I've only worked with DD and not much with UD - UD might have some additional features or hooks you can use. It's worth asking in their thread or on the DD NG discord.

[scoul73]

On 12/22/2025 at 10:03 AM, Frayed said:

You're not overcomplicating things, unfortunately. I've burned my fingers on similar things when I first started making mods involving DD.

 

I was afraid of that. You would think that items in the player's inventory would be considered more important than the endless junk items in the world for script accessibility. But that is not the choice Bethesda made. Thanks for the confirmation of the bad news, even if I was hoping for the opposite answer. It helps me understand why I see a few mod authors here that refuse to support DD in their own mods.

 

On 12/22/2025 at 10:03 AM, Frayed said:

A word of caution, though: Skyrim is a little bit weird about items when they move between the game world and the player's inventory. Consider for example stacking two items with scripts on them: if you drop or equip one, which one is it? The two script instances may not have the same property values, so you'd have to dig into how the game resolves that, which is a nasty can of worms. I don't actually know the specifics of how the game resolves it.

 

Yeah. This does weird things in the base game too. I did an experiment today with a weapon that counted the number of times it got equipped. I spawned two of them, drew them in various patterns, dropped and picked them up in various patterns. They stopped printing the debug notification counters after I did that a few times. I guess I broke the script entirely? The game somehow tracks separate enchanted weapons with different charge levels, but maybe I could screw that up too by doing the same thing.

 

On 12/22/2025 at 10:03 AM, Frayed said:

f possible, it might be preferable to avoid associating your state with an actual item instance. If you don't care about tracking the "charge" state of multiple items, you can store state on a Quest or ReferenceAlias script, and just have the item scripts refer to that script to get the state.

 

I hear you. If it gets frustrating enough I will change the design to do something simpler like that. Right now I'm still in the mode of wanting to get it working even if I have to jump through some more hoops. My initial experiments with substituting a persistent reference item are promising, but I need to be clever about finding the right hook point. UD likes to spawn and delete items in rapid sequence during the equip sequence, and replacing one of those would not be good. But I think that persistent items, value passing through StorageUtil, and some sort of cleanup timer if the item is lost (so it doesn't bloat the save file) will probably work.

 

On 12/22/2025 at 10:03 AM, Frayed said:

Also, I've only worked with DD and not much with UD - UD might have some additional features or hooks you can use. It's worth asking in their thread or on the DD NG discord.

 

I might do that after some more experiments. I am developing against UD but if I get it working well enough I could publish it as a mod here. So I would rather have it work with base DD too for the non-UD users. So using UD-specific tricks could be counterproductive

[Frayed]

56 minutes ago, scoul73 said:

I was afraid of that. You would think that items in the player's inventory would be considered more important than the endless junk items in the world for script accessibility. But that is not the choice Bethesda made. Thanks for the confirmation of the bad news, even if I was hoping for the opposite answer. It helps me understand why I see a few mod authors here that refuse to support DD in their own mods.

 

I suspect that it may have been an optimization decision. If I were designing an inventory system where items could stack, that implies that they are interchangeable, and then I'd probably not store individual references but just a "type + count". But again that's a wild guess, because I don't know how the game actually handles it.

 

Quote

Right now I'm still in the mode of wanting to get it working even if I have to jump through some more hoops. My initial experiments with substituting a persistent reference item are promising, but I need to be clever about finding the right hook point.

 

Go for it, just trying it anyway is often a good approach. Let us know what you discover, I for one am curious 🙂 Here's some more references for persistence behavior, in case you didn't already find these yourself:

https://ck.uesp.net/wiki/Persistence_(Papyrus)

https://ck.uesp.net/wiki/Persistence_(Creation_Kit)

https://forums.nexusmods.com/topic/3004514-persistence-of-items/

https://github.com/xanderdunn/skaar/wiki/Understanding-Forms%2C-Object-References%2C-Reference-Aliases%2C-and-Persistence