Release Notes for 568

They also use “client” and “server” to refer to game servers and roblox’s own infrastructure, so it still could be DataStoreService.


I cannot be sure if this appearing only for me but when i’m clicked on the link it gave me a 404 error.


This is for MemoryStoreService, apologies for the confusion!


The issue should be fixed now!


Release 568 is delivering yet another powerhouse of features that will greatly aid my development and I am happy that some long-standing requests are seeing address.


I am so happy that Roblox finally appears to be investigating long-needed audio search improvements with the introduction of the AudioSearchParams object and AudioSubType Enum. The Licensed Music catalog is so indispensible for low-capital projects and boasts a good selection of tracks with hopefully more to come. I use them frequently for a vast number of projects.

Tooling and improvements to audio are something I’ve personally been requesting for a long time - from my end, I’ve wanted better searching and for Roblox to upload newer APM Licensed Music in addition to some of the other companies they’ve obtained partnerships with (e.g. Position Music). This was also one of my primary asks during Accelerator to the music team. Hopefully audio search updates are a pathway to finishing the job with uploading.

I think the one thing lacking from the object right now appears to be a “catalog” indicator. It seems that AudioSearchParams is currently only tailored towards the format spec for APM uploads unless the same can be applied for other catalogs and then use the tag function as an effective discriminator so you only search, for example, audio from the APM catalog only.

Some feature requests to rep while we wait:

Actor Messages

There are new Actor methods: SendMessage, BindToMessage and BindToMessageParallel. The API looks identical to MessagingService - you specify a name (topic) and if a message with that name comes in, it’ll execute the bound function. They are all thread safe.

Looks like these methods will give us the ability to effectively cross VMs through Actor messages so that we can use some content in other Actors or even outside them? One of the main pain points I’ve had with the current actor model is the inability to nicely import and export data out of Actors.

If this is the VM-crossing we’ve been asking for, that would be stellar and exciting.


Additional thing: apparently we’re finally getting some shapecasts according to this tweet by MaximumADHD!? I’m super excited for this as this is so important to my experience. My team can finally update Raycast Hitbox to support it. Raycast hitboxes are already really powerful for our experience but we have janky workarounds in cases where it doesn’t, so this could fully cover those other cases where we couldn’t use raycasts to track hits. Reference post I made talking shapecasts and our experience’s need for them.


Ill be porting chickynoid to shapecasts asap


Wait so what would be the difference between shapecasts and WorldRoot:GetPartsInRadius() and the other overlap functions?

  • Efficiency: Shapecasts can early-out after doing a minimal amount of work to find only the first hit, vs region queries are in for the whole shebang.

  • Precision: You get the precise distance before collision back from a shapecast which you don’t from a region query.


Alright yeah thats good. Do you plan on adding Capsules too?

A capsule is just a Spherecast. From the center of the bottom sphere, to the top, with the selected radius.

Capsules are distinct from spheres in Unity - according to the API, the spherecasts we’ll getting seem to be more akin to just the Spherecast portion. You could in theory use a spherecast like a capsule but it’s more like an elongated sphere than an actual capsule.

A capsule calls for two spheres and a cylinder joining them, whereas a spherecast is just the one sphere. Although I’m content with and mainly need spheres, having a distinct capsule would be lovely too. That is unless the API will also support two spheres and a joining cylinder.

My hopes are being able to perform a true capsule like the hitboxes in Dark Souls 3:


I thought that spherecasts are just a sphere sweep though, I don’t really understand the difference there in practice. A sweep should result in the exact same envelope, you just have to perform some math to figure out where to do the cast from.

This should produce a capsule:

local function capsuleCast(worldRoot: WorldRoot, pointA: Vector3, pointB: Vector3, radius: number, params: RaycastParams)
	local difference = pointB - pointA
	return worldRoot:Spherecast(pointA + difference.Unit * radius / 2, radius, difference - difference.Unit * radius / 2, params)

I suppose if you are worried about directionality, if your spherecast fails, you can retry with pointA and pointB swapped and then you cover the full range. I guess this is probably slightly suboptimal compared to an in-engine solution, but, I would expect it to produce the exact same results.


local result = capsuleCast(worldRoot, pointA, pointB, 5) or capsuleCast(worldRoot, pointB, pointA, 5)

He’s talking about using the CapsuleCast detecting hits in motion. I.e.: Sweep from where the sword capsule previous was to where the sword capsule currently is.


Oh? I think I understand, thank you.

Looks like these methods will give us the ability to effectively cross VMs through Actor messages so that we can use some content in other Actors or even outside them?

Don’t BindableEvents cover this case already?

What I think is more useful is SharedTableRegistry which was silently added in 564 (Not enabled yet), in my experimentation it allows for state to be shared across VMs.

They do, but i think there comes a time where bindable events just start bottlenecking the speed/performance any sort of Serial to Parallel and vice versa communication along with the fact that data sent via bindable events may or may not morph into something else or just entirely vanish (i had A LOT of cases where table keys would just be transformed into strings from numbers along with random entries becoming voided.) I think actor messages are to pretty much provide the same functionality as bindable events but perhaps without the speed limitations along with the data not suddenly getting mangled across actors?

This feels like an AI generated response
Also I literally didn’t see any of this in the release notes

I actually had no idea that you could cross VMs with BindableEvents. I did see BindableEvent use in Roblox Parallel Worker but wasn’t sure what their purpose was. Thanks, learned something today.

Although I’m not entirely sure what Actor messages are going to be for and how their data is going to be transmitted (e.g. is Roblox going to do a copy of the sent data like they do for some signals or a reference instead), I do agree that being able to create a shared state between VMs sounds like it’d be more amazing. There are some use cases I have where I’d like an Actor to write directly to ModuleScripts for example given that most of my codebase is modular.


I feel like modern discourse is dead if the first thought that comes to mind is AI generated replies. This is the second time someone’s accused me of using AI to write replies. I just like to write a lot, but it feels rude and demotivating if from this point on I’m just going to keep being accused of using AI to write up replies to a topic I’m passionate about (that being development).

Even if it was intended as a joke, this felt in incredibly poor taste. Or maybe I just need to change perspective and take it as a compliment that my writing’s good enough that I sound like a machine to people of today. Either way, not a good time or place.

I get these from checking the API dump diffs in Roblox Client Tracker on GitHub (a project by MaximumADHD). They were previously posted as the immediate reply to a Release Notes thread but haven’t been done lately so I go directly to the source to check them out every update.

Some API changes aren’t listed in the Release Notes while others have dedicated announcement threads when they’re open for betas or release.


Yeah, I understand, but it was 100% a compliment in joking form.

That’s literally what the joke was making fun of in the first place

Oh, that makes sense. I was just curious since the Release Notes are… vague, at best.