scaling new baby mob entities down on older clients#1268
Open
mfishma wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resubmitting for feature request #1058
I gave another go of the baby mob scaling, it was much easier using the SharedRegistrations system, and as discussed, minimized impact by making sure to use the filter by type framework to just check for registered mobs (Happy Ghast, Squids, Dolphin). I tied the packet injection strictly to state-changes, unlike the previous PR that more globally hooked to
UPDATE_ATTRIBUTES. So, this should really minimize overhead on the network thread.I still felt this was important, for the Ghastling's hitbox, both for jumping on, and matching the server physics, because when one flies to the player with a snowball, it currently has this jittery rubber-banding interaction where the client thinks the 4x4x4 version is pushing the player away, but the server has to reset them back.
Changes
New
EntityScaleHelperinapi/entities-- a dedicated listener for the metadata, rather than a global packet hook.Updated protocol rewriters to explicitly register the entities we care about & their scale factors.
When the baby metadata is seen, the helper calculates the scale, compares it to the tracked
EntityScaleData, and dynamically injects anUPDATE_ATTRIBUTESpacket into the pipeline to shrink the mob.Also added
cancel(16), hard-coded that because it's a known Ghast attribute, inEntityPacketRewriter1_21_6for the Happy Ghast so older clients don't keep showing the Ghast's "is attacking" fireball face.I know the preference is to attach attributes during
SPAWN_ENTITY. But the baby state of these mobs is entirely dictated by theisBabymetadata (e.g., index 16 for HGs). BecauseSPAWN_ENTITYdoesn't have metadata, I couldn't find a way to know its baby state until its firstENTITY_DATApacket. Injecting the attribute update at the exact moment the metadata is parsed seemed like the most non-intrusive way to guarantee the scale applies.Manual testing