can you tell me what does this mean ?
not sure how i feel about this; while it is technically accurate i don’t think implicit coercions should be encouraged, they cause way more trouble than they’re worth
6 Likes
In many cases, we were previously enforcing that concat operands be only strings, and have updated the type solver to accept numbers in those cases as well.
I can’t immediately think of -how- but I just get a slight feeling that this is gonna cause some sort of problem somewhere.
1 Like
I suspect this means we will be able to manipulate the camera using welds and constraints.
Just a guess though.
Or perhaps making it easier to attach things to the camera (such as hats??)
2 Likes
Really want the ability to round only specific corners in a GUI. Hope to see this soon!
6 Likes
Not quite. Aurora is the upcoming server authoritative API that Roblox has teased at recent RDCs and on the creator roadmap.
From what’s been either disclosed publicly, been found through API dumps, or disclosed in release notes, here’s what we think we know about it:
-
It is slated to release sometime after summer 2025.
-
It introduces two new services,
AuroraServiceandAuroraScriptService, as well as a new script typeAuroraScript. -
It contains all features necessary to:
- Run code on the server and client simultaneously.
- Rollback and re-simulate the entire Roblox datamodel, Luau VM, and physics engine as one unit, likely in the event of mispredictions.
- Predict ahead for remotely owned physics assemblies.
The obvious intent behind all of this is to finally, finally, finally eliminate all client-side exploits, particularly physics and character exploits, that have plagued the platform for years, and to do it in a developer-friendly way.
To any concerned parties, I repeat once again that all information in this post has been disclosed publicly in one way or another. 
30 Likes
This was always valid Luau behaviour, inherited from Lua 5.1, and never caused any errors at runtime. They’re just fixing a false-positive warning you would get for writing perfectly valid code.
--!strict
local apples = 5
-- Previously, you would've gotten a warning here,
print("I have " .. apples .. " apples")
-- It did not error when ran,
-- but you would need to use `tostring` to get rid of it
print("I have " .. tostring(apples) .. " apples")
-- Side note: In this case, you can write cleaner code w/o concatenation at all
-- Only for `print`, which will add spaces between each argument you pass
print("I have", apples, "apples")
-- "String interpolation"
-- Can be used for any string
-- Note the ` instead of a "
-- (backtick vs quotation mark)
print(`I have { apples } apples`)
4 Likes
There’s an issue with box selecting in the new beta explorer.
I can’t box select outside of instances, but I could in the old explorer. Not sure if they intentionally removed it, and also don’t know if it affects anything, so just saying here.
There’s a bug currently with box selecting from the area after the last Instance. If you select from the empty space beside the Instances it will work.
1 Like
I don’t mind this change in principle — but there was no early warning. This broke quite a few of my plugins, which scan for and manipulate all PVInstances in workspace.
1 Like
For reference we did do some early testing of it in-experience without it breaking anything there.
I’m curious what specific pattern broke.
I figured this would be a relatively safe change from the plugin perspective because a lot of codepaths involving PVInstance subclasses have to be coded defensively anyways to avoid breaking from stuff like new BasePart types.
Did stuff break break, or just the camera getting moved too when it shouldn’t have been?
1 Like
Stuff broke in the sense that we call PivotTo on all PVInstances, causing the Camera to be moved.
There was also a case (my personal favorite) where one of our models (an elevator), which happened to have a ThumbnailCamera, would now treat it as a valid floor.
(PS: We’ve already fixed this through excluding the camera from PVInstance checks)
Ideally you wouldn’t have to exclude the Camera.
Do you just mean you did that as the quick fix to get things working again or do you have some cases that would end up needing the inelegant exclude even if refactored to align with the change?
I believe this will make a few things also behave quite interestingly! Since the Model class for example also inherits the PVInstance class, any children within it when the pivot is changed automatically move with it.
Maybe this would allow for you to just parent a model (e.g a viewmodel) into the camera and it now automatically moves with the camera? No longer requiring you to manually pivot it to the camera every frame?
@tnavarts I’m curious if this is true? Is this behaviour from the PVInstance class or another one? Also, are there any plans on possibly allowing rendering layers so we could finally make viewmodels that don’t clip though the world and are properly affected by world lighting? ViewportFrames work, but these can’t accurately display the lighting of the world. Not to mention their antialiasing on the edges are quite jagged.
3 Likes
Why was “Highlight hierarchy under selection” removed? I prefer it off…
Found this out the hard way, but using the command bar to add a HapticEffect into workspace and saving the game and leaving will brick your game and prevent you from re-entering
1 Like
A fix could be downloading the place as an rbxlx file, searching for and removing any HapticEffect instances, saving, turning the file into rbxl, and publishing it.
1 Like
I believe it’s related to this:
1 Like