AlifePlus SISKI Synergy (APS): Technical Analysis

Overview

"AlifePlus SISKI Synergy" (APS) v2.7.0 appeared on ModDB on April 4, 2026. 28 scripts, 6,112 lines of Lua. It depends on xlibs, AlifePlus, and SISKI 0.9.5 (which is under a DMCA takedown). Uploaded by forTheMonolith. The code is AI-generated, uses AlifePlus's internal architecture as its blueprint, and hard-depends on SISKI — a mod whose core infrastructure (event bus, AP bridge, callback factory) was stolen from AlifePlus and xlibs.

After this report was published, forTheMonolith publicly stated he would take the mod down within 24 hours. Instead, he created a new ModDB page and re-uploaded APS as v2.8.4 with cosmetic changes: a CREDITS.md, a LICENSE file (copied from AlifePlus's PolyForm Perimeter license), and some API cleanup. The architecture copying, internal API usage, and SISKI dependency remain unchanged. With each new AP release, APS updates to match — tracking AP's internal changes as they happen.

v2.8.4: Promise and Re-upload

After this report was shared (including on the GAMMA Discord, ~700k members), forTheMonolith posted the following on the original APS ModDB page:

"Look, I'll be straight with you. There's a technical report out about this mod that's making it more trouble than it's worth. I'm not going to sit here and argue point by point or get into a back and forth with anyone. I made this in my own time, for free, because I love this game and I wanted other people to have a good time in the Zone. That's the entire story. There was no agenda, no money involved, no intention to upset anyone or take credit for anyone else's work. Just a guy wanting to share something with the community. I'm taking the mod down in 24 hours."

Instead of taking the mod down, forTheMonolith created a new ModDB page and re-uploaded APS as v2.8.4 with the following changes:

What did not change:

• Architecture copying: same consequence template (observe -> rules -> eval -> action -> PDA -> result_squads)
• Internal API usage: still calls ~15 undocumented AP-internal functions
• AP terminology: still uses "radiant", "reactive", "cause predicate", "personality-driven" in code and comments
• SISKI dependency: still requires SISKI 0.9.5+ (which contains stolen xbus/bridge/factory code)
• Personality values: faction bias table still tracks AP's PERSONALITY values within 0.1

The "concept inspirations" section in CREDITS.md states: "The implementations in APS are not ports or reimplementations of these mods' code, but the ideas came from them." This is contradicted by the evidence in sections 4, 5, and 6 below, which show that APS reproduces AlifePlus's internal architecture, not just its ideas.

The Mod

Authorship Indicators

The mod's code exhibits numerous characteristics consistent with AI-generated output. The evidence falls into several categories.

Author's own statement

"The more logs file I can get what the more behaviour I can learn and train into the mod."

This describes an iterative process: code generation tool produces output, users test and report crashes, crash logs are fed back to generate fixes. The first real user to install the mod got a fatal engine crash (below), confirming zero pre-upload testing.

Mechanical uniformity

Every file follows the exact same template, without any of the natural variation that appears in hand-written code:

Defensive coding and pcall misuse

67 pcall wraps in 6,112 lines. Wrapping calls in pcall hides the problem instead of fixing it. Two categories:

The generator doesn't know the X-Ray runtime boundary: pcall cannot catch C++/luabind faults because the engine terminates the process before Lua sees the error. And for hallucinated items, pcall just hides the fact that the feature doesn't work. For comparison, SISKI has 488 pcalls at 1/59 lines.

Other indicators: 74 tostring() wraps including one on an X-Ray vector that caused the fatal crash, 125 nil-guards on values guaranteed by the code's own logic, 170 log statements (1 per 36 lines vs AlifePlus's 1 per 120), and two empty for loops that iterate over results but execute no code (vestigial from an earlier generation pass).

RPG template systems

Several gameplay systems follow textbook AI RPG design patterns with no STALKER-specific grounding:

• 4-trait personality system (aggression, greed, caution, loyalty) with faction bias tables and random variation -- a standard AI fantasy RPG pattern
• 3-tier boss system (Lieutenant/Captain/Warlord) with nickname pools ("Razor", "Butcher", "Ghost", "Shadow"), gear injection, rank boost -- classic AI game design template
• Wealth scoring formula (outfit_tier * weight + artefact_count * weight + money / divisor) -- textbook numeric scoring that looks reasonable but has never been tested against actual game balance
• Passive tension generation between 30 hardcoded faction pairs -- the AI generated a complete faction conflict matrix without understanding which factions actually interact in-game

Fabricated version number

"v2.7.0" implies a long development history with 2 major versions and 7 minor releases, but no git repository exists and no prior versions appear on ModDB. The first user to install the mod got a fatal crash on basic gameplay, which means no version with this code could have been tested or iterated on.

ModDB readme

The ModDB description is approximately 5,500 words in English + 2,000 words in Russian. The section structure mirrors AlifePlus's own ModDB description: "How it works step by step:", numbered bullets, "What makes it realistic:", "PDA notifications:", "What you experience:". The AlifePlus readme was provided to the code generation tool alongside the source, and the AI reproduced the same organizational template for a different mod. Both language versions are semantically identical -- consistent with generation from a single source followed by machine translation.

Framework Pattern Matching

AlifePlus has internal conventions for how causes and consequences are structured. These are documented in architecture.md and conventions.md -- development documents, not a public API specification. APS follows these conventions exactly:

4a. Naming conventions -- every layer matches

In plain English: AlifePlus has a naming system for its files, events, and settings — not published anywhere as a standard. APS uses the exact same scheme, just swapping in different words. The structure, separators, prefixes, and suffixes are character-for-character identical.

Every row follows the same template with only the bold word substituted. This pattern is documented in AlifePlus's internal conventions.md -- a development document, not a public specification.

4b. Handler structure -- the skeleton is identical

In plain English: Every AlifePlus consequence handler follows the same structure: extract the trace, wrap in observe(), check gates in a fixed order, find targets, move squads, send PDA, return a result code. APS handlers follow the exact same structure in the exact same order. Below is real code from both — the only difference is the consequence name.

local function _handler(event_data)
    local trace = event_data._trace
    return ap_debug.observe(trace,
      CONSEQUENCE.STASH_AMBUSH, function()

        -- GATE 1: MCM enabled?
        if not cfg.consequence_stash_ambush_enabled
          then return { code = RESULT.DISABLED_NEXT }
        end

        -- GATE 2: chance roll
        if not xmath.chance(cfg
          .consequence_stash_ambush_chance)
          then return { code = RESULT.CHANCE_NEXT }
        end

        -- GATE 3: data validation
        if not position then
          return { code = RESULT.RULES_NEXT }
        end

        -- FIND: squads near position
        local ambushers =
          ap_utils.find_squads_observed(trace,
            position, opts)

        -- MOVE: script squads to smart
        ap_debug.observe(trace,
          ACTION.MOVE_SQUAD, function()
            for _, sq in ipairs(ambushers) do
              ap_alife_tracker.script_squad(
                sq, smart, { rush = cfg
                  .consequence_stash_ambush_rush })
        end end)

        -- PDA: send message
        ap_debug.observe(trace,
          ACTION.SEND_PDA, function()
            ap_utils.send_pda(cfg
              .consequence_stash_ambush_pda_chance,
              "text_pda_consequence_stash_ambush",
              { location = location })
        end)

        -- RESULT
        return ap_debug.result_squads(moved, {
            code = RESULT.OK_STOP,
            dst_id = smart.id,
        })
    end)
end

