Release Notes for 493

[LuaCow]

Notes for Release 493

[Maximum_ADHD]

Client Difference Log

0.493.0.4930373

API Changes

Added Property bool GuiService.TouchControlsEnabled
Added Property bool PathfindingModifier.PassThrough
Added Property bool PlayerEmulatorService.CustomPoliciesEnabled {RobloxScriptSecurity} [Hidden]
Added Property bool Studio.Set Pivot of Imported Parts
Added Property bool Studio.EnableOnTypeAutocomplete {RobloxScriptSecurity} [Hidden] [NotReplicated]

Added Function void AssetImportService:UploadCurrentMesh() {RobloxScriptSecurity}
Added Function void Plugin:SetReady() {RobloxScriptSecurity}
Added Function void Selection:ClearTerrainSelectionHack() {RobloxScriptSecurity}
Added Function void Selection:SetTerrainSelectionHack(Vector3 center, Vector3 size) {RobloxScriptSecurity}

Added Event Plugin.Ready() {RobloxScriptSecurity}

Added Tag [Deprecated] to Property UserInputService.ModalEnabled

Removed Function StudioService:BaseURLHasChineseHost

(Click here for a syntax highlighted version!)

[metatablecatmaid (metatablecat)]

Fiex the bug, probs want to “fiex” this typo lol.

[LuaCow]

Thanks for reporting the typo. I’ll have it fixed.

[colbert2677 (Dreamseeker)]

IIRC this was that one mobile property that a lot of developers really wanted to use but couldn’t use it adequately because it stopped working? Even the new PlayerModule didn’t reference it. Cool that we’ve finally got an alternative to use here.

[rogeriodec_games]

Need to appear on GuiService | Roblox Creator Documentation

[loueque (paperbagger)]

Logpoints will be an excellent feature to have for a programming environment, lessens the usage of print everywhere in the code, and a headache thankfully. Will the ability to hook up a logpoint to a warning or error message be available? A more variety is what I am asking.

[Hexcede]

This change is super underrated, and I’m all for it. It’s a lot like how class methods are defined in lua where you tend to define them outside of the construction, but this allows them to be defined inside the construction too, as long as no upvalues are used.

---

Unfortunately it has a relatively limited range of application, which I bet could be extended in theory (but its probably way more complex in practice)

As long as upvalues are a primitive constant (e.g. strings, numbers, and Vector3s as of recently) they should be safe since redefining the upvalue shouldn’t change the reference.

Things like tables, userdatas, and functions have unique references and unique data that can be modified, so they wouldn’t be applicable. With one exception for functions, which, has to do with the closures reuse in the first place.

---

Functions that reuse closures could actually be included in the list of safe upvalue constants as long as its not as a table key, a function argument, or have any operations applied to them (because metatables are functions too, and could use them as table keys, or rely on references).

That might mean you have two references to the same closure, but it wouldn’t matter because any code outside of that closure will be relative to the reference, and since the closure body is independent of the reference its still safe.

For example, this function would be safe:

local constantString = "abc" -- A primitive constant
local function safeClosure() -- Doesn't have unsafe upvalues, so it only gets created once
	return 123
end

local function safeClosureWithUpvalues() -- Has two upvalues, but they're both reference-safe
	return tostring(safeClosure()) .. constantString
end

But this one wouldn’t be even though it references a safe closure:

local function safeClosure() -- Doesn't have unsafe upvalues, so it only gets created once
	return 123
end

local function unsafeClosureCase(arg)
	return arg[safeClosure] -- Reference-dependent, this closure can't be safe anymore
end
local function unsafeClosureCase2(arg)
	return arg .. safeClosure
end
local function unsafeClosureCase3(arg)
	return arg(safeClosure)
end
local function unsafeClosureCase4()
	return tostring(safeClosure) -- Unsafe because tostring is reference dependent
end
local function safeClosureFromException()
	-- Could be hard to take into account but its technically possible that some global functions could be considered safe (obviously as long as fenvs aren't used)
	return coroutine.wrap(safeClosure)
end

[zeuxcg]

We have longer term plans to extend this optimization to more cases including the ones you mention. But we need to release this one first.