Wipe all TotalFreedomMod player data when moving from 2021.06 to 2021.09

↩  videogamesm12 well i mean, why are we trying to add it into tfm at all, just make 1 script which runs through the database and updates it and then bam, done. after that it would just need to be put on the server and then everything should work, theres litterly 0 reason for it to be incorperated into TFM

↩  videogamesm12 regardless, it could get the job 99% done and the people with edge cases can have their data restored instead of every single person

Object for now. I don't understand the reasoning behind "There are some cases where it doesn't work, so let's also throw out the data for all cases where it does work".

↩  videogamesm12 o well this is not so bad, I vouch.

Vouch.

Also I really feel like the value of coins is so low when you have like 20k.. maybe we should create an exchange system of like 1 old coin = 0.2 new coins (meaning 20k would be 4,000 new coins) and increasing prices of items.. that’s a whole other thread though

So the main issue is how to handle inconsistencies during the conversion / addition of online UUIDs in cases like cached names not matching a valid online account? (Ignoring the case where another account has taken the same name as the current system can't detect that as well)

I see plugins like PlotSquared have a built-in converter that switches between offline and online UUIDs, can we take inspiration from it?

The right time to do this was when switching to online mode, who thought it was a good idea to never store UUIDs in the first place.

I will say that if Steven decides to approve this suggestion, my only stipulation (Beyond my views already expressed on this in dev channels that we shouldn't even need to do this and that this is reasonably important) is that the data is archived for future access, which shouldn't be an issue but is the only real requirement I have if the decision is to purge the data from the server and re-set from clean go.

What I know is that, when a player joins, Paper gets the UUID from bungee-02, as one can see in server logs.
I haven't studied how TFM manages player data yet so I hope I get this right, anyway if a method like OfflinePlayer.getUuid() returns the already cached UUID without querying Mojang API (as this is bungee's job), or generating a random one, things could go this way:

1. Player joins
2. TFM looks for a matching UUID in its data
3. If it's not found, it falls back to the previous system and adds the UUID after successful verification (if triggered).

videogamesm12  Paldiu Could you confirm if this is even still relevant? Given the changes to how we tackled 1.17 and the current dev plans.

↩  videogamesm12 I mean i think its guaranteed SOMETHING goes wrong so object

↩ @'Ryan' so, here's the thing. With the conversion to uuids from ip addresses, we would need to add a uuid value and remove the ip value. This consequentially would result in the files needing to be regenerated, causing all stored data to be erased. There could be a potential workaround by making a copy of the old file within tfms internal memory and copying over its contents into a new file with the uuid field included, but this would result in a floating value for the ip which may or may not be an issue.

↩  videogamesm12 "this would result in a floating ip value"

It's not ever used so why would we keep it?

this is pretty much how we're going to have to do it now unless we manage to fast track everything and get it done before the 13th

I still support the idea of building a new db to preserve as much data about active members as possible and to let go of the remaining orphaned records after that.

We have a test machine available to do this without affecting the freedom server.