How to access a table from another script

Raytheonly7 · July 12, 2021, 3:02pm

I apologize if the formatting is weird since this is my first post, but please do point out what I should do differently next time.

I am trying to let a server script access a table inside of a module script in replicated storage, but it’s not working.

I only included the lines that are relevant, so if you are wondering how the id is sent to the server, well I just left the remote event part out since I have already tested that part and it works fine.

Replicated storage Module script:

local module = {}
module.Bullets = {}
local id = math.random(-100000,100000)
module.Bullets[id] = {
		serverResult = "tbd";
		clientResult = "placeholder";
}
---somewhere down here I fire the remote event to the server along with the id
return module

Serverscriptservice Script:

local module = require(*path_to_module*)

----this is all inside the OnServerEvent function of the same remote event
local bulletTable = module.Bullets[id]
print(bulletTable)  -------this prints nil

iBuzzes · July 12, 2021, 3:08pm

Please format the code. it will be easier to read.

sleitnick · July 12, 2021, 3:12pm

It looks like your code is probably fine. Most likely there is just a mismatch with your id or something. Otherwise, you have the right idea in terms of how to access the table given by a ModuleScript.

Raytheonly7 · July 12, 2021, 3:18pm

Ok so I just did:
Serverscriptservice Script:

local module = require(*path_to_module*)

----this is all inside the OnServerEvent function of the same remote event
local bulletTable = module.Bullets  *I removed the [id] part*
print(bulletTable)  -------this now prints {}

edit: I’m thus suspecting that it’s the way I inserted the values inside the table that is wrong. I’m going to try and see.

Raytheonly7 · July 12, 2021, 7:04pm

update: I don’t think that’s the problem afterall, I just tried printing the entire module.Bullets table inside the replicated storage module script and it works fine. I just can’t comprehend why the table’s content seems to be erased when it is referenced from the server script.

Raytheonly7 · July 12, 2021, 7:14pm

update2: Did some new testing, this time, instead of making module.Bullets = {} in the module script, i did module.Bullets = {“working”} and when i went to print the Bullets table in the server script, it returned the string “working” in the table. So I guess what happened before is: when i required the module script inside the server script, the module.Bullets table used to be empty, so even when i modified the table afterwards inside the replicated storage module script, the modification isn’t transfered to the Bullets table in the server script. Does this finally mean that: require() doesn’t reference or link to the module script, but rather creates a copy of it for the server script to use? Hmm doesn’t sound right though.

Redridge · July 12, 2021, 7:21pm

Most likely you are writing something wrong. Can you paste the module script again, in the state that it is now?

Raytheonly7 · July 12, 2021, 7:25pm

local module = {}

module.Bullets = {"working"}

local id = math.random(-100000,100000)
	module.Bullets[id] = {
		serverResult = "tbd";
		clientResult = "placeholder";
	}
-----I fire the remote event to the server along with the id

return module

Redridge · July 12, 2021, 7:27pm

It’s because you set the table to module.Bullets[id] and the id is random. I recommend setting the id to something just to test.

local module = {}

module.Bullets = {}

local id = math.random(-100000,100000)
module.Bullets[1] = {
		serverResult = "tbd";
		clientResult = "placeholder";
	}
-----I fire the remote event to the server along with the id

return module

and from the other script

local module = require(*path_to_module*)

----this is all inside the OnServerEvent function of the same remote event
local bulletTable = module.Bullets[1]
print(bulletTable)

EDIT: Is there a reason you want the id to be random? If you really need it to be random then you can try and iterate through the whole table with pairs

local module = require(*path_to_module*)

----this is all inside the OnServerEvent function of the same remote event
for id, bulletTable in pairs(module.Bullets) do
    print(id, bulletTable)
end

Raytheonly7 · July 12, 2021, 7:37pm

1.print(bulletTable) → nil

2.Basically, this id thing is unique for each bullet that is shot, the variables: serverResult and clientResult hold the objects that the bullet hit on the server and the client respectively. So math.random is here only to give a unique table to each bullet even though there’s an extremely small chance of 2 bullets having the same id. This can be optimized though.

Raytheonly7 · July 12, 2021, 7:42pm

At this point, I might just give these variables in the form of attributes to the bullets instead of saving them in a table, although I’m not sure if it’s better performance-wise.

Redridge · July 12, 2021, 7:54pm

Are you sure you are pasting the whole script then? These scripts are correct, it probably is something else in your code that messes with the tables.

Raytheonly7 · July 12, 2021, 7:57pm

Yea most that’s most likely the case, i will give you a more complete script in a second

Soybeen · July 12, 2021, 8:03pm

You’re bound to get many duplicates if the range is as small as 200,000.

I use HttpService:GenerateGUID() for creating unique bullet IDs

If you want to keep the table of bullets inaccessible to the client/server, but manipulate them through functions of the ModuleScript, you would structure the ModuleScript in this way:

local bullets = {}

local module;module = {

MakeBullet = function()
    local newBullet = {}
    bullets[#bullets+1] = newBullet
end 
}

return module

– requiring script

local bulletModule = require(yourModule)
bulletModule.MakeBullet()

The functions of the module should be responsible for editing the bullet table, and scripts that require the bullet module should be calling those functions to make changes instead of by directly manipulating the bullet table (that’s one of the main reasons people stray away from using _G.)

Raytheonly7 · July 12, 2021, 8:25pm

Woah Soybeen !!

Is it a typo in the second line or is it just some weird syntax I don’t know about?
I don’t really understand what putting the bullets table outside the module does differently compared to putting it inside.
@Redridge I’m not forgetting about you

Raytheonly7 · July 13, 2021, 1:50pm

Hello everyone, I finally managed to make it work, i will mark @Soybeen 's reply as the solution since it helped me the most. However i really appreciate all of you helping and sorry @Redridge , i never sent you the script did I?

Soybeen · July 13, 2021, 10:42pm

1: I do that to silence the warning you’d get if you self-reference a variable that hasn’t been declared, the semicolon acts as a line break.

local module;module = {}

…is functionally equivalent to:

local module
module = {}

Otherwise you’d get this warning:

2: The reason we put the bullet table on the outside of the returned module (but still within the module script) is just to reinforce the idea that outside scripts should not be editing/referencing the table directly, but rather, they should manipulate the table through the functions of the module. Functionally there is not much difference - two local scripts that require this module would see the same bullet table because table IDs are unique, the ModuleScript will return the same reference to the same table every time it is required, (if that behavior was not desired you would explicitly generate and return a new table within a function of the ModuleScript).

What you were doing in the OP wasn’t incorrect, this was just a structural suggestion that makes ModuleScripts more autonomous.