Fix gamemode test and implementation

[IceTank]

This fixes the broken gamemode test and also fixes the gamemode implementation for pre 1.10

[IceTank]

Tests are not working. Will fix.

[extremeheat]

This should be a feature

[IceTank]

Gamemode in 1.20.6 is now of type "mapper" https://prismarinejs.github.io/minecraft-data/?d=protocol&v=1.20.6#toClient_undefined. What is that? @extremeheat

[IceTank]

Is that like a string then?

[extremeheat]

Mapper is a enum. The enum values can be found in the protocol files inside minecraft-data for the relevant version.

The current Mcpc mcdata protocol doc gen doesn't support the mapper type. Can be fixed in future by swapping it with the protodef-yaml html gen that bedrock is currently using.

[IceTank]

Related #3508

[IceTank]

Do we wait for mc data to update, or can we merge with just the version check and add the feature later?

[extremeheat]

What change to the protocol was made for this with 1.21? I don't see any changes. The last change was with 1.20.5 with the new world state field. It doesn't seem mineflayer is handling that in the linked PR.

[IceTank]

What change to the protocol was made for this with 1.21?

The login packet in 1.21 now has gamemode as string instead of a number. This means the mineflayer needs to use bot.game.gameMode = packet.gamemode for 1.21 and bot.game.gameMode = parseGameMode(packet.gamemode) for all lower versions.
With update I mean wait for the feature flag to be added in mc data.

[extremeheat]

I mean where in the protocol the change happened with 1.21, specifically a link to the protocol spec changes.

The last change was with 1.20.5 with the new world state field. It doesn't seem mineflayer is handling that in the linked PR.

[IceTank]

Looks like the mc protocol did not change. But minecraft-protocol now maps the game mode from a number to a string by itself. Wiki.vg still has the gamemode value as a number https://wiki.vg/Protocol#Login_.28play.29. But there is a clear change in minecraft-protocol. packet.gamemode gives a number pre 1.21 and a string post or at 1.21. Without a version check, mineflayer won't be able to handle gamemode coming from minecraft-protocol.

minecraft-protocol 1.21.1 protocol.json https://github.com/PrismarineJS/minecraft-data/blob/9cfa6ea955af24d6f481484ebe5d8221a2265421/data/pc/1.21.1/protocol.json#L3713
minecraft-protocol 1.20.3 protocol.json without mapper https://github.com/PrismarineJS/minecraft-data/blob/9cfa6ea955af24d6f481484ebe5d8221a2265421/data/pc/1.20.3/protocol.json#L3359

[extremeheat]

Yes, as you can see in the mcdata link the data is encapsulated inside the world state (SpawnInfo) field. This is not handled in mineflayer and there is an existing feature for that change, spawnRespawnWorldDataField.

[IceTank]

The packet_login now has the worldState field then I guess? https://github.com/PrismarineJS/minecraft-data/blob/9cfa6ea955af24d6f481484ebe5d8221a2265421/data/pc/1.21.1/protocol.json#L4993

How does that match up with Wiki.vg login (play) packet? Or is login (play) at wiki.vg not the same as packet_login? https://wiki.vg/Protocol#Login_.28play.29

[extremeheat]

1. Wiki.vg is not reliable on its own, you need to look at the vanilla source code to be correct. Wikivg is manually updated and sometimes is missing data from being out of date or oversight (it's not validated against anything). But can be helpful for general reference. When it comes to minecraft-data, all the structures have to be perfectly correct or there will be a crash.
2. Some packets encode shared data structures. To avoid duplicating packet fields, minecraft-data may similarly use shared data types for packet fields. This has many benefits including that should there be a change to the shared data type, it's less likely to see desync (eg, one packet is updated and another is not).
3. Inside the protocol.yml files for the versions, atop of all the packet definitions is an "MC:" header that contains the official class name that you can use to lookup the packet def in the official mc code. You can use that to quickly audit any of the packets for correctness.

[zardoy]

It might be a little off topic but shouldn’t parseGamemode function also fixed? packet with game mode -1 is valid but Minecraft client would go to survival mode if the number is out of range (not to spectator or any other)