findFirstChild lowercase is deprecated, so we didn’t add the ThreadSafe tag to it. Please use the uppercase version.
5 Likes
Your puny engine restrictions have no power over me!
Script called Heartbeat:
game["Run Service"].Heartbeat:connect(function()
local ti = tick()
print("Start Heartbeat")
repeat until tick() - ti > 0.01
print("End Heartbeat")
end)
Local script called Renderstepped
game["Run Service"].RenderStepped:connect(function()
print("------------------")
task.desynchronize()
task.synchronize()
local ti = tick()
print("Start RenderStepped")
repeat until tick() - ti > 0.01
print("End RenderStepped")
end)
That being said, are there plans to add another event to Runservice to allow the execution of serial lua before parallel lua within the same frame?
2 Likes
This is something we have been talking about as it would be nice to set things up, let the parallel phase run, and then use the results all in one frame. How we will enable this hasn’t been decided yet however.
8 Likes
Coroutines emulate threads by placing tasks in a queue. It will resume a task if all other tasks are yielding, so only one task can run at a time.
1 Like
I hope this will scale with the amount of players or in some other way. A server with around 10 players might not even need multi-threading, but it is a must on servers with over 50 players. Also, some genres like RTSs would benefit much more than more casual ones.
I’ve made some upgrades to my parallel terrain generator since the previous revision.
It’s hard to really show it off in one clip though, best to check it out for yourself!
ParallelTerrain.rbxl (55.4 KB)
Hopefully I can test this in a live game soon.
54 Likes
good stuff. ive been wondering what this actor stuff that ive been seeing around was. finally the uncomfortable feeling of crunching a lot of numbers in a synchronous thread is gone, at least partially. the explanation was a little confusing, though; why is writing to instances restricted? id think that as soon as an instance is written to that write would be visible to other scripts like normal. if this isnt the case, why? if it is the case, whats the problem?
I’m curious how you’re going to approach this given how Luau VM stacks currently work with ModuleScripts.
It would be nice if the synchronised phase could access the root global state of a module though, whether thats possible or not, is another question
1 Like
The reason scripts under an Actor have a different view of module scripts even during the synchronous phase is because a native lua object can’t move between VMs. The module root is a lua table, so it would have to be copied by value into the other VM, which is expensive and likely not what you want.
The shared storage will likely be an object that isn’t a native lua object and is thread safe.
6 Likes
I saw you typing btw, also with the allowance of multiple threads have an impact on improving FPS and increasing render distance?
The biggest problem with writing to instances at the moment is that changing a property triggers the Changed event, possibly in another VM, that is already running a different thread. We plan to make more properties writable over time.
5 Likes
It’s not the main goal, but it could help with client FPS under some rare circumstances.
4 Likes
I think this update is really good and promises a lot of new possibilities. Well done!
1 Like
Just finished my ECS lib too, I’ll be using this in future projects. Thanks for all the good work!
I love it!
I’ve been waiting for it since the developer preview and im so excited to finally start using it in my projects.
.
.
.
Btw i think you forgot to lock the “task” table 
Is this behavior intentional?
When you require a module and try to connect something in parallel in a function you call from another script it will cause the error “Scripts that connect in parallel must be rooted under an Actor.”, but it works just fine when you do the same from within the module script.
Modulescript:
script.Parent = Instance.new("Actor")
local function thisRunsFine()
Instance.new("BindableEvent").Event:ConnectParallel(function() end)
end
thisRunsFine() --this works
return thisRunsFine
Script:
local moduleScript = script.ModuleScript
thisCausesAnError = require(moduleScript) --this works
thisCausesAnError() --this causes an error
1 Like
That behavior isn’t intentional per sea. The main purpose of the error is a learning aid, that stops a user who’s new to the system from just changing Connect to ConnectParallel without setting up actors and thinking they have made things parallel. In a module script you might write a function that’s called by both scripts that are and are not under Actors, so for now we don’t throw this informative error. This may change in the future.
4 Likes
Overall, couldn’t understand this a lot, if someone can sum it up that’d be appreciated.
2 Likes
I have to say, I only understood half of what you were saying. I’m just going to wait for a youtube video to come out. Also, are there any resources for a more in-depth explanation of everything? I understand the basic premise of scripts running on different hardware threads, but that’s the limit of my understanding. Will there be an article tutorial about this?
2 Likes
This sounds incredible and all, but I’m just thinking about how on Earth I’m gonna switch my games to this new feature…