Good news, I’m touching the InsertPoint because I’m working on restructuring the code backing all those insert paths at the moment, and that’s one of the things I’m going to fix as part of it. Insert from File will work the same as Paste.
There’s an issue where the Animation Editor doesn’t work on the MacOS version of Roblox Studio.
• Keyframes don’t appear on the keyframe
• Importing an animation opens up a glitched out tab
• Adding body parts to Animation doesn’t work
There’s also an issue where the Tools (move, scale, and rotate), break and refuse to move when intersecting an object, or just using the tool for a few seconds.
Do you have the “Collisions” toggle in the Model tab of the ribbon turned on? That’s what that toggle does for intersecting objects.
Oh yeah. So I uncheck it? Thanks for the clarification.
Was there any changes to physics? I’m getting quite a few reports and from my own testing today that the physics in my group’s bowling game suddenly is behaving very erratically. One of them being that a lot of time the bowling pins are becoming too bouncy.
i concur, the character controllers in my game move erratically ingame but not in studio. Something has gone wrong this release.
@fireys and @Rodj1, do you have repro files or videos we can use to track down the physics issue?
Feel free to DM me directly.
where v621 release notes i would like to see thanks
It would be good if this behaviour only happens in the workspace. If it happens outside of the workspace (e.g. ServerStorage) it might result in things intended to have a certain location in the world getting moved around unintentionally on re-insertion, so the location data would pretty much get lost.
Don’t worry, that’s the same way paste always works. If you paste into a location outside the workspace the pasted object will remain in the same position it originally was. Would be the same with inserting from file.
TL;DR: Insert point only impacts pasting into the 3d scene.
I’ve encountered a problem with setting a Humanoid’s CameraOffset while in shift lock and I believe it is coming from the recent changes. I’ve been listening to when MouseBehavior is changed to set a custom CameraOffset and it has worked correctly up until now. The Humanoid will display the correct CameraOffset I want but the camera won’t actually shift to it and will instead shift to the default shift lock value (1.75,0,0). I’ve had no luck with forking over the camera module and changing the default value.
UserInputService:GetPropertyChangedSignal("MouseBehavior"):Connect(function()
if UserInputService.MouseBehavior == Enum.MouseBehavior.LockCenter then
--humanoid displays CameraOffset as (5,3,0) but camera actually only moves to (1.75,0,0)
Humanoid.CameraOffset = Vector3.new(5,3,0)
else
Humanoid.CameraOffset = Vector3.new(0,0,0)
end
end)
I’m very sorry to be late but I’m quite curious about CommerceService? Are we getting outside-world shops within Roblox soon?
Finally this feature will be fixed, I tried playing with cameraoffset but turns out there is a bug on what was said in this note, I guess other developers got around this bug by messing with the playermodule:
Seriously, can someone make bug report on that, this issue has been out for a week and yet we haven’t heard anything from Roblox’s staff regarding this issue
It appears that this issue is no longer exist as of today
No coincidence, we reverted something which we suspected caused that, so you shouldn’t have to worry about it coming back.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.