Proposal: a "role-defining" chip
complete
f
forbym
The original motivation for this suggestion is that it is difficult to make inventions with circuits that require any specific game roles (an example is ^DiscGolfTemplate). It would be nice if we could save any game roles that an invention needs with the invention, spawn it in any room, and it just works with any other roles that might already be in that room.
The proposal is a "role-defining" chip that has no inputs. Each "role-defining" chip can be configured to specify all features of exactly one role. (No "inheritance" from other roles but cloning of chips covers some of the use cases of this inheritance feature.) The one output of a "role-defining" chip is a unique ID of that role, which is unpredictable but constant while a room instance exists (similar to object IDs).
The Role Mapper chip gets an additional optional input which expects a role ID. If this input is connected, the Role Mapper chips uses that role, otherwise it works as it does currently (for full backwards compatibility).
If multiple roles of "role-defining" chips are enabled, the most recently enabled role is the active one. If any role of a "role-defining" chip is enabled, it overrides any other user-specified roles.
And that's it! With this, if an invention requires a role, you can just add a "role-defining" chip and connect its output to the new input pin of all Role Mapper chips that use that role. Since the roles that are defined this way don't use any kind of inheritance, they play nicely with any other roles that are defined in the room where an invention is spawned.
Other advantages: 1) "role-defining" chips get rid of the inheritance concept of game roles and replace it by familiar cloning of chips. 2) The use of roles in Role Mapper chips is visually represented by connections between chips instead of being hidden away in the configuration of chips and the room setup. 3) Role Mapper chips could use dynamically changing roles (depending on the game mode etc.).
Open question: how to represent roles from "role-defining" chips in the current user interface in the watch menu? There are many options: from just a message that the active role is provided by a chip, to listing all enabled roles that are provided by chips with configured names of all roles and a read-only interface to inspect the roles.
EDIT: When I wrote the description I did not understand how role inheritance works currently. (I'm pretty certain that role inheritance was changed since I last checked it.) With the current way inheritance works, there should be some changes to this suggestion, for example, by allowing inheritance of settings and giving the most recently activated role precedence over previously activated roles.
Joker
complete
DrummerGeek
Role inheritance is really important to some of the rooms I am working on. Losing it would be a real problem. There are also concerns when it comes to permissions. A room can allow someone to spawn in inventions, but not change roles, this would create issues as well. There would have to be another fixed role like Eliminated to set the limitations of what the role defining chip could do.
As long as room roles could still be defined and have inheritance, I would be all for this, though.
f
forbym
DrummerGeek: could you describe a use case of role inheritance where it is "really important"? IMHO saving work specifying all details of roles does not count as "really important" because it just means that inheritance saves the creator some time when defining the roles. It doesn't make anything possible that would be impossible or super difficult without it. And in my understanding, all you get from role inheritance is that you don't have to specify all the details of roles for each role.
I didn't think of the interaction with permissions to change roles. But that's something that could be handled: if an invention has a role-defining chip, whoever spawns it in a room has to have permissions to change roles. And that's a requirement that can be tested automatically by Rec Room.
Defining limitations of what a role-defining chip could do is an interesting thought. There is clearly a possibility of potential abuse by people spawning inventions that give them specific powers and take them from all others. But that might just mean that creators have to be more careful about giving others permissions to change roles.
DrummerGeek
forbym: Yes I can, my theater room has 11 roles and inheritance is really important to how they work. Without them, I would have to have closer to 20 roles to handle the combinations that can happen around who is where, plus it would cost more ink due to the increase of role check chips. I don't think any new feature should kill an existing feature.
If the chip defined roles define lower than the room roles, none of this would be a problem, the inheritance would allow the room owner to define the minimum requirements at the room role level and no invention could override it, if a value is not set, the invention can set it.
f
forbym
DrummerGeek: You are right; I didn't understand roles correctly. (I'm quite certain that the behavior of role inheritance was changed since I checked last time. And I checked extensively because the way it used to work made far less sense than it does now.)
f
forbym
DrummerGeek: Regarding overriding of room roles: think of the rules of games: there are certain situations in which a game has to allow or disallow flying/moving or in which you want to change speed of movement, jumping height etc. If the roles in inventions cannot override these settings, certain game rules would not work. Which would mean that if room owners are trying to use an invention by someone else, the room owners would have a much harder time to identify which setting they have to change in the room roles to make an invention work (assuming that they even realize that the invention fails to set certain settings). I'm convinced that role-defining chips have to be able to override at least the settings of the standard roles of the room.
I would agree that administrative roles (i.e. roles that are not part of any game) are different and should take precedence. One possible solution might be to give auto-assigned roles precedence over all other roles.
DrummerGeek
The problem is if a room creator doesn't want flying, or the voice rolloff set to 500 or sprint speed too high, etc, they need a way to set limits. If they don't set flying to disabled, then a role can set it. That would work with any role permission, if it isn't overridden above, the imported role can't change it.
f
forbym
DrummerGeek: well, the situation i'm imagining is someone with permission to spawn inventions and changing roles wants to spawn an invention by someone else that needs to change roles to implement some game. if room roles always have preference then i see a risk that the invention won't work correctly because it cannot do something that the game rules require, which would be difficult to debug for the person trying to use the invention (assuming that they don't know the internals of the invention). on the other hand, i think the risk that the invention does something unwanted is more manageable because if that's the case then the player spawning the invention just shouldn't save the room with the invention. i guess my assumption is: either you want a functioning invention or you don't want the invention at all.
and if the room creator wants those limits, they have to stop other players from changing permissions and roles, which should stop other players from spawning inventions that set roles. thus, the room creator would be in full control which role-changing inventions are spawned.
DrummerGeek
forbym: The alternative is that the roles created by the invention also show up in the roles list of the room, but at the bottom by default, so anyone who has permissions to change the room roles can move them up in the priority, but if they don't have permissions, then the default room roles take priority if they are set.
f
forbym
DrummerGeek: my concern is that a room creator who spawns an invention might not know nor care what roles an invention defines and which precedence level those roles need. i think that your proposal will require too much from room creators when they try to use inventions that define roles. in my view, an invention should just work - room creators should not be required to fix the room roles to make it work.
i do see your point for more administrative roles that do not take part in games and therefore should not be affected by roles in an invention. but for all other roles, strict limitations on them will probably break many inventions that rely on roles.
DrummerGeek
forbym: I agree. The default behavior is for it to work out of the box. But room owners should have the option to limit it.