Replacing player names in variables with player UUIDs.

[sovdeeth]

What is happening?

We're making {var::%player%} use UUIDs by default instead of player names.

By default, when you write {var::%player%} in Skript, it evaluates the player as their username: {var::Sahvde}, for example. However, if the player changes their name, this can cause issues with your variable storage as the player is no longer linked to their old name.

on join:
    if {var::%player%} is not set:
        send "Hi, %player%!"
    set {var::%player%} to true

# When I first join with the name "Sahvde", {var::Sahvde} is set.
# Then, I no longer see the message after my first join.
# If I then change my name to "Sovde", the next time I join, 
# {var::Sovde} isn't set, so I see the "Hi, Sovde" message a second time.

To avoid this, players in variable names will soon be defaulting to UUIDs, which cannot be changed by the user. This makes your data much safer and much less likely to have data loss for players. Skript has had this option in the config for a while now:

Over the coming months, please make an effort to migrate your player variables to use UUIDs, either by enabling this config option or specifically using player's uuid. If you have a situation that requires the player's name, you should specifically use player's name.

As the image states, please be aware that this upcoming change will not change your previous variables. If you have data stored under player names, you will have to either migrate all your data over to uuid-based variables, or use player's name in your variables.

How do I prepare for the changes?

We recommend switching all player-related variables to use UUIDs. The easiest way to do this is switch your config option use player UUIDs in variable names to true. You can find this on line 91 or so of your config.sk file. This means you don't have to make any changes to your actual code, Skript handles the switch to UUIDs for you.

However, this does not fix any existing variables that use player's names. You will have to manually migrate that information over to lists that use the player's UUID. Below is a command that you can use to migrate list variables over, or use as an example if you have more complex variables you want to migrate.

⚠️ Before you attempt any migration, please ensure you have a recent backup of your variables.csv file. ⚠️
Stop your server, make a copy of your variables.csv file in a safe location, and then continue.

Here's a script that you can use to migrate variables. If you have a variable list named {var::*} that you use with {var::%player%}, you can run /migrate-variable var to automatically migrate that list over.

command /migrate-variable <var:text>:
    trigger:
        send "Migrating variable {%{_var}%::*} to UUID indices..."
        loop {%{_var}%::*}:
            set {_player} to loop-index parsed as offline player
            {_player} is set
            set {_temp::%{_player}'s uuid%} to loop-value
            delete {%{_var}%::%loop-index%}
            send "  %loop-index% -> %{_player}'s uuid%"
        loop {_temp::*}:
            set {%{_var}%::%loop-index%} to loop-value
        send "Migrated variable {%{_var}%::*} to UUID indices."

When will this change be happening?

We will not be making this change until 2.9 at the soonest. This gives you 6 months to prepare, which you should use wisely.
Following the change to use UUIDs by default, we will still respect it if you have use player UUIDs in variable names set to false. This means that you won't be forced to the new usage unless you regenerate your config file. Any new config file will use UUIDs by default.

If you have further questions or concerns, please ask them in the comments below.

[rudde0]

This should be optional.

[EquipableMC]

That is understandable, I just wanted to bring databases into discussion because sometimes people just go straight into a database (example, mongodb) to find information about a player. Thats why :)

[ByteAfterlife]

I think that it should be changeable by the player. I don't think its alright for some servers that don't like it, but seriously, I have to now waste 2 hours of my time adding "'s name" to each variable then half of it gives me an error, yeah no thanks. I think you should have an option instead of use player's uuids, "use player names in variable names." Thats my perspective. I don't mean to be negative, just sharing opinions.

[EquipableMC]

You realize it's just changing for variables right? Anything outside variables will just return the player's name. It's literally just setting a config option to true

[NotSoDelayed]

It is still change-able, but for first time users (or simply deleting config.sk) will no longer reveal this option in the config, see #6270 (comment)

[bluelhf]

You should instead waste your time migrating to UUIDs — that's the point of the change

[TheLimeGlass]

I want to add that the node currently exists, so this is only going to affect users that are regenerating the config.sk. Which is mostly new users. Existing users that don't regenerate their config.sk will continue to have this node as false.

[sovdeeth]

Good point, thank you Lime. I'll add this to the main article.

[NewNiklas]

I already use %player's uuid% in my variables. This should also work after the change right?

[Pikachu920]

I already use %player's uuid% in my variables. This should also work after the change right?

correct, if you're already using player's uuid you are good to go

[WarnDa]

Some plugins doesn't support UUID instead of user name, so make it optional or add a "%player_name% would be cool yes !

[Pikachu920]

you can already do player's name

[Fusezion]

Alright since I've seen a post like this now

I'm gonna make a little bit clear as I also was confused on what this config setting actually did despite how clear the wording is.

1. player toString is not being changed to their uuid it'll still show in everyday syntax as their username
   

2. player toVariableString more so known as a variable index is the only thing being changed. i.e {blah::%player%} is now {blah::%uuid of player%}
   usage of blah_ is to prevent only 2 variables being set
   

