Is This Code Expensive?

YO

So I have a script that hides player’s characters each time they spawn if they’re not sharing the same match ID as you, so I can hide players who aren’t playing together and reuse the same maps.

Basically the code goes:

  1. CharacterAdded connection to every player
  2. Check if the they share the same match ID as you
  3. If they don’t share the same match ID, parent their character to a folder in replicated storage, if they do then parent their character to a folder in workspace.

That’s how simple the code is, but I’m afraid in a 40 player server, when a 4v4 match ends, all 8 characters spawn at the same time, and the code parents them to a folder.

The reason I’m posting this is because recently players have been jittering every 5-10 seconds, where they all the character movement (except yourself) lag for 0.5-2 seconds, which harms gameplay because it’s an third person shooter.

Let me know if you can help, thanks!

2 Likes

If this code is expensive, let me know what other ways I can hide players from each other that doesn’t interfere with mouse hit position.

I feel like this is very unnecessary and that you could just make a place where players get teleported to. (lobby separate from actual game)

Also, can we see some of the code??

1 Like

There’s lobbies for that. Teleport

Our game has same server match making, so that’s not a good idea. The only solution I’m looking for is what to do with characters, involving anything bigger than that isn’t a good idea.

1 Like

uhhhh… the code??

also I’m in your game right next to your rn LOL

1 Like

Well I already explained how the code works, it just parents the characters to replicated storage and workspace.

I want to know if parenting the characters is expensive and causing lag spikes

Maybe the problem is with how it checks if the match ID is the same??
(also, it’s very possible that this happens just because of server/client lag)

I don’t think parenting them should lag (if you’re doing it from the client).
I don’t see why it lags for 0.5-2 seconds. Are you, by chance, checking their match ids every frame or only at the start?

It’s not possible to make any conclusions from the two pieces of information you’re giving.

1 Like

Do (if you haven’t) :Connect(AlreadyExistingCharAddedFunc), without it you are creating a new function each player (bad)

2 Likes

this code schema by itself is not the cuplrit for any lag. Its likely some other code causing the latency issues.

the given schema is just

on character added, if not same matchid then parent character to repstorage

thats literally the simplest thing.

image
you do have a lot of incoming receive packets, could be implicated in lag.

4 Likes

Mmmm, that’s a good point.

@CoIdYeti, you can check in the console the performance of the server/client and you can see if memory usage goes up over time. If it goes up over time, then most likely it’s because of this.

No, closures don’t do this big of a difference, in fact it’s just a micro optimization, but either way it’s better to not have closures as it’s bad practice

2 Likes

Why are you parenting the character to replicated storage.. just make it invisible using .LocalTransparencyModifier and not it’s not expensive at all loll…

It might interfere with mouse.hit, if he uses it.

1 Like

Parenting characters between Workspace and ReplicatedStorage causes the entire character model to be re-parented. This triggers network replication for all parts, humanoids, and accessories
With 8+ characters doing this simultaneously, it creates network spikes. The physics engine has to re-evaluate spatial relationships each time.. kayteai_dunno8p option is valid and so would be a folder on the workspace.. You can see the spikes happening and when they are going off, so that pretty much tells the tale. I’m going to go with yes, it’s too “expensive” in this case. At least how you’re doing it, so it might happen to more than one at the same time..

2 Likes

Just make the characters invisible for the other clients

I’m not sure that it’s the character spawning/reparenting that causes the network lag spike. It could be - but the main issue is that it’s already high from having the data of 40 players’ movement and actions sent to the client all the time. Parenting them to ReplicatedStorage does not stop the server sending data, and the client still receives and processes it.

You might need to create a solution involving a bit of custom replication if you want large same-server matchmaking lobbies like this.