Improbable Icon

SpatialOS Discourse Forums


Why is it when building an authoritative player entity template when setting its write access
via EntityTemplate.GetWorkerAccessAttribute which results in something like workerId:UnityClient-6e431ea8 , while in the same time you can just pass something like UnityClient / UnityGameLogic as the component read / write access ?

Hi @Wad1m,

You would typically set the write access of a component to a worker type (e.g. UnityGameLogic, UnityClient) when you don’t mind which specific worker is authoritative, as long as it is one of those workers. For example, I might want the enemy NPC shooting component to be controlled by a UnityGameLogic worker, but I don’t care to specify which individual worker is authoritative as the NPC may be moving around the game world.

In contrast, for something like a player controls component, you would not want to set the authority to UnityClient as then one player (a.k.a. UnityClient worker instance) might gain authority over another player’s control component!

For this case, you would set the write access to the specific worker Id through EntityTemplate.GetWorkerAccessAttribute to ensure that the authority is tied to the specific worker.

Hi @Wad1m, just to add to the above, specifying a worker type (as opposed to a worker Id) in an ACL for write authority is only valid when that worker type is a managed worker type. So with that in mind, UnityClient wouldn’t be valid.

I hope that clears things up for you!