local function _handler(event_data)
    local trace = event_data._trace
    return ap_debug.observe(trace,
      CONSEQUENCE.WEALTHY_AMBUSH, function()

        -- GATE 1: MCM enabled?
        if not cfg.consequence_wealthy_ambush_enabled
          then return { code = RESULT.DISABLED_NEXT }
        end

        -- GATE 2: chance roll
        if not xmath.chance(
          aps_difficulty.adjust_chance(cfg
            .consequence_wealthy_ambush_chance,
            "ambush"))
          then return { code = RESULT.CHANCE_NEXT }
        end

        -- GATE 3: data validation
        if not position then
          return { code = RESULT.RULES_NEXT }
        end

        -- FIND: squads near position
        local ambushers =
          ap_utils.find_squads_observed(trace,
            ambush_smart.position, opts)

        -- MOVE: script squads to smart
        ap_debug.observe(trace,
          ACTION.MOVE_SQUAD, function()
            for _, ambusher in ipairs(ambushers) do
              ap_alife_tracker.script_squad(
                ambusher, ambush_smart, { rush = cfg
                  .consequence_wealthy_ambush_rush })
        end end)

        -- PDA: send message
        ap_debug.observe(trace,
          ACTION.SEND_PDA, function()
            ap_utils.send_pda(cfg
              .consequence_wealthy_ambush_pda_chance,
              "text_pda_consequence_wealthy_ambush",
              { location = location })
        end)

        -- RESULT
        return ap_debug.result_squads(moved, {
            code = RESULT.OK_NEXT,
            dst_id = ambush_smart.id,
        })
    end)
end

Line by line: same function signature, same trace extraction, same observe() wrapper, same gate order (enabled -> chance -> validation), same find_squads_observed(), same nested observe(ACTION.MOVE_SQUAD), same script_squad() call with same rush config key, same nested observe(ACTION.SEND_PDA), same send_pda() call with same key pattern, same result_squads() return. The only differences are the consequence name and the addition of aps_difficulty.adjust_chance().

4c. Cause registration -- identical loop

function on_game_start()
    local radiant = ap_const.RADIANT_CALLBACKS
    for i = 1, #radiant do
        ap_producer_reactive.register(
            CAUSE.STASH,
            { callback = radiant[i] },
            _on_smart
        )
    end
    ap_debug.info("[CAUSE.STASH] Initialized")
end

function on_game_start()
    cfg = aps_mcm.cfg
    for i = 1, #ap_const.RADIANT_CALLBACKS do
        ap_producer_reactive.register(
            CAUSE.WEALTHY,
            { callback =
              ap_const.RADIANT_CALLBACKS[i],
              priority = 80 },
            _on_radiant
        )
    end
    _aps_log.info("[CAUSE.WEALTHY] Initialized")
end

4d. Consequence registration -- identical call

ap_consumer.register(
    CONSEQUENCE.STASH_AMBUSH, {
        event = CAUSE.STASH,
        priority = 20,
        condition = function()
            return cfg
              .consequence_stash_ambush_enabled
        end,
    },
    _handler
)

ap_consumer.register(
    CONSEQUENCE.WEALTHY_AMBUSH, {
        event = CAUSE.WEALTHY,
        priority = 20,
        condition = function()
            return cfg
              .consequence_wealthy_ambush_enabled
        end,
    },
    _handler
)

The function, argument structure, field names, priority value (20), and condition pattern are all identical -- only the cause/consequence names differ.

4e. Chase configuration -- identical table keys

local chase_opts = {
  handler_key   = "revenge_chase",
  log_prefix    = "CONSEQUENCE.SQUADKILL_REVENGE",
  max_chases_key= "consequence_squadkill_revenge_max_chases",
  pda_chance_key= "consequence_squadkill_revenge_pda_chance",
  pda_start     = "text_pda_consequence_squadkill_revenge",
  pda_lost      = "text_pda_consequence_squadkill_revenge_lost",
  pda_found     = "text_pda_consequence_squadkill_revenge_found",
  rush_key      = "consequence_squadkill_revenge_rush",
}

-- on_game_start:
chase_opts.cfg = cfg
ap_utils.chase_register(chase_opts)

