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!)
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. 
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.
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!
Wouldn’t something like this work?
local myArray = table.create(1, table.create(2, table.create(3, value)))
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?)
I don’t know, looks like we’ll have to wait for the feature to be ready to see.
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.
It would point to the same table. You would still need your function but you can:
- create innermost tables with
table.create(size, 0)immediately - 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.
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 
SPOILER ALERT
Roblox is about to receive physically based rendering 
!
[Roblox] Physically Based Rendering - YouTube
When can we expect table.find and table.create to be enabled?
I want to use it for my game’s update and would like to release it asap
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?
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.
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.
No plans for extensions atm. find supports __eq - it has to to be able to find many Roblox primitive types.
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.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.