Methods to wait for CoreScript registry

Anaminus · May 12, 2017, 2:09pm

CoreScripts aren’t guaranteed to be setup and running before normal scripts run. This can lead to core functions being called before they are registered, causing errors and requiring sloppy workarounds.

Solution A:

Function: StarterGui:WaitForRegisterGetCore(string parameterName, double timeOut)
Function: StarterGui:WaitForRegisterSetCore(string parameterName, double timeOut)

Works like WaitForChild. Waits until a core function has been registered. Has optional timeout argument.

More convenient for CoreScript engineers; no changes to CoreScripts are required.
Less convenient for developers; each core function must be checked.

Solution B:

Function: StarterGui:FinishCoreRegistry()
Function: StarterGui.IsCoreRegistryFinished()
Event:    StarterGui.CoreRegistryFinished()

The event is fired after registry is finished. Core functions cannot be called until registry is finished. New core functions cannot be registered afterwards.

Less convenient for CoreScript engineers; CoreScripts must be reworked to make sure all core functions are properly registered before finishing.
More convenient for developers; they only have to check one value.
Access to all core functions depends on the core function slowest to register.

Solution C:

Function: StarterGui:PreregisterGetCores(Array parameterNames)
Function: StarterGui:PreregisterSetCores(Array parameterNames)

Preregisters a list of names that will eventually be registered. Calling GetCore or SetCore on a preregistered but unregistered name waits until the core function has been registered before resuming normally.

Less convenient for CoreScript engineers; must keep track of core functions in multiple locations.
More convenient for developers; no changes are required.
Core functions must be preregistered in a CoreScript that is absolutely guaranteed to run before any other script.

TheGamer101 · May 12, 2017, 8:50pm

Currently we try to make all SetCore and GetCore methods work without requiring the developer to wait a frame before calling it. This requires making sure that SetCore/GetCore methods are registered in the CoreScripts on the first frame, before userscripts run. I don’t know if there are any Set/GetCore methods which requiring yielding currently but if there are let me know and I will fix them.

The problem is that we end up accidentally adding yields before where SetCore methods are registered without realising it. I think ideally we would solve this problem in some way that did not require developers to know that SetCore methods can’t be relied on to be available on the first few frames. One such solution is that we could add some form of automated testing to make sure that we don’t accidentally add yields to before where SetCore methods are registered in the future.

EchoReaper · May 12, 2017, 9:16pm

Anaminus · May 12, 2017, 11:16pm

Relying on frames for synchronization is the worst practice. Unless CoreScripts have an explicit “I’m ready” condition, which must be satisfied in order for other scripts to start running, CoreScripts must be considered as running concurrently with other scripts. Which means, as long as core function registration has no means of synchronizing with other scripts, the feature cannot be used reliably.

Usering · September 8, 2020, 7:29pm

As a developer, it is currently impossible to work with SetCore when your game is loading. You never know when the parameters are going to be set up, and they just leave an error. This causes developers to have to work around the issue by repeatedly setting the values until Roblox finally allows it. Ideally, these errors should never happen for valid SetCore parameters (such as TopbarEnabled, ResetBindableCallback, etc).

This is an issue that has been around for years, when I was writing this post, this is the list of suggested topics Discourse gave to me.