Feature Request: Manual Event Firing for Touched and PropertyChanged
Hello Developers!
I’m proposing a significant quality-of-life and functionality improvement for Luau scripting in Roblox Studio—the ability to manually fire certain key events, specifically Touched and PropertyChanged.
Currently, these events are exclusively tied to the engine’s physics simulation or internal property changes. Adding a method to trigger them manually would unlock powerful new design patterns and simplify many common scripting tasks.
Proposed API Additions
I suggest adding a new, non-yielding function to the relevant instances (e.g., BasePart for Touched, and all Instance objects for PropertyChanged).
1. Manual Touched Event Firing
Target Instance:BasePart
Proposed Function Signature:
Part:FireTouched(OtherPart: BasePart)
Behavior: Triggers all connections to Part.Touched as if a physics collision just occurred, passing OtherPart as the argument.
Use Cases for FireTouched
Tool/Ability Design: Triggering existing Touched logic after detecting a hit via non-physics methods (e.g., raycasting, Region3).
Server-Side Verification: Manually triggering collision effects when the server detects a valid overlap through custom or corrected means.
Behavior: Triggers all connections to Instance:GetPropertyChangedSignal(PropertyName) as if the named property had just been modified. It does not change the value of the property.
Use Cases for FirePropertyChanged
UI Synchronization: Forcing UI or visual elements to refresh based on the current property value without having to unnecessarily set the property value (which can sometimes cause replication or memory overhead).
Testing/Debugging: Simplifying unit tests by mocking a property change state.
Analysis: Pros and Cons
Category
Pros (Advantages)
Cons (Concerns)
Code Structure
Increased Reusability: Logic can be centralized in one event handler and triggered by both engine events and custom script actions.
Potential for Confusion: Developers must be careful not to create infinite loops by having the event handler call the Fire... function.
Flexibility
Custom Hitboxes: Enables complex, non-physics-based hit detection systems that leverage existing Touched connection scripts.
Misuse in Replication: If not properly guarded, developers could use this to simulate events that the server should be controlling, leading to desync issues.
Efficiency
Optimization: Allows for targeted property signal firing (FirePropertyChanged) without the need to actually modify the property value (which may involve replication/overhead).
Engine Integration Difficulty: Implementation might be complex, as these events are currently deeply tied to the engine’s internal physics and property management loops.
Testing
Simplified Unit Testing: Makes it easier to write unit tests that check event handler logic without needing to simulate full physics/property-setting scenarios.
Conclusion
I believe these additions would be invaluable to the Roblox development community by promoting cleaner, more reusable code and enabling more sophisticated game mechanics. The potential for misuse is manageable through clear documentation and developer best practices.
What are your thoughts on implementing these manual event firing APIs?
Wow. Not only is this completely AI slop, it has absolutely zero actual use cases!
Have you ever heard of a little thing called manually calling for updates of items and writing custom logic?
For example:
local function onPartTouched(hitPart: BasePart)
print(hitPart)
end
workspace.Baseplate.Touched:Connect(onPartTouched) --// Touched call
onPartTouched(workspace.Baseplate) --// Manual call
-- Same logic goes for PropertyChangedSignal
There is LITERALLY no use case for this. If you need cross-script communication, BindableEvents exist. If you need to manually fire a .Touched event, refer to the block above. This literally has no use.
I’m sorry for the engineer who has to read this nothing burger of a request.
You’re not supposed to be suggesting exact solutions to satisfy a feature request you’re writing. Instead, clearly define the problem that developers are facing, and generally how that could be fixed with a new feature. Explicitly suggesting methods or API endpoints is not what you should focus on.
I agree that for isolated unit testing, you can simply call an individual function connected to an event to verify its internal logic.
However, that approach completely misses the point when we talk about testing event-driven architecture and integration.
Testing System Integration, Not Isolated Units: The entire purpose of events like Touched is that they allow multiple, decoupled systems to respond simultaneously. When three or more functions (e.g., a DamageModule, an EffectModule, and a StatTracker) are connected, we need to verify that a single event trigger correctly executes all of them—that’s integration testing. Calling each function individually requires knowing the implementation details of every listener, which defeats the principle of event decoupling.
Efficiency and Test Harness: Relying on running the full game simulation, waiting for character loading, and physically triggering the event is incredibly slow and brittle for automated tests. We need the ability to run a test harness that can instantly fire the event:
OR
Would you rather load your entire character deal with any custom sequences many times over to test a single event every time you want to test a single touched event
This is precisely the goal. Being able to programmatically call MyPart:FireTouched(mockHitPart) allows developers to bypass the overhead of the physics engine and test the event’s full propagation instantly, making testing reliable, fast, and deterministic.
The whole reason for events is propagation. The event simply announces a change; it shouldn’t matter where the signal originated. Allowing manual firing lets us efficiently test the wiring and the collective response of the system, which is a massive quality-of-life improvement for serious development.
Basically a common problem every developer faces is testing events so im proposing being able to fire custom events so developers can propagate an event and see exactly if the logic they made works without the need to constantly press play and test something a touching a part directly but if you could fire the event manually you could hit run and instantly see the results of a propagated event
No developer faces this because there’s smarter solutions around it that already work.
Literally all of your points are voided by BindableEvents and RemoteEvents. They are already capable of exactly what ChatGPT has suggested.
If you wish to replace .Touched connections with an easier method specifically to test, again as I said before, just manually call the function OR replace the .Touched with a BindableEvent.
Also, no you don’t have to load your character to test .Touched events (unless they’re done on the client in which case you have to load your character either way). Its easy enough to insert an unanchored part and move it to the part that has the .Touched connection binded.
your forgetting that bindable events are for custom use cases. I’m talking about use cases where you are using the built in engine interfaces
yes you can move a simple part but that totally neglects the core argument because if your game is just a simple part then there is’nt really any complexity involved and sound like a incredibly basic game with no real skill involved
Touched Events can be used for hitbox such as for melee fighting mechanics , in bullet mechanics they are used multiple times on walls or player damage calculation, volume based situations and much more
the whole point is that when you making multiple mechanics with instance related events there is no other way to test the full logic with out running the full game
but with the ability to fire the in engine events you can skip that need entirely also it would be entirely a crude test to simply drag a part and hit random things
local base = workspace.Part
base.Touched:Connect(function(hit)
print(base, hit)
end)
local base = workspace.Part
game.ReplicatedStorage.TouchedEvent.Event:Connect(hit)
print(base, hit)
end)
Nothing but whats being connected. It takes not even 5 seconds to swap out the code, and in the case where you’re testing, your code already isn’t final so whats having some temporary connections going to hurt?
If you’d like to have both, it’s as simple as this:
local base = workspace.Part
local function onTouched(hit)
print(base, hit)
end
base.Touched:Connect(onTouched)
game.ReplicatedStorage.TouchedEvent.Event:Connect(onTouched)
There’s already simple solutions around what this feature request is. Also, the use cases you give aren’t exactly the best. In the case of Melee PVP systems, you want to make sure things work but also feel good. Its easier to kill 2 birds with 1 stone than it is to get it working and then have to rewrite everything because it doesn’t feel good.
Also, as for “having to press play and wait for it to load”, it takes at most 2 seconds, it’s really not that slow.
As I said, this is a problem literally no one faces.
Feature Request: Manual Event Firing for 
Proposed API Additions
Analysis: Pros and Cons
Pros (Advantages)
Cons (Concerns)
