Around this morning July 1st I noticed some unioned parts I’ve created currently or in the past to have inaccurate collision detection when using the .Touched event in scripts (for example, using .Touched to damage players when they touch the union). While it has not affected all of my past creations, as of testing in a new base plate it appears to affect almost all newly created unions.
Reproduction Steps
Create a Union such that it is uniquely shaped, for my examples I made a Donut and X shape.
Use a script to continuously change the size of the union, I used the script below:
local TweenService = game:GetService("TweenService")
local originalSize = script.Parent.Size
script.Parent.Touched:Connect(function(hit)
if hit.Parent:FindFirstChild("Humanoid") then
hit.Parent.Humanoid.Health -= 2
end
end)
while true do
local TweenInformation = TweenInfo.new(5,Enum.EasingStyle.Linear,Enum.EasingDirection.In)
local TweenGoal = {Size = Vector3.new(0.55,8,8)}
local TweenGo = TweenService:Create(script.Parent,TweenInformation,TweenGoal)
TweenGo:Play()
task.wait(6)
local TweenInformation = TweenInfo.new(5,Enum.EasingStyle.Linear,Enum.EasingDirection.In)
local TweenGoal = {Size = originalSize}
local TweenGo = TweenService:Create(script.Parent,TweenInformation,TweenGoal)
TweenGo:Play()
task.wait(6)
end
Stand within or close the part where your character is able to touch the union as it changes it’s size.
I have created multiple examples below to demonstrate the issue:
Example A
Example B Part 1
Example B Part 2
Expected Outcome (from Example A)
This is how the collision for this union should interact with the player’s character
Control example with non-union part (Accurate Collision)
Here is an example with a non-union part where the collision is accurate
All of the unions used for this bug report have the following properties:
CanTouch = true
CanCollide = false
Anchored = true
CollisionFidelity = “Precise”
This issue is very important to me and for any other developers that use unions, as it creates confusion for everybody involved when interacting with collision of these unions.
Expected behavior
The collision (when CollisionFidelity is set to Precise) should be accurate as it visually appears for the players that interact with it regardless of if a property such as Size is manipulated.
This started occurring in the morning of July 1st (10 days ago) when players in my game started reported that parts of the game were not working correctly, specifically some unions collision detection for doing damage to players just not working at all.
Before this was never an issue, no matter how you changed the size of a union the collision would always be accurate, as mentioned by one of the replies above, it would appear now that the collision for unions don’t update whenever the size property changes.
Hey @Vikram200526, thanks for the report! I wanted to follow up that there was indeed a bug that was exposed through our changes, which has been resolved. However, it’s worth mentioning that the current code you’ve given is dependent on buggy behavior that we hope on changing. Currently, the Touch event is firing on every resize only because of an inefficiency within the current engine, where contact information is regenerated every frame (also causes a lot of Touch event spam). In general, the expectation is that the two events Touch and TouchEnded are used in conjunction, when a touch begins and ends, and that while two parts are touching, no additional events are fired.
I’d suggest the following code as an example of a replacement, which I’ve tested still steadily decreases the HP of the humanoid as in your repro. The following takes damage while X # of limbs of the humanoid are still touching the part.
-- Map that tracks the # of parts per humanoid touching the current script parent"
-- touchedHumanoids["Humanoid"] = 3, e.g.
-- means 3 parts of the humanoid are touching
local touchedHumanoids = {}
-- For every world step, if the humanoid is touching the part, decrease HP
game:GetService("RunService").Stepped:Connect(function()
for humanoid, numparts in touchedHumanoids do
humanoid.Health -= 2
end
end)
script.Parent.Touched:Connect(function(hit)
if hit.Parent:FindFirstChild("Humanoid") then
-- If not previously touching, add the humanoid
if touchedHumanoids[hit.Parent.Humanoid] then
touchedHumanoids[hit.Parent.Humanoid] += 1
else
-- Otherwise, add a new humanoid
touchedHumanoids[hit.Parent.Humanoid] = 1
end
end
end)
script.Parent.TouchEnded:Connect(function(hit)
if hit.Parent:FindFirstChild("Humanoid") then
touchedHumanoids[hit.Parent.Humanoid] -= 1
-- If no parts of the humanoid are touching, remove the humanoid
if touchedHumanoids[hit.Parent.Humanoid] == 0 then
touchedHumanoids[hit.Parent.Humanoid] = nil
end
end
end)
If you’re familiar with flags, this code will work with both the current state of the engine and with the change that will roll out under future flags SimOptimizeSetSizeNonDeferred and SimBulletContactSupportsResize.
The currently broken behavior is definitely on us, but hopefully this change will also bring some performance benefits and reduce some need for Touch Event debouncing. Let us know if you have other questions or concerns.
I will like to note that I’m fine with a damage script not continuously damaging a player that is standing still within the part, my main concern of this original bug report was that the hitbox wasn’t properly functioning with visual changes.
The only time I expect a simple damage script using ,Touched to deal damage to a player (whether or not the damage part is changing its size, position, or nothing) is when the player initially touches the part, or when the player moves around within the part (as parts of their character such as their feet, legs, knees, etc will move in and out of the damage part). This behavior is what I expect, and hope to stay, as there are thousands of old games such as obbies that use simple damage scripts like this one.
Absolutely, the hitbox issue (specifically for non-convex objects) was definitely the bug and has been identified and resolved. In the case of a character moving around, the upcoming changes should definitely still support these cases as long as the limbs are coming in and out of contact when in the damaging part, the character first moving in vs out of the part. etc. which sounds like your use case. If any other issues do come up, though, please let us know and we’ll take a look!