local chase_opts = {
  handler_key   = "wealthy_rob_chase",
  log_prefix    = "CONSEQUENCE.WEALTHY_ROB",
  max_chases_key= "consequence_wealthy_rob_max_chases",
  pda_chance_key= "consequence_wealthy_rob_pda_chance",
  pda_start     = "text_pda_consequence_wealthy_rob",
  pda_lost      = "text_pda_consequence_wealthy_rob_lost",
  pda_found     = "text_pda_consequence_wealthy_rob_found",
  rush_key      = "consequence_wealthy_rob_rush",
}

-- on_game_start:
chase_opts.cfg = cfg
ap_utils.chase_register(chase_opts)

9 identical table keys. Same registration call. Same .cfg = cfg assignment. The values follow the naming convention from AlifePlus's conventions.md.

4f. MCM config creation -- one character different

cfg, get_config, load_config =
    xmcm.create_config("ap", defaults, path_builder)

function on_game_start()
    load_config()
    RegisterScriptCallback(
      "on_option_change", load_config)
end

cfg, get_config, load_config =
    xmcm.create_config("aps", defaults, path_builder)

function on_game_start()
    load_config()
    RegisterScriptCallback(
      "on_option_change", load_config)
end

The only difference is "ap" vs "aps" -- one character. Everything else is identical: same variable names, same function call, same callback registration, same lifecycle hook.

Uniqueness Proof

AlifePlus's consequence template defines a specific execution pattern: observe(trace, CONSEQUENCE, function() ... end) wrapping, find_squads_observed() for traced entity search, nested observe(trace, ACTION.MOVE_SQUAD, function() ... end), script_squad() dispatch in a loop, result_squads() return builders, observe(trace, ACTION.SEND_PDA, function() ... end), and chase_register() for pursuit mechanics. These functions and this pattern exist only in AlifePlus.

To verify this claim, every .script file in the GAMMA mod collection (~2,000 files across all installed mods) was searched for the following function names:

Zero results. Not one of the ~2,000 GAMMA script files uses any of these patterns. They are not engine functions, not Anomaly utilities, not community conventions. They exist in exactly two places in the entire STALKER modding ecosystem:

1. AlifePlus — where they were designed and implemented
2. APS — where they were copied

The consequence template is not a standard modding pattern that forTheMonolith could have arrived at independently. It is AlifePlus's original architecture, documented in architecture.md and conventions.md — internal development documents, not a public specification. APS reproduces this architecture function-by-function, with only the consequence names changed.

Framework API Usage

In plain English: AlifePlus has two layers: a public guide that shows mod authors what functions to call, and internal development documents that describe how AlifePlus itself is built — naming rules, file organization, handler structure, config key formats. APS bypassed the public API and used the internal documents directly, reproducing the internal conventions character-for-character with only the names changed.

5a. Documented API (Level 1 and 2 — these are fine to use)

The usage guide documents these integration paths:

APS uses these calls correctly. This is not the issue.

5b. Undocumented internals (Level 3 — not part of any public API)

These functions do not appear in the guide. They can only be discovered by reading AlifePlus source code. ~8 documented API calls vs ~70+ undocumented internal calls.

Tracing system (33+ calls) — AP's internal hierarchical trace/debug pipeline:

State manager (15 calls) — AP's internal squad tracking and elite system:

Internal helpers and data (22+ calls) — chase system, search wrappers, pipeline internals:

Several modules are accessed via rawget(_G, ...) — bypassing module resolution to reach into the global table directly.

APS uses 14 of 16 xlibs modules. Every AlifePlus and xlibs function call is correct — right module, right name, right arguments, right field names. No framework call is hallucinated. This strongly suggests the complete source of both codebases was provided to the code generation tool. (Game item sections and engine APIs, which were not in the provided source, are hallucinated — see above.)

Design Language and ModDB Description

AlifePlus's readme.txt opens with: "You are not special." Its architecture.md defines it as: "YANS (You Are Not Special). Same rules for player and NPCs." This term appears only in AlifePlus documentation.

APS reproduces it in three places:

AP-original vocabulary used in APS code

AlifePlus classifies causes as "radiant" (ambient observations on squad update ticks) and "reactive" (responses to world events). These terms are defined in architecture.md and do not appear in any other STALKER mod. APS uses them as if they are standard terminology:

