Current EFT / PvE compatibility investigation for SPT 4.1.x-dev

[JohnyRiddle]

Current EFT / PvE compatibility investigation for SPT 4.1.x-dev

Hi. I spent some time investigating what is currently needed to move SPT closer to the current EFT PvE client shape. This is not a finished port and not a working current-client launch, but it produced several concrete server/data findings, repeatable probes, and a small compatibility patch that may save upstream time.

The short version:

• Current EFT is Unity 2022.3.43f2 and IL2CPP.
• The old Mono Assembly-CSharp.dll patch/module path is no longer applicable as-is.
• The local SPT server/data side can be made green for early PvE bootstrap and Factory raid-data probes.
• The current official client does not reach GameAssembly.dll in a local SPT-style launch. It stops before IL2CPP/BepInEx with The required BattlEye service is not running.
• I did not patch, bypass, spoof, or disable BattlEye. The client-side result here is a blocker diagnosis, not a bypass.

Environment Tested

Current EFT client facts:

Unity version: 2022.3.43f2
Runtime backend: IL2CPP
Present: EscapeFromTarkov.exe
Present: UnityPlayer.dll
Present: GameAssembly.dll
Present: EscapeFromTarkov_Data\il2cpp_data\Metadata\global-metadata.dat
Missing: EscapeFromTarkov_Data\Managed\Assembly-CSharp.dll

This means the existing SPT Mono-era client module/delta model cannot be reused directly against the current client layout.

Server/Data State Reached Locally

The local SPT C# server was brought to a clean state for the tested bootstrap flow:

templates/items.json:          5501 items
templates/customization.json:  848 templates
database reference check:      0 issues
server log missing item IDs:   0
server fatal routes:           0
mock client smoke:             52/52 OK
early current-PvE routes:      38/38 OK
Factory raid-data probe:       2/2 OK

Factory raid-data validation generated both static and dynamic loot for:

factory4_day
factory4_night

Important caveat: this was a local research tree. Some current EFT metadata restored into SPT tables used compatibility fallback/inference for handbook/category/price/localization coverage. It should be reviewed before being treated as authoritative live economy/localization data.

Current PvE Route Compatibility Patch

I prepared a small server-side patch against server-csharp 4.1.x-dev.

The handoff package is available here:

Google Drive: SPT current EFT/PvE handoff package

Inside the package, the patch is:

patches/server-csharp-current-pve-compat.patch

The same package also includes the changed C# files, probe scripts, compact reports, and the longer handoff notes.

Validation:

git apply --check: OK
dotnet build server-csharp.slnx --no-restore: OK

The patch adds a conservative compatibility router/callback for current PvE endpoints observed during local route probing:

/client/quest/getMainQuestsList
/client/quest/getMainQuestNotesList
/client/variable/group
/client/tape/list
/client/subtitle-track/list
/client/friends
/client/ending/list
/client/tutor-game/check

It also adds bodyless request tolerance for existing early-bootstrap endpoints:

/client/dialogue
/client/mail/dialog/list
/client/achievement/list

Files added/changed by the patch:

Libraries/SPTarkov.Server.Core/Callbacks/CurrentPveCompatibilityCallbacks.cs
Libraries/SPTarkov.Server.Core/Routers/Static/CurrentPveCompatibilityStaticRouter.cs
Libraries/SPTarkov.Server.Core/Routers/Static/DataStaticRouter.cs
Libraries/SPTarkov.Server.Core/Routers/Static/DialogStaticRouter.cs
Libraries/SPTarkov.Server.Core/Routers/Static/AchievementStaticRouter.cs

Implementation choices were intentionally conservative:

• route aliases delegate to existing SPT callbacks where possible
• empty/data-less current-PvE endpoints return empty arrays/objects or false
• no client patching or anti-cheat interaction is involved

PvE Route Extraction / Probe Result

From available official client logs, I extracted:

Unique Live backend routes: 220
PvE routes:                 134
PvP routes:                  86

The early PvE route probe against the local server currently reports:

OK:     38
Failed: 0

Representative early PvE routes observed:

