Arelith

I am proposing that a PGCC Server-only command be provided so that players can save and store character builds and concepts on the server vault longer than the automatic (2 week) period before their character is deleted if they have not been recently active by the player logging in to refresh the acvitiy token).

Due to a previous update on the PGCC to prevent constant memory leakage and crashing, a solution was provided which resulted in a bi-weekly automatic server vault deletion of characters on player accounts that had not recently been active after a period of 2 weeks. This solution has greatly improved PGCC stability as the server vault is no longer being filled up with level 1 characters, or half unfinished characters which bloated the vault. However, as a result, concept builders and theorycrafters like me, who exist primarily on the PGCC plane, have had to safeguard their fully equipped, and perfected builds from becoming inactive to ensure they are not flagged for deletion in the automatic cleanup. This is a tedious task to maintain , and at times, results in a cherished concept fading to the wind.

As I proposed, a server command (-save_favorite) to flag a character as "remain active" or "favourited" should be added to the PGCC, and would allow players to maintain some record of their builds and concepts for finalised or particularily worthy candidates. I know that this may eventually lead to a storage probelm that could lead to server instability at some point. So, perhaps a fair duration for extended storage before deletion would be a compromise (3-6, 6-12 months), with that duration refreshing when the character is automatically flagged as "active" as normal after the player has logged in on it, within the "favourted" duration.

I made this just to help visualize this, no idea if its helpful or accurate:
https://chatgpt.com/share/e80b84c9-d8a8 ... c13ffae563

As the person who implemented this, I'll leave my two cents for what it is worth. The team can make an overall decision.

The implementation was to control account sizing and space issues on the PGCC server. Players make and test characters and they were allowed to sit and build to large sizes. I think some people had upwards of 500+ characters on the PGCC. So, the implementation was to control the size by an automated cleanup where you delete characters inactive for 14 days. If a person wanted to retain the character, they only needed to login for 2 seconds in the two week period. This was not done through in-game coding, but shell scripts and a CRON schedule outside of the game.

Your proposal could work but it just leads to the same issue that encountered before, people will just favorite their characters and build them up and not address necessary clean up.

You could do it two ways:

• Script of -save_fav could be implemented which adds a particular suffix to the end of the .bic file and then can update the cleanup shell script to remove characters that do not meet that masking.

• Leave it as is, and players who love their characters take the time to login once in two weeks to maintain them.

My input:

Leave it as is and do nothing further. The test server is for testing - it should be the least managed, least code driven server of all. It is not the intention for the server to maintain test characters, but to clean them up. If players want to ensure they last, the effort of logging in once per two weeks is there. Otherwise, it can be rebuilt - usually characters are just excel documents that can be recreated at any point.

Agreed with Malkalz, It should be handsoff where possible and providing a tool to allow a clogging of the system or a new db requirement purely to track an allowable amount of favourites is unnecessary overhead.

As one of the server maintainers I will have to say that we will be leaving it as is, as MalKalz said. Unfortunately allowing this would simply lead to the same issue in the long term and the PGCC is primarily intended for testing character concepts, not for making an archive of concepts in perpetuity.

I realize this would be a nice to have but it is just something that would introduce other issues in the long term.