Module Script returns a table with parts on module perspective, empty table on client perspective

Help and Feedback Scripting Support
1

On the server/module perspective, the table is:
{Ball1, Ball2} - parts

On the client/local perspective, the table is:
{} - empty table

I want the client/local perspective to be the same as server/module perspective, but I’ve tried everything I’ve found online and have yet to found an answer. Any help will be appreciated, thanks!

(forgot to say, this is for an index to see what has been discovered)

ModuleScript:

local module = {
	indexList = {}
}
return module

LocalScript:

local rs = game:GetService("ReplicatedStorage")
local currentIndex = {}

while task.wait() do
	local newIndex = require(rs.Index).indexList
	print(newIndex)
	for _, indexBall in pairs(newIndex) do
		if not currentIndex:FindFirstChild(indexBall) then
			print("hi")
			currentIndex[#currentIndex+1] = indexBall
		end
	end
end

setmetatable(currentIndex, {
	__newindex = function(_, _, ball)
		local template = script.Ball:Clone()
		template.Name = ball.Name
		local match = tostring(string.match(ball.Name, "%d"))
		local split = tostring(string.split(ball.Name, match))
		split[2] = " "..split[2]
		template.BallName.Text = split
		local newBall = ball:Clone()
		newBall.Position = Vector3.new(0, 0, 0)
		newBall.Orientation = Vector3.new(40, 180, 0)
		newBall.Parent = template.Image
		template.Parent = script.Parent
	end
})
2

It would not replicate to the client as requiring from the server and client is not the same, you could fire a remotefunction to read that data instead

game.ReplicatedStorage.RemoteFunction.OnServerInvoke = function(Player) 
     return require(Module)
end
3

Nope, didn’t work. Still returns “{}”

Though, I did discover that printing “h” before invoking prints it to both the dev console and output, rather printing the return value of invoking prints “{}” to only the output.

4

return the indexList in the module not the require() itself

5

Still didn’t work, but I also just discovered that printing the table in the module its self returns “{}” aswell.

6

On the server??? Some char stuff i n eed

7

If the server is adding the items to the module then it won’t replicate when the client goes to load the module.

The client and server both have their own environment for the module.

8

Yeah, thats what I’m doing. So how do I solve this exactly?

9

I’m a little confused by what this is for honestly.

I guess you could define like an initializer function you can call both locally and server-sided to add the items to the table or something.

10

Basically, its an index for showing what balls you’ve discovered inside the game, and once theres a new one, it adds the part its self to the index list and its supposed to copy a frame with a viewportframe into an index frame in the index gui, but instead thats not happening for right now until I find a solution.

Its based off of this game: Merge Fanmade - Roblox (I’m trying to make an index similar to the one in this game)

11

Also what do you mean by initializer function? Could you clear it up a little?

12

A function you could call to handle loading the instances into the table, before you use the module.

I might also advise to try using abstract data instead of instances, then it would be easier for you to transmit this over to the client for processing. What I mean by that is using like strings or bools to represent what balls the user has.

example:

local module = {ownedBalls = {}}

ownedBalls.ball1 = true --//ball1 is owned
13

I need the part and not a bool so I can import it into the viewportframe, and do some other things

14

I solved the issue by using a regular folder in replicatedstorage rather than a modulescript.

15

ModuleScripts return a unique table value for each context layer they are required in (client and server), in order to force this table to store the same items/entries you need to make the same modifications to it from both the server and the client.

16

Yeah, but a module script with only instances inside it is the same as a regular folder.
The folder is easier in my opinion because both sides have almost the same environment (unless something is created locally.)