I’ve always found it really awkward that region and ray methods are members of Workspace. I guess it kind of makes sense because you’re doing calculations based on parts in the Workspace, but those methods are more related to their respective data types than Workspace.
The following methods of Workspace should be deprecated: FindPartOnRay, FindPartOnRayWithIgnoreList, FindPartsInRegion3, FindPartsInRegion3WithIgnoreList, IsRegion3Empty, IsRegion3EmptyWithIgnoreList
In their place, the following methods should be created:
It seemed messy to have separate methods just for changing the type (instance or table) of the ignore list. Overloading the paramater seems much cleaner imo
Regions are kind of useless right now. We can’t exactly easily control what is inside the contents of a region (any number of unanchored parts could have been flung into the region), and no matter what we set maxParts to, up to the max, we may find that the parts we were searching for have been cut off by randoms that hit the maxParts limit prematurely. Being able to whitelist our searches will ensure that we don’t have unexpected parts interfering with our searches, and saving us the trouble of repeatedly calling FindPartsInRegion3WithIgnoreList(), adding the previous search’s results to the ignore list, until all parts in that space are accounted for. Rays would use the same type of parameter for consistency and because it’d also be useful in some cases to raycast in a whitelist (e.g. a weapon that could shoot through solid walls (whole map))
As far as I know these methods only find parts in Workspace, so that’s why it makes sense to have the methods as members of Workspace rather than Ray and Region3 (since that would imply it could also find parts in other places than Workspace).
As far as I know these methods only find parts in Workspace, so that’s why it makes sense to have the methods as members of Workspace
I appreciate your thorough reading. Second sentence:
I guess it kind of makes sense because you’re doing calculations based on parts in the Workspace
And then afterwards in the suggested methods, the very first parameter of each is locationDecendantsInstance, meaning regions/rays could search in places other than exactly Workspace, making regions (especially) / rays more useful, and cutting their ties to workspace
I didn’t mean to say that it makes sense conceptually (you already said that), but that it would make sense to me that you actually can’t perform ray/region operations on parts outside of Workspace, because parts outside Workspace are not in the spatial octree (otherwise they would have to check the parent for each part in each physics/rendering step). A staff member would have to back me up on that though.
Yeah its probably because the operations rely on data structures that are tied to workspace.
But I would like a whitelist / ability to limit the query to a specific instance and its descendants. Currently I do multiple queries with the same data, to build up the ignore table until it hits something I dont want to ignore (the alternative would be to stick like everything in the workspace into the table which isnt exactly practical).
These methods are methods of Workspace because they work using a spatial acceleration structure that is used for physics (that we use for physics broadphase, lighting, streaming and path finding). We can’t currently provide efficient methods with the interface that is suggested in OP.
Even given a subtree of Workspace, the only way for us to perform the operation efficiently is to run the usual operation discarding parts that are not descendants of the root of the subtree (or rather sometimes a bruteforce search is more efficient but it’s hard to tell up front).