So I’m requiring modules by their packaged AssetID’s
local moduleExample = require(12345678) -- like this
And I’m unsure where they exist and I can’t think of a good way to test my theories. If you could please help me understand my uncertainties that would be great. Also if you have any documentation links that would also be great.
Here is my main uncertainties when requiring a module by assetID:
does the module exist only on the server?
if required by local script does a separate instance of the module exist on the client?
can I change the directory of the module?
My Goal:
I want a system where modules are required by assetID so I don’t have to constantly worry about updating the path on several workspace scripts. Also I want games to have access to the latest updates of the modules, in case if something is not working properly, or new features are released. However on current implementations of this strategy I’ve noticed that some things are not working the way I intended, and not sure if this is because client is accessing a different instance of the modules.
Requiring by AssetId is the same as requiring a ModuleScript instance except it comes from the site and not the DataModel. When you require, you’re returned with the results, not the instance. Therefore:
As require by id can only be done by the server and it’s the server that performs the action, the module is only available server-side
A LocalScript cannot require by id and cannot get anything from the ModuleScript either because it’s not replicated to them.
You cannot change the directory of the ModuleScript because you don’t get one back in the first place. The only thing that exists is the return value which is cached in an inaccessible location.
I don’t like requiring by id, I found the practice to be unnecessary in more cases than one.
As for your use case for all this, this is exactly what packages were created for. A few other details are just implementation-specific that you can figure out by spending time on resolving the problem.
Don’t want to update the path? Make your paths consistent across games. A loader of some kind can bridge the work while a framework can enforce a path for everything.
Packages are cross-place AND cross-game. Every place that uses your package will be consistent and use the same assets. You can mass update the package so all places have their copy updated.
I found that this case is pretty useful for requiring by asset ID. This was my inspiration, but since most likely I’m the only one accessing the modules then it’s probably not that big of a deal.
Thanks for the information. I’m fairly new to packages. Currently I’ve been packaging the MainModule then requiring it by the AssetID of the package. Maybe this strategy is a little wacky.
Another primary reason for doing it this way is for security but maybe it wont work how I think it will. Say I was collaborating with other coders in a place is it possible for someone to obtain the contents of a module if it was required by AssetID? I can imagine if I just had packages in ServerScripts then the contents would by easily accessible.
Yeah, that’s not how you use packages. If you’ve packaged the module, leave it in the DataModel someplace that you know is constant amongst your games. Thus, once you update the package, all you need to do is mass push the updates and the rest of your games get the new copy.
If you’re collaborating with others and they have Studio access, all they need to do is open your script to view its contents. This isn’t a case of security, it’s just a case of collaborator access to code. In that case, don’t give people Studio access: think of a different method for collaboration.
As far as actual security concerns go, if you keep it in a server-only container, it’ll remain server-only. If you don’t want clients accessing it or you have different plans, set up an endpoints folder full of remotes that the client can use to communicate with the server (module).