Progression Costs & Vehicle Status — Prices, allowances and award evidence

Personal price reductions use item-specific baselines

The vehicle discount requester starts each matching personal discount from the default shop item price. It filters enabled discount definitions by target and account-goodie membership, evaluates the matching discounts independently, and keeps the lowest defined result in the default price's selected currency. It does not apply one vehicle discount to the result of another. The defaults accessor can itself fall back to the main shop table or item-price getter when default data is absent; its resolved value is not guaranteed to be an untouched historical list price. The shared arithmetic helper truncates a percentage result to an integer and floors negative results at zero; fixed reductions use max(price - reduction, 0).

The GUI vehicle captures the personal quote during synchronized construction. Its buyPrices property compares that captured quote with the item's current primary quote, using the primary quote's selected currency. It selects the personal quote on equality or a lower amount. Only afterward does an active rental subtract its compensation. The original default price and alternate wrapper remain separate; this is not a cross-currency cheapest-price calculation or a promise that a retained item refreshes automatically.

For comparable single-currency synthetic inputs, default price 1000 with independent discounts of 10% and 30% produced a personal quote of 700. An item quote of 800 selected 700; an item quote of 600 stayed 600. Active-rental compensation of 100 then yielded 500 in the latter case. The vehicle purchase processor consumes the projected primary quote when assembling its total, with separate validation. These stages do not establish affordability or server purchase permission.

The premium-packet path uses a different baseline: getPremiumCostWithDiscount passes the current premium-cost map to the shared premium helper. A synthetic current price of 800 with a 25% reduction produced 600, without reading a default price of 1000. The catalog projection reads default packet costs separately from the discounted map. Do not generalize the vehicle default-price rule to every personal discount.

Selected original requester, filter, vehicle-property and discount-helper checks used inert single-currency money/item wrappers and supplied account-goodie records. The premium checks used supplied maps and left the input map unchanged. Separate selected accessor checks covered a supplied default and main-shop fallbacks for a missing item or table. Actual money arithmetic, synchronized construction/cache refresh, catalog rendering, coupon configuration, requests, server acceptance and the client Python 2 runtime were not exercised.

Progressive customization sale counts retain a configured allowance

The vehicle-sale helper returns the installed count for a nonprogressive customization item. For a progressive item it instead returns min(installed, installed + depot - autoGrantCount). Here depot is the customization wrapper's unbound inventory plus stock bound to the queried vehicle; it excludes installed copies and stock bound to other vehicles. autoGrantCount is descriptor configuration, not a record of newly received items. Do not estimate these proceeds by multiplying every installed copy by its sale price.

For supplied installed count 3 and configured allowance 2, depot counts 0, 1 and 2 yielded sell counts 1, 2 and 3. More depot stock did not raise the count above 3. This is a count allocation: the depot term can change how many installed copies are included, rather than adding every depot copy to this vehicle-sale option.

The sale dialog uses the helper for customization rows. The processor multiplies its result by the item sale price when computing selected customization proceeds across the vehicle group. Its request-layout builder separately includes only positive counts and deduplicates item identifiers within each vehicle. These cached quote and layout stages do not establish server acceptance, actual stock removal or credited proceeds.

Selected original count helpers ran with inert stock maps and supplied progression metadata under host Python 3.11, with original constructors and bases omitted. The checks covered the progressive allocation, installed-count ceiling, other-vehicle exclusion and nonprogressive branch. Source inspection covered synchronized construction and the dialog/processor consumers; actual inventory synchronization, full sale processing, real configuration, rendering, server behavior and the client Python 2 runtime were not exercised.

Eligibility and awarded XP are different evidence

Cached vehicle flags describe the client's projection of account state. They do not prove an XP award, authorize a research purchase or specify every progression feature's availability. Use the relevant account update or battle result for awarded values.

Game files and evidence

These links follow the public repository's default branch. Search each file for the symbols below. They establish client-side calculations and state handling; they do not verify server configuration or live behavior.

Use this in a mod

See Account & Lobby for synchronization, Vehicles & Items for item state and Battle Results and Accounting for economic records.