Find who placed lockSolved

We've been having problems with people locking multiple cars and just leaving so players loose out on them unless they break. Is there a way to allow admins to see who placed that lock. I tried using something like prod but cant see the owner as it just shows the car not the lock, prod will show the code though

Yes, the lock should have an owner id on it. I can add a command in an upcoming update that will allow privileged players to view the lock owner.

I am generally more interested in prevention as that will save time for your admins. Do you have any suggestions on ways to reduce this abuse vector in the first place? I know limits have been suggested, but that can create some other problems, so I'm looking for other ideas as well, such as automatically unlocking after a while of not using the vehicle.

Command would help a lot. Not sure honestly. Maybe have it Auto Unlock if it's not in tc range and hasn't been used in the past hour or something?

@RocketMyrr
Are the players forgetting to lock the lock they put on or do they simply not put a lock on ?

@WhiteThunder
We have a similar issue as we are using AutoCodeLock from ChaosCode to auto-lock player's items.
The problem is that AutoCodeLock does not work on locks deployed on subs, cars, horses copters etc., and players forget to lock those things because they are used to the autolocking feature, and when some troll has then put their lock on, it's impossible to figure out who owns what.

My suggestions are these:

  1. Config option to deny players putting a lock on items that are not either their own or OwnerID 0 (helpful for servers using Claim Vehicle Ownership and/or Vehicle Vendor Options).
  2. Set the OwnerID of the entity that gets a lock on it to the player who places the lock if (OwnerID is 0).
  3. A command to check ownerID of a placed lock (or even better if Entity Owner plugin could check the lock only, but that's probably an EntityOwner issue).
  4. Have AutoCodeLock work with Vehicle Deployed Locks (tho again this might be a problem of AutoCodeLock and not Vehicle Deployed Locks) or have an auto-lock function within Vehicle Deployed Locks or maybe support for AutoCodeLock if there's a usable API.
  5. A configurable "decay" timer for the lock when outside TC range so it will simply remove the lock and set OwnerID to 0.
I know this is a lot, but a boy can dream right ;o)
rmXhxvAZXg89izz.png FuelStream

We have a similar issue as we are using AutoCodeLock from ChaosCode to auto-lock player's items.
The problem is that AutoCodeLock does not work on locks deployed on subs, cars, horses copters etc., and players forget to lock those things because they are used to the autolocking feature, and when some troll has then put their lock on, it's impossible to figure out who owns what.

My suggestion is this:

  1. Config option to deny players putting a lock on items that are not either their own or OwnerID 0 (helpful for servers using Claim Vehicle Ownership and/or Vehicle Vendor Options).
  2. Set the OwnerID of the entity that gets a lock on it to the player who places the lock if (OwnerID is 0).
  3. A command to check ownerID of a placed lock (or even better if Entity Owner plugin could check the lock only, but that's probably an EntityOwner issue).
  4. Have AutoCodeLock work with Vehicle Deployed Locks (tho this again might be a problem of AutoCodeLock and not Vehicle Deployed Locks) or have an auto-lock function within Vehicle Deployed Locks or maybe support for AutoCodeLock if there's a usable API.
  1. Vehicle Deployed Locks already has a config option for this: "AllowIfNoOwner": false. However, this is a global setting, so not sure if you're asking for this to be per vehicle type.
  2. Thanks for the suggestion. I will consider adding this, probably with some optional integration with Claim Vehicle Ownership so that plugins monitoring ownership changes can be notified. An alternative would be to improve Claim Vehicle Ownership so that players get a UI button when they mount an unclaimed vehicle, and to implement auto-deploying locks which I mention below, which can auto deploy the lock after claiming the vehicle, which ACL will then auto lock.
  3. I will look into whether patching Entity Owner makes sense for this. If it does not, I will add a command to this plugin.
  4. AutoCodeLock does with work Vehicle Deployed Locks because VDL artficially calls an Oxide hook that ACL listens to. This happens to work, but only if the entity is owned by the player who deployed the lock because ACL is performing that check. This could be addressed in AutoCodeLock, or it could be addressed in Vehicle Deployed Locks by automatically assigning ownership of the vehicle to the player as you described in #2.
    1. I've considered having an auto lock feature in VDL, but for the time being, I would prefer to avoid that complexity (commands, data files, streamer mode, etc.), not to mention the duplication with ACL.
    2. A similar idea on my radar is to auto-deploy locks to vehicles that spawn with the player's owner id, and when vehicles are claimed. This can help with players forgetting. This will not suffer from the ACL compatibility problem because it will only be done for vehicles that the player owns so ACL will always auto lock.
  5. The lock decay sounds reasonable for this plugin, but I'm hesitant to change ownership as that takes away control from other plugins that want to manage ownership. I'll have to think more on this one.
@FuelStream
Our players are just running around locking vehicles on the server on the first day. A lot of them are just doing it to be trolls.

I submitted a patch to Entity Owner that will display the lock owner. The lock owner will show when it's known and different from the entity owner.

I've released v1.5.0 of Vehicle Deployed Locks which adds an optional RequireTCIfNoOwner config option. If you set it to true, players will need to place a TC nearby in order to deploy a lock onto an unowned vehicle. This should be a slight deterrent. As for @FuelStream's comments, I've also improved compatibility with AutoCodeLock, as well as made key locks auto lock.

I've also implemented a beta version of the plugin which has an optional feature to automatically unlock vehicles that have been idle for some time. @RocketMyrr  @FuelStream  please give it a try and provide feedback.

Download: https://raw.githubusercontent.com/WheteThunger/VehicleDeployedLocks/develop/VehicleDeployedLocks.cs
Documentation: https://github.com/WheteThunger/VehicleDeployedLocks/tree/develop

@WhiteThunder

Auto unlock works well from testing so far, although it seems like locks unlock on the CheckIntervalSeconds timer and not IdleSeconds.

No edits to a locked car option is also very useful and work perfectly.
Locks stays locked in TC range which is really nice.
ACL works perfectly now on all vehicles.
Lock placement on Submarineduo.entity is not optimal as the red light is right in your face when sitting in driverseat.
Haven't tested EntityOwner yet as the patch is not published yet.

Really nice update :o)

ONz0U9Z9RVkpDDB.png FuelStream

Auto unlock works well from testing so far, although it seems like locks unlock on the CheckIntervalSeconds timer and not IdleSeconds.

Lock placement on Submarineduo.entity is not optimal as the red light is right in your face when sitting in driverseat.

Whether a vehicle is idle is tracked independently of the plugin. This means if a vehicle was already idle and the plugin is loaded with the update, assuming default settings, the vehicle will unlock in 5 min if it has already been idle for an hour. To ensure it was working during development, I used 5 second checks with 60 seconds idleness.

As for the duo submarine lock position, the rule I follow is that a lock should be usable outside of the vehicle, and from the driver seat. Let me know if you find a better position that meets that criteria.
Locked automatically