None of these terms exist in any other STALKER mod. They are AlifePlus's internal vocabulary, adopted wholesale by APS because forTheMonolith's AI code generator was fed AP's documentation.

The ModDB description itself follows AlifePlus's readme structure section by section:

The APS ModDB description is approximately 5,500 words in English + 2,000 words in Russian. The AlifePlus readme was provided to the code generation tool alongside the source code, and the AI reproduced the same organizational template for a different mod.

Runtime Behavior

The first user to test the mod reported a fatal engine crash:

FATAL ERROR
aps_consequence_wealthy_rob.script(182) : _run_handler
LUA error: No such operator defined

The crash occurs at line 182, where tostring(event_data.position) is called on an X-Ray engine vector userdata. X-Ray vectors do not define __tostring. This is a known engine limitation that any STALKER modder encounters early.

The crash propagates through AP's internal pipeline: ap_consumer._process -> xbus.publish -> ap_producer_reactive. Because APS injects directly into AP's dispatch chain via ap_producer_reactive.register() and ap_consumer.register(), a crash in APS code crashes AlifePlus itself for any user who has both installed.

The "v2.7.0" version number in the mod name does not correspond to any observable development history, and no git repository exists.

SISKI Dependency

APS requires SISKI 0.9.5+ and accesses its internals 32 times via _G.siski.* (bus, memory, board_index, mutants, loot, fast_trading, ap_bridge, tasks). SISKI 0.9.5 is the version that is the subject of an active DMCA takedown for containing architecture copied from AlifePlus.

The dependency chain:

AlifePlus (original) --> SISKI 0.9.5 (under DMCA) --> APS v2.7.0 (this mod)
xlibs (original)     --> SISKI 0.9.5 (under DMCA) --> APS v2.7.0 (this mod)

Feature Set Cloning

Beyond the framework and API usage documented above, APS's feature list is assembled from ideas found in existing Anomaly mods and in AlifePlus itself. Several features are direct clones of AlifePlus systems with the names changed.

9a. Boss system = Alpha system renamed

AlifePlus has an alpha/elite promotion system (ap_ext_consequence_alpha_promote, ap_ext_tracker). APS has a "boss" system (aps_bosses). They are the same design:

The APS code comment (aps_bosses.script:2-3) even uses the same language as AlifePlus's readme — "natural selection produces its own leaders" mirrors AlifePlus's "emergent behavior nobody scripted." No other STALKER mod describes NPC promotion systems with the phrase "natural selection."

9b. Personality values derived from AlifePlus

AlifePlus defines per-faction personality traits in ap_ext_const.script (7 traits, 12 factions + 17 species, sourced from GSC AI design documents). APS defines a parallel table in aps_personality.script (4 traits, 12 factions). The values are suspiciously close:

Multiple exact matches (highlighted). All values within 0.1-0.2. AlifePlus's values are derived from GSC's AI design documents (Ai.doc personality axes, cited in code). APS provides no source for its values. The simplest explanation: the AI was given AP's personality table and told to generate a "different" version.

9c. Feature set comparison

Individually, none of these similarities would be notable — many mods solve similar problems. But the pattern is that APS's entire feature list was assembled by systematically cataloguing what already exists in the Anomaly modding ecosystem and asking an AI to generate equivalents. Nearly every feature in APS traces to an existing Anomaly mod or to AlifePlus itself. The remainder are generic RPG templates — personality traits, boss tiers, nickname pools — with no STALKER-specific grounding.

License

Both AlifePlus and xlibs use the PolyForm Perimeter License 1.0.0.

v2.7.0

v2.8.4

After promising to take the mod down, forTheMonolith re-uploaded with cosmetic compliance changes:

The CREDITS.md claims: "The implementations in APS are not ports or reimplementations of these mods' code." The uniqueness proof contradicts this directly: the patterns APS uses exist nowhere in the STALKER modding ecosystem except AlifePlus.