One of the biggest challenges facing Frostfall is persistently tracking certain values for n number of items across many different manifestations of that item.

Example: Tents that the player can set up have durability. For instance, the Small Hide Tent can be set up and torn down 10 times. The way I currently implement this is with 10 different Misc Items (for carrying them in the inventory) and 10 different Activators when "rolled up" (before they are set up), and 10 more Activators (for their in-world display once set up). This lets me associate the item directly to its durability level. So to support one type of tent with a durability of 10, I need 30 in-game objects and a lot of scripting glue to tie it all together. If I decide to create tents with even higher durability, this is going to get very unwieldy very fast.

I was wondering if anyone had come up with more inventive or better methods of tracking arbitrary data about an undefined number of items, and linking data directly back to a particular item? Scripts tied to the items themselves has always been a complete bust since the second it goes from the world into the player's inventory or vice versa, you lose your object reference ID 9 times out of 10.

Another example are Woodcutter's Axes, which in Frostfall also now have durability. I've had to create numerous duplicates of this axes as well and swap them out at particular times when the durability rating increases or decreases.

Appreciate any feedback, insight, or just general commiserating.

What about storing an array in a remote "master" script and having each individual object store an index value that could then be used to retrieve a value from the array? If you need to store more than 128 values, then just couple multiple arrays together in a pseudo-property:

ScriptName Test extends QuestInt[] Array1Int[] Array2Event OnInit()	Array1 = new Int[128]	Array2 = new Int[128]EndEventInt Function GetValue(Int aiIndex)	Int iArrayNum = aiIndex / 128	aiIndex = aiIndex % 128	If (iArrayNum == 0)		Return Array1[aiIndex]	ElseIf (iArrayNum == 1)		Return Array2[aiIndex]	Else		Return 0	EndIfEndFunctionFunction SetValue(Int aiIndex, Int aiValue)	Int iArrayNum = aiIndex / 128	aiIndex = aiIndex % 128	If (iArrayNum == 0)		Array1[aiIndex] = aiValue	ElseIf (iArrayNum == 1)		Array2[aiIndex] = aiValue	EndIfEndFunction

Cipscis

I am not sure if I understand exactly what the problem is, but is it that you can't store information on an object's instance itself, because there are no properties for you to store it in? I.e. if you want 5 weapons to have independant durability, you need to store the data for each one in some external place?

If so, I understand this problem, and I just thought of a solution that sounds silly but might actually work.

Is all of the swapping because you want to be able to display the item health/uses left on individual items?

And so I suppose an issue is that players can have more than one of these items...?

Very good code, but I'm still not sure of how to overcome the problem of differentiating between, say, Tent A, B, and C, and associating Data C with Tent C. There is currently nothing about Tent C that tells me what array index it belongs to. ObjectReference ID is the first obvious choice, but this can easily change / get lost between picking up and putting down the item, and many items in a player's inventory have no ObjectRef ID at all.


That is exactly the problem. Currently the "data" is being stored on the item itself, by virtue of it being a unique item. i.e. Axe_Durability01, Axe_Durability02, Axe_Durability03, etc.


Sorta. Different items does allow me to give them different names, but it wouldn't kill me to not have this ability. On the second comment: Yes, they can craft and possess n number of tents, woodcutter's axes, and so on. I can't control how many of these they have.

Yeah, that occurred to me as well soon after I made that post. It seems the index stored in the object's script might be just as inaccessible as the data that you'd tried to stored directly on the object in that you can't get a handle on it because of that problem with inventory items. Presumably, if that problem can be solved, then that'd negate any need for the whole array business.

If I remember correctly, creating ObjectReferences as inventory objects (e.g. via http://www.creationkit.com/AddItem_-_Actor will cause issues with them not having proper referenceIDs, whereas creating them as references (e.g. via http://www.creationkit.com/PlaceAtMe_-_ObjectReference) then adding them to an inventory will, or at least can, create them "correctly".

Perhaps what you need to do is make use of both PlaceAtMe and http://www.creationkit.com/Activate_-_ObjectReference (to add the item to the player's inventory when activated) instead of AddItem when creating objects. I don't know if it's a requirement for them to be http://www.creationkit.com/Persistence_(Papyrus), but if they do then that should be simple enough to force by storing "Self" in a variable on that object's script.

Cipscis

You could fill an alias with the item or use a persistent reference of it and it will retain its FormID. ghostblade, for instance, is persistent, so it'll remain [REFR:00094A2C] throughout the game even when added/removed from your inventory.

You can add a persistent REFR to the player's inventory with

PlayerREF.AddItem(PersistentREF)

...or...

PersistentREF.Activate(PlayerREF)

If it's a ReferenceAlias

PlayerREF.AddItem(AliasName.GetReference())

...or...

AliasName.GetReference().Activate(PlayerREF)

You should be able to manage with a single tent of each type, incrementing an iUses var or something similar.

Thanks Cipscis, Justin. I'll run some tests based on this information.

I do this for my fetch quests. My scripts could easily be expanded to use a system you're after. Just a simple case of adding more functions to do different things.

You're welcome to have a nosey. I use a player alias to track the OnItemAdded/Removed, and to AddInventoryFilter. Then a script attached to the quest with all my functions. Instead of tracking the global as an item count, you could use it for your goal.

The alias idea I think is really promising, assuming it works. It wouldn't cost me much of anything to add, say, 20 aliases to a quest to track tents (it's possible but 99.9% unlikely anyone would ever want to possess that many tents of the same type). After that it's a simple matter of tying an alias to an array value. The only thing I would lose is the ability to display the durability rating of the item on the name of the item itself. If I can do this some other acceptable way (such as displaying a notification displaying the durability when the item is used) then I will have a go at it.