Pr #146
Pr #146
Conversation
WalkthroughThe pull request introduces modifications across various YAML files and a new JSON file, primarily focusing on defining and updating entities related to lights and airlocks. New entities for different types of light bulbs and airlocks are added, while existing entities receive updates to their attributes, such as colors, energy consumption, and sprite paths. The changes also include adjustments to game rules, player requirements, and the introduction of new states and metadata for graphical resources, enhancing the overall configuration and organization of game mechanics. Changes
Suggested labels
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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 (
|
|
RSI Diff Bot; head commit 6bcfbc1 merging into 42a429b Resources/Textures/DeltaV/Objects/Misc/id_cards.rsi
Resources/Textures/NES/Objects/Devices/pda.rsi
Resources/Textures/NES/Objects/Misc/id_cards.rsi
Resources/Textures/NES/Structures/Doors/Airlocks/Standard/freezer.rsi
Resources/Textures/NES/Structures/Storage/tanks.rsi
Resources/Textures/NES/Structures/Wallmounts/switch.rsi
Resources/Textures/Structures/Shuttles/thruster.rsi
Resources/Textures/Clothing/Neck/Misc/dinkystar.rsi
Resources/Textures/Clothing/OuterClothing/WinterCoats/coatwardenarmored.rsi
Resources/Textures/NES/Mobs/Effects/Resomi/brute_damage.rsi
Resources/Textures/NES/Structures/Decoration/chairs.rsi
Resources/Textures/NES/Structures/Power/computer.rsi
Resources/Textures/Structures/Wallmounts/signs.rsi
Resources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (8)
Resources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/meta.json (2)
1-8: Consider standardizing the copyright formatThe copyright attribution "NES-Station : Aserovich" uses a non-standard format with a colon. Consider using a more conventional format like "© 2024 NES-Station, Aserovich" for clarity and consistency.
128-196: Review animation timing patternsSeveral observations about the animation timings:
- Emergency animation (1.2s per frame) seems unusually slow compared to other states (0.1s per frame)
- Sparks_broken has an extra long delay (1.7s) at the end that's inconsistent with other spark animations
Consider adjusting the timings for better consistency:
{ "name": "emergency_unlit", "delays": [ [ - 1.2, - 1.2 + 0.6, + 0.6 ] ] },{ "name": "sparks_broken", "delays": [ [ 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, - 1.7 + 0.1 ] ] },Resources/Prototypes/game_presets.yml (1)
Line range hint
39-230: Consider implementing a comprehensive low-population server frameworkThe consistent pattern of reducing player requirements and adjusting voting options suggests these changes are targeted at lower population servers. To make this more maintainable and flexible:
Consider creating a server population profile system that would:
- Allow different minimum player requirements based on server configuration
- Automatically adjust game mechanics and voting options based on typical player counts
- Provide built-in scaling mechanisms for all game modes
This would make it easier to maintain both high and low population server configurations without requiring separate changes to each game mode.
Resources/Prototypes/Entities/Structures/Doors/Airlocks/airlocks.yml (1)
Line range hint
227-307: Inconsistent sprite paths in glass airlock variantsSimilar to the standard airlocks, some glass variants still use the old sprite path format:
AirlockSyndicateGlassAirlockMiningGlassConsider updating these entities to use the new
NES/sprite path prefix for consistency.Resources/Prototypes/Entities/Structures/Doors/Airlocks/assembly.yml (1)
Based on the search results, I can now generate the final response:
Sprite files need to be included in the PR for door resprites
The PR changes reference sprite files with the comment "#Delta V - Resprite Doors", but these files are not included in the changed files list. The following sprite paths need to be added to the PR:
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/Standard/atmospherics.rsi
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/Glass/atmospherics.rsi
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/Standard/freezer.rsi
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/Standard/hydroponics.rsi
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/Glass/hydroponics.rsi
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/Standard/virology.rsi
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/Glass/virology.rsi
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/Standard/centcomm.rsi
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/Glass/centcomm.rsi
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/Standard/syndicate.rsi
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/Glass/syndicate.rsi
- Resources/Textures/DeltaV/Structures/Doors/Airlocks/highsec/highsec.rsi
🔗 Analysis chain
Line range hint
1-400: Verify sprite assets are included in the PRSince this PR includes resprites for doors, we should verify that all the referenced sprite assets exist and are included in the PR.
Let me verify if the sprite files are present in the repository by searching for them.
Let me try a different approach to locate the sprite files.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all referenced sprite files are included in the PR # Get the list of changed files in the PR echo "Changed files in PR:" gh pr view 146 --json files -q '.files[].path' # Extract all sprite paths from the YAML echo "Sprite paths referenced in YAML:" rg "sprite: .*\.rsi" Resources/Prototypes/Entities/Structures/Doors/Airlocks/assembly.yml | \ sed -E 's/.*sprite: (.*)\.rsi.*/\1.rsi/' | sort -u # Compare to ensure all sprite files are includedLength of output: 2900
Script:
#!/bin/bash # Check if the referenced sprite files exist in the repository echo "Checking for NES sprite files:" fd -e rsi "^(atmospherics|cargo|centcomm|command|coridor|engineering|external|freezer|hydroponics|medical|science|security|shuttle|virology)\.rsi$" -p "NES/Structures/Doors/Airlocks" echo -e "\nChecking for base sprite files:" fd -e rsi "^(clockwork_pinion|maint|mining|shuttle_syndicate|syndicate|highsec)\.rsi$" -p "Structures/Doors/Airlocks"Length of output: 680
Script:
#!/bin/bash # Search for RSI files in Resources/Textures directory echo "Searching for sprite files in Resources/Textures:" # First, check if the directories exist echo "Directory structure for NES sprites:" fd -t d "NES" Resources/Textures echo -e "\nSearching for all RSI files:" fd -e rsi . Resources/Textures | grep -E "(NES|Structures)/.*Doors/Airlocks"Length of output: 10339
Resources/Prototypes/GameRules/roundstart.yml (1)
Line range hint
297-318: LGTM: Zombie mode improvements enhance gameplay flowThe changes improve the Zombie game mode through:
- A 5-minute grace period before zombie transformation
- Better component organization using DelayedRule
- Consistent player count adjustment (15 → 10) with other modes
Consider adding a comment explaining the gameplay impact of the 5-minute delay to help future maintainers understand the design decision.
- type: DelayedRule # DeltaV: Grace period of 5 minutes before you can turn, to avoid a random passenger ruining your plan + # The 5-minute delay gives players time to develop strategies and prevents immediate chaos from random infections delay: 300Resources/Prototypes/GameRules/events.yml (2)
Line range hint
251-269: Review combat event balance changesThe significant reduction in weights and increase in player requirements for combat events (DragonSpawn weight: 6.5→1, minimumPlayers: 20→45) makes these events much rarer and restricted to high-population servers. While this may improve game balance, it might overly restrict content accessibility.
Consider implementing a scaling difficulty system instead of fixed high player requirements, allowing these events to occur with fewer players but with adjusted challenge levels.
Line range hint
1-24: Consider adding event metrics trackingGiven the significant number of balance changes in this update, it would be valuable to implement metrics tracking for:
- Event occurrence frequencies
- Player counts during events
- Event success/failure rates
This would help validate these balance changes and inform future adjustments.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (28)
Resources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/assembly.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/bolted_open_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/bolted_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/closed.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/closed_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/closing.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/closing_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/deny_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/emergency_open_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/emergency_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/open.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/open_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/opening.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/opening_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/panel_closed.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/panel_closing.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/panel_open.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/panel_opening.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/sparks.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/sparks_broken.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/sparks_damaged.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/sparks_open.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/welded.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Standard/freezer.rsi/assembly.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Standard/freezer.rsi/closed.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Standard/freezer.rsi/opening.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Wallmounts/switch.rsi/off.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Wallmounts/switch.rsi/on.pngis excluded by!**/*.png
📒 Files selected for processing (10)
Resources/Prototypes/Entities/Objects/Power/lights.yml(1 hunks)Resources/Prototypes/Entities/Structures/Doors/Airlocks/airlocks.yml(1 hunks)Resources/Prototypes/Entities/Structures/Doors/Airlocks/assembly.yml(1 hunks)Resources/Prototypes/Entities/Structures/Doors/Airlocks/base_assembly.yml(1 hunks)Resources/Prototypes/Entities/Structures/Lighting/base_lighting.yml(3 hunks)Resources/Prototypes/Entities/Structures/hydro_tray.yml(1 hunks)Resources/Prototypes/GameRules/events.yml(3 hunks)Resources/Prototypes/GameRules/roundstart.yml(1 hunks)Resources/Prototypes/game_presets.yml(5 hunks)Resources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/meta.json(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- Resources/Prototypes/Entities/Structures/Doors/Airlocks/base_assembly.yml
🔇 Additional comments (19)
Resources/Prototypes/Entities/Structures/hydro_tray.yml (1)
12-12: LGTM! Verify the adjusted collision bounds.
The expanded collision box should fix the hydroponics collision detection issues mentioned in the PR objectives. The box is now taller (extending more downward) while maintaining the same width.
✅ Verification successful
Bounds adjustment is consistent with similar entities
The collision bounds change (-0.45,-0.45,0.45,0.1) is verified to be appropriate because:
- It matches exactly with the
hydroponicsSoilentity, which is a related structure - Similar bounds are used by other low-profile structures like beds (
0.45,0.05) and stasis beds (0.45,0.05) - The width (
-0.45to0.45on X-axis) is a common standard used across many structure entities - The lowered top boundary (
0.1) is consistent with the visual profile of a hydroponics tray
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any other hydroponics-related entities that might need similar collision adjustments
rg -l "hydroponics" Resources/Prototypes/Entities/
Length of output: 1049
Script:
#!/bin/bash
# Check soil.yml for similar collision bounds as it might be related
cat Resources/Prototypes/Entities/Structures/soil.yml
# Also check for any other entities with similar bounds pattern
rg "bounds.*-0\.45.*0\.45" Resources/Prototypes/Entities/
Length of output: 5428
Resources/Textures/NES/Structures/Doors/Airlocks/Glass/maint.rsi/meta.json (1)
1-197: JSON structure is valid
The overall structure is well-formed and follows proper JSON formatting.
Resources/Prototypes/game_presets.yml (3)
82-82: Verify impact of removing Extended mode from voting options
While the comment suggests this mode is "2boring2vote", removing it from voting options limits player choice, particularly for those who prefer a more relaxed gameplay experience.
Let's check if there are alternative relaxed gameplay modes available in voting:
✅ Verification successful
Removing Extended mode from voting options is appropriate
Looking at the available presets, there are suitable alternatives for relaxed gameplay:
- "Secret" mode is available for voting and can potentially provide similar gameplay
- "Survival" mode is also voteable and appears to be a balanced preset
- Extended mode's rules are largely covered by other presets, making it redundant in the voting pool
The change aligns with the server's design goals while maintaining sufficient gameplay variety through other available options.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for game presets with showInVote: true
rg "showInVote:\s*true" Resources/Prototypes/
Length of output: 362
Script:
#!/bin/bash
# Let's see the full game preset configurations to understand available modes
cat Resources/Prototypes/game_presets.yml
Length of output: 5895
39-39: Consider gameplay balance with reduced player count
Running multiple game modes (Nukeops, Traitor, Revolutionary, Zombie) simultaneously with only 10 players could overwhelm the remaining crew members and impact gameplay balance negatively.
Let's analyze the typical player roles needed for these modes:
Consider either:
- Increasing the minimum player count to ensure balanced gameplay
- Implementing a scaling mechanism that enables only a subset of modes based on the actual player count
✅ Verification successful
Minimum player requirement reduction is appropriate
The reduction to 10 players for the AllAtOnce preset is actually consistent with the individual game mode requirements:
- Individual antag modes (Traitor, Revolutionary, Nukeops, Zombie) have also been adjusted to require 10 players
- The change is part of a broader "Stray" modification pattern reducing player requirements across multiple game modes
- Most regular maps support 10-15 players as their minimum
- Event rules are configured to scale with population, with many having 10-15 player minimums
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for role requirements in game mode configurations
rg -A 5 "required.*role|minimum.*players" Resources/Prototypes/GameRules/
Length of output: 75
Script:
#!/bin/bash
# Let's try searching for role/player requirements in different ways and locations
echo "=== Searching for player counts and roles in game presets ==="
rg -i "minplayers|players.*required|minimum.*players" Resources/Prototypes/
echo -e "\n=== Checking game rules configurations ==="
rg -i "role|players" Resources/Prototypes/GameRules/
echo -e "\n=== Looking at the full game_presets.yml for context ==="
cat Resources/Prototypes/game_presets.yml
Length of output: 20803
190-190: Review balance implications of reduced player requirements
The consistent reduction to 10 minimum players across Nukeops, Revolutionary, and Zombie modes suggests a deliberate rebalancing for lower population servers. However, these modes traditionally require a balance between antagonists and crew members.
Consider implementing the following adjustments to maintain gameplay balance:
- Scale the number of antagonists based on the actual player count
- Adjust antagonist objectives to be achievable with fewer crew members
- Add additional mechanical support for low-population scenarios (e.g., AI assistants, automated defense systems)
Let's analyze the current antagonist ratios:
Also applies to: 209-209, 230-230
Resources/Prototypes/Entities/Structures/Doors/Airlocks/airlocks.yml (4)
Line range hint 1-307: Verify department rename impacts
The renaming of departments (Cargo → Logistics, Science → Epistemics) has been consistently applied across airlock entities. However, these changes might affect other systems that reference these department names.
✅ Verification successful
Based on the output, I can generate the final response as we have comprehensive information about the department renames across the codebase.
Department renames have been consistently implemented
The department renames (Cargo → Logistics, Science → Epistemics) have been thoroughly and consistently applied across the entire codebase, including:
- Entity definitions (airlocks, lockers, signs, etc.)
- Job configurations and roles
- Access control systems
- Clothing and equipment descriptions
- Department-specific items and prototypes
All instances are properly commented with "# DeltaV - Logistics Department replacing Cargo" or "# DeltaV - Epistemics Department replacing Science", indicating an intentional and systematic change.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any remaining references to old department names
echo "Checking for old department references..."
rg -i "department.*cargo" --type yaml
rg -i "department.*science" --type yaml
# Check for any potential department-based access controls
echo "Checking access control configurations..."
fd "access" -e yml | xargs rg -l "cargo|science"
Length of output: 23701
Line range hint 220-226: Verify the "DO NOT MAP" restriction
The comment indicates that AirlockHydroponicsGlass should not be mapped as it's not resprited yet. This needs verification to prevent broken sprites in-game.
✅ Verification successful
DO NOT MAP restriction is valid and correctly marked
The entity AirlockHydroponicsGlass is correctly marked with "DO NOT MAP" in the suffix, with an explicit comment indicating it's not resprited yet. While the entity is not used in any maps (verified by the empty search results), it's still referenced by AirlockHydroGlassLocked as its parent. The sprite path has been updated to the new NES path, but the "DO NOT MAP" restriction should remain until fully verified by the development team.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if this entity is currently used in any maps
echo "Checking for usage of AirlockHydroponicsGlass in maps..."
rg "AirlockHydroponicsGlass" Resources/Maps/
Length of output: 167
Script:
#!/bin/bash
# Let's verify if the entity exists and check its current state
echo "Checking the entity definition and its sprite path..."
rg -A 10 "AirlockHydroponicsGlass" Resources/Prototypes/
# Also check if there are any DO NOT MAP comments
echo -e "\nChecking for DO NOT MAP comments..."
rg -B 2 -A 2 "DO NOT MAP" Resources/Prototypes/
Length of output: 25496
Line range hint 1-156: Inconsistent sprite path updates detected
Some airlock entities still use the old sprite path format while others have been updated to the new NES/ prefix. This inconsistency should be addressed for:
AirlockSyndicateAirlockMining
Consider updating these entities to use the new NES/ sprite path prefix for consistency.
Line range hint 1-307: Verify implementation of glass tech door
The PR objectives mention a "glass tech door" (стеклянный тех шлюз), but it's not clearly visible in these changes. Please clarify if this is implemented elsewhere or still pending.
Would you like help implementing the glass tech door if it's missing?
Resources/Prototypes/Entities/Objects/Power/lights.yml (1)
201-203: LGTM: Light adjustments align with PR objectives.
The changes to the fluorescent light tube enhance the lighting as intended:
- Brighter color (#b6c7d6)
- Increased light radius (8 units)
- Balanced light energy (0.8)
Let's verify the lighting changes don't cause performance issues:
✅ Verification successful
Light radius adjustment is consistent with existing configurations
The verification shows that:
- The new light radius of 8 units matches several other light configurations in the codebase
- Light radius values in the game range from 1.5 to 15 units
- The chosen value of 8 is within the common range used for standard lighting fixtures
No performance-related configurations or warnings were found in the codebase regarding light settings.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for other light-related configurations that might need adjustment
# Look for any performance-related configurations or comments
# Search for light performance settings
rg -i "performance.*light|light.*performance"
# Search for other light radius configurations to ensure consistency
ast-grep --pattern 'lightRadius: $_'
Length of output: 2635
Resources/Prototypes/Entities/Structures/Doors/Airlocks/assembly.yml (1)
Line range hint 1-400: Inconsistent sprite path updates across entities
Some entities still use the old sprite path structure without the "NES" prefix (e.g., Mining, Maintenance, Clockwork), while others have been updated. This inconsistency should be addressed.
Consider:
- Updating all sprite paths consistently to use the new "NES" prefix
- Creating a central configuration for sprite path prefixes to make future updates easier
Resources/Prototypes/GameRules/roundstart.yml (3)
Line range hint 241-260: LGTM: Revolutionary balance changes appear well-considered
The changes to the Revolutionary game mode maintain balance by:
- Reducing maximum Head Revolutionaries from 3 to 2
- Increasing player ratio from 15 to 30
These adjustments should result in more balanced revolutionary teams relative to station population.
Line range hint 419-432: Verify event timing adjustments across different server populations
The changes to event scheduling parameters affect the overall game pacing:
- BasicStationEventScheduler: Events can now occur between 3-10 minutes
- RampingStationEventScheduler: Modified chaos and end time values
Please ensure these timings have been tested with various server populations to maintain an engaging gameplay experience.
✅ Verification successful
Event timing configurations appear well-distributed and balanced
The event timing configurations show a thoughtful progression across different event types:
- Basic events (3-10 minutes)
- Glimmer events (5-25 minutes)
- Regular events (10-30 minutes)
- Visitor events (20-120 minutes)
The timing distribution creates a natural escalation of events while maintaining breathing room between them. The chaos value of 4.5 and end time of 180 minutes are reasonable defaults that allow for dynamic adjustment based on server conditions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other event-related timing configurations
rg "minMaxEventTiming|averageChaos|averageEndTime" | grep -v "^#"
Length of output: 661
Script:
#!/bin/bash
# Let's check the actual values in these files
cat Resources/Prototypes/GameRules/roundstart.yml Resources/Prototypes/GameRules/meteorswarms.yml Resources/Prototypes/DeltaV/GameRules/glimmer_events.yml | grep -A 2 "minMaxEventTiming\|averageChaos\|averageEndTime"
Length of output: 903
99-99: Consider the balance implications of halving the minimum player requirement
Reducing the minimum players from 20 to 10 for the Nukeops game mode is a significant change that could impact game balance. With fewer players:
- The station might have insufficient personnel to defend against a nuclear operative team
- The ratio of operatives to station crew might become unbalanced
- The challenge level might become too difficult for the defending side
Let's check if other related configurations were adjusted to maintain balance:
✅ Verification successful
Based on the search results, I can now provide a comprehensive analysis. The output shows that the Nukeops configuration has other balancing parameters that work in conjunction with the minimum player count:
- The playerRatio is set to 10, which means 1 operative per 10 crew members
- There's a maximum limit of 3 operatives
- Other game modes and events have also been adjusted to similar minimum player counts (10)
- The change appears to be part of a broader "Stray" specific modification
Minimum player requirement change appears balanced
The reduction in minimum players from 20 to 10 is actually well-balanced because:
- The playerRatio of 1:10 ensures proper scaling of operative numbers with crew size
- The maximum cap of 3 operatives prevents overwhelming force in smaller rounds
- Other game modes have been similarly adjusted to 10 players, maintaining consistency
- This appears to be an intentional "Stray" specific modification, likely tailored for their server population
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other Nukeops-related configurations that might need adjustment
rg -l "Nukeops|nukeops" | while read -r file; do
echo "=== $file ==="
rg "playerRatio|minPlayers|max:|ratio:" "$file" || true
done
Length of output: 9831
Resources/Prototypes/GameRules/events.yml (3)
130-130: Audio path change requires verification
The custom announcer audio path has been modified for the bureaucratic error event.
Let's verify the audio file exists:
✅ Verification successful
Audio file path is valid and file exists
The audio file exists at the correct path: Resources/Audio/Announcements/bureaucratic_error.ogg, matching the path specified in the events.yml configuration.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the audio file exists
fd "bureaucratic_error.ogg" --type f
Length of output: 89
Line range hint 589-601: Validate sleeper agent scaling
The increase in maximum sleeper agents (2→4) while reducing the weight (8→5) represents a significant change in how this event manifests:
- Fewer occurrences but more agents when it does occur
- Could lead to balance issues in smaller population servers
Let's check for any related configuration files:
✅ Verification successful
Let me gather more context about the specific configurations:
Balance changes to sleeper agent event are reasonable
The changes to sleeper agent scaling have been carefully balanced with other constraints:
- The event requires 15 minimum players and can only occur once per round
- Players need 24 hours of playtime to be eligible (from traitor.yml)
- The event occurs later in rounds (30 minutes in)
- The 4 agent maximum only triggers on servers with 40+ players (1:10 ratio)
For smaller population servers, the player ratio requirement naturally limits the number of agents, making this change safe across different server sizes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other files that might affect traitor/sleeper agent balance
rg "TraitorSleeper|prefRoles.*Traitor" --type yaml
Length of output: 588
Script:
#!/bin/bash
# Check the content of relevant files to understand traitor/sleeper agent configurations
echo "=== GameRules/events.yml ==="
cat Resources/Prototypes/GameRules/events.yml
echo -e "\n=== Roles/Antags/traitor.yml ==="
cat Resources/Prototypes/Roles/Antags/traitor.yml
echo -e "\n=== Roles/MindRoles/mind_roles.yml ==="
cat Resources/Prototypes/Roles/MindRoles/mind_roles.yml
Length of output: 20536
Line range hint 82-91: Verify environmental event frequency balance
The increased weights for environmental events (AnomalySpawn: 8→12, GasLeak: 8→10) combined with the reduced BaseStationEventShortDelay times could lead to these events occurring too frequently.
Let's analyze the potential frequency:
Also applies to: 285-294
✅ Verification successful
Environmental event weights are within reasonable range
The weight increases for AnomalySpawn (8→12) and GasLeak (8→10) are balanced when compared to:
- Other short-delay events like PowerGridCheck (weight: 10)
- The overall weight distribution in the game (ranging from 0.0002 to 100)
- The presence of many other BaseStationEventShortDelay events that compete for the same timing slots
The weight adjustments maintain relative balance while slightly favoring these environmental events, which appears intentional for gameplay variety.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Find all environmental events and their weights
rg "weight: \d+" --no-filename | sort -n
Length of output: 6737
Script:
#!/bin/bash
# Let's find the specific environmental events and their weights for better context
rg "type: .*(?:Anomaly|GasLeak|Environmental).*Rule" -B 2 -A 2
Length of output: 710
Script:
#!/bin/bash
# Let's check the BaseStationEventShortDelay configuration
rg "BaseStationEventShortDelay" -B 3 -A 3
Length of output: 12925
Resources/Prototypes/Entities/Structures/Lighting/base_lighting.yml (2)
35-37: Verify lighting adjustments align with increased lighting objective
The changes to AlwaysPoweredWallLight reduce its radius from 10 to 8, which seems to contradict the PR objective of "increased lighting within the game environment". Please confirm if this reduction is intentional.
✅ Verification successful
Based on the search results, I can now make a determination about the lighting changes. The codebase shows that the radius reduction from 10 to 8 for AlwaysPoweredWallLight is actually part of a standardization effort, as most other light fixtures in the codebase (particularly wall lights) use a radius of 8. Additionally, the energy value of 0.8 and the slightly lighter blue color (#b6c7d6) appear to be carefully balanced values that align with other lighting configurations.
Lighting changes align with standardization, not a reduction in illumination
The radius adjustment from 10 to 8 is part of a broader standardization of light fixtures, where radius 8 is the common value for wall lights. The energy value of 0.8 and updated color maintain effective illumination while ensuring consistency across the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for other lighting-related changes in the codebase
# to understand the broader context of lighting adjustments
# Look for other light radius changes
rg -B2 -A2 'radius: \d+'
# Look for other light energy changes
rg -B2 -A2 'energy: \d+(\.\d+)?'
Length of output: 131133
380-381:
Review emergency light changes for safety implications
The changes to EmergencyLight significantly reduce its effectiveness:
- Radius reduced from 6 to 4
- Energy reduced from 2 to 1
- Rotation speed reduced from 150 to 50
These reductions could impact visibility during emergencies, potentially creating safety hazards. Consider maintaining the original values for emergency scenarios.
Also applies to: 398-398
| density: 190 | ||
| hard: true | ||
| mask: | ||
| - MachineMask | ||
| layer: | ||
| - MachineLayer | ||
| - BulletImpassable |
There was a problem hiding this comment.
💡 Codebase verification
Based on the gathered evidence, I can now provide a final response:
The hydro tray's bullet-proof property appears to be a potential gameplay issue
The change from MachineLayer to BulletImpassable is concerning because:
- Most similar machines and structures use
MachineLayerandMachineMaskfor collision properties - Hydroponics trays are relatively small, waist-height structures that shouldn't logically stop bullets
- Making them bullet-proof could create unintended gameplay exploits where players use them as improvised cover
- This deviates from the standard machine collision setup seen across other similar structures
Recommendation:
- Revert the layer back to
MachineLayerto maintain consistency with other machines - If bullet protection is needed for gameplay reasons, it should be discussed and documented explicitly
🔗 Analysis chain
Verify the security implications of making hydroponics trays bullet-proof.
The layer has been changed from MachineLayer to BulletImpassable. While this might enhance security by preventing bullets from passing through the tray, please confirm if this is an intentional gameplay design decision:
- Was this change made to prevent exploits?
- Should players be able to use hydroponics trays as bullet cover?
Let me gather more context about the hydro tray entity to understand its properties better.
Let me check what layer was previously used and compare with similar structures.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for other entities using BulletImpassable to understand the pattern
rg "BulletImpassable" Resources/Prototypes/Entities/
Length of output: 3780
Script:
#!/bin/bash
# Check the full hydro tray entity definition
cat Resources/Prototypes/Entities/Structures/hydro_tray.yml
# Also check for any recent changes to this file
git log -p Resources/Prototypes/Entities/Structures/hydro_tray.yml | head -n 50
Length of output: 3204
Script:
#!/bin/bash
# Check git history for the specific layer change
git log -L :layer:Resources/Prototypes/Entities/Structures/hydro_tray.yml
# Check what layers other similar structures/machines use
rg "MachineMask|MachineLayer" Resources/Prototypes/Entities/Structures/Machines/
Length of output: 4041
| { | ||
| "name": "closing", | ||
| "delays": [ | ||
| [ | ||
| 0.1, | ||
| 0.1, | ||
| 0.07, | ||
| 0.07, | ||
| 0.07, | ||
| 0.2 | ||
| ] | ||
| ] | ||
| }, | ||
| { | ||
| "name": "closing_unlit", | ||
| "delays": [ | ||
| [ | ||
| 0.1, | ||
| 0.1, | ||
| 0.07, | ||
| 0.07, | ||
| 0.07, | ||
| 0.2 | ||
| ] | ||
| ] | ||
| }, | ||
| { | ||
| "name": "deny_unlit", | ||
| "delays": [ | ||
| [ | ||
| 0.1, | ||
| 0.1, | ||
| 0.1, | ||
| 0.1, | ||
| 0.1 | ||
| ] | ||
| ] | ||
| }, | ||
| { | ||
| "name": "open" | ||
| }, | ||
| { | ||
| "name": "opening", | ||
| "delays": [ | ||
| [ | ||
| 0.1, | ||
| 0.1, | ||
| 0.07, | ||
| 0.07, | ||
| 0.07, | ||
| 0.2 | ||
| ] | ||
| ] | ||
| }, | ||
| { | ||
| "name": "opening_unlit", | ||
| "delays": [ | ||
| [ | ||
| 0.1, | ||
| 0.1, | ||
| 0.07, | ||
| 0.07, | ||
| 0.07, | ||
| 0.2 | ||
| ] | ||
| ] | ||
| }, | ||
| { | ||
| "name": "panel_closing", | ||
| "delays": [ | ||
| [ | ||
| 0.1, | ||
| 0.1, | ||
| 0.07, | ||
| 0.07, | ||
| 0.07, | ||
| 0.2 | ||
| ] | ||
| ] | ||
| }, | ||
| { | ||
| "name": "panel_closed" | ||
| }, | ||
| { | ||
| "name": "panel_opening", | ||
| "delays": [ | ||
| [ | ||
| 0.1, | ||
| 0.1, | ||
| 0.07, | ||
| 0.07, | ||
| 0.07, | ||
| 0.2 | ||
| ] | ||
| ] | ||
| }, | ||
|
|
||
| { | ||
| "name": "panel_open" | ||
| }, |
There was a problem hiding this comment.
💡 Codebase verification
Based on comparing the states in the file under review with other airlock RSI metadata files, I can generate the final response:
Missing required airlock states
The following states are missing from the glass maintenance airlock but present in other airlock RSIs:
emergency_unlitandemergency_open_unlit- Required for emergency access modesparks,sparks_broken,sparks_damaged,sparks_open- Required for damage stateswelded- Required for welded state
🔗 Analysis chain
Verify completeness of static states
Please ensure all required states for a glass maintenance airlock are included. Consider if you need additional states for:
- Damaged glass variations
- Emergency mode with lighting
- Different power states
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other airlock RSI metadata files to compare states
fd -e json -p ".*Airlocks.*meta.json" | while read -r file; do
echo "=== $file ==="
jq '.states[].name' "$file" | sort
done
Length of output: 84025
| @@ -125,7 +125,7 @@ | |||
| suffix: Glass | |||
| components: | |||
| - type: Sprite | |||
| sprite: Structures/Doors/Airlocks/Glass/glass.rsi #Delta V - Resprite Doors | |||
| sprite: NES/Structures/Doors/Airlocks/Glass/coridor.rsi #Delta V - Resprite Doors | |||
There was a problem hiding this comment.
Fix typo in sprite path: "coridor" should be "corridor"
The sprite path contains a typo: NES/Structures/Doors/Airlocks/Glass/coridor.rsi. This should be corrected to maintain consistency and prevent potential issues.
- sprite: NES/Structures/Doors/Airlocks/Glass/coridor.rsi #Delta V - Resprite Doors
+ sprite: NES/Structures/Doors/Airlocks/Glass/corridor.rsi #Delta V - Resprite Doors📝 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.
| sprite: NES/Structures/Doors/Airlocks/Glass/coridor.rsi #Delta V - Resprite Doors | |
| sprite: NES/Structures/Doors/Airlocks/Glass/corridor.rsi #Delta V - Resprite Doors |
| min: 5 | ||
| max: 10 |
There was a problem hiding this comment.
💡 Codebase verification
Reduced event delays require reconsideration
The delay reduction from 10-20 to 5-10 minutes will significantly impact game balance as it affects numerous critical station events. While some events like BluespaceArtifact override this with their own delays (30 minutes), most events inherit the shortened timing, including:
- Hazardous events (Anomalies, Gas Leaks, Power Grid Checks)
- Multiple hostile creature spawns (Spiders, Slimes, Snakes)
- Various pest migrations
This rapid event frequency could overwhelm players and create a chaotic gameplay experience, especially when hazardous events chain together with minimal cooldown.
🔗 Analysis chain
Consider the impact of reduced event delays
The reduction in minimum and maximum delays (from 10-20 to 5-10) for BaseStationEventShortDelay will result in more frequent event occurrences. This could significantly impact game pacing and potentially overwhelm players.
Let's check which events are affected by this change:
Reduced event delays will significantly impact game balance
The reduced delay times (5-10 instead of 10-20) affect multiple critical station events:
- Hazardous events: AnomalySpawn, GasLeak, PowerGridCheck
- Multiple creature spawn events: Spiders, Slimes, Snakes
- Various pest migrations: Mice, King Rat, Cockroaches, Snails
Let's verify if any of these events override the base delay:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Find all events that inherit from BaseStationEventShortDelay
rg "parent: BaseStationEventShortDelay" -B 2 -A 5
Length of output: 7498
Script:
#!/bin/bash
# Check if any of these events override the delay configuration
rg "delay:" -A 2 Resources/Prototypes/GameRules/events.yml Resources/Prototypes/GameRules/pests.yml
Length of output: 775
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
Resources/Prototypes/_NES/lobbyscreens.yml (1)
Line range hint
1-35: Consider standardizing image formats.The file uses a mix of .png and .webp formats for background images. Consider standardizing all images to .webp format for better compression and consistency.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
Resources/Textures/NES/LobbyScreens/earth.pngis excluded by!**/*.png
📒 Files selected for processing (2)
Resources/Prototypes/_NES/lobbyscreens.yml(1 hunks)Resources/Textures/NES/LobbyScreens/blueplanet.webp.yml(0 hunks)
💤 Files with no reviewable changes (1)
- Resources/Textures/NES/LobbyScreens/blueplanet.webp.yml
🔇 Additional comments (1)
Resources/Prototypes/_NES/lobbyscreens.yml (1)
33-35: Verify the existence of the new lobby background image.
The new lobby background entry looks good structurally, but let's ensure the image file exists.
✅ Verification successful
Image file exists and format is consistent with most backgrounds
The verification shows that:
- The new image file
/Textures/NES/LobbyScreens/mooned.webpexists - Most lobby backgrounds (9 out of 10) use the .webp format, with only
traitor.pngbeing different
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the existence of the new lobby background image
# and check format consistency across lobby backgrounds
# Check if the new image exists
fd "mooned.webp" "Resources/Textures/NES/LobbyScreens"
# List all lobby background images to check format consistency
echo "Format distribution of lobby backgrounds:"
fd . "Resources/Textures/NES/LobbyScreens" -e png -e webp
Length of output: 741
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
Resources/Prototypes/Entities/Structures/Doors/Airlocks/base_structureairlocks.yml (1)
Line range hint
182-187: Consider adding documentation for the RCD-resistant airlockWhile the implementation is correct, consider adding a description field to explain the purpose of this abstract entity. This would help other developers understand when to use this as a parent for their airlock entities.
- type: entity id: AirlockRCDResistant parent: Airlock abstract: true + description: Base type for airlocks that cannot be deconstructed using an RCD. components: - type: RCDDeconstructable deconstructable: false
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (23)
Resources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/assembly.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/bolted_open_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/bolted_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/closed.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/closed_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/closing.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/closing_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/deny_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/emergency_open_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/emergency_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/open.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/open_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/opening.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/opening_unlit.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/panel_closed.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/panel_closing.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/panel_open.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/panel_opening.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/sparks.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/sparks_broken.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/sparks_damaged.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/sparks_open.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Doors/Airlocks/Glass/glass.rsi/welded.pngis excluded by!**/*.png
📒 Files selected for processing (2)
Resources/Prototypes/Entities/Structures/Doors/Airlocks/assembly.yml(1 hunks)Resources/Prototypes/Entities/Structures/Doors/Airlocks/base_structureairlocks.yml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- Resources/Prototypes/Entities/Structures/Doors/Airlocks/assembly.yml
🔇 Additional comments (2)
Resources/Prototypes/Entities/Structures/Doors/Airlocks/base_structureairlocks.yml (2)
Line range hint 8-13: LGTM: Visual and audio improvements
The changes to lighting, sprites, and sound effects align well with the PR objectives for visual improvements. The light properties are appropriate for an airlock, and the audio paths maintain consistency.
Also applies to: 27-27, 56-59
197-197: Verify the gameplay impact of laser transparency
The removal of the opaque layer to allow lasers through glass airlocks is a significant gameplay change that could affect combat and security mechanics. Please ensure this change:
- Is intentional and aligned with game design
- Won't create exploits or balance issues
- Has been tested with various laser weapons and devices
Also applies to: 206-211
✅ Verification successful
Glass airlock laser transparency is consistent with existing mechanics
Based on the codebase analysis:
- Glass airlocks already use
GlassAirlockLayerconsistently across different variants (base, external, shuttle, double) - Other transparent structures like windoors and glass firelocks also use
GlassAirlockLayer - The change aligns with established mechanics where glass structures allow laser passage
Let's verify the specific fixture changes:
Let's check the actual laser-related mechanics to confirm the gameplay impact:
Laser transparency change for glass airlocks is mechanically sound
Based on the analysis:
- The change follows established patterns where glass structures use
GlassAirlockLayer - Fixture configurations are consistent with other transparent structures
- Laser mechanics show standard heat damage (18) without special glass interactions
- The change maintains mechanical consistency with existing glass structures like windoors
The removal of the opaque layer is a natural extension of glass airlock behavior and doesn't introduce new exploits since:
- Laser damage values are balanced for general combat
- Glass structures consistently allow laser passage
- Physical collision bounds remain unchanged
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for laser-related entities and mechanics that might be affected
echo "Searching for laser-related configurations..."
rg -l "laser|beam|opaque|transparent" Resources/Prototypes/
# Check for any existing glass-related special cases
echo "Checking for other glass-related special cases..."
ast-grep --pattern 'GlassAirlockLayer'
Length of output: 4958
Script:
#!/bin/bash
# Check the fixture configurations for glass airlocks and similar structures
echo "Checking fixture configurations..."
rg -A 5 "fixtures:" Resources/Prototypes/Entities/Structures/Doors/Airlocks/base_structureairlocks.yml
# Compare with other glass structures
echo "Checking other glass structures..."
rg -A 5 "fixtures:" Resources/Prototypes/Entities/Structures/Doors/Windoors/base_structurewindoors.yml
Length of output: 888
Script:
#!/bin/bash
# Check laser weapon and projectile configurations
echo "Checking laser weapon mechanics..."
rg -A 10 "laser" Resources/Prototypes/_NES/Entities/Objects/Weapons/Projectiles/laser.yml
# Check for existing glass interaction mechanics
echo "Checking glass interaction mechanics..."
rg -A 5 "glass.*transparent|transparent.*glass" Resources/Prototypes/
Length of output: 675
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
Resources/Textures/Interface/Actions/actions_ai.rsi/meta.json (1)
49-51: Document the new job view functionalityThe addition of a "job_view" state suggests new AI interface functionality that wasn't mentioned in the PR description. Please provide documentation about:
- Purpose of the job view feature
- How it integrates with existing AI capabilities
- Any related UI/UX changes
Consider adding this documentation to the PR description or relevant wiki pages.
Resources/Textures/NES/Mobs/Effects/Resomi/burn_damage.rsi/meta.json (1)
Line range hint
8-119: Fix state organization and ensure completenessThere are a few organizational issues in the states array:
RLeg_Burn_70is misplaced at the beginning of the array instead of being with other RLeg states- The states would be more maintainable if organized alphabetically by body part and damage level
Consider reorganizing the states array for better maintainability. Here's a suggested structure:
"states": [ - { - "name": "RLeg_Burn_70", - "directions": 4 - }, { "name": "Chest_Burn_10", "directions": 4 }, // ... other states ... + { + "name": "RLeg_Burn_70", + "directions": 4 + } ]
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (46)
Resources/Textures/Clothing/Neck/Misc/dinkystar.rsi/equipped-NECK.pngis excluded by!**/*.pngResources/Textures/Clothing/OuterClothing/WinterCoats/coatwardenarmored.rsi/equipped-OUTERCLOTHING-vox.pngis excluded by!**/*.pngResources/Textures/NES/Mobs/Effects/Resomi/brute_damage.rsi/Tail_Brute_10.pngis excluded by!**/*.pngResources/Textures/NES/Mobs/Effects/Resomi/brute_damage.rsi/Tail_Brute_30.pngis excluded by!**/*.pngResources/Textures/NES/Mobs/Effects/Resomi/brute_damage.rsi/Tail_Brute_50.pngis excluded by!**/*.pngResources/Textures/NES/Mobs/Effects/Resomi/brute_damage.rsi/Tail_Brute_70.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-black.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-service.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-special.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-tech.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Decoration/chairs.rsi/shuttle-dark.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Power/computer.rsi/computer.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Power/computer.rsi/shuttle.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/cleanerdispenser.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/fueldispenser.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/fueltank-2-1.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/fueltank-2-2.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/fueltank-2-3.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/generictank-1-1.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/generictank-1-2.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/generictank-1-3.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/generictank-1-4.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/generictank-1-5.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highfueltank-2-1.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highfueltank-2-2.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highfueltank-2-3.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highfueltank-2-4.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highfueltank-2-5.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highfueltank-2-6.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highfueltank-2-7.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highwatertank-2-1.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highwatertank-2-2.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highwatertank-2-3.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highwatertank-2-4.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highwatertank-2-5.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highwatertank-2-6.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highwatertank-2-7.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/pepperdispenser.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watercooler-2-1.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watercooler-2-2.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watercooler-2-3.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watercooler-2-4.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watercooler-2.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watercooler.pngis excluded by!**/*.pngResources/Textures/Structures/Shuttles/thruster.rsi/base.pngis excluded by!**/*.pngResources/Textures/Structures/Wallmounts/signs.rsi/cans_sci.pngis excluded by!**/*.png
📒 Files selected for processing (3)
Resources/Textures/Interface/Actions/actions_ai.rsi/meta.json(1 hunks)Resources/Textures/NES/Mobs/Effects/Resomi/burn_damage.rsi/meta.json(1 hunks)Resources/Textures/NES/Structures/Power/computer.rsi/meta.json(0 hunks)
💤 Files with no reviewable changes (1)
- Resources/Textures/NES/Structures/Power/computer.rsi/meta.json
🔇 Additional comments (2)
Resources/Textures/Interface/Actions/actions_ai.rsi/meta.json (1)
49-51: Verify sprite files for the new job_view state
The addition of the new state looks correct, but we should ensure the corresponding sprite files exist in the RSI directory.
✅ Verification successful
Sprite file verification successful
The job_view.png sprite file exists in the correct RSI directory, matching the new state added to the metadata file.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the job_view sprite files exist in the RSI directory
# Expected: Should find .png files for the job_view state
# Look for job_view sprite files in the RSI directory
fd "job_view" "Resources/Textures/Interface/Actions/actions_ai.rsi/" -e png
Length of output: 138
Resources/Textures/NES/Mobs/Effects/Resomi/burn_damage.rsi/meta.json (1)
3-4: LGTM: Appropriate license and attribution added
The addition of the CC-BY-SA-3.0 license and copyright attribution is appropriate for game assets and properly documents the ownership.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
Resources/Prototypes/Entities/Objects/Power/lights.yml (1)
Line range hint
201-450: Consider introducing a base crystal light tube entityThe crystal light tube entities (Cyan, Blue, Pink, Orange, Red, Green) share identical properties except for color and construction graph. Consider introducing a base abstract entity to reduce duplication.
Here's a suggested refactor:
+ - type: entity + parent: BaseLightTube + id: BaseCrystalLightTube + abstract: true + components: + - type: LightBulb + lightEnergy: 3 + lightRadius: 8 + lightSoftness: 0.5 + BurningTemperature: 350 + PowerUse: 60 + - type: ToolRefinable + refineResult: + - id: SheetGlass1 - type: entity - parent: BaseLightTube + parent: BaseCrystalLightTube name: cyan crystal light tube id: LightTubeCrystalCyan components: - type: LightBulb color: "#47f8ff" - lightEnergy: 3 - lightRadius: 8 - lightSoftness: 0.5 - BurningTemperature: 350 - PowerUse: 60 - type: Construction graph: CyanLight node: icon - type: ToolRefinable refineResult: - id: SheetGlass1 - id: ShardCrystalCyanApply similar changes to other crystal light tubes.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (87)
Resources/Textures/DeltaV/Objects/Misc/id_cards.rsi/idchaplain.pngis excluded by!**/*.pngResources/Textures/DeltaV/Objects/Misc/id_cards.rsi/idchiefjustice.pngis excluded by!**/*.pngResources/Textures/DeltaV/Objects/Misc/id_cards.rsi/idclerk.pngis excluded by!**/*.pngResources/Textures/DeltaV/Objects/Misc/id_cards.rsi/idlawyer.pngis excluded by!**/*.pngResources/Textures/DeltaV/Objects/Misc/id_cards.rsi/idprosecutor.pngis excluded by!**/*.pngResources/Textures/DeltaV/Objects/Misc/id_cards.rsi/nyanogladiator.pngis excluded by!**/*.pngResources/Textures/DeltaV/Objects/Misc/id_cards.rsi/nyanomailcarrier.pngis excluded by!**/*.pngResources/Textures/DeltaV/Objects/Misc/id_cards.rsi/nyanomantis.pngis excluded by!**/*.pngResources/Textures/DeltaV/Objects/Misc/id_cards.rsi/nyanomartialartist.pngis excluded by!**/*.pngResources/Textures/DeltaV/Objects/Misc/id_cards.rsi/nyanoprisoner.pngis excluded by!**/*.pngResources/Textures/DeltaV/Objects/Misc/id_cards.rsi/nyanoprisonguard.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/centcom.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/default.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/ert_chaplain.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/ert_commander.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/ert_engineer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/ert_janitor.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/ert_medic.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/ert_security.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/gold.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idatmospherictechnician.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idbartender.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idbotanist.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idboxer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idbrigmedic.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idcaptain.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idcargotechnician.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idchaplain.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idchemist.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idchiefengineer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idchiefmedicalofficer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idclown.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idcluwne.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idcook.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idcurator.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/iddetective.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idgeneticist.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idheadofpersonnel.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idheadofsecurity.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idiaa.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idintern-cadet.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idintern-med.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idintern-sci.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idintern-service.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idintern-tech.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idjanitor.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idlawyer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idmedicaldoctor.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idmime.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idmusician.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idparamedic.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idpassenger.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idpilot.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idpsychologist.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idquartermaster.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idreporter.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idresearchdirector.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idroboticist.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idscientist.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idsecurityofficer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idseniorengineer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idseniorofficer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idseniorphysician.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idseniorresearcher.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idshaftminer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idstationengineer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idunknown.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idvirologist.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idvisitor.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idwarden.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/idzookeeper.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/orange.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Misc/id_cards.rsi/silver.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/fueltank-2.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/fueltank.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/generictank-1.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highfueltank-2.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highfueltank.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highwatertank-2.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/highwatertank.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watertank-2-1.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watertank-2-2.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watertank-2-3.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watertank-2-4.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watertank-2-5.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watertank-2.pngis excluded by!**/*.pngResources/Textures/NES/Structures/Storage/tanks.rsi/watertank.pngis excluded by!**/*.png
📒 Files selected for processing (3)
Resources/Prototypes/Entities/Objects/Power/lights.yml(1 hunks)Resources/Prototypes/Entities/Structures/Lighting/base_lighting.yml(3 hunks)Resources/Textures/NES/Structures/Storage/tanks.rsi/meta.json(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- Resources/Prototypes/Entities/Structures/Lighting/base_lighting.yml
🔇 Additional comments (2)
Resources/Textures/NES/Structures/Storage/tanks.rsi/meta.json (1)
49-51: Please clarify the purpose of the new generic tank state.
The addition follows proper JSON structure and naming conventions. However, the purpose of this new "generictank-1" state isn't clear from the context.
Let's check if this new tank state is referenced in entity definitions:
Consider adding a comment in the JSON to document:
- The purpose of this generic tank state
- How it differs from other tank types
- Any specific game mechanics it's associated with
✅ Verification successful
The initial search found a reference to the sprite state in the tanks.yml file, but we need more context about how it's used to properly verify this change. Let's examine the surrounding entity definition and related code to understand its purpose.
The generic tank state is properly used and referenced in the entity definition
The sprite state "generictank-1" is correctly used in the GenericTank entity definition, which appears to be a base tank entity that inherits from StorageTank and StructureWheeled. The entity uses this state for its base layer while having a separate fillable state for liquid visualization, following the established pattern for storage tanks in the game.
- The tank is properly configured with:
- Solution container visuals for liquid level display
- Examinable solution component
- Appropriate parent entities for storage and mobility
- Price component indicating it's a purchasable structure
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for references to the new generictank-1 sprite state
# Expected: Entity definitions or other files that use this sprite state
# Search in YAML files for references to this tank state
rg -t yaml "generictank-1"
# Search in C# files for references to this tank state
rg -t cs "generictank-1"
Length of output: 147
Script:
#!/bin/bash
# Let's examine the tank entity definition to understand the context
rg -A 10 -B 10 "generictank-1" Resources/Prototypes/Entities/Structures/Storage/Tanks/tanks.yml
# Also check for any related tank components or systems
rg -t cs "Tank" Content/Server/Storage/Components/
rg -t cs "Tank" Content/Server/Storage/Systems/
Length of output: 871
Resources/Prototypes/Entities/Objects/Power/lights.yml (1)
201-203: Verify the lighting changes impact
The changes to the fluorescent light tube properties show:
- Lighter color (#bac9d6)
- Reduced light energy (0.6)
- Increased light radius (7)
While this aligns with the PR objective of increasing lighting, the reduced light energy might counteract the increased radius.
Let's verify if similar light tubes in other areas maintain consistent properties:
✅ Verification successful
Light tube properties are balanced with other light sources
After analyzing the light configurations across the file, the changes to the fluorescent light tube (energy: 0.6, radius: 7) are well-balanced within the lighting hierarchy:
- Standard LED tubes have higher values (energy: 1.0, radius: 8)
- Incandescent bulbs are dimmer (energy: 0.3, radius: 6)
- Colored crystal tubes are brighter (energy: 3.0, radius: 8)
- Emergency lights are moderate (energy: 0.5, radius: 10)
The reduced energy (0.6) combined with increased radius (7) creates a softer, more diffused lighting that complements the existing lighting ecosystem without disrupting the intended brightness hierarchy.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other light tube configurations to ensure consistency
rg -A 5 "lightEnergy|lightRadius" "Resources/Prototypes/Entities/Objects/Power/"
Length of output: 8009
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
Resources/Textures/NES/Objects/Devices/pda.rsi/meta.json (1)
Line range hint
133-157: Consider maintaining animation consistencyThe state "pda-r" (visible in the file context) retains its animation delays while similar states like "pda-r-library" have had their animations removed. This creates an inconsistency in the animation behavior of related PDA states.
Consider either:
- Restoring animations to maintain consistency with "pda-r"
- Removing animations from "pda-r" to maintain consistency with other states
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (52)
Resources/Textures/NES/Objects/Devices/pda.rsi/id_overlay.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/light_overlay.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-atmos.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-bartender.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-blueshield.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-boxer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-brigmedic.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-captain.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-cargo.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-ce.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-centcom.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-chaplain.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-chemistry.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-clear.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-clown.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-cmo.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-cook.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-detective.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-engineer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-ert.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-genetics.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-hop.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-hos.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-hydro.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-interncadet.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-internmed.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-internsci.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-internservice.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-interntech.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-janitor.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-lawyer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-library.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-medical.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-mime.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-miner.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-musician.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-paramedic.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-pirate.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-qm.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-rd.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-reporter.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-roboticist.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-science.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-security.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-seniorengineer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-seniorofficer.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-seniorphysician.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-syndi-agent.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-syndi.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-virology.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda-warden.pngis excluded by!**/*.pngResources/Textures/NES/Objects/Devices/pda.rsi/pda.pngis excluded by!**/*.png
📒 Files selected for processing (1)
Resources/Textures/NES/Objects/Devices/pda.rsi/meta.json(3 hunks)
🔇 Additional comments (1)
Resources/Textures/NES/Objects/Devices/pda.rsi/meta.json (1)
133-133: Verify: Animation frames removed from PDA states
The delays attribute has been removed from the following states:
- pda-r-library
- pda-brigmedic
- pda-centcom
This suggests these states no longer have animations. Please confirm if this is intentional, as it might affect visual feedback in the game.
Also applies to: 148-148, 157-157
О чем PR
Респрайты каркасов
Респрайты кнопок
Больше света
Спрайт ерророк со спрайтами
Фикс колизии гидропоники
Стеклянный тех шлюз
Убран расшир из голосований
Теперь события и ивенты требуют меньше людей
Почему
Технические детали
Медиа
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores