Fail fast on client-side when getting throttled by the service. Prevents the request queue getting longer and allows callers to handle 429 throttled responses correctly.
Which service is this referring to? DataStoreService?
I don’t believe it would be datastore service as you can’t use that on the client iirc.
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.
AudioSearchParams
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:
- Add newer APM music
- Many APM tracks from already licensed libraries not uploaded
- Have some consistency with uploading Licensed Music and finish the job
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)
end
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.
E.g.
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?