Pr work #163
Pr work #163
Conversation
Signed-off-by: GeneralGaws <[email protected]>
WalkthroughThe pull request introduces modifications to game configuration files, focusing on adjusting game rules, event scheduling, and game presets. Changes include updating time parameters for space traffic control events, reducing the maximum occurrences of unknown shuttle events, and modifying player limits and voting visibility for various game presets. These updates aim to fine-tune gameplay mechanics and event frequencies across different game modes. Changes
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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
Resources/Prototypes/game_presets.yml (1)
Line range hint
190-190: Reconsider enabling vote visibility for Deathmatch.Making Deathmatch votable (showInVote: true) while having a maxPlayers limit of 5 could:
- Lead to frequent vote requests for a very limited game mode
- Cause frustration when players can't join due to the low player limit
- Create confusion when the mode is voted for but can't accommodate all voters
Consider either:
- Keeping showInVote: false for limited-capacity modes
- Increasing maxPlayers if the mode is to be votable
🧹 Nitpick comments (1)
Resources/Prototypes/GameRules/roundstart.yml (1)
341-344: Document the reasoning behind specific timing values.While the increased delays align with reducing shuttle frequency, the specific timing values (8900, 8720, 11200, 7900, 7720, 9200) would benefit from documentation explaining:
- Why these specific values were chosen
- What these timings represent in real gameplay duration
- How they coordinate with other game events
Consider adding comments explaining the timing choices, for example:
- type: BasicStationEventScheduler - minimumTimeUntilFirstEvent: 8900 #NES14-Changes + minimumTimeUntilFirstEvent: 8900 # ~148 minutes: Allows for station setup and early game progression minMaxEventTiming: - min: 8720 - max: 11200 + min: 8720 # ~145 minutes: Minimum time between shuttle events + max: 11200 # ~186 minutes: Maximum time between shuttle eventsAlso applies to: 353-356
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
Resources/Prototypes/GameRules/roundstart.yml(2 hunks)Resources/Prototypes/GameRules/unknown_shuttles.yml(5 hunks)Resources/Prototypes/game_presets.yml(2 hunks)
🔇 Additional comments (1)
Resources/Prototypes/GameRules/unknown_shuttles.yml (1)
61-61: LGTM: Changes align with PR objective.
The reduction of maxOccurrences to 1 for all shuttle events and the removal of hostile encounters effectively implements the goal of reducing unknown shuttle frequency in the station sector. The changes are consistent across all shuttle types, maintaining balance while reducing event frequency.
Also applies to: 71-71, 81-81, 101-101, 220-220
| @@ -80,6 +80,7 @@ | |||
| - shittersafari | |||
| name: extended-title | |||
| showInVote: false #2boring2vote # DeltaV - I'd like to disagree, used for periapsis. | |||
| maxPlayers: 3 # Stray | |||
There was a problem hiding this comment.
💡 Codebase verification
Let me analyze the output to verify the concern about player limits.
The search results show:
- Most maps have maxPlayers ranging from 30-80 players
- Even smaller maps like 'reach' and 'frame' support 20 players
- Various game events and rules have minimumPlayers requirements:
- Basic events require 10-15 players
- Many station events expect 20-30 players
- Some advanced events need 40-50 players
Let me generate the final response:
Setting maxPlayers to 3 is too restrictive and incompatible with game design
The codebase shows that the game is designed for significantly higher player counts:
- Most maps support 30-80 players
- Basic station events require 10-15 players minimum
- Many gameplay mechanics expect 20+ players for proper functioning
🔗 Analysis chain
Consider increasing the player limits for Extended and Greenshift presets.
Setting maxPlayers to 3 for both Extended and Greenshift presets seems extremely restrictive. Such low player counts could:
- Lead to underpopulated stations
- Reduce player interaction and gameplay opportunities
- Impact station maintenance and emergency response capabilities
Also applies to: 99-99
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any station roles or systems that require more than 3 players
rg -A 2 "minPlayers:|minimumPlayers:" Resources/Prototypes/
Length of output: 20199
|
молимся чтоб прошли |
|
ЗДЕСЬ я могу СРАТЬ |
О чем PR
Почему
Технические детали
Медиа
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
maxPlayersandshowInVotesettings.