My goal is to access the MasterControl module from the player scripts so that I can get the MoveVector of the player while in parallel Luau.
Loading the MovementControl module in a script under an actor results in the following error: Attempt to load a function from a different Lua VM
This is the code I am currently using to access the MasterControl module:
...
local player = -- Local Player
local playerScripts: PlayerScripts = player:WaitForChild("PlayerScripts")
local PlayerModule = require(playerScripts:WaitForChild("PlayerModule"))
local MasterControl = PlayerModule:GetControls()
...
... MasterControl:GetMoveVector() -- this is the method I use to access the move vector
...
Because my local script is under an actor, I receive the aforementioned error when attempting to require the PlayerModule. Any ideas on how I can access the MasterControl module or at least some other method to get the MoveVector regardless of user device?
Though not the ideal solution, I found a hacky workaround. I have a separate script on a core thread that continuously sets an attribute on the actor so that the actor can access the move vector via the attribute:
Script that distributes the MoveVector:
...
local PlayerModule = require(playerModuleScript)
local MasterControl = PlayerModule:GetControls()
local moveVector = MasterControl:GetMoveVector()
while true do
local updatedMoveVector: Vector3 = MasterControl:GetMoveVector()
if moveVector ~= updatedMoveVector then
frontendScooterMechanicsManagerActor:SetAttribute("moveVector", updatedMoveVector)
end
task.wait()
end
Script that needs to access MoveVector:
... script.Parent:GetAttribute("moveVector") -- access moveVector via attribute
Although this solves my personal issue of needing to access the MoveVector, it does not solve the posted issue of accessing the MasterController from parallel Luau, so I will not mark this is a solution.
for your case, you may benefit from using SharedTable(s). These allow you to read and write to a shared table across multiple actors, but have limits to their key/value pairs. in your case, it seems like it will be the perfect fit as you are only storing serialized data types (numbers, strings, vectors, booleans, etc). To use this, you will want to change your master control to provide a shared table to the actor script before the actor script desyncronizes. while desyncronized, the actor script can freely edit and read that table without having to call the module again. this table can also be shared to multiple actor scripts to allow dynamic reading across multiple scripts.
Thanks for your response! The SharedTable you mentioned sounds like a great option. However, the MasterControl module script is a default Roblox module script which handles the default Roblox controls and can be found in some player > PlayerScripts > PlayerModule > MasterControl, so I do not know how I can dynamically change its functionality. Do you know of any other possible solutions to access the info from the non-parallel module script from some other parallel script more cleanly than my workaround?
I don’t see a practical reason why you need to modify player characteristics from a parallel context. You may have a design flaw if that happens to be required in your game. You should instead send whatever result that came from parallelized code to some centralized “marshaller” that does run in serial which can then more easily interface with the engine.
Parallelization is really only meant for data-crunching and hardcore mathematics; things like algorithms, raycasting/shapecasting, and world generation. It’s not supposed to be used for tinkering with frontend APIs all that much, which is why you need some organization and relaying to get things done.
Thank you for your response! You are correct. There was a design flaw that I fixed and so this is no longer an issue for me. But I suppose I must ask just to get a solution for this topic (but mainly out of curiosity); would it be possible to somehow access a non-parallel module from a parallel context? I know certain information can be distributed, but what I am asking is: can the entire non-parallel module be loaded from a parallel context? If so, how? If not, then I will leave this topic at that.
Each parallelized script is treated as a separate execution context, so loading the modulescript from a parallel context will work but the environment will be isolated (you cannot use modulescripts to share data between parallel scripts or between a parallel and a serial one). Usually, multiple scripts on the same execution context when requiring the same module will share the same module environment and the module itself will only be executed once, but this won’t happen for parallel scripts and the module will be executed separately for every parallel script.
