Добавить КД на покупку предметов у карго #147
Conversation
WalkthroughThis pull request introduces several enhancements to the cargo ordering system, primarily by implementing a cooldown mechanism for product orders. A new property, Changes
Suggested labels
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 (
|
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Signed-off-by: OCO_Omega <[email protected]>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (7)
Content.Server/Cargo/Components/StationCargoOrderDatabaseComponent.cs (1)
30-35: Enhance documentation and consider immutabilityA few suggestions to improve this implementation:
- Remove the "GoobStation" reference from the documentation as it's an implementation detail
- Add more descriptive documentation about the dictionary's key-value relationship
- Consider making the dictionary immutable to prevent unintended modifications
Here's the suggested implementation:
/// <summary> - /// GoobStation - Tracks next time that a product on cooldown can be ordered. + /// Maps product IDs to their next available order time. Used to enforce cooldown + /// periods between consecutive orders of the same product. /// </summary> [ViewVariables(VVAccess.ReadOnly), DataField] - public Dictionary<string, TimeSpan> ProductCooldownTime = new Dictionary<string, TimeSpan>(); + public IReadOnlyDictionary<string, TimeSpan> ProductCooldownTime { get; init; } + = new Dictionary<string, TimeSpan>();Resources/Locale/en-US/cargo/cargo-console-component.ftl (1)
35-35: Improve the comment to be more professional and descriptiveThe current comment is informal and doesn't clearly explain the purpose. Consider updating it to better describe the feature's intent.
-# GoobStation - cooldown on Cargo Orders (specifically gamba) +# Implementation of cooldown system for specific cargo orders to regulate purchase frequencyContent.Shared/Cargo/CargoOrderData.cs (1)
32-37: Consider improving property name and adding validationWhile the implementation is solid, consider these improvements:
- Rename to
CooldownSecondsto make the time unit explicit in the property name- Add validation to ensure non-negative cooldown values
/// <summary> -/// GoobStation - The cooldown in seconds before this product can be bought again. +/// The cooldown period in seconds before this product can be bought again. /// </summary> [DataField] -public int Cooldown { get; private set; } +public int CooldownSeconds +{ + get => _cooldownSeconds; + private set => _cooldownSeconds = value >= 0 ? value : 0; +} +private int _cooldownSeconds;Content.Shared/Cargo/Prototypes/CargoProductPrototype.cs (2)
86-91: LGTM! Consider adding value validationThe implementation is clean and well-structured. However, consider adding validation to ensure the cooldown value is non-negative.
[DataField] -public int Cooldown { get; private set; } = 0; +public int Cooldown +{ + get => _cooldown; + private set => _cooldown = Math.Max(0, value); +} + +private int _cooldown = 0;
87-88: Standardize documentation commentThe comment includes a project-specific reference ("GoobStation") which should be removed or standardized for better maintainability.
- /// GoobStation - The cooldown in seconds before this product can be bought again. + /// The cooldown in seconds before this product can be bought again.Resources/Prototypes/Catalog/Cargo/cargo_fun.yml (1)
208-208: Consider using a more formal comment styleThe comment
# GoobStation - 10 minute cooldownis informal. Consider using a more descriptive comment that explains the reasoning behind the cooldown value.- cooldown: 600 # GoobStation - 10 minute cooldown + cooldown: 600 # Restricts gambling crate purchases to once every 10 minutes to prevent abuseResources/Prototypes/Entities/Objects/Weapons/Guns/Projectiles/projectiles.yml (1)
Line range hint
883-897: Modified laser behavior to penetrate windows.The change from
Impassable/BulletImpassabletoOpaquemask allows lasers to pass through windows. This is balanced by reducing the heat damage from 13 to 10.Consider documenting this behavior change in the game's wiki or player documentation, as it significantly affects combat tactics around windows.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (10)
Content.Server/Cargo/Components/StationCargoOrderDatabaseComponent.cs(1 hunks)Content.Server/Cargo/Systems/CargoSystem.Orders.cs(4 hunks)Content.Server/Cargo/Systems/CargoSystem.Shuttle.cs(1 hunks)Content.Shared/Cargo/CargoOrderData.cs(3 hunks)Content.Shared/Cargo/Prototypes/CargoProductPrototype.cs(1 hunks)Resources/Changelog/DeltaVChangelog.yml(1 hunks)Resources/Locale/en-US/cargo/cargo-console-component.ftl(1 hunks)Resources/Locale/ru-RU/cargo/cargo-console-component.ftl(1 hunks)Resources/Prototypes/Catalog/Cargo/cargo_fun.yml(1 hunks)Resources/Prototypes/Entities/Objects/Weapons/Guns/Projectiles/projectiles.yml(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- Resources/Changelog/DeltaVChangelog.yml
🔇 Additional comments (12)
Content.Server/Cargo/Systems/CargoSystem.Orders.cs (2)
213-218: Cooldown time correctly updated after order approval
The product's cooldown time is properly updated upon order approval, ensuring the cooldown mechanism functions as intended.
390-391: Verify all instances of CargoOrderData constructor include cooldown parameter
The constructor for CargoOrderData now includes a cooldown parameter. Ensure that all instantiations of CargoOrderData across the codebase have been updated to include this new parameter to prevent potential errors or unexpected behavior.
Run the following script to locate all instances where CargoOrderData may not include the cooldown parameter:
This script searches for instances where the constructor may have been called without the required cooldown parameter.
✅ Verification successful
Based on the search results, I can now generate the final response:
All CargoOrderData constructor calls include the cooldown parameter
After examining the codebase, all instances of CargoOrderData constructor calls have been properly updated to include the cooldown parameter. The two main instantiations found are:
- In
CargoSystem.Orders.cs:- Line 390:
new CargoOrderData(id, cargoProduct.Product, cargoProduct.Name, cargoProduct.Cost, args.Amount, args.Requester, args.Reason, cargoProduct.Cooldown) - Line 467:
new CargoOrderData(id, spawnId, name, cost, qty, sender, description, 0)
- Line 390:
- In
CargoSystem.Shuttle.cs:- Line 101:
new CargoOrderData(order.OrderId, order.ProductId, order.ProductName, order.Price, spaceRemaining, order.Requester, order.Reason, 0)
- Line 101:
All calls match the constructor signature defined in Content.Shared/Cargo/CargoOrderData.cs which requires 8 parameters including the cooldown.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all usages of CargoOrderData constructor calls with fewer than 8 parameters.
# Search for constructor calls with 7 or fewer arguments (should now be 8)
rg -t cs 'new\s+CargoOrderData\(\s*[^,\)]*(\s*,\s*[^,\)]*){0,6}\s*\)' -A 2
Length of output: 76
Script:
#!/bin/bash
# Let's first find all files that contain CargoOrderData to understand its usage
rg -l "CargoOrderData"
# Then let's examine the class definition and all its usages
rg -A 5 "CargoOrderData"
Length of output: 22362
Content.Server/Cargo/Components/StationCargoOrderDatabaseComponent.cs (1)
Line range hint 1-35: Consider architectural improvements for cooldown management
The addition of cooldown tracking introduces new state management responsibilities to this component. Consider the following architectural suggestions:
- The cooldown management could potentially be split into a separate component if it grows more complex
- We should ensure proper cleanup of expired cooldown entries to prevent memory growth
- The relationship between order capacity and cooldowns should be documented
Let's verify the implementation details:
✅ Verification successful
Let me gather more information about the cooldown implementation to verify the cleanup concerns.
Based on the search results, I can now generate a final response. The code shows that cooldowns are properly managed in the CargoSystem with clear implementation for both checking and setting cooldown times.
Cooldown implementation is well-structured and doesn't require architectural changes
The cooldown system is appropriately implemented:
- Cooldowns are checked before order approval in
CargoSystem.Orders.cs - The system provides user feedback with time remaining when a product is on cooldown
- Cooldown times are managed alongside the game timing system using
_timing.CurTime - Memory concerns are minimal as cooldowns are temporary and tied to specific products
The current implementation is sufficient for its purpose and doesn't warrant splitting into a separate component. The relationship between orders and cooldowns is clear: cooldowns prevent spam-ordering of specific products while the order capacity limits total concurrent orders.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check how cooldowns are managed and cleaned up
rg -A 10 "ProductCooldownTime"
# Check if there are any tests covering the cooldown functionality
fd -e cs -e yaml "Test.*Cargo.*" --exec grep -l "ProductCooldownTime" {} \;
Length of output: 3759
Script:
#!/bin/bash
# Check for any cleanup mechanisms or cooldown-related systems
rg -A 5 "Cooldown.*Cargo"
# Look for the CargoOrderData definition to understand cooldown property
ast-grep --pattern 'class CargoOrderData {
$$$
}'
# Check for any system that might handle cleanup
rg "IEntitySystemManager|ISystem.*Cargo" -A 3
Length of output: 101008
Resources/Locale/en-US/cargo/cargo-console-component.ftl (1)
36-37: Clarify cooldown messaging and verify implementation
The messages are functional but could benefit from some clarification:
- The first message could be more specific about the timing context
- Consider adding a comment documenting expected time units for maintainability
-cargo-console-cooldown-count = Cannot order more than one {$product} at a time.
+cargo-console-cooldown-count = Cannot order more than one {$product} within the cooldown period.
+# Time units can be: seconds, minutes, hours
cargo-console-cooldown-active = Orders for {$product} cannot be placed for another {$timeCount} {$timeUnits}.Let's verify the usage of these strings and their parameters:
✅ Verification successful
Cooldown messages are correctly implemented, but suggestion for clarity remains valid
The code review shows that:
- The cooldown messages are used correctly with proper parameter passing
- Time units are consistently handled, automatically choosing between "minutes" and "seconds"
- The "at a time" message is specifically used when order quantity > 1, making the current message accurate
The original suggestion to add a comment about time units is unnecessary since the code clearly shows it only uses "minutes" and "seconds". However, the suggestion to clarify the first message would still improve readability:
-cargo-console-cooldown-count = Cannot order more than one {$product} at a time.
+cargo-console-cooldown-count = Cannot order multiple {$product} in a single order.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usage of these cooldown messages to ensure consistent parameter passing
rg -l "cargo-console-cooldown-(count|active)" --type-add 'cs:*.cs' --type cs
Length of output: 129
Script:
#!/bin/bash
# Let's examine the actual usage of these messages in the cargo system
rg "cargo-console-cooldown-(count|active)" -A 5 -B 5 --type-add 'cs:*.cs' --type cs
Length of output: 1923
Resources/Locale/ru-RU/cargo/cargo-console-component.ftl (2)
34-36: LGTM! The translations are accurate and well-structured.
The new Russian translations correctly convey:
- The limitation of one product per order
- The active cooldown period with proper placeholders for dynamic content
34-34: Please clarify the scope of the cooldown feature.
The comment mentions this is for "gamba" (gambling), but the implementation appears generic. Could you please clarify:
- Is this cooldown mechanism specifically for gambling-related items?
- If so, should we make the translations more specific to gambling items?
- If not, should we remove the gambling-specific comment?
Let's check if there are any gambling-specific references in the codebase:
✅ Verification successful
Let's broaden our search to understand both the gambling context and the cargo cooldown implementation.
The cooldown comment is accurate and should be kept
The cooldown mechanism is indeed specifically implemented for gambling-related cargo orders. This is evidenced by:
- The gambling crate (
FunCrateGambling) has an explicit 10-minute cooldown incargo_fun.yml - The comment accurately reflects this specific implementation, as the cooldown was added to prevent abuse of the gambling system
- The translation string is part of the cargo console component that handles these cooldown messages
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for gambling-related terms to understand the scope
rg -i "gamba|gambling|casino" --type-add 'proto:*.proto' --type proto
Length of output: 220
Script:
#!/bin/bash
# Search for gambling-related terms in all files
rg -i "gamba|gambling|casino"
# Also search for cargo cooldown related configurations
rg -i "cargo.*cooldown|cooldown.*cargo"
Length of output: 6913
Script:
#!/bin/bash
# Let's check the cargo product definitions to see if cooldown is specifically applied to gambling items
rg -C 5 "FunCrateGambling|CrateCargoGambling" Resources/Prototypes/Catalog/
Length of output: 1981
Content.Shared/Cargo/CargoOrderData.cs (1)
Line range hint 61-72: Review implementation of gambling-related cooldown mechanism
A few concerns about the implementation:
- The comment mentions "gamba" (gambling), which may have legal/regulatory implications
- Consider adding parameter validation
- Comment style differs from the codebase standard
-// GoobStation - (cooldown parameter) cooldown on Cargo Orders (specifically gamba)
+/// <param name="orderId">Unique identifier for the order</param>
+/// <param name="productId">Product prototype identifier</param>
+/// <param name="productName">Display name of the product</param>
+/// <param name="price">Price of the order</param>
+/// <param name="amount">Quantity being ordered</param>
+/// <param name="requester">Name of the requesting entity</param>
+/// <param name="reason">Reason for the order</param>
+/// <param name="cooldown">Minimum time in seconds between orders of this product</param>
public CargoOrderData(int orderId, string productId, string productName, int price, int amount, string requester, string reason, int cooldown)
{
+ if (cooldown < 0)
+ throw new ArgumentException("Cooldown cannot be negative", nameof(cooldown));
+
OrderId = orderId;
ProductId = productId;
ProductName = productName;
Price = price;
OrderQuantity = amount;
Requester = requester;
Reason = reason;
- // GoobStation - (cooldown assignment) cooldown on Cargo Orders (specifically gamba)
Cooldown = cooldown;
}Content.Shared/Cargo/Prototypes/CargoProductPrototype.cs (1)
86-91: Verify integration with cargo system components
The cooldown property needs to be properly integrated with other cargo system components.
✅ Verification successful
Cooldown property is properly integrated with cargo system components
The cooldown property is well integrated within the cargo system:
- Properly stored in
CargoOrderData - Correctly tracked in
StationCargoOrderDatabaseComponentusingProductCooldownTimedictionary - Properly handled in
CargoSystem.Orders.cswith:- Cooldown validation before order processing
- Time tracking using
_timing.CurTime - Proper cooldown enforcement with remaining time calculation
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the integration of the cooldown property with other cargo system components
# Check for cooldown usage in cargo system
echo "Checking cooldown usage in cargo system components..."
rg -l "Cooldown" --type cs | grep -i "cargo"
# Check for related database component
echo "Checking for StationCargoOrderDatabaseComponent..."
ast-grep --pattern 'class StationCargoOrderDatabaseComponent {
$$$
ProductCooldownTime
$$$
}'
# Check for cooldown handling in order processing
echo "Checking for cooldown handling in order processing..."
ast-grep --pattern 'class CargoSystem {
$$$
Cooldown
$$$
}'
Length of output: 774
Script:
#!/bin/bash
# Let's examine the actual implementation and usage of Cooldown in cargo system
# Check CargoOrderData.cs for cooldown implementation
echo "=== Checking CargoOrderData.cs ==="
rg "Cooldown" Content.Shared/Cargo/CargoOrderData.cs -C 2
# Check CargoSystem.Orders.cs for cooldown handling
echo -e "\n=== Checking CargoSystem.Orders.cs ==="
rg "Cooldown" Content.Server/Cargo/Systems/CargoSystem.Orders.cs -C 2
# Check StationCargoOrderDatabaseComponent for cooldown tracking
echo -e "\n=== Checking StationCargoOrderDatabaseComponent ==="
rg "Cooldown" Content.Server/Cargo/Components/StationCargoOrderDatabaseComponent.cs -C 2
# Look for any methods that might handle cooldown
echo -e "\n=== Checking for cooldown-related methods ==="
ast-grep --pattern 'method($_) {
$$$
Cooldown
$$$
}'
Length of output: 2057
Resources/Prototypes/Catalog/Cargo/cargo_fun.yml (1)
201-210: Verify the gambling mechanics implementation
Please ensure that:
- The referenced
CrateCargoGamblingproduct exists and implements appropriate gambling mechanics - The high cost (10000) and cooldown (600s) values are balanced for gameplay
✅ Verification successful
Let me analyze the results and generate a final response.
The search results show:
CrateCargoGamblingis defined inResources/Prototypes/Catalog/Fills/Crates/cargo.yml- The crate is referenced in the cargo product and a shuttle map
- There are gambling-related entities like gambling tables, but no direct connection to the crate's mechanics
Let me check the crate's definition to understand its contents.
Gambling mechanics are properly implemented with appropriate risk/reward balance
The gambling crate implementation is verified and well-balanced:
- It's a lottery-style crate with a 0.1% chance of winning 1,000,000 space cash
- The 10,000 cost and 10-minute cooldown are appropriate given the potential high payout
- The mechanics are simple and transparent, implemented through standard probability-based StorageFill
- The crate is properly secured (inherits from CratePrivateSecure)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the CrateCargoGambling product is properly defined
rg "CrateCargoGambling" --type yaml
# Look for any gambling-related configuration or restrictions
rg "gambling|bet|wager" --type yaml
Length of output: 22760
Script:
#!/bin/bash
# Check the gambling crate contents
cat Resources/Prototypes/Catalog/Fills/Crates/cargo.yml | grep -A 10 "CrateCargoGambling"
Length of output: 405
Content.Server/Cargo/Systems/CargoSystem.Shuttle.cs (1)
168-172: 🛠️ Refactor suggestion
Improve documentation and handle cooldown splitting consistently
The changes introduce cooldown handling for cargo orders, but there are several concerns:
- The comment should be more professional and explain the general purpose rather than using informal terms like "gamba".
- Setting cooldown to 0 for split orders could potentially be used to bypass cooldown restrictions.
- The code appears to be specific to "GoobStation" but seems like a general feature.
Consider these improvements:
- // GoobStation - cooldown on Cargo Orders (specifically gamba)
- // We won't be able to fit the whole order on, so make one
- // which represents the space we do have left:
+ // When an order cannot be fully accommodated due to space constraints,
+ // create a reduced order with the remaining space while preserving the original cooldown
var reducedOrder = new CargoOrderData(order.OrderId,
- order.ProductId, order.ProductName, order.Price, spaceRemaining, order.Requester, order.Reason, 0);
+ order.ProductId, order.ProductName, order.Price, spaceRemaining, order.Requester, order.Reason, order.Cooldown);Let's verify if this cooldown mechanism is consistently implemented:
✅ Verification successful
Based on the search results, I can see that the CargoOrderData class has a Cooldown property that is used to track cooldown periods for cargo orders. Let me verify the implementation of cooldown handling in the cargo system by searching for relevant code.
Let me check the broader cargo order handling to understand how cooldowns are managed across the system.
Based on the code review, I can now provide a final response regarding the cooldown handling in the cargo system.
The cooldown implementation is correct and working as intended
The code shows that:
- The cooldown system is properly implemented with the
ProductCooldownTimedictionary inStationCargoOrderDatabaseComponenttracking cooldowns per product. - When splitting orders due to space constraints, setting cooldown to 0 is correct because:
- The original order's cooldown is already applied when approved (in
CargoSystem.Orders.cs) - The reduced order is just a portion of an already approved order, not a new purchase
- The cooldown is meant to limit purchase frequency, not split deliveries
- The original order's cooldown is already applied when approved (in
The comment about "gamba" (gambling) suggests this is an intentional game design feature to prevent abuse of certain purchasable items, and the cooldown is properly enforced at the approval stage.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other cooldown-related code to ensure consistent handling
rg -A 3 "Cooldown" --type cs
Length of output: 100366
Script:
#!/bin/bash
# Search for cargo order cooldown handling
ast-grep --pattern 'class CargoOrderData {
$$$
Cooldown $$$
$$$
}'
# Also check for any cooldown-related code in cargo systems
rg -A 5 "Cooldown.*=.*" Content.Server/Cargo/Systems/
Length of output: 669
Script:
#!/bin/bash
# Look for cargo order handling code
rg -l "CargoOrderData" --type cs
# Then get the content of key cargo system files
cat Content.Server/Cargo/Systems/CargoSystem.Orders.cs
cat Content.Shared/Cargo/CargoOrderData.cs
Length of output: 26637
Resources/Prototypes/Entities/Objects/Weapons/Guns/Projectiles/projectiles.yml (2)
Line range hint 899-931: Well-structured spread variants with balanced parameters.
The new spread variants provide good tactical variety:
- Wide spread (5 shots, 30°): High potential damage but requires close range
- Narrow spread (4 shots, 10°): More focused for medium range
- Disabler spread (3 shots, 9°): Balanced for non-lethal options
The spread parameters appear well-balanced, with appropriate tradeoffs between shot count and spread angle.
621-629: Significant increase in omega particle lethality.
The changes increase both severity (0.1 → 0.3) and damage (20 → 30), making omega particles considerably more lethal. This aligns with the AI summary's note about increased danger to Mystagogues.
✅ Verification successful
Omega particle damage increase appears intentionally balanced
The search results confirm this is a deliberate balance change:
- The uplink catalog description indicates omega particles are meant to be powerful, specifically designed to "inflict severe burns and cause anomalies to go supercritical"
- Comparing to other anomalous particles in the codebase, the standard severity hit value is 0.05, making the omega particle's new 0.3 value significantly higher
- This aligns with its role as a specialized weapon obtained through the uplink system
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any balance discussions or related changes
rg -i "omega.*particle.*damage" -g "!*.yml"
Length of output: 45
Script:
#!/bin/bash
# Let's search for any mentions of omega particles in the codebase
rg -i "omega.*particle" -g "!*.yml" -A 2
# Also search for any related configuration or balance discussions
rg -i "anomalous.*particle" -g "!*.yml" -A 2
# Check if there are any other similar projectiles for comparison
rg "severityPerSeverityHit|healthPerWeakeningeHit" Resources/Prototypes/Entities/Objects/Weapons/Guns/Projectiles/
Length of output: 9738
| // GoobStation - cooldown on Cargo Orders (specifically gamba) | ||
| var order = new CargoOrderData(id, spawnId, name, cost, qty, sender, description, 0); |
There was a problem hiding this comment.
Potential oversight: Cooldown value set to zero
The Cooldown value is hardcoded to 0 when creating a new CargoOrderData instance. If the product associated with the order has a non-zero cooldown, this may bypass the intended cooldown mechanism. Consider retrieving the product's cooldown value or explicitly setting an appropriate cooldown.
Apply this diff to fix the issue:
-var order = new CargoOrderData(id, spawnId, name, cost, qty, sender, description, 0);
+// Assuming you have access to the product's cooldown value
+var cooldown = GetProductCooldown(spawnId);
+var order = new CargoOrderData(id, spawnId, name, cost, qty, sender, description, cooldown);Ensure that GetProductCooldown(spawnId) correctly retrieves the cooldown value associated with the product.
Committable suggestion skipped: line range outside the PR's diff.
| // GoobStation - cooldown on Cargo Orders (specifically gamba) | ||
| if (order.Cooldown > 0) | ||
| { | ||
| if (orderDatabase.ProductCooldownTime.TryGetValue(order.ProductId, out var cooldownTime) && cooldownTime > _timing.CurTime) | ||
| { | ||
| var timeLeft = (cooldownTime - _timing.CurTime); | ||
| (int count, string units) timeInfo = (timeLeft.Minutes > 0) ? (timeLeft.Minutes, "minutes") : (timeLeft.Seconds, "seconds"); | ||
| ConsolePopup(args.Actor, Loc.GetString("cargo-console-cooldown-active", ("product", order.ProductName), ("timeCount", timeInfo.count), ("timeUnits", timeInfo.units))); | ||
| PlayDenySound(uid, component); | ||
| return; | ||
| } | ||
| if (order.OrderQuantity > 1) | ||
| { | ||
| ConsolePopup(args.Actor, Loc.GetString("cargo-console-cooldown-count", ("product", order.ProductName))); | ||
| PlayDenySound(uid, component); | ||
| return; | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Potential issue with TimeSpan component usage for cooldown display
The use of timeLeft.Minutes and timeLeft.Seconds may result in incorrect time displays when the cooldown exceeds one hour, as TimeSpan.Minutes returns the minute component within the hour. To accurately reflect the remaining cooldown time, consider using timeLeft.TotalMinutes and timeLeft.TotalSeconds, and cast them to integers.
Apply this diff to fix the issue:
-(int count, string units) timeInfo = (timeLeft.Minutes > 0) ? (timeLeft.Minutes, "minutes") : (timeLeft.Seconds, "seconds");
+(int count, string units) timeInfo = (timeLeft.TotalMinutes >= 1)
+ ? ((int) timeLeft.TotalMinutes, "minutes")
+ : ((int) timeLeft.TotalSeconds, "seconds");📝 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.
| // GoobStation - cooldown on Cargo Orders (specifically gamba) | |
| if (order.Cooldown > 0) | |
| { | |
| if (orderDatabase.ProductCooldownTime.TryGetValue(order.ProductId, out var cooldownTime) && cooldownTime > _timing.CurTime) | |
| { | |
| var timeLeft = (cooldownTime - _timing.CurTime); | |
| (int count, string units) timeInfo = (timeLeft.Minutes > 0) ? (timeLeft.Minutes, "minutes") : (timeLeft.Seconds, "seconds"); | |
| ConsolePopup(args.Actor, Loc.GetString("cargo-console-cooldown-active", ("product", order.ProductName), ("timeCount", timeInfo.count), ("timeUnits", timeInfo.units))); | |
| PlayDenySound(uid, component); | |
| return; | |
| } | |
| if (order.OrderQuantity > 1) | |
| { | |
| ConsolePopup(args.Actor, Loc.GetString("cargo-console-cooldown-count", ("product", order.ProductName))); | |
| PlayDenySound(uid, component); | |
| return; | |
| } | |
| } | |
| // GoobStation - cooldown on Cargo Orders (specifically gamba) | |
| if (order.Cooldown > 0) | |
| { | |
| if (orderDatabase.ProductCooldownTime.TryGetValue(order.ProductId, out var cooldownTime) && cooldownTime > _timing.CurTime) | |
| { | |
| var timeLeft = (cooldownTime - _timing.CurTime); | |
| (int count, string units) timeInfo = (timeLeft.TotalMinutes >= 1) | |
| ? ((int) timeLeft.TotalMinutes, "minutes") | |
| : ((int) timeLeft.TotalSeconds, "seconds"); | |
| ConsolePopup(args.Actor, Loc.GetString("cargo-console-cooldown-active", ("product", order.ProductName), ("timeCount", timeInfo.count), ("timeUnits", timeInfo.units))); | |
| PlayDenySound(uid, component); | |
| return; | |
| } | |
| if (order.OrderQuantity > 1) | |
| { | |
| ConsolePopup(args.Actor, Loc.GetString("cargo-console-cooldown-count", ("product", order.ProductName))); | |
| PlayDenySound(uid, component); | |
| return; | |
| } | |
| } |
|
В идеале добавить кд на предметы которые ломают экономику или для ограничения карго по вооружению. |
|
На будущее |
О чем PR
Почему
Технические детали
Медиа
Summary by CodeRabbit
Release Notes
New Features
User Interface Enhancements
Bug Fixes
Changelog