/client/game/start
/client/game/version/validate
/client/languages
/client/game/config
/client/items
/client/customization
/client/customization/storage
/client/globals
/client/settings
/client/trading/api/traderSettings
/client/quest/getMainQuestsList
/client/quest/getMainQuestNotesList
/client/variable/group
/client/dialogue
/client/tape/list
/client/subtitle-track/list
/client/handbook/templates
/client/hideout/settings
/client/hideout/qte/list
/client/hideout/areas
/client/hideout/customization/offer/list
/client/hideout/production/recipes
/client/game/profile/list
/client/game/profile/select
/client/profile/status

Client Launch Blocker

The main launch blocker is not currently server data or route compatibility.

I tested multiple local launch shapes:

spt_standard
spt_with_logfile
unity_batchmode_probe
current_pve_shape

Tested against both:

clean current EFT client
BepInEx 6 IL2CPP / Doorstop test copy

Observed in all tested variants:

UnityPlayer.dll loads
GameAssembly.dll does not load
CoreCLR/BepInEx does not load
Unity output_log.txt remains empty
Fatal window: The required BattlEye service is not running.

Static observations:

BattlEye\BELauncher.ini points at EscapeFromTarkov.exe
UnityPlayer.dll contains BEService and BattlEye fatal strings
UnityPlayer.dll contains BSG guard-related symbols around BattlEyeService
EscapeFromTarkov.exe, UnityPlayer.dll, and GameAssembly.dll are signed by Battlestate Games
EscapeFromTarkov_BE.exe is signed by BattlEye

Interpretation:

• the current official executable stops before IL2CPP
• BepInEx/Doorstop never gets execution
• more ordinary Unity flags or launcher argument tweaks are unlikely to help
• a legitimate local/offline entrypoint would need to reach GameAssembly.dll before any runtime adapter can work

This was treated as a hard boundary. I did not attempt to patch UnityPlayer.dll, GameAssembly.dll, BattlEye service checks, signatures, or launcher behavior.

Offline Launcher / Runtime Adapter Contract

Because the current official client does not reach runtime, I built a local offline host/stub contract to keep server work testable.

The local launcher core:

• starts the local SPT server
• waits for /launcher/v2/ping
• creates/reuses a local launcher profile
• writes an offline launch manifest
• passes SPT-style backend/token/config arguments
• supports PvE mode, developer mode, Factory location selection, and optional loot generation

The offline stub successfully reaches:

/client/game/config
/client/game/version/validate
/client/game/mode
/client/game/start
/client/profile/status
/client/customization
/client/game/profile/list
/client/settings
/client/languages
/client/globals
/client/handbook/templates
/client/trading/api/traderSettings
/client/quest/list
/client/hideout/production/recipes
/client/hideout/areas
/client/hideout/settings
/client/items
/client/items/prices
/client/raid/configuration
/client/match/local/start

I also defined a simple runtime state contract for a future legitimate offline runtime adapter:

NotStarted
PreRuntimeBlocked
Il2cppReached
AdapterReady
MenuReady
RaidReady

Current official-client launches land at:

PreRuntimeBlocked

This is a terminal state for that run. The status file/contract does not try to convert a blocked official-client launch into an adapter-ready runtime.

Developer Mode / Command Bridge Idea

A local-only developer command bridge was prototyped as a contract for a future in-game console/overlay.

The command bridge:

• reads local launch/runtime status artifacts
• allows local/offline commands immediately
• blocks runtime-only commands until the runtime adapter reports at least AdapterReady
• does not interact with Live services or BattlEye

Example command categories:

Local/offline:
help
session.info
profile.summary
items.search
quest.list
raid.start-local

Runtime-only:
telemetry.toggle
spawn.inspect
bot.debug

This is intended as a safe architecture boundary: the server/launcher can expose development tooling now, while any in-game overlay waits for a legitimate runtime adapter.

Launcher UI Prototype

I also made a small SPT Launcher-like offline launcher prototype for the local test flow. It is not the actual game client.

Current features:

• profile card
• active server mods card
• bottom profile/level/progress strip
• settings screen
• profile selector from local server\user\profiles
• Factory day/night selector
• developer mode toggle
• backend/game path fields
• developer command field
• local bootstrap through the offline launcher core

Verified local profile paths include:

