Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix gamemode test and implementation #3508

Merged

Conversation

IceTank
Copy link
Contributor

@IceTank IceTank commented Nov 21, 2024

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

@IceTank
Copy link
Contributor Author

IceTank commented Nov 21, 2024

Tests are not working. Will fix.

Add test function to kill the bot
@@ -25,10 +25,11 @@ function inject (bot, options) {
function handleRespawnPacketData (packet) {
bot.game.levelType = packet.levelType ?? (packet.isFlat ? 'flat' : 'default')
bot.game.hardcore = packet.isHardcore ?? Boolean(packet.gameMode & 0b100)
if (bot.registry.isOlderThan('1.10')) { // gamemode is used pre 1.10 and post 1.20 but in between it's gameMode
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be a feature

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that like a string then?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

IceTank commented Nov 25, 2024

Related #3508

@IceTank
Copy link
Contributor Author

IceTank commented Nov 25, 2024

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

@extremeheat
Copy link
Member

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
Copy link
Contributor Author

IceTank commented Nov 25, 2024

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
Copy link
Member

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
Copy link
Contributor Author

IceTank commented Nov 25, 2024

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
Copy link
Member

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
Copy link
Contributor Author

IceTank commented Nov 25, 2024

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
Copy link
Member

extremeheat commented Nov 25, 2024

  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
Copy link
Contributor

zardoy commented Nov 25, 2024

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)

@IceTank
Copy link
Contributor Author

IceTank commented Nov 27, 2024

Ok, I updated the code to use the spawnRespawnWorldDataField feature instead of the version check. I also implemented @zardoy suggestion with gamemode out of bounds checking.

@zardoy
Copy link
Contributor

zardoy commented Nov 27, 2024

Ok, I updated the code to use the spawnRespawnWorldDataField feature instead of the version check. I also implemented @zardoy suggestion with gamemode out of bounds checking.

thank you very much! A lot of people would benefit from your improvements

@IceTank
Copy link
Contributor Author

IceTank commented Nov 27, 2024

Failing test is unrelated to the changes.

@zardoy
Copy link
Contributor

zardoy commented Nov 29, 2024

@IceTank I think we might be waiting for all ci checks to be green. I think restarting the failing job might help…

Comment on lines +33 to +38
// Either a respawn packet or a login packet. Depending on the packet it can be "gamemode" or "gameMode"
if (bot.supportFeature('spawnRespawnWorldDataField')) { // 1.20.5
bot.game.gameMode = packet.gamemode
} else {
bot.game.gameMode = parseGameMode(packet.gamemode ?? packet.gameMode)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand how this is different from the current code. It does the same thing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pre 1.20.5, the respawn packet and the login packet used numbers to indicate what gamemode the player is in. The problem is that with one packet, it's gamemode, and with the other, it's gameMode.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

packet.gamemode could be a number. But game.gameMode needs to be a string. Also,|| is wrong as it will be falsy if the gamemode is 0. And 0 is a valid gamemode in some versions where the packet has gamemode as a number.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line was broken before bot.game.gameMode = packet.gamemode || parseGameMode(packet.gameMode). It only works correctly in versions after 1.20.5. In versions pre 1.20.5, it would set game.gameMode to a number for gamemodes other than survival. No one noticed that because most people use survival mode and the test was not working, and the change was only made recently.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gamemode lower case is only defined on 1.20.5+ because this function is called with a SpawnInfo object. gameMode is the previous number field. || can be replaced with ??, but otherwise for the else condition it should be this:

      bot.game.gameMode = parseGameMode(packet.gameMode)

parseGameMode can likely just be set to gameModes[gameModeBits] || 'survival']

I think it may be worthwhile to just backport this change inside minecraft-data to 1.20.5 to all the old versions so we can get rid of the logic here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gamemode lower case is only defined on 1.20.5+ because this function is called with a SpawnInfo object.

No, the two different cases have been used before. Handle respawn is used by the respawn packet and the login packet. They both use different cases for the same field pre 1.20.5.

See https://prismarinejs.github.io/minecraft-data/?v=1.12.2&d=protocol#toClient_respawn

And

https://prismarinejs.github.io/minecraft-data/?v=1.12.2&d=protocol#toClient_login

The same protocol uses different versions of the field gamemode.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to focus on the tests instead of the implementation. The protocol is inconsistent and changes a lot across versions. Trying to figure out what the implementation should look like by looking really hard at the code always fails in mineflayer. That's why there are tests. They tell you if something works or not. The current implementation does not work for pre 1.20.5. Your changes to game.js to update past 1.20.5 only when through review because the gamemode test was not working and did not catch the bug with the different cased gamemode fields.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes what I mean is there are things we can fix in minecraft-data to avoid the need to do special handling in mineflayer.

Can you reopen the PR against the 1.21.2 branch?

@extremeheat extremeheat changed the base branch from master to 1.21.3 December 2, 2024 00:10
@IceTank
Copy link
Contributor Author

IceTank commented Dec 11, 2024

@extremeheat What's the progress on this?

@extremeheat extremeheat merged commit 55f32ab into PrismarineJS:1.21.3 Dec 11, 2024
24 of 25 checks passed
@IceTank IceTank deleted the fix-gamemode-test-and-implementation branch December 16, 2024 21:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants