Parenting Models to Character Causes Lag

Hello, I’ve identified a problem in my game that causes lag spikes according to the Micro profiler tool (Really handy tool, by the way):

  • Player will click on a piece of equipment
  • The game applies server-sided stats (Armor rating) and sends a remote event to the client
  • The client receives the event, which indicates that the player equipped something successfully
  • The equipment module script gets the gear: cloning the model, welding to torso, then parenting it

The lag spike will only occur: when the model is parented to the character.

What I have tried:

  • Slowly welding the parts (This did not change the lag)
  • Slowly parenting the parts (This causes more stutters, time, and sometimes inaccurate positioning)
  • Server-sided parenting (Not optimal, builds more parts, still causes lag spikes)
  • Changing the model parent to a workspace folder (This creates another issue: First-person vision is blocked by equipment, and players can’t see anything due to the transparency modifier from PlayerModule. However, this successfully fixed the lag spike.)

I’ve attached a video to demonstrate what is happening.

I’m not sure how to fix this issue, but I would like to post this issue here because I feel like other people might run into the same problem as me, when working with similar framework / systems. If anyone has a solution to this issue, or perhaps a clue on how to fix this, that’d be amazing and it would help anyone in the future looking for this type of solution.

Edit: I forgot to mention, even though this lag spike is very minor in this test, it becomes a larger issue when over 30 players are in a game, who are constantly equipping and unequipping items. Therefore, this causes a lot of lag spikes throughout the game.

1 Like

Turn of CanCollide, CanTouch, CanQuery and also change the hitbox to be either it was hull or box.
Also I suggest to make a global script to handle all the equipping which would also reduce the lag, after which you can also add a player-debounce so that players cannot spam equip/unequip.

A player debounce would look something like this:

local debounces: {[Player]: boolean} = {}

-- On equip
if debounces[Player] then return end
debounces[Player] = true

... -- script here

task.wait(2) -- cooldown time 
debounces[Player] = nil
1 Like


The descendants of the models, prior to your post, have their CanCollide set to false, CanTouch set to false, and the CollisionFidelity set to Box. I cannot change CanQuery because Query is required to allow the players interact with the gear (Clicking, Prompts, etc.).

For the scripting, there is already a global script that handles all of the equipment, as well as a debounce of 1 second per player. The issue does not lie in the scripting itself, but the parenting of the models.

You could always add a click hitbox instead or change CanQuery to false on click.

Another suggestion I could make is making use of an already existent part inside every player with a MeshObject instead of a MeshPart, then changing the TextureId and MeshId of whichever part you clicked. If I am not mistaken this could greatly reduce the lag, due to MeshParts being able to use Materials and their PBRTextures, this would mean you only need to update the models instead of constantly having to delete them. Also if there are any additional parts I suggest to make them into one Mesh else only duplicating those.

Interesting suggestion, I think that the complexity of the models however, will increase the part count significantly because the MeshParts / MeshObjects (We have both in the models depending on who contributed the models) vary from 1 instance to over 30 instances; If every character spawns, it would mean duplicating those parts each time.

I’m not saying that your suggestion doesn’t work, it will definitely help games with smaller MeshPart counts in their models and each character is guaranteed to wear the gear. However, in my game, not every player wants to wear the gear; replicating the MeshParts wouldn’t be an optimal decision if they’re not even using the equipment.

For the click hitbox, is this referring to a raycast / overlapping method to detect items, or is this referring to something else? I’m confused how this would be an optimal alternative to click detection, respectively.

Actually, I think I understand your proposal about the model idea. You would store these into a storage and only pull them when they’re required. Is that correct?

I dont think you understood what I meant exactly, basically get every single of the Meshes into 1 Mesh (preferably) then make use of MeshObjects. This in itself would probably reduce lag due to the fact that it would not need to render the PBRTextures.

Then if you want to go the extra mile because these meshes are all single mesh objects, create a Part inside each character (teamed player preferably). This part would also have a MeshObject inside of it, then on changing to a different MeshId it will just update, if the player is already wearing the same protection (MeshId) then it will just become nil. Then you’d copy over all the properties of the models, quite easy:

local playerMesh, clickedMesh = ..., ... -- path to MeshObjects
for _, propertyName in pairs({"MeshId", "TextureId", "Offset", "Scale"}) do
   playerMesh[propertyName] = clickedMesh[propertyName]

My CanQuery suggest was either using seperate parts to handle the click detection or updating CanQuery to false on :Clone().

1 Like

I see, yeah that makes a lot more sense. What if there’s multiple MeshIds? All of the gear you see in the video are composed of different MeshIds, textures and such.

Lastly, to merge all of these meshes would require a bit of blender / maya work, wouldn’t it? It basically makes this into a 3d modeling optimization job from what I’m getting.

Are the model Parts Massless? Adding anything with mass to a Humanoid can cause all sorts of issues as well.

Yes, all of the parts are essentially not impacting any physical properties in the game; they’re purely rendered as cosmetics

You mentioned that the lag spike could become a larger issue with more people in the game. Did you test this out or is that an assumption you made? The problem might not actually be as serious as you might think, since it seems like this is behavior you can’t work around unless you didn’t weld/parent properly or the meshes have a high amount of vertices.

Also, you should test whether these lag spikes occur when you parent it in workspace. If it still lags, then that might mean that the meshes have a lot of vertices.

The video shows the lag spike occurring in the micro profiler. I’m not sure how else you want me to explain where the lag is coming from: It’s clearly showing in the video.

Theoretically, even if it isn’t coming from this particular entity in the game; let’s say it’s coming from another script: That doesn’t even matter in this case, because the video shows what is happening within this scope.

You can also check out the game if you want to verify it yourself, but whatever reassures you.

You should reread what I said, I was asking if you’re sure that the lag spike is as bad as it seems and if it’s not something you can ignore as this seems like something you can’t fix because of the nature of Humanoids. I get that the lag spike is coming from the parenting, I was just saying that it might not be as bad as you might think. But that’s something you’ll have to test in greater scale.

And I answered your silly question; If you can see evident that the lag is occurring within 1 player (Me, testing the game), then you can theorize that the lag happens to a larger server (30+ players). How difficult is it to understand that?

That’s why I linked you the game; so you can test this theory. Please stop posting here if you’re not contributing to the efforts of the current issue.

What’s with the attitude towards someone trying to help? The lag spike is coming from something you can’t actually change, unless you decrease the amount of parts getting added to the character.

So there’s this “contribution to the efforts of the current issue” that you are asking for: The only way to fix this is to lower the complexity of the equipment. Ways to do this include:

  • Decimating the meshes used to decrease the amount of vertices.
  • Merging the meshes like someone else suggested which should lower the lag spikes by a lot, since the reason why the lag spikes happen in the first place is because of the amount of parts getting added to the character.

It’s not hard to see the issue for yourself; there is literal proof that the issue occurs on a small-scale in the form of a video, and there’s a game that’s live and release, which is currently experiencing this problem. So you’re asking if it occurs as a large-scale, then you doubt that it’s actually a serious problem. If you just test out the game yourself, you can see that it is actually a serious problem. Why are you doubting that the issue isn’t serious, when literally dozens of people in my game are complaining about this issue? Do you think that I’m just creating this post just to satisfy a small little issue? That’s nonsense.

The reason why I’m doubting if the problem is serious is because the problem seems like something everyone has to deal with. Something that can’t be fixed besides doing something that you didn’t want to do because, I quote:

Lastly, to merge all of these meshes would require a bit of blender / maya work, wouldn’t it? It basically makes this into a 3d modeling optimization job from what I’m getting.

This is me assuming that the code to weld and parent the equipment is as good as it can get, since you didn’t even bother giving more detailed information about what you’re actually doing besides just:

  • The equipment module script gets the gear: cloning the model, welding to torso, then parenting it
1 Like

The only thing that I’m getting from your “contribution” is literally a rephrasal of what the first user said, what is the point of spitting out the same suggestion if it’s already posted? So pretentious… If you would just read through the entire thread, you would easily obtain the same information that I just wrote, and you can see what you basically rewrote.

Like I said before, your posts are not contributing much to this issue, so you should just exit and find a new issue. It’s clear that you don’t have any knowledge about the scope of the problem.

1 Like

You are so petty for no reason, there is no solution to this problem besides what this first user already said. I am repeating it because you seem to be too dense to understand that.

1 Like

Yeah, okay mate. I can barely see that you have any portfolio, so your opinion is invalid. Perhaps you should try getting more work and make a portfolio before you start giving advice, that’ll make you credible for anything at least.

1 Like

Are you trying to start some devforum beef or something :worried:
Invalidating an opinion because you can’t handle the truth.
Ridiculing me while I’m still trying to help while I try to ignore your weird attitude that came out of nothing in the first place.

That’s crazy…

1 Like