The error people are getting about a lock file already existing is due to `checkFileSync` returning false if the lock file is "stale".
The default "stale" timeout is 10 seconds, so if a save takes longer than this, the user will end up in a state where they can no longer save.
The documentation for `proper-lockfile` recommends using the callback returned by `lockFileSync` to remove the lock file, so I've switched to using this, and the error no longer occurs with long running save operations
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/239
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 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>
#### Summary
> Should fix [Issue 523](https://dev.sp-tarkov.com/SPT-AKI/Issues/issues/523)
Tested a few different scenarios and the items were always correctly removed and returned to the player, however I did see the console warnings reported in the issue.
Both of the following call `this.ragfairOfferHandler.removeOffer(...)`:
- `this.returnPlayerOffer(...)`
- `this.removeOfferById(...)`
The latter logs a warning to the console because the offer is already removed when we reach that point.
This fix simply returns after the offer has been returned to the player, letting `returnPlayerOffer` deal with removing from the flea
Co-authored-by: phrisk <phrisk@phrisk.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/237
Co-authored-by: phrisk <phrisk@noreply.dev.sp-tarkov.com>
Co-committed-by: phrisk <phrisk@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>
