Quest failure is handled by client now, no need to find and fail quests in server on quest completion
Move `getQuestsFailedByCompletingQuest()` to questHelper
Attempt to return the armor preset found in globals.json first as this has default plates, if that fails construct item outselves based on mods _requried properties
Altered `addTimeLockedQuestsToProfile()` to not fail when checked quest has no `target` property
Altered `getNewlyAccessibleQuestsWhenStartingQuest()` to check all statuses of quest, not just first
New function to purge completed condtions + remove status timers beyond what a newly started quest would have + add updated quest status object to `questsStatus` property on profile changes response object
- Implement formula based on 30 weapon repairs done on live
- Return the repair amount as `repairAmount` from `repairItemByKit`
- Add an additional `repairPoints` to `RepairDetails` to return the repair points used
- Update `repairAmount` references to `repairPoints` to keep old behavior
- Add new parameter to rewardSkillPoints that applies live-like level scaling
- Only give weapon maintenance XP when using a repair kit
This implementation comes with a "Crit Fail" and "Crit Success" mechanic to account for live sometimes randomly being -4 or +4 off from my estimated values. By default the chance of each is 10%, and they can overlap and cancel each other out
Spreadsheet of live repair data:
https://docs.google.com/spreadsheets/d/1-tR4WYelhZfKZ3ZDbxr3nd73Y60E1wQRjDWONpMVSew/edit?usp=sharing
Useful columns:
C: The amount of dura attempted to be repaired, this is used in the estimated skill calculated
G: Hand entered value of how much skill gain I actually saw on live (Multiplied by 10 for readability. So "3.2" would be "32")
J: The estimated skill gain, based on the calculation included in this merge request
K: How far off the estimated skill gain was (Negative implies we guessed high and the actual result was lower)
One thing of note:
I've modified all the existing references to `repairAmount` to be the new `repairPoints` when a repair kit is used. This is to keep the existing behaviour outside of my direct changes as much as possible.
However, this seems to be incorrect in some cases (For example, buff chance is repairPoints/maxDura, but repairPoints will go down the higher your int. I'm assuming this is meant to be repairedDura/maxDura). May want to update these references to use `repairAmount` once they've been confirmed to expect the repair amount instead of repair points used.
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/164
Co-authored-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Co-committed-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
- Ability to use @spt-aki path alias on the whole project.
- Swapped all imports from relative paths, for imports using the path alias.
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/157
Co-authored-by: TheSparta <thesparta@noreply.dev.sp-tarkov.com>
Co-committed-by: TheSparta <thesparta@noreply.dev.sp-tarkov.com>
Item crafting:
HideoutManagement skillpoints give
Intellect skillpoints given
Examining item:
Intellect given
Repairing weapon/armor
Intellect given
Cleanup of hideouthelper + reordering of functions
Flagged rewardSkillPoints() as dupe of PlayerService.incrementSkillLevel()
Flagged incrementSkillLevel() as dupe of QuestHelper.rewardsSkillPoints()
Need to decide which one wins
Added nullguards to incrementSkillLevel() + added optional multiplication by global skillprogression rate
Made it update last access timestamp
