raylu
pushed to updatesjun2 at raylu/pruncalc
8397f14ecc Expand_Dropdown_Options_Via_Interpolation
Removed `0` values in favor of 'Omit From Calculation' logic and dynamically generated deep numerical option arrays for Round Trip and Target Permit parameters.
PURPOSE:
To provide a comprehensive range of configuration without cluttering the underlying source code. Because `0` is mathematically equivalent to the `Omit From Calculation` bypasses previously established, explicitly removing `0` as a visual option streamlines user intent and removes redundancy. Additionally, leveraging ES6 string interpolation allows us to inject dozens of options (e.g. up to 50 permit tiers) cleanly within the HTML template literal.
IMPLEMENTATION DETAILS:
- `ts/roi.ts`: Changed the initialization fallback for `roundTripOption` from `0` to `omit` so cached users don't trigger a missing option value.
- `ts/roi.ts`: Removed `<option value="0">0</option>` from the `working-capital` dropdown menu array.
- `ts/roi.ts`: Replaced the hardcoded lists for `round-trip` and `target-permit` with `Array.from()` map functions that inherently join directly into the HTML string, outputting consecutive `<option>` elements spanning lengths 1-25 and 2-50 respectively.
- fb96c4b1e6 Add_Omit_Calculations_Dropdown_Toggles
Replaced textual numerical `<input>` fields with strict dropdown `<select>` options, adding an explicit 'Omit From Calculation' bypass.
PURPOSE:
To improve UI safety while providing a distinct toggle for isolating base construction costs. Numerical inputs run the risk of user error (e.g., typos that generate infinite loops or mathematically impossible supply chain matrices). Locking the inputs to predetermined `<select>` arrays prevents mathematical overflow. Furthermore, adding 'Omit From Calculation' allows players to instantly sever the OpEx, Ship, or HQ logic from the CapEx pipeline, providing a clean method to evaluate pure localized factory ROI.
IMPLEMENTATION DETAILS:
- `ts/roi.ts`: Overhauled the DOM generation block, swapping `<input type="number">` to `<select>` arrays for `round-trip`, `working-capital`, and `target-permit`.
- `ts/roi.ts`: Migrated `roundTripOption` and `targetPermitOption` variables from parsed integers back to raw strings to safely encapsulate the `omit` logic branch without firing `NaN` errors.
- `ts/roi.ts`: Within the `.map()` derivation block, encased the HQ, OpEx, and Little's Law math inside `if (Option !== 'omit')` safeguards. When bypassed, the variables strictly default to `0`, isolating the CapEx calculation strictly to base construction.
- `ts/roi.ts`: Updated the CapEx cell tooltip constructor. If an option evaluates to `'omit'`, its string interpolation block is completely bypassed, vanishing that specific text from the hover element entirely to confirm to the user that the logic was cleanly severed.
- 469c02f6ff Add_Dynamic_OpEx_and_Little's_Law_Ship_Calculations
Refactored ship capacity planning and implemented context-aware dynamic OpEx capital requirements.
PURPOSE:
To achieve maximum fidelity in supply chain modeling. Ship fleets are constrained by round-trip duration, which dictates exactly how many discrete vessels must be purchased to sustain continuous daily throughput (Little's Law). Furthermore, inventory working capital (OpEx Days) can be tied natively to the shipping bottleneck. If a bulky product mandates a shipment every 2 days, the company mathematically only needs 2 days of OpEx buffer, preventing capital over-allocation.
IMPLEMENTATION DETAILS:
- `roi.py`: Completely stripped out the static `ship_capex_per_base` pre-calculation, as its derivation is now fully handled in real-time by the frontend.
- `ts/roi.ts`: Replaced the "Include Ships" checkbox and "Days OpEx" numerical input with a "Round Trip (hrs)" input and a "Days OpEx" dropdown.
- `ts/roi.ts`: The dropdown includes `<option value="dynamic">Max for Shipment (dynamic)</option>` alongside standard integer days `0` through `30`.
- `ts/roi.ts`: Within the `.map()` derivation block, if the `dynamicOpEx` parameter is active, the script evaluates `1 / p.normalized_logistics_per_base` to derive the exact number of days a recipe takes to fill a standard freighter, scaling the working capital CapEx requirement dynamically row-by-row.
- `ts/roi.ts`: Implemented `const shipsNeeded = p.normalized_logistics_per_base * (roundTripHours / 24);` to evaluate the exact fleet capacity required for continuous throughput, multiplying by 800,000 to assign the CapEx. This effectively deletes the capital cost if the user inputs `0` hours.
- `ts/roi.ts`: Updated the CapEx column tooltip to output the specific evaluated `activeWorkingCapitalDays`, `activeShipCapex`, and `shipsNeeded` metrics to maintain visual verification of the dynamic math.
- f04969ad6b Update_Percentile_Formatting_and_Logic_Inversion
Changed percentile format to standard percentage syntax (`99.0%`) and inverted cost metrics so `100.0%` universally equates to the best outcome.
PURPOSE:
To establish logical consistency and readability. Previously, percentiles merely mapped to numerical size (`0.00` to `1.00`), causing "bad" metrics like massive capital expenditures to boast a 99th percentile rating, which contradicts established data analysis conventions. By inverting the math strictly for cost-based metrics, users can now quickly skim the dashboard knowing that `99.0%` is an objectively excellent outcome across every single column.
IMPLEMENTATION DETAILS:
- `ts/roi.ts`: Modified `getPercentile()` to accept an `invert: boolean = false` parameter.
- `ts/roi.ts`: When `invert` is active, the function calculates `1.0 - decimal` before formatting.
- `ts/roi.ts`: Updated the return string from `.toFixed(2)` to `(decimal * 100).toFixed(1) + "%"`.
- `ts/roi.ts`: Explicitly routed the six calls: `profit_per_base` and `market_capacity_base` remain `false` (highest numerical value is best), while `break_even`, `capex_val`, `opex_val`, and `normalized_logistics_per_base` are passed as `true` (lowest numerical value is best).
- `ts/roi.ts`: Updated the "Profit/Base" tooltip legend to explicitly clarify the new 100.0% desirability metric for the user.
- e5ca96babe Add_Negative_Profit_Toggle
Implemented a UI toggle to filter out negative-profit recipes post-derivation.
PURPOSE:
To immediately declutter the table by vanishing mathematically unviable base builds. By establishing this filter *after* the dynamic metric evaluation (VWAP/Bid/Ask), but *before* the percentile arrays are generated, the mathematical baseline for percentiles remains pure and context-accurate.
IMPLEMENTATION DETAILS:
- `ts/roi.ts`: Added `<input type="checkbox" id="show-negative">` to the DOM header block, bound to the `showNegativeProfit` state variable (defaulting to true) and synced with `localStorage`.
- `ts/roi.ts`: Changed the instantiation of `profitsWithMetrics` from `const` to `let`.
- `ts/roi.ts`: Injected an `if (!showNegativeProfit)` block immediately following the `.map()` derivation block. This explicitly overwrites the array with a strict `> 0` profit filter.
- Because this structural wipe occurs prior to `arrProfit`, `arrBreak`, etc. being populated, all money-losing rows are flawlessly excluded from the percentile generation logic.
- View comparison for these 55 commits »
1 week ago
