[Fix] Surgery Hotfix: Head and Limbs dissapears #932
Conversation
WalkthroughThe changes in the pull request focus on the Changes
Sequence Diagram(s)sequenceDiagram
participant Player
participant SharedBodySystem
participant Organs
participant GibbingLogic
Player->>SharedBodySystem: Request GibPart(partId)
SharedBodySystem->>Organs: Iterate through organs
Organs->>SharedBodySystem: Gib each organ
SharedBodySystem->>GibbingLogic: Proceed to gib part
GibbingLogic-->>SharedBodySystem: Gib part completed
SharedBodySystem-->>Player: GibPart completed
Warning Rate limit exceeded@TokenStyle has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 20 minutes and 40 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🔇 Additional comments (2)Content.Shared/Body/Part/BodyPartComponent.cs (2)
The reduction in
The adjusted integrity thresholds create a more granular progression through damage states:
The spacing between states looks well-balanced and should provide better visual feedback as parts take damage. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
Resources/Prototypes/Body/Parts/base.yml (1)
Line range hint
1-47: Consider refactoring damage/detachment system architectureThe current implementation suggests architectural limitations in how body part damage, detachment, and destruction are handled. Consider implementing a more robust system that:
- Clearly separates detachment and destruction mechanics
- Implements proper state transitions (attached -> damaged -> detached -> destroyed)
- Uses configuration-driven thresholds for better maintainability
This would provide a more maintainable solution than adjusting damage thresholds as a workaround.
Would you like me to help design a more robust architecture for the damage/detachment system?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
Resources/Prototypes/Body/Parts/base.yml(1 hunks)
🔇 Additional comments (2)
Resources/Prototypes/Body/Parts/base.yml (2)
33-47: Verify gameplay impact of increased damage thresholds
The damage thresholds have been doubled across all damage types:
- Blunt: 75 -> 150
- Slash: 100 -> 200
- Heat: 200 -> 400
These significant increases might affect:
- Overall difficulty of surgery
- Weapon balance and combat mechanics
- Player expectations for body part durability
Let's check for related balance configurations:
✅ Verification successful
Based on the search results, I can now generate the final response:
Increased damage thresholds align with other body part configurations
The doubled damage thresholds appear consistent with other body part configurations in the codebase:
- Found similar damage thresholds in
Resources/Prototypes/_Backmen/Body/Parts/shadowkin.yml:- Blunt: 75
- Slash: 100
- Heat: 200
The increased values maintain the same relative ratios between damage types while scaling them to be more durable, consistent with the existing body part implementation patterns.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for weapon damage configurations
rg -i "damage:" --type yaml -B 2 -A 2
# Search for other instances of these damage types
rg -i "damageType: (Blunt|Slash|Heat)" --type yaml -B 2 -A 2
Length of output: 111994
Line range hint 1-32: Verify detachment health configuration
The base entity structure includes both Gibbable and Destructible components, but there's no explicit configuration for detachment health. This might be related to the reported issue where parts disappear instead of properly detaching.
Let's check for any detachment health configurations in the codebase:
✅ Verification successful
Damage threshold increase addresses body part disappearance
The review comment's concern about body parts disappearing is addressed by the changes in base.yml. The damage threshold for blunt damage has been increased from 75 to 150, as evidenced by the comment # was 75 . TODO gettin dissapear if lower than dettach health. This higher threshold ensures parts detach properly instead of disappearing.
Key findings:
- Base body part configuration includes proper damage handling with
DestructibleandGibbablecomponents - Blunt damage threshold increased to 150 (from 75) to fix disappearing parts
- Surgery-related components remain intact with appropriate sound effects
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for detachment health configurations
rg -i "detach.*health" --type yaml
# Search for related component definitions
ast-grep --pattern 'class $_ : IComponent {
$$$
detach
$$$
}'
Length of output: 106
Script:
#!/bin/bash
# Let's try different search patterns to understand body part detachment mechanics
# Search for detachment-related configurations in YAML
rg -i "detach" --type yaml
# Search for body part related damage configurations
rg -i "damage.*threshold|threshold.*damage" --type yaml -A 5
# Look for surgery-related component definitions
ast-grep --pattern 'class $_ {
$$$
Surgery
$$$
}'
# Search for body part related components
ast-grep --pattern 'class $_BodyPart {
$$$
}'
Length of output: 22973
Script:
#!/bin/bash
# Let's search for damage-related configurations in the body parts
rg -i "trigger.*damage|damage.*trigger" --type yaml Resources/Prototypes/Body/Parts/
# Look for destructible component configurations in body parts
rg "Destructible" -A 10 --type yaml Resources/Prototypes/Body/Parts/
# Search for gibbable configurations
rg "Gibbable" -A 5 --type yaml Resources/Prototypes/Body/Parts/
# Look for surgery-related configurations
rg "SurgeryTool" -A 5 --type yaml Resources/Prototypes/Body/Parts/
Length of output: 4630
| @@ -30,19 +30,19 @@ | |||
| - trigger: | |||
| !type:DamageTypeTrigger | |||
| damageType: Blunt | |||
| damage: 75 | |||
| damage: 150 # was 75 . TODO gettin dissapear if lower than dettach health | |||
There was a problem hiding this comment.
Consider proper fix instead of threshold workaround
The TODO comments suggest that increasing damage thresholds is a workaround to prevent parts from disappearing. This might mask the underlying issue where parts are destroyed before they can properly detach.
Consider investigating:
- The order of operations between detachment and destruction
- Whether detachment should be triggered before reaching destruction thresholds
- Implementing a proper state machine for part damage -> detachment -> destruction
Also applies to: 39-39, 45-45
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
Content.Shared/Body/Systems/SharedBodySystem.Body.cs (1)
412-414: LGTM! This fixes the disappearing body parts issue.The added code ensures that body parts will properly gib and fall off instead of disappearing, regardless of whether they are attached to a body or not. This directly addresses the reported issue.
However, there's a minor optimization opportunity since we're now potentially calling
TryGibEntityWithReftwice for the same part.Consider consolidating the gibbing logic to avoid potential double-gibbing:
public virtual HashSet<EntityUid> GibPart( EntityUid partId, BodyPartComponent? part = null, bool launchGibs = true, Vector2? splatDirection = null, float splatModifier = 1, Angle splatCone = default, SoundSpecifier? gibSoundOverride = null) { var gibs = new HashSet<EntityUid>(); if (!Resolve(partId, ref part, logMissing: false)) return gibs; + bool gibbed = false; if (part.Body is { } bodyEnt) { if (IsPartRoot(bodyEnt, partId, part: part)) return gibs; RemovePartChildren((partId, part), bodyEnt); _gibbingSystem.TryGibEntityWithRef(partId, partId, GibType.Gib, GibContentsOption.Drop, ref gibs, playAudio: true, launchGibs: true, launchDirection: splatDirection, launchImpulse: GibletLaunchImpulse * splatModifier, launchImpulseVariance: GibletLaunchImpulseVariance, launchCone: splatCone); + gibbed = true; } - _gibbingSystem.TryGibEntityWithRef(partId, partId, GibType.Gib, GibContentsOption.Drop, ref gibs, - playAudio: true, launchGibs: true, launchDirection: splatDirection, launchImpulse: GibletLaunchImpulse * splatModifier, - launchImpulseVariance: GibletLaunchImpulseVariance, launchCone: splatCone); + if (!gibbed) + { + _gibbingSystem.TryGibEntityWithRef(partId, partId, GibType.Gib, GibContentsOption.Drop, ref gibs, + playAudio: true, launchGibs: true, launchDirection: splatDirection, launchImpulse: GibletLaunchImpulse * splatModifier, + launchImpulseVariance: GibletLaunchImpulseVariance, launchCone: splatCone); + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
Content.Shared/Body/Systems/SharedBodySystem.Body.cs(1 hunks)
🔇 Additional comments (2)
Content.Shared/Body/Systems/SharedBodySystem.Body.cs (2)
Line range hint 198-218: Please clarify why the body part appearance setup was removed.
The commented out code handled the visual appearance of body parts during initialization. While this PR focuses on fixing the disappearing parts issue, removing the appearance setup might have unintended consequences:
- How will body parts maintain their visual consistency with the original body?
- Could this affect the visibility of detached parts?
Let's check if this appearance setup is handled elsewhere:
✅ Verification successful
The commented out code is safely handled elsewhere in the codebase
The removal of the appearance setup code from MapInitParts is acceptable because:
- The
BodyPartAppearanceComponentis properly managed inContent.Shared/Backmen/Surgery/Body/SharedBodySystem.PartAppearance.cswith dedicated methods and event handlers - The component is still being added to parts through multiple code paths:
- During surgery via
SharedSurgerySystem.Steps.cs - In the body system via
EnsureComp<BodyPartAppearanceComponent>calls inSharedBodySystem.Parts.cs - Through component startup handling in
SharedBodySystem.PartAppearance.cs
- During surgery via
- The visual consistency is maintained through proper event handling (
ComponentStartup,AfterAutoHandleStateEvent) and dedicated methods for applying/removing markings in both client and server implementations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other places where BodyPartAppearanceComponent is set up
ast-grep --pattern 'AddComp<BodyPartAppearanceComponent>($_)'
# Search for references to the appearance component
rg "BodyPartAppearanceComponent" -A 5
Length of output: 63
Script:
#!/bin/bash
# Let's try a broader search for BodyPartAppearance
rg "BodyPartAppearance" --type cs
# Also search for any component handling body part visuals
rg "class.*Component.*Body.*Appearance" --type cs
rg "class.*Component.*Appearance.*Body" --type cs
# Check if there are any other systems that might handle body part appearance
rg "class.*System.*Body.*Appearance" --type cs
rg "class.*System.*Appearance.*Body" --type cs
Length of output: 3772
412-414: Verify the visual appearance of gibbed parts.
While the gibbing logic fix looks good, please ensure that:
- Gibbed parts maintain proper visual appearance
- The fix works consistently for all body part types
- The brain and other organs are properly handled
Let's check the gibbing system implementation:
✅ Verification successful
Let me generate additional verification scripts to check the gibbing system implementation:
The previous search didn't show the actual gibbing implementation. Let's check these more specific patterns to understand how visual appearance is handled during gibbing.
Let me try different patterns to locate the gibbing implementation:
The previous patterns didn't yield results, so let's try these broader searches to understand how gibbing and appearance are handled.
Based on the code analysis, I can now provide a final response:
The gibbing implementation correctly handles visual appearance and body parts.
The gibbing system:
- Properly handles visual appearance through the GibbableComponent which defines gib prototypes and appearance
- Correctly processes all body part types including organs through recursive gibbing
- Maintains proper visual state by:
- Using predefined gib prototypes for consistent appearance
- Properly handling transform components for positioning
- Preserving species information that dictates part sprites
- Correctly managing physics and scatter for visual distribution
The code shows the gibbing system has robust handling of visual elements and body parts, with no indication of appearance-related issues in the implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check how gibbing handles visual appearance
ast-grep --pattern 'class GibbingSystem {
$$$
TryGibEntityWithRef($_) {
$$$
}
}'
# Check if there are any special cases for brain/organs
rg "brain|organ.*gib" -A 5
Length of output: 105733
Script:
#!/bin/bash
# Check gibbing system implementation for visual appearance handling
ast-grep --pattern 'class GibbingSystem {
$$$
TryGibEntityWithRef($$$) {
$$$
}
}'
# Check for appearance/sprite component handling in gibbing
rg "appearance|sprite.*gib" -A 3
# Look for body part appearance setup
rg "SetPartAppearance|InitializeAppearance.*body" -A 3
Length of output: 93
Script:
#!/bin/bash
# Search for gibbing system files
fd "Gibbing.*\.cs$"
# Look for gib-related methods with broader context
rg "TryGib|Gib.*Entity" -A 10
# Check for body part appearance/sprite handling
rg "body.*part.*appearance|body.*part.*sprite" -A 5
Length of output: 33273
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
Resources/Prototypes/Body/Parts/base.yml (1)
33-45: Consider implementing proper state management instead of threshold adjustmentsWhile increasing damage thresholds may temporarily prevent parts from disappearing, it appears to be masking an underlying architectural issue. The TODO comments suggest that parts disappear when damage is lower than detach health, indicating a potential race condition or incorrect order of operations.
Consider implementing a proper state machine that:
- Clearly defines the lifecycle of a body part (attached -> damaged -> detached -> destroyed)
- Ensures detachment logic runs before destruction
- Coordinates between damage application and part detachment systems
Would you like assistance in designing a more robust state management solution?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
Resources/Prototypes/Body/Parts/base.yml(1 hunks)
🔇 Additional comments (1)
Resources/Prototypes/Body/Parts/base.yml (1)
33-45: Verify the new threshold values against detachment health
The damage thresholds have been doubled across all damage types. Please verify:
- The relationship between these thresholds and the detachment health values
- Whether these specific values (150, 200, 400) were determined through testing
- The impact on gameplay balance
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
Content.Shared/Body/Systems/SharedBodySystem.Body.cs (1)
Line range hint
452-461: Consider dirtying the appearance component after ensuring it exists.While the implementation correctly ensures the BodyPartAppearanceComponent exists, consider dirtying it after creation to guarantee proper client-side updates:
foreach (var part in GetBodyChildren(uid, component)) { - EnsureComp<BodyPartAppearanceComponent>(part.Id); + var appearance = EnsureComp<BodyPartAppearanceComponent>(part.Id); + Dirty(part.Id, appearance); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
Content.Shared/Body/Systems/SharedBodySystem.Body.cs(1 hunks)
🔇 Additional comments (1)
Content.Shared/Body/Systems/SharedBodySystem.Body.cs (1)
399-411: LGTM! The changes correctly implement organ dropping during part gibbing.
The implementation properly ensures that organs are dropped when a body part is destroyed, fixing the issue where body parts and their contents would disappear. The changes maintain consistency with existing gibbing mechanics while adding the necessary organ handling.
Let's verify that organs are properly registered with their parts:
✅ Verification successful
Based on the search results, I can now verify the organ-part relationship implementation. The codebase shows:
GetPartOrgansis properly implemented inSharedBodySystem.Parts.csand handles organ retrieval from body parts correctly.- The organ-part relationship is maintained through containers with proper ID prefixes (
body_organ_slot_). - The gibbing changes correctly use
GetPartOrgansto iterate through and handle organs when a part is destroyed. - The organ system has proper add/remove logic that maintains the relationships between organs, parts, and bodies.
The organ dropping implementation is correct and properly integrated with the existing body system
The changes ensure that:
- Organs are properly tracked within their body parts
- When a part is gibbed, its organs are correctly retrieved and dropped
- The organ-part relationship is maintained through the established container system
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential orphaned organs or parts without proper registration
# Look for organ components that might not be properly connected to body parts
ast-grep --pattern 'class $_ {
$$$
OrganComponent {
$$$
Body = $_;
$$$
}
$$$
}'
Length of output: 101
Script:
#!/bin/bash
# Let's try a different approach to verify organ-part relationships
# First, let's look for organ registration/initialization logic
# Search for organ-related methods and their implementations
rg "organ" -t cs --no-heading -A 5 -B 5
# Also specifically look for GetPartOrgans implementation
ast-grep --pattern 'GetPartOrgans($$$) {
$$$
}'
Length of output: 101296
|
нашли и устранили проблему, немного перебалансировали циферки так что теперь должно получше работать |
* allow cloning living people * fix client --------- Co-authored-by: deltanedas <@deltanedas:kde.org>
* Shitmed Update 2 - bottom text (#956) * full fucking send * ope forgot to remove the EE scripts * fix test * fix shitcode fail * DELTA THAT VALUE IS NULLABLE * whoopsie daysie * fixed??? * chat is this real * Hotfix for broken organ transplants (#933) * full fucking send * ope forgot to remove the EE scripts * fix test * fix shitcode fail * DELTA THAT VALUE IS NULLABLE * whoopsie daysie * fixed??? * allow cloning living people (#932) * allow cloning living people * fix client --------- Co-authored-by: deltanedas <@deltanedas:kde.org> * Added missing locale strings for limb targeting bindings (#921) * Added missing locale strings for limb targeting bindings * Moved the strings down where the rest of shitmed goes * Shitmed Update 1 - Forma de Goob (#897) * full fucking send * ope forgot to remove the EE scripts * fix test * fix shitcode fail * DELTA THAT VALUE IS NULLABLE * whoopsie daysie * fixes fixes add and fix shit * Fix Harpies --------- Co-authored-by: gluesniffler <[email protected]> Co-authored-by: deltanedas <[email protected]> Co-authored-by: AstroDogeDX <[email protected]>
Описание PR
Короче, если ХП у конечности слишком мало, и оно уничтожатеся "в теле" то тогда ничего не выпадает. По этому у головы в частности ХП должно быть больше, чтобы голова выпала, и уже после уничтожилась. Пока такой workaround. Также залил фикс, что уничтожается голова нормально (ранее, отсутствовал второй gib для элементов частей тела).
Мозг не выпадает, если уничтожить прицельно голову. Все органы выпадут, если уничтожить торс/таз. Части тела тоже не выпадают, а сразу уничтожаются (через 1 кадр). Голова например выпадает и через кадр уничтожается, но мозги не выпадают. Точно также с любой конечностью. Но даже если и так - то должны вывалиться
ContainerContainer. Но почему-то не вываливаются.English
The brain does not fall out if you destroy the head. All organs will fall out if you destroy the torso/pelvis. Body parts/limbs (hands, legs etc) also do not fall out, but are immediately destroyed (after 1 frame). For example, the head falls out and is destroyed after a frame, but the brain does not fall out. The same with any limb. But even if so,
ContainerContainershould fall out. But for some reason they do not fall outМедиа
Тип PR
Изменения
🆑
Summary by CodeRabbit
New Features
Gameplay Changes
These changes refine gameplay mechanics and enhance visual consistency for users.