How to detect an object is 'locked away'?

[PJMail]

Basically I want to stop people using a feature to 'steal' objects locked away.

Does anyone have a tricky idea on how to tell a particular object is in a locked room/or hasn't been moved?

 

It would be enough to know it is still in it's original "Editor" location, but the only idea I have so far is

- get object's x,y,z location

- call object.MovetoMyEditorLocation()

- get new x,y,z location

- if original and new location are the same - assume it hasn't been moved (still locked away so can't be taken)

otherwise allow it to be taken.

 

Using something like "player.PathToReference(object)" - to see if it is accessable - would cause the player to move...

 

Any thoughts? The objects I am trying to protect from script based stealing are Power Armor frames locked away.

[LarannKiar]

Does anyone have a tricky idea on how to tell a particular object is in a locked room/or hasn't been moved?

 

For objects in a locked room, you can scan through the area for object references whose GetParentCell() (or the objects themselves) are owned by an actor or faction, then 1) either store their IsActivationBlocked() status and call BlockActivation(True, abHideActivationText = True) to make them unable to be stolen or 2) add a conditionalized "Activate perk" to the player that supposedly hijacks the default activate button "Steal" and shows a message like "This object can't be stolen." instead.

[PJMail]

The problem is the item is actually owned by the player (because it is not stealing if you get through the lock) - it is just inaccessable behind a lock.

Not in a container or a different interior Cell, but a normal door to an area in the same Worldspace cell.

 

I am talking in this case about Power Armor in those locked cages, but there are lots of these sort of things.

Bethesda has the same problem evidenced by the 'trick' people use to get the Cryolator from it's locked display (using Dogmeat).

 

Unfortunately there is no 'isInaccessable()" call, and "GetLockLevel" only applies to the door/container - not the objects it protects.

[hereami]

Curious task, but why needs be done at runtime and what is "script based stealing"? I'd suggest that best protection could only be done in editor and for selection of most important things, like said caged Frames, though still nothing may prevent a user from opening mod file in editor, unless that's on BethNet for consoles only.

[PJMail]

My mod has a "Store Power Armor" feature. If you use that while standing next to PA in a locked cage it will "Store" it for you (right out of that cage)!

Unintended 'cheat' I am trying to work around.

[hereami]

Funny. I don't know currently how can be done for any random item in a random locked unowned area, but said Power armor encounters probably have standard cage and door IDs? Then might check for door presence nearby and see if that's locked. Possibly, testing if PA is inside a cage. Unlikely there can be more than one door in close proximity and possibly it's not even necessary to test exact ID, so may be any Door. If there's a standard LinkedRef between PA and cage/door, then task would be easier and most reliable, but it's doubtful.

 

Or maybe could reduce allowed distance for "Store" to very minimal, since that's not wanted to be an explicit cheat. Or make it require direct Player contact.

 

ps. Haha, wait.. If player is already standing inside a locked cage, then probably will have everything he wants no matter what. Looks like a very redundant measure to learn if some piece was taken out of locked area earlier.

Edited March 21, 2023 by hereami

[NeinGaming]

Maybe I'm missing something, but my first thought is: The first time a player enters a PA, attach a keyword you made for that purpose to it. Then make the store feature only work with PA that have that keyword.

[hereami]

Makes sense. Though script would be idling 99,9% of time, keyword as well. Possibly, could make it actually Owned by Player instead, wouldn't clutter objects with keywords at least.

[PJMail]

I don't want a solution that requires a new game (i.e. requires PA to be tagged when you aquire it) or other 'unrelated to my mod' game additions.

 

My original idea is still the best then? (if it hasn't moved from it's original game specified starting location then it isn't yours to take).

 

If all PA you aquired was tagged as 'owned by player' then that would be perfect - but unfortunately the game doesn't seem to work that way by default.

 

Oh well... Thanks for thinking about this.

[NeinGaming]

Makes sense. Though script would be idling 99,9% of time, keyword as well. Possibly, could make it actually Owned by Player instead, wouldn't clutter objects with keywords at least.

What do you mean with "idling"? Of course keywords do nothing and nothing cares about keywords it doesn't check for, that's the point.

 

Setting "owned by player on" would mean a PA would become "legit" via the mod, right? So you might say it'd be cluttering that flag by overloading it with unrelated functionality.

 

I don't want a solution that requires a new game (i.e. requires PA to be tagged when you aquire it) or other 'unrelated to my mod' game additions.

It would just require the player to enter each power armour "normally" once per game. Which also handles anything original editor location stuff potentially not handling, as well as still allowing player to use glitches to get some power armours if they want to. It's just the best proof there is that the player can access PA normally - to access it normally.

 

No idea what you mean with "unrelated additions", because only your mod would even know that keyword exists. Instead of using something that is already in the game and but has a different meaning.

 

Last thing to consider is, every time that store function would be used, the original and stored locations would have to be compared, so that's storing two numbers for each PA somewhere, versus one keyword to set when the player enters PA (no need to care if it's already set, either).

Edited March 23, 2023 by NeinGaming