That error caused game freeze because of server exception after played scav death or after successful extraction of played scav
Co-authored-by: ElRabbito <you@example.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/149
Co-authored-by: ElRabbito <elrabbito@noreply.dev.sp-tarkov.com>
Co-committed-by: ElRabbito <elrabbito@noreply.dev.sp-tarkov.com>
Added a new range for weekly elimination, intead of having two, `1-15, 16+`, we have` 1-15, 16-40, 17+`
weekly elimination kill count requirements went way up
body part targeting is lower for low level weeklies, no change at high level
disabled specific weapon requirement for all elimination quests
level 1-15 weekly quests will target scavs more
This pull request aims to refactor the InsuranceController class to improve its code quality and maintainability. The changes include restructuring methods, adding detailed comments, and enhancing the overall logic for processing insured items.
Specific changes include:
- Updating the `findItemstoDelete()` method (and the entire class, really) to keep track of which items are tagged using a Set. This *ensures* that an item can only be attempted to be deleted once, as Sets cannot contain duplicates.
- Changing the method in which we remove insurance packages from the profile. We were iterating over them using a `for` in reverse order and then removing them with a splice and the current index. On paper this should work, but funny things were happening... Sometimes. I've created a new method that removes packages from a profile by matching against the package systemData date, time, and location. This should give us a specific insurance package (as we don't have an ID to use). In addition to this we're fetching a new instance of the profile to edit, instead of modifying packages that are being iterated over as they're being iterated over.
-----
I was unable to reproduce the issue where insurance packages were not being removed from the profile, but hopefully these simplified approaches lead to less funny business.
Co-authored-by: Refringe <brownelltyler@gmail.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/148
Co-authored-by: Refringe <refringe@noreply.dev.sp-tarkov.com>
Co-committed-by: Refringe <refringe@noreply.dev.sp-tarkov.com>
Signed-off-by: bili@育碧苏联Ubisoviet
server strings are translated. player chat message WIP
Co-authored-by: Your Name <you@example.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/131
Co-authored-by: ghost114514 <ghost114514@noreply.dev.sp-tarkov.com>
Co-committed-by: ghost114514 <ghost114514@noreply.dev.sp-tarkov.com>
The `BotEquipmentModPoolService.generatePool()` method is recursive, but it does not check if the pool it creates already contains data for sub items when it finds them and calls itself on them. This creates substantial bloat in the function that is undetectable to end users, but causes some additional delay when it is called.
I noticed this when using a server mod that allows for less restrictions on mod combinations (as it would hit the system recursion limit and error out) but the bloat still affects vanilla - it takes ~1 minute for all the recursive calls to end, whereas this fix reduces that to <10 seconds.
To fix this, I've moved a block of code into the conditional block that checks if the item we're adding (and its' sub items) are already in the pool before it calls itself.
This is my first pull request, so let me know if I've fudged up somewhere and I'll do my best to fix it.
I submitted a previous request about this, but I removed my name from the commits so I had to delete the branch.
Co-authored-by: gasmo <burr.cameron@gmail.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/120
Co-authored-by: gasmo <gasmo@noreply.dev.sp-tarkov.com>
Co-committed-by: gasmo <gasmo@noreply.dev.sp-tarkov.com>