local-offline
mock-spt-moddev

Both reached /client/match/local/start for Factory in the offline stub flow.

Useful Reproduction Commands

Server/data checks:

python C:\SPT-port\local-build\check_database_refs.py
python C:\SPT-port\local-build\spt_api_mock_client.py --start-server --stop-server --include-heavy --include-raid
python C:\SPT-port\local-build\analyze_server_logs.py

Current-PvE route compatibility:

python C:\SPT-port\local-build\probe_pve_route_compat.py --start-server --stop-server --token 6a2eaab7a299bc416cbafb74

Factory raid-data validation:

python C:\SPT-port\local-build\probe_factory_raid_data.py --start-server --stop-server --token 6a2eaab7a299bc416cbafb74

Client entrypoint blocker probe:

python C:\SPT-port\local-build\probe_client_entrypoint_variants.py --start-server --stop-server --game-dir "C:\SPT-port\Escape From Tarkov\Install_EFT" --username entrypoint-clean-probe --wait 7

Overall readiness:

python C:\SPT-port\local-build\spt_port_readiness.py

Expected readiness shape:

{
  "missingFiles": [],
  "serverGreen": true,
  "clientReachesIl2cppRuntime": false,
  "nextBlocker": "client_pre_runtime_battleye_guard"
}

What Seems Useful Upstream

The parts that seem directly useful to SPT:

• current-PvE route aliases for early bootstrap
• bodyless request tolerance for early bootstrap routes
• route extraction/probe tooling
• database reference checker coverage
• current EFT item/customization diff/restore tooling
• Factory raid-data probe
• explicit diagnosis that this current official client stops before GameAssembly.dll
• runtime adapter handshake/status shape for future IL2CPP work

The parts that look like dead ends for this exact official client:

• changing only SPT launcher arguments
• installing BepInEx/Doorstop and expecting it to run before the native guard
• treating the fatal as a backend route/data failure
• trying more ordinary Unity flags

Boundary

This work is intended for local/offline PvE SPT research and mod-development support.

It does not include instructions or code to bypass, disable, patch, spoof, or otherwise defeat BattlEye. The blocker diagnosis is included so time is not wasted debugging server routes or BepInEx setup when the process never reaches IL2CPP.

Suggested Next Steps

1. Review and, if acceptable, merge/adapt the small server route compatibility patch.
2. Continue route probing against real current-PvE bootstrap logs.
3. Restore/verify remaining map loot LFS data before broad raid gameplay validation.
4. Decide where an IL2CPP-era local client/runtime adapter abstraction should live in the SPT architecture.
5. Keep the client entrypoint problem separate from server/data compatibility work, because the current blocker is pre-runtime.

[JohnyRiddle]

I wanted to help with the development in some way, and if needed, I'll try to upload all the files that were changed as a result of the tests.

[DrakiaXYZ]

SPT has no intentions of moving to Tarkov 1.0+, as per the announcement in the SPT Discord:

Hi everyone,
We wanted to give everyone a brief update on what's been going on behind the scenes and the future of SPT.

Since the launch of Escape From Tarkov's 1.0 update, we've mentioned that any future updates built on top of EFT's versions post-launch were on hold while we explored our options and saw what we had in terms of tooling and what modding capabilities still exist. It's been a little over 5 months since Escape From Tarkov left early access, and we've given a lot of thought on how to approach a theoretical 'SPT 5.0' update.

To put it directly, the team has come to the decision that we will not be pursuing a version of SPT for Escape From Tarkov's 1.0 update and beyond. The reasons are many, but a major one is that nobody on the team has enough familiarity with working on such a low level of code, nor does anyone have the desire to learn. A big hurdle is, of course, aside from the sheer amount of modules that need to be completely rewritten, is that BSG at any point can simply change encryptions on their end on a whim and render everything useless. Even after reaching feature parity with SPT 4.0, client modding would be incredibly difficult for 1.0 (so difficult, that very few people could even do so at all) that the scope of mods we would have would be limited to (mostly) strictly server mods. Such a massive undertaking for learning, writing, and potentially having it all be for nothing is far too great a risk for everyone here to take, especially when the payoff leaves the experience so much less capable than a previous version.