for an example if i do
local a = workspace.Baseplate
the game will store the date but where can i check all the data that is stored?
also if i do
wait(4)
local a = workspace.Baseplate
workspace.Baseplate:Destroy()
wait(1)
print(a)
it wont print nil so that means the data is still there i would like to know if there is a place i can see all the data store from all the scripts in the game
You would have to have the data as a variable before deletion to check it. There is no place to check “deleted” data from what i know.
Is there a place to check created data from script variables?
You can use the Watch window to see the variables accessed by the script when a breakpoint is reached.
Example:
-- Local Variables
local MyLocalVariable = 1 -- A local variable inside of this script.
-- Global Variables
MyGlobalVariable = "i liek roblok" -- A global variable inside of this script.
-- Modules
local MyLocalModule = require(script.ModuleScript) -- Will retrieve everything shared in the ModuleScript (Locally because we've put local on the beginning).
-- Global Table
_G.MyGlobalBoolValue = false -- Shared between all scripts of the SAME context level.
--Breakpoint--
Thats good but is there a way to do it without breakpoint?
what do you mean by “all the data store from all the scripts in the game”? do you want this to be part of another script during runtime, that can check what is and isn’t in memory? Or is this just for debugging purposes?
I want to know which variables are stored in my game. and how do i manage them, thanks
no, as in do you want to just view it yourself or are you looking for some kind of script behaviour? Studio’s IDE tools are the way to view it for debugging purposes, just like proturk_yt said.
i think the second option suits better
I’m afraid this isn’t possible, and it’s because how Luau as a language manages memory.
first of all, it’s very important to note that Luau is a memory safe language. This means it has its own garbage collector, which I will explain more about in a minute.
The Roblox engine is written in C++, and one of the reasons Luau is the scripting language is because it can be directly embedded and run from C++ code. Lua, the language Luau is derived from, also supports this. You can actually see this by running debug.info(_, "s") (where _ is a built-in function), to retrieve the function source. You’ll notice it returns [C].
There are two main memory structures: the stack and the heap.
The stack is a structure where local variables and function call data is stored. Imagine a stack of plates - one is added on top and one is removed. This is where temporary data is held, and it’s accessible from both C++ and Luau.
The heap is an unordered area of memory, and this is where the garbage collector acts. Data is stored here for long-term use; things like your baseplate you talked about before. The garbage collector detects when items in your script are no longer referenced and clears the memory associated with them. This prevents memory leaks and keeps unnecessary memory free for when it’s next needed.
Let’s take an example function of C++ to further explain this. Imagine you have this very basic function to multiply a number by 2.
int multiplyNumber(lua_State* L) { //L is a pointer to the lua stack manager
int num = lua_tointeger(L, -1); //this retrieves the top item from the stack and converts it to an integer
int result = num * 2; //this is the logic for multiplying by 2
lua_pushinteger(L, result); //this pushes the result back onto the stack
return 1; //telling lua how many values the function left on the stack
}
//would then go on to register this function to Lua
Your Lua code would then receive this integer and carry on like normal.
local val = multiplyNumber(3)
The same thing is happening to your baseplate, really. When you initialise the variable a, you are giving it a reference to the baseplate in the workspace. When you destroy the baseplate, it doesn’t get cleared from memory; all destroy does is set the parent to nil, lock the parent, and call destroy on all descendants. This means you can’t reference it again without the variable.
When your code finishes executing, the garbage collector notices a isn’t used anymore. Hence, it frees the memory location a was at. This is why when you output a after destroying it, it still prints the baseplate, because a isn’t out of scope yet, so it still exists in memory. After all code referencing the baseplate goes out of scope, then that too will be freed from memory.
I hope this clears things up, please ask if you have any questions, i appreciate this is quite a lengthy explanation.
Note: Although I said the C++ stack is accessible from both C++ and Luau, it can only be manipulated manually through C++. You can’t access it in Luau.
TL;DR: You can’t access the Luau stack or heap!
*note to anyone who is concerned about this: yes, you can actually access the Luau stack but with limited access - you can only read from it, and specific values at that. debug.info with the f option and a stack level (e.g. debug.info(2, "f") would return the function at stack level 2 should it exist.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.