Ben Smith
- codename_B
- codename_b
- Europe/Stockholm
- Yes
- No
Is duplicated by https://bugs.mojang.com/browse/MC-49375
Several users have multiple UUIDs, documented here is one user "jumbokiller2001".
{"name":"jumbokiller2001","agent":"minecraft"} {"id":"e01c28e44f2443389440e07974a47393","name":"JUMBOKILLER2001"} {"id":"6d0409ceb40c4580b2075e19d6a12003","name":"JUMBOKILLER2001"} {"id":"a8e27c733217448ab7166ae32f00799c","name":"JUMBOKILLER2001"} {"id":"a5d19e7fb70f4a7ab9bfaf02eda2562a","name":"JUMBOKILLER2001"} {"id":"311a4cacf4584766aa89212a55d9ea3d","name":"JUMBOKILLER2001"}Code used:
A very simple wrapper created from https://github.com/Mojang/AccountsClientString name = "jumbokiller2001";
{ return profiles[0].getId(); }
Profile[] profiles = profileRepository.findProfilesByCriteria(new ProfileCriteria(name, "minecraft"));
if (profiles.length == 1)else {
{ System.err.println(gson.toJson(profile)); }
for(Profile profile : profiles)return "Couldn't get the UUID!
";
}
Sounds more like a bug in the conversion code Mojang-side since names are unique and don't care about casing.
Just saying, called it.
Kicking players is a really childish end to working out an actual solution for this, and doesn't take into account instances where a user changes their system time.
An actual solution would be something more along the lines of scrapping having the data in the player spawn packet, etc, and adding in a new packet for players skins, that way the skin url only has to be resent every time a player joins the server, along with moving away from the current really inefficient system.
PacketXXXSkinData
Jimmy and Jenny are playing on their realms server, Jimmys connection is a little bit slow but he decides to have a bit of fun by teleporting himself far away and back again very quickly.
Jenny gets disconnected because Jimmys spawn named entity packet gets sent before his despawn entity packet due to him being despawned and spawned in the same tick, as far as the server is concerned.
Relevant client code causing the issue;
<<code>>
public void a(gb paramgb)
{
double d1 = paramgb.f() / 32.0D;
double d2 = paramgb.g() / 32.0D;
double d3 = paramgb.h() / 32.0D;
float f1 = paramgb.i() * 360 / 256.0F;
float f2 = paramgb.j() * 360 / 256.0F;
GameProfile localGameProfile = paramgb.e();if (this.g.a(localGameProfile.getId()) != null) {
{ "Server sent invalid player data." }
this.e.a(new fr("disconnect.genericReason", new Object[]));
}if ((this.e.h()) && (this.f.E() != null) && (!this.f.E().d())) {
{ this.f.ac().getTextures(localGameProfile, true); }
trycatch (InsecureTextureException localInsecureTextureException) {
{ "Outdated server! Pretending to be 1.7.8" }
if (!(localInsecureTextureException instanceof InsecureTextureException.OutdatedTextureException)) {
this.e.a(new fr("disconnect.genericReason", new Object[]));
}
}
}bnx localbnx = new bnx(this.f.f, paramgb.e());
localbnx.p = (localbnx.S = localbnx.bZ = paramgb.f());
localbnx.q = (localbnx.T = localbnx.ca = paramgb.g());
localbnx.r = (localbnx.U = localbnx.cb = paramgb.h());int m = paramgb.k();
{ localbnx.bm.a[localbnx.bm.c] = new adc(ada.d(m), 1, 0); }
if (m == 0)
localbnx.bm.a[localbnx.bm.c] = null;
elselocalbnx.a(d1, d2, d3, f1, f2);
this.g.a(paramgb.d(), localbnx);List localList = paramgb.c();
if (localList != null)
localbnx.y().a(localList);
}
<</code>>Jimmy and Jenny are playing on their realms server, Jimmys connection is a little bit slow but he decides to have a bit of fun by teleporting himself far away and back again very quickly.
Jenny gets disconnected because Jimmys spawn named entity packet gets sent before his despawn entity packet due to him being despawned and spawned in the same tick, as far as the server is concerned.
Relevant client code causing the issue;
public void a(gb paramgb) { double d1 = paramgb.f() / 32.0D; double d2 = paramgb.g() / 32.0D; double d3 = paramgb.h() / 32.0D; float f1 = paramgb.i() * 360 / 256.0F; float f2 = paramgb.j() * 360 / 256.0F; GameProfile localGameProfile = paramgb.e(); if (this.g.a(localGameProfile.getId()) != null) { this.e.a(new fr("disconnect.genericReason", new Object[] { "Server sent invalid player data." })); } if ((this.e.h()) && (this.f.E() != null) && (!this.f.E().d())) { try { this.f.ac().getTextures(localGameProfile, true); } catch (InsecureTextureException localInsecureTextureException) { if (!(localInsecureTextureException instanceof InsecureTextureException.OutdatedTextureException)) { this.e.a(new fr("disconnect.genericReason", new Object[] { "Outdated server! Pretending to be 1.7.8" })); } } } bnx localbnx = new bnx(this.f.f, paramgb.e()); localbnx.p = (localbnx.S = localbnx.bZ = paramgb.f()); localbnx.q = (localbnx.T = localbnx.ca = paramgb.g()); localbnx.r = (localbnx.U = localbnx.cb = paramgb.h()); int m = paramgb.k(); if (m == 0) localbnx.bm.a[localbnx.bm.c] = null; else { localbnx.bm.a[localbnx.bm.c] = new adc(ada.d(m), 1, 0); } localbnx.a(d1, d2, d3, f1, f2); this.g.a(paramgb.d(), localbnx); List localList = paramgb.c(); if (localList != null) localbnx.y().a(localList); }




