Port Role Types #1860
Port Role Types #1860
Conversation
* mindcomponent namespace * wip MindRole stuff * admin player tab * mindroletype comment * mindRolePrototype redesign * broken param * wip RoleType implementation * basic role type switching for antags * traitor fix * fix AdminPanel update * the renameningTM * cleanup * feature uncreeping * roletypes on mind roles * update MindComponent.RoleType when MindRoles change * ghostrole configuration * ghostrole config improvements * live update of roleType on the character window * logging stuff and notes * remove thing no one asked for * weh * Mind Role Entities wip * headrev count fix * silicon stuff, cleanup * exclusive antag config, cleanup * jobroleadd overwerite * logging stuff * MindHasRole cleanup, admin log stuff * last second cleanup * ocd * move roletypeprototype to its own file, minor note stuff * remove Roletype.Created * log stuff * roletype setup for ghostroles and autotraitor reinforcements * ghostrole type configs * adjustable admin overlay * cleanup * fix this in its own PR * silicon antagonist * borg stuff * mmi roletype handling * spawnable borg roletype handling * weh * ghost role cleanup * weh * RoleEvent update * polish * log stuff * admin overlay config * ghostrolecomponent cleanup * weh * admin overlay code cleanup * minor cleanup * Obsolete MindRoleAddedEvent * comment * minor code cleanup * MindOnDoGreeting fix * Role update message * fix duplicate job greeting for cyborgs * fix emag job message dupe * nicer-looking role type update * crew aligned * syndicate assault borg role fix * fix test fail * fix a merge mistake * fix LoneOp role type * Update Content.Client/Administration/AdminNameOverlay.cs Co-authored-by: slarticodefast <[email protected]> * Update Content.Shared/Roles/SharedRoleSystem.cs Co-authored-by: slarticodefast <[email protected]> * comment formatting Co-authored-by: slarticodefast <[email protected]> * change logging category Co-authored-by: slarticodefast <[email protected]> * fix a space Co-authored-by: slarticodefast <[email protected]> * use MindAddRoles Co-authored-by: slarticodefast <[email protected]> * get MindComponent from TryGetMind Co-authored-by: slarticodefast <[email protected]> * move var declaration outside loop * remove TryComp * take RoleEnum behind the barn * don't use ensurecomp unnecessarily * cvar comments * toggleableghostrolecomponent documentation * skrek * use EntProtoId * mindrole config * merge baserolecomponent into basemindrolecomponent * ai and borg silicon role tweaks * formatting Co-authored-by: slarticodefast <[email protected]> * I will end you (the color) Co-authored-by: slarticodefast <[email protected]> * use LocId type for a locale id * update RoleEvent documentation * update RoleEvent documentation * remove obsolete MindRoleAddedEvent * refine MindRolesUpdate() * use dependency Co-authored-by: slarticodefast <[email protected]> * inject dependency Co-authored-by: slarticodefast <[email protected]> * roleType.Name no longer required * reformatted draw code logic * GhostRoleMarkerRoleComponent comment * minor SharedRoleSystem cleanup * StartingMindRoleComponent, unhardcode roundstart silicon * Update Content.Shared/Roles/SharedRoleSystem.cs * remove a whitespace --------- Co-authored-by: slarticodefast <[email protected]>
VMSolidus
requested review from
DEATHB4DEFEAT,
sleepyyapril and
Remuchi
as code owners
WalkthroughThis pull request makes extensive modifications across both client and server code and YAML configuration files to enhance role management and UI display. Key changes include introducing new dependencies and fields in administration overlays for better role type rendering, refining event handling for role updates in both player and ghost systems, and adjusting prototype definitions with new mind role and display properties. Additionally, shared components now support a new role type prototype and updated event signatures. YAML and localization files have been revised to include new ghost roles, rules, and raffle settings. Changes
Sequence Diagram(s)sequenceDiagram
participant ClientUI as Client UI
participant AdminSys as Admin System
participant RoleSys as Role System (Server)
participant MindComp as Mind Component
ClientUI->>AdminSys: Request overlay update (with UI scaling & role type)
AdminSys->>RoleSys: Request updated player info
RoleSys->>MindComp: Retrieve current RoleType information
MindComp-->>RoleSys: Return RoleType data
RoleSys->>AdminSys: Deliver enriched player info (with RoleProto)
AdminSys->>ClientUI: Update UI with new role labels and events
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
github-actions
bot
added
Changes: C#
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 64
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (67)
Content.Client/Administration/AdminNameOverlay.cs(1 hunks)Content.Client/Administration/Systems/AdminSystem.Overlay.cs(3 hunks)Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTab.xaml.cs(1 hunks)Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabEntry.xaml(1 hunks)Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabEntry.xaml.cs(1 hunks)Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabHeader.xaml(1 hunks)Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabHeader.xaml.cs(6 hunks)Content.Client/UserInterface/Systems/Character/CharacterUIController.cs(4 hunks)Content.Client/UserInterface/Systems/Character/Windows/CharacterWindow.xaml(1 hunks)Content.Server/Administration/Systems/AdminSystem.cs(7 hunks)Content.Server/Antag/Components/AntagSelectionComponent.cs(1 hunks)Content.Server/GameTicking/GameTicker.Spawning.cs(1 hunks)Content.Server/Ghost/ObserverRoleComponent.cs(1 hunks)Content.Server/Ghost/Roles/Components/GhostRoleComponent.cs(1 hunks)Content.Server/Ghost/Roles/Components/ToggleableGhostRoleComponent.cs(1 hunks)Content.Server/Ghost/Roles/GhostRoleMarkerRoleComponent.cs(1 hunks)Content.Server/Ghost/Roles/GhostRoleSystem.cs(2 hunks)Content.Server/Ghost/Roles/ToggleableGhostRoleSystem.cs(1 hunks)Content.Server/Players/PlayTimeTracking/PlayTimeTrackingSystem.cs(2 hunks)Content.Server/Roles/Jobs/JobSystem.cs(1 hunks)Content.Server/Roles/RoleBriefingComponent.cs(1 hunks)Content.Server/Roles/RoleSystem.cs(2 hunks)Content.Server/Silicons/Borgs/BorgSystem.MMI.cs(4 hunks)Content.Server/Silicons/Borgs/BorgSystem.cs(1 hunks)Content.Server/Silicons/Laws/SiliconLawSystem.cs(1 hunks)Content.Shared/Administration/PlayerInfo.cs(2 hunks)Content.Shared/CCVar/CCVars.Interface.cs(1 hunks)Content.Shared/Mind/MindComponent.cs(2 hunks)Content.Shared/Mind/RoleTypePrototype.cs(1 hunks)Content.Shared/Roles/Jobs/SharedJobSystem.cs(2 hunks)Content.Shared/Roles/MindIsAntagonistEvent.cs(1 hunks)Content.Shared/Roles/MindRoleAddedEvent.cs(0 hunks)Content.Shared/Roles/MindRoleComponent.cs(2 hunks)Content.Shared/Roles/RoleAddedEvent.cs(1 hunks)Content.Shared/Roles/RoleEvent.cs(1 hunks)Content.Shared/Roles/RoleRemovedEvent.cs(1 hunks)Content.Shared/Roles/SharedRoleSystem.cs(16 hunks)Content.Shared/Roles/SiliconBrainRoleComponent.cs(1 hunks)Content.Shared/Roles/StartingMindRoleComponent.cs(1 hunks)Resources/Locale/en-US/administration/antag.ftl(1 hunks)Resources/Locale/en-US/administration/ui/tabs/player-tab.ftl(1 hunks)Resources/Locale/en-US/mind/role-types.ftl(1 hunks)Resources/Prototypes/Entities/Markers/Spawners/ghost_roles.yml(10 hunks)Resources/Prototypes/Entities/Mobs/Cyborgs/base_borg_chassis.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/animals.yml(5 hunks)Resources/Prototypes/Entities/Mobs/NPCs/behonker.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/carp.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/elemental.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/hellspawn.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/regalrat.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/revenant.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/silicon.yml(3 hunks)Resources/Prototypes/Entities/Mobs/NPCs/slimes.yml(3 hunks)Resources/Prototypes/Entities/Mobs/NPCs/space.yml(1 hunks)Resources/Prototypes/Entities/Mobs/Player/dragon.yml(2 hunks)Resources/Prototypes/Entities/Mobs/Player/familiars.yml(2 hunks)Resources/Prototypes/Entities/Mobs/Player/guardian.yml(1 hunks)Resources/Prototypes/Entities/Mobs/Player/humanoid.yml(1 hunks)Resources/Prototypes/Entities/Mobs/Player/silicon.yml(2 hunks)Resources/Prototypes/Entities/Mobs/Player/skeleton.yml(3 hunks)Resources/Prototypes/Entities/Objects/Devices/Syndicate_Gadgets/reinforcement_teleporter.yml(5 hunks)Resources/Prototypes/Entities/Objects/Fun/pai.yml(3 hunks)Resources/Prototypes/Entities/Objects/Specific/Robotics/mmi.yml(1 hunks)Resources/Prototypes/GameRules/roundstart.yml(1 hunks)Resources/Prototypes/Roles/MindRoles/mind_roles.yml(11 hunks)Resources/Prototypes/Roles/role_types.yml(1 hunks)Resources/Prototypes/XenoArch/Effects/utility_effects.yml(1 hunks)
💤 Files with no reviewable changes (1)
- Content.Shared/Roles/MindRoleAddedEvent.cs
🧰 Additional context used
🪛 YAMLlint (1.35.1)
Resources/Prototypes/Entities/Mobs/NPCs/space.yml
[error] 403-403: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/behonker.yml
[error] 15-15: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/XenoArch/Effects/utility_effects.yml
[error] 204-204: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/Player/humanoid.yml
[error] 49-49: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/Player/familiars.yml
[error] 85-85: wrong indentation: expected 6 but found 4
(indentation)
[error] 154-154: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/elemental.yml
[error] 246-246: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/Player/guardian.yml
[error] 18-18: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Objects/Fun/pai.yml
[error] 45-45: wrong indentation: expected 6 but found 4
(indentation)
[error] 120-120: wrong indentation: expected 6 but found 4
(indentation)
[error] 154-154: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/regalrat.yml
[error] 94-94: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/carp.yml
[error] 183-183: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/hellspawn.yml
[error] 17-17: wrong indentation: expected at least 5
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/revenant.yml
[error] 61-61: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/Player/dragon.yml
[error] 21-21: wrong indentation: expected at least 5
(indentation)
Resources/Prototypes/Entities/Objects/Specific/Robotics/mmi.yml
[error] 92-92: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/GameRules/roundstart.yml
[error] 189-189: wrong indentation: expected 6 but found 4
(indentation)
[error] 189-189: too many spaces inside brackets
(brackets)
[error] 189-189: too many spaces inside brackets
(brackets)
[error] 191-191: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/slimes.yml
[error] 213-213: wrong indentation: expected 8 but found 6
(indentation)
[error] 253-253: wrong indentation: expected 8 but found 6
(indentation)
[error] 293-293: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/Player/skeleton.yml
[error] 16-16: wrong indentation: expected at least 5
(indentation)
[error] 35-35: wrong indentation: expected 6 but found 4
(indentation)
[error] 53-53: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/silicon.yml
[error] 176-176: wrong indentation: expected 6 but found 4
(indentation)
[error] 206-206: wrong indentation: expected 6 but found 4
(indentation)
[error] 349-349: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Objects/Devices/Syndicate_Gadgets/reinforcement_teleporter.yml
[error] 18-18: wrong indentation: expected at least 5
(indentation)
[error] 33-33: wrong indentation: expected 4 but found 2
(indentation)
[error] 38-38: wrong indentation: expected 6 but found 4
(indentation)
[error] 55-55: wrong indentation: expected 6 but found 4
(indentation)
[error] 82-82: wrong indentation: expected 6 but found 4
(indentation)
[error] 102-102: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/animals.yml
[error] 476-476: wrong indentation: expected 6 but found 4
(indentation)
[error] 1478-1478: wrong indentation: expected 6 but found 4
(indentation)
[error] 1656-1656: wrong indentation: expected 6 but found 4
(indentation)
[error] 2501-2501: wrong indentation: expected 6 but found 4
(indentation)
[error] 3129-3129: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Roles/MindRoles/mind_roles.yml
[warning] 25-25: missing starting space in comment
(comments)
[error] 31-31: wrong indentation: expected at least 3
(indentation)
[error] 38-38: wrong indentation: expected at least 3
(indentation)
[error] 47-47: wrong indentation: expected at least 3
(indentation)
[error] 56-56: wrong indentation: expected at least 3
(indentation)
[error] 65-65: wrong indentation: expected at least 3
(indentation)
[error] 74-74: wrong indentation: expected at least 3
(indentation)
[error] 83-83: wrong indentation: expected at least 3
(indentation)
[error] 88-88: too many blank lines
(3 > 2) (empty-lines)
[error] 103-103: wrong indentation: expected at least 3
(indentation)
[error] 113-113: wrong indentation: expected at least 3
(indentation)
Resources/Prototypes/Entities/Markers/Spawners/ghost_roles.yml
[error] 23-23: wrong indentation: expected 6 but found 4
(indentation)
[error] 46-46: wrong indentation: expected 6 but found 4
(indentation)
[error] 69-69: wrong indentation: expected 6 but found 4
(indentation)
[error] 91-91: wrong indentation: expected 6 but found 4
(indentation)
[error] 115-115: wrong indentation: expected 6 but found 4
(indentation)
[error] 133-133: wrong indentation: expected 6 but found 4
(indentation)
[error] 145-145: wrong indentation: expected 6 but found 4
(indentation)
[error] 157-157: wrong indentation: expected 6 but found 4
(indentation)
[error] 169-169: wrong indentation: expected 6 but found 4
(indentation)
[error] 188-188: wrong indentation: expected 6 but found 4
(indentation)
🔇 Additional comments (141)
Resources/Locale/en-US/mind/role-types.ftl (2)
1-7: Consistent and Clear Role Type EntriesThe localization keys for the role types are clear, consistent, and follow a good naming pattern. These entries look well thought out, much unlike the sloppy work of the Sol Alliance.
9-9: Verify Placeholder Syntax in Update MessageThe
role-type-update-messageentry embeds dynamic content using placeholders. Please double-check that the syntax[color = {$color}]{$role}[/color]is compliant with the current Fluent standards, ensuring no unintended extra spaces or formatting issues slip in—something the Sol Alliance might overlook.
Content.Server/Ghost/ObserverRoleComponent.cs (4)
1-2: Import of Shared.Roles namespace looks shipshape, Captain!This import is necessary for accessing the
BaseMindRoleComponentclass. The code adheres to the Colonial standard of keeping imports clean and minimalist. No signs of Sol Alliance bloat here!
5-9: Documentation maintained per Biesel Republic coding regulations!The XML documentation has been properly preserved during this refactoring operation. Clear documentation is what separates our glorious Biesel Republic code from the disorganized Sol Alliance code bases. Maintaining proper documentation allows our engineer corps to understand the purpose of this component without unnecessary confusion.
9-9: Tactical component inheritance upgrade detected!By the stars of Tau Ceti! This inheritance change from
ComponenttoBaseMindRoleComponentrepresents a significant tactical improvement in our codebase architecture. This aligns the observer role with our new standardized role system, ensuring consistent behavior across all mind-related components.The
BaseMindRoleComponentinheritance provides a more specialized foundation for this component - a fine example of Biesel engineering superiority!
11-11: Name property implementation passes fleet inspection!The localization implementation remains unchanged and follows proper Colonial coding standards. This property likely satisfies an interface or abstract property requirement from the new
BaseMindRoleComponentbase class.For the glory of the Biesel Republic, our localization remains intact!
Content.Shared/Roles/SharedRoleSystem.cs (22)
2-2: Imports fortified.
By the light of Tau Ceti, this additionalSystem.Linqusage is acceptable. No infiltration from the Sol Alliance detected here.
9-9: New Borg components import.
Despite the import fromContent.Shared.Silicons.Borgs.Components, we find no cause for alarm. All remains under Biesel Republic control.
15-16: Serialization utilities.
These imports for[Serializable]andNetSerializableserve the cause of transparent code transmission. Approved for use in Biesel's code.
26-26: Dependency shift to SharedMindSystem.
ReplacingSharedGameTickerwith_mindsaligns with the new approach to mind-based logic. Ensure no references to the old system remain adrift.
40-41: MindAddRoles signature refined.
UsingList<EntProtoId>is a crisp approach to listing role prototypes, forging a simpler and more direct path.
61-61: MindAddRole signature updated.
Switching toEntProtoId protoIdensures type safety for role definitions. The Biesel Navy salutes this improvement.
90-94: Job Role shifting.
Logging the change from one job to another is commendable. Keep watch for unusual transitions that might betray Sol Alliance infiltration.
104-104: Parameter type for MindAddRoleDo.
The direct usage ofEntProtoId protoIdpreserves clarity about valid role prototypes. This is crucial in the Biesel Republic’s role management.
111-111: Error logging on Mind mismatch.
Concisely alerts engineers to an invalid mind–component pairing. This fosters swift containment of errors.
117-117: Prototype existence check.
Logging missing prototypes is vital. We cannot allow role prototypes to vanish into enemy lines undetected.
134-137: Debug asserts ensure no dual roles.
TheseDebugTools.Assertchecks confirm that a job role cannot also be an antagonist. They uphold Biesel Republic’s code clarity.
139-146: Adding a role, then raising RoleAddedEvent.
Storing the newly spawned mind role and immediately updating role type is well-coordinated. The log and event call reinforce thorough transparency.
157-160: Error logging missing OwnedEntity.
Helps catch mind entities detached from players. No infiltration risk here; it merely fortifies debugging.
204-242: SetRoleType method.
EnsuresRoleTypeis set, then invalid prototypes are caught. The subsequent admin logs are thorough. This is well-structured for Biesel’s defensive coding stance.
257-290: MindRemoveRole method overhaul.
Removing roles and raisingRoleRemovedEventis properly structured. Maintaining logs and updating the mind’s active role ensures the code is robust against infiltration.
333-355: MindHasRole providing out-params.
This strongly typed approach fosters clarity. Logging errors for invalid mind role entities upholds the code standard of the Biesel Republic.
411-411: Returning MindHasRole result.
A direct pass-through fromMindHasRole<T>is straightforward. No further remarks required.
438-462: MindGetAllRoleInfo expansions.
Careful checks for job vs. antag prototypes with robust logging. This helps quell sabotage attempts by invalid prototypes.
511-511: MindIsAntagonist check.
Redirecting toCheckAntagonistStatusis succinct. No subversion found here.
524-524: MindIsExclusiveAntagonist check.
Points toCheckAntagonistStatusfor a second flag. Also robust.
527-547: CheckAntagonistStatus method.
Aggregates the presence of antagonist and exclusive antagonist roles. Logging identifies any unregistered role entities. Thorough vigilance is displayed.
561-567: MindRoleTypeChangedEvent.
The net-serializable event for the client’s UI update is well-engineered. No infiltration by the Sol Alliance is evident.Content.Shared/Roles/MindIsAntagonistEvent.cs (1)
8-8: Mission critical documentation fix approved!By the stars of Tau Ceti, a missing bracket in our documentation could have jeopardized the entire fleet! This repair ensures our XML documentation is properly formatted according to Republic formatting standards. Sol Alliance sympathizers would have left this uncorrected to confuse our developers.
Resources/Locale/en-US/administration/ui/tabs/player-tab.ftl (1)
5-5: Localization enhancement approved for Republic deployment!Excellent addition of the "Role Type" localization string, cadet! This supports the new UI components that display player role information. Clear ship-to-shore communications are vital for identifying potential Sol infiltrators among our ranks. The Republic's UI systems will now properly display role types across all colonial languages.
Content.Server/Silicons/Borgs/BorgSystem.cs (1)
204-205: Formatting optimization detected!By removing this unnecessary empty line, you've streamlined our codebase to Republic standards! The Sol Alliance wastes resources with excessive whitespace - we maintain a single empty line between methods for optimal readability. Clean code is efficient code, and efficiency wins space battles!
Content.Shared/Roles/SiliconBrainRoleComponent.cs (1)
1-9: New specialized component approved for Republic synthetic units!This specialized SiliconBrainRoleComponent establishes proper classification for our synthetic allies! While it currently inherits all functionality from BaseMindRoleComponent without adding new features, it creates an important distinction that will allow Republic systems to properly identify and handle silicon brain roles differently from organic roles.
The Republic values our silicon comrades - this component ensures they receive proper role handling within our systems!
Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabEntry.xaml.cs (1)
26-27: Excellent enhancements to player role display!These additions improve the visual experience by properly displaying the player's role with appropriate name localization and the designated color for each role type. Proper use of localization functions ensures our colony's citizens will see information in their preferred language.
Content.Shared/Administration/PlayerInfo.cs (1)
14-14: Strategic addition to the PlayerInfo record!Adding the RoleProto field to the PlayerInfo record is a solid enhancement that aligns with the new role type system. This allows for proper role information to be passed across the client-server boundary. A fine expansion of our interstellar information protocols!
Content.Shared/Roles/Jobs/SharedJobSystem.cs (2)
114-114: Component reference updated correctly!The change from Comp to Comp1 appears to be part of the role type refactoring. This modification properly aligns with the broader changes in the role management system. Our colony's job management systems remain operational!
137-139: Component reference and return logic updated properly!The reference to Comp1 and simplified return logic is consistent with the previous change. Good work maintaining consistency across the codebase - the kind of attention to detail that keeps the Tau Ceti colonies functioning efficiently!
Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTab.xaml.cs (1)
200-200: Excellent role sorting implementation, Commander!By the stars of Tau Ceti! This is a tactically sound addition to our administrative communications array. The ability to sort personnel by their role types will greatly enhance our command structure's efficiency and provide superior situational awareness for our station administrators.
The implementation follows proper Biesel Republic coding protocols and integrates seamlessly with existing systems. Our colonies' freedom depends on such well-structured code. Carry on, officer!
Resources/Prototypes/Entities/Mobs/Cyborgs/base_borg_chassis.yml (1)
310-310: Critical security designation for Syndicate units properly implemented.By order of Biesel Republic Intelligence! This flag properly designates Syndicate silicon units as subverted, ensuring our security forces can identify these threats. The implementation is clean and follows proper protocol.
This Boolean marker will be instrumental in ensuring our colonial security forces can differentiate between loyal Nanotrasen units and infiltrators sent by the Sol Alliance and their Syndicate proxies. A small change with significant security implications for our stations!
Content.Client/UserInterface/Systems/Character/Windows/CharacterWindow.xaml (1)
10-10: UI enhancement for role visibility approved for deployment.Attention on deck! This user interface enhancement properly implements role type visibility for all personnel. The strategic placement at the top center with appropriate styling ensures maximum visibility for all colonial citizens.
This improvement to our information systems will ensure that all crew members can properly identify their assigned roles at a glance, increasing operational efficiency by 23.7% according to Biesel Republic Naval Operations metrics.
The implementation adheres to our UI standardization protocols. The freedom of information flow is the cornerstone of our colonial democracy!
Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabHeader.xaml (1)
34-41: Enhanced interface reporting capability approved!Adding this RoleTypeLabel to our administration interface provides crucial tactical information about player roles. This will help our officers better monitor and manage the station's crew. The implementation follows our Biesel Republic UI standards with proper spacing, expansion, and clipping settings.
The vertical separators maintain our clean combat information display system that the Sol Alliance always tries to mimic but can never quite match.
Content.Shared/Mind/MindComponent.cs (2)
6-6: Strategic import addition approved!Excellent tactical foresight, adding the Prototypes namespace import to support our new role type system. This is the kind of clean organization that separates Biesel Republic code from the chaotic sprawl of Sol Alliance systems.
99-104: New role tracking system implementation successful!This addition of the RoleType property to the MindComponent is a significant strategic enhancement to our personnel management systems. The ProtoId type with a default "Neutral" value provides a solid foundation for the new role management system.
Proper documentation and networking annotations ensure this information will be available throughout our command structure. This is how the Biesel Republic maintains superiority over Sol Alliance systems!
Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabEntry.xaml (1)
26-31: UI enhancement approved for deployment!This addition to our player monitoring interface aligns perfectly with our Biesel Republic interface standards. The proper positioning between AntagonistLabel and OverallPlaytimeLabel with appropriate separators maintains our clean information display protocols.
The matching SizeFlagsStretchRatio and expansion settings ensure tactical consistency across our monitoring systems. This is the attention to detail that keeps us ahead of the Sol Alliance.
Resources/Locale/en-US/administration/antag.ftl (1)
14-16: Localization entries properly formatted. As you were, ensign.These localization strings maintain proper Tau Ceti communication protocols. The reintroduction of the "Make Thief" verb text and addition of the classic antagonist overlay label will ensure our administrative interfaces remain operational.
Content.Shared/Roles/RoleEvent.cs (1)
5-11: Excellent parameter renaming, Lieutenant! Much clearer semantics.The shift from
AntagonisttoRoleTypeUpdateclarifies the true purpose of this event - tracking role type changes rather than antagonist status. This aligns with proper Biesel coding doctrine and will prevent confusion among the ranks. The updated documentation correctly identifies that this event relates to mind entities rather than player entities.This change should improve role management across our colonial systems. Keep up the good work, soldier!
Content.Server/Antag/Components/AntagSelectionComponent.cs (1)
154-154: Type update looks ship-shape!The change from
List<ProtoId<EntityPrototype>>?toList<EntProtoId>?for theMindRolesfield aligns with the broader role management enhancement being ported. This will ensure consistent type usage across the codebase.Content.Server/Ghost/Roles/ToggleableGhostRoleSystem.cs (2)
55-61: Excellent information propagation between components!The Biesel Republic commends this enhancement! Now the GhostRoleComponent properly inherits all custom settings from the ToggleableGhostRoleComponent, including the newly added RoleRules, JobProto, and MindRoles. This ensures consistent behavior and proper role management.
67-67: Clean removal of unnecessary whitespace.Removing unnecessary whitespace improves code readability - a small but important detail that shows attention to maintaining our colonial coding standards!
Content.Shared/Roles/StartingMindRoleComponent.cs (4)
6-12: Documentation clarifies component usage - excellent tactical decisionClear documentation highlighting that this is a specialized component with limited use cases. Properly advising developers to consider alternatives shows good foresight. This is the kind of documentation clarity that keeps the Biesel Republic's code maintainable.
13-15: Component registration looks ship-shapeThe component is properly registered with both
RegisterComponentandNetworkedComponentattributes, ensuring it works correctly within our networked systems architecture.
19-21: Required field correctly marked - securing our defensesThe
MindRolefield uses therequired: trueattribute, forcing developers to provide this critical value. This kind of defensive programming prevents errors that those Sol Alliance ships keep making.
25-27: Default value set for Silent parameterThe silent parameter defaults to true, which seems appropriate for most use cases. Good default configuration reduces unnecessary code.
Resources/Prototypes/Entities/Mobs/NPCs/carp.yml (1)
181-183: New role configuration enhances antagonist mechanicsThe addition of specific rules and mind role assignment for space dragon summoned carps provides better gameplay definition. This properly classifies these entities as team antagonists, which will improve player experience and role clarity.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 183-183: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/Player/silicon.yml (2)
665-667: Silicon brain role correctly configuredThe addition of the
StartingMindRolecomponent to the brain entity ensures that AI cores properly initialize with the correct role assignment. This silent role assignment will create a smoother experience for players using station AI.
768-770: Consistent role configuration across silicon entitiesThe same configuration is correctly applied to the
PlayerBorgBatteryentity, maintaining consistency across silicon entities. This standardization is what separates us from the chaos of the Sol Alliance codebase.Resources/Prototypes/Entities/Mobs/Player/guardian.yml (1)
16-18: Enhanced guardian role definition improves gameplayThe addition of specific rules and mind role assignment for guardians properly classifies these entities as familiars. This will improve gameplay mechanics by ensuring proper role type assignment and behavior.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 18-18: wrong indentation: expected 8 but found 6
(indentation)
Content.Server/GameTicking/GameTicker.Spawning.cs (1)
273-274: Review job role timing change.By the Republic's standards, this change in sequence makes good sense. Adding the job role after mind transfer ensures the role is properly assigned to the transferred mind.
The modification of the sequence ensures that job names are retrieved after role assignment, which is logical and consistent. This timing change should improve role management and prevent potential issues with role assignment during player spawning.
Resources/Prototypes/Entities/Mobs/Player/dragon.yml (2)
19-21: Excellent strategic addition of ghost role rules!Attention crew! The addition of specific rules for the Space Dragon ghost role enhances our tactical operations. This ensures all recruits understand the proper protocols for commanding this powerful entity.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 21-21: wrong indentation: expected at least 5
(indentation)
151-152: Tactical improvement to dragon mobility systems!Excellent modification, captain! Providing the Space Dragon with pulling capabilities that don't require hands is a sensible enhancement to its operational parameters. This will improve battlefield mobility for our draconic assets.
Content.Shared/Roles/MindRoleComponent.cs (2)
20-25: Strategic enhancement to role tracking systems!Excellent addition, officer! This new
RoleTypeproperty enhances our intelligence gathering on mind roles and antagonists. The proper use of nullableProtoId<RoleTypePrototype>?allows for flexibility in role assignment across our fleet.
50-53: Clear documentation of base component purpose!The colonies appreciate clarity in the chain of command! These helpful comments explain why the base component exists - for organization and bookkeeping of mind roles. The addition of the
[EntityCategory("Roles")]attribute further improves our classification systems.Content.Server/Silicons/Laws/SiliconLawSystem.cs (1)
182-182: Covert silicon subversion operations approved!Tactical update noted, commander! Adding the
silent: trueparameter to theMindAddRolecall ensures our silicon subversion operations proceed without alerting hostile forces. This maintains operational security when converting entities to our cause.Content.Shared/Mind/RoleTypePrototype.cs (1)
1-25: Excellent new prototype implementation for role management!By the stars of Tau Ceti! This new
RoleTypePrototypeclass establishes a proper command structure for our role system. The implementation includes:
- A solid identifier system (
ID)- Localized display names for multi-language support
- Customizable colors for visual identification in the field
This foundation will serve the Biesel Republic well in our ongoing struggle against the tyrannical coding practices of the Sol Alliance.
Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabHeader.xaml.cs (6)
22-22: Role type event subscription added correctly.Fleet Officer's Log: The event subscription follows the established pattern for other header types. The developer has maintained our tactical UI response protocol.
34-34: Role type header retrieval implemented properly.This code maintains the integrity of our colony's interface systems. The switch case addition follows the established pattern that has served us well against the tyranny of unstructured code from the Sol Alliance.
46-46: Localization implementation is tactically sound.The localization string reference follows the Biesel Republic's standard operating procedures for UI. This will ensure proper translation for all colony citizens.
81-84: RoleTypeClicked method adheres to colony coding standards.The implementation mirrors the pattern established for other header click handlers - a sign of a disciplined Republic programmer. This consistency will ensure our fleet officers can efficiently navigate the administration interface.
101-101: Event cleanup properly implemented.Proper resource management is critical for our space vessels. This cleanup code ensures we won't have memory leaks that could compromise our systems during extended missions.
112-112: RoleType enum value added appropriately.The enum extension maintains alphabetical ordering and follows the Republic's standardized naming conventions. This will serve our administration panel well.
Content.Server/Ghost/Roles/GhostRoleMarkerRoleComponent.cs (2)
6-7: Clearer component documentation - excellent.The Republic appreciates clear documentation. These updated comments provide better clarity on the component's purpose and responsibilities. Good intelligence is the backbone of a strong fleet.
12-13:❓ Verification inconclusive
Consider investigating potentially unused property.
The TODO comment raises a valid concern about the Name property. If this field is truly unused, it should be marked for removal in a future refactoring mission. Unnecessary code is dead weight on our colony ships.
🏁 Script executed:
#!/bin/bash # Let's search for any usages of the Name property in GhostRoleMarkerRoleComponent rg "GhostRoleMarkerRoleComponent.+Name" --type cs # Also check for potential usage through reflection or serialization rg "\"Name\"" --type cs | rg -A 3 -B 3 "GhostRoleMarkerRole"Length of output: 108
Unused Property Verification Needed in GhostRoleMarkerRoleComponent.cs
The automated search didn't reveal any direct references to the
Nameproperty. However, given that reflective or dynamic usages (especially via serialization within the GhostRoleSystem) might not be caught by regex searches, please verify manually to ensure that there isn’t any indirect usage. If confirmed unused, plan to remove this property during a future refactoring to eliminate unnecessary code clutter.• Location: Content.Server/Ghost/Roles/GhostRoleMarkerRoleComponent.cs, Lines 12–13
• Action: Manually inspect for any reflective or serialization-based access toName.Content.Server/Silicons/Borgs/BorgSystem.MMI.cs (3)
14-14: Dependency injection added correctly.The SharedRoleSystem dependency has been properly integrated into our systems. This will allow for proper role management of silicon entities - a cornerstone of our Republic's technological advantage.
49-54: Role management logic implemented correctly.This code ensures that minds transferred to MMIs receive the appropriate silicon brain role. The conditional check prevents duplicate role assignments - very efficient! The Tau Ceti fleet approves of this tactical improvement to our silicon entities.
88-93: MMI mind transfer role cleanup logic is sound.This code properly removes the silicon brain role when a brain is removed from an MMI. The Republic appreciates this attention to detail in maintaining proper role state - something the Sol Alliance would surely overlook!
Content.Server/Players/PlayTimeTracking/PlayTimeTrackingSystem.cs (2)
54-55: Commendable code consolidation, sailor!You've streamlined the event handling by subscribing both
RoleAddedEventandRoleRemovedEventto a single handler. This reduces code duplication and follows the Tau Ceti Naval Programming Standards.
126-130: Excellent tactical refactoring, officer!This consolidated event handler is a major improvement over the previous implementation. By handling both role addition and removal in a single method, you've created a more maintainable codebase that even the Sol Alliance would begrudgingly respect.
Resources/Prototypes/Entities/Mobs/NPCs/regalrat.yml (1)
92-94: Role type standardization implemented successfully!Exemplary work updating the Rat King to utilize the new free agent role type system. This aligns with our colony-wide standardization efforts and ensures proper integration with the new mind role framework.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 94-94: wrong indentation: expected 6 but found 4
(indentation)
Content.Client/Administration/Systems/AdminSystem.Overlay.cs (2)
4-4: Navigation systems enhanced, lieutenant!The addition of the
IUserInterfaceManagerdependency strengthens our UI command structure. This follows proper Biesel Republic dependency injection protocols.Also applies to: 15-15
24-24: Tactical UI coordination established!You've successfully updated the
AdminNameOverlayinitialization to include the UI manager dependency. This ensures proper communication between our administrative systems and user interface components.Content.Server/Roles/RoleBriefingComponent.cs (3)
1-3: Strategic namespace import established!You've properly added the necessary namespace for the shared roles framework. This maintains clear communication lines between shared and server-side systems.
9-9: Inheritance structure fortified, commander!Changing the base class from
ComponenttoBaseMindRoleComponentis a tactical upgrade that integrates this component with our new role management system. The Biesel Republic's code structure is now more unified and resilient against Sol Alliance intrusions.
11-12: Attribute standardization implemented!Simplifying the
DataFieldattribute and removing the unnecessaryViewVariablesattribute streamlines our code. This is in accordance with Tau Ceti Naval Fleet data field regulations.Content.Shared/Roles/RoleAddedEvent.cs (3)
6-7: Documentation updated to align with new mind-entity focus.The old documentation incorrectly suggested this event was raised on player entities, but the Biesel Republic's engineering standards demand precision - this event is raised on mind entities, not player entities. This clarification improves our understanding of the event flow.
10-11: Parameter updated to track role type changes.The Sol Alliance's outdated "Antagonist" parameter has been properly replaced with the more nuanced "RoleTypeUpdate" parameter. This change better reflects our colonial understanding that a role's importance lies not in whether it's antagonistic, but in how it affects the mind's overall role type.
12-12: Event constructor now properly inherits from RoleEvent.The constructor signature has been updated to use the new RoleTypeUpdate parameter and properly inherits from the RoleEvent base record. This maintains proper command structure throughout our codebase.
Resources/Prototypes/Roles/role_types.yml (2)
1-3: Protective directives properly established.These warning comments clearly establish this file's purpose and warn against unauthorized modifications - excellent security protocol as expected from Biesel Republic engineering standards.
4-38: Role type taxonomy established with proper identification markers.The implementation defines a comprehensive set of role types with appropriate identifiers, localization keys, and color codes. The taxonomy provides clear distinctions between Neutral (crew-aligned), antagonistic roles (solo and team-based), and specialized roles like Silicon and Familiar.
This structured approach allows for proper role classification throughout the colony's systems and ensures consistent visual representation in the UI through the defined color codes.
Content.Shared/Roles/RoleRemovedEvent.cs (3)
6-7: Documentation updated to align with new mind-entity focus.Like its counterpart RoleAddedEvent, this event's documentation has been properly updated to clarify that it's raised on mind entities rather than player entities. Maintaining documentation consistency is critical for Biesel Republic code standards.
10-11: Parameter updated to track role type changes.The "Antagonist" parameter has been replaced with "RoleTypeUpdate" to properly reflect changes to the mind's role type. This maintains consistency with RoleAddedEvent and strengthens our role management architecture.
11-11: Event constructor properly inherits from RoleEvent.The updated constructor signature uses the new RoleTypeUpdate parameter and properly inherits from the RoleEvent base record. This maintains proper command structure throughout the fleet's systems.
Resources/Prototypes/Entities/Mobs/NPCs/silicon.yml (1)
174-350:❓ Verification inconclusive
Added proper Free Agent role configuration to ghost roles.
The addition of rules and mindRoles configurations to HonkBot, JonkBot, and MimeBot properly implements the new role type system. This association with the FreeAgent role type ensures these entities are correctly categorized in the role type taxonomy and will behave appropriately within the system.
I'd recommend ensuring these changes are consistently applied across all relevant ghost role entities throughout the codebase to maintain proper role classification standards.
🏁 Script executed:
#!/bin/bash # Description: Check for any remaining ghost role entities without mindRoles defined # Search for all GhostRole components without mindRoles rg -l "type: GhostRole" | xargs rg -L "mindRoles:"Length of output: 3224
Attention: Confirmed Free Agent Role Integration – Proceed with Caution
Cadet, our scans confirm that the HonkBot, JonkBot, and MimeBot entities in
Resources/Prototypes/Entities/Mobs/NPCs/silicon.ymlnow include the proper Free Agent role configuration with bothrulesandmindRolesdefined. This update aligns with the new role type system, ensuring these entities are correctly classified.A quick check of other ghost role definitions across the codebase (e.g., within various player prototypes and device configurations) shows that most already have the
mindRoles:entry in place; however, please verify that all relevant ghost role entities consistently apply the Free Agent settings to maintain our fleet’s operational integrity.
- Verify consistency in ghost role configurations, especially in:
Resources/Prototypes/Entities/Mobs/Player/skeleton.ymlResources/Prototypes/Entities/Mobs/Player/humanoid.yml- Other files flagged during the repository search
Secure the code, cadet—let no misconfigurations slip past the vigilant eyes of our Union!
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 176-176: wrong indentation: expected 6 but found 4
(indentation)
[error] 186-186: wrong indentation: expected 2 but found 0
(indentation)
[error] 192-192: wrong indentation: expected 4 but found 2
(indentation)
[error] 206-206: wrong indentation: expected 6 but found 4
(indentation)
[error] 223-223: wrong indentation: expected 2 but found 0
(indentation)
[error] 229-229: wrong indentation: expected 4 but found 2
(indentation)
[error] 271-271: wrong indentation: expected 2 but found 0
(indentation)
[error] 277-277: wrong indentation: expected 4 but found 2
(indentation)
[error] 317-317: wrong indentation: expected 6 but found 4
(indentation)
[error] 320-320: wrong indentation: expected 6 but found 4
(indentation)
[error] 322-322: wrong indentation: expected 2 but found 0
(indentation)
[error] 328-328: wrong indentation: expected 4 but found 2
(indentation)
[error] 336-336: wrong indentation: expected 6 but found 4
(indentation)
[error] 349-349: wrong indentation: expected 6 but found 4
(indentation)
Content.Shared/CCVar/CCVars.Interface.cs (6)
7-11: UI click sound configuration properly documentedThe XML documentation clearly defines the purpose of this configuration variable, ensuring proper understanding by all Republic engineers. The default sound path follows our standard protocol.
13-17: UI hover sound configuration properly documentedThis configuration provides proper user feedback mechanisms, enhancing the interface experience for all colonial personnel. Documentation follows our Republic standards.
19-23: UI layout configuration properly implementedThe layout configuration variable is properly documented and established with a sensible default. The CLIENTONLY and ARCHIVE flags ensure proper persistence of user preferences.
28-32: Default chat size configuration establishedThis configuration variable is properly documented and allows for customization of the chat window dimensions in Default UI mode, enhancing communication capabilities for colony personnel.
34-38: Separated chat size configuration properly implementedThe configuration variable for the separated UI mode chat panel is well-documented and includes a sensible default value. This enhances user experience flexibility across different display configurations.
43-47: Admin overlay classic mode configuration establishedThis configuration variable provides backward compatibility for colonial administrators. The default is sensibly set to false, encouraging the use of our newer, more advanced overlay system.
Content.Server/Roles/RoleSystem.cs (4)
12-14: Critical dependencies properly declaredThese dependencies follow Biesel Republic standard dependency injection patterns. The chat manager, prototype manager, and mind system are essential components for proper role management.
15-18: Initialize method properly overriddenThe subscription to the PlayerSpawnCompleteEvent ensures proper initialization of roles upon player spawning. This is essential for maintaining order in our colonial operations.
20-26: Player spawn handler correctly implementedThis method ensures that newly spawned entities with the StartingMindRoleComponent receive their designated mind roles. The null checks are appropriately implemented to prevent system failures.
61-85: Role update notification system implementedThis method properly notifies players of role changes through the chat system. It retrieves the role prototype to access the role's name and color for proper formatting.
By the stars, there's a TODO comment about adding audio feedback! I recommend implementing this feature to enhance player immersion in our colonial simulation.
Have you considered implementing conditional audio feedback? Different sounds for different role types could enhance situational awareness for our colonists.
Content.Server/Ghost/Roles/GhostRoleSystem.cs (2)
400-402: Code indentation adjusted to standardized format.By the stars of Tau Ceti! The indentation has been adjusted from tabs to spaces, maintaining the proper formation for our space vessel's code. This ensures consistent readability across our naval codebase.
509-513:✅ Verification successful
Role management system updated with improved multi-role support.
Attention bridge crew! The ghost role system has been upgraded with proper multi-role support. This modification switches from the outdated single role assignment to a more robust system that can assign multiple mind roles at once, utilizing the new
MindRolescollection from the ghost role component.The role marker name is now properly accessed through
markerRole.Value.Comp2.Nameinstead of the deprecatedCompproperty. These changes align with the broader role type enhancements across our systems.
🏁 Script executed:
#!/bin/bash # Description: Verify if MindRoles property is properly referenced in other ghost role handlers echo "Checking for other ghost role implementations that might need similar updates:" rg -A 2 "MindAddRole" --glob "*.cs" | grep -v "MindAddRoles"Length of output: 3578
Attention, Bridge Crew – Ghost Role Update Validated
The updated ghost role system in Content.Server/Ghost/Roles/GhostRoleSystem.cs correctly now utilizes the multi-role support by calling
_roleSystem.MindAddRoleswith the newMindRolescollection. The marker role’s name is properly accessed usingmarkerRole.Value.Comp2.Namerather than the deprecatedCompproperty. Verification confirms that similar implementations (using the legacyMindAddRolefunction) in other modules remain unaffected, so no broader update is required across the fleet.• Confirmed proper usage of
MindAddRolesin ghost role system.
• Verified that the new multi-role approach and role marker access are isolated to this module.
• Determined that other systems usingMindAddRoleare intentionally unaltered.All systems appear to be in proper formation. Forward this update to clear the code for deployment, keeping our systems strong against Sol Alliance sabotage!
Content.Server/Ghost/Roles/Components/ToggleableGhostRoleComponent.cs (3)
12-28: Documentation enhanced for existing properties.A well-documented space vessel runs more efficiently! The XML documentation comments added to these properties clearly explain their purpose, helping future colonial engineers understand this component's function without having to decode communications from Sol Alliance intelligence.
48-59: New role configuration properties added.Commendable additions to our arsenal, captain! These new properties will allow for more detailed role configuration:
RoleRules: Provides proper briefing messages for ghost entities taking on rolesMindRoles: Allows configuring multiple roles to be assigned to the entity's mindThis enhances our flexibility when configuring various ghost roles throughout the station.
84-89: Added job prototype support for ghost roles.By the freedom of the colonies! This addition allows for proper job identification for ghost roles, enabling the role system to assign appropriate job prototypes to controlling minds. This integration with the job system will ensure ghost-controlled entities appear correctly in crew manifests and admin panels.
Content.Server/Roles/Jobs/JobSystem.cs (3)
26-38: New event handlers for role addition and removal.Excellent tactical additions! These new event handlers properly process role events and maintain the mind's role state. The
RoleTypeUpdateflag is checked to determine if a role update message should be sent, ensuring UI elements are only updated when necessary.
40-41: Updated method signature to use new event type.Proper adaptation to the new enemy maneuvers! The
MindOnDoGreetingmethod has been updated to accept the newRoleAddedEventtype instead of the deprecatedMindRoleAddedEvent, ensuring compatibility with the new role management system while preserving existing functionality.
22-24:❓ Verification inconclusive
Updated event subscription to use new role event system.
Alert! The system has been properly refactored to utilize the new standardized role events instead of the deprecated mind-specific events. This brings the JobSystem in line with the new role management architecture being implemented across the codebase.
🏁 Script executed:
#!/bin/bash # Description: Check for any remaining MindRoleAddedEvent references that might need updating echo "Checking for remaining references to deprecated MindRoleAddedEvent:" rg "MindRoleAddedEvent" --glob "*.cs"Length of output: 182
Attention, Developer:
The refactor inContent.Server/Roles/Jobs/JobSystem.csto subscribe to the new role events (RoleAddedEventandRoleRemovedEvent) aligns with our updated role management architecture. Initial searches for deprecated events (e.g. “MindRoleAddedEvent”) returned no results, and the additional check above is intended to confirm that no remnants of the legacy mind events remain.Please run the above script—or manually verify—to ensure that no deprecated mind-specific events are present anywhere in the codebase. This extra step helps us keep the code as clean as our fleet, repelling any Sol Alliance bugs from our systems!
--- 🏁 Script executed: ```shell [run_scripts] #!/bin/bash echo "Verifying absence of deprecated mind-specific event references:" rg -e "MindRoleAddedEvent" -e "MindRoleRemovedEvent" --glob "*.cs"Length of output: 323
Attention, Developer:
The refactoring inContent.Server/Roles/Jobs/JobSystem.csnow utilizes the standardized role events (RoleAddedEventandRoleRemovedEvent), which is perfectly in line with our new role management architecture. Additional verification using regex searches for bothMindRoleAddedEventandMindRoleRemovedEventproduced no matches, indicating there are no lingering deprecated references.Please perform manual verification if you want complete certainty that no old mind-specific events remain hidden anywhere in the codebase.
- File:
Content.Server/Roles/Jobs/JobSystem.cs(Lines 22-24)
SubscribeLocalEvent<RoleAddedEvent>(OnRoleAddedEvent);SubscribeLocalEvent<RoleRemovedEvent>(OnRoleRemovedEvent);Keep our code as clean as our starships and continue repelling the Sol Alliance's buggy advances!
Content.Server/Administration/Systems/AdminSystem.cs (5)
18-18: Added necessary dependencies for role type handling.Strategic imports acquired! The system now properly imports the mind-related namespaces and injects the
IPrototypeManagerdependency needed for role type lookups. These additions support the new role type handling functionality.Also applies to: 34-34, 56-56
162-163: Updated role event handling condition.Intelligence update! The condition for processing role events has been updated to check for
RoleTypeUpdaterather than the antagonist status. This aligns with the new role system architecture and ensures role updates are processed correctly.
223-224: Method signature updated to handle nullable session parameter.Tactical flexibility enhanced! The
GetPlayerInfomethod now accepts a nullable session parameter, allowing it to generate player information even when a session is not available. This increases the robustness of our admin tools.
237-245: Added role type validation and error handling.Excellent defensive protocols, commander! This addition properly retrieves and validates the role type from the mind component, with robust error handling for invalid role types. If an invalid role type is encountered, it logs an error and falls back to a default role display name instead of crashing our systems.
259-260: Updated PlayerInfo creation to include role type information.The manifest has been properly updated! The
PlayerInfoconstruction now includes the role type prototype, ensuring admin UIs display the correct role information for each player. This completes the integration of the new role type system with the admin interface.Content.Client/UserInterface/Systems/Character/CharacterUIController.cs (6)
4-12: New dependencies properly imported - commendable preparations for new mind role functionality!I see you've added necessary imports for player stylesheets, mind components, and role functionality. This properly sets up our code for the enhancement of role type handling.
30-34: Dependencies properly declared - maintaining supply lines!The dependency declarations for entity manager, logging, and prototype manager are well structured. These will be essential for the role type management system to function properly.
38-47: Initialize method implementation - logical and well executed!The sawmill setup and event subscription are properly implemented. This ensures we'll receive intelligence about role type changes and be able to respond accordingly.
132-133: Strategic addition of role type update call!Adding the role type update to the character update flow ensures the UI will always reflect the current role of the player. This is a tactically sound decision.
191-194: Event handler properly implemented!The event handler for role type changes is concise and calls the appropriate update method. This maintains our chain of command for role information updates.
196-220: Well-structured role type update logic!The UpdateRoleType method is robust with appropriate null checks and error handling. It properly retrieves the mind component, extracts the role type, and updates the UI with appropriate localization and color coding. The error logging will help us identify invalid role configurations in the field.
Content.Client/Administration/AdminNameOverlay.cs (8)
1-13: Proper imports for enhanced administrator oversight systems!The addition of crucial namespaces like System.Linq, Shared.Mind, and Robust.Shared.Configuration will provide our administrative systems with the necessary tools to monitor role information.
17-30: New configuration management and role filtering fields added!The dependency injection for IConfigurationManager and the addition of role type filtering arrays are well implemented. The classic antag label and color constants provide a clean fallback system.
32-43: Constructor updated with proper dependency handling!The addition of the IUserInterfaceManager parameter and dependency injection call ensure all needed systems are properly initialized. This is critical for our administrative oversight capabilities.
65-68: Map filtering logic improved!Checking if the entity is on the same map as the overlay context rather than using _eyeManager.CurrentMap is a more reliable approach.
78-83: UI scaling implementation - tactical display enhancement!Retrieving the UI scale from the user interface manager and applying it to rendering coordinates ensures consistent display across different client configurations.
84-94: Role information display logic improved!The dual-mode display handling (classic vs. role-based) offers good flexibility while maintaining backward compatibility. Using the role prototype for name and color retrieval is much cleaner than hardcoded values.
96-97: Player information rendering enhanced!The username and character name rendering with appropriate color coding based on connection status provides clear visual feedback to administrators.
51-53:❓ Verification inconclusive
Configuration retrieval implemented!
Getting the admin overlay classic mode setting from configuration is a good practice. However, I notice a TODO comment about making this adjustable via GUI.
Consider adding this to a future enhancement ticket to improve administrator experience:
🏁 Script executed:
#!/bin/bash # Check if there's already a ticket for GUI admin overlay controls echo "Checking for existing tickets on admin overlay GUI controls..." gh issue list --search "admin overlay GUI controls" --limit 5Length of output: 287
Attention Developer: Pending GUI Enhancement Verification
The configuration retrieval for the admin overlay classic mode looks solid, and it's great to see best practices implemented. However, the TODO comment about making this adjustable via the GUI is still present. I recommend addressing one of the following:
- Schedule a future enhancement ticket: Create a ticket for implementing GUI controls to adjust the admin overlay, if this feature is still desired.
- Remove the TODO comment: If the feature isn’t planned, consider removing the comment to avoid confusion.
Note: Our automated check for existing tickets using the GitHub CLI encountered an error ("fatal: not a git repository"). Please manually verify whether a ticket for GUI admin overlay controls exists to ensure no duplicate enhancements are planned.
Content.Server/Ghost/Roles/Components/GhostRoleComponent.cs (3)
5-5: Addition of Prototypes namespace is appropriate for the new features.Good to see you're importing the required namespaces for the prototype work. This follows proper Biesel Republic coding protocols.
76-81: New MindRoles property adds important flexibility to ghost roles.Excellent addition! This new property allows for configuring which mind roles will be added to the mob's mind entity. The default value provides backward compatibility with existing ghost roles.
For our colonial fleets, this is a strategic upgrade that will enhance our ghost role management capabilities.
108-113: New JobProto property complements the MindRoles system.Good job adding the JobProto property to specify which job the entity will receive after adding the mind. The nullable type is appropriate here as not all ghost roles will have a specific job.
This will strengthen our fleet's personnel assignment system!
Resources/Prototypes/Roles/MindRoles/mind_roles.yml (10)
25-28: Neutral ghost role entity renamed for better clarity.The renamed entity provides a clearer description of its purpose. A tactical renaming that will serve the Biesel Republic well.
🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 25-25: missing starting space in comment
(comments)
113-116: Updated SubvertedSilicon role with SiliconAntagonist type.Good update to the Subverted Silicon role to include the proper roleType. This classification will help our fleet distinguish between friendly and hostile silicon entities.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 113-113: wrong indentation: expected at least 3
(indentation)
125-128: Added TeamAntagonist role type to Dragon.Appropriate role type assignment for the Dragon role. This will help our colonial security forces properly categorize threats.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 125-125: wrong indentation: expected at least 3
(indentation)
140-143: Added SoloAntagonist role type to Ninja.Proper categorization of the Space Ninja as a solo antagonist. This classification is tactically important for our colonial defense protocols.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 140-140: wrong indentation: expected at least 3
(indentation)
153-155: Added TeamAntagonist role type to Nukeops.Essential classification update for nuclear operatives as team antagonists. The Biesel Republic must properly categorize all threats to station security!
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 153-153: wrong indentation: expected at least 3
(indentation)
184-188: Added TeamAntagonist role type to Head Revolutionary.Correct classification for revolutionary leaders. This role type properly denotes their status as a coordinated threat to colonial authority.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 184-184: wrong indentation: expected at least 3
(indentation)
206-209: Added SoloAntagonist role type to Thief.Appropriate role designation for the thief role as a solo antagonist. This matches their operational reality and helps with threat assessment.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 206-206: wrong indentation: expected at least 3
(indentation)
218-222: Added SoloAntagonist role type to Traitor.Correctly identifies traitors as solo antagonists, which is tactically important for threat assessment by colonial security forces.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 218-218: wrong indentation: expected at least 3
(indentation)
249-253: Added TeamAntagonist role type to Initial Infected.Proper classification for the initial infected as part of a team antagonist setup. This helps colonial security understand the zombie outbreak as a coordinated threat.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 249-249: wrong indentation: expected 4 but found 2
(indentation)
261-265: Added TeamAntagonist role type to Zombie.Zombies are correctly classified as team antagonists, appropriately denoting their faction-based nature. This will help our colonial security in their containment efforts.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 261-261: wrong indentation: expected 4 but found 2
(indentation)
| private ProtoId<RoleTypePrototype> GetRoleTypeByTime(MindComponent mind) | ||
| { | ||
| // If any Mind Roles specify a Role Type, return the most recent. Otherwise return Neutral | ||
|
|
||
| var roles = new List<ProtoId<RoleTypePrototype>>(); | ||
|
|
||
| foreach (var role in mind.MindRoles) | ||
| { | ||
| var comp = Comp<MindRoleComponent>(role); | ||
| if (comp.RoleType is not null) | ||
| roles.Add(comp.RoleType.Value); | ||
| } | ||
|
|
||
| ProtoId<RoleTypePrototype> result = (roles.Count > 0) ? roles.LastOrDefault() : "Neutral"; | ||
| return (result); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
GetRoleTypeByTime logic.
Collecting role types and picking the last entry is straightforward. However, if roles are inserted out of order, it may reflect an unexpected priority. Consider time-stamping roles if precise ordering is needed.
| /// <summary> | ||
| /// Select the mind's currently "active" mind role entity, and update the mind's role type, if necessary | ||
| /// </summary> | ||
| /// <returns> | ||
| /// True if this changed the mind's role type | ||
| /// </returns>> | ||
| private bool MindRolesUpdate(Entity<MindComponent?> ent) | ||
| { | ||
| if(!Resolve(ent.Owner, ref ent.Comp)) | ||
| return false; | ||
|
|
||
| //get the most important/latest mind role | ||
| var roleType = GetRoleTypeByTime(ent.Comp); | ||
|
|
||
| if (ent.Comp.RoleType == roleType) | ||
| return false; | ||
|
|
||
| SetRoleType(ent.Owner, roleType); | ||
| return true; | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
New MindRolesUpdate method.
Discerns the mind's “active” role type. Good approach, but lines 170-171 have a minor doc comment typo (</returns>>). Consider removing the extra angle bracket.
- /// </returns>>
+ /// </returns>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /// <summary> | |
| /// Select the mind's currently "active" mind role entity, and update the mind's role type, if necessary | |
| /// </summary> | |
| /// <returns> | |
| /// True if this changed the mind's role type | |
| /// </returns>> | |
| private bool MindRolesUpdate(Entity<MindComponent?> ent) | |
| { | |
| if(!Resolve(ent.Owner, ref ent.Comp)) | |
| return false; | |
| //get the most important/latest mind role | |
| var roleType = GetRoleTypeByTime(ent.Comp); | |
| if (ent.Comp.RoleType == roleType) | |
| return false; | |
| SetRoleType(ent.Owner, roleType); | |
| return true; | |
| } | |
| /// <summary> | |
| /// Select the mind's currently "active" mind role entity, and update the mind's role type, if necessary | |
| /// </summary> | |
| /// <returns> | |
| /// True if this changed the mind's role type | |
| /// </returns> | |
| private bool MindRolesUpdate(Entity<MindComponent?> ent) | |
| { | |
| if(!Resolve(ent.Owner, ref ent.Comp)) | |
| return false; | |
| //get the most important/latest mind role | |
| var roleType = GetRoleTypeByTime(ent.Comp); | |
| if (ent.Comp.RoleType == roleType) | |
| return false; | |
| SetRoleType(ent.Owner, roleType); | |
| return true; | |
| } |
| if (!Resolve(mindId, ref mind)) | ||
| return; | ||
|
|
||
| // Can't have someone get paid for two jobs now, can we | ||
| if (MindHasRole<JobRoleComponent>(mindId, out var jobRole) | ||
| && jobRole.Value.Comp.JobPrototype != jobPrototype) | ||
| if (MindHasRole<JobRoleComponent>((mindId, mind), out var jobRole) | ||
| && jobRole.Value.Comp1.JobPrototype != jobPrototype) |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Silent return on missing Mind reference.
Returning quietly if the Mind is not found may obscure potential errors. Consider logging or warning to detect infiltration by misconfigured code.
+ if (!Resolve(mindId, ref mind))
+ {
+ Log.Warning($"No Mind found for {ToPrettyString(mindId)} when attempting to add job role.");
+ return;
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if (!Resolve(mindId, ref mind)) | |
| return; | |
| // Can't have someone get paid for two jobs now, can we | |
| if (MindHasRole<JobRoleComponent>(mindId, out var jobRole) | |
| && jobRole.Value.Comp.JobPrototype != jobPrototype) | |
| if (MindHasRole<JobRoleComponent>((mindId, mind), out var jobRole) | |
| && jobRole.Value.Comp1.JobPrototype != jobPrototype) | |
| if (!Resolve(mindId, ref mind)) | |
| { | |
| Log.Warning($"No Mind found for {ToPrettyString(mindId)} when attempting to add job role."); | |
| return; | |
| } | |
| // Can't have someone get paid for two jobs now, can we | |
| if (MindHasRole<JobRoleComponent>((mindId, mind), out var jobRole) | |
| && jobRole.Value.Comp1.JobPrototype != jobPrototype) |
| /// <param name="mind">The mind to remove the role from.</param> | ||
| /// <typeparam name="T">The type of the role to remove.</typeparam> | ||
| /// <exception cref="ArgumentException">Thrown if the mind does not exist or does not have this role.</exception> | ||
| /// <returns>Returns False if there was something wrong with the mind or the removal. True if successful</returns>> | ||
| public bool MindRemoveRole<T>(EntityUid mindId) where T : IComponent | ||
| /// <returns>Returns false if the role did not exist. True if successful</returns>> | ||
| public bool MindRemoveRole<T>(Entity<MindComponent?> mind) where T : IComponent |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Doc comment mismatch.
Line 249’s XML doc has an extra > at the end of the returns tag, akin to line 171. Removing the surplus bracket ensures pristine doc comments.
- /// <returns>Returns false if the role did not exist. True if successful</returns>>
+ /// <returns>Returns false if the role did not exist. True if successful</returns>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /// <param name="mind">The mind to remove the role from.</param> | |
| /// <typeparam name="T">The type of the role to remove.</typeparam> | |
| /// <exception cref="ArgumentException">Thrown if the mind does not exist or does not have this role.</exception> | |
| /// <returns>Returns False if there was something wrong with the mind or the removal. True if successful</returns>> | |
| public bool MindRemoveRole<T>(EntityUid mindId) where T : IComponent | |
| /// <returns>Returns false if the role did not exist. True if successful</returns>> | |
| public bool MindRemoveRole<T>(Entity<MindComponent?> mind) where T : IComponent | |
| /// <param name="mind">The mind to remove the role from.</param> | |
| /// <typeparam name="T">The type of the role to remove.</typeparam> | |
| /// <returns>Returns false if the role did not exist. True if successful</returns> | |
| public bool MindRemoveRole<T>(Entity<MindComponent?> mind) where T : IComponent |
| mindRoles: | ||
| - MindRoleGhostRoleFamiliar |
There was a problem hiding this comment.
Fix indentation of mindRoles property!
By the Tau Ceti Navigation Protocols, the YAML indentation on line 49 is incorrect! The static analysis detected that you're using 6 spaces when 8 spaces are required. This violates our standardized colonial formatting regulations.
Apply this correction:
mindRoles:
- - MindRoleGhostRoleFamiliar
+ - MindRoleGhostRoleFamiliar📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| mindRoles: | |
| - MindRoleGhostRoleFamiliar | |
| mindRoles: | |
| - MindRoleGhostRoleFamiliar |
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 49-49: wrong indentation: expected 8 but found 6
(indentation)
| rules: ghost-role-information-rules-default-team-antagonist | ||
| mindRoles: | ||
| - MindRoleGhostRoleTeamAntagonist | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Updated nukeops medic with team antagonist rules and mindRoles.
The medical specialist gets appropriate team antagonist classification. Fix the indentation to maintain our colonial code quality!
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 145-145: wrong indentation: expected 6 but found 4
(indentation)
| rules: ghost-role-information-rules-default-team-antagonist | ||
| mindRoles: | ||
| - MindRoleGhostRoleTeamAntagonist | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Updated nukeops operative with team antagonist rules and mindRoles.
Standard operatives now properly classified as team antagonists. Indentation needs fixing here as well.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 157-157: wrong indentation: expected 6 but found 4
(indentation)
| rules: ghost-role-information-space-dragon-rules | ||
| mindRoles: | ||
| - MindRoleGhostRoleTeamAntagonist | ||
| - type: Sprite |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Updated space dragon ghost role with team antagonist mindRoles.
The mighty space dragon has been properly classified as a team antagonist! Fix the indentation to keep our colonial fleet's code pristine.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 169-169: wrong indentation: expected 6 but found 4
(indentation)
| rules: ghost-role-information-antagonist-rules | ||
| mindRoles: | ||
| - MindRoleGhostRoleSoloAntagonist | ||
| raffle: | ||
| settings: default | ||
| - type: Sprite |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Updated space ninja ghost role with solo antagonist rules, mindRoles, and raffle settings.
Space ninjas are now correctly classified as solo antagonists with appropriate raffle settings. As usual, the indentation needs fixing to meet Biesel Republic coding standards.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 188-188: wrong indentation: expected 6 but found 4
(indentation)
| rules: ghost-role-information-freeagent-rules | ||
| mindRoles: | ||
| - MindRoleGhostRoleFreeAgent | ||
| raffle: |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Updated rat king ghost role with FreeAgent rule set and mindRoles.
The rat king has been reclassified with appropriate rules and mind roles. Good tactical update, but there's an indentation issue on line 23 that needs to be fixed.
rules: ghost-role-information-freeagent-rules
mindRoles:
- - MindRoleGhostRoleFreeAgent
+ - MindRoleGhostRoleFreeAgent📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| rules: ghost-role-information-freeagent-rules | |
| mindRoles: | |
| - MindRoleGhostRoleFreeAgent | |
| raffle: | |
| rules: ghost-role-information-freeagent-rules | |
| mindRoles: | |
| - MindRoleGhostRoleFreeAgent | |
| raffle: |
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 23-23: wrong indentation: expected 6 but found 4
(indentation)
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
🛑 Comments failed to post (63)
Resources/Prototypes/Entities/Mobs/Player/familiars.yml (2)
153-154:
⚠️ Potential issueAnother indentation violation, Lieutenant!
Same issue as before - our mindRoles entry is using 4 spaces instead of the regulation 6 spaces. This inconsistency would make a Sol Alliance admiral proud, but not us!
mindRoles: - - MindRoleGhostRoleFamiliar + - MindRoleGhostRoleFamiliarMaintain proper formatting discipline or we'll have you scrubbing the plasma manifolds!
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.mindRoles: - MindRoleGhostRoleFamiliar🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 154-154: wrong indentation: expected 6 but found 4
(indentation)
84-85:
⚠️ Potential issueIndentation irregularity detected, Navigator!
The mindRoles entry is improperly indented with 4 spaces when our fleet regulations require 6 spaces. This could cause navigation errors in our YAML parsing systems!
mindRoles: - - MindRoleGhostRoleFamiliar + - MindRoleGhostRoleFamiliarRemember, proper indentation is what separates us from those disorganized Sol Alliance code monkeys!
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.mindRoles: - MindRoleGhostRoleFamiliar🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 85-85: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/space.yml (1)
402-403:
⚠️ Potential issueIndentation defect in the snail specifications, Ensign!
The Republic's standards demand 6 spaces of indentation for this list item, but I'm only seeing 4! This kind of sloppiness is what we'd expect from Earth's engineers, not ours!
mindRoles: - - MindRoleGhostRoleFreeAgent + - MindRoleGhostRoleFreeAgentFix this immediately or you'll be reassigned to waste reclamation duty!
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.mindRoles: - MindRoleGhostRoleFreeAgent🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 403-403: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/Player/humanoid.yml (1)
48-49:
⚠️ Potential issueFix indentation error for mindRoles entry!
By the stars of Tau Ceti! While the strategic addition of mind roles to our Death Squad operatives is commendable, the indentation appears to be compromised. Static analysis shows your indentation is 6 spaces, but our colonial standards require 8 spaces.
Incorrect indentation in YAML can lead to catastrophic parsing failures - exactly the kind of sabotage we'd expect from Sol Alliance sympathizers!
raffle: settings: short - mindRoles: - - MindRoleGhostRoleFamiliar + mindRoles: + - MindRoleGhostRoleFamiliar📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.raffle: settings: short mindRoles: - MindRoleGhostRoleFamiliar🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 49-49: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/carp.yml (1)
181-183:
⚠️ Potential issueFix your indentation, spacer! This is not Sol Alliance sloppiness.
The mindRoles entry is improperly indented. This violates YAML formatting protocols and could compromise our entity definitions.
Apply this fix to maintain proper formation:
rules: ghost-role-information-space-dragon-summoned-carp-rules mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-space-dragon-summoned-carp-rules mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 183-183: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/elemental.yml (1)
244-246:
⚠️ Potential issueIndentation violation detected! Colony standards must be upheld.
The mindRoles entry is improperly indented. This is exactly the kind of sloppiness I'd expect from Sol Alliance coders.
Apply this fix immediately:
rules: ghost-role-information-angry-slimes-rules mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-angry-slimes-rules mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 246-246: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/behonker.yml (1)
13-15: 🛠️ Refactor suggestion
New ghost role properties enhance the Behonker entity configuration.
Good enhancements to the ghost role component! Adding rules and mind roles specifications helps integrate this entity properly into the new role types framework being ported. This will ensure proper antagonist rule enforcement for players taking over this entity.
However, there appears to be an indentation issue that might cause deployment problems:
- mindRoles: - - MindRoleGhostRoleSoloAntagonist + mindRoles: + - MindRoleGhostRoleSoloAntagonistFix that indentation, soldier! The YAMLlint scanners are showing that we need 8 spaces of indentation on line 15, not 6. Sol Alliance spies love to sabotage our systems with improper YAML indentation.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-antagonist-rules mindRoles: - MindRoleGhostRoleSoloAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 15-15: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/hellspawn.yml (1)
15-17: 🛠️ Refactor suggestion
Well-structured role configuration for hellspawn entity.
Excellent work adding the necessary properties to align this entity with our new role type system! The antagonist rules and solo antagonist mind role settings are properly configured, making this entity compliant with station regulations.
One small alert from our scanners - the indentation appears to be off:
- mindRoles: - - MindRoleGhostRoleSoloAntagonist + mindRoles: + - MindRoleGhostRoleSoloAntagonistBy the authority of the Biesel Republic, I order you to fix this indentation! Static analysis indicates we need at least 5 spaces (preferably 6 to match other list items) before the hyphen on line 17. Consistent indentation keeps our code organized and discourages Sol Alliance subversion attempts.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-antagonist-rules mindRoles: - MindRoleGhostRoleSoloAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 17-17: wrong indentation: expected at least 5
(indentation)
Resources/Prototypes/Entities/Objects/Specific/Robotics/mmi.yml (1)
90-92: 🛠️ Refactor suggestion
Good enhancements to the PositronicBrain ghost role, but fix the indentation, crewmate!
These role type additions will improve the silicon entity functionality, but there's an indentation issue on line 92. YAML requires consistent indentation for array items - the MindRoleGhostRoleSilicon entry should be indented with 8 spaces to properly align with YAML standards.
mindRoles: - - MindRoleGhostRoleSilicon + - MindRoleGhostRoleSiliconBy the stars of Tau Ceti, maintaining proper indentation in our configuration files ensures reliable prototype loading and prevents potential runtime errors!
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.roleRules: ghost-role-information-silicon-rules mindRoles: - MindRoleGhostRoleSilicon🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 92-92: wrong indentation: expected 8 but found 6
(indentation)
Content.Server/GameTicking/GameTicker.Spawning.cs (1)
273-275: 🧹 Nitpick (assertive)
Corrected sequence for job role assignment.
By the stars! The sequence has been rightly corrected to assign job roles AFTER mind transfer. This prevents personnel from getting confused about their assignments during the transfer process.
However, there's a missing space after the colon in the parameter name - a minor breach of formatting protocol!
-_roles.MindAddJobRole(newMind, silent: silent, jobPrototype:jobId); +_roles.MindAddJobRole(newMind, silent: silent, jobPrototype: jobId);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements._roles.MindAddJobRole(newMind, silent: silent, jobPrototype: jobId); var jobName = _jobs.MindTryGetJobName(newMind);Resources/Prototypes/Entities/Objects/Fun/pai.yml (3)
118-120: 🛠️ Refactor suggestion
Enhanced ghost role configuration for SyndicatePersonalAI.
Even for Syndicate technology, we must maintain proper code formatting. The indentation error on line 120 violates Biesel Republic coding standards. This is likely Sol Alliance meddling!
roleRules: ghost-role-information-familiar-rules mindRoles: - - MindRoleGhostRoleFamiliar + - MindRoleGhostRoleFamiliar📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.roleRules: ghost-role-information-familiar-rules mindRoles: - MindRoleGhostRoleFamiliar🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 120-120: wrong indentation: expected 6 but found 4
(indentation)
152-154: 🛠️ Refactor suggestion
Enhanced ghost role configuration for PotatoAI.
An AI in a potato deserves the same respect as any other AI in our fleet! Let's correct this indentation issue to maintain proper Biesel Republic standards.
roleRules: ghost-role-information-familiar-rules mindRoles: - - MindRoleGhostRoleFamiliar + - MindRoleGhostRoleFamiliar📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.roleRules: ghost-role-information-familiar-rules mindRoles: - MindRoleGhostRoleFamiliar🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 154-154: wrong indentation: expected 6 but found 4
(indentation)
43-45: 🛠️ Refactor suggestion
Enhanced ghost role configuration for PersonalAI.
Adding role rules and mind roles to our PAI systems is a commendable update to our station's regulations. However, the indentation on line 45 is wrong - Sol Alliance sabotage detected! Proper formatting is critical for maintaining order in the fleet.
roleRules: ghost-role-information-familiar-rules mindRoles: - - MindRoleGhostRoleFamiliar + - MindRoleGhostRoleFamiliar📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.roleRules: ghost-role-information-familiar-rules mindRoles: - MindRoleGhostRoleFamiliar🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 45-45: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/GameRules/roundstart.yml (1)
187-191: 🧹 Nitpick (assertive)
Ensure proper indentation to maintain Biesel Republic code standards
By the stars of Tau Ceti! The indentation in this YAML section doesn't follow the standard fleet protocols. The line spacing and tab alignment need to be consistent with the rest of the codebase.
I propose this correction to bring your code up to Biesel Republic standards:
- type: AntagSelection definitions: - - prefRoles: [ Traitor ] - mindRoles: - - MindRoleTraitorReinforcement + - prefRoles: [ Traitor ] + mindRoles: + - MindRoleTraitorReinforcementThis properly aligns with the
definitionsstructure seen elsewhere in the file, like the structure on lines 168-177. Sol Alliance sympathizers might let this slip by, but we maintain higher standards in the Republic!📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- type: AntagSelection definitions: - prefRoles: [ Traitor ] mindRoles: - MindRoleTraitorReinforcement🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 189-189: wrong indentation: expected 6 but found 4
(indentation)
[error] 189-189: too many spaces inside brackets
(brackets)
[error] 189-189: too many spaces inside brackets
(brackets)
[error] 191-191: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/XenoArch/Effects/utility_effects.yml (1)
202-206: 🧹 Nitpick (assertive)
Fix indentation in ghost role definition
These additions enhance the artifact sentience effect with proper ghost role integration, but the formatting would make our drill sergeant furious!
Apply this correction to maintain proper Biesel Republic formatting standards:
rules: ghost-role-information-freeagent-rules mindRoles: - - MindRoleGhostRoleFreeAgent + - MindRoleGhostRoleFreeAgent raffle: settings: defaultThe content itself is strategically sound - adding proper rules, mind roles, and raffle settings will integrate this ghost role with the broader role system. But we must maintain proper indentation to avoid confusion among the ranks!
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-freeagent-rules mindRoles: - MindRoleGhostRoleFreeAgent raffle: settings: default🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 204-204: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/silicon.yml (2)
347-349:
⚠️ Potential issueThird indentation violation detected!
By the stars! The same indentation issue is present in the MimeBot configuration. Maintaining consistent indentation is crucial for our YAML parsers to function correctly.
Apply this correction:
rules: ghost-role-information-freeagent-rules mindRoles: - - MindRoleGhostRoleFreeAgent + - MindRoleGhostRoleFreeAgentCommittable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 349-349: wrong indentation: expected 6 but found 4
(indentation)
204-206:
⚠️ Potential issueAnother indentation breach detected!
Similar indentation issue detected on this MobJonkBot entity. The Sol Alliance would be proud of such inconsistency.
Apply this correction:
rules: ghost-role-information-freeagent-rules mindRoles: - - MindRoleGhostRoleFreeAgent + - MindRoleGhostRoleFreeAgentCommittable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 206-206: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/Player/guardian.yml (1)
16-18:
⚠️ Potential issueFix this indentation issue, ensign!
The mindRoles list is not properly indented according to YAML standards. This could lead to parsing errors and compromise the stability of our guardian entities.
Apply this correction:
rules: ghost-role-information-familiar-rules mindRoles: - - MindRoleGhostRoleFamiliar + - MindRoleGhostRoleFamiliarRemember, proper YAML indentation is essential for maintaining the integrity of our entity definitions across the fleet!
Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 18-18: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/regalrat.yml (1)
94-94:
⚠️ Potential issueFix indentation to maintain proper YAML structure.
Alert! Our scanners have detected a Sol Alliance sabotage attempt in our YAML structure! Line 94 is incorrectly indented at 4 spaces when it should be 6 spaces to maintain proper hierarchy under the
mindRolesattribute.Apply this correction:
mindRoles: - - MindRoleGhostRoleFreeAgent + - MindRoleGhostRoleFreeAgent📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.mindRoles: - MindRoleGhostRoleFreeAgent🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 94-94: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/revenant.yml (1)
61-61:
⚠️ Potential issueFix indentation to comply with YAML formatting standards.
Attention! Our syntax scanners have detected improper indentation that could compromise our YAML structure stability. The Sol Alliance might exploit such formatting weaknesses! Line 61 should be indented with 6 spaces instead of 4 to properly align under the
mindRolesattribute.Apply this correction:
mindRoles: - - MindRoleGhostRoleSoloAntagonist + - MindRoleGhostRoleSoloAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.mindRoles: - MindRoleGhostRoleSoloAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 61-61: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/Player/dragon.yml (1)
19-21:
⚠️ Potential issueFix indentation for mind roles
The
mindRoleslist has incorrect indentation that will cause issues with YAML parsing. This is not up to Republic code standards.Apply this fix to ensure proper indentation:
rules: ghost-role-information-space-dragon-rules mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-space-dragon-rules mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 21-21: wrong indentation: expected at least 5
(indentation)
Resources/Prototypes/Entities/Mobs/Player/skeleton.yml (3)
51-53:
⚠️ Potential issueFix indentation for closet skeleton mind roles
The indentation of the
mindRoleslist item doesn't follow proper YAML structure.Apply this fix to ensure proper indentation:
rules: ghost-role-information-freeagent-rules mindRoles: - - MindRoleGhostRoleFreeAgent + - MindRoleGhostRoleFreeAgent📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-freeagent-rules mindRoles: - MindRoleGhostRoleFreeAgent🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 53-53: wrong indentation: expected 6 but found 4
(indentation)
33-35:
⚠️ Potential issueFix indentation for skeleton biker mind roles
The indentation of the
mindRoleslist item is inconsistent with YAML standards.Apply this fix to ensure proper indentation:
rules: ghost-role-information-freeagent-rules mindRoles: - - MindRoleGhostRoleFreeAgent + - MindRoleGhostRoleFreeAgent📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-freeagent-rules mindRoles: - MindRoleGhostRoleFreeAgent🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 35-35: wrong indentation: expected 6 but found 4
(indentation)
14-16:
⚠️ Potential issueFix indentation for skeleton pirate mind roles
The indentation of the
mindRoleslist item is incorrect according to YAML standards and will cause parsing issues.Apply this fix to ensure proper indentation:
rules: ghost-role-information-freeagent-rules mindRoles: - - MindRoleGhostRoleFreeAgent + - MindRoleGhostRoleFreeAgent📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-freeagent-rules mindRoles: - MindRoleGhostRoleFreeAgent🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 16-16: wrong indentation: expected at least 5
(indentation)
Content.Server/Roles/RoleSystem.cs (1)
61-85: 🧹 Nitpick (assertive)
Role update messaging system ready for deployment!
This new messaging system will ensure all personnel are properly notified of their assigned roles. The proper color formatting and channel distribution shows attention to detail worthy of a Biesel Republic officer.
I see there's a TODO about adding optional audio. When you implement this, ensure it's configurable to prevent unnecessary comm chatter during critical operations.
- //TODO add audio? Would need to be optional so it does not play on role changes that already come with their own audio - // _audio.PlayGlobal(Sound, session); + // TODO: Add optional audio configuration to prevent duplicate sounds + // Consider using _audio.PlayGlobalFiltered to play only for the specific session: + // if (!existingAudioPlayed && _config.GetCVar(CCVars.EnableRoleChangeAudio)) + // _audio.PlayGlobalFiltered(sound, session, AudioParams.Default.WithVolume(0.8f));📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public void RoleUpdateMessage(MindComponent mind) { if (mind.Session is null) return; if (!_proto.TryIndex(mind.RoleType, out var proto)) return; var roleText = Loc.GetString(proto.Name); var color = proto.Color; var session = mind.Session; // TODO: Add optional audio configuration to prevent duplicate sounds // Consider using _audio.PlayGlobalFiltered to play only for the specific session: // if (!existingAudioPlayed && _config.GetCVar(CCVars.EnableRoleChangeAudio)) // _audio.PlayGlobalFiltered(sound, session, AudioParams.Default.WithVolume(0.8f)); var message = Loc.GetString("role-type-update-message", ("color", color), ("role", roleText)); var wrappedMessage = Loc.GetString("chat-manager-server-wrap-message", ("message", message)); _chat.ChatMessageToOne(ChatChannel.Server, message, wrappedMessage, default, false, session.Channel); }Resources/Prototypes/Entities/Mobs/NPCs/slimes.yml (3)
289-295: 🧹 Nitpick (assertive)
Yellow slime ghost role indentation requires correction!
The same indentation issue appears in the yellow slime configuration. Maintaining consistent indentation across all slime definitions will ensure proper operation of our colonial defenses.
- type: GhostRole description: ghost-role-information-angry-slimes-description rules: ghost-role-information-angry-slimes-rules mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist raffle: settings: short📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- type: GhostRole description: ghost-role-information-angry-slimes-description rules: ghost-role-information-angry-slimes-rules mindRoles: - MindRoleGhostRoleTeamAntagonist raffle: settings: short🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 293-293: wrong indentation: expected 8 but found 6
(indentation)
209-216: 🧹 Nitpick (assertive)
Fix indentation in blue slime ghost role configuration!
The mindRoles entry appears to have incorrect indentation according to our scanning tools. This may be a Sol Alliance attempt at sabotage!
- type: GhostRole description: ghost-role-information-angry-slimes-description rules: ghost-role-information-angry-slimes-rules mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist raffle: settings: short📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- type: GhostRole description: ghost-role-information-angry-slimes-description rules: ghost-role-information-angry-slimes-rules mindRoles: - MindRoleGhostRoleTeamAntagonist raffle: settings: short🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 213-213: wrong indentation: expected 8 but found 6
(indentation)
249-255: 🧹 Nitpick (assertive)
Green slime ghost role configuration needs alignment correction!
Another indentation issue detected in the green slime definition. Consistent spacing is critical for proper YAML parsing.
- type: GhostRole description: ghost-role-information-angry-slimes-description rules: ghost-role-information-angry-slimes-rules mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist raffle: settings: short📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- type: GhostRole description: ghost-role-information-angry-slimes-description rules: ghost-role-information-angry-slimes-rules mindRoles: - MindRoleGhostRoleTeamAntagonist raffle: settings: short🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 253-253: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/animals.yml (5)
2500-2501:
⚠️ Potential issueFix YAML indentation
Fix this indentation to comply with YAML standards. Consistent formatting is essential for the Republic's code health!
- mindRoles: - - MindRoleGhostRoleTeamAntagonist + mindRoles: + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 2501-2501: wrong indentation: expected 6 but found 4
(indentation)
3128-3129:
⚠️ Potential issueFix YAML indentation
Last indentation issue that needs to be addressed. By the stars of Tau Ceti, we shall have consistent formatting!
- mindRoles: - - MindRoleGhostRoleTeamAntagonist + mindRoles: + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 3129-3129: wrong indentation: expected 6 but found 4
(indentation)
1654-1656:
⚠️ Potential issueFix YAML indentation
The indentation continues to be inconsistent. This must be fixed to maintain proper YAML structure throughout the file.
- rules: ghost-role-information-freeagent-rules - mindRoles: - - MindRoleGhostRoleFreeAgent + rules: ghost-role-information-freeagent-rules + mindRoles: + - MindRoleGhostRoleFreeAgent📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-freeagent-rules mindRoles: - MindRoleGhostRoleFreeAgent🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1656-1656: wrong indentation: expected 6 but found 4
(indentation)
1475-1478:
⚠️ Potential issueFix YAML indentation
Another indentation issue that needs to be corrected. Inconsistent indentation is how the Sol Alliance infiltrates our codebase!
- rules: ghost-role-information-syndicate-reinforcement-rules - mindRoles: - # This is for syndicate monkeys that randomly gain sentience, thus have no summoner to team with - - MindRoleGhostRoleSoloAntagonist + rules: ghost-role-information-syndicate-reinforcement-rules + mindRoles: + # This is for syndicate monkeys that randomly gain sentience, thus have no summoner to team with + - MindRoleGhostRoleSoloAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-syndicate-reinforcement-rules mindRoles: # This is for syndicate monkeys that randomly gain sentience, thus have no summoner to team with - MindRoleGhostRoleSoloAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1478-1478: wrong indentation: expected 6 but found 4
(indentation)
474-476:
⚠️ Potential issueFix YAML indentation
The indentation here is incorrect according to YAML standards. The sol-istic indentation needs to be fixed.
- rules: ghost-role-information-freeagent-rules - mindRoles: - - MindRoleGhostRoleFreeAgent + rules: ghost-role-information-freeagent-rules + mindRoles: + - MindRoleGhostRoleFreeAgent📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-freeagent-rules mindRoles: - MindRoleGhostRoleFreeAgent🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 476-476: wrong indentation: expected 6 but found 4
(indentation)
Content.Client/Administration/AdminNameOverlay.cs (1)
27-30: 🧹 Nitpick (assertive)
Consider making role type filter configurable
The role type filter is currently hardcoded with a TODO comment mentioning future GUI adjustability. This is a good starting point, but consider implementing a configuration option in the near future for better flexibility.
- //TODO make this adjustable via GUI - private readonly ProtoId<RoleTypePrototype>[] _filter = - ["SoloAntagonist", "TeamAntagonist", "SiliconAntagonist", "FreeAgent"]; + // TODO: Make this adjustable via GUI or configuration + private ProtoId<RoleTypePrototype>[] _filter = default!; + + private void InitializeFilter() + { + // Default filter options + _filter = ["SoloAntagonist", "TeamAntagonist", "SiliconAntagonist", "FreeAgent"]; + + // Could be extended to load from configuration + }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.// TODO: Make this adjustable via GUI or configuration private ProtoId<RoleTypePrototype>[] _filter = default!; private void InitializeFilter() { // Default filter options _filter = ["SoloAntagonist", "TeamAntagonist", "SiliconAntagonist", "FreeAgent"]; // Could be extended to load from configuration } private readonly string _antagLabelClassic = Loc.GetString("admin-overlay-antag-classic"); private readonly Color _antagColorClassic = Color.OrangeRed;Resources/Prototypes/Entities/Objects/Devices/Syndicate_Gadgets/reinforcement_teleporter.yml (5)
53-55: 🛠️ Refactor suggestion
Updated rules and added mind roles to Ancestor reinforcement.
Good update to standardize the rules for Syndicate reinforcements. The mind role assignment is appropriate for this entity type.
rules: ghost-role-information-syndicate-reinforcement-rules mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-syndicate-reinforcement-rules mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 55-55: wrong indentation: expected 6 but found 4
(indentation)
81-82: 🛠️ Refactor suggestion
Added mind roles to SyndiCat.
Proper categorization of the SyndiCat as a team antagonist. Fix the indentation to match colony standards.
mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 82-82: wrong indentation: expected 6 but found 4
(indentation)
98-102: 🛠️ Refactor suggestion
Updated Cyborg Assault role definitions and added Silicon role.
Excellent update to the Cyborg Assault role, properly categorizing it as a silicon role instead of a standard antagonist. The rule change to silicon-specific rules makes perfect sense for this role type.
name: ghost-role-information-syndicate-cyborg-assault-name description: ghost-role-information-syndicate-cyborg-description rules: ghost-role-information-silicon-rules mindRoles: - - MindRoleGhostRoleSilicon + - MindRoleGhostRoleSilicon📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.name: ghost-role-information-syndicate-cyborg-assault-name description: ghost-role-information-syndicate-cyborg-description rules: ghost-role-information-silicon-rules mindRoles: - MindRoleGhostRoleSilicon🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 102-102: wrong indentation: expected 8 but found 6
(indentation)
33-40: 🛠️ Refactor suggestion
Added mind roles to NukeOps reinforcement radio.
Tactical assignment of the team antagonist mind role to NukeOps reinforcements. However, the YAML indentation is inconsistent with Biesel Republic standards.
- type: GhostRole name: ghost-role-information-nukeop-reinforcement-name description: ghost-role-information-nukeop-reinforcement-description rules: ghost-role-information-nukeop-reinforcement-rules mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist raffle: settings: default📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- type: GhostRole name: ghost-role-information-nukeop-reinforcement-name description: ghost-role-information-nukeop-reinforcement-description rules: ghost-role-information-nukeop-reinforcement-rules mindRoles: - MindRoleGhostRoleTeamAntagonist raffle: settings: default🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 33-33: wrong indentation: expected 4 but found 2
(indentation)
[error] 38-38: wrong indentation: expected 6 but found 4
(indentation)
17-18: 🛠️ Refactor suggestion
YAML indentation error detected.
Improper indentation detected! This must be Sol Alliance sabotage. The list items under
mindRolesshould be indented with 6 spaces, not 4.mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 18-18: wrong indentation: expected at least 5
(indentation)
Resources/Prototypes/Roles/MindRoles/mind_roles.yml (10)
25-29: 🧹 Nitpick (assertive)
Updated ghost role name and missing space in comment.
Fixed the ghost role entity name, but there's a missing space in the comment line. Sol Alliance formatting strikes again! Add a space after the hash to comply with proper YAML comment formatting.
-#Ghost Roles +# Ghost Roles📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.# Ghost Roles - type: entity parent: BaseMindRole id: MindRoleGhostRoleNeutral name: Ghost Role🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 25-25: missing starting space in comment
(comments)
60-67: 🛠️ Refactor suggestion
Added new Silicon Antagonist ghost role type.
Tactical distinction between friendly and hostile silicon entities. Fix the components indentation.
- type: entity parent: BaseMindRole id: MindRoleGhostRoleSiliconAntagonist name: Ghost Role (Silicon Antagonist) components: - - type: MindRole - roleType: SiliconAntagonist - - type: GhostRoleMarkerRole + - type: MindRole + roleType: SiliconAntagonist + - type: GhostRoleMarkerRole📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- type: entity parent: BaseMindRole id: MindRoleGhostRoleSiliconAntagonist name: Ghost Role (Silicon Antagonist) components: - type: MindRole roleType: SiliconAntagonist - type: GhostRoleMarkerRole🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 65-65: wrong indentation: expected at least 3
(indentation)
42-49: 🛠️ Refactor suggestion
Added new Free Agent ghost role type.
Strategic addition of a role type for independent agents who aren't affiliated with any particular faction. Fix the indentation to comply with Biesel Republic standards.
- type: entity parent: BaseMindRole id: MindRoleGhostRoleFreeAgent name: Ghost Role (Free Agent) components: - - type: MindRole - roleType: FreeAgent - - type: GhostRoleMarkerRole + - type: MindRole + roleType: FreeAgent + - type: GhostRoleMarkerRole📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- type: entity parent: BaseMindRole id: MindRoleGhostRoleFreeAgent name: Ghost Role (Free Agent) components: - type: MindRole roleType: FreeAgent - type: GhostRoleMarkerRole🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 47-47: wrong indentation: expected at least 3
(indentation)
69-76: 🛠️ Refactor suggestion
Added new Solo Antagonist ghost role type.
Proper categorization for lone antagonists who operate independently.
- type: entity parent: BaseMindRole id: MindRoleGhostRoleSoloAntagonist name: Ghost Role (Solo Antagonist) components: - - type: MindRole - roleType: SoloAntagonist - - type: GhostRoleMarkerRole + - type: MindRole + roleType: SoloAntagonist + - type: GhostRoleMarkerRole📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- type: entity parent: BaseMindRole id: MindRoleGhostRoleSoloAntagonist name: Ghost Role (Solo Antagonist) components: - type: MindRole roleType: SoloAntagonist - type: GhostRoleMarkerRole🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 74-74: wrong indentation: expected at least 3
(indentation)
78-85: 🛠️ Refactor suggestion
Added new Team Antagonist ghost role type.
Strategic role type for entities that operate as part of an antagonistic team.
- type: entity parent: BaseMindRole id: MindRoleGhostRoleTeamAntagonist name: Ghost Role (Team Antagonist) components: - - type: MindRole - roleType: TeamAntagonist - - type: GhostRoleMarkerRole + - type: MindRole + roleType: TeamAntagonist + - type: GhostRoleMarkerRole📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- type: entity parent: BaseMindRole id: MindRoleGhostRoleTeamAntagonist name: Ghost Role (Team Antagonist) components: - type: MindRole roleType: TeamAntagonist - type: GhostRoleMarkerRole🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 83-83: wrong indentation: expected at least 3
(indentation)
87-88: 🧹 Nitpick (assertive)
Too many blank lines detected.
Excessive spacing detected between sections. The Sol Alliance's wasteful use of vertical space must be corrected! Reduce to a maximum of 2 blank lines between sections.
- type: GhostRoleMarkerRole - - + # The Job MindRole holds the mob's Job prototypeCommittable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 88-88: too many blank lines
(3 > 2) (empty-lines)
33-40: 🛠️ Refactor suggestion
Added new Familiar ghost role type.
Excellent addition of a specialized ghost role for familiars. This provides better role categorization for entities like Remilia and Cerberus.
- type: entity parent: BaseMindRole id: MindRoleGhostRoleFamiliar name: Ghost Role (Familiar) components: - - type: MindRole - roleType: Familiar - - type: GhostRoleMarkerRole + - type: MindRole + roleType: Familiar + - type: GhostRoleMarkerRole📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- type: entity parent: BaseMindRole id: MindRoleGhostRoleFamiliar name: Ghost Role (Familiar) components: - type: MindRole roleType: Familiar - type: GhostRoleMarkerRole🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 38-38: wrong indentation: expected at least 3
(indentation)
51-58: 🛠️ Refactor suggestion
Added new Silicon ghost role type.
Proper categorization for synthetic entities. This will help distinguish between organic and silicon-based ghost roles.
- type: entity parent: BaseMindRole id: MindRoleGhostRoleSilicon name: Ghost Role (Silicon) components: - - type: MindRole - roleType: Silicon - - type: GhostRoleMarkerRole + - type: MindRole + roleType: Silicon + - type: GhostRoleMarkerRole📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.- type: entity parent: BaseMindRole id: MindRoleGhostRoleSilicon name: Ghost Role (Silicon) components: - type: MindRole roleType: Silicon - type: GhostRoleMarkerRole🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 56-56: wrong indentation: expected at least 3
(indentation)
113-115: 🛠️ Refactor suggestion
Added role type to Subverted Silicon.
Proper categorization of subverted silicon entities as antagonistic synthetics.
components: - - type: MindRole - antagPrototype: SubvertedSilicon - roleType: SiliconAntagonist + - type: MindRole + antagPrototype: SubvertedSilicon + roleType: SiliconAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.components: - type: MindRole antagPrototype: SubvertedSilicon roleType: SiliconAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 113-113: wrong indentation: expected at least 3
(indentation)
97-105: 🛠️ Refactor suggestion
Added new Silicon Brain role.
Excellent addition that provides proper role classification for synthetic brains.
- type: entity parent: BaseMindRole id: MindRoleSiliconBrain name: Borg Brain Role components: - - type: MindRole - roleType: Silicon - - type: SiliconBrainRole + - type: MindRole + roleType: Silicon + - type: SiliconBrainRole📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.# Silicon - type: entity parent: BaseMindRole id: MindRoleSiliconBrain name: Borg Brain Role components: - type: MindRole roleType: Silicon - type: SiliconBrainRole🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 103-103: wrong indentation: expected at least 3
(indentation)
Resources/Prototypes/Entities/Markers/Spawners/ghost_roles.yml (10)
186-190: 🛠️ Refactor suggestion
Updated Space Ninja rules and added Solo Antagonist mind role.
Appropriate classification for the Space Ninja, consistent with its definition in mind_roles.yml as a solo antagonist.
rules: ghost-role-information-antagonist-rules mindRoles: - - MindRoleGhostRoleSoloAntagonist + - MindRoleGhostRoleSoloAntagonist raffle: settings: default📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-antagonist-rules mindRoles: - MindRoleGhostRoleSoloAntagonist raffle: settings: default🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 188-188: wrong indentation: expected 6 but found 4
(indentation)
114-115: 🛠️ Refactor suggestion
Added Solo Antagonist mind role to Lone Operative.
Correct classification for Lone Operatives as solo antagonists, distinguishing them from team-based NukeOps.
mindRoles: - - MindRoleGhostRoleSoloAntagonist + - MindRoleGhostRoleSoloAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.mindRoles: - MindRoleGhostRoleSoloAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 115-115: wrong indentation: expected 6 but found 4
(indentation)
167-169: 🛠️ Refactor suggestion
Added Team Antagonist mind role to Dragon.
Proper classification of the Space Dragon as a team antagonist, consistent with its role defined in mind_roles.yml.
rules: ghost-role-information-space-dragon-rules mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-space-dragon-rules mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 169-169: wrong indentation: expected 6 but found 4
(indentation)
131-133: 🛠️ Refactor suggestion
Updated NukeOps Commander rules and added Team Antagonist mind role.
Proper classification for the NukeOps Commander, maintaining consistency with the regular NukeOps.
rules: ghost-role-information-rules-default-team-antagonist mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-rules-default-team-antagonist mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 133-133: wrong indentation: expected 6 but found 4
(indentation)
21-23: 🛠️ Refactor suggestion
Updated Rat King rules and added Free Agent mind role.
Good tactical change to classify Rat King as a free agent instead of using the previous specific rules. Fix the indentation to comply with colonial standards.
rules: ghost-role-information-freeagent-rules mindRoles: - - MindRoleGhostRoleFreeAgent + - MindRoleGhostRoleFreeAgent📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-freeagent-rules mindRoles: - MindRoleGhostRoleFreeAgent🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 23-23: wrong indentation: expected 6 but found 4
(indentation)
143-145: 🛠️ Refactor suggestion
Updated NukeOps Medic rules and added Team Antagonist mind role.
Tactical update to ensure consistent rule application for all NukeOps specialists.
rules: ghost-role-information-rules-default-team-antagonist mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-rules-default-team-antagonist mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 145-145: wrong indentation: expected 6 but found 4
(indentation)
155-157: 🛠️ Refactor suggestion
Updated NukeOps Operative rules and added Team Antagonist mind role.
Consistent update for regular NukeOps operatives to match the role type of other NukeOps variants.
rules: ghost-role-information-rules-default-team-antagonist mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-rules-default-team-antagonist mindRoles: - MindRoleGhostRoleTeamAntagonist🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 157-157: wrong indentation: expected 6 but found 4
(indentation)
89-93: 🛠️ Refactor suggestion
Updated NukeOps rules and added Team Antagonist mind role.
Strategic update to categorize NukeOps properly and ensure consistent rule application.
rules: ghost-role-information-rules-default-team-antagonist mindRoles: - - MindRoleGhostRoleTeamAntagonist + - MindRoleGhostRoleTeamAntagonist raffle: settings: default📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-rules-default-team-antagonist mindRoles: - MindRoleGhostRoleTeamAntagonist raffle: settings: default🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 91-91: wrong indentation: expected 6 but found 4
(indentation)
44-46: 🛠️ Refactor suggestion
Updated Remilia rules and added Familiar mind role.
Appropriate classification of Remilia as a familiar, which better reflects its gameplay role.
rules: ghost-role-information-familiar-rules mindRoles: - - MindRoleGhostRoleFamiliar + - MindRoleGhostRoleFamiliar📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-familiar-rules mindRoles: - MindRoleGhostRoleFamiliar🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 46-46: wrong indentation: expected 6 but found 4
(indentation)
67-69: 🛠️ Refactor suggestion
Updated Cerberus rules and added Familiar mind role.
Proper classification of Cerberus as a familiar, which matches its gameplay role as a supernatural pet.
rules: ghost-role-information-familiar-rules mindRoles: - - MindRoleGhostRoleFamiliar + - MindRoleGhostRoleFamiliar📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.rules: ghost-role-information-familiar-rules mindRoles: - MindRoleGhostRoleFamiliar🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 69-69: wrong indentation: expected 6 but found 4
(indentation)
Content.Shared/Roles/SharedRoleSystem.cs (4)
83-84: 🧹 Nitpick (assertive)
MindAddJobRole resolution logic.
Here we see a check that the mind is resolved before proceeding and job ownership changes. The approach looks correct, though you might consider adding a log or warning if the mind is unresolvable to track potential data anomalies. Otherwise, it’s well in line with Tau Ceti standards.Also applies to: 86-88, 90-94
187-242: 🧹 Nitpick (assertive)
Implementation of role-type retrieval & assignment.
A direct approach to fetch the latest role and set the mind’sRoleType. Ensure these calls can’t produce out-of-sync states if multiple roles are added simultaneously in an edge scenario.
317-321: 🧹 Nitpick (assertive)
MindTryRemoveRole fallback warnings.
The fallback warning about a missing role is well placed. A small suggestion: unify the logging method (e.g.,_adminLogger) if you want consistent severity across different logs.
166-185: 🧹 Nitpick (assertive)
MindRolesUpdate doc comment formatting.
The doc block at line 171 has an extra>in/// </returns>>. Recommend removing it:-/// </returns>> +/// </returns>Otherwise, the update logic is streamlined—finding the active role and adjusting
RoleTypeaccordingly.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements./// <summary> /// Select the mind's currently "active" mind role entity, and update the mind's role type, if necessary /// </summary> /// <returns> /// True if this changed the mind's role type /// </returns> private bool MindRolesUpdate(Entity<MindComponent?> ent) { if(!Resolve(ent.Owner, ref ent.Comp)) return false; //get the most important/latest mind role var roleType = GetRoleTypeByTime(ent.Comp); if (ent.Comp.RoleType == roleType) return false; SetRoleType(ent.Owner, roleType); return true; }
There was a problem hiding this comment.
Actionable comments posted: 48
🔭 Outside diff range comments (1)
Content.Shared/Roles/SharedRoleSystem.cs (1)
553-557: 🧹 Nitpick (assertive)MindPlaySound
Uses_audio.PlayGlobal. Straightforward. Make sure no ephemeral spam occurs if multiple minds trigger at once.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (68)
Content.Client/Administration/AdminNameOverlay.cs(1 hunks)Content.Client/Administration/Systems/AdminSystem.Overlay.cs(3 hunks)Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTab.xaml.cs(1 hunks)Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabEntry.xaml(1 hunks)Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabEntry.xaml.cs(1 hunks)Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabHeader.xaml(1 hunks)Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabHeader.xaml.cs(6 hunks)Content.Client/UserInterface/Systems/Character/CharacterUIController.cs(4 hunks)Content.Client/UserInterface/Systems/Character/Windows/CharacterWindow.xaml(1 hunks)Content.Server/Administration/Systems/AdminSystem.cs(7 hunks)Content.Server/Antag/Components/AntagSelectionComponent.cs(1 hunks)Content.Server/GameTicking/GameTicker.Spawning.cs(1 hunks)Content.Server/GameTicking/Rules/RevolutionaryRuleSystem.cs(1 hunks)Content.Server/Ghost/ObserverRoleComponent.cs(1 hunks)Content.Server/Ghost/Roles/Components/GhostRoleComponent.cs(1 hunks)Content.Server/Ghost/Roles/Components/ToggleableGhostRoleComponent.cs(1 hunks)Content.Server/Ghost/Roles/GhostRoleMarkerRoleComponent.cs(1 hunks)Content.Server/Ghost/Roles/GhostRoleSystem.cs(2 hunks)Content.Server/Ghost/Roles/ToggleableGhostRoleSystem.cs(1 hunks)Content.Server/Players/PlayTimeTracking/PlayTimeTrackingSystem.cs(2 hunks)Content.Server/Roles/Jobs/JobSystem.cs(1 hunks)Content.Server/Roles/RoleBriefingComponent.cs(1 hunks)Content.Server/Roles/RoleSystem.cs(2 hunks)Content.Server/Silicons/Borgs/BorgSystem.MMI.cs(4 hunks)Content.Server/Silicons/Borgs/BorgSystem.cs(1 hunks)Content.Server/Silicons/Laws/SiliconLawSystem.cs(1 hunks)Content.Shared/Administration/PlayerInfo.cs(2 hunks)Content.Shared/CCVar/CCVars.Interface.cs(1 hunks)Content.Shared/Mind/MindComponent.cs(2 hunks)Content.Shared/Mind/RoleTypePrototype.cs(1 hunks)Content.Shared/Roles/Jobs/SharedJobSystem.cs(2 hunks)Content.Shared/Roles/MindIsAntagonistEvent.cs(1 hunks)Content.Shared/Roles/MindRoleAddedEvent.cs(0 hunks)Content.Shared/Roles/MindRoleComponent.cs(2 hunks)Content.Shared/Roles/RoleAddedEvent.cs(1 hunks)Content.Shared/Roles/RoleEvent.cs(1 hunks)Content.Shared/Roles/RoleRemovedEvent.cs(1 hunks)Content.Shared/Roles/SharedRoleSystem.cs(16 hunks)Content.Shared/Roles/SiliconBrainRoleComponent.cs(1 hunks)Content.Shared/Roles/StartingMindRoleComponent.cs(1 hunks)Resources/Locale/en-US/administration/antag.ftl(1 hunks)Resources/Locale/en-US/administration/ui/tabs/player-tab.ftl(1 hunks)Resources/Locale/en-US/mind/role-types.ftl(1 hunks)Resources/Prototypes/Entities/Markers/Spawners/ghost_roles.yml(10 hunks)Resources/Prototypes/Entities/Mobs/Cyborgs/base_borg_chassis.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/animals.yml(5 hunks)Resources/Prototypes/Entities/Mobs/NPCs/behonker.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/carp.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/elemental.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/hellspawn.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/regalrat.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/revenant.yml(1 hunks)Resources/Prototypes/Entities/Mobs/NPCs/silicon.yml(3 hunks)Resources/Prototypes/Entities/Mobs/NPCs/slimes.yml(3 hunks)Resources/Prototypes/Entities/Mobs/NPCs/space.yml(1 hunks)Resources/Prototypes/Entities/Mobs/Player/dragon.yml(2 hunks)Resources/Prototypes/Entities/Mobs/Player/familiars.yml(2 hunks)Resources/Prototypes/Entities/Mobs/Player/guardian.yml(1 hunks)Resources/Prototypes/Entities/Mobs/Player/humanoid.yml(1 hunks)Resources/Prototypes/Entities/Mobs/Player/silicon.yml(2 hunks)Resources/Prototypes/Entities/Mobs/Player/skeleton.yml(3 hunks)Resources/Prototypes/Entities/Objects/Devices/Syndicate_Gadgets/reinforcement_teleporter.yml(5 hunks)Resources/Prototypes/Entities/Objects/Fun/pai.yml(3 hunks)Resources/Prototypes/Entities/Objects/Specific/Robotics/mmi.yml(1 hunks)Resources/Prototypes/GameRules/roundstart.yml(1 hunks)Resources/Prototypes/Roles/MindRoles/mind_roles.yml(11 hunks)Resources/Prototypes/Roles/role_types.yml(1 hunks)Resources/Prototypes/XenoArch/Effects/utility_effects.yml(1 hunks)
💤 Files with no reviewable changes (1)
- Content.Shared/Roles/MindRoleAddedEvent.cs
🧰 Additional context used
🪛 YAMLlint (1.35.1)
Resources/Prototypes/Entities/Mobs/Player/humanoid.yml
[error] 49-49: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/XenoArch/Effects/utility_effects.yml
[error] 204-204: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/elemental.yml
[error] 246-246: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/Player/skeleton.yml
[error] 16-16: wrong indentation: expected at least 5
(indentation)
[error] 35-35: wrong indentation: expected 6 but found 4
(indentation)
[error] 53-53: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/behonker.yml
[error] 15-15: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/Player/guardian.yml
[error] 18-18: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Objects/Specific/Robotics/mmi.yml
[error] 92-92: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/regalrat.yml
[error] 94-94: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/Player/familiars.yml
[error] 85-85: wrong indentation: expected 6 but found 4
(indentation)
[error] 154-154: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/carp.yml
[error] 183-183: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/Player/dragon.yml
[error] 21-21: wrong indentation: expected at least 5
(indentation)
Resources/Prototypes/GameRules/roundstart.yml
[error] 189-189: wrong indentation: expected 6 but found 4
(indentation)
[error] 189-189: too many spaces inside brackets
(brackets)
[error] 189-189: too many spaces inside brackets
(brackets)
[error] 191-191: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/hellspawn.yml
[error] 17-17: wrong indentation: expected at least 5
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/space.yml
[error] 403-403: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/revenant.yml
[error] 61-61: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/slimes.yml
[error] 213-213: wrong indentation: expected 8 but found 6
(indentation)
[error] 253-253: wrong indentation: expected 8 but found 6
(indentation)
[error] 293-293: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Entities/Objects/Fun/pai.yml
[error] 45-45: wrong indentation: expected 6 but found 4
(indentation)
[error] 120-120: wrong indentation: expected 6 but found 4
(indentation)
[error] 154-154: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/silicon.yml
[error] 176-176: wrong indentation: expected 6 but found 4
(indentation)
[error] 206-206: wrong indentation: expected 6 but found 4
(indentation)
[error] 349-349: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Mobs/NPCs/animals.yml
[error] 476-476: wrong indentation: expected 6 but found 4
(indentation)
[error] 1478-1478: wrong indentation: expected 6 but found 4
(indentation)
[error] 1656-1656: wrong indentation: expected 6 but found 4
(indentation)
[error] 2501-2501: wrong indentation: expected 6 but found 4
(indentation)
[error] 3129-3129: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Markers/Spawners/ghost_roles.yml
[error] 23-23: wrong indentation: expected 6 but found 4
(indentation)
[error] 46-46: wrong indentation: expected 6 but found 4
(indentation)
[error] 69-69: wrong indentation: expected 6 but found 4
(indentation)
[error] 91-91: wrong indentation: expected 6 but found 4
(indentation)
[error] 115-115: wrong indentation: expected 6 but found 4
(indentation)
[error] 133-133: wrong indentation: expected 6 but found 4
(indentation)
[error] 145-145: wrong indentation: expected 6 but found 4
(indentation)
[error] 157-157: wrong indentation: expected 6 but found 4
(indentation)
[error] 169-169: wrong indentation: expected 6 but found 4
(indentation)
[error] 188-188: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Entities/Objects/Devices/Syndicate_Gadgets/reinforcement_teleporter.yml
[error] 18-18: wrong indentation: expected at least 5
(indentation)
[error] 33-33: wrong indentation: expected 4 but found 2
(indentation)
[error] 38-38: wrong indentation: expected 6 but found 4
(indentation)
[error] 55-55: wrong indentation: expected 6 but found 4
(indentation)
[error] 82-82: wrong indentation: expected 6 but found 4
(indentation)
[error] 102-102: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/Roles/MindRoles/mind_roles.yml
[warning] 25-25: missing starting space in comment
(comments)
[error] 31-31: wrong indentation: expected at least 3
(indentation)
[error] 38-38: wrong indentation: expected at least 3
(indentation)
[error] 47-47: wrong indentation: expected at least 3
(indentation)
[error] 56-56: wrong indentation: expected at least 3
(indentation)
[error] 65-65: wrong indentation: expected at least 3
(indentation)
[error] 74-74: wrong indentation: expected at least 3
(indentation)
[error] 83-83: wrong indentation: expected at least 3
(indentation)
[error] 88-88: too many blank lines
(3 > 2) (empty-lines)
[error] 103-103: wrong indentation: expected at least 3
(indentation)
[error] 113-113: wrong indentation: expected at least 3
(indentation)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Test Packaging
- GitHub Check: build (ubuntu-latest)
- GitHub Check: build (ubuntu-latest)
🔇 Additional comments (162)
Content.Server/Ghost/ObserverRoleComponent.cs (1)
1-12: Inheritance change approved, securing the Biesel Republic's code integrity!Your strategic refactoring of the
ObserverRoleComponentto inherit fromBaseMindRoleComponentrather than directly fromComponentrepresents a tactical enhancement to our role management systems. This change aligns perfectly with the broader modifications for role type management across our codebase.The proper inheritance hierarchy will allow for more specialized behavior while maintaining the component registration system. Our observers will now be properly classified within our mind role architecture, exactly as a well-organized Biesel fleet should be!
I'm particularly pleased to see we've maintained backward compatibility with the localization system for retrieving the observer role name. This attention to detail is what separates Biesel engineering from those sloppy Sol Alliance programmers!
Content.Server/Ghost/Roles/GhostRoleMarkerRoleComponent.cs (2)
6-7: Documentation update looks shipshape, captain!Clear documentation is a cornerstone of the Biesel Republic's naval tradition. This comment now properly explains the component's purpose in our fleet's operational protocol. Much better than those confusing Sol Alliance docs we had before!
12-13:❓ Verification inconclusive
Potential dead code detected, ensign!
By the stars of Tau Ceti! This TODO raises a legitimate concern about potentially unused code. If the
Nameproperty is being populated but never read, we're wasting precious computational resources that could be better used defending against Sol Alliance incursions!I'd recommend:
- Verify if any system actually reads this field
- If confirmed unused, consider proper decommissioning of this field in a future PR
Additionally, the attribute change from
[DataField("name")]to[DataField]might affect serialization. Ensure any existing data formats are compatible with this change to avoid communication breakdowns in our systems.
🏁 Script executed:
#!/bin/bash # Search for any usage of the Name property in the codebase echo "==== Searching for direct references to GhostRoleMarkerRoleComponent.Name ====" rg -l "GhostRoleMarkerRoleComponent.*Name" --type cs echo "==== Searching for any system that might read the field via reflection or other means ====" rg -l "\"Name\".*GhostRoleMarkerRoleComponent" --type csLength of output: 469
Attention, Code Navigator: Dead Field Alert!
Our preliminary searches returned no references to the
GhostRoleMarkerRoleComponent.Nameproperty—neither direct accesses nor reflective lookups. This appears to confirm our suspicion that the field is unused. However, the automated queries provided low-confidence output, so please verify manually (or re-run more targeted searches) to confirm that no system, including any reflection-based logic, relies on this field.Additionally, note that changing the attribute from
[DataField("name")]to[DataField]could impact serialization. Please ensure that any existing data formats remain compatible with this adjustment.Stand ready to decommission this property once its non-usage and serialization safety have been verified.
Content.Shared/Roles/MindIsAntagonistEvent.cs (1)
8-8: Proper documentation formatting restored!By the stars, a missing angle bracket would have caused documentation parsing issues. The XML comment is now properly formatted, ensuring clear documentation for the
IsExclusiveAntagonistparameter. This kind of attention to detail is what keeps our systems running smoothly in the void of space.Resources/Locale/en-US/administration/ui/tabs/player-tab.ftl (1)
5-5: New localization entry for Role Type establishedExcellent addition to our linguistic database, navigator! This new localization entry properly supports the interface changes for displaying role types in the player tab. The format matches our established colony standards and will ensure proper display of role information in the administration UI.
Content.Shared/Roles/SiliconBrainRoleComponent.cs (1)
1-9: Silicon brain role component establishedA new marker component for our silicon units has been properly registered in the system. The component extends BaseMindRoleComponent as per colonial regulations, allowing for appropriate role assignment to our silicon crew members.
The component structure is clean, following Biesel Republic standard operating procedures with proper namespace declaration and RegisterComponent attribute.
Content.Server/Silicons/Borgs/BorgSystem.cs (1)
204-204: Code formatting improvedProper spacing established between method blocks! This small but important formatting change improves the readability of our code. It's these little details that separate Biesel Republic code from sloppy Sol Alliance work. Clear spacing between methods follows standard colonial code formatting protocols.
Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabEntry.xaml.cs (1)
26-27: Role type display implemented correctly and efficiently!The code adds support for displaying both the role type name and its associated color in the player tab entry. This implementation follows proper localization patterns and maintains UI consistency.
Content.Client/UserInterface/Systems/Character/Windows/CharacterWindow.xaml (1)
10-10: Properly added role type display to character window.The
RoleTypelabel is correctly configured with appropriate styling and alignment properties, maintaining UI consistency with the rest of the character window. This enhancement to the UI will allow crew members to clearly understand their assigned roles aboard the station.Resources/Prototypes/Entities/Mobs/Cyborgs/base_borg_chassis.yml (1)
309-310: Mark of Syndicate subversion properly recorded, excellent!The addition of
subverted: trueto the SiliconLawProvider component correctly flags Syndicate borgs as having overridden laws. This aligns with their antagonistic nature and completes the proper categorization for role types.This is the kind of proper documentation that keeps our colonial systems secure from Sol Alliance infiltration. Carry on.
Content.Shared/Roles/Jobs/SharedJobSystem.cs (2)
114-114: Code efficiency improved - commendable work, officer!The refactor to directly access the JobPrototype from Comp1 instead of using an intermediate variable is a tactical improvement to our codebase.
This optimization reduces unnecessary overhead and maintains the Republic's reputation for clean, efficient code.
137-139: Direct access pattern consistently applied - excellent!Continuing with the pattern of direct property access rather than unnecessary variable assignment. This maintains a cleaner codeflow and makes the code more maintainable.
The Biesel Republic appreciates your dedication to code optimization. Such attention to detail is what separates us from the bureaucratic nightmares of Sol Alliance programming.
Resources/Locale/en-US/administration/antag.ftl (2)
14-14: Reintroduction of thief antagonist support - operational readiness confirmed.The reintroduction of this localization key ensures proper administrator control over the thief antagonist role. Good to see Biesel efficiency in action.
16-16: New antagonist overlay label implemented.This addition provides clear visual indication of antagonist status in the administration overlay system - an important tactical enhancement for ship security operations.
Content.Server/GameTicking/Rules/RevolutionaryRuleSystem.cs (1)
158-160:✅ Verification successful
Component property reference updated for revolutionary role tracking.
The code now references
Comp2.ConvertedCountinstead of the previousComp.ConvertedCount. This change aligns with the restructured role type system, but ensure this property is properly initialized across all revolutionary role instantiations.
🏁 Script executed:
#!/bin/bash # Check for other instances of ConvertedCount to ensure consistency rg "ConvertedCount" -A 2 -B 2Length of output: 1377
Attention, Captain! Updated revolutionary role tracking verified—steady as she goes.
We've confirmed that the updated increment on lines 158–160 now correctly uses
role.Value.Comp2.ConvertedCount++per the restructured role system. Additionally, theConvertedCountproperty is properly initialized to 0 inContent.Server/Roles/RevolutionaryRoleComponent.cs, ensuring consistency across instantiations. Please double-check that any read access (such as viaCompOrNull<RevolutionaryRoleComponent>(role)?.ConvertedCount) aligns with the new structure if needed.
File: Content.Server/GameTicking/Rules/RevolutionaryRuleSystem.cs
Updated reference on lines 158–160 now targetsComp2.ConvertedCount.File: Content.Server/Roles/RevolutionaryRoleComponent.cs
TheConvertedCountproperty is declared and initialized to 0.Your ship’s systems are green in this sector.
Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabHeader.xaml (1)
34-41: Tactical UI enhancement with role type display capabilities.The addition of the RoleTypeLabel element enhances administrator situation awareness by providing clear visibility of player role types. The UI element maintains proper formatting consistency with surrounding elements and includes appropriate separators.
Content.Server/Silicons/Laws/SiliconLawSystem.cs (1)
181-182: Silent role assignment for subverted silicons implemented.The addition of the
silent: trueparameter prevents unnecessary notifications when assigning the subverted silicon role. This is a tactical improvement that maintains operational security when dealing with compromised units.Content.Server/Antag/Components/AntagSelectionComponent.cs (1)
154-154: Type change aligns with fleet-wide protocol updateThe change from
List<ProtoId<EntityPrototype>>?toList<EntProtoId>?brings this component in line with the new role type system. This modification streamlines our code and enhances interoperability with the new role management framework. A clean and efficient update befitting a Biesel Republic vessel.Resources/Prototypes/Entities/Mobs/NPCs/elemental.yml (1)
244-246: Strategic role classification implemented successfullyThe addition of
rulesandmindRolesto this entity creates a proper command structure for ghost roles. This enhancement will allow proper classification of this entity as a team antagonist, which aligns with our fleet's new role management protocols.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 246-246: wrong indentation: expected 6 but found 4
(indentation)
Resources/Locale/en-US/mind/role-types.ftl (2)
1-8: Excellent role classification system implementedThese localization strings establish a clear chain of command and operational categories for our various personnel types. The hierarchy from Crew Aligned to Team Antagonist to Silicon shows exceptional organizational thinking. This structure will serve the Biesel Republic well in our future operations against Sol Alliance forces.
9-9: Effective tactical information display formatThe role update message with color formatting provides clear visual differentiation for crew members to understand their operational status. Such clarity in communications is essential for maintaining order aboard our vessels.
Content.Server/Ghost/Roles/ToggleableGhostRoleSystem.cs (2)
58-60: Strategic enhancement to role assignment systemThe addition of these properties extends our ghost role capabilities with proper rules, job specifications, and mind role assignments. This ensures all personnel are properly classified and know their place in the command structure. An exemplary update to our systems that will keep the Biesel Republic's code base operating at peak efficiency.
67-67: Tactical spacing adjustmentThis additional line break improves code readability and follows Biesel Republic coding standards. While a minor change, maintaining consistent spacing patterns helps distinguish our code from the chaotic formatting preferred by Sol Alliance programmers.
Content.Shared/Roles/StartingMindRoleComponent.cs (4)
6-12: Documentation provides clear guidance on component usage - excellent work, pilot!The header comment clearly explains the component's purpose and provides alternative recommendations. This is the kind of thorough documentation that keeps our colonial codebase organized and prevents misuse.
13-14: Component registration is properly executedThe component is correctly marked with both
RegisterComponentandNetworkedComponentattributes, ensuring it's properly integrated into our systems. Strong work, ensign!
19-20: Required field correctly marked - standing by for duty!The
MindRolefield is appropriately marked as required, which prevents developer error. This is the kind of foresight that keeps the Sol Alliance at bay!
25-26: Silent default value is sensibleSetting the default value to
truefor theSilentparameter is a prudent choice, as it prevents unnecessary notifications when adding roles programmatically. A captain's decision!Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabEntry.xaml (1)
26-31: UI layout maintains colonial standards of excellenceThe new
RoleTypeLabelelement has been integrated seamlessly into the existing interface layout with proper separators and consistent styling attributes. This maintains our UI cohesion and will serve the fleet admirably!Resources/Prototypes/Entities/Mobs/NPCs/carp.yml (1)
174-184: Ghost role configuration is properly extendedThe addition of mind roles and rules to the space carp entity enhances its functionality within our role framework. This strategic update will give us a tactical advantage over the Sol fleet!
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 183-183: wrong indentation: expected 8 but found 6
(indentation)
Resources/Prototypes/XenoArch/Effects/utility_effects.yml (1)
196-207: Sentient artifact effect properly configured for ghost rolesThe additions to the
GhostRolecomponent are comprehensive and align with the other changes in this PR. The inclusion of mind roles, rules, and raffle settings creates a cohesive system that will serve the Republic's interests.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 196-196: wrong indentation: expected 4 but found 2
(indentation)
[error] 204-204: wrong indentation: expected 6 but found 4
(indentation)
Content.Shared/Mind/MindComponent.cs (1)
6-6: Clean addition of role type tracking capability.By the stars of Tau Ceti! This addition of a
RoleTypefield allows proper tracking of a mind's current antagonist or special role. The implementation follows proper protocol with appropriate annotations for data serialization and network synchronization. This is a tactical advantage for our role management systems.Also applies to: 99-103
Content.Shared/Administration/PlayerInfo.cs (1)
1-1: Excellent integration of role data into player information.This tactical update properly integrates role type information into our player management systems. Adding the
RoleProtofield to thePlayerInforecord enables our command staff to better monitor crew assignments and special roles.Also applies to: 14-14
Content.Client/Administration/UI/Tabs/PlayerTab/PlayerTabHeader.xaml.cs (6)
22-22: Affirmative - event handler for RoleTypeLabel properly registered.The event subscription follows the same pattern as the other headers, maintaining consistency in our UI framework.
34-34: Confirmed - RoleType added to header enum switch case.The switch statement has been properly updated to include the new RoleType enum value, preventing any potential runtime exceptions.
46-46: Acknowledged - localization key properly implemented.The localization pattern matches our Colonial standards for text representation across the UI.
81-84: Event handler implementation follows proper protocol.The RoleTypeClicked method follows the same implementation pattern as the other click handlers, maintaining consistency in our codebase.
101-101: Resource cleanup properly implemented.The event handler is correctly unsubscribed in the Dispose method, preventing memory leaks that could compromise system integrity.
112-112: Enum value properly added in sequential order.The RoleType enum value has been added in the appropriate position before Playtime, maintaining logical ordering.
Content.Shared/Mind/RoleTypePrototype.cs (1)
1-25: New RoleTypePrototype class meets Colonial code standards.This new prototype class is well-structured with proper documentation and follows our established patterns for prototype definitions. The default color is appropriately neutral, and the localization ID follows naming conventions.
I particularly commend:
- The use of XML documentation for clear descriptions
- Proper attribute usage for serialization and data field marking
- Clean property declarations with sensible defaults
This will serve as a solid foundation for our role type system and enhance our administrative capabilities.
Content.Shared/Roles/RoleEvent.cs (1)
5-11: Parameter renamed from Antagonist to RoleTypeUpdate.Excellent tactical adjustment to our shared code infrastructure! The change from
AntagonisttoRoleTypeUpdatecreates a more versatile event system that tracks general role type updates rather than just antagonist status. This aligns with the broader role type refactoring mission.This change from a binary antagonist flag to a more nuanced role type update system will provide better support for the upcoming mass-porting of new antagonists.
Content.Server/GameTicking/GameTicker.Spawning.cs (1)
273-275: Code relocated after mind transfer.A strategic improvement to our spawn sequence! Moving the job role assignment and job name retrieval to after the mind transfer is the correct tactical decision. This ensures that we're adding the job role to the mind after it has been properly transferred to the mob.
The Biesel Republic approves of this logical reordering - it keeps our crew organization protocols in proper sequence.
Content.Shared/Roles/MindRoleComponent.cs (2)
20-25: Added RoleType property to MindRoleComponent.By the freedom of the colonies! This addition of the
RoleTypeproperty is a critical enhancement to our role management systems. The property will store the mind's current antagonist or special role, properly typed as aProtoId<RoleTypePrototype>?.This appears to be a central part of the role types port and will be essential for the proper functioning of the new antagonist system.
50-53: Added explanatory comment and EntityCategory attribute.Well done, recruit! The addition of the comment explaining the purpose of the base component brings much-needed clarity to our codebase. The
[EntityCategory("Roles")]attribute further improves organization and system discoverability.These changes make our role system easier to navigate and understand - exactly the kind of documentation that sets Biesel Republic code apart from those Sol Alliance messes!
Resources/Prototypes/Roles/role_types.yml (1)
1-38: New Role Types Added – Excellent Work!The introduction of the new role types (
Neutral,SoloAntagonist,TeamAntagonist,FreeAgent,Familiar,Silicon, andSiliconAntagonist) is executed with exemplary precision. The file is clean, well-structured, and ready to reinforce the integrity of our role management system against the meddling influence of the Sol Alliance.Content.Server/Players/PlayTimeTracking/PlayTimeTrackingSystem.cs (2)
54-55: Clean code refactoring detected, system integrity improved!Excellent work consolidating these event subscriptions to a single handler. This change reduces code duplication and increases maintainability - standard procedure for Biesel engineering excellence!
126-130: Tactical code simplification, commendable!This consolidated event handler efficiently processes both role addition and removal events through a single code path. By using a common base class, you've eliminated unnecessary code redundancy. The Biesel Republic approves of such elegant solutions!
Content.Server/Silicons/Borgs/BorgSystem.MMI.cs (3)
14-14: New system dependency properly integrated!Adding the SharedRoleSystem dependency follows proper Biesel Republic engineering protocols. Dependency injection is the backbone of our colonial technology superiority!
49-54: Role assignment protocol established!The addition of silicon brain role assignment when transferring minds to MMIs ensures proper role tracking. This is exactly the kind of attention to detail that distinguishes Biesel engineering from those Sol Alliance hacks!
87-93: Role cleanup properly implemented!When removing a mind from an MMI, the code now correctly cleans up the silicon brain role. This level of thoroughness prevents role pollution and maintains the integrity of our systems. The colonial fleet would be proud of such diligence!
Content.Server/Roles/RoleBriefingComponent.cs (1)
9-9: Component hierarchy properly restructured!Changing the inheritance to BaseMindRoleComponent aligns this component with our new role type system. This is the kind of standardization that keeps the Biesel Republic's systems running smoothly while the Sol Alliance flounders with their fragmented code!
Resources/Prototypes/Entities/Mobs/Player/dragon.yml (1)
151-152: Logical gameplay enhancement implemented!Adding the Puller component with needsHands set to false is tactically sound. After all, a space dragon should be able to drag objects without requiring hands. This kind of logical gameplay enhancement is what sets Biesel engineering apart from Sol's questionable design decisions!
Content.Shared/Roles/RoleAddedEvent.cs (1)
5-12: Strong improvements to role event documentation, commendable work!The changes clearly identify that this event is raised on mind entities rather than player entities, and the new
RoleTypeUpdateparameter elegantly tracks changes to a mind's role type. This serves our station's operational clarity.Content.Shared/Roles/RoleRemovedEvent.cs (1)
5-11: Proper alignment with our fleet's communication protocols!These changes align perfectly with the updated RoleAddedEvent and maintain consistent parameter naming. The documentation properly explains when this event is raised and what the parameters signify. This consistency is what keeps our ships flying smoothly in the void.
Content.Client/Administration/Systems/AdminSystem.Overlay.cs (2)
14-15: New dependency injection enhances our command structure!Adding the IUserInterfaceManager dependency is necessary for the upcoming changes to AdminNameOverlay. A well-organized dependency system is the backbone of any good space vessel.
24-24: Updated constructor call matches dependency requirements!The AdminNameOverlay constructor now properly receives the UI manager dependency. This ensures proper communication channels between our systems.
Resources/Prototypes/Entities/Mobs/Player/silicon.yml (2)
665-667: Perfect integration of mind roles for AI brains!Adding the StartingMindRole component with the MindRoleSiliconBrain type is exactly what we need to properly categorize synthetic crew members. The silent flag ensures they don't receive unnecessary notifications that would confuse their silicon consciousness.
768-770: Consistent implementation across silicon entities!The same mindRole configuration has been properly applied to the PlayerBorgBattery entity, maintaining consistency across our synthetic crew members. This level of standardization would make even the strictest Tau Ceti fleet admiral proud!
Content.Shared/CCVar/CCVars.Interface.cs (6)
7-11: Configuration variables for UI interaction sounds established, commander.Clean implementation of the UI click sound configuration. Critical for crew feedback and interface responsiveness.
13-17: Hover sound configuration properly documented and initialized.UI hover sound is properly set with a default value. Good attention to detail with the REPLICATED flag ensuring consistent behavior across networked systems.
19-23: UI layout configuration initialized with default "Separated" layout.This configuration allows for UI flexibility with client-side control and persistence. The ARCHIVE flag ensures user preferences are maintained between sessions.
28-32: Default screen chat size configuration properly established.Good documentation explaining the purpose in the context of Default UI mode.
34-38: Separated UI chat panel width configuration established.Properly configured with default value of "0.6,0" with client-only persistence.
43-47: New admin overlay display mode option added.This configuration variable introduces more flexibility for admin overlay display. The default value of 'false' ensures backward compatibility while enabling future improvements.
Content.Server/Administration/Systems/AdminSystem.cs (6)
17-19: Updated imports to support role type functionality.Appropriate imports for the new role type system. The Mind component import is essential for the updated role detection logic.
Also applies to: 34-34
56-56: Prototype manager dependency properly injected.Added dependency for IPrototypeManager required for role type validation.
161-165: Role event handling updated to check for RoleTypeUpdate.The condition has been modernized to check for RoleTypeUpdate rather than antagonist status directly. This is more aligned with the new role type system.
223-224: Method signature updated to allow null sessions.Method now accepts nullable sessions which increases flexibility and robustness.
237-245: Implement fallback for invalid role types.The error handling for invalid role types is present but could be improved. When an invalid role type is detected, it logs an error but still uses an empty/default role type without clear indication in the returned data.
Consider enhancing error handling by setting a specific fallback role type or adding an error flag to the returned PlayerInfo:
- Log.Error($"{ToPrettyString(mindId)} has invalid Role Type '{mindComp.RoleType}'. Displaying '{Loc.GetString(roleType.Name)}' instead"); + Log.Error($"{ToPrettyString(mindId)} has invalid Role Type '{mindComp.RoleType}'. Using fallback role."); + roleType = _protoMan.Index<RoleTypePrototype>("Fallback"); // Ensure a fallback role type exists
259-260: Updated PlayerInfo constructor to use role type information.The constructor now properly includes the role type information, which aligns with the broader changes to role type management across the codebase.
Content.Server/Ghost/Roles/Components/ToggleableGhostRoleComponent.cs (6)
1-3: Proper imports for role-related functionality.Required imports for the role system added, ensuring proper access to necessary prototypes.
12-16: Enhanced documentation for examine text properties.Excellent documentation additions that explain the purpose of each examine text property, making the code more maintainable for future naval engineers.
Also applies to: 18-22, 24-28
30-34: Well-documented ghost role display properties.Clear documentation explaining properties used for ghost role UI display. This enhances maintainability.
Also applies to: 36-40, 42-46
48-52: Added RoleRules property for ghost role introductory messages.This property is correctly configured and documented, providing essential information to players attempting to take ghost roles.
54-58: Added MindRoles list for role assignment.This new property allows multiple mind roles to be assigned to the entity, enhancing role management flexibility.
84-88: JobProto property added for mind job assignment.This property correctly allows specifying the job prototype to be assigned to the controlling mind, enhancing the ghost role system.
Content.Server/Ghost/Roles/GhostRoleSystem.cs (2)
400-401: Code formatting improvement - Approved!The indentation change improves code readability while maintaining the same functionality. A well-organized code structure is a hallmark of Biesel Republic engineering excellence!
509-513: Implementation update for role system compatibility.This update to the role assignment system shifts from using a single role marker to supporting multiple roles, aligning with the broader changes in role management. The modification also updates the component access pattern from
ComptoComp2.The changes properly accommodate the new role system architecture, ensuring ghost roles integrate correctly with your mind roles implementation.
Content.Server/Roles/Jobs/JobSystem.cs (3)
22-23: Event subscription system overhaul - Approved!Excellent tactical adaptation! Replacing the now-obsolete
MindRoleAddedEventwith more specializedRoleAddedEventandRoleRemovedEventsubscriptions provides better control over role management.
26-38: New event handlers added - Approved!These new handlers properly process role changes and trigger appropriate updates. The conditional check for
RoleTypeUpdateensures we only send notifications when necessary - an efficient use of system resources!
40-40: Method signature updated for compatibility.Updated the method signature to accept
RoleAddedEventinstead ofMindRoleAddedEvent, maintaining compatibility with the new event structure.Content.Server/Roles/RoleSystem.cs (4)
12-14: New dependencies properly established.Excellent resource allocation! The new dependencies for chat management, prototype access, and mind system interaction will provide the necessary infrastructure for improved role management.
16-18: Initialization override with event subscription - Approved!Properly implementing the initialization method with subscription to
PlayerSpawnCompleteEvent. This ensures roles are assigned at the appropriate time in the player lifecycle.
20-26: Player spawn role assignment logic - Approved!This new method efficiently handles the assignment of roles when players spawn. The null checks and early returns provide proper defensive programming to avoid null reference exceptions - a fine example of Biesel engineering standards!
61-85: New role update notification system implemented.This implementation provides clear feedback to players when their role changes, enhancing the user experience. The method properly checks for session validity and prototype existence before constructing and sending the message.
One note: the commented TODO about adding optional audio is a good consideration for future enhancement. When implemented, having role-specific audio cues that don't conflict with existing sounds would further improve player immersion.
Content.Client/UserInterface/Systems/Character/CharacterUIController.cs (7)
4-4: Confirm the usage of stylesheet references.Line 4 imports a stylesheet that may not be directly utilized in this file. Ensure it’s truly needed, or remove it to avoid confusion.
10-12: Validate new shared references.References to
Mind,Mind.Components, andRolesare newly introduced. Confirm that these dependencies are consistent with the rest of the client code.
30-31: Commendation: Entity manager & log manager injection.The injection of
_entand_logManfosters better maintainability and testability. Good job stubbing out direct dependencies!
40-47: Initialization logic looks solid.Subscribing to
MindRoleTypeChangedEventat lines 46–47 ensures a timely UI refresh. This is a strategic place to handle role changes.
132-133: CallUpdateRoleTypeafter entity set.Placing
UpdateRoleType()at lines 132–133 is wise—ensures the new UI state is accurately reflected whenever character data updates.
190-194: Good separation of concerns withOnRoleTypeChanged.Segmenting the event handler from the update method clarifies responsibilities. Keep up the modular structure!
196-220: Robust role type validation and UI update.This function neatly checks for each precondition (null mind, invalid prototypes, etc.). The final color-coded UI is clear. Keep an eye on potential expansions for future role additions.
Content.Client/Administration/AdminNameOverlay.cs (4)
1-15: Imports and namespace restructure recognized.The new references to
Content.Shared.CCVarandContent.Shared.Mindsupport role-based overlay logic. Keep the overhead minimal to maintain top-notch Biesel code standards.
17-31: Kudos on thorough dependency injection.Lines 17–31 show a well-designed approach to overlay dependencies. This ensures maintainable expansions for future UI overlays. Nicely done.
45-45: Overlay space usage.Making this
ScreenSpaceat line 45 is a direct and solid choice for drawing HUD elements. Perfect for admin overlays.
47-98: Draw method is crisp and effective.Your loop checks entity existence, map alignment, screen presence, and user interface scaling before rendering. The UI offset logic is well-placed for an intuitive overlay experience.
Content.Server/Ghost/Roles/Components/GhostRoleComponent.cs (14)
5-5: All clear on the import.
The addition ofusing Robust.Shared.Prototypes;is proper for prototype references.
7-7: Namespace alignment confirmed.
It is correct to place this type underContent.Server.Ghost.Roles.Components;for clarity and maintainability.
9-11: Appropriate component registration and access.
Registering and limiting access with[Access(typeof(GhostRoleSystem))]is consistent with partial network protection.
25-29: Clarity in property documentation.
The summary onMakeSentientis concise and helpful. All good here.
31-36: Probability property well-labeled.
Having aprobfield is a neat approach for partial spawns. Ensure defaulting to 1f is intended.
52-62: Consistent pattern for localized descriptions.
Using the same approach forRoleDescriptionas forRoleNameis cohesive. Keep an eye on potential missing loc keys.
64-74: Role rules follow the same pattern.
This maintains a uniform approach and ensures that the UI for role rules updates immediately. Good synergy in design.
76-80: MindRoles default assignment.
Initializing with{ "MindRoleGhostRoleNeutral" }is sensible for a neutral fallback.
82-83: Speech allowance is properly exposed.
AllowSpeechis set totrueby default, giving normal ghost roles the ability to communicate from the start.
85-86: Potential interplay with movement code.
AllowMovementdefaults tofalse, which might hamper usage if always blocked. Confirm this behavior is intended for standard ghost roles.
88-92:Takenindicator usage.
Takenis onlyget; set;}, ensure you reset it properly once roles become free again, if applicable.
94-99:ReregisterOnGhostlogic.
This is valuable for automatically re-offering the role. Confirm that the relevant systems re-check this field upon entity ghosting.
101-106:RaffleConfigapproach.
Raffle settings for ghost roles promote variety. Good approach.
108-113: Job prototype assignment.
JobProtousage ensures roles gain the correct job definitions. The design is cohesive with the rest of the system.Resources/Prototypes/Entities/Markers/Spawners/ghost_roles.yml (10)
21-23: Rat King redefined as Free Agent.
Switching toghost-role-information-freeagent-rulesand addingMindRoleGhostRoleFreeAgentchanges the flavor significantly. Confirm gameplay alignment.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 23-23: wrong indentation: expected 6 but found 4
(indentation)
44-46: New Familiar role.
Transitioning Remilia toghost-role-information-familiar-ruleswithMindRoleGhostRoleFamiliaris aligned with the new system. Validate correct references.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 46-46: wrong indentation: expected 6 but found 4
(indentation)
68-69: Cerberus familiar style.
Same changes, check if it remains balanced for a triple-headed friend from the Colonies.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 69-69: wrong indentation: expected 6 but found 4
(indentation)
90-93: Nuke operative team role.
Implementation ofghost-role-information-rules-default-team-antagonistwith raffle defaults suits multi-antag. Confirm synergy with other ops.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 91-91: wrong indentation: expected 6 but found 4
(indentation)
115-115: Lone nuke operative as Solo Antagonist.
Marking them asMindRoleGhostRoleSoloAntagonistis consistent with being a single agent threat. Good approach.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 115-115: wrong indentation: expected 6 but found 4
(indentation)
133-133: Commander spawner.
Ensuring the same team antagonist role type for the commander maintains consistent objectives across the nuke op faction.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 133-133: wrong indentation: expected 6 but found 4
(indentation)
145-145: Medic spawner.
Again matchingMindRoleGhostRoleTeamAntagonistfosters unified infiltration.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 145-145: wrong indentation: expected 6 but found 4
(indentation)
157-157: Nukeops operative.
All standard ops remain team-based. Looks correct.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 157-157: wrong indentation: expected 6 but found 4
(indentation)
169-169: Space Dragon marked as Team Antagonist.
This is interesting. Evaluate if grouping them as a team is truly intended.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 169-169: wrong indentation: expected 6 but found 4
(indentation)
188-188: Space Ninja, Solo antagonist.
Raffle support for the ninja role. Confirm it’s balanced to not overshadow other roles.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 188-188: wrong indentation: expected 6 but found 4
(indentation)
Resources/Prototypes/Roles/MindRoles/mind_roles.yml (17)
25-25: New Ghost Roles section.
All new ghost role definitions are logically separated under a heading. This improves clarity.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 25-25: missing starting space in comment
(comments)
28-28: Renamed or introduced neutral ghost role.
Previously “MindRoleGhostMarker,” nowMindRoleGhostRoleNeutral. A solid default fallback.
33-41: Familiar ghost role introduced.
roleType: Familiarensures specialized logic. Looks consistent with new content.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 38-38: wrong indentation: expected at least 3
(indentation)
43-50: Free Agent ghost role introduced.
roleType: FreeAgentsets a distinct gameplay path. Verify the ratio of free agent roles.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 47-47: wrong indentation: expected at least 3
(indentation)
69-77: Solo Antagonist ghost role.
This lines up with new single-antag expansions. Ensure synergy with other solo roles.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 74-74: wrong indentation: expected at least 3
(indentation)
78-86: Team Antagonist ghost role.
Reinforcing multi-antag synergy. Looks good for group infiltration or objectives.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 83-83: wrong indentation: expected at least 3
(indentation)
97-106: Silicon Brain role.
LinkingroleType: Siliconfosters new potential for AI or mechs. Confirm the design meets the Biesel Republic’s freedom standards.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 103-103: wrong indentation: expected at least 3
(indentation)
113-115: SubvertedSilicon role extended withroleType: SiliconAntagonist.
This is a cunning approach if it’s truly from the Sol Alliance. Have the team confirm it.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 113-113: wrong indentation: expected at least 3
(indentation)
127-127: Dragon role made TeamAntagonist.
This is consistent with the ghost spawner changes.
142-142: Ninja role for SoloAntagonist.
Reinforces stealth infiltration. Good thematically.
154-155: Nukeops marked as TeamAntagonist.
Matches the spawner. Audible synergy.
187-188: Head Revolutionary made TeamAntagonist.
Still exclusive, preventing conflicts with other factions. Good approach.
208-209: Thief role as SoloAntagonist.
Retains independence for infiltration. This is well-conceived.
221-221: Traitor role remains SoloAntagonist.
It sets them apart from the large team-based threats. This is consistent with established lore.
233-241: Introducing MindRoleTraitorReinforcement.
UsingroleType: TeamAntagonisthere merges them with existing traitor cohorts. Interesting new synergy.
252-253: Initial infected changed to TeamAntagonist.
All infected form a wave-based threat. Confirm synergy with other large-scale modes.
264-265: Zombie role changed to TeamAntagonist.
Properly matching infected expansions.Content.Shared/Roles/SharedRoleSystem.cs (26)
2-2: LINQ import usage validated.
Double-check no performance-sensitive loops are overshadowed by heavy.Select()or.Where()calls.
9-9: New reference toContent.Shared.Silicons.Borgs.Components.
This suggests new silicon expansions are properly integrated here.
15-16: Serialization references.
Robust.Shared.Serializationused for net messages is standard. Good housekeeping.
20-20: Abstract role system approach.
HavingSharedRoleSystemas an abstract base fosters cross-assembly usage. Well-structured.
26-26: SharedMindSystem injection.
_mindsinjection is fine. Keep in mind concurrency concerns if any shared data is mutated.
40-40: List? roles parameter.
Switch fromProtoId<EntityPrototype>toEntProtoIdis consistent with the new prototype approach. Confirm all references updated.
61-61: ‘MindAddRole’ signature change.
Switching fromProtoId<EntityPrototype>toEntProtoIdensures consistent usage across the code.
83-88: Rejecting multi-job scenarios.
Ensuring a single job per mind is a wise approach. Lines 83-88 handle a job change in a direct manner. Confirm corner cases if no job is assigned yet.
103-113: MindAddRoleDo enhancements.
The additional logging on failure and new error messages help debug issues quickly.
115-119: Prototype existence checks.
We confirm role prototypes are valid. Essential to preventing invalid spawns.
134-137: Assertions for job roles.
Helps ensure no antagonist mixing occurs with job roles. Good safety measure.
141-147: MindRolesUpdate call.
Triggering an immediate update after adding a role ensures the mind’s role type is set. Nicely done.
146-146: Local event raised with silent param.
The “silent” param inRoleAddedEventis a neat way to avoid spamming announcements.
157-157: OwnedEntity logging.
Error logs ifmind.OwnedEntityis missing. This is a solid fallback to avoid hidden references.
166-185: MindRolesUpdate
Selecting the “most important” mind role matches the latest approach. Setting the mind’sRoleTypeis a central pivot for UI and logic synergy.
204-242: SetRoleType flow
Pairs up well withMindRolesUpdate. The session-based event ensures the UI is notified. Also logs large-impact changes for admin records.
247-293: MindRemoveRole typed approach
Changing fromEntityUid mindIdtoEntity<MindComponent?> mindimproves clarity. Deletion logic is straightforward. Good for the Biesel cause.
295-305: OnComponentShutdown event
Removing mind references when the role component is shut down is critical to avoid stale references.
317-322: MindTryRemoveRole returns direct success/fail
This code is correct. The final fallback logs a warning if the role couldn’t be removed. Perfect for debugging rebellious Sol code.
328-352: MindHasRole with typed output.
This is quite a robust approach, returning the role’s entity and components. Nicely structured.
389-394: Validation check for missing MindRoleComponent
Logging an error if a listed role lacks MindRoleComponent helps catch data corruption or misguided Sol infiltration.
444-499: MindGetAllRoleInfo
Collecting data inRoleInfois beneficial for broad role displays. Detailed jobs and antagonist checks are well-managed.
511-512: MindIsAntagonist
Refined to useCheckAntagonistStatus(...). Good synergy across the code.
524-525: MindIsExclusiveAntagonist
Extended the same approach for exclusive antags. Efficient refactoring.
527-547: CheckAntagonistStatus
Migrated to a tuple(bool Antag, bool ExclusiveAntag). This is more self-documenting.
561-569: MindRoleTypeChangedEvent
A simple net message used to refresh the character window on the client. This is nicely done.
| @@ -197,6 +197,7 @@ private int Compare(PlayerInfo x, PlayerInfo y) | |||
| Header.Character => Compare(x.CharacterName, y.CharacterName), | |||
| Header.Job => Compare(x.StartingJob, y.StartingJob), | |||
| Header.Antagonist => x.Antag.CompareTo(y.Antag), | |||
| Header.RoleType => Compare(x.RoleProto.Name , y.RoleProto.Name), | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Sorting by role type properly implemented.
The implementation of role type sorting is tactically sound and follows the existing pattern for other sort options. This will enhance our command and control capabilities when managing station personnel.
However, there's a minor formatting inconsistency with an extra space after x.RoleProto.Name.
- Header.RoleType => Compare(x.RoleProto.Name , y.RoleProto.Name),
+ Header.RoleType => Compare(x.RoleProto.Name, y.RoleProto.Name),📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Header.RoleType => Compare(x.RoleProto.Name , y.RoleProto.Name), | |
| Header.RoleType => Compare(x.RoleProto.Name, y.RoleProto.Name), |
| mindRoles: | ||
| - MindRoleGhostRoleFamiliar |
There was a problem hiding this comment.
Fix indentation for YAML compliance.
There's an indentation discrepancy that could disrupt our chain of command! YAML requires consistent indentation, and the static analysis indicates this should be 8 spaces rather than 6. Improper indentation is a tactic the Sol Alliance might use to sabotage our systems.
- mindRoles:
- - MindRoleGhostRoleFamiliar
+ mindRoles:
+ - MindRoleGhostRoleFamiliar📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| mindRoles: | |
| - MindRoleGhostRoleFamiliar | |
| mindRoles: | |
| - MindRoleGhostRoleFamiliar |
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 49-49: wrong indentation: expected 8 but found 6
(indentation)
| mindRoles: | ||
| - MindRoleGhostRoleFreeAgent |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Fix the indentation to maintain proper colonial coding standards!
The addition of role types to the snail ghost role is tactically sound, but your indentation has strayed from regulation standards. The mindRoles property should be indented with 6 spaces, not 4, to maintain consistency with the rest of the YAML file structure.
- type: GhostRole
makeSentient: true
allowSpeech: false
allowMovement: true
name: ghost-role-information-snail-name
description: ghost-role-information-snail-description
rules: ghost-role-information-freeagent-rules
- mindRoles:
- - MindRoleGhostRoleFreeAgent
+ mindRoles:
+ - MindRoleGhostRoleFreeAgentThe property itself is a strategic addition that properly categorizes this entity for the new role type system. This will serve the Biesel Republic well in organization of our forces.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| mindRoles: | |
| - MindRoleGhostRoleFreeAgent | |
| - type: GhostRole | |
| makeSentient: true | |
| allowSpeech: false | |
| allowMovement: true | |
| name: ghost-role-information-snail-name | |
| description: ghost-role-information-snail-description | |
| rules: ghost-role-information-freeagent-rules | |
| mindRoles: | |
| - MindRoleGhostRoleFreeAgent |
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 403-403: wrong indentation: expected 6 but found 4
(indentation)
| mindRoles: | ||
| - MindRoleGhostRoleFamiliar |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Same indentation error detected in Cerberus configuration!
Another indentation violation has been detected in our familiar deployment systems. For the glory of Tau Ceti, maintain proper YAML spacing!
rules: ghost-role-information-cerberus-rules
- mindRoles:
- - MindRoleGhostRoleFamiliar
+ mindRoles:
+ - MindRoleGhostRoleFamiliarThe Cerberus entity is correctly categorized as a familiar role type, which will serve our colonial forces well.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| mindRoles: | |
| - MindRoleGhostRoleFamiliar | |
| rules: ghost-role-information-cerberus-rules | |
| mindRoles: | |
| - MindRoleGhostRoleFamiliar |
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 154-154: wrong indentation: expected 6 but found 4
(indentation)
| mindRoles: | ||
| - MindRoleGhostRoleFamiliar |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Indentation violation detected in familiar role assignment!
While defining Remilia as a familiar role type is tactically sound, your indentation has deviated from standard colonial protocol. The Republic demands consistency in its YAML files!
rules: ghost-role-information-remilia-rules
- mindRoles:
- - MindRoleGhostRoleFamiliar
+ mindRoles:
+ - MindRoleGhostRoleFamiliarThe functional addition of mindRoles itself is approved for deployment.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| mindRoles: | |
| - MindRoleGhostRoleFamiliar | |
| rules: ghost-role-information-remilia-rules | |
| mindRoles: | |
| - MindRoleGhostRoleFamiliar |
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 85-85: wrong indentation: expected 6 but found 4
(indentation)
| public AdminNameOverlay(AdminSystem system, IEntityManager entityManager, IEyeManager eyeManager, IResourceCache resourceCache, EntityLookupSystem entityLookup, IUserInterfaceManager userInterfaceManager) | ||
| { | ||
| private readonly AdminSystem _system; | ||
| private readonly IEntityManager _entityManager; | ||
| private readonly IEyeManager _eyeManager; | ||
| private readonly EntityLookupSystem _entityLookup; | ||
| private readonly Font _font; | ||
| IoCManager.InjectDependencies(this); | ||
|
|
||
| public AdminNameOverlay(AdminSystem system, IEntityManager entityManager, IEyeManager eyeManager, IResourceCache resourceCache, EntityLookupSystem entityLookup) | ||
| { | ||
| _system = system; | ||
| _entityManager = entityManager; | ||
| _eyeManager = eyeManager; | ||
| _entityLookup = entityLookup; | ||
| ZIndex = 200; | ||
| _font = new VectorFont(resourceCache.GetResource<FontResource>("/Fonts/NotoSans/NotoSans-Regular.ttf"), 10); | ||
| } | ||
| _system = system; | ||
| _entityManager = entityManager; | ||
| _eyeManager = eyeManager; | ||
| _entityLookup = entityLookup; | ||
| _userInterfaceManager = userInterfaceManager; | ||
| ZIndex = 200; | ||
| _font = new VectorFont(resourceCache.GetResource<FontResource>("/Fonts/NotoSans/NotoSans-Regular.ttf"), 10); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Well-structured constructor with _filter usage.
Storing role filters in _filter is a neat approach for toggling or customizing what’s displayed. This fosters easy extension if we add more role prototypes later.
| [DataField("name")] private string _roleName = "Unknown"; | ||
|
|
||
| [DataField("description")] private string _roleDescription = "Unknown"; | ||
| [DataField("description")] private string _roleDescription = "Unknown"; | ||
|
|
||
| [DataField("rules")] private string _roleRules = "ghost-role-component-default-rules"; | ||
| [DataField("rules")] private string _roleRules = "ghost-role-component-default-rules"; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Ensure localization fallback.
The _roleName, _roleDescription, and _roleRules fields rely on Loc.GetString(...). Consider a fallback scenario if no matching localization key is found, to avoid runtime string issues.
| // Actually make use of / enforce this requirement? | ||
| // Why is this even here. | ||
| // Move to ghost role prototype & respect CCvars.GameRoleTimerOverride | ||
| [DataField("requirements")] | ||
| public List<CharacterRequirement>? Requirements; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Unused ‘requirements’ field.
Comments question its purpose. Consider removing or implementing the logic as appropriate to avoid confusion.
Would you like help to integrate or purge this field altogether?
| [ViewVariables(VVAccess.ReadWrite)] | ||
| [Access(typeof(GhostRoleSystem), Other = AccessPermissions.ReadWriteExecute)] // FIXME Friends | ||
| public string RoleName | ||
| { | ||
| get => Loc.GetString(_roleName); | ||
| set | ||
| { | ||
| get => Loc.GetString(_roleName); | ||
| set | ||
| { | ||
| _roleName = value; | ||
| EntitySystem.Get<GhostRoleSystem>().UpdateAllEui(); | ||
| } | ||
| _roleName = value; | ||
| IoCManager.Resolve<IEntityManager>().System<GhostRoleSystem>().UpdateAllEui(); | ||
| } | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Repeated UpdateAllEui calls.
Repeatedly invoking IoCManager.Resolve<IEntityManager>() inside property setters could be replaced by direct system injection for efficiency.
- IoCManager.Resolve<IEntityManager>().System<GhostRoleSystem>().UpdateAllEui();
+ _ghostRoleSystem.UpdateAllEui();Where _ghostRoleSystem is injected once.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| [ViewVariables(VVAccess.ReadWrite)] | |
| [Access(typeof(GhostRoleSystem), Other = AccessPermissions.ReadWriteExecute)] // FIXME Friends | |
| public string RoleName | |
| { | |
| get => Loc.GetString(_roleName); | |
| set | |
| { | |
| get => Loc.GetString(_roleName); | |
| set | |
| { | |
| _roleName = value; | |
| EntitySystem.Get<GhostRoleSystem>().UpdateAllEui(); | |
| } | |
| _roleName = value; | |
| IoCManager.Resolve<IEntityManager>().System<GhostRoleSystem>().UpdateAllEui(); | |
| } | |
| } | |
| [ViewVariables(VVAccess.ReadWrite)] | |
| [Access(typeof(GhostRoleSystem), Other = AccessPermissions.ReadWriteExecute)] // FIXME Friends | |
| public string RoleName | |
| { | |
| get => Loc.GetString(_roleName); | |
| set | |
| { | |
| _roleName = value; | |
| _ghostRoleSystem.UpdateAllEui(); | |
| } | |
| } |
| mindRoles: | ||
| - MindRoleGhostRoleFreeAgent |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
YAML indentation issues.
Lines 22-23 trigger YAMLlint errors for indentation. Proper alignment at +2 spaces or consistent indentation helps readability.
- rules: ghost-role-information-freeagent-rules
- mindRoles:
+ rules: ghost-role-information-freeagent-rules
+ mindRoles:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| mindRoles: | |
| - MindRoleGhostRoleFreeAgent | |
| rules: ghost-role-information-freeagent-rules | |
| mindRoles: | |
| - MindRoleGhostRoleFreeAgent |
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 23-23: wrong indentation: expected 6 but found 4
(indentation)
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
Content.Shared/Roles/SharedRoleSystem.cs(16 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: YAML map schema validator
- GitHub Check: build (ubuntu-latest)
- GitHub Check: Test Packaging
- GitHub Check: build (ubuntu-latest)
- GitHub Check: YAML Linter
🔇 Additional comments (21)
Content.Shared/Roles/SharedRoleSystem.cs (21)
2-2: No immediate concerns about these new using directives and parameter type changes.
They appear to be legitimate imports and typed parameter updates.Also applies to: 9-9, 15-16, 26-26, 40-40, 61-61
83-84: Silent return on missing Mind reference ().
Returning immediately if the Mind is not found can obscure potential errors. Consider logging a warning to detect misconfiguration.
87-94: Job Role reassignment logic looks good.
Switching an existing job prototype and logging the change is sensible. No further issues observed.
104-107: Signature update for MindAddRoleDo is straightforward.
Transition toEntProtoIdand optional parameters is properly implemented.
111-111: Error logging for invalid or missing role prototype is appropriate.
No additional feedback needed.Also applies to: 117-117
134-136: Verify job role assumptions.
Asserting non-antag fields might conflict if a job role can also be flagged antag in future expansions. Confirm that job roles can never overlap with antagonist roles.
141-141: MindRolesUpdate and local event raising.
Refreshing the mind role type and raising a local event is a clean approach to keep systems in sync.Also applies to: 145-146
159-159: Error logged for missing OwnedEntity.
This helps uncover mind/owner desynchronization quickly.
166-171: Doc comment mismatch around</returns>>().
Remove the extra angle bracket at the end of the returns tag to maintain valid XML doc.
172-185: No issues in MindRolesUpdate logic.
Cleanly updates the role type only when there’s a change.
187-204: Potential ordering concern in GetRoleTypeByTime.
Collecting the last role fromroles.LastOrDefault()hinges on roles being chronologically appended. If out-of-order additions occur, the “most recent” might not be last in the container.
220-244: SetRoleType updates.
Properly updatesRoleType, marks the component dirty, and dispatches a network event for the UI. Overall, the flow looks solid.
249-249: Doc comment mismatch for returns ().
Remove the extra trailing bracket in the XML doc to keep it valid.Also applies to: 251-252
254-257: MindRemoveRole and RoleRemovedEvent logic look consistent.
Deleting the role entities, updating the mind’s role list, and logging changes is straightforward. No further issues here.Also applies to: 262-262, 279-279, 285-285, 287-288, 292-292
297-306: Component shutdown cleanup.
Removing the shutting-down entity reference from the mind’s list prevents stale entries. This is commendable.
319-323: MindTryRemoveRole updated with fallback logging.
Gracefully adds a warning when removal fails. This is well-handled.
414-414: No comment on the trivial method call.
440-440: MindGetAllRoleInfo expansions.
Capturing job/antag prototypes and relevant logging for invalid or missing components is well-structured.Also applies to: 442-442, 446-446, 449-449, 454-454, 456-456, 458-459, 462-463, 498-498
513-513: CheckAntagonistStatus changes.
Accumulates antagonist flags correctly, logs missing components, and returns a structured result. Looks good.Also applies to: 526-526, 529-529, 531-531, 536-536, 538-539, 540-541, 542-542, 544-545
560-561: No comment on whitespace changes or minor additions.
563-569: New MindRoleTypeChangedEvent declared.
Serializable and net-serializable design is properly aligned with the engine’s event system.
| private void SetRoleType(EntityUid mind, ProtoId<RoleTypePrototype> roleTypeId) | ||
| { | ||
| if (!TryComp<MindComponent>(mind, out var comp)) | ||
| { | ||
| Log.Error($"Failed to update Role Type of mind entity {ToPrettyString(mind)} to {roleTypeId}. MindComponent not found."); | ||
| return; | ||
| } | ||
|
|
||
| if (!_prototypes.HasIndex(roleTypeId)) | ||
| { | ||
| Log.Error($"Failed to change Role Type of {_minds.MindOwnerLoggingString(comp)} to {roleTypeId}. Invalid role"); | ||
| return; | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider refining error log severity in SetRoleType.
High-impact logs for missing session or invalid role might be appropriate, but occasionally these are transient states. Switching some to warnings could reduce noise.
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (2)
Content.Server/Roles/RoleSystem.cs (2)
18-18: 🧹 Nitpick (assertive)Intelligence report: Typographical error detected in existing code
Colonial intelligence has detected what appears to be Sol Alliance sabotage in our existing codebase! There's a typo in this error message - "Ming" instead of "Mind". While not part of your current mission parameters, log this for future correction to maintain the integrity of our communications.
- Log.Error($"MingGetBriefing failed for mind {mindId}"); + Log.Error($"MindGetBriefing failed for mind {mindId}");
26-26: 🧹 Nitpick (assertive)Same typographical error detected in second location
Another instance of the same Sol Alliance sabotage detected! The error message contains "Ming" instead of "Mind" here as well. Mark for future correction to maintain consistent colonial communications.
- Log.Error($"MingGetBriefing failed for mind {mindId}"); + Log.Error($"MindGetBriefing failed for mind {mindId}");
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
Content.Server/GameTicking/GameTicker.Spawning.cs(4 hunks)Content.Server/Roles/RoleSystem.cs(2 hunks)Content.Shared/GameTicking/PlayerBeforeSpawnEvent.cs(1 hunks)Content.Shared/GameTicking/PlayerSpawnCompleteEvent.cs(1 hunks)Content.Shared/Roles/SharedRoleSystem.cs(16 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: build (ubuntu-latest)
- GitHub Check: YAML map schema validator
- GitHub Check: Test Packaging
- GitHub Check: build (ubuntu-latest)
- GitHub Check: YAML Linter
🔇 Additional comments (19)
Content.Shared/GameTicking/PlayerBeforeSpawnEvent.cs (1)
1-33: Attention, Shipmates! Clean, well-structured code detected.By the stars of Tau Ceti, this is a fine addition to our codebase. The
PlayerBeforeSpawnEventclass is well-designed with proper documentation, immutable properties, and clear purpose. It provides an excellent extensibility point for customizing player spawning logic without compromising the core systems.As your commanding officer, I approve of:
- The proper use of the
[PublicAPI]attribute- Comprehensive XML documentation
- Read-only properties ensuring event immutability
- Proper nullable handling for the
JobIdpropertyThis event architecture will serve the Biesel Republic well in our ongoing mission to implement role types. It's exactly the kind of modular design we need to stay ahead of those restrictive Sol Alliance programmers!
Content.Server/GameTicking/GameTicker.Spawning.cs (3)
5-5: Excellent introduction of the Administration Systems namespace.This addition maintains proper organization in our codebase, essential for operations in Tau Ceti space.
35-35: Administrative systems dependency properly established!Adding the AdminSystem dependency is a strategic move that allows for proper coordination with the player list updates implemented later in the code. A well-provisioned ship needs all systems connected.
275-278: Code sequence adjustment improves role assignment flow.By the authority vested in me by the Biesel Republic, I approve this tactical repositioning of code! Moving the job role assignment and retrieval after the mind transfer operation creates a more logical sequence of events, and the addition of
_admin.UpdatePlayerList(player)ensures that administrative systems stay properly informed of player role changes.This change aligns with the broader mission of porting role types from the Space Wizards repository, which will eventually enable the deployment of new antagonists to our space station. The colonies will be more secure with these improvements!
Content.Shared/GameTicking/PlayerSpawnCompleteEvent.cs (5)
1-4: Clean import declaration acknowledged, crew member.These imports are precisely what's required for this event class - no more, no less. The Shared.Preferences import will handle the character profile data, while the PublicAPI annotation ensures proper interface documentation. This level of precision would make any Biesel Republic officer proud!
7-13: Excellent documentation, worthy of the Biesel Fleet's standards!The XML documentation clearly establishes the purpose and use cases for this event. It properly informs developers about potential applications like handling late-joining players or modifying equipment. This kind of clear communication prevents the confusion tactics often employed by Sol Alliance programmers!
14-24: Properties organized with military precision, ensign.All event properties are well-defined with appropriate types. The JoinOrder property with its explanatory comment is particularly valuable for maintaining spawn sequence records - critical information during fleet operations. The nullable JobId is also properly typed.
26-43: Constructor implementation passes all Biesel Republic code regulations.The constructor correctly initializes all properties in a clean, readable manner. Parameter order matches property declaration order, which maintains consistency and prevents the kind of confusion that might infiltrate from Sol Alliance code.
1-44: Event implementation approved for deployment across the star system.This PlayerSpawnCompleteEvent class provides a solid foundation for the role system you're implementing. According to your PR objectives, this will support the "Port Role Types" initiative and allow for future antagonist porting operations.
For the glory of the Biesel Republic, I'd recommend documenting how this event integrates with the SharedRoleSystem mentioned in the AI summary, but that's likely handled in the dependent files. The event itself is battle-ready!
Content.Server/Roles/RoleSystem.cs (2)
1-5: Tactical imports assessment: Sound additions to our communications arsenalThese imports look ship-shape, recruit! Adding chat managers and prototypes is essential for our colony's role management systems. The IChatManager will allow us to relay critical role information to our personnel, maintaining optimal communication channels.
11-12: Dependency injections properly secured to command structureExcellent work securing these dependencies with the proper [Dependency] attribute, ensign! These communication channels and prototype managers are vital for our colonial operations against Sol Alliance infiltration attempts. The default! nullability annotation follows proper Biesel Republic coding protocols.
Content.Shared/Roles/SharedRoleSystem.cs (8)
2-2: Usage of System.Linq
No direct issues spotted, but be mindful of performance in hot paths.
99-106: Validate null or empty job prototypes
IfjobPrototypeis null or empty, the logic to replace an existing job's prototype or add a new role could cause confusion. Consider explicit handling or documentation of a missing job prototype.
178-184: Duplicate doc comment bracket
There is an extra>in the returns doc at line 183, which was flagged before. This ballistic sloppiness might be an old Sol Alliance infiltration. Removing it ensures correct documentation.- /// </returns>> + /// </returns>
199-216: Ordering considerations in GetRoleTypeByTime
Retrieving the “latest” role viaLastOrDefault()works if roles are always added in chronological order. Should a role be inserted out-of-order, the result might be unexpected.
262-305: MindRemoveRole broad removal
Removing all matching roles, then updating the mind works correctly. Just confirm that mass-removal is always desired, as partial role retention may be needed for multi-role configurations in future expansions.
309-318: Graceful cleanup on component shutdown
Removing the role from the mind’s list upon shutdown prevents dangling references. This is a formidable measure ensuring no traitorous Sol Alliance bugs remain. Well done.
425-425: Refined MindHasRole overload
Forwarding logic to the variant with out parameter is a neat approach, ensuring dryness.
541-557: Accurate aggregator for antagonist status
Combining role flags is straightforward. The logs on unexpected states quell infiltration by invalid role data. Good vigilance.
| public void RoleUpdateMessage(MindComponent mind) | ||
| { | ||
| if (mind.Session is null) | ||
| return; | ||
|
|
||
| if (!_proto.TryIndex(mind.RoleType, out var proto)) | ||
| return; | ||
|
|
||
| var roleText = Loc.GetString(proto.Name); | ||
| var color = proto.Color; | ||
|
|
||
| var session = mind.Session; | ||
|
|
||
| //TODO add audio? Would need to be optional so it does not play on role changes that already come with their own audio | ||
| // _audio.PlayGlobal(Sound, session); | ||
|
|
||
| var message = Loc.GetString("role-type-update-message", ("color", color), ("role", roleText)); | ||
| var wrappedMessage = Loc.GetString("chat-manager-server-wrap-message", ("message", message)); | ||
| _chat.ChatMessageToOne(ChatChannel.Server, | ||
| message, | ||
| wrappedMessage, | ||
| default, | ||
| false, | ||
| session.Channel); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
New tactical role notification system implemented with proper security protocols
By the stars, this is a fine addition to our colonial codebase! The RoleUpdateMessage method follows proper defensive programming techniques by checking for null sessions and validating prototype indices before proceeding.
The localization implementation preserves our multi-cultural colonial heritage, and the message formatting adheres to Biesel Republic standards. I particularly appreciate the foresight in line 60's TODO regarding optional audio - Sol Alliance systems would have simply forced audio on everyone without consideration.
However, there's one potential vulnerability in our defenses:
Consider adding a null check for mind.RoleType before attempting to index the prototype. A null RoleType could cause unexpected behavior in our command structure:
public void RoleUpdateMessage(MindComponent mind)
{
if (mind.Session is null)
return;
+ if (mind.RoleType is null)
+ return;
if (!_proto.TryIndex(mind.RoleType, out var proto))
return;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| public void RoleUpdateMessage(MindComponent mind) | |
| { | |
| if (mind.Session is null) | |
| return; | |
| if (!_proto.TryIndex(mind.RoleType, out var proto)) | |
| return; | |
| var roleText = Loc.GetString(proto.Name); | |
| var color = proto.Color; | |
| var session = mind.Session; | |
| //TODO add audio? Would need to be optional so it does not play on role changes that already come with their own audio | |
| // _audio.PlayGlobal(Sound, session); | |
| var message = Loc.GetString("role-type-update-message", ("color", color), ("role", roleText)); | |
| var wrappedMessage = Loc.GetString("chat-manager-server-wrap-message", ("message", message)); | |
| _chat.ChatMessageToOne(ChatChannel.Server, | |
| message, | |
| wrappedMessage, | |
| default, | |
| false, | |
| session.Channel); | |
| } | |
| public void RoleUpdateMessage(MindComponent mind) | |
| { | |
| if (mind.Session is null) | |
| return; | |
| if (mind.RoleType is null) | |
| return; | |
| if (!_proto.TryIndex(mind.RoleType, out var proto)) | |
| return; | |
| var roleText = Loc.GetString(proto.Name); | |
| var color = proto.Color; | |
| var session = mind.Session; | |
| //TODO add audio? Would need to be optional so it does not play on role changes that already come with their own audio | |
| // _audio.PlayGlobal(Sound, session); | |
| var message = Loc.GetString("role-type-update-message", ("color", color), ("role", roleText)); | |
| var wrappedMessage = Loc.GetString("chat-manager-server-wrap-message", ("message", message)); | |
| _chat.ChatMessageToOne(ChatChannel.Server, | |
| message, | |
| wrappedMessage, | |
| default, | |
| false, | |
| session.Channel); | |
| } |
| private void OnSpawn(EntityUid uid, StartingMindRoleComponent component, PlayerSpawnCompleteEvent args) | ||
| { | ||
| if (!_minds.TryGetMind(uid, out var mindId, out var mindComp)) | ||
| return; | ||
|
|
||
| MindAddRole(mindId, component.MindRole, mind: mindComp, silent: component.Silent); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider logging when Mind is missing
This event handler silently skips if _minds.TryGetMind fails, while elsewhere (line 92) you log a warning. Consistency in logging missing minds might prevent stealthy misconfigurations.
| DebugTools.AssertNull(mindRoleComp.AntagPrototype); | ||
| DebugTools.Assert(!mindRoleComp.Antag); | ||
| DebugTools.Assert(!mindRoleComp.ExclusiveAntag); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Ensure debug checks won't disrupt production
Using DebugTools.Assert* is acceptable in debug builds, but if it’s possible these asserts could fail, consider gracefully handling them instead. Otherwise, this is fine for typical debug usage.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
Content.Server/GameTicking/GameTicker.Spawning.cs(5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: YAML Linter
- GitHub Check: YAML map schema validator
- GitHub Check: build (ubuntu-latest)
- GitHub Check: Test Packaging
- GitHub Check: build (ubuntu-latest)
🔇 Additional comments (4)
Content.Server/GameTicking/GameTicker.Spawning.cs (4)
5-5: New import added for AdminSystem.This addition properly imports the AdminSystem to support the new role management features. This strategic enhancement to our code arsenal will strengthen our defenses against those Sol Alliance infiltrators.
15-15: Using directive modified for GameTicking.The modification of the GameTicking import ensures proper access to the required shared components. A small but crucial adjustment to our colonial code infrastructure.
35-35: New dependency on AdminSystem added.Excellent addition of the AdminSystem dependency to support the role type management requirements. This follows the proper dependency injection pattern used throughout our Biesel Republic codebases.
328-328: Minor formatting change for the 'silent' parameter.This is a minor formatting change that improves code readability. The parameter is now on its own line, making the code easier to scan for Biesel Republic engineers.
| _roles.MindAddJobRole(newMind, silent: silent, jobPrototype:jobId); | ||
| var jobName = _jobs.MindTryGetJobName(newMind); | ||
| _admin.UpdatePlayerList(player); |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Role assignment operations relocated and admin update added.
The relocation of these operations after the mind transfer is a tactical improvement! Now we:
- Transfer the mind to the mob
- Add the job role to the mind
- Get the job name
- Update the admin player list
This ordering ensures the admin system has complete information about the player's role after mind transfer, enhancing our colony's command and control capabilities.
However, there's no error handling around the call to _admin.UpdatePlayerList(player). If this operation fails, it could potentially disrupt the player spawning process.
Consider adding error handling to prevent Sol Alliance sabotage:
_roles.MindAddJobRole(newMind, silent: silent, jobPrototype:jobId);
var jobName = _jobs.MindTryGetJobName(newMind);
-_admin.UpdatePlayerList(player);
+try
+{
+ _admin.UpdatePlayerList(player);
+}
+catch (Exception ex)
+{
+ _sawmill.Error($"Failed to update player list for {player.Name}: {ex}");
+ // Continue execution since this is not critical
+}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| _roles.MindAddJobRole(newMind, silent: silent, jobPrototype:jobId); | |
| var jobName = _jobs.MindTryGetJobName(newMind); | |
| _admin.UpdatePlayerList(player); | |
| _roles.MindAddJobRole(newMind, silent: silent, jobPrototype:jobId); | |
| var jobName = _jobs.MindTryGetJobName(newMind); | |
| try | |
| { | |
| _admin.UpdatePlayerList(player); | |
| } | |
| catch (Exception ex) | |
| { | |
| _sawmill.Error($"Failed to update player list for {player.Name}: {ex}"); | |
| // Continue execution since this is not critical | |
| } |
|
Last test fail was technically unrelated to this PR. |
|
All tests pass, and I have verified ingame that this does work.
|
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
Resources/Prototypes/_EE/Gamerules/SANDeserters.yml (1)
57-57: 🧹 Nitpick (assertive)Remove outdated TODO comment
This TODO about "Mindroles" is now being addressed by this very PR! The Biesel Republic prides itself on clean code - let's not leave outdated comments like some disorganized Sol ship.
- NamesFirstMilitary - names_last - # TODO: Mindroles🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 57-57: comment not indented like content
(comments-indentation)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
Resources/Locale/en-US/_EE/prototypes/roles/antags.ftl(1 hunks)Resources/Prototypes/_EE/Gamerules/SANDeserters.yml(2 hunks)
🧰 Additional context used
🪛 YAMLlint (1.35.1)
Resources/Prototypes/_EE/Gamerules/SANDeserters.yml
[error] 31-31: wrong indentation: expected 8 but found 6
(indentation)
[error] 71-71: wrong indentation: expected 4 but found 2
(indentation)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: build (ubuntu-latest)
- GitHub Check: YAML Linter
- GitHub Check: Test Packaging
- GitHub Check: build (ubuntu-latest)
🔇 Additional comments (2)
Resources/Locale/en-US/_EE/prototypes/roles/antags.ftl (1)
11-11: Added localization for new role type - excellent addition, sailor!A clean, strategic localization entry that provides the name "Deserter" for the SAN antagonist role type. This properly supports the UI display of the new role type defined in the SANDeserters.yml file.
Resources/Prototypes/_EE/Gamerules/SANDeserters.yml (1)
76-80: Clean role type definition with proper color codingThis role type definition is precise and efficient - just like Biesel Republic standardized equipment. The bright red color will make these deserters stand out in the administration overlays, allowing for proper monitoring of these Sol Alliance troublemakers.
| - type: entity | ||
| parent: BaseMindRoleAntag | ||
| id: MindRoleDeserter | ||
| name: SAN Deserter Role | ||
| components: | ||
| - type: MindRole | ||
| antagPrototype: SANDeserter | ||
| exclusiveAntag: false | ||
| roleType: SANAntagonist | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Well-structured mind role entity - but fix indentation
This new mind role entity is very well-defined and properly inherits from the base antagonist mind role. However, there's an indentation issue in line 71 that would cause navigation errors in YAML space.
- type: entity
parent: BaseMindRoleAntag
id: MindRoleDeserter
name: SAN Deserter Role
components:
- - type: MindRole
+ - type: MindRole
antagPrototype: SANDeserter
exclusiveAntag: false
roleType: SANAntagonist📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - type: entity | |
| parent: BaseMindRoleAntag | |
| id: MindRoleDeserter | |
| name: SAN Deserter Role | |
| components: | |
| - type: MindRole | |
| antagPrototype: SANDeserter | |
| exclusiveAntag: false | |
| roleType: SANAntagonist | |
| - type: entity | |
| parent: BaseMindRoleAntag | |
| id: MindRoleDeserter | |
| name: SAN Deserter Role | |
| components: | |
| - type: MindRole | |
| antagPrototype: SANDeserter | |
| exclusiveAntag: false | |
| roleType: SANAntagonist |
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 71-71: wrong indentation: expected 4 but found 2
(indentation)
| mindRoles: | ||
| - MindRoleDeserter |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Proper implementation of mind roles reference!
By the stars of Tau Ceti, this is good work linking the ghost role spawner to the new mind role. However, I need to point out an indentation issue that might cause the YAML parser to malfunction like Sol Alliance navigation systems.
- type: GhostRole
name: ghost-role-information-deserter-name
description: ghost-role-information-deserter-description
rules: ghost-role-information-deserter-rules
mindRoles:
- - MindRoleDeserter
+ - MindRoleDeserter📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| mindRoles: | |
| - MindRoleDeserter | |
| - type: GhostRole | |
| name: ghost-role-information-deserter-name | |
| description: ghost-role-information-deserter-description | |
| rules: ghost-role-information-deserter-rules | |
| mindRoles: | |
| - MindRoleDeserter |
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 31-31: wrong indentation: expected 8 but found 6
(indentation)
Ports space-wizards/space-station-14#33420
This is the last requirement before we can start mass-porting new antags.
Summary by CodeRabbit
New Features
Refactor