I have been doing some Testing for about an Hour and I learnt a lot about how TouchInterest works and how they are created
for i , v in pairs(workspace:GetDescendants()) do
if v.Name == 'TouchInterest' then
v:Destroy()
end
end
I have use this code to remove all of the TouchInterest inside the Accessories Handle
but when the Accessories are Re-Parented Studio and also the Game creates a new TouchInterest (when a New Server is being created)
I have noticed that when an Empty Character with no Accessories inside of it touches an Accessory with a TouchInterest in it will Parent the Accessory to the Character.
If the TouchInterest is removed then it does nothing upon touch
I have also found that when TouchInterest is :Destroy() in the client it won’t Parent the Accessory to the Player.Character even when the TouchInterest is still on the Server
This is also true for Tools and BaseParts with Touched:Connect(function)
So why do I think there should be more Documents on TouchInterest?
Because we know nothing about it and there is nothing on the Wiki that Explains what it does or how it’s even created as you can see here Oops!
“This object has been marked as internal. It currently serves no significant use to developers.”
But it’s in our games and it can cause unwanted behaviors
A Developer might not want Players to pick up Tools/Accessories from the ground when Touched and they have no idea how to do that because there is no Documents about TouchInterest.
A Developer might have Accessories inside an NPC and Anchored all of the BaseParts inside it then a Player Touches the Accessory gets stuck then Resets and then the Accessory is gone from that Server, and they have no idea how to deal with that because there is no Documents about TouchInterest.
(This happened in my game btw so it’s a legit case, it was the reason why I have been doing this in the first place)
A Developer might want to limit Touch Events for a Specific Client and they have no idea how to do that because there is no Documents about TouchInterest.
(Let’s say that you have an Obby and they have CheckPoints you could :Destroy() the TouchInterest of a Specific Checkpoint with a LocalScript to limit Touch Events so that the Server doesn’t receive the Touch Event when the player Touches Level 5’s Checkpoint when they are actually at Level 10, because it’s just useless and it bothers the Server for no good reason)
TouchInterest/TouchTransmitters exist only to server as “Hey, I’m something that cares if something touches me (.Touched connected), please tell me if I’m touched.” It’s to serve as an optimization so that .Touched isn’t fired for everything physical that touches it. You shouldn’t rely on any behavior it gives you, nor should you consider deleting them. Disconnecting the Touched event is how you should be doing whatever you want to do.
Everything you stated should be able to be done without having knowledge of internal objects. If it isn’t able to be done easily, perhaps you should make a feature request.
It’s not hard to delete TouchInterest it’s way easier to achieve Those Use Cases than not deleting them.
That’s not true I’m sure that 99% of people have no idea how to deal with those Situations and it’s easier to :Destroy() them rather than finding a work around it.
it’s easier to :Destroy() them rather than finding a work around it.
Which is the problem. You should be able to do things without having to have knowledge of internal objects. For example, instead of deleting the TouchTransmitter to make it so you can’t pick up tools, Roblox should have a property that lets you do it instead.
So you are saying that Roblox should give us ways to deal with these Situations rather than having to know about TouchTransmitter in the first place?
Well I have thought of making a Feature Request for it but I am a “New Member” and I doubt that Roblox would implement it so this is another Solution. Because adding Text to the Wiki is easier than making a feature.
But I don’t know if it will ever happen because This never got a response.
Roblox generally doesn’t want to document internal features because it gives a sense that they’ll always act the way that was written, which leads Roblox to have some sense of responsibility to make sure games that are relying on what would be undocumented behavior are aware of the changes.
I know about this and have done it multiple times, it’s just that I don’t think that Lead_Top_Contributor will approve it & idk if it will be implemented.
The lead top contributors are very good at handling the feature requests and bug reports, as I have learned first hand. Whether or not they personally agree with your feature request won’t be the deciding factor for them on whether or not they should move the request. Your request needs to be thorough, and follow the guidelines for posting feature requests.
If your request isn’t up to par, from my experience, you will receive help bringing it up to par. I was only nervous the first time I filed a post through them because the help I got the first time was exceptionally good.