Add ability to browse / view instances that are parented to `nil`

Can we get some of the synapse people on this now that, well… they’re more available? :smiley:


Please add a feature. As a plugin developer it is essential to be able to properly locate nil instances especially when the PluginToolbar class is parented to nil and I need to reference it to be able to unify my plugins to use the same toolbar.

The below code is a really hacky way to get a unified plugin toolbar be creating a toolbar and then parenting it to something that isn’t nil.

local PluginGuiService = game:GetService("PluginGuiService")

-- Find the PluginToolbar class, or create it if it doesn't exist
local PluginToolbars: Folder = PluginGuiService:FindFirstChild("PluginToolbars")
if PluginToolbars == nil then
	PluginToolbars ="Folder")
	PluginToolbars.Archivable = false -- Don't want to save this to the place file
	PluginToolbars.Name = "PluginToolbars"
	PluginToolbars.Parent = PluginGuiService

local PluginToolbar: table = {}
local plugin = nil -- Unfortunately, even if this module is require()'d in a plugin context, this does not exist

-- Creates a new toolbar with the given name
local function CreateNewToolbar(name: string): PluginToolbar
	local toolbar: PluginToolbar = plugin:CreateToolbar(name)
	toolbar.Name = name
	toolbar.Parent = PluginToolbars
	return toolbar

-- Creates a new button on the given toolbar
function PluginToolbar:CreateToolbar(name: string): PluginToolbar
		typeof(name) == "string",
		"Incorrect parameter type for param 'name' (expected string, got " .. typeof(name) .. ")"
	assert(#name > 0, "Cannot have zero-length toolbar name.")
	return PluginToolbars:FindFirstChild(name) or CreateNewToolbar(name)

-- Sets the reference stored in the plugin variable.
-- Returns the table for chaining calls (e.g. you can call this in-line on the require function itself)
function PluginToolbar:SetPlugin(reference: Plugin): table
	plugin = reference
	return self

return PluginToolbar

All of get these two plugins using the same toolbar.


If there was something like game:GetNilInstances() it would be so much better.

local pluginToolbar = game:GetNilInstances():FindFirstChild("PluginToolbars")
    or plugin:CreateToolbar("PluginToolbars")

Now wouldn’t that be easy.

Or we could just not parent PluginToolbar to nil. I still want to be able to detect stuff in nil still though

1 Like

Would be nice if this was an engine-wide feature. Indexing the nil space. Then you could do something like nil:GetChildren() or

They would need to make nil an instance of itself to do that though, which would hinder performance.

1 Like

nil is a reserved keyword in Lua, as well as this, there be dragons with accessing destroyed instances that otherwise wouldn’t have any references.

getnilinstancenames, which just returns the names of objects, is likely more than enough to figure out if nil-space still contains my object.


Came on New Year’s Day to say this would incredibly helpful to find data leaks instead of just trial and error

1 Like

Funny how developers are starting to ask for exploit functions like getnilinstances. Aside from that, I believe this would be good for debugging.

there are so many core events parented as “nil” so it will lack security.

Why couldn’t they just not list anything thats from the core? I feel like a possible security issue is outweighed when compared to how this can help developers.

You’re already completely prevented from interacting with or modifying things used by Roblox’s corescripts or core gui. Not only would you not be able to do anything with them in the first place, I don’t think it’d exactly be hard for them to just exclude them from the list as Trio said

Upon reading the OP post again, I believe the root request is solved by the new Luau VM memory tools. (finding references to nil-parented objects)


Thank you @Mauio64 for the link.
That tool is made to solve this feature request as one its features.

Lost this topic over time, but we are working on a system to track feature requests better, similar to
improvements we made in the ‘Bug Reports’ category.


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