EntityOwner

I'm not sure if I agree. Database overhead is comparable to filesystem overhead. Considering most of the relevant data is stored in-memory anyway, I think SQL queries would not have a significant effect and might even reduce performance. Not to mention that it is preferable to have to data stored in an intermediate format like JSON for easy integration with other systems and plugins.

Introducing SQLite would require significant code modifications. Considering how few lines of code the DataFileSystem approach requires(with the EntityProfile as a JSON contract and serialization), how big this mod already is, and that I'm not aware of any modelling layer in Oxide for handling potentially complex SQL relationships, I think I'll stick with this method until the SQL stuff is as seemless as the DataFileSystem approach.

 

My only thought was if there was a lot of I/O with the files. I'm not really familiar with your plugin. The sub-directory feature is available though in the latest releases though.

 

The majority of the IO happens at server start when the (active) profiles are loaded into memory. The active player list can be expired (however online players are automatically reloaded). There is the potential that a lot of IO could occur if a large structure (built by many people) is prodded soon after ownership is manually expired (with /expireowners or owners.expire). There is no automatic expiration of players to an inactive state and therefore ownership profiles exist solely in memory 99% of the time.

On a side note, it is intended that admins run /wipeowners or "owners.wipe" from console after a wipe. If ownership is not wiped right after a map wipe, ownership files for previous players will become EXCESSIVELY LARGE and potentially bog down performance on high population servers.
[DOUBLEPOST=1440030551][/DOUBLEPOST]Let me also say that the SQLite approach would remove the need for the expiration feature of this mod, however - like I said I think the technical debt here is manageable until the Oxide SQLite component is more mature.

Thanks a ton for adding that stuff to the DataFileSystem.

 

I'll look into that again later tonight.

 

Calytic updated EntityOwner with a new update entry:

0.3.1

 

The player who originally places any block entity will always be the owner. If you prod a ladder that doesn't mean that the player who built the ladder now owns the wall behind it. The structure before is still owned by the previous owner. Changing ownership of deployables depending on where they are deployed is outside the scope of this mod, however it would be possible without much difficulty for another mod author to write that using the EntityOwner API.

Currently mass prod (/prod2) and /own work in exactly the same way. Both commands will include any entities or building blocks within 3 tiles (12 feet) of any other entity or building block (in your query). I will add an option to both of these commands to use another distance other than 3.

 

Hmm, that shouldnt be happening repeatedly for an individual but on a per-profile basis. I'll look into it later tonight

 

This message occurs when there is an error loading an OwnerProfile and as such represents a critical failure of EntityOwner to properly save the OwnerProfile. Because it appears to be occuring every time LoadProfile is called, this means that an entity profile is corrupted and can no longer be loaded. The log message is there to indicate as such and I will have to fix the underlying issue.

Is this occurring for a single player or all players? If it is one individual, or maybe even a few, I recommend deleting their OwnerProfile under the data directory (usually "entityowner_STEAMID.json")

 

Calytic updated EntityOwner with a new update entry:

0.3.2

 

Well, no. Follow the steps below to ensure its not saving properly.

1. Console: server.save
2. In-game: place an entity, like a foundation
3. Console: server.save

After doing that, you should see the following message in your console:

Code:

EntityOwner: Saved 1 profiles

Please do that and confirm whether or not you see that message.

Also please confirm your Oxide is updated to the most recent version.. Oxide recently had a problem with the OnItemDeployed hook that might prevent deployed items from being saved.