Placing a large furnace or refinery means every reload it comes back with its 100 wood, and anything inside of it is lost. Placed chippy machines lose their top scores. Anyway around this? I know a lot of servers that restart daily these days. Can't the items be 'saved' in their place until makill'd, or a profile is switched?

There are multiple ways that I could implement saving. However, it's fairly low priority for me at this time, and saving will need to be implemented for every type of entity, so I'll be relying on feedback from users such as your self to know which entities I should prioritize saving state for. For example, the chippy arcade thing was not on my radar at all.

Merged post

I have implemented a feature for this which you can download and test from the develop branch here:
https://github.com/WheteThunger/MonumentAddons/tree/develop

To use the feature, you will have to add a config option "PersistEntitiesAfterUnload": true. You will not see that option in your config, but adding it will work. After loading the plugin with that config option, the plugin will start tracking all entities that it spawns in the oxide/data/MonumentAddons_State.json file. When unloading the plugin, the entities will remain. When reloading the plugin, it will find existing entities from that state file, and only spawn entities that are missing, despawn entities that should no longer exist, and update/move entities as necessary.

Since this feature uses the vanilla Rust entity saving functionality, I didn't have to code special handling for specific entity types, so basically all entities should work. This should also address the sign file buildup issue you reported, though I plan to address that separately for "PersistEntitiesAfterUnload": false.

This is awesome, I can see the change right away. I wont know about the sings for sure until a few days(restart), but it seems like it would be fixed just how things dont disapear and respawn. thanks alot WhiteThunder!

Merged post

The db does still keep growing at restarts/reloads. I also noticed when you makill a sign that image is left behind in the db. I tried manually removing the sign from the profile.json and doing a normal ent kill but this did not help. Another problem I noticed is if you don't even use signartist, and paint signs by hand those do not persist even after a plugin reload, however that image is left behind in the db too.

I was working on the sign file issue on the weekend. I learned that ent killing or makilling a sign will leak the image. Only destroying the sign via stability or via damage will clean up the image. I made a change on that branch which should fix the issue for the expected ways (not for direct ent kill), but not sure if I pushed it yet. You can check the recent commits.

Manual sign painting is not intended to persist across reloads, but you are right that those will leak as well.

I do not expect leakage across reloads/restarts with the config option you enabled, so I will have to reproduce that case first.

As for testing this issue, I noticed that I had to stop the sever for the SQLite file to be updated to reflect the images. Do you know of a more expedient way I can test?

WhiteThunder

 Do you know of a more expedient way I can test?

No this is why I really only trust when a full restart has happened.. I notice -wal files lately, these two files togeather seem nessary to look at an accurate db

maxWalker

I see what your saying, the game locks the db - copy the db somewhere else and access that. Trying the latest dev version 2f5584c I noticed makill does not get rid of the entity until you reload the plugin. Specifically I tried the large and small box, barbeque, and a snowman.

WhiteThunder

I found that copying it didn't show the latest additional unless the server was off.

Correction: I found that copying both the db and db-wal files, then opening the db file, was showing the latest data, without requiring a restart.