Release Notes for 420

[stravant]

Shooting rays is overwhelmingly more common that drawing lines, at least for whitelist raycast, since I investigated the usage of whitelist raycasts to decide whether the new API needed to support them (As you can see, it did). I strongly suspect the same is true for ignore list raycasts.

[Halalaluyafail3 (FindFirstChild)]

@Maximum_ADHD

Added Class PluginDebugService : Instance [NotCreatable] [Service] Added Class DebuggablePlugin : Plugin

I’m curious about these, what are they for?
I’ve noticed a few new things in Customize Keybinds which seem to be related (they don’t seem to do anything?)

It looks like you can create a DebuggablePlugin with Instance.new, unlike a normal Plugin; and the children of PluginDebugService must be DebuggablePlugins.

[ColdSmoke]

new Raycast function feels weird to me. In almost any circumstance where I’m using raycasting, I want to receive the endpoint regardless of whether the ray hit anything or not. So Raycast takes a direction using object space, like old raycast function, except now it doesn’t guarantee to return the world space result like old raycasting functions. So then now in most scenarios I have to use several extra lines of code to compensate for that

I guess it’s weird that rays feel like a hybrid between rays and segments, but then it’s missing segment information that I feel like I expect given the kind of information I use to create it

@stravant Perhaps this could be some sort of optional functionality for RaycastParams in the future? like an AlwaysReturnResult parameter or something?

[tnavarts]

In almost any circumstance where I’m using raycasting, I want to receive the endpoint regardless of whether the ray hit anything or not.

What kind of pattern is making your code like this? I designed it that way because in my experience I tend to write logic like this which doesn’t want to generalize the hit and non hit cases:

local hit = --raycast
if hit then
    -- do something with the hit
else
    -- do something else
end

The new API is certainly more verbose in some simpler use cases, I’ll give you that, but that’s the natural cost of making it more future-proof and performant. It’s generally better for a more advanced functionality like raycasting to be verbose and flexible, as you can always wrap it in your own helper function to make using it for your particular use case more terse.

Perhaps this could be some sort of optional functionality for RaycastParams in the future?

That will not happen: A RaycastResult is fundamentally supposed to represent information about a hit surface, so getting a one in a situation where you didn’t hit anything would be very surprising behavior. You’ll have to settle for wrapping it in a helper function.

I guess it’s weird that rays feel like a hybrid between rays and segments

This is just an unfortunate result of the fact that the engine can’t actually do an infinite length raycast leaking into the API. If you performance test you will notice that longer raycasts are actually slightly slower even when they don’t pass close to anything significant… an infinite length raycast would take infinitely long currently.