The server expects that the total "Progress" when a bitcoin is complete to be the "ProductionTime" value (145000 by default). However the server was using a modified target value, while only adding the actual time change to the Progress.
This results in a drift over time between the client/server while the server is stopped, as the client gets an incorrect value on startup.
If we instead scale the addition to Progress based on the adjusted craft time, and target the base productionTime for completion, we can get a much more accurate progress while offline that matches the client
I used the profile from this ticket for testing: https://dev.sp-tarkov.com/SPT-AKI/Issues/issues/496
The user has both an upgrade and bitcoin going at the same time, so they should progress at the same rate. This is what the code was previously resulting in:
While the server was shut down for 50 minutes (As noted by the upgrade), only 36 minutes was deducted from the bitcoin craft.
This is the result of that same profile after these changes were made:
You can see that ~2 hours 25 minutes was deducted from both the upgrade, as well as the bitcoin craft timer. There is still a slight discrepancy, but in a total bitcoin run it should be minimal
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/225
Co-authored-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Co-committed-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Updated `getItemQualityModifierForOfferItems()` to return root items quality modifer when its a weapon
Fixed `getItemQualityModifierForOfferItems()` assuming quality started at 1
Bundle up profile save time and display in one line + do not log to file
Don't log when each profile is saved
Do not log to file how much fuel is left in generator
Only check if progress was only `great than` craft time, not `great than or equal to`
Didn't take into account developer accounts have reduce craft timers
Added small optimisations to skip full rows when looking for a free slot to put item in
Added small optimisation to skip looking for a free slot when entire container is full
Fixed error messages not properly being passed back up chain
Removed unused legacy function `placeItemInInventoryLegacy()`
Dont return stash layout as result in `fillContainerMapWithItem()`
Added small optimisation to `fillContainerMapWithItem()`, check if all slots of failled before trying to fit item
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
[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>
- 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
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
