joi_s4 - #62
Conversation
… estimate, UI & persistence refinements
──────
### Summary
Implemented a realistic degradation model where a part can degrade to Good or jump directly to Critical, updated the maintenance‑days estimation to match the new 20 % degradation chance, fixed the direct‑assignment bug by
using BreakDown(), and incorporated several earlier quality‑of‑life improvements (persistence, menu restructuring, production‑flow realism, batch handling, and localisation) that were completed in previous checkpoints.
──────
──────
### Detailed Changes
File | Change | Reason
-----------------|--------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------
File | Change | Reason
-----------------|----------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------
Core/Machine.cs | • Updated GetEstimatedDaysUntilMaintenance comment and divisor from 0.8 → 0.2 to reflect 20 % wear probability.• | Provides the logical model the user requested and fixes accessibility errors.
| Adjusted the calculation: expectedCycles = minSteps * N / 0.2.• Re‑implemented ApplyProductionWearAndTear: - |
| ApplyProductionWearAndTear: - Added explanatory comments describing the 20 % overall chance and the 10 %/10 |
| % split for Excellent parts. - When the part is Excellent, a second random roll decides Good (10 %) or a |
| direct Critical (10 %) using selectedPart.BreakDown(). - When the part is Good, it degrades to Critical (20 |
| %). - Kept Critical parts unchanged.• Replaced direct Condition = PartCondition.Critical with the |
| encapsulated selectedPart.BreakDown() to respect the part’s API. |
Core/MachinePart.cs | No code changes, but referenced to clarify that BreakDown() is now the proper way to force a part to | Needed for the new degradation path.
| Critical. |
Core/ProductionOrder.cs | Added BatchId property to track a production batch across interruptions. | Allows reuse of an existing batch instead of creating duplicates on a machine
| | trip.
UI/ProductionMenuHandler.cs | • Integrated batch‑reuse logic using BatchId.• Ensured the live‑feed UI updates to the final progress count | Improves user experience and matches the “final number before price”
| before prompting for pricing.• Suppressed pricing prompts on intermediate trips; now only shown when an | requirement.
| order finishes. |
| final progress count before prompting for pricing.• Suppressed pricing prompts on | requirement.
| intermediate trips; now only shown when an order finishes. |
UI/SalesMenuHandler.cs | Implemented UseConverter to filter unsold batches and present only relevant batch | Aligns sales view with the new batch handling.
| choices. |
UI/AccountingMenuHandler.cs | Propagated reportRequestsRepo and added state‑saving for accounting data. | Guarantees persistence of accounting reports.
UI/Program.cs | Removed the now‑obsolete “Factory Information” menu entry and cleaned the switch‑case | Reflects the user’s decision to drop that menu.
| handling. |
Text/Machines.cs | Added localisation strings for the new degradation messages and spinner updates. | Keeps UI text externalised and consistent.
Text/Sales.cs (reference) | No changes, but used as a source for localisation patterns. | Supporting consistency.
UI/FactoryReportMenuHandler.cs | Deleted file (obsolete after menu removal). | Eliminates dead code.
Persistence files (orders.json, report_requests.json) | Not code files, but now the system writes pending orders and report requests here via | Guarantees data survives crashes.
| the new JSON repositories. |
Project metadata | Updated README / comments where applicable to note the 20 % degradation configuration. | Documentation consistency.
──────
### Why These Changes Matter
• Realistic wear‑and‑tear – The machine now mirrors the user‑specified 20 % chance with a split between gradual degradation and sudden failure, making the simulation more believable.
• Accurate maintenance forecasting – The GetEstimatedDaysUntilMaintenance method now returns values that align with the new probability, eliminating the previous 5/10‑day confusion.
• Robust API usage – Using BreakDown() respects encapsulation and resolves the earlier compile‑time access error.
• Batch integrity – Introducing BatchId prevents duplicate batch creation when a machine trips, fixing the “price each time it trips” bug.
• UI polish – Live‑feed now shows the final production count before prompting for price, and menus have been trimmed to the requested set.
• Persistence – JSON repositories ensure orders and report requests survive application restarts.
• Localization – All user‑visible strings live in the Text project, simplifying future translations.
Signed-off-by: CasperGamingOne <caspergamingone@outlook.dk>
Qodana Community for .NET113 new problems were found
View the detailed Qodana reportTo be able to view the detailed Qodana report, you can either:
To get - name: 'Qodana Scan'
uses: JetBrains/qodana-action@v2026.1.3
with:
upload-result: trueContact Qodana teamContact us at qodana-support@jetbrains.com
|
Summary by JulesThis branch ( New Features
Bug Fixes
Enhancements
Refactoring
Files Changed
Total: 34 files changed, +1 184 insertions, −590 deletions |
|
@ganeaandreea701-crypto ⬆️ ⬆️ |
No description provided.