Board:GetBoards() is returning nil, and I’m not sure why! Boards should be full, based on the print in my Board.New function, my local script calls Board:GetBoards() in a loop every 30 or so seconds, so it should be returning a full table at least once!
I do call Board.New() on a module, required by the server.
local Board = {
Boards = {},
Queue = {}
}
Board.__index = Board
function Board.New(Object: Instance)
local Data = {
Interface = nil
}
Data.Interface = Templates.Board:Clone()
Data.Interface.Parent = Object
Board.Boards[Object] = Data
print(Board.Boards) -->
-- {
-- Instance = {
-- Interface = Board
-- }
-- }
end
function Board:GetBoards()
print(Board.Boards) --> nil
return Board.Boards
end
My local script that makes use of the function is shown below!
local Run = function()
warn('[🚀] Started client loop!')
local Boards = Board:GetBoards()
print(Boards) -- {}
for _, Object in pairs(Boards) do
print(Object)
for _, Data in pairs(Board:GetQueue()) do
warn(Data)
end
end
end
Run()
while true do task.wait(Shared.Wait.Value or 30)
Run()
end
Ok so, if you require a module on the server, and then require that same module on a client, they are basically separate instances and scripts. The server cannot reach the variables on the client, and the client cannot access the variables on the server.
So naturally, you will not be able to see the created boards on the client, unless you have it check on the server by remotefunction or something. Client and server are completely separate execution environments, in different physical locations.
keep all board instances on the server, send messages to the clients to do things
keep all board instances on the client, send messages from the server to manage them
do both, have both a server instance and a connected local instance
In general, it’s important to organise the communication between client and server. Certain tasks should go to either side, for example animations should be local on the client while security should be server side (keeping scores, etc).
Personally, I mostly use remote events to send instructions from server to client, and player choices back to the server. Note that you can send copies of tables by remoteevent, but not custom-made objects - they will lose their identity and any unreplicated references.
Remember that clients may log in after the game started, so the server has to track everything. You will just need to decide where in the process you let something be done by the clients, and then program any necessary communication between client and server.