Action Required: MeshPart Heads & Accessories (May 27th)

We’re aware of this issue and hope to fix it soon. We’ll need to rework how the scripts work a little bit.

2 Likes

We have a good idea on how to get HumanoidDescription with Model asset IDs working properly again. For the time being, you’ll want to keep Workspace.MeshPartHeadsAndAccessories disabled.

I will post in this thread when the fix is live.

3 Likes

This update appears to completely disable the ability for custom assets to be loaded via HumanoidDescriptions. When trying to do so, the following error now appears:

‘Humanoid::ApplyDescription() Some requested assets were not available’

Is this meant to be intentional? This unannounced change has been really disruptive for my own games (until realising it was related to this update), and I imagine for many others as outlined by the responses in this thread.

1 Like

We have a fix in the works, but it will take some time to release. In the meantime, you should set Workspace.MeshPartHeadsAndAccessories to Disabled if that issue impacts your game.

3 Likes
	-- Function for when the player gets a new character
	function newCharacter(character)
		print("New Character")
		-- Function for when the character's head hits something
		function hitCheckpoint(part)
			print("Checkpoint Touched")
			-- If the part the character hit is the next checkpoint
			if part == nextCheckpoint then

				-- Get the next checkpoint the player wants to hit
				checkpointNumber = checkpointNumber + 1
				nextCheckpoint = checkpointList[checkpointNumber]
				changeColorEvent:FireClient (player, nextCheckpoint, Color3.new(0,1,0))
				-- Start the race if it's the first checkpoint
				if part == firstCheckpoint then
					player:FindFirstChild('racing').Value = true
				end

			end

		end
		
		character.Head.Touched:Connect(hitCheckpoint)

	end
	player.CharacterAdded:Connect(newCharacter)

This code worked with the old Meshed Part heads but it doesn’t work with the MeshPart heads. The Touched event doesn’t fire for the MeshPart.

MeshPart heads all have CanCollide disabled as of recently; is this intentional? This has been causing a few issues for me.

Yes, this is intentional.

MeshParts have collision geometry that matches their visual appearance. Previously, heads were roughly 2x1x1 (with humanoid scaling applied). The increased size could make certain bundles much taller than they were previously and we wanted to avoid compatibility issues with existing games.

If you’d like to re-enable head collisions, you can simply set character.Head.CanCollide = true after the character spawns. We no longer set the Head’s CanCollide property every frame.

Would you be able to explain the issues you ran into so we can better understand your use case?

6 Likes

Some issues I’ve ran into:

  1. Since head collisions are off, if the player is able to clip their head through a part (e.g. a ceiling), they can also clip their camera through said part and look through it.
    • In my game, the character rotates with the camera, and in first-person the camera position follows the head, meaning that if the character simply looks down they can clip their head into any wall and see through it.
  1. Apparently if Humanoid.BreakJointsOnDeath is true then the head automatically gets collisions re-enabled when you die, but not if it’s false. I had it set to false in my game, but I still had to manually break the neck joint, meaning that when you die the head would fall through the entire map instead of just landing on the ground.

  2. Having head collisions off also seems to make the character slightly less buoyant in terrain water.

3 Likes

I have noticed as a player that since the update it seems that hats fall apart just like the player as well. Before the update they just fell through the baseplate or map. Is this intentional?

1 Like

Are there any plans to set the accessory mesh parts RenderFidelty to Automatic? I think it’d do good for performance.

1 Like

I thought I would mention that this unintentionally broke a lot of scripts, especially nametag scripts. By using mesh parts, the head is loaded in twice because of how R15 works. When using nametags and parenting them to the head before the character fully loads, they are replaced when the new head mesh is added and the nametag is deleted in the old head part.

1 Like

Hey, will materials affect the way heads look eventually? Currently, the most they do is change how metal and rough the heads are, which is annoying. Could this behavior be changed eventually? (keep normal plastic excluded pls)

1 Like

What I find odd is that even though this is now default, the rig builder plugin in studio still uses normal parts with mesh rather than a meshpart for the head?

When will the change also occur for the rig builder?

(Ignore the weird lighting, was testing some things) :flushed:

4 Likes

I still have parts with SpecialMeshes on all three settings, is this feature disabled or something?

1 Like

This sadly only works with R15 for now.

3 Likes

I just realized that recently. Thanks.

1 Like

An option to change the CollisionFidelity of head & accessories would be nice.

3 Likes

Hoping in the future they also allow us to change RenderFidelity as well. Some accessories have an extreme amount of triangles that are unnecessary when viewing from far distances and setting the RenderFidelity to Automatic would surely stop some lag.

2 Likes

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