Resolves the issue of incorrect fuel usage by using relative percentages for both the profile bonus and hideout management bonus
Add a sanity check to make sure we never return fuel to the player (No negative fuel consumption)
Adds a type definition for the variables added to the global scope.
Personally i'd probably stick them in an object off the route and drop the G_prefix but didn't want to make any major changes with no reason.
Reviewed-on: https://dev.sp-tarkov.com/SPT/Server/pulls/398
Co-authored-by: Alex McAuliffe <alex@romanx.co.uk>
Co-committed-by: Alex McAuliffe <alex@romanx.co.uk>
(cherry picked from commit 18d39224a9c3beb284fde65da6c20d416e9b5b50)
Moved confusing `isValidItem()` check out of `isItemOnCustomFleaBlacklist()` and into main function
Removed redundant blacklist check from flea item generation as its already covered in `isValidItem()`
(cherry picked from commit f46694a169b6df2c87e8b652c643f6e8791d9bd7)
Moved code into own function
Expanded force stock check to look for any child items instead of ones for slot `mod_stock`
Expanded check to include additional slot names
This is because the base value doesn't take into account any craft bonuses the profile has
After collecting a product from a continious craft, `ProductionTime` in the profiles craft data will be refreshed, this resolves issues with adjusting the `production.json` craft times not applying to continuous crafts
Refactor to remove legacy code that bloats the `ProfileFixerService` class. Most of which is old profile porting code, some being old profile fixes. Organizes code in the class so that public members are at the top (as they should be). Finally break out some code into their own methods so they're not in the primary method for the class `checkForAndFixPmcProfileIssues`.
I have tested this with a developer profile, an EOD profile and a Standard profile. I've encountered no issues in my own testing.
Co-authored-by: Cj <161484149+CJ-SPT@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT/Server/pulls/391
Co-authored-by: Cj <cj@noreply.dev.sp-tarkov.com>
Co-committed-by: Cj <cj@noreply.dev.sp-tarkov.com>
When compiled natively to linux, logfiles are saved in main SPT folder instead of default location. It's caused by file paths being hardcoded as text.
This patch fixes logs location on linux build.
Reviewed-on: https://dev.sp-tarkov.com/SPT/Server/pulls/390
Co-authored-by: witek <falls-toluene.0q@icloud.com>
Co-committed-by: witek <falls-toluene.0q@icloud.com>
(cherry picked from commit 3edf0f2ff9d6793d7441591f15dd309fef9871f5)
**Before merging: Please test on a real Windows installation if possible!**
I tested this on Linux as well as inside a Windows VM hosted on Linux, but wasn't able to test it on a real Windows installation.
This commit fixes an issue with loading bundles from a native Linux server:
When compiling the server natively for Linux & installing some mods, everything works except for mods trying to load bundles from the server. Reason is a malformed path to the bundle:
```ts
2024-07-30 23:48:16.968 +02:00|0.14.9.1.30626|Error|Default|
EXCEPTION: System.IO.DirectoryNotFoundException: Could not find a part of the path "C:\home\USER\Games\escape-from-tarkov\drive_c\SPTarkov\user\mods\Bloody-Bullet-Wounds\bundles\assets\systems\effects\particlesystems\effects.bundle".
```
`process.cwd()` returns the linux-agnostic path of course, but for some reason it also returns `C:`.
Changing the line to `modpath.slice(0, -1).replace(/\\/g, "/");` seems to work and the bundles seem to get loaded without issues (did a quick test raid), even without passing the absolute path to the mod.
I tried to check why that is, and I think node is able to [get the cwd and resolve the relative path](4d1d88118b/src/path.cc (L101)) by itself..
Reviewed-on: https://dev.sp-tarkov.com/SPT/Server/pulls/389
Co-authored-by: MadByte <madbyte@noreply.dev.sp-tarkov.com>
Co-committed-by: MadByte <madbyte@noreply.dev.sp-tarkov.com>
(cherry picked from commit 6f010acfca8ec57105a3cd3bc959ed61be206e13)
Previously `highestValue` could be lower than `lowestValue`, resulting in an exception. These values are now generated in the same method and clamped
Add a catch to the botgen promise await so we get more useful errors if botgen fails
Co-authored-by: DrakiaXYZ <565558+TheDgtl@users.noreply.github.com>
Reviewed-on: https://dev.sp-tarkov.com/SPT/Server/pulls/388
Co-authored-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
Co-committed-by: DrakiaXYZ <drakiaxyz@noreply.dev.sp-tarkov.com>
(cherry picked from commit ee1eb7d690c5ebd3d1aa4229d3a15d1050f84b5a)
