lodkaCry #167
lodkaCry #167
Conversation
WalkthroughThis pull request involves extensive localization efforts, primarily translating game documentation and guidebook entries from English to Russian. The changes span multiple files across different directories, focusing on translating content for various game elements such as chemical tabs, species descriptions, alert procedures, justice systems, and specific creature or race guides. Additionally, there are modifications to guidebook entry priorities, the removal of certain entries, and the addition of new species, enhancing the organizational structure of the game's documentation. Changes
Possibly related PRs
Suggested Labels
Poem
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 (
|
github-actions
bot
added
size/L
Changes: Documentation
Changes: YML
and removed
size/L
labels
![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
🧹 Nitpick comments (2)
Resources/Prototypes/Guidebook/rules.yml (1)
Line range hint
1-92: Consider documenting the priority systemThe priority values (-3 to 100) appear to be logically ordered, but the reasoning behind specific values isn't documented. Consider adding comments explaining the priority ranges:
- Negative: Default/fallback entries
- 1-10: Core rules
- 20-100: Administrative entries
Resources/ServerInfo/Guidebook/DeltaV/AlertProcedure.xml (1)
15-20: Inconsistent list formattingThe formatting of crew norms lists varies across different alert levels. Some use "- " prefix while others have additional spaces. Standardize the formatting across all lists.
Also applies to: 37-42, 96-102
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (22)
Resources/Prototypes/DeltaV/Guidebook/rules.yml(1 hunks)Resources/Prototypes/Guidebook/rules.yml(1 hunks)Resources/Prototypes/Guidebook/species.yml(0 hunks)Resources/ServerInfo/Guidebook/Antagonist/Thieves.xml(1 hunks)Resources/ServerInfo/Guidebook/ChemicalTabs/Biological.xml(1 hunks)Resources/ServerInfo/Guidebook/ChemicalTabs/Elements.xml(1 hunks)Resources/ServerInfo/Guidebook/ChemicalTabs/Foods.xml(1 hunks)Resources/ServerInfo/Guidebook/ChemicalTabs/Narcotics.xml(1 hunks)Resources/ServerInfo/Guidebook/ChemicalTabs/Other.xml(1 hunks)Resources/ServerInfo/Guidebook/ChemicalTabs/Pyrotechnic.xml(1 hunks)Resources/ServerInfo/Guidebook/ChemicalTabs/Toxins.xml(1 hunks)Resources/ServerInfo/Guidebook/DeltaV/AlertProcedure.xml(1 hunks)Resources/ServerInfo/Guidebook/DeltaV/Epistemics/GlimmerCreatures.xml(1 hunks)Resources/ServerInfo/Guidebook/DeltaV/Justice.xml(1 hunks)Resources/ServerInfo/Guidebook/DeltaV/Logistics/TradeStation.xml(1 hunks)Resources/ServerInfo/Guidebook/Mobs/DeltaV/Felinid.xml(1 hunks)Resources/ServerInfo/Guidebook/Mobs/DeltaV/Harpy.xml(1 hunks)Resources/ServerInfo/Guidebook/Mobs/DeltaV/Rodentia.xml(1 hunks)Resources/ServerInfo/Guidebook/Mobs/DeltaV/Vulpkanin.xml(1 hunks)Resources/ServerInfo/Guidebook/ReferenceTables/Drinks.xml(1 hunks)Resources/ServerInfo/Guidebook/Security/CriminalRecords.xml(1 hunks)Resources/ServerInfo/Nyanotrasen/Guidebook/Epistemics/Altar.xml(1 hunks)
💤 Files with no reviewable changes (1)
- Resources/Prototypes/Guidebook/species.yml
✅ Files skipped from review due to trivial changes (19)
- Resources/ServerInfo/Guidebook/Security/CriminalRecords.xml
- Resources/ServerInfo/Guidebook/Mobs/DeltaV/Harpy.xml
- Resources/ServerInfo/Guidebook/ReferenceTables/Drinks.xml
- Resources/ServerInfo/Guidebook/Mobs/DeltaV/Vulpkanin.xml
- Resources/ServerInfo/Guidebook/Mobs/DeltaV/Rodentia.xml
- Resources/ServerInfo/Guidebook/DeltaV/Logistics/TradeStation.xml
- Resources/ServerInfo/Guidebook/Antagonist/Thieves.xml
- Resources/ServerInfo/Nyanotrasen/Guidebook/Epistemics/Altar.xml
- Resources/ServerInfo/Guidebook/ChemicalTabs/Toxins.xml
- Resources/ServerInfo/Guidebook/ChemicalTabs/Narcotics.xml
- Resources/ServerInfo/Guidebook/Mobs/DeltaV/Felinid.xml
- Resources/ServerInfo/Guidebook/ChemicalTabs/Other.xml
- Resources/ServerInfo/Guidebook/ChemicalTabs/Foods.xml
- Resources/ServerInfo/Guidebook/DeltaV/Epistemics/GlimmerCreatures.xml
- Resources/ServerInfo/Guidebook/DeltaV/Justice.xml
- Resources/ServerInfo/Guidebook/ChemicalTabs/Pyrotechnic.xml
- Resources/Prototypes/DeltaV/Guidebook/rules.yml
- Resources/ServerInfo/Guidebook/ChemicalTabs/Elements.xml
- Resources/ServerInfo/Guidebook/ChemicalTabs/Biological.xml
🔇 Additional comments (4)
Resources/Prototypes/Guidebook/rules.yml (1)
1-7: Verify the impact of DefaultRuleset changes
The DefaultRuleset is marked as "Should not be listed anywhere if the server is using a custom ruleset" but it's still referencing rules R1-R7. This might cause confusion with the removed DeltaVRuleset.
Resources/ServerInfo/Guidebook/DeltaV/AlertProcedure.xml (3)
107-108: Verify translation of company name
The company name "NanoTrasen" is kept in Latin script. Verify if this is consistent with the game's localization guidelines for proper nouns.
✅ Verification successful
Based on the search results, I can generate the final response as we have sufficient information about the usage of the company name "NanoTrasen" across the Russian localization files.
Company name "NanoTrasen" is consistently used in Latin script
The search results show that "NanoTrasen" is consistently kept in Latin script across all Russian-localized XML files, including rules, guidelines, and lore documents. This appears to be the intended style for the company name in Russian translations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other occurrences of company name in translations
rg "NanoTrasen|НаноТрейзен" --type xml
Length of output: 1459
2-3: Verify translation of technical terms
The translation "Уровни угроз" (threat levels) is used instead of "коды тревоги" (alert codes) which might be more consistent with game terminology. Please verify this aligns with other in-game translations.
1-127: Address author's concerns about incomplete translation
As mentioned in the PR description, there are potential issues with "powergrid" and drinks sections. However, this file seems to be completely translated. Please verify if these concerns apply to other files not included in this review.
| # Условия | ||
| - Значение мерцания близится к 500 или выше | ||
| # Нормы экипажа: | ||
| - Все известные псионики должны быть избавлены от псионических способностей (Персоналу эпистемики разрешено иметь псионические способности) | ||
| - Сотрудники Службы Безопасности продолжают выполнение своих обязанностей по предыдущему коду | ||
| - Каталигер или мантис должен передать список псиоников службе безопасности, а те в свою очередь принести их к мантису, для избавления от пси-сил | ||
| - Персонал не РнД обязан подчинятся инструкциям кафедры эпистемики | ||
| - Членам экипажа рекомендуется воспользоваться средствами псионической изоляции. | ||
| - Псионики должны сообщать о принятии токсина "майндблейкер" или големизации. | ||
| # Нормы кафедры эпистемики: | ||
| - РнД должны отключить все наполнители мерцания (glimmer prober) | ||
| - При белом коде скорость работы превыше бюрократии | ||
| - Если персонал не успел отключить ноосферные зонды (glimmer prober), то они должны предупредить инженерный отдел, убрать оборудование и уничтожить остатки наполнителей для предотвращения проблем во всём секторе. Если мерцание слишком высокое и было замечено снижение эвакуация скорее всего будет разрешена, для уменьшения потерь экипажа |
There was a problem hiding this comment.
Technical terms need standardization
Several technical terms in the White Code section need standardization:
- "мерцание" (glimmer)
- "наполнители мерцания" (glimmer prober)
- "ноосферные зонды" (glimmer prober)
The same concept (glimmer prober) is translated differently in lines 87 and 89.
There was a problem hiding this comment.
Actionable comments posted: 16
🔭 Outside diff range comments (1)
Resources/Prototypes/Maps/split.yml (1)
❗ The PR contains both translation and gameplay changes
The diff shows that the only gameplay-related change is reducing
minPlayersfrom 25 to 0, while the file also contains Cyrillic text for station names (e.g., "Мэйхен", "Пэйбэк", "Ламбер"). This suggests:
- The translation work is legitimate and aligns with the PR's stated purpose
- The gameplay change (minPlayers reduction) appears to be an unrelated modification
Resources/Prototypes/Maps/split.yml: Line 5 changesminPlayers: 25tominPlayers: 0🔗 Analysis chain
Line range hint
1-200: ❓ Request for clarification on PR scopeThe changes in these files appear to be a significant gameplay modification rather than translation work:
- All map configurations are being modified to reduce minimum player requirements
- These changes could impact game balance, server performance, and player experience
- The modifications seem unrelated to the stated PR objective of translating the guidebook
Please clarify:
- Why are these map changes included in a translation PR?
- Has the impact of these changes been tested?
- Is this an intentional gameplay modification?
Let's check if there are any translation-related changes that should be the focus of this PR:
Let me verify the changes in the map file to determine if they are primarily translation-related or gameplay modifications:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for actual translation-related changes echo "Checking for translation-related changes..." rg -l "[\u0400-\u04FF]" Resources/Prototypes/Length of output: 15788
Script:
#!/bin/bash # Get the previous version of the file to compare git show HEAD~1:Resources/Prototypes/Maps/split.yml > /tmp/split_old.yml 2>/dev/null if [ $? -eq 0 ]; then echo "=== Differences in split.yml ===" diff /tmp/split_old.yml Resources/Prototypes/Maps/split.yml else echo "=== Current content of split.yml ===" cat Resources/Prototypes/Maps/split.yml fiLength of output: 253
🧹 Nitpick comments (3)
Resources/Prototypes/Maps/delta.yml (1)
71-71: Minor: Formatting change appears unrelated to translationThe addition of
Borgminon a new line appears to be a formatting change unrelated to translation work.Consider keeping formatting changes separate from translation work to maintain clear PR scope.
Resources/Prototypes/Maps/outpost.yml (1)
Line range hint
1-1: Overall concerns with PR scope and completenessThis PR appears to have deviated from its stated translation objectives:
- The main changes modify gameplay mechanics (minimum player requirements) rather than translations
- Translation work appears incomplete with mixed language content still present
- There are inconsistent minimum player requirements across maps (0 vs 3)
Recommendations:
- Separate gameplay changes into a dedicated PR
- Complete the translation work as originally intended
- Maintain consistent minimum player requirements or document reasons for differences
Consider breaking this into two PRs:
- A gameplay PR for minimum player requirement changes
- A translation PR focused solely on language updates
Resources/Prototypes/Maps/lighthouse.yml (1)
Line range hint
1-1: PR Scope Significantly Deviates from ObjectivesThis PR, described as a translation effort, contains systematic changes to game mechanics through
minPlayersmodifications across multiple map configurations. These changes:
- Are unrelated to translation work
- Could impact gameplay and server management
- Lack proper testing and documentation
Recommended Action Plan:
- Revert all gameplay-related changes
- Focus on completing the translation work
- Create a separate PR for gameplay modifications with:
- Proper testing
- Impact analysis
- Server management considerations
- Player experience documentation
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (28)
Resources/Prototypes/Entities/Objects/Materials/materials.yml(0 hunks)Resources/Prototypes/Maps/arena.yml(1 hunks)Resources/Prototypes/Maps/aspid.yml(1 hunks)Resources/Prototypes/Maps/astra.yml(2 hunks)Resources/Prototypes/Maps/avrite.yml(2 hunks)Resources/Prototypes/Maps/bagel.yml(1 hunks)Resources/Prototypes/Maps/box.yml(2 hunks)Resources/Prototypes/Maps/cog.yml(1 hunks)Resources/Prototypes/Maps/core.yml(1 hunks)Resources/Prototypes/Maps/delta.yml(2 hunks)Resources/Prototypes/Maps/edge.yml(1 hunks)Resources/Prototypes/Maps/fland.yml(2 hunks)Resources/Prototypes/Maps/gelta.yml(1 hunks)Resources/Prototypes/Maps/hammurabi.yml(1 hunks)Resources/Prototypes/Maps/hive.yml(1 hunks)Resources/Prototypes/Maps/ishimura.yml(1 hunks)Resources/Prototypes/Maps/lighthouse.yml(1 hunks)Resources/Prototypes/Maps/marathon.yml(2 hunks)Resources/Prototypes/Maps/meta.yml(2 hunks)Resources/Prototypes/Maps/oasis.yml(2 hunks)Resources/Prototypes/Maps/outpost.yml(1 hunks)Resources/Prototypes/Maps/paper.yml(1 hunks)Resources/Prototypes/Maps/pearl.yml(1 hunks)Resources/Prototypes/Maps/pilgrim.yml(2 hunks)Resources/Prototypes/Maps/split.yml(1 hunks)Resources/Prototypes/Maps/submarine.yml(1 hunks)Resources/Prototypes/Maps/tortuga.yml(1 hunks)Resources/Prototypes/Maps/train.yml(1 hunks)
💤 Files with no reviewable changes (1)
- Resources/Prototypes/Entities/Objects/Materials/materials.yml
🔇 Additional comments (12)
Resources/Prototypes/Maps/pearl.yml (1)
7-7: Verify the gameplay impact of removing minimum player requirement
Setting minPlayers to 0 for a map designed for up to 50 players (with multiple required roles) raises several concerns:
- Gameplay balance: The map's size and job distribution suggest it's designed for larger groups
- Security: Empty or near-empty servers could be vulnerable to exploitation
- Scope: This change appears unrelated to the PR's stated objective of guidebook translation
Let's check if there are any gameplay balance considerations in the documentation:
Resources/Prototypes/Maps/ishimura.yml (1)
7-7: Similar concerns as pearl.yml
This change exhibits the same gameplay balance and security concerns as noted in the pearl.yml review.
Resources/Prototypes/Maps/cog.yml (1)
5-7: Architectural Concern: Systematic removal of minimum player requirements
This PR, which is described as a guidebook translation effort, contains systematic changes to remove minimum player requirements across multiple maps. This raises several architectural concerns:
- Scope Creep: These changes are unrelated to the PR's stated translation objectives
- Missing Documentation: No justification or impact analysis is provided for this significant gameplay modification
- Security Implications: Removing minimum player requirements across all maps could expose servers to exploitation
- Gameplay Balance: Maps are designed with specific player counts in mind, as evidenced by their job configurations
Recommendation: These gameplay changes should be:
- Moved to a separate PR focused on map configuration
- Accompanied by proper documentation explaining the rationale
- Reviewed by game design stakeholders
Let's check for any related configuration or documentation:
Resources/Prototypes/Maps/gelta.yml (1)
7-7:
This change appears unrelated to translation work and requires justification
Reducing minPlayers from 30 to 0 is a significant gameplay modification that:
- Allows the map to run without any players
- May impact server resource usage
- Could affect gameplay balance
This change seems outside the scope of a translation PR.
Let's check if this is part of a broader pattern:
Please provide justification for this gameplay change or consider submitting it as a separate PR focused on gameplay modifications.
Resources/Prototypes/Maps/paper.yml (1)
Line range hint 1-1:
This PR, described as a translation effort, contains systematic modifications to minimum player requirements across multiple map files. These changes:
- Are unrelated to the stated translation objectives
- Could significantly impact gameplay balance
- Require proper review and testing
Let's verify the extent of these changes:
Recommendation: Please separate these changes into two PRs:
- Keep this PR focused on translation work
- Create a new PR for gameplay balance changes with proper documentation and testing
Resources/Prototypes/Maps/avrite.yml (1)
7-7:
This change reduces the minimum player requirement from 25 to 0 for Avrite Station. This is concerning because:
- It's unrelated to the PR's stated translation objectives
- The map was designed for 25+ players, suggesting it may not function well with fewer players
- Could impact gameplay balance and player experience
Resources/Prototypes/Maps/meta.yml (1)
5-5:
🛑 Request for clarification on scope and impact
These changes appear to be outside the scope of the PR's translation objectives. The systematic removal of minimum player requirements across multiple maps (as seen in Meta Station and others) raises several concerns:
- Scope Creep: The PR description focuses on guidebook translation, but includes significant gameplay changes
- Verification: The author mentions not verifying certain sections, which is concerning given the impact of these changes
- Design Impact: Maps with high maximum player counts (75 for Meta Station) may not function well without minimum requirements
Recommendation:
- Separate these gameplay changes into a different PR
- Provide justification for removing minimum player requirements
- Include testing results showing how these maps perform with very low player counts
Resources/Prototypes/Maps/marathon.yml (1)
5-5: Verify impact of removing minimum player requirement
Setting minPlayers to 0 allows the map to be played with any number of players. This could affect game balance and player experience, especially given the extensive job configuration.
Consider maintaining a minimum player count that ensures balanced gameplay, or document any special considerations for low-player scenarios.
✅ Verification successful
Setting minPlayers to 0 is consistent with map configuration patterns
Based on the search results, setting minPlayers: 0 for Marathon Station is consistent with the game's map configuration patterns:
- Almost all station maps in the codebase (Box, Meta, Atlas, etc.) use
minPlayers: 0 - Only one map (Delta) has a non-zero minimum player count of 3
- The
maxPlayersvalue of 65 for Marathon is within the normal range seen across maps (10-80 players) - Game modes/rules handle their own minimum player requirements separately (e.g., Nukeops requires 10 players)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if this map has special gameplay mechanics or balance considerations
rg -l "Marathon.*Station" --type yaml | xargs rg "balance|mechanics|special"
# Check for related configuration or documentation
fd -e md -e txt | xargs rg -i "minimum.*players|player.*requirements"
Length of output: 373
Script:
#!/bin/bash
# Let's check for map configuration patterns and player count settings in YAML files
rg -l "minPlayers" --type yaml | xargs rg "minPlayers|maxPlayers" -C 2
# Check for any game mode or map rotation configurations
fd -e yml -e yaml | xargs rg "GameMap|MapRotation" -C 2
# Look for any map-specific documentation or configuration
rg "Marathon" --type yaml -C 3
Length of output: 25610
Resources/Prototypes/Maps/bagel.yml (1)
5-5:
Changes appear unrelated to PR objectives
This modification to minPlayers seems unrelated to the PR's stated purpose of translation work. Additionally, reducing the minimum player count from 20 to 0 could have significant gameplay implications:
- Server resource management
- Game balance considerations
- Player experience in low-population scenarios
Let's check if this is part of a broader pattern of changes:
Please clarify:
- Why this change is included in a translation PR
- Whether the gameplay impact of zero minimum players has been tested
Resources/Prototypes/Maps/core.yml (1)
5-5:
Changes appear unrelated to translation work and may impact game balance
The modification of minPlayers from 15 to 0 raises several concerns:
- This change appears unrelated to the PR's stated purpose of translation work
- Allowing zero-player games could have implications for server resources and game balance
- The original minimum requirement of 15 players likely existed to ensure proper gameplay dynamics
Let's verify the extent of these changes across map files:
Resources/Prototypes/Maps/submarine.yml (1)
5-5:
Systematic reduction of player requirements requires architectural review
This change is part of a broader pattern of removing minimum player requirements across multiple maps. This systematic change:
- Deviates significantly from the PR's stated translation objectives
- Could fundamentally alter game balance and server resource utilization
- May enable unintended gameplay scenarios
Recommendations:
- These changes should be submitted as a separate PR focused on game mechanics
- A thorough gameplay impact analysis should be conducted
- Consider implementing a configurable server-wide minimum player policy instead of per-map settings
Let's check for any related configuration changes:
Resources/Prototypes/Maps/edge.yml (1)
5-5:
This change modifies core gameplay mechanics by removing minimum player requirements, which appears unrelated to the PR's stated objective of guidebook translation. This could have significant gameplay implications:
- The map was designed for 10-70 players
- Running with 0 players could lead to unbalanced gameplay
- Security concerns with unmanned critical stations
| minPlayers: 0 | ||
| maxPlayers: 60 #big map |
There was a problem hiding this comment.
High-risk change for explicitly large map
This change is particularly concerning because:
- The map is explicitly marked as a "big map" in the comments
- It supports the highest player count (60) among the reviewed maps
- It has the most complex job configuration
Setting minPlayers: 0 for such a large map could severely impact gameplay experience and server security.
| @@ -4,7 +4,7 @@ | |||
| mapPath: /Maps/corvax_delta.yml | |||
| maxRandomOffset: 0 | |||
| randomRotation: false | |||
| minPlayers: 30 | |||
| minPlayers: 3 | |||
There was a problem hiding this comment.
Inconsistent minimum player requirement
While other maps are being set to 0 players, this map is set to 3 players. This inconsistency:
- May indicate special requirements for this map
- Could cause confusion for server operators
- Seems unrelated to the PR's translation focus
Please clarify:
- Why this map requires 3 players while others require 0
- Whether this gameplay change should be in a separate PR
| @@ -4,7 +4,7 @@ | |||
| mapPath: /Maps/corvax_outpost.yml | |||
| maxRandomOffset: 0 | |||
| randomRotation: false | |||
| minPlayers: 15 | |||
| minPlayers: 0 | |||
There was a problem hiding this comment.
Gameplay change outside PR scope + Incomplete translation
- The
minPlayerschange from 15 to 0 appears to be a gameplay modification outside the scope of a translation PR. - The file contains untranslated elements (e.g.,
mapNameTemplate: '{0} Outpost {1}') that should be in scope for this translation work.
Please:
- Consider moving gameplay changes to a separate PR
- Complete the translation of remaining English text elements
| @@ -4,7 +4,7 @@ | |||
| mapPath: /Maps/corvax_astra.yml | |||
| maxRandomOffset: 0 | |||
| randomRotation: false | |||
| minPlayers: 30 | |||
| minPlayers: 0 | |||
There was a problem hiding this comment.
❌ This change appears unrelated to translation work and could break gameplay
This modification reduces the minimum player count from 30 to 0 for Astra Station, which seems inappropriate given:
- The station's job configuration shows it's designed for larger player counts
- This change is unrelated to the PR's stated purpose of translation work
- Running a large station map with no minimum player requirement could lead to unplayable scenarios
Please revert this change or provide justification for this gameplay modification in the PR description.
| @@ -2,7 +2,7 @@ | |||
| id: Train | |||
| mapName: 'Train' | |||
| mapPath: /Maps/train.yml | |||
| minPlayers: 10 | |||
| minPlayers: 0 | |||
There was a problem hiding this comment.
❌ Part of concerning pattern of gameplay changes
This is one of many files where minimum player requirements are being removed. This change:
- Is unrelated to the PR's translation objective
- Could affect gameplay balance
- Is part of a pattern of similar modifications across multiple map files
Please explain the rationale for these widespread gameplay changes or revert them to focus on translation work.
| @@ -2,7 +2,7 @@ | |||
| id: Box | |||
| mapName: 'Box Station' | |||
| mapPath: /Maps/box.yml | |||
| minPlayers: 15 | |||
| minPlayers: 0 | |||
There was a problem hiding this comment.
Zero minimum players may break intended gameplay mechanics
The removal of minimum player requirements is particularly concerning for Box Station because:
- The map includes specialized roles like Prisoners that require player interaction
- The security and prisoner dynamics would be meaningless without a minimum number of players
- This change could enable abuse of game mechanics in empty servers
Consider implementing a role-based minimum player system instead, where certain roles become available only when specific player count thresholds are met.
Also applies to: 85-85
| @@ -2,7 +2,7 @@ | |||
| id: Arena | |||
| mapName: 'Arena' | |||
| mapPath: /Maps/arena.yml | |||
| minPlayers: 10 | |||
| minPlayers: 0 | |||
There was a problem hiding this comment.
Setting minPlayers to 0 for an arena-style map is particularly concerning:
- Arena maps typically require multiple players for intended gameplay
- Original design was for 10-60 players
- Combat and competition mechanics may break with insufficient players
| @@ -2,7 +2,7 @@ | |||
| id: Tortuga | |||
| mapName: 'Tortuga' | |||
| mapPath: /Maps/tortuga.yml | |||
| minPlayers: 20 | |||
| minPlayers: 0 | |||
There was a problem hiding this comment.
Setting minPlayers to 0 for a large station (originally 20-70 players) raises operational concerns:
- Station has multiple critical departments requiring minimum staffing
- Complex job hierarchy with command structure
- Security risks with understaffed critical areas
Consider implementing a dynamic scaling system that adjusts available areas/departments based on player count instead of removing the minimum requirement entirely.
🛑 Overall Assessment: These changes require separate PR and thorough testing
These modifications appear to be part of a larger change affecting multiple map files, systematically removing minimum player requirements. Given that:
- These changes are unrelated to the PR's stated objective of guidebook translation
- The author admits to not verifying changes
- The modifications could significantly impact gameplay balance and security
Recommendations:
- Please create a separate PR for these gameplay modifications
- Include documentation explaining the rationale for removing minimum player requirements
- Provide test results showing the impact on gameplay balance
- Consider implementing a dynamic scaling system instead of removing requirements entirely
| @@ -2,7 +2,7 @@ | |||
| id: Hammurabi | |||
| mapName: 'Hammurabi' | |||
| mapPath: /Maps/hammurabi.yml | |||
| minPlayers: 20 | |||
| minPlayers: 0 | |||
There was a problem hiding this comment.
💡 Codebase verification
The map configuration shows this is a complex prison station requiring specific staffing:
- Comments indicate a planned 2:1 prisoner:guard ratio
- Current configuration requires 4-6 prisoners and 4-6 prison guards
- Additional security roles: 6-8 officers, 2-3 cadets, 1 warden, 1 HoS
- Multiple departments (medical, service, etc.) with minimum staffing needs
Setting minPlayers to 0 would allow the station to run without the necessary security personnel to maintain order and safety, contradicting the station's design and role requirements.
🔗 Analysis chain
Reducing minimum players from 20 to 0 for a prison station map raises gameplay balance concerns:
- The map has specific role ratios (e.g., prisoner:guard ratio mentioned in comments)
- The station design likely assumes multiple players for security and operations
Let's check for any related gameplay balance configurations:
Let me gather more information about the map configuration to better understand the gameplay balance implications.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for role ratio configurations and balance settings
echo "Checking for role ratio configurations..."
rg -A 5 "ratio|balance" Resources/Prototypes/Maps/hammurabi.yml
Length of output: 399
Script:
#!/bin/bash
# Check the full map configuration
echo "Checking full map configuration..."
cat Resources/Prototypes/Maps/hammurabi.yml
# Check for other prison maps configurations for comparison
echo -e "\nChecking other prison maps..."
fd prison -e yml -e yaml | xargs rg "minPlayers|PrisonGuard|SecurityOfficer"
Length of output: 4250
| @@ -2,7 +2,7 @@ | |||
| id: CorvaxSplit | |||
| mapName: 'Split Stations' | |||
| mapPath: /Maps/corvax_split.yml | |||
| minPlayers: 25 | |||
| minPlayers: 0 | |||
There was a problem hiding this comment.
💡 Codebase verification
After analyzing the configuration, reducing minPlayers to 0 would severely compromise the intended gameplay design:
- Each station has unique critical roles that cannot be left unfilled:
- Mayhen: Heavy focus on medical (CMO, 3-4 doctors) and science (RD, 4 scientists)
- Payback: Security-focused with HoS and 3-3 officers
- Lumber: Engineering and cargo focused with unique Borg requirements
- Inter-station dependencies are built into the design:
- All stations have trading posts requiring player interaction
- Shared emergency shuttle system
- Lumber has special ruins (3 required) for inter-station exploration
- Minimum staffing needs:
- Command structure (each station needs Captain/HoP)
- Essential services (Security, Medical, Engineering)
- Support roles (Cargo for resource movement)
Recommend maintaining a higher minPlayers value to ensure basic station functionality.
🔗 Analysis chain
Reducing minimum players from 25 to 0 for a multi-station map (Mayhen, Payback, Lumber) could significantly impact the intended gameplay experience:
- Each station has distinct role assignments and responsibilities
- Inter-station interactions may be crucial for gameplay
- The map includes special features like trading stations and ruins that may require multiple players
Let's analyze the station dependencies:
Let me gather more information about the map configuration and job assignments to better understand the station dependencies.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for inter-station dependencies
echo "Analyzing station interactions..."
rg -A 10 "trading_|emergency_|cargo_" Resources/Prototypes/Maps/split.yml
Length of output: 1508
Script:
#!/bin/bash
# Check map configuration and job assignments
echo "Analyzing map configuration..."
cat Resources/Prototypes/Maps/split.yml
echo -e "\nChecking related shuttle configurations..."
for shuttle in trading_mayhen.yml cargo_mayhen.yml trading_payback.yml cargo_payback.yml trading_outpost.yml corvax_emergency.yml
do
if [ -f "Resources/Prototypes/Maps/Shuttles/$shuttle" ]; then
echo -e "\n=== $shuttle ==="
head -n 20 "Resources/Prototypes/Maps/Shuttles/$shuttle"
fi
done
Length of output: 7901
О чем PR
Гайдбук перевод
Почему
Лодка наплакал, ну конечно не всё сделано, например powergrid вроде офф трабл, и напитки, т.к. мне лень было проверить что за ошибка
https://discord.com/channels/1257261160521138187/1258847021867991150/1319450796147871746
Технические детали
Медиа
Summary by CodeRabbit
New Features
Bug Fixes
DeltaVRuleset.Localization
Gameplay Changes