String -> UUID

[Burbulinis]

Description

Let the Strings become UUIDs!

This PR aims to convert the current implementation of UUIDs (strings) to actual UUIDs. This may help some addons (like SkBee with UUID tags) and it performs better. This PR has also cleaned up UUIDs in general. I.e. it no longer uses regex (or try-catches), there is now a method in the Utils class which returns whether a string has the valid pattern for a UUID.

With this PR, UUIDs will look some what like this:

set {_uuid} to "uuid" parsed as uuid

set {_entity} to entity from {_some uuid}
set {_player} to player from {_some uuid}
set {_offline player} to offline player from {_some uuid}
set {_world} to world from {_some uuid}

# parsing strings as offlineplayers/worlds, etc. still work
set {_offline player} to "some uuid" parsed as offline player
set {_offline player} to "some name" parsed as offline player

command /is-this-a-player <uuid>:
    trigger:
        send true if player from arg is set

set {_string} to string within {_uuid}

There are some PRs that could use this. For example, #7069.

---

Target Minecraft Versions: any
Requirements: none
Related Issues: none

[ShaneBeee]

Looks good, I've wanted this for a long time.
Just a few small concerns.

[sovdeeth]

Can you elaborate exactly how this improves things? you mentioned "performs better", is there testing to back this up? I see there's a x from uuid syntax, which seems reasonable, but doesn't need uuids to be changed to exist.
Also a lot of tests are failing.

[TheLimeGlass]

This is going to break existing code, since a string cannot be compared to a UUID without the user knowing and parsing as a UUID.

Adding a String to UUID converter is a bad idea though, as the parser throws lots of random inputs through the parsing of ClassInfos and converters. It's always been best to avoid String to anything convert.

So for this reason, it's probably a breaking change. This current implementation is good to avoid this issue.

[Burbulinis]

Can you elaborate exactly how this improves things? you mentioned "performs better", is there testing to back this up? I see there's a x from uuid syntax, which seems reasonable, but doesn't need uuids to be changed to exist. Also a lot of tests are failing.

I have done tests and they appear to show that this method is faster. The x from uuid expression is only done because (string within uuid) parsed as x would be quite literally stupid. With the expression, you don't need any checks whether the UUID is of valid format. Either way, method or not, this is better because every time a string is used you'd need to check if it's correct.

[Burbulinis]

Tests were failing because of a silly problem from me. This PR will not have breaking changes

[Burbulinis]

This is going to break existing code, since a string cannot be compared to a UUID without the user knowing and parsing as a UUID.

Adding a String to UUID converter is a bad idea though, as the parser throws lots of random inputs through the parsing of ClassInfos and converters. It's always been best to avoid String to anything convert.

So for this reason, it's probably a breaking change. This current implementation is good to avoid this issue.

Instead of a String to UUID converter, I have added a UUID and String comparator which solves this issue.

[sovdeeth]

Can you elaborate exactly how this improves things? you mentioned "performs better", is there testing to back this up? I see there's a x from uuid syntax, which seems reasonable, but doesn't need uuids to be changed to exist. Also a lot of tests are failing.

I have done tests and they appear to show that this method is faster. The x from uuid expression is only done because (string within uuid) parsed as x would be quite literally stupid. With the expression, you don't need any checks whether the UUID is of valid format. Either way, method or not, this is better because every time a string is used you'd need to check if it's correct.

I meant, like, numbers showing the performance benefits, I'd still like to see those.
You make a good point about verification though.

[Burbulinis]

I meant, like, numbers showing the performance benefits, I'd still like to see those. You make a good point about verification though.

Here are the tests, https://discord.com/channels/135877399391764480/836220422223036467/1331680812546134097

[ShaneBeee]

Looks good, nothing major.