Mind Role Entities

[Errant-4]

About the PR

Mind Roles are now entities. They can be accessed by a new datafield on MindComponent which containts a List of all mind role entities on that mind.

Each Mind Role Entity has

• a MindRoleComponent, which contains most of the data commonly used by mind roles such as antag status, antag prototype, job prototype, and the Entity of the mind entity for easy access.
• some specific component which were previously considered "the mind roles" like JobRoleComponent ((previously JobComponent)), GhostRoleMarkerRoleComponent or some antagonist component like DragonRoleComponent.

Mind Role Entities are created from the entity prototypes you can currently see in mind_roles.yml, and are searched based on the additional unique mind role components they have. This is why mind roles only have one* "free-choice" component on top their mandatory MindRoleComponent, so you can search the zombie mind role based on which one has ZombieRoleComponent, delete it, and be assured that no other mind role data will be deleted along with it. Those are on their own mind role entities.
(RoleBriefingComponent is an exception since for that it makes sense to be paired with something specific, like the mind role entity of TraitorRoleComponent. So role briefing is put on some other mind role. For this reason, searching for the RoleBriefingComponent mind role entity will possibly show misleading results, but no one should ever need to search for that mind role anyway, you would want to access it in the context of a specific mindrole)

Externally, RoleSystem(s) and JobSystem(s) work rather similarly as they did before.

You can add roles to a mind with MindAddRole, remove them with MindRemoveRole, and check them with MindHasRole
MindHasRole can now also output the Entity of the mind role (and also Entity for the few situations where some data is stored on that component, such as the conversion counter of Head Revs
As noted, from any MindRoleComponent you also have an easy way back to the mind Id and component with the Mind datafield (although you would in almost every imaginable scenario probably already have at least the mindId when you are dealing with mind roles)

Admin stuff

Admins get a log entry (in the Mind category) every time a mind role is added or removed, or if the Job role of someone changes (aka they are set from Captain to Botanist) (I think this only currently possible manually via the addrole command, which now modifies an existing job when you try to add one on top of it, rather than spew out an error as it does on Live. However, a quick informal query found that basically no admin has ever used this command for anything)

Why / Balance

Currently on Live it is only possible to flag minds as antagonist by adding "antagonist components" to an ever-increasing list in JobSystem. A comment left on that section by SmugLeaf specifically asks for mind role entities
I also need this change for an upcoming PR about better tracking the specific (antag-or-other) Role Types of minds

Media

Requirements

• I have read and I am following the Pull Request Guidelines. I understand that not doing so may get my pr closed at maintainer’s discretion
• I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Role Components are now on their own Mind Role entities, rather than on the Mind entity. They have been all parented to BaseMindRoleComponent for organisational clarity

MindTryGetJob no longer has two outputs. Simply remove the first output variable (component) from any current uses of the function. This only ever seemed to be used to get the prototype, which was the second (now only) output.

MindAddRole now takes prototypes as input, not a component. Create an entity prototype for the mind role you want to add to a mind. These are in mind_roles.yml. To add a Job mind role, use MindAddJobRole and pass it the job prototype id as well.

SpawnPlayerMob now takes a job prototype id as input, not job component

JobComponent was renamed to JobRoleComponent. Check any current implementations that look for or manipulate this component, as it is now on a mind role entity rather than on the mind entity.

RoleRequirementComponents using mind role components will no longer work. Entity prototypes relying on this must switch to looking for mindRoles instead.

Some briefings created by specific new AntagonistSystems might break, since the subscribed components moved from the Mind to Mind Roles. Thus, there is a high possibility that the function to handle the OnGetBriefingEvent will fail to finish.

MindGetAllRolesEvent renamed to MindGetAllRoleInfoEvent (to avoid confusion between it and mind roles)
MingGetAllRoles() was renamed to MindGetAllRoleInfo()
RoleInfo type no longer holds component data. This was only used by one specific listingcondition, BuyerAntagCondition, which no longer needs it to work (and no actual listing prototype even used this condition anyway)

MindSystem.MindAddJob() was removed. You can use SharedRoleSystem.MindAddJobRole() instead

Changelog
🆑 Errant

• tweak: Nukies now have role briefing on their character screen.
• fix: Animals who are made Thief no longer get told in their briefing about the thief gear that they don't actually have and couldn't possibly use.

[Errant-4]

I'M 90% sure the test fail was random and unrelated, if anyone is bored and wants to look into that

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[Errant-4]

Test fail is a lie

[Winkarst-cpu]

Test fail is a lie

Portal reference?!

[Errant-4]

Everything is a portal reference if you want it enough

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[Callmore]

wait are you suggesting this is how i should of been checking if a player was the ai in a sane and reasonable way