How to use Text Replacement in Terminals to display a Global Variable?

[SKKmods]

Its because the base game PipBoy has no persistent ObjectReference whilst in inventory/worn so no "Self" context to pass.

 

Using the new(ish) cc_ap_Pipboy_Texture OMOD attach slot it can become persistent, but not enough people have that crap to be a dependable platform solution.

[PJMail]

Really? Just giving the Pipboy an attach slot fixes the issue! How non-intuitive...

 

Back a step - so does that mean you can't drop the pipboy/move it to another container?

I know inventory items have no objectreference, but I have used a temporary dropitem to 'instantiate' an item so I can get it's attributes and details on it's omods.

 

Or are you saying that items with omods secretly have an objectreference when in inventory because they can't just be treated as their base form anymore.

That actually explains why when I drop items some are base and some have an object reference...

[steve40]

You can drop/move the pip-boy.

 

Both inventory and worn items can have an ObjectReference if they are persistent. Many (most?) items are not, and are stored/worn as their base object.

 

From the CK wiki for OnItemRemoved and OnItemUnequipped:

 

"akItemReference: The specific reference removed from the container, if any. Will be None if a non-persistant object is removed."

 

"akReference: The reference the actor just unequipped, if the reference is persistent. Otherwise, None."

[SKKmods]

The issue is that non unique/persistent objects do not have unique/persistent references in player or any container inventory so it is not possible to get a discrete ObjectReference for them.

Workaround 1 Use a quest to generate the item and fillthe RefAlias with an ObjectRefernce, BUT, the RefAlias will be cleared once the item is added to a container.

Workaround 2 Attach the FeaturedItem keyword to the base form before the item is created/spawns which seems to make some items (MISC, BOOKS) unique and persist an ObjectReference in inventory. But it pops the featured item flash every time it is accessed.

Workaround 3 If the item has OMOD attach point (weapons, armor) attach an invisible/ghost OMOD to make them unique.

A base form can be DropObject() from inventory to get an ObjectReference, but unless it has a unique/persistent marker that ObjectReference disappears as soon as it is put in a container/inventory/equipped.

[PJMail]

Ok, a variant of what I thought... To summarize you both

 

- persistent items have persistent object references.

- unique or 'featured' items are considered persistent.

- an item with a mod attached is considered unique

- an items' object reference is not accessible when in a container (even if persistent)

- non-persistent items Dropped from a container aquire a temporary object reference

 

I will add one more - in my PA mod I sort through the players inventory of Fusion cores to find the one with least 'health' (%used) by transferring between containers and catching the onitemremoved events. Unused fusion cores come through with a 'None' object reference (just a base fromid), whereas partly used ones have an object reference (and thus I can use GetItemHealthPercent()).

 

So, I will add that - items with actor values are also considered 'unique'.

[SKKmods]

> an items' object reference is not accessible when in a container (even if persistent)

That is incorrect depending on your taxonomy, so to fully qualify:

The ObjectReference of a persistent but non uniquely attributed item is not accessible in inventory. This can be tested by PlaceAtMe abForcePersist = True an item with no unique attributes, AddItem to inventory then RemoveItem akItemToRemove = TheObjectReference will fail.

A uniquely attributed (attached OMOD or specific keywords) object will be naturally persistent so RemoveItem akItemToRemove = TheObjectReference will work. Due to its "uniqueness" as an object which causes inventory persistence.

I would infer (not know) that world persistence and inventory persistence both mean that an object's assigned ObjectReference does not change, but they have different causal conditions. Persistent in the world != Persistent in inventory.

[PJMail]

I had forgotten that additem, removeitem, and getitemcount can take an objectreference so I stand corrected.

Silly of me as I use this fact all the time in my scripts...