-
-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update how /is purge works to be team based. #2359
Comments
@spookymgmt This is done. Please have a check and confirm it works how you expect. |
Putting it live now, don't really have a great way to test it I don't think, but maybe I can setup a test server this Monday and see. Thank you. |
Entire server freezes then crashes when purging on this version. Additionally, I typed /isa purge 40, and it's saying it's going to purge islands with a team member that was online just a day ago. It should be, the entire team must be offline for the given days, to purge.
|
That is odd. Some comments/questions and a request for files:
Thanks! |
Hey so yeah server time is correct. The lag issue happens with the team version of purge, and the original version of purging, but it's just not as bad. The freeze happens the second you run the command, not when confirming it. Server version is on 1.20.1. I'll send over a zip of all my files, gonna take a bit to transfer and zip them up though, ill send them over on discord? If dms are off ill figure a way out to just send them here as a google drive link or something. Thank you |
Okay. You can also email the link to tastybento @ bentobox . world |
I've went ahead and sent that over now, thanks |
The email forwarding doesn't seem to be working so please send to tastybento 2 @ gmail . com |
I got it. I made some changes that I think should work, but I’d like you to test - run the |
[05:48:44 INFO]: AlsoLunar issued server command: /isa purge 40 10098 islands to check, and 10097 of them are purgable now |
That appears to be the correct assessment because out of all the islands in the database, none of them have an owner in the usercache.json file, so it appears that none of the users have ever logged into that server. Is the usercache the correct file for that server? I ran a check and not a single UUID in the Island's database folder matches any in the server's usercache.json file, so as a result, the owner of every single appears to have never logged into the server, and therefore every island is over that timelimit and purgeable. I don't know how this happened. Any ideas? It's as if the database is not from the server that the usercache.json file applies to. |
Mmm, I think something is wrong then, when I open up the usercache.json in a file editor, and then /seen any name inside of this file, they've all been online in the last 50 days. |
Thanks, that helps. Yes, I see that. |
If I run:
then I get this in console:
even though I have that usercache.json file in the server folder and it's a totally fresh server. It looks like the I also verified that the date is correct shown for a player that logged in to the server that I'm running, and also, if that file is transferted to another server, my player also appears to have never logged in. So, the upshot of this is that the purge command should in theory correctly identify the actual number of islands to purge if you run it on the production server, but it won't if all you did was copy the files from the production server to a local server. There must be a hidden file somewhere with the info in it, but I need to hit the sack, so I'll look at this later. |
Appreciate it a bunch, and this is a prod server, but I may have copied an old usercache file from a different gamemode of mine? Hmm, would I possibly be able to just delete it so it's fresh? I don't know, thanks for the help though |
I don't understand why it is doing what it is doing right now, but I'm tired. I think that I may have to start storing the last login time in my own database instead of relying on the server cache. That way I can tell for sure. That won't help with your current situation immediately. |
Tasty... just curiosity... |
@BONNe Yeah, thanks. The thing is though that the calculations are done on Unix timestamps, which are just longs. This part of the code hasn't changed since forever. I'm open to suggestions though. |
How we lookin boss |
I checked on the Paper Discord and the last played time for players comes from the player dat file, or it uses the file mtime. So, if those files don't exist on the server, e.g., in the folder So, you could... wait 30 or 40 days and let players log in and build those files up again. Then any that haven't logged in within 40 days will be purged. |
Would it be a better solution to build your own system for tracking last login dates, in the bento database? This would remove any margin for error? Because currently this isn't a test server nor did I delete any files. So I'm unsure why it's not having the correct data. |
No, that version is 2.3.0 so it's probably a smaller amount because it is ignoring team islands. I saw your previous message about storing the last login time of a user in our own database and we could although it duplicates the Bukkit API for last login. I could. It'd be interesting to see what date you have for your players in |
I have this player data file from /world/playerdata, but I'm not noticing any last login date in the file. https://cdn.discordapp.com/attachments/1247546496040177717/1249515838201921616/8535aad2-8ead-4834-afea-0902457db4f3.dat?ex=666795ce&is=6666444e&hm=153535393349b6dd783c4511ac970b2ef8f1570c968ed0b15cf9aa0c57b5a37e& File download, not positive if it works or not. |
Ohhhhh yeah is that usable? Can we switch it to use that instead? I don't see how that could fail. It looks correct from what I can see |
That is what Bukkit is using. But if that folder was deleted, or moved, or the default world was changed so a new folder was used, then when the query on the UUID is made, the date given is 0. This makes the player appear to have never logged in, or to have logged in back in the 70's. This is why all your users appeared to be valid for purging. However, as players login from now on, that folder will be rebuilt and after 40 days or so, you will have an accurate list of all the players who are recent and all the ones who are not (they will still be unlisted in the folder). So at that point, the purging will be accurate. Does that make sense? |
Oooh and thats what the current team purge jar is using? |
Yes. |
Ah okay, so I'll put the jar back on, test out the purge again, and see if it's better? As that default main world folder hasn't been touched at all since launching the server last month. |
Yes, you can try it. Can you also look at that folder and see how many files are in there and what sort of dates they have? It should have all the players in there who have logged in over the last few weeks at least. |
Around 45 thousand files and yeah the dates seem correct. |
Good. Let's see what the purge says with the latest BentoBox. 🤞 |
Is your feature request related to a problem?
The /is purge command in redundant when using it in a multiplayer experience.
Currently, the command is ran on every server reboot, but according to support in the discord, it completely skips any islands that are part of a team.
How does that help me?
Describe the solution you'd like.
I think this feature should be changed, so that it works like this:
When /is purge 10 is ran for example, it will check every island on the server, and in order for an island to be purged, the following requirement must be met.
This would make for a very good purge system, compared to what we have now.
That way, it's not skipping islands with a team, and, if it was still only owner based, what if owner invites friend, owner quits playing server, but friend keeps playing. You do not want to purge the island on him. So it just makes the most sense to do a check, and see if EVERY SINGLE team member has been offline for the purge arg time.
Describe alternatives you've considered.
Asked in discord.
Agreements
Other
$20 bounty
The text was updated successfully, but these errors were encountered: