Disallow to Store an object in Workshop mode?

[hereami]

I know, this can be done, but not how... There are keywords for NoRepair, NoScrap, and none for NoStore.

Tried to utilize unused dfob WorkshopItemDeleteOnlyList (whatever that means..., and assuming they can be scraped (deleted) only) - no effect.

Any activated workshop can be Stored inside self - so, being a Workshop doesn't prevent it (that's weird btw, a collapsed universe...).

Destroyed objects can't be stored, but no practical use, they must be intact, not destroyed.

Tried making a Quest object - no effect.

MustPersist kw - no effect.

Persistence ref - no effect.

Scrap-only objects can't be stored, but also they can't be moved - no use.

 

Anybody willing to unveil a huge basic secret? : )

Edited September 5, 2019 by hereami

[SKKmods]

I dont know of an easy keyword, but if you can attach a script and the event OnUnload() triggers on storage then using GetContainer() to test, maybe you can pop the object back out of storage.

 

Saving the original xyz coordinates as actorvalues OnLoad and OnWorkshopItemMoved would probably need to be in the background.

[pra]

UnscrappabbleObject should work. I'm rather certain that it prevents you from storing objects, not just scrapping.

 

Any activated workshop can be Stored inside self - so, being a Workshop doesn't prevent it (that's weird btw, a collapsed universe...).

Now THAT sounds like an actual issue. Did you make a recipe to make the vanilla Workshop workshop-buildable? I see absolutely no reason why this would be a good idea, but several potential problems. Like the one you described.

[hereami]

@SKK50, yes, can be, but it handles the consequences, not the reason. If storing (or even scraping) an obj, it can be Enabled back. Curious, if they also react to OnContainerChanged event.

Weapons work differently and are duplicated, so you can obtain 2+ entities of an exact same item (one enabled and others from workshop container, both retain alias display name) and both+ can be used simultaneously - e.g. you and companion, but if all dropped - only one keeps existing.

For things like power armor, only base object will appear, when enabled (no fusion core, armor).

I don't know, how long the obj does live after such tricks - possibly, it's marked to be deleted still, though Delete() doesn't seem to allow farther Enable to succeed.

That works for spawned (built) things. CK-placed unique refs do not reappear and are lost, but quite interesting here - their anchor (marker? whatever that is) still exists and can be moved or used for MoveTo() destination.

 

@pra, no, it doesn't. Mostly not a problem, if there's a kind of head on shoulders, but always good to have it made properly. Single example i know is on ps4 - Build anywhere - there is no option Store for the root Workhsop object, it can be moved, and Scrap is greyed out (by UnscrappableObject kw perhaps) - so it's completely "safe".

PS. Yes, made a recipe for regular Workshop, it's not a vanilla trouble, if that was meant.

Edited September 5, 2019 by hereami

[hereami]

Got it! Accidentally... CK-placed Ref must have WorkshopItemKeyword LinkedRef (one of my things is workshop, so i linked it to self) and a co recipe with an invalid condition. The recipe can have no Workbench keyword, nor any Category - all empty. Making condition valid allows Storing. For quest spawned things, LinkedRef should be assigned at creation time, i guess.

 

PS. Just for interest, having only Workshop link without any recipe outlines object green, but no operations are possible.

Edited September 8, 2019 by hereami

[VIitS]

Scrap being grayed out is definitely due to the keyword. The game ignores conditions when it comes to scrapping, only caring about them for building, so having the unscrappable keyword is definitely good.