For those who already use uuid of player, there's no difference for you. your code will run the exact same without any data loss.
Those who haven't listened to feedback from SkUnity help channels telling you to use uuid of player this will affect you. since in previous releases your variables would look like {t::Fusezion} rather than {t::d3581c05-b26d-495a-96aa-10c920916f57}

I am all for this change even if I personally never used this setting. As any code I write I do uuid of player so I can easily put it across servers.

I've seen mentions of issues where player's had 2 different uuids when using proxies and such, I've had this issue in the past and last I remember it's related to forwarding not being properly set up I suggest reading over this https://docs.papermc.io/velocity/player-information-forwarding if using velocity, for those who use Waterfall or Bungee ask in their related support channels.

I hope this can clear up some misconceptions on this, as the change is important for those who need it. There's just about zero reason not to already be using UUIDs. Especially in a large scale of things.

[KxmischerLasse]

will anything be changed in e.g. %arg-1%?

[Fusezion]

this response here will show the changes in effect #6270 (comment)
nothing is happening to everyday <player> and <offlineplayer> arguments

[sovdeeth]

to summarize

command /test <player>:
    trigger:
         send "%arg-1%" to player # No change here
         set {var::%arg-1%} to "Test" # change here, in the variable name, which will now use uuid by default.

[mr-scoobis]

Why not set the default config to true? I FREQUENTLY use %player% as variable indexes, using the uuid in most cases is 100% overkill. Now sure, I could change it to %player's name%, but that's impractical and silly when you guys can set it to true by default.

[Fusezion]

The plan is to make the config setting true by default as of release 2.9. They are providing a warning and alert ahead of time to ensure/encourage users to swap. A decent majority of users likely can flip this and have zero issues, however the users who don't have it true and don't use player's uuid will have their previous variables wiped unless they update.

[Moderocky]

when you guys can set it to true by default.

This is exactly what is happening, the option will just be hidden in newly-generated config.sk files.

[TheBentoBox]

Possible improvement: the warning associated with this could account for the variable save pattern.

Many players use a custom pattern to make "temporary globals" by prefixing variables with a certain symbol, typically -, such that they persist globally but only until the next server restart. If a variable starts with this prefix, there is far less odds that it is affected negatively by indexing by player name vs. player UUID. This applies to local variables as well.

I get why the team may disagree here -- technically you can have long-form triggers, or a server which goes days between restarts, where local or "temporary global" variables can indeed persist long enough to span name changes. Figured I'd suggest it either way!

[madebygood]

Basically all skripters know that %player% = nickname.

A stupid useless update that violates the rules even though it already has %player's uuid%.

[Fusezion]

If anyone believes that then they're sorely mistaken. %player% = player object, not a string
This update brings it in line with all other entities

[madebygood]

broadcast "%player%"
just type and print this.

The value should not vary depending on where the same code is used.
And there is already intuitive code called %player's uuid%, so this is an unnecessary update.

[Fusezion]

I suggest reading this #6270 (comment) showcases the actual change

[JerryTheSlime16]

Are there any plans to create an option to disable the warning for users who are keeping the option false?

[JerryTheSlime16]

What happened to "This means that you won't be forced to the new usage unless you regenerate your config file"? Additionally, the lack of this option is making it harder to catch actual issues due to the warning spamming console when all the scripts are loaded.

[sovdeeth]

As I said in the post, this warning will go away in 2.9 and any setting in the config file will be respected.

[rayhandestian]

Does the command /migrate-variable could also migrate variables structured like this: {stats::%player%::assist}?
Or does it only works for variables structured like: {stats::assist::%player%}?

[rayhandestian]

Ah thanks for the clarification. Though I can't really do much as a server admin that knows very little about programming. But I'll try asking/paying someone to create such complicated command for me.

[sovdeeth]

It should be pretty straightforward to adapt the example command. You'd just have loop in the indices of the var and then do a second loop inside to re-set all the various values like assist.

[rayhandestian]

I'm sorry but I might be just stupid or probably you're experiencing the curse of knowledge bias.

[bluelhf]

I wonder if we could write a generic script with a command like /migrate-variable {stats::%player%::assist} which would detect the usages of %player% in the text argument and migrate variables accordingly?

[sovdeeth]

(whoops, wrong comment box the first time)

I'm sorry but I might be just stupid or probably you're experiencing the curse of knowledge bias.

Yeah maybe I'm biased lol, I'll see about making a more general one like blue suggested.

[Moderocky]

I've seen a lot of confusion from people misunderstanding this (actually I was a bit confused myself at first so I'll forgive you) so I'd like to clarify it nice and simply:

There is currently a config option for %player% to be the player's UUID in a variable name.

This currently defaults to false, but you can set it to true.

This option doesn't affect broadcast "%player%"! It only affects {%player%}.

After 2.9, if you make a new config.sk this option will default to true.

The option also won't appear in new config.sk files, but you can write it in yourself if you want to change it.

If you keep using the same config.sk you've always used, nothing will change!!!

Really emphasising this because a lot of people think this is the end of the world -- it isn't, for 99% of the world nothing is actually happening, it will only change if you're:

1. Installing Skript for the first time
2. Deleting and regenerating your config.sk

And in either case, you can still switch it off!!!