Release Notes for 407

Notes for Release 407

23 Likes

Client Difference Log

API Changes

Added Property float Lighting.EnvironmentDiffuseScale
Added Property float Lighting.EnvironmentSpecularScale

Added Function void ABTestService:ClearUserVariations()

Added EnumItem StudioDataModelType.None : 6

Changed the security of Class DataModelSession 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Changed the security of Class MDIInstance 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Changed the security of Property Plugin.HostDataModelType 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Changed the security of Property Plugin.HostDataModelTypeIsCurrent 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Changed the security of Property Plugin.MDIInstance 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Changed the security of Function Plugin:Bind 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Changed the security of Function Plugin:BindAndFire 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Changed the security of Function Plugin:Fire 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Changed the security of Function Plugin:GetItem 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Changed the security of Function Plugin:HasItem 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Changed the security of Function Plugin:RemoveItem 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Changed the security of Function Plugin:SetItem 
	from: {PluginSecurity}
	  to: {RobloxScriptSecurity}

Removed Property DebugSettings.ErrorReporting
Removed Property DebugSettings.GfxCard
Removed Property DebugSettings.OsIs64Bit
Removed Property DebugSettings.OsPlatform
Removed Property DebugSettings.OsPlatformId
Removed Property DebugSettings.OsVer
Removed Property DebugSettings.RobloxProductName
Removed Property DebugSettings.SIMD
Removed Property DebugSettings.SystemProductName
Removed Property DebugSettings.VideoMemory
Removed Property NotificationService.IsLuaBottomBarEnabled
Removed Property NotificationService.IsLuaBottomBarWithText

Removed Function ABTestService:clearUserVariations

Removed Enum ErrorReporting
	Removed EnumItem ErrorReporting.DontReport
	Removed EnumItem ErrorReporting.Prompt
	Removed EnumItem ErrorReporting.Report

Removed Enum JointType
	Removed EnumItem JointType.Weld
	Removed EnumItem JointType.Snap
	Removed EnumItem JointType.Rotate
	Removed EnumItem JointType.RotateP
	Removed EnumItem JointType.RotateV
	Removed EnumItem JointType.Glue
	Removed EnumItem JointType.None

Removed EnumItem StudioDataModelType.Null

(Click here for a syntax highlighted version!)

12 Likes

I feel like table.create is going to be underrated, but that update looks amazing. I assume that the memory allocation is done on the backend instead of whenever you create a table? To get around this, I currently construct tables with placeholder values or initialise members with placeholders.

-- Construction with a size of 8
local array = {1, 1, 1, 1, 1, 1, 1, 1}

-- Construction with members
local dictionary = {
    Test = 1,
    Other = 1,
}

Does table.create work in around the same manner as the first sample? That is, constructing a table with a size of n and any elements above n cause the table to resize and reallocate. It’s not quite clear if this creates a fixed-size table or if standard resizing behaviour is implied.

As for table.find, I like this. It prevents me from always having to write a custom iterator or extended table library in pure-Lua (iirc backend calls are faster) as shown:

local function findIndexForValue(targetTable, targetValue)
    for index, value in ipairs(findTable) do
        if value == targetValue then
            return index
        end
    end
    return nil
end

There’s still going to be cases where that’s necessary, such as working with dictionaries, but at least the work is saved when working with arrays.

Will this stop the menace of scopes being opened in comments? I’d actually like to use brackets, quotes and the word function, for example, in my comments again. :pensive:

image

6 Likes

table.create will immediately create the table at the exact specified size - this is the same as array construction from literals as you mentioned. This allows you to create tables at the exact desired size and capacity quickly, which you can’t get by inserting elements into the table one at a time.

table.find is mostly a convenience method. It ended up being ~2x faster than a ipairs-based loop - which was a really pleasant surprise wrt new VM performance.

And yeah we discussed the dictionary use case re: find but felt that it’s most appropriate to only work with arrays for now - all methods in table library assume arrays. If we ever add an equivalent for dictionaries (not sure we will), we’ll highlight the fact that it works for non-numeric indices somehow.

19 Likes

I feel personally attacked by table.create o.o

I’ve historically always had an Arrays library to do it for me:

...
--[[
	Returns a zero-initialised array of the specified dimensions.
--]]
function Arrays.new(length, secondArg, ...)
	if secondArg == nil then
		local arr = {}
		for i=1, length do
			arr[i] = 0
		end
		return arr
		
	else
		local arr = {}
		for i=1, length do
			arr[i] = Arrays.new(secondArg, ...)
		end
		return arr
		
	end
end
...

Used like this:

local myArray = Arrays.new(1, 2, 3) --creates a 3D array of size 1, 2, 3

A shame that table.create doesn’t support multiple dimensions like this, so I’ll be sticking to Arrays for now, but I’m definitely reimplementing part of the function using this!

1 Like

Wouldn’t something like this work?

local myArray = table.create(1, table.create(2, table.create(3, value)))
6 Likes

Wow that’s ugly. Also very smart. I love it.

Does that actually work? (that is, does table.create support tables as initial values, or would it all point to the same table in memory?)

1 Like

I don’t know, looks like we’ll have to wait for the feature to be ready to see.

3 Likes

Wouldn’t your method be more expensive than table.create, let alone just creating a table with a hard-coded amount of placeholder elements? I mean, your new method creates a table with a size of 0 and then forces reallocation n times with the length parameter.

1 Like

It would point to the same table. You would still need your function but you can:

  1. create innermost tables with table.create(size, 0) immediately
  2. create outer tables with table.create(size) instead of {} before filling it.

2 seems pointless - why create a table and fill it with nil? - but it’s actually important. Normally tables start with internal capacity of 0 and every time you insert a value that results in length > capacity, the table is reallocated to a larger capacity. So the cost of filling the table one element at a time is O(NlogN). Pre-allocating the table with table.create makes sure that the loop never needs to reallocate it.

8 Likes

That’s not my new method, it’s my existing method I’ve used in production for a long time. I plan to add table.create into it to make it a bit faster as zeux outlined above :slightly_smiling_face:

SPOILER ALERT

Roblox is about to receive physically based rendering :smiley:!
[Roblox] Physically Based Rendering - YouTube

35 Likes

When can we expect table.find and table.create to be enabled?

image

I want to use it for my game’s update and would like to release it asap

1 Like

Are we going to get autocomplete information for table.create/table.find right off the bat, or will we have to wait for it similar to things like table.pack?

2 Likes

Due to the nature of mobile upgrades, new APIs usually take several weeks to become available, since we only enable features once they are available on all platforms for all players.

I guess we just need to wait and see.

7 Likes

These new API’s are very exciting!

Is table.find’s equality test equivalent to rawequal? If not can it optimize for when the input value has no __eq metamethod?

Are there any plans to look into table.findLast, or additional upper-bound and step parameters that enable searching through a range?

In most of my use-cases involving table.find, the top/end of the array is the most volatile and likely to change. Searching backwards would find the result in significantly fewer iterations in these cases, plus it’s faster to table.remove items from the end of an array. My hope is that table.find is so blazing fast that it doesn’t matter if the value it’s looking for is likely near the end of a long array.

2 Likes

No plans for extensions atm. find supports __eq - it has to to be able to find many Roblox primitive types.

4 Likes

I should have mentioned that if you have a large table and you’re pretty sure the element is near the end, it’s likely that manually trying to find it is going to be faster - but that’s a very special use case so it’s not clear yet if we want to support it in a first-class manner. The benefit of table.find is that it’s simple, ergonomic, and reasonably fast for the case where you don’t really know where the element is.

6 Likes

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.