Will AddToFilter also have a RemoveFromFilter counterpart?
The API is intended for use in the common pattern where you incrementally add things to ignore as you progress a raycast. You don’t need a remove call for said pattern.
There’s performance reasons why trying to micromanage the ignore list via a remove call would not be a good idea and would actually be counterproductive over setting a fresh ignore list so it could actually be actively detrimental to have in leading people down the wrong optimization path.
Thanks to the ones who added such feature, with this announcement I even noticed a flaw in my code where I was using table.insert for the FilterDescendantsInstances list. Quick question, is it expected for all tables to change every time we assign it to anything that comes from the engine?
Why do these tables change as well? Is like they get clone or something. Could you let me know, I am curious as to why BindableEvent/Function clone the tables I passed via Fire. Why do tables assigned to OverlapParams are not the same when accessed?
I am sorry if I explained myself terribly here, but I hope you get the point. Why is this thing in place?
Also, should you guys warn developers about these behaviors because for sure many errors like the one I committed for table.insert can happen to many.
Yes. The engine needs a chance to “respond” when you change things, and if you were just directly modifying the contents of a table the engine was holding for you it wouldn’t get a chance to respond.
That’s for Instance the same reason that you can’t do part.Position.X = 5, if you could attempt that there’d be no clean way for the engine to know that it needs to take action. The engine needs to see you set part.Position = ... to know it needs to take action and update the physical position.
It would have been better for us to make the table returned when you get raycastParams.FilterDescendantsInstances a readonly table (in the same way that Vector3s and CFrames are immutable) so that people couldn’t make your mistake but I didn’t think of that at the time when adding it and changing it now could break stuff.
Unfortunately I would call this one of my biggest API blunders, a lot of people fall into the trap of trying to insert into the filter list. We may be able to solve this with a LINT warning about that pattern in the script editor at some point.
A detail to add here is that AddToFilter will be available to call in Parallel Luau stage (there are synchronization reasons that make FilterDescendantsInstances unmodifiable during parallel execution)
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.