Release Notes for 431

Updates Release Notes
#1

Notes for Release 431

30 Likes
#2

Client Difference Log

API Changes

Added Property Enum<AutoIndentRule> Studio.Auto Indent Rule
Added Property Instance StudioService.HoverInstance {RobloxScriptSecurity} [<📁> LoadOnly] [NotReplicated]
Added Property Vector2 VideoFrame.Resolution  [ReadOnly] [NotReplicated]

Added Function bool DataModel:GetEngineFeature(string name) {LocalUserSecurity}

Added Enum AutoIndentRule
	Added EnumItem AutoIndentRule.Off : 0
	Added EnumItem AutoIndentRule.Absolute : 1
	Added EnumItem AutoIndentRule.Relative : 2

(Click here for a syntax highlighted version!)

19 Likes
#3

Yea boi we finally got it!

image
image811×200 14.7 KB

Now I’m only waiting for the announcement post and for its functionality to be enabled. Man, the team behind this is awesome!

26 Likes
#4

It’s enabled right now!

If you want to find out first, do a quick refresh of https://fflag.eryn.io/ every once in a while and you might see a new change before everyone else :eyes:

16 Likes
#5

I like how Roblox added Depth of Field, as it’s been such a long awaited feature. However, I honestly believe it isn’t ready yet.

Although it has some properties we can tweak to our liking, it is still missing some things, such as how strong the blur is / the size of the blur (similarly to BlurEffect) and InFocusRadius / InFocusDistance don’t really reflect the distance as expected (or atleast, I was expecting them to work in studs). Instead, what we get right now, seems to start only after a certain threshold and does not really reflect the property change well.

Don’t get me wrong, I like it. I just think that it needs a little bit of improvement until I can start using it in my games.
Right now it just doesn’t look right no matter how I adjust it.

7 Likes
#6

OMG, you’re right! I didn’t realize at first since I had my graphics settings down to match my poopy computer. But this is seriously amazing!

image
image1228×726 664 KB

image
image1236×769 526 KB

It’s just a little sad that it requires higher end PCs (which I can understand). But man it’s still amazing!

8 Likes
#7

Been waiting for DOF for a while now

10 Likes
#8

Feedback on the new Animation Uploader/Importer.
I would like to mouse over the icons to see the full name, or make it where it always shows the full name of the animation because I am unable to differentiate between these two animations.
image

6 Likes
#9

Here’s a video demo I did for the DepthOfFieldEffect class about a month ago if anyone is interested lol:

14 Likes
#10

Are those material footstep sounds an upcoming feature from Roblox, or is that something you just made for the demo? Curious about the realistic first person cam as well.

2 Likes
#11

To be quite honest, you can do that right now currently with the current studio - you just need the sweet SFX that hes got.

#12

I’m aware that you can do this already - I was just curious if it’s an upcoming behavior of the corescripts or if it was something he implemented for the demo video.

1 Like
#13

Nah, its part of my (yet unreleased) character realism system. I shoehorned it into the demo because I didn’t like Roblox’s default character behavior lol.

You’ll see it in one of my upcoming projects though :slight_smile:
It’s already present in Welcome to Roblox Building:

https://www.roblox.com/games/2897155393/Welcome-to-Roblox-Building-Beta

7 Likes
#14

image
image1016×125 7.08 KB

:eyes:
This means we’ll have… import type as well, right? :pray: That’s all I’ve been asking for

8 Likes
#15

Is Luau just going to become TypeScript at this point? Exporting types is a very TypeScripty thing.

3 Likes
#16

So we had some internal feedback that automatically exporting all types declared in the module is harmful, which is why we’re going to transition to explicitly exporting types that are part of the public type interface. This change isn’t enabled yet.

For importing though, we’re going to continue to use namespaced type aliases for now (e.g. local foo = require(bar) brings exported types into foo namespace).

6 Likes
#17

My major concern is the fact that it’s still difficult to import a type namespace from a module without requiring it, which is very important for avoiding circular require deadlocks at runtime. Right now the only way to do that is with a rather confusing and limited type MyImportedModule = typeof(require(...)) statement. For what I want to do with the type system, it’s essential to be able to have some way of reading a module’s exported types statically, without actually requiring that module at runtime.

I suppose a possible workaround here is to lazy-load the modules when you need their types, but it feels like this is a major problem with importing type namespaces with require; you’re enforcing runtime effects for a feature that shouldn’t affect runtime code. Importing modules at runtime has side effects like the require deadlock, and whatever else the required module is doing. Why should I use a require statement at runtime when all I need is static type information?

I know you’ve got a lot on your hands with typed lua, as it’s such a big project, but I hope you consider adding a syntax for type imports that don’t affect runtime code; it’s a small feature that goes a long way for me.

3 Likes
#18

It’s probably not the most intuitive way to import it, but can you explain the limitations?

#19

Well, the biggest thing is that you don’t actually get the module’s type namespace; you only get the single type of the value you’re trying to import. This often means you have to use some hacks to get the type you actually want to import, and it’s hard to get a well-defined, manually-specified type from another module.

A good example is with classes. Often times the type you want from a class module is the object type, even those these modules return the class value. So with the typeof(require()) syntax, you have two options, which aren’t particularly great:

  1. Use type ObjectType = typeof(require(...).new()). This works, but it still isn’t very great. It’s also really easy to confuse the class type and object type if this is the only available option for other people using your code to import the object type.
    or
  2. Conflate the “Class type” and “Object type”. This is very hacky, but magnalite showed an example of it in this thread: https://devforum.roblox.com/t/the-future-of-oop-in-light-of-typed-luau/554988/10?u=databrain

It would be much nicer if instead you could do export type MyClass = {...} for the object type, and a statement along the lines of import type MyClass from path.to.MyClass or importtypes(path.to.MyClass) to avoid this altogether.

1 Like
#20

Ah, right, I get it… so you really need to do something like this which is not great either

local ModuleType
if false then
    ModuleType = require(path)
end

(assuming this works, which I am not sure about)