The title pretty much sums up what I want to do. I have a hitbox with a script inside of it, but the problem is once I destroy the hitbox and the script, the game occasionally freezes for a part of a second due to destroying the script for some reason.
2 Likes
The lag seems unavoidable. Just setting the parent of a script to nil will cause it. Do you know if this freeze happened in the client too and not just studio?
You could instead use a script that looks for tagged hitboxes with CollectionService and handles the logic for many on its own.
1 Like
Known bug: Destroying a Script or LocalScript with :Destroy() causes a lag spike - #36 by mashkov_dev
The issue seemingly occurs intermittently, with most ppl reporting issues in studio but not in the actual game client.
The issue likely stems from what you could call “replication cost.” When you create or destroy an object that exists on both the server and the client (like a hitbox), the engine has to serialize and send that information over the network. There is some sort of bug on the backend side that sporadically causes this process to hang somewhere when deleting scripts, maybe in garbage collection? Potentially if there is some race between running code and :Destroy()? Unsure. What is going on in the script under the hitbox though?
For now, you can work around this issue by implementing a single and persistent handler that never gets destroyed.
2 Likes
I made a script to do this, but the weird thing is that half the time I play test works as intended (function runs when remote event to spawn hitbox is fired, detects hitbox) but for some reason about half the time it will instead only detect spawned hitboxes if another hitbox already exists, so essentially the first hitbox never gets detected, only the second and so on.
local cs = game:GetService("CollectionService")
game.ReplicatedStorage.RemoteEvent.OnServerEvent:Connect(function()
local hitbox = cs:GetTagged("hitbox")
for i, v in pairs(hitbox) do
local parts = game.Workspace:GetPartsInPart(v)
print(parts)
v:Destroy()
end
end)
You can see in the video where during the first test it works as intended. The hitbox detects the parts inside and is then destroyed. But in the second test where no code was changed in any way, the hitbox only works the second time, and it only works when there is already a hitbox.
How are the hitboxes being created? Also, can you see if the first hitbox bug is more consistent with more replication lag? (increase “Incoming replication lag” in studio settings)
It appears that increasing replication lag did not do anything, as in it’s still a bit of a coin flip whether it works or not.
The hitboxes are part of the model which is being cloned. The model contains the sound, particles, and hitbox. I can send you the whole clone script if you’d like.
Oh okay, I was mistaken.
That’d be great!
edit: I think this is getting a bit off topic at this point though. @mc3334’s reply is great to mark as a solution. As for implementing a separate script for hitboxes, you might want to make another topic or continue this in forum PMs.
Move the hitbox logic outside of the hitbox itself. It’s better if you have one main script for all the hitboxes instead of many small ones acting independently. If you want parallel behavior you can utilize things such as events and threads within that main script.
It also solves the issue because then you wont have to delete any scripts.
Hello,
I’ve started a new topic if you’d like to continue this.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.