[/spoiler] ok it sounds great! I could use this in my placement system[spoiler]
I remember asking for this feature 6 years ago, my prayers went through!!
Thanks so much, the rotatedRegion3 module broke a few months ago and started becoming unreliable so this is a welcome update and I can finally remove my band-aid fixes.
2 Likes
Can we get an OverlapIgnored property on OverlapParams which would work the same way as WorldRoot:ArePartsTouchingOthers()? Or maybe a CubicAreaOverlapIgnored property?
So can someone clear this up for me, is this perfomance wise better than region3, gettouching parts. and can i use these new methods to replace them for hit detection, combat, abilities.? because i’ve seen some comparison saying that new methods are slower
Hopefully this helps you to decide what to use :).
1 Like
Finally had the chance to play around and introduce these into ZonePlus. All-in-all, really awesome, it’s finally great to have an official substitute for RotatedRegion3 on top of all the additional performance gains!
Expanding upon this, it’d be great to have an option (for instance a property within OverlapParams) to return parts outside the Workspace (such as in ReplicatedStorage), in addition to being able to pass through objects not in Workspace.
With ZonePlus, we essentially reverse how checks are performed. Instead of casting queries on the zone parts themselves, queries are instead performed on player characters, using the zone parts as a whitelist.
This has been one of our most heavily requested feature and would be a really neat addition to the API!
Then with ZonePlus we could create a new constructor that generates parts from a given region and parents these to ServerStorage/ReplicatedStorage (which is currently impossible to do):
local zone = Zone.fromRegion(cframe, size)
4 Likes
This is already possible, you simply need to put the parts outside of the workspace inside of a WorldModel, and you will be able to raycast and region query against them on the WorldModel the same way you would against parts in the Workspace by calling those functions on the Workspace.
Returning a mixture of parts from different physical spaces doesn’t make a ton of sense, but creating a separate physical space for parts to exist in via a WorldModel already works.
5 Likes
The post talks about baseparts, but I’m curios if this would work on anything else. Notably, meshes and terrain?
Meshes and Terrain are technically BaseParts as they inherit from that class so the answer is, probably yes.
Are there any plans to have this support terrain? This would save me a lot of time programming and probably resources too if done because my solution now is to use raycasting to get terrain.
1 Like
This is perfect for my dynamic destruction script!
Support in what way? Terrain is voxel based, so you can naturally query whether cells are full / empty using the GetCell / GetCellsReadVoxels API
1 Like
Terrain::GetCell is deprecated, and Terrain::GetCells dosen’t exist.
Use Terrain::ReadVoxels instead.
3 Likes
My bad, thought I remembered the API off the top of my head but I should have looked it up. My brain is still thinking in 2014.
9 Likes
The dude wrote over several pages of benchmarks and spent considerable time testing the performance of the new APIs, which many people wanted answers about, and for you to accuse him of faking this with no reasonable motive is very toxic.
I guess that some people just won’t accept the truth and would rather say it’s false and make up a stupid excuse
1 Like
even a roblox staff member said it’s inaccurate and false but ok
a question, how get touching parts work? it loop on all parts from workspace and make a math?cause people said me get touching parts be slower if have a lot of parts on workspace.