Touched events with OOP

Help and Feedback Scripting Support
1

Hello,

I’m currently working on a project where you can destroy certain parts, present in different spawn areas of the map. The user has a tool to damage and destroy a part using a .touched event client-side on the tool (with remote validation on the server).

I quite like the ‘lua OOP structure’ to organise my project, allowing me to easily add more varied destructable parts. I thought about making the destructable part a class, but I’m not sure how I would handle touched events that way. I would need to find the part object (instantiated class) based on the given part (given through the touched event) in some way. This is probably possible by collecting all instantiated objects in some script (EDIT: and looping over them, finding the right part) but I already have spawner objects holding the parts for a specific area.

Is there a way to do this without big overhead? Otherwise I’ll just keep my functional structure using instance values for the part properties and a general module for processing the attack on a given workspace part.

Thanks in advance.

2

You could tag those objects with CollectionService | Documentation - Roblox Creator Hub

3

I already tag the parts for being destructable, but I don’t quite see how I could use this system to quickly bridge between parts and the instantiated part objects in a script?

4

Hey. Sorry if this might get a tad bit messy. I’m on phone. But overall I think you’d need to construct something along the lines of this;

local destructableClass = {}

destructableClass.__index = destructableClass
destructableClass.__tostring = "destructablePart"


destructableClass.destroyed = false

function destructableClass:destruct()
      destructableClass.destroyed = true
      self.basePart:Destroy()
end

function destructableClass.new(basePart)
      local self = setmetatable({}, destructableClass)
      self.basePart = basePart
end
5

Yous choose to return self, given self you can create a collection of destructable parts. Or add onto the class in any way you really wanted.

6

I see what you mean now. OOP would intend you to connect the event from the destructible part itself, which would result in too many connections I would assume. In true OOP languages this wouldnt be an issue which is why I don’t think you can find a satisfying solution here.

1 Like
7

Sorry if I was unclear with my question.
Yeah I understand your answer, but how would I, let’s say, get the right “destructableClass” object from a

-- client
toolPart.Touched:Connect(function(touchedPart)
	...
    -- invoke remote
end)

-- server
remoteEvent.OnServerEvent:Connect(function(player, part)
    -- validation
    ...
end)

Is there a data structure that I can use for this that doesn’t introduce a significant overhead? The only thing I can think of right now is a collection of all “destructableClass” objects and looking over them for the right part.

8

Thanks for your answer.
I also currently think this as there’s no existing connection between the event and the made up abstraction of the parts. But still curious as to what others have to say.

9

You want one signal. To find the part? And then this part will have data used in your code?

If so you’d use a table, and when the signal is fired for .touched. youd loop though that table, to find that part.

Each object inside of that table, will be a table that has the object, the object name. A guid etc. Youd find the target part from the object, if TocuhedObject == IndexedExample.Object …

10

For things like this, I like to just add an integer “ID” to the object and store the same value inside of the object as a NumberValue. Then simply store it in a dictionary like DestructableParts[UniqueIntegerID] = Constructor.new(basePart, UniqueIntegerID). When a client touches a part, the server can easily look up the object and it’s methods using the dictionary and ID found inside of the part.

1 Like
11

My systems take advantage of shared and _G, using these tables to store data such as custom classes and geberall data. Maybe you can do the same. Manipulate shared or _G to house those classes. So when you do fire .Touched. you can get a hold of the class.

Either that or you could bind a custom .Touched event to the class itself.

destructableClass.event = basePart.Touched

12

This is the obvious answer but introduces big overhead when dealing with many objects unfortunately.

13

Smart! Didn’t think of that, might try :slight_smile:

14

Hm. So why not make sub tables, just tables inside of tables. shared.touchedEvents = {}

15

If your talking about a network call, then I’d advice not too. A hacker could easily spood/manipulate that. Try to handle all .touched events in the Sever.

16

How can an exploiter still manipulate a remote call with spam protection and sanity checks?
I handle collision client-side because I prefer playability above perfect security.

17

  1. .Touch relies on a players FPS. Most people use FPS boosters. So they’re faster and can do things quicker.

  2. A dedicated hacker will find ways to spoof and trick you system. But I understand what your doing.

As long as the checks and server verifies it. It’s fine. But I’m just saying be careful for when it comes to handling stuff on the client.