Главная Обзор Помощь
Вход
knottly
Репозитории Активность

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • 619a2f9299 Add GitHub Actions workflow for Pages deployment

1 месяц назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • 40ce74ef3f Add methodology documentation block Purpose: Add a persistent "How it Works" section to the bottom of the page to demystify the background calculations. - Created a new `initDocumentation()` function utilizing DOM manipulation to dynamically build a comprehensive `<details>` HTML block. - Styled the block to blend naturally with the existing UI, using standard CSS for spacing and borders. - Broken down the mathematical process behind Area normalization, CapEx/OpEx mapping, Logistics standardizations, and percentile weights into 6 readable sections. - Triggered the initialization exactly once at the end of the script execution loop.

1 месяц назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • a198b50c67 Force vertical stacking of percentiles in ROI table Purpose: Fix erratic CSS layout wrapping where percentiles would sometimes sit adjacent to the value instead of stacking neatly beneath it on wider displays. - Modified the `tr.innerHTML` assignments in `ts/roi.ts`. - Swapped the empty space characters that separated the value and the `<span>` tags with explicit `<br>` line break tags.

1 месяц назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • f9df56d946 Add percentile display toggle Purpose: Simplify and declutter the table UI by changing the dual-percentile output string `(rel / abs)` into a single output string toggled by the user. - Added `percentileMode` state tied to localStorage (`roi-pct-mode`). - Injected a new select dropdown into the metrics controls to swap between "Normalized (Weighted)" and "Absolute". - Updated the `getPercentiles` lookup in the render loop to fetch `.abs` or `.rel` dynamically based on state. - Removed the parentheses from the HTML template literal outputs. - Updated the tooltip explainer to document the new behavior.

1 месяц назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • 65b2cb61b6 Fix copy-paste duplication bugs in ts/roi.ts Purpose: Fix compilation errors originating from syntax and scoping issues. The previous commit inadvertently introduced severe copy-paste duplicate blocks in several locations: - Around the `const runs_per_base = ...` loop inside `render()`, creating duplicate `capexCell`, `profitCell`, and `marketCell` let/const definitions, crashing TS scope logic. - Redundant `let savedBuilding` assignments. - A malformed partial duplication of `function formatMatPrices() { ... }` that lacked a closing bracket. - Redundant object key fields for interface declarations `Metrics`, `Profit`, and `MatPrice`. All unneeded redundancies have been surgically cleared, allowing `bun build` to compile properly again.
  • 2122aec098 Cleaned up extrenious logging some more
  • 0fa7c0135a removed www logging
  • Просмотр сравнение для этих 3 коммитов »

1 месяц назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • 8015c1cd70 Merge branch 'updatesjun2' of https://git.raylu.net/raylu/pruncalc into updatesjun2
  • 1f83560dac Merge branch 'main' of https://git.raylu.net/raylu/pruncalc into updatesjun2
  • d30d98757f Manually Staging Updates
  • 8c4214824c aen
  • 31d261a677 Add_Relative_Volume-Weighted_Percentile_Ranking Replaced single absolute percentile calculations with a dual absolute/relative formatting string `(Relative% / Absolute%)` to capture cash-flow market weight. PURPOSE: To protect users from falsely prioritizing "statistically excellent" base builds that operate in tiny, illiquid markets. Calculating a relative percentile weighted by the maximum potential cash flow of a recipe isolates the highly profitable, massively traded commodities from the niche, low-volume anomalies. Displaying both metrics simultaneously provides a holistic strategic assessment: an `(80.0% / 99.0%)` rank immediately informs the player that the recipe is top 1% mechanically, but only top 20% when scaled against global market liquidity. IMPLEMENTATION DETAILS: - `ts/roi.ts`: Added `market_cash_flow = revenue_val * p.market_capacity_base` to the `.map()` derivation block. This defines the weight limit, dynamically computing the total global daily market capitalization for the recipe's bottleneck item. - `ts/roi.ts`: Modified all 6 structural mapping arrays (e.g. `arrProfit`, `arrCapex`) to store object tuples `{val: number, weight: number}` rather than isolated numeric primitives. - `ts/roi.ts`: Redesigned `getPercentiles()` to simultaneously calculate `absDecimal` based on unweighted item count and `relDecimal` based on the sum of `market_cash_flow` weights below the target row. Designed a max-denominator mapping system to ensure that the highest strict array item cleanly normalizes to `100.0%` rather than stalling at `99.9%`. - `ts/roi.ts`: Updated the standard header tooltips to inject an explicit legend clarifying the `(Relative Volume / Absolute)` structure and explaining the market cash flow weighting parameters to prevent initial user confusion.
  • Просмотр сравнение для этих 37 коммитов »

1 месяц назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • 4a8ff504cb 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.

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • a699f4f037 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.

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • 3d6caf9bca 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.

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • f6f142c571 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.

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • 8b461024d6 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.

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • a8358675af Add_Numerical_Percentiles_and_Logistics_Normalization Implemented universal percentile tracking and strictly normalized the logistics sorting algorithms. PURPOSE: To provide immediate comparative context to absolute financial metrics. By tagging every cell with a percentile `(0.00 - 1.00)` relative to the currently active UI view, users can instantly identify top-tier and bottom-tier recipes without manually scanning the entire array. Furthermore, the previous logistics sorting logic evaluated "raw amount" (e.g., 2000t vs 900m³), which failed to account for asymmetrical ship capacity limits. Normalizing this metric ensures that 1000m³ is correctly evaluated as mathematically identical to 3000t (1 full ship) for both array sorting and percentile generation. IMPLEMENTATION DETAILS: - `roi.py`: Extracted `normalized_logistics_per_base` directly into the `Profit` dataclass. - `ts/roi.ts`: Migrated the `logistics` array sort target away from the raw output variable to target the newly exposed `normalized_logistics_per_base`. Implemented a `localStorage` migration catch to ensure users with cached states do not crash. - `ts/roi.ts`: Built a `getPercentile()` helper function that calculates simple numerical rank relative to array length. - `ts/roi.ts`: Extracted 6 distinct sorted arrays immediately following the `.filter()` and `.map()` iterations. This guarantees that recipes hidden by UI toggles (like "low volume") are entirely excluded from the percentile population base, ensuring mathematical accuracy. - `ts/roi.ts`: Modified the HTML `<tr>` string generator to interpolate the calculated percentiles wrapped in a `<span style="opacity: 0.6;">` tag. This creates a visual hierarchy, ensuring the 3-sig-fig absolute metrics remain prominent while the percentile acts as supplemental metadata.

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • e6b204bfb7 Add_HQ_Permit_Capital_Requirements Executed an open-source pull from PRUNplanner to dynamically model endgame HQ permit capital costs. PURPOSE: To integrate the massive material requirements for late-game expansion permits directly into the ROI break-even mathematics. Because permit requirements are a static mechanic with no official public API endpoint, the raw hardcoded JSON dictionary was intercepted directly from the PRUNplanner GitHub CDN. Injecting these requirements organically into the CapEx calculation ensures that players planning their 3rd, 4th, or 5th planetary base accurately model the upfront financial barrier required to unlock it. IMPLEMENTATION DETAILS: - `roi.py`: Added a `cache.get()` call targeting `https://raw.githubusercontent.com/prunplanner/prunplanner/main/frontend/src/features/hq_upgrade_calculator/hq_levels.json`. - `roi.py`: Pre-calculated the VWAP, Bid, and Ask values for every HQ upgrade tier using the existing `get_metrics()` function. Appended this dictionary (`hq_costs`) to the `Profit` dataclass. - `ts/roi.ts`: Added `<input type="number" id="target-permit">` to the DOM header block, bound to the `targetPermit` state variable (defaulting to 2, the free starting limit). - `ts/roi.ts`: If `targetPermit >= 3`, the `.map()` derivation block translates the permit number to the corresponding PRUNplanner JSON key (`targetPermit - 1`), retrieves the cost based on the active `capexMetric` dropdown, and adds it to `capex_val`. - `ts/roi.ts`: Appended a dedicated `HQ Upgrade (Permit X)` line item inside the CapEx cell tooltip specifically when the upgrade cost triggers, maintaining absolute financial transparency.

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • a148c65f5d Add_Dynamic_OpEx_CapEx_Integration_and_3SigFig_Format Merged working capital into CapEx conditionally and universally applied 3-significant-figure formatting. PURPOSE: To increase the accuracy and legibility of the ROI dashboard. Structurally moving working capital (days of OpEx) into the CapEx bucket allows the user to see the true upfront cost required to initiate a production line, while adding a persistent DOM numerical input empowers them to dynamically model aggressive vs. conservative supply chains. Additionally, universally enforcing a 3-significant-figure standard via `Intl.NumberFormat('compact')` drastically reduces visual clutter across the entire table, and explicitly tagging the Logistics column with a bottleneck suffix prevents ambiguity regarding freighter constraints. IMPLEMENTATION DETAILS: - `roi.py`: Refactored the internal `max()` constraint check for logistics to store and pass forward a `logistics_bottleneck` string (e.g., `t (I)` or `m³ (O)`). - `ts/roi.ts`: Defined `formatSigFig` using `Intl.NumberFormat({ notation: 'compact', maximumSignificantDigits: 3 })`. Stripped out all previous formatters (`formatWhole`, `formatDecimal`) and applied `formatSigFig` to all cell rendering and tooltip building loops. - `ts/roi.ts`: Added `<input type="number" id="working-capital">` to the DOM header block. Registered event listeners and `localStorage` syncing for dynamic state preservation. - `ts/roi.ts`: Abstracted the `break_even` working capital addition logic and moved it directly into the `capex_val` derivation mapping. `break_even` now calculates universally as `capex_val / profit_per_base`. - `ts/roi.ts`: Overhauled tooltips for CapEx, Break Even, and Logistics to explicitly break down and clarify the new mathematical inclusions and suffix meanings.

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • 81259ae3d5 Add_Fleet_Logistics_Capital_Expenditure Integrated fractional ship procurement costs into base CapEx modeling. PURPOSE: To provide a brutally realistic timeline for return on investment (ROI). Previously, scaling up to a 500-area base modeled the raw construction costs of the factories and habitats, but entirely ignored the capital required to transport the massive influx of inputs and outputs. By calculating the exact shipping capacity bottleneck per day and translating that into the cost of 800k-credit freighters, users can now toggle "Include Ship CapEx" to see their true operational break-even time. IMPLEMENTATION DETAILS: - `roi.py`: Refactored `logistics_per_base` calculations to extract `in_w`, `in_v`, `out_w`, and `out_v` into explicit variables. - `roi.py`: Calculated `ships_needed_per_base` by finding the maximum bottleneck across the round trip using standard freighter limits (3000 weight OR 1000 volume) and scaling by `runs_per_base`. Multiplied the output by 800,000 to derive `ship_capex_per_base`. - `ts/roi.ts`: Injected a new `<input type="checkbox" id="include-ships">` into the DOM alongside the price metric dropdowns, binding it to a persistent `localStorage` state variable. - `ts/roi.ts`: Inside the dynamic mapping loop, conditionally added `p.ship_capex_per_base` to `capex_val` when the toggle is active. Because this execution occurs *before* `break_even` is computed, the new cost cascades perfectly into the ROI math. - `ts/roi.ts`: Overrode the CapEx cell's empty tooltip to explicitly print a breakdown of `Base Construction` vs `Ship CapEx`, demonstrating exactly how many fractional ships were mathematically requested for the user's specific recipe pipeline.

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • c998b72076 Scale_CapEx_and_OpEx_To_Planetary_Base Fully unified all table metrics to a 500-area "Planetary Base" standard. PURPOSE: To resolve scaling inconsistencies across the dashboard. Previously, Profit, Logistics, and Market Capacity were scaled to represent a 500-area planetary base, while CapEx and OpEx remained scaled to individual, 1-area footprint units. This mismatch forced users to perform mental gymnastics to relate construction costs to profit yields. By dynamically scaling CapEx and OpEx up via the `(area / 500)` multiplier, the dashboard now natively provides holistic, end-to-end strategic metrics for mass-scale industrial planning. IMPLEMENTATION DETAILS: - `roi.py`: Updated the fallback `__lt__` algorithm to calculate `c_a` (CapEx scaled) and `o_a` (OpEx scaled) before evaluating the negative-profit sorting logic. - `ts/roi.ts`: Implemented `const bases = p.area / 500;` within the data mapping iteration. Substituted the raw `capex[capexMetric]` evaluation with `capex[capexMetric] / bases`, achieving uniform mathematical scaling. - `ts/roi.ts`: Increased UI color mapping thresholds proportionally (`~10x`). Example: `capex_val` threshold increased from `[300k, 40k]` to `[3mil, 400k]` to ensure standard buildings utilizing ~50 area per unit continue to render informative visual gradients. - `ts/roi.ts`: Renamed table headers to `CapEx/Base` and `OpEx/Base` and added dedicated `dataset.tooltip` explanations. - `ts/roi.ts`: Abstracted `p.runs_per_day` to a new `runs_per_base` variable inside the hover tooltip string-builder. This forces the input/output quantity breakdown to physically display the total resources processed by the *entire base* per day, validating the final scaled `profit_per_base` number directly in the UI.

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

  • 3ca0e52e0a Scale_Metrics_To_Planetary_Base Updated ROI calculations and UI to display metrics scaled to a full 500-area planetary base rather than a single area. PURPOSE: To better align the dashboard with actual gameplay mechanics. Players plan production across full bases (500 area limit) rather than individual 1-area plots. Displaying 'Profit per Base', 'Logistics per Base', and 'Market Capacity (Bases)' gives users immediately actionable data at the strategic level. IMPLEMENTATION DETAILS: - `roi.py`: Modified `market_capacity_base` and `logistics_per_base` calculations to divide by `(area / 500)` rather than just `area`. Updated the `Profit` dataclass keys. - `ts/roi.ts`: Updated the dynamic mapping calculation for `profit_per_base` using the `(area / 500)` divisor. - `ts/roi.ts`: Adjusted the UI color mapping thresholds proportionally (500x). For example, the profit color scale was increased from `[0, 300]` to `[0, 150000]`. - `ts/roi.ts`: Renamed table headers to "Profit/Base", "Logistics/Base", and "Market Cap (Bases)" and rewrote all associated hover tooltips to explicitly explain the 500-area scaling math.

2 месяцев назад

knottly запушил(а) updatesjun2 в raylu/pruncalc

2 месяцев назад