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>
Remove unneeded HttpBufferHandler
-----------
The old code processed each chunk of data as an entire request, which is not correct. It was observed split data after ~14600 bytes (on a 1 gig lan connection). I think it was worse on remote connections.
This was the cause of the "unknown compression method" and invalid json parse errors when saving the profile.
Co-authored-by: Decoy <redacted@example.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/162
Reviewed-by: Terkoiz <terkoiz@noreply.dev.sp-tarkov.com>
Co-authored-by: ree <ree@noreply.dev.sp-tarkov.com>
Co-committed-by: ree <ree@noreply.dev.sp-tarkov.com>
Only adds lower when weapon has no launcher attached
Adjust sub stock adding code to trigger when stock has a subslot that starts with `mod_stock`, this means `mod_stock_akms` and `mod_stock_000` will be included
Add a new /singleplayer/log route for logging data to the server console from the client
Supports:
- All server log levels
- `Custom` log level with text/background color
- Specifying the source of the log line (ex. Plugin name)
Example output:
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT-AKI/Server/pulls/160
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>
