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

Bedrock stack network id protocol fix for 1.16.220 to 1.20.10 #749

Closed
wants to merge 6 commits into from
Closed

Bedrock stack network id protocol fix for 1.16.220 to 1.20.10 #749

wants to merge 6 commits into from

Conversation

irkmandeer
Copy link
Contributor

The stack_id field in StackRequestSlotInfo and Item needs to be varint and not zigzag32.

This causes a mismatch of the stack_id for an item stack between the inventory_content, inventory_slot, inventory_transaction, item_stack_request and item_stack_response packets.

The problem can be seen by using the relay to print the inventory_content, item_stack_request and item_stack_response packets; moving an item in the inventory, then comparing the stack_id from the packets

Code references

The change was applied and tested for for all supported (and playable 1.16.220+) versions against vanilla bedrock servers.

@extremeheat
Copy link
Member

Actually, I am confused here. Both your links do not show an unsigned varint, they show a signed varint, which is what the current field is. How are you sure this field is not wrong as opposed to the others?

@extremeheat extremeheat self-requested a review August 9, 2023 17:36
@irkmandeer
Copy link
Contributor Author

irkmandeer commented Aug 10, 2023

You are absolutely correct!

I specifically checked the other implementations since both types work, just as long as they are consistent. I've got no idea why my brain decided on varint when it's clearly zigzag and network ids always seem to be zigzag.

I wrote tests for all this, so let me change it to zigzag, and run everything again.

Do I need to close this PR and open another one?

@extremeheat
Copy link
Member

Do I need to close this PR and open another one?

Up to you

@irkmandeer
Copy link
Contributor Author

irkmandeer commented Aug 24, 2023

Sorry for the wait, I was out of action the last couple of weeks.

I just created a new PR 762 for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Closed
Development

Successfully merging this pull request may close these issues.

2 participants