Don't panic. This code doesn't "break" inventory event cancelling.
It does however cause derpiness client side.
Whoever formatted this for me, you're a saint, thankyou.
That doesn't fix expiring skins for new joins after 24h
/tp commandercarrot ~1000 ~ ~ followed by /tp commandercarrot ~-1000 ~ ~
Just to be clear, I'm talking about the "Server sent invalid player data." message here.
http://nooooooooooooooo.com/
Oh ok, so false alarm?
I'm unclear if this is still an issue or not.
If the intended behaviour is for the username -> uuid lookup to return a single uuid, so as far as it looks, even if it's for the demo account reasons, it's still an issue.
Is that an authoritative statement, or a suggestion?
Looks like the vanilla minecraft server assigns the wrong UUID to this user.
I just ran a test startup of an online mode vanilla server and it exceptioned out (but still converted) Nico.dat to 3bfb7c8d-02a2-4ece-8b56-c7e22a553be3.dat
Bug still present in vanilla server, please mark as unresolved.
It looks like this issue can currently arise from legacy account holders/demo account holders buying accounts and this not being properly handled by the system, but obviously we don't have any idea about the internal workings, so we can only conjecture.
As far as server owners are concerned, yes, it is possible to get a wrong uuid for a user, and in fact is quite likely if you happen to get one of the users affected by this bug since it seems the incorrect uuid is the ony first in the list, which will result in (when it gets fixed) the correct uuid being the second one, which means that any server that tried to convert them beforehand will have the wrong uuid saved!
Yeah, just drop those 200 users. They're people who refunded their Minecraft purchase or were removed for other reasons.
How very strange, well caught!
As far as I'm aware this is due to Mojang rate-limiting a critical API of theirs recently, I'm not 100% sure why...
This isn't a technical issue, this is a bug with the rate-limiting of the API by Mojang.
While it might be technically a DOS, it's a very low threshold they've set. This bug report serves to prove that they are harming vanilla gameplay with their rate-limiting.