Change `foreach` to use `for of` instead, `for of` is faster than `foreach`
Co-authored-by: Cj <161484149+CJ-SPT@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/248
Co-authored-by: Cj <cj@noreply.dev.sp-tarkov.com>
Co-committed-by: Cj <cj@noreply.dev.sp-tarkov.com>
This resolves an issue where FiR tools were coming back as non-FiR. We now just store the whole .upd property, so any stats on the tool should carry over to after the craft is finished
Note: Will break any in-progress crafts that use tools
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/238
Co-authored-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Co-committed-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
When starting a craft, tools are now taken, and the templateId is stored in the production in the user profile
When finishing a craft, space for both the tools and crafted item is verified, then both are added to the player stash correctly flagged as non-FiR and FiR respectively
Included a bit of code cleanup/reorg in areas I was working in
A few assumptions were made:
- Tools are expected to be single items, not stacks of an item (productions.json doesn't include a count property for tools, so this seems safe)
- Tools will never be a preset or have child items
- That the `canPlaceItemsInInventory` method over a concatenation of the tools and crafted item(s) will result in the same result as calling it individually over the two collections of items individually
Will need tested once merged into 380, I did basic testing, but there's a lot of different crafts that require tools
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/234
Co-authored-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Co-committed-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
This resolves an issue where a mod with bad preset data is able to break loot generation
Can be tested by changing the "\_id" property of an item preset in globals.json, and seeing the error output to the console.
A better solution for the future may be to deprecate the "\_id" property entirely, and use just the object key, however that would have more far reaching changes compared to this simple fix
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/233
Co-authored-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Co-committed-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
There is no need to copy all achievement counters from scav to PMC, we only need to copy the achievement counters where the achievement side is "Savage"
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/232
Co-authored-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Co-committed-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Switched `transferItem` to use the `getOwnerInventoryItems` method, so that it properly handles transfer events on the scav inventory
Bit of cleanup and consistency changes made to the `transferItem` method
Testing instructions in issue: https://dev.sp-tarkov.com/SPT-AKI/Issues/issues/483
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/230
Co-authored-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Co-committed-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
This change should handle any map having its level range changed.
With base data, no changes should occur, because GZ currently lists level 0-100 as its level range. You can however change GZ's base.json to limit it to level 20 for testing
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/229
Co-authored-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Co-committed-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
