Client Difference Log
API Changes
Added Class UnvalidatedAssetService : Instance [NotCreatable] [Service]
Added Function void UnvalidatedAssetService:AppendTempAsset(int64 id, Vector3 lookAt, Vector3 camPos, string usage) {RobloxScriptSecurity}
Added Function bool UnvalidatedAssetService:AppendVantagePoint(int64 id, Vector3 lookAt, Vector3 camPos) {RobloxScriptSecurity}
Added Function bool UnvalidatedAssetService:RenameTempAsset(int64 tempId, int64 assetId) {RobloxScriptSecurity}
Added Property bool GuiService.RenderHumanoidBillboards {RobloxScriptSecurity} [Hidden] [NotReplicated]
Added Property bool PhysicsSettings.ForceCSGv2 [Hidden] [NotReplicated]
Added Property bool Studio.Enable Http Sandboxing
Added Property bool Studio.Enable Internal Beta Features
Added Function void StudioService:DEPRECATED_ShowPlaceVersionHistoryDialog() {RobloxScriptSecurity}
Added Event BulkImportService.AssetImported(Enum<AssetType> assetType, string name, int id) {RobloxScriptSecurity}
Changed the parameters of Function StudioService:ShowPlaceVersionHistoryDialog
from: ()
to: (int64 placeId)
(Click here for a syntax highlighted version!)
When an up parameter isn’t provided, will the new function identically to the deprecated constructor? There was a replacement on the DevHub that used fromMatrix and didn’t work the same in many (edit: one or two) cases, if I remember right.
(Considering the new function’s syntax is much more similar to the original, though, it could also make sense for it to be the same.)
No it will not. It will actually work better!
It works almost the same, but when the Look direction was within about 7.5 degrees of +Y the old function would choose a different up direction. The new function will still respect the up direction until the up and look directions are within about 0.001 degrees.
I eagerly await the kind soul that will create an awesome GIF that explains what that argument does to troglodytes such as myself.
Easy way to describe it, it’s the direction opposite of gravity:
CFrame.lookAt(whereIAm, whatIWantToLookAt, -whatDirectionGravityPointsIn)
Up defaults to +Y because gravity is usually downwards.
If you were making a game in space where there’s no single frame of reference for what way “up” is, then you would want to use a non-default value for instance.
Anyone know the correct syntax for this? I’ve tried a bunch of variations with no luck so far. I’m on the latest Studio version. Here are the ones that don’t work:
<font font-face="SciFi">Test</font>
<font fontface="SciFi">Test</font>
<font face="SciFi">Test</font>
<font font="SciFi">Test</font>
Edit: Fixed
Edit2: Broken again for some reason…
Edit3: Fixed again!
The changes to the camera seem to have heavily decreased the Left and Right Arrow key camera rotation speeds. It’s a lot more tedious playing with arrow keys or using arrow keys as camera controls, as it’s near impossible to quickly turn while using them.
This is a big problem with players who use arrow keys as their primary controls or camera controls, which is also what I use whenever I play Roblox on a laptop with a touchpad.
Is there any chance the speeds will be changed in a future update?
This appears to be the correct one. This only works at the moment when the EnableFontFaceParsing FFlag is enabled, and it’s currently disabled.
For instance <font face="SciFi">a</font><font face="Legacy">b</font><font face="SourceSans">c</font><font face="Fantasy">d</font><font face="Gotham">e</font> becomes
I assume this means the CFrame lookAt constructor is officially no longer deprecated as it was previously documented as.
This is great since it was very widely used and I much need it as well.
So, here’s what happened:
- We were planning on adding
CFrame::lookAtand deprecatingCFrame.new(look, at). - Issues were found with the
CFrame::lookAtproposal, so it got delayed. - The documentation update deprecating
CFrame.new(look, at)still went out. -
CFrame::lookAtended up sitting on the back burner. But now it will be arriving soon! -
CFrame.new(look, at)will be deprecated again onceCFrame::lookAtis turned on. You should be using the new lookAt variant because it has better precision as mentioned above.
TL;DR: CFrame::lookAt was intended to arrive as a replacement right after that deprecation, but it ended up taking much longer than intended hence the awkward period where it was marked deprecated but without a nice replacement.
This new lookAt API works wonders for the camera system in my puzzle game! Saves me a lot of headache, this does.
Yes, that’s exactly what I set out to avoid when I was implementing the new variant, nice video.
You’ll have to wait a couple weeks still for a mobile force update before I can turn it on but it will indeed solve that problem when you move over to it.
Couldn’t help but notice these aren’t RobloxScriptSecurity?
If I had to guess, there’s probably an FFlag behind them for now at least, but, this seems a little strange.
Ooh!
What is the syntax for this? Sounds like (based on above) its
<font face="NameOfFont"></font>. Additionally, does this support built in font faces beyond the Enum? I can’t think of any examples of these, but, I believe they do exist, from the looks of it this only supports the Enum based fonts since those are the names used.
Also, sorry if this is super obvious, beyond <b></b> tags, do we currently have color support? For example, <font face="SciFi" color="#ffffff">Abc123</font>. I’m sure this is a planned feature if not, I’m trying to keep myself up to date on RichText at this point. (Also, as soon as we get color support its syntax highlighter time for me)
I am extremely hyped about this. Given what @tnavarts has mentioned above, sounds like I’m refactoring with this asap. (I am an ENORMOUS fan of the up vector addition)
Thanks for the simple and straight-forward answer. Now I know exactly how to use it and I’m already looking forward!
Yes, I’ve tested color support personally and it’s definitely working, and the syntax (for face and color) is correct.
Will this new constructor allow the default game and studio camera to look nearly straight up/down in the future?
I too am curious on this as I ended up having to botch some weird camera+position offset code together in my 2D engine thingy.
I wasn’t sure what the issue was, but, it caused the camera to be rotated 90 degrees and sometimes flip around since the camera pointed straight down.
My solution was to rotate the “game window” so it would appear proper and keep the camera perfectly static.
We’re not going to modify the camera right now, as we have tentative plans to completely rebuild the studio camera in the medium term (some time next year).