MeshPartHeadsAndAccessories now disables character head collisions

Reproduction Steps

  1. Open the “Starting Place” template in Studio
  2. Set MeshPartHeadAndAccessories to “Default” or “Enabled”
  3. Press Play
  4. Enter the house, jump, observe there are no collisions with the player’s head
  5. Press Stop
  6. Set MeshPartHeadAndAccessories to “Disabled”
  7. Press Play
  8. Enter the house, jump, observe there are collisions with the player’s head

This currently can only be reproduced in Studio, not live games.

Expected Behavior
MeshPartHeadAndAccessories should keep the player’s head CanCollide true. This is historically what the behavior has always been.

I was unable to find if this change was intentional, but if it is, it messes up backwards compatibility with numerous doorways and small openings. Conversely, CanCollide MeshPart heads could be pretty awkward. I’m on the fence.

image

Actual Behavior
MeshPartHeadAndAccessories sets the player’s head to CanCollide false. It makes the player’s camera behavior and interactions with level geometry incredibly awkward.

If this intentional, it may make sense to announce this change in behavior to developers. This change will break several hallways and a few puzzles throughout my games.

image

Workaround
Either set MeshPartHeadAndAccessories to false or use a custom script to re-enable the player’s head collisions.

Issue Area: Studio
Issue Type: Other
Impact: Moderate
Frequency: Constantly
Date First Experienced: 2021-10-02 11:00:00 (-04:00)
Date Last Experienced: 2021-10-02 11:30:00 (-04:00)

5 Likes

Sorry no one ever got back to you about this! This decision was in fact intentional, so we are closing this.

Is it intentional that the CanCollide property of the Head is forcibly enabled with the MeshPartHeadsAndAccessories property disabled?

It was my understanding that R15 rigs were, contrary to the original post, not supposed to have Head collision, but having the property disabled forces the CanCollide property of the Head to be enabled upon character load/Humanoid state change. If a developer wants the property off but also wants to disable Head collision (whether it be in R6 or R15) wouldn’t this behavior interfere with that?

I understand the case you’re making here, but we aren’t going to attempt to make any changes to support a use case for having MPHA disabled. So any developer that wants to be in this state needs to handle this case themselves - and I guess I should warn you not to sink significant time into this since we will at some point be removing the ability to disable MPHA. If you believe you have a use case that requires you to disable MPHA, please DM me separately because we’d like to hear about it.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.