I’m very glad to see Shapecast coming in the near future.
I do believe it would be best for Shapecast to have its own “Position” parameter so developers don’t have to potentially make rapid position updates to a part/mesh to change where the cast originates.
I’m not sure if rapid position updates would have any noticeable affect, but I feel it would be generally better for Shapecast to have it’s own position just for ease of use anyway.
Is there any possibility this could or would be changed before release?
I just feel this would be a nice small improvement.
they also added the assistant from the rdc keynote, but they basically degraded it into an assistant that tells you how to do things rather than actually doing them
How do you use EditableMesh?
I’m trying to make it work, but apparently it’s not allowed according to a localscript from the startergui that i’ve made.
This was planned for from the start, actually.
An optional cframeOverride argument will be added in the first or second release of 2024. Adding optional args is backwards compatible, so it didn’t need to come in the initial release.
Noone be talking about tho the Controllermanager game/studio fix and yet it takes (as of 21th, nov) 8 days to fix/stop pending in for something critical.
The next client release is after Thanksgiving, so you might have to wait until then. I think the fix is in the codebase already; but there’s a release cycle and for the crashes to completely stop there has to be a forced client update on all platforms (mobile, desktop, console)
This isn’t a miss by the way, it was intentionally designed with that parameter order in the first place.
Most shapecasts will likely be from the current position thanks to being used for some form of continuous collision detection or because the part was created for the sole purpose of doing the cast (meaning you’re free to move the part as the way of setting the position).
Having to include the position to use a RaycastParams would probably be more awkward because most raycasts do use a RaycastParams: You’d force the boilerplate of specifying the position.
We’re in the process of changing the envmap system to incorporate information about parts that exist between the player and the envmap probe.
A probe and a focus point-e.g. the camera- should now have a straight line unblocked through them at the moment an envmap is placed. This prevents some issues where the envmap is generated in a space physically separate from the camera such as another room.
Please let us know how this change impacts your experience with the platform.
this does fix some problems that I had previously, but I don’t think its enough for me to rely on using env maps on false reflections. but nice update!.. next add a shader node editor
I really feel like that the envmap system needs to be removed and replaced with manual cubemap placement. Automatic generation is just too broken and unreliable. Not to mention its not even parallax corrected
how about you make it one shouldn’t it have been easier to just allow manual placement, instead of having to do all the math to get those auto generated ones?
shouldn’t it have been easier to just allow manual placement, instead of having to do all the math to get those auto generated ones?
