Issue description:
There is currently a inconsistency with how actor environments behave.
Right now if you create actors it has a global environment shared between every actor in the same VM, two per a logical core.
But currently on production servers each actor has a individual environment, breaking this consistency between studio and the client.
I don’t know if this is a feature not fully rolled out but it has implications for some previously assumed behavior.
I have attached a demo model which can be used to reproduce the behavior.
Reproduction steps:
Load in the model in studio
Do a play test in studio and observe there is only warns of a new VM id for each logical core you have on the client and server. The rest will be already assigned an ID.
Publish the place
Join a server on the published place. Note how the client keeps this previously observed behavior, but in the server logs each actor has a new ID implying that environments aren’t shared.
Thanks for your report. I took a look at the sample you provided. It turns out that the behavior between production servers and studio is actually the same. However, the number of VM’s being created is different. For example when I modified your sample to create 512 actors I could see that we start to reassign the same VM to multiple actors. So essentially the behavior is the same, but the number of actors that can be spawned before a VM is shared between actors is higher.
We consider how actors are assigned to VM’s to be intentionally unspecified behavior. It is quite possible in the future we could change how many actors are assigned to a single Luau VM. To be safe, code really shouldn’t rely on sharing state between actors using global luau variables or any other global VM state. Using actor messaging, SharedTable’s or DataModel state is what we encourage as alternatives ways to communicate state between actors.
On a somewhat related note, we do want to release some documentation soon to discuss how many scripts can run in parallel on a production server, or client, or in studio. Even the amount of parallelism is subject to change, but we hope to give developers some idea what they can expect.