Being able to set Mouse.TargetFilter to an array of objects rather than a single object has been requested on the developer forums before, but every time the response is “Can’t replicate a table as a property”. Replicating it to the server obviously doesn’t matter – what those responses have been referring to is telling other local scripts the new target filter. You can’t do that because even if you give them a pointer to the table’s memory address, that address can change and now the other local scripts don’t have the correct target filter.
Despite that, we absolutely do need to be able to use multiple objects for target filter – it’s not so much that we need other scripts to know what the target filter is, but just so that we A ) don’t overwrite the target filter of other plugins / public scripts that aren’t under our control and B ) don’t have to screw up our game’s hierarchy by making every object that needs to be ignored a descendant of workspace.Ignore (really not a fan of parenting my first person arms / weapon models to workspace.Ignore because then I have to manually clean them up since they don’t get automatically removed with the character)
The solution? Following the example of selection:Set() and selection:Get(). That behavior is exactly what we want with mouse.TargetFilter. We could do mouse:GetTargetFilter() and mouse:SetTargetFilter(), but I have a feeling plugin developers and people who make public domain scripts wouldn’t play nicely and keep in mind that there might be other plugins/scripts that use TargetFilter as well. The best API implementation to ensure cross-compatibility between all plugins/scripts is the following:
mouse:AddToTargetFilter(objects)
mouse:RemoveFromTargetFilter(objects)
mouse:GetTargetFilter() (returns table of target filters)
Adding and removing objects from the target filter would be pretty much specific to individual plugins/scripts and they wouldn’t interfere with each other this way. The only instance you’d really run into problems is if you had a plugin/script intentionally clear the whole target filter, and you could just uninstall that plugin/remove that script since it was that bad – most plugins/scripts would just work perfectly with each other if they used the previously mentioned API.
We obviously can’t remove mouse.TargetFilter for backwards-compatibility, but we don’t want setting mouse.TargetFilter to get rid of all of the items you added with AddToTargetFilter() either, because then older plugins would still overwrite your TargetFilter. The best thing to do would be to have TargetFilter completely separate from the new target filter table. When calculating mouse.Target/mouse.Hit, the mouse would ignore everything in the new target filter table + the object in the TargetFilter property, and setting the TargetFilter property and adding items to the new target filter table would not affect each other.
This new API implementation for the mouse’s TargetFilter would help out tremendously with cross-compatibility between plugins / scripts and save us the trouble of screwing up our game hierarchy just to move something into workspace.Ignore. Please?