Replying here because 577 appeared at the same time.
Removes pitch and roll from VR camera.
What exactly does this mean? Are we, as developers, no longer able to apply pitch and roll to the VR camera? Does that mean making 3D space simulators â a category of game that Robloxâs physics excel at â is now impossible in VR?
When nothing is selected, holding down modifier keys other than the Shift key no longer moves the camera in Studio. For example, Ctrl+D no longer moves the camera to the right.
EXCELLENT change! Much appreciation for fixing these random shortcut problems. I believe this may also solve long runtime problems in Studio, as well â some operations would grab certain keys and âhold them hostageâ, making it impossible to press shortcuts that used them.
WAIT WAIT, Really?
When is this estimated to be completed? Currently I have to spam raycast to find floor positions and make the objects remain on the floor.
Could you guys add to that list a way to keep objects some studs from ground? Will be really helpful too⌠
EDIT:
I skipped something:
Thanks for this as people in my game can currently unequip tools in such way. (Hopefully this change doesnât disrupt games that uses such feature though).
Omg this is amazing. Now we just need the ability to not put the tool away when you press itâs associated key (optional ofc). Thank you guys.
I want to add that Wireframes do not render on Mobile devices.
Yes, thatâs one of the fixes!
The idea is that we should naturally be be able to change this without disrupting anything:
-
If you have a custom backpack: There is no backspace on mobile, so if unequipping was important to your game there already must be some other way to do it for mobile players to use.
-
If you donât have a custom backpack: People can just unequip using the backpack button.
Thank you for the fixes! Is there any plans on when the bug where layered clothing cause lag when changing unrelated part properties will be fixed?
Reference:
Should I be concerned about this?
Since I have some things that use GetDescendants() and want to make sure my existing code wonât break. Iirc it originally returned a simple table just like how GetChildren() worked. I usually use this in a âfor i, v in pairs(Model:GetDescendants())â loop to loop through each descendant of something.
GetDescendants will return the same runtime value, change is only for Luau static analysis to be more precise.
But this will actually not be enabled in current release because of a different small issue with it.
Yeah, Iâm super curious about this as well. I wonder what this means
YES! This is an awesome update! I didnât like how pressing backspace would forcibly put away whatever tool that I was holding, when I wanted to repurpose that key as a âdrop/throwâ button.
When I added my own inventory bar UI, I had to program tools to detect when Roblox returned them to the backpack and fire a RemoteEvent to re-equip themselves. Soon (whenever this goes live), Iâll no longer need to use this hackish workaround.
What do the backslashes mean? I know that this is one of those âvariable type definitionâ that developers can add after creating a variable like this:
local example : number = 1
local array : {string} = { "hello", "world" }
âŚand I know that you can use a vertical pipe (|) to indicate that a variable may be one of multiple possible types, and a question mark means that it may or may not be nil, but what do the backslashes indicate?
PerAxis and the backspace change for tools are both incredible, thank you so much!!
You can ignore the slashes, it is just a bug with release note generation where {} ended up with âescape sequencesâ like \n \t etc.
Really sad, two release notes today and they still didnât fix the major bug causing a lot of games that rely on animation events to break. There is no provided workaround for the time being until it is fixed either.
I cant wait for this to come out I have been waiting for ages as force equipping lags low performance devices and itâs even more confusing for switching toolsâŚ
What exactly can we do with this? Will we finally be able to use keycode without worrying people having other sorts of keyboard layouts as AZERTY?
Do the VR camera adjustments apply to the core scripts only, or does this affect our scripts too? I have prototypes that rely on the ability to rotate the camera such that the horizon is intentionally not level.
I understand that keeping the horizon level is generally a good practice to follow so that people donât get motion sick, but if this is a safety measure being implemented at the engine level, then I would prefer that games have an ability to bypass it as a way of indicating that we promise we know what weâre doing - some kind of checkbox or enum, perhaps.
KeyCode is just an example, nothing is changed with keyboard input handling. There was just a minor bug with editing enum attributes when they had a very long value list and KeyCode was the most obviously impacted.
My gosh, finally. No more
for _, desc: Instance in a:GetDescendants()
Wait so does this allow for AlignPositions to only apply force on specific axes? Documentation for Enum.ForceLimitMode is missing so I canât check rn
I donât have much else to say that would affect me but yeah all-in-all a decent update 