Notable coding Changes:
- Added `getRootItemParentID` method in `InsuranceService` to standardize the determination of the root insurance container.
- Added `IInsuranceEquipmentPkg` model for structuring insurance packages, a type used to store insurance item data before it's saved in the profile.
- Added `HashUtil` in `InsuranceController` and `InsuranceService` for generating an ID for the root insurance container in the case that the root ID cannot be found.
- Updated and normalized item map generation and usage across `InsuranceService` and `InsuranceController`.
- Updated `ItemHelper` with new methods `adoptOrphanedItems` and `generateItemsMap`, facilitating better management of item relationships and efficient item look-ups.
- Updated `InsuranceController.findItemsToDelete` and related methods to use the new `rootItemParentID` parameter to ensure that all root level items share the same parent ID.
- Updated logic in `InsuranceService` for creating insurance packages and handling orphaned items.
Uh-huh, but what would you say you do here?
- Resolves an issue that arose when `lostondeath.json` equipment configuration options were set to `false`. On death, the equipment's children items would be sent back to the player through insurance, duplicating them.
- Resolves an issue that prevented items from appearing in an insurance return even though they passed an insurance roll.
- Improved debug logging.
Remaining Oopses:
- We do not have data on items that were dropped in a raid. This means we have to pull item data from the profile at the start of the raid to return to the player in insurance. Because of this, the item positioning may differ from the position the item was in when the player died. Apart from removing all positioning, this is the best we can do.
Resolves#425
Expanded `condition` config system to separate out current and max durability
Added missing armor config settings
Rewrote weapon durability method `randomiseWeaponDurabilityValues()` to do work similar to `randomiseArmorDurabilityValues()`
Fixed various items being classified as ARMORED_EQUIPMENT and using the wrong category config values
Moved ARMORED_EQUIPMENT to bottom of config so its chosen last, fixes vests being flagged as wrong item
Resolved by having the client send the sell price instead of trying to calculate it on the server. Same route, just with an extra parameter passed in
Removed unnecessary value calculation code, and renamed method to match new behaviour
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/216
Co-authored-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Co-committed-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
[The wiki specifies](https://escapefromtarkov.fandom.com/wiki/Scavs#Scav_karma) that, between 6 and 8, Fence rep is reset to 6 before penalties are applied (i.e. killing someone at 7.5 rep leaves you at 5.9), but the current fix just subtracts a flat 1 reputation instead (i.e. a kill at 7.5 leaves you at 6.4)
this should change that.
Co-authored-by: Azrael <Azrael@noneofyourbusiness.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/215
Co-authored-by: Azrael1123 <azrael1123@noreply.dev.sp-tarkov.com>
Co-committed-by: Azrael1123 <azrael1123@noreply.dev.sp-tarkov.com>
Made several improvements to the `InsuranceController` to ensure a more reliable and logical handling of insured items and their attachments.
- Updates `parentAttachmentsMap` declaration to `let` for mutability, enabling dynamic updates during processing.
- Updates `parentAttachmentsMap` to initially include all attachments (including attachments that should not be in-raid moddable).
- Updates `processRegularItems` logic to include `parentAttachmentsMap` in its parameters and logic. Now better ensures that attachments are correctly identified and processed alongside their parent items.
- Adds `removeNonModdableAttachments` method to filter out non-moddable attachments from processing.
- Updates deletion logic to better handle cases where items, such as armour vests and their non-removable plates, are processed to prevent orphaned items post-deletion.
Resolves#401
Resolved an issue that caused insurance packages that were created/lost in the same raid with different traders to be removed all at once instead of one-by-one after they were processed. This shouldn't have been causing any notable issues as the packages were already cached/queued up for processing elsewhere in the code, but it was never the original intent to have them removed before they were processed. The fix was simply to also match the trader ID when the package removal takes place.
Possibly related to #401#425
- Implemented deep cloning of input Items to prevent mutation.
- Reordered parameters: Items (required) now precede PMC data (optional).
- Updated method calls to bring them inline with these changes.
Two changes:
Calcualte the quality of an item and its mods, not just root item
Calcualte the average price of an offer using item + mods, not just root item
- Resolves an issue in bot generation caused by a missing parameter when calling the `shouldModBeSpawned` method.
- Adds a optional chaining operator within a condition to safeguard against undefined errors.
Contributed by: barlog_m
Thank you! :D
Resolves an issue where the error message in `getItemsToListOnFleaFromInventory` did not propagate as expected due to the pass-by-value behaviour in JavaScript. The solution was to refactor the method to return an object that includes both the items and the error message.
Fixed some instances of:
- Unordered imports
- Reassigning function parameters
- Modifying values in assignment/return statements
- Array.forEach being used instead of for...of
- Simplified control logic
Better handling of item rewards that need to be split into root + child (ammo boxes)
Use `addItemsToStash()`
move `recipe.isEncoded` check to earlier in function
make use of `getItem()` inside `splitStack()` instead of direct db access
Keep completed dailies inside "activeQuests" array until dailies are refreshed
Adjust post-raid quest handling to ensure previously completed/failed quests keep their original status
Make function calculate drain rate for the whole period since last update ran, not just the interval period in config
Look up max fuel storage of item instead of assuming its expeditionary or the other fuel container
Reduce nesting by inventing an if
