Changed the name of the new `trainArrivalDelaySeconds` setting to `trainArrivalDelayObservedSeconds` so it's more obvious that it doesn't actually control the train arrival time.
`trainArrivalDelayObservedSeconds` is my first choice for naming this setting, and `trainArrivalDelayThatYouDefinitelyShouldNotChangeSoDoNotEvenThinkAboutItSeconds` is my second choice.
Co-authored-by: dwesterwick <dwesterwick@yahoo.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/171
Co-authored-by: DanW <danw@noreply.dev.sp-tarkov.com>
Co-committed-by: DanW <danw@noreply.dev.sp-tarkov.com>
Made the following changes for determining if train extracts should be disabled in Scav raids:
* When determining at what time the train will leave, include the extraction time and the delay between the train extract activating and it becoming available to board
* Fixed the variable used for determining if the extract should be disabled
* Ensure `MinTime` and `MaxTime` for extracts are never negative
Also, trains are hard, and my brain hurts.
Co-authored-by: dwesterwick <dwesterwick@yahoo.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/170
Co-authored-by: DanW <danw@noreply.dev.sp-tarkov.com>
Co-committed-by: DanW <danw@noreply.dev.sp-tarkov.com>
Moved logic out of `updateProfileBaseStats()` and into separate functions for pmc/scav, left profile-agnostic code alone
new functions `updatePmcProfileDataPostRaid` and `updateScavProfileDataPostRaid`
scav - Only copy active quest progress from client profile to server scav profile
scav - dont attempt to update trader standings, none exist on scav profile
scav - dont transfer psot-raid limb damage to server profile
Update quest status values similarly to PMC quests post raid to ensure they're consistent with existing quest data in profile
Simplifies `migrateScavQuestProgressToPmcProfile`
made various warnings debug instead
When multiple falsey conditions are being checked Biome recommends to check for all the truthy conditions negated. Logic remains untouched, while only using one negation. Apparently easier to comprehend.
Event bots are generated from their base type, then their role is updated before being sent to the client e.g. peacefullZryachiyEvent becomes bossZryachiy for generation, then back to peacefullZryachiyEvent
- 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>
This commit includes a series of changes aimed at improving the logic and readability of the `payMoney` method in the PaymentService class. The method is pivotal for handling in-game payments, specifically in cases involving multiple types of currencies and barter trades. The changes resolve an issue that prevented barter payments that included both a currency and another item.
## Changes:
- Replaced `barterPrice` variable with a `currencyAmounts` mapping that efficiently tracks each type of currency involved in the trade.
- Updated how the `costOfPurchaseInCurrency` variable is calculated to factor in multiple currencies.
- Introduced a new variable `totalCurrencyAmount` to sum up the total amount of all currencies, which is checked to determine whether any (non)currency payment is necessary.
- Added some inline comments for readability.
Resolves#176
Co-authored-by: Refringe <brownelltyler@gmail.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/159
Co-authored-by: Refringe <refringe@noreply.dev.sp-tarkov.com>
Co-committed-by: Refringe <refringe@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>
This PR makes it so typescript generates inline sourcemaps when transpiling mods to javascript.
This will make it so stacktraces originating in the mod source code point to the typescript files, lines and columns.
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/155
Co-authored-by: TheSparta <thesparta@noreply.dev.sp-tarkov.com>
Co-committed-by: TheSparta <thesparta@noreply.dev.sp-tarkov.com>
Don't rely on globals event value for event check, store event bools on SeasonaleventService class construction
Remove dupe function `getSeasonalEventItemsToBlock(), rely on `getAllSeasonalEventItems()`
Initially this was going to be an update to dependencies but it seems i got a little carried away!
Anyways this PR removes 2 unused dependencies (`jshint` and `utf-8-validate`), and 2 other, `del` and `fs-extra` that were replaced by the built-in `fs/promises`.
It also renames all `tsconfig` and `Dockerfile` files, in a way that when viewed in a file tree sorted alphabetically they will be next to each other.
It also updates the typescript target to `ES2022`, and changes moduleResolution from `Node` to `Node10` (this isn't an update, they are the same thing but `Node` is now deprecated).
It also adds the `node:` discriminator to every import from built-in modules.
It also has major changes to the build script, `del` and `fs-extra` were only being used in the build script, it's now using `fs/promises` instead, cleaned up the code from some functions, adds better documentation to a few functions, and renames some gulp tasks and npm scripts to better represent what they actually do.
And finally it updates dependencies, except for `atomically` which can't be updated unless the project switches to ESM.
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/150
Co-authored-by: TheSparta <thesparta@noreply.dev.sp-tarkov.com>
Co-committed-by: TheSparta <thesparta@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>
Fixes insured items comin back full durability
Co-authored-by: CWX <CWX@noreply.dev.sp-tarkov.com>
Co-authored-by: Dev <dev@dev.sp-tarkov.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/110
Add new function in dialog helper for getting dialogs frm profile - creates empty object if none found
Set gift collection time to 48 hours if none supplied
Also allow money from sold flea offers to enter sorting table
Remove unused addItem() from InventoryController
Add optional param to inventoryHelper.addItem() to allow use of sorting table, default = off
