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

add xander's patches #13

Merged
merged 2 commits into from
Apr 18, 2024
Merged

Conversation

MicrocontrollersDev
Copy link

@MicrocontrollersDev MicrocontrollersDev commented Apr 18, 2024

Description

From patcher's upstream pr number 28

the shader one was denied with a stupid reason and i see no reason why it shouldnt be added

the other one was denied under fears it may send a packet to server. i have no clue how to confirm nor deny this removed for this reason

Related Issue(s)

Fixes #

How to test

Release Notes

Fixed entering an entity in spectator mode while in third person applies shader

Documentation

@Wyvest
Copy link
Member

Wyvest commented Apr 18, 2024

Remove the block breaking one, I am also slightly worried about that

@MicrocontrollersDev
Copy link
Author

Remove the block breaking one, I am also slightly worried about that

done

@Wyvest Wyvest merged commit 653f123 into Polyfrost:main Apr 18, 2024
1 check failed
@MicrocontrollersDev MicrocontrollersDev deleted the xander-fixes branch April 18, 2024 23:07
@Mixces
Copy link
Member

Mixces commented Apr 19, 2024

Remove the block breaking one, I am also slightly worried about that

Based on my understanding of the source code, I can conclusively say that it won't cause issues... I've also been using a modified version of this fix for the better part of 2 years in my private mod and I've been perfectly fine on all servers.

Furthermore, the fix could be modified to also include Adventure mode rather than just Spectator mode as well. Minecraft does actually check to see if the player has the ability to edit (aka in Survival Mode), however, the check (isAllowEdit) isn't in an effective place.

The check is located at the top of PlayerControllerMP#clickBlock, and the clickBlock method is invoked within the PlayerControllerMP#onPlayerDamageBlock method which is where the actual problem arises. The game only invokes clickBlock at the end of onPlayerDamageBlock... and well... the section of code above this call basically checks to see if you had damage progress on the last block you were touching and will send block-breaking packets and will return true. That means that whatever block you were mining before you switched to Spectator or Adventure mode will still be valid to mine (it'll show a block-breaking animation and particles yet won't actually get destroyed) despite the fact that shouldn't be able to mine. If you were wondering why this issue doesn't happen with Creative Mode, well, the game actually checks for Creative mode at the top of onPlayerDamageBlock and acts accordingly.

Nevertheless, whatever you guys decide is best for the general population, I'll support it. I can totally understand why it's a worry to add this check although I personally am of the opinion that it will cause no harm.

@Mixces
Copy link
Member

Mixces commented Apr 20, 2024

Actually now that I think of it, there is probably a safer way to do it without the fear of manipulating packets in a non-vanilla fashion 🤔

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