SISKI ALIFE: Code Copying and License Violation Report

Summary

AlifePlus and xlibs were built from scratch starting autumn 2025. The private GitHub repository has 265 commits from December 2025 through April 2026. The source code was published so that other modders could use it, build on it, and integrate with it. Within days, the published source was fed into an AI agent and used to replicate the design in a competing mod.

SISKI ALIFE (by GitHub user qkff99) contains architecture and code copied from xlibs and AlifePlus (by Damian Sirbu) without attribution, in violation of their license. The evidence below shows what was copied and how, with side-by-side code comparisons.

Actions taken:

• DMCA Takedown Notice filed with GitHub Trust & Safety (Ticket #4214814, revised April 3) — identifies infringing files, bus references, and the foundational nature of the copied architecture. Under review.
• Abuse Report filed with GitHub Trust & Safety — documents coordinated harassment, organized campaign to "strike, shame, ban, ruin"
• Terms of Service violation report submitted to ModDB — coordinated downvote campaign confirmed by ModDB staff, warnings and access restrictions issued to qkff99

About the counter-claim: qkff99 and associates claim AlifePlus stole from SISKI. This is false. The first AlifePlus commit was December 28, 2025. SISKI's first commit was January 24, 2026 — nearly a month later. The reactive architecture was created January 5. SISKI added reactive architecture March 23. Git logs from both repositories prove this.

Verify it yourself (5 commands):

# Clone the archived SISKI repository
git clone https://github.com/qkff99/siski && cd siski

# 1. See the deleted AI plans that prescribe the AlifePlus architecture
git show b026c90:plan.md | head -20
git show b026c90:plan_stage2.md | head -40

# 2. See the event bus clone (zero prior history)
git log --all --follow -- gamedata/scripts/siski_bus.script

# 3. See the old SISKI v0.9.4.1 (no squad callbacks, no bus, no reactive architecture)
git show 74a1fbd:gamedata/scripts/siski_core.script | grep RegisterScriptCallback  # last commit before refactor

# 4. See the new SISKI (all AlifePlus patterns)
git show 6e0fb89:gamedata/scripts/siski_core.script | grep RegisterScriptCallback

What needs to happen:

1. Remove cloned code (siski_bus.script, siski_ap_bridge.script) and all reverse-engineered internals
2. Add attribution to AlifePlus/xlibs where design patterns are used, per the license terms
3. Cease coordinated negative actions (downvote campaigns, false accusations, platform manipulation)
4. If the above is not feasible: takedown of the infringing repository and ModDB page

The Author Admitted It

Discord: describes studying and replicating the architecture

When confronted by an independent community member about the code similarities, qkff99 (as "Kostya Feniks") described the process in his own words:

Community member: "they also write that you stole code"

qkff99: "I processed the Romanian's code docs through my agent with a code breakdown, then looked at his reactive model and made an identical one"
(Original Russian: "ya manifesty rumyna s razborom koda cherez svoyego agenta prognal, potom posmotrel yego reaktivnuyu model' i sdelal takuyu zhe")
"it's really more profitable than a loop with budgets"
"and by the way I knew they'd throw shit at me for this"
"I don't hide it"

Full Russian text visible above. Translation verified.

Discord: "~95% vibe coded"

"siski is vibe coded too, ~95% maybe, but shhh..."
"I'm not a coder and never was"

ModDB: admits using the AlifePlus code analysis

After evidence of code copying was presented on Discord and ModDB issued warnings for slander and harassment, qkff99 edited the SISKI mod page description to include:

"BIG thanks to Damian for big amount of reviews SISKI's codebase he posted in his Anomaly mod-posting topic, i used it to make SISKI better and faster and compatible with his ALIFE PLUS."

Timeline and License

License violations

The Proprietary License v1.0 (in effect March 18–29, when all copying occurred) stated:

Section 4(a): "You may not modify the software, create derivative works, merge the software into other software"
Section 4(c): "reverse engineer, decompile, or disassemble the software for the purpose of creating competing or substantially similar software"
Section 5: "Creating software that reproduces or substantially resembles the software's design, structure, architecture, methodology [...] is a violation of this license, regardless of whether source code was directly copied"

The PolyForm Perimeter License (current, March 29–present) continues to prohibit competing use, replication without attribution, and reverse engineering. It permits addons and extensions that depend on the software with attribution — the legitimate path that was available and rejected.

Grep across all 58 SISKI .script files, config files, README, changelog, and LICENSE for: Damian, Sirbu, AlifePlus, xlibs, xbus, xsmart. Result: zero matches. SISKI's own GPL-3.0 LICENSE (commit b83ddd0) has the copyright holder placeholder still unfilled: <name of author>.

Note on GPL-3.0: qkff99 released SISKI under GPL-3.0, but you cannot GPL code you do not own the copyright to. Derivative works of proprietary/PolyForm-licensed code cannot be relicensed under GPL without the original author's permission. The GPL license on SISKI is invalid for all code derived from xlibs and AlifePlus.

Evidence: Design-by-Design Comparison

Each subsection below shows one design pattern copied from AlifePlus/xlibs. For each pattern, three columns are shown where applicable:

• AlifePlus/xlibs — the original code (published March 18)
• SISKI deleted plan — the AI instruction that described what to copy (created March 23, deleted March 24)
• SISKI 0.9.5 — the resulting code (March 23–28)

Every pattern shown below did not exist in SISKI 0.9.4.1 (March 12).

3a. Event Bus Clone (xbus → siski_bus)

In plain English: An event bus lets different parts of a mod send and receive messages. Every modder builds theirs differently. The xbus implementation uses 5 specific functions and tracks subscribers by string name in an ordered list — an unusual design choice. SISKI's bus has the exact same 5 functions, the exact same unusual design, and appeared fully formed in a single commit with zero prior development history.

A search across thousands of mods in the STALKER modding ecosystem found that xbus is the only named-subscriber pub/sub event bus. No other mod implements a subscribe/unsubscribe/publish system with string-keyed dedup and ordered subscriber arrays.

-- 5 API functions:
subscribe(event, callback, name)
unsubscribe(event, name)
publish(event, data)
count(event)
has(event, name)

-- Data structure:
subs[#subs + 1] = {
  callback = callback,
  name = name
}

API fixed:
  subscribe/unsubscribe/publish
  for bus and
  schedule/cancel/reschedule
  for keyed timers

siski_core to become thin
  bootstrap and publisher

-- 5 API functions:
subscribe(event, name, fn)
unsubscribe(event, name)
publish(event, payload)
count(event)
has(event, name)

-- Data structure:
list[#list + 1] = {
  name = name,
  fn = fn
}

5 out of 5 API functions match:

Identical algorithm — the subscribe function in both mods performs the same 4 steps in the same order. Annotated line-by-line:

-- STEP 1: ensure array exists for this event
subscribers[event] = subscribers[event] or {}

-- STEP 2: reject if name already registered
if find_subscriber_index(event, name) then
    return false                  -- ^ same return
end

-- STEP 3: append record with .name key
local subs = subscribers[event]
subs[#subs + 1] = {
    callback = callback,
    name = name                   -- ^ same .name field
}

-- STEP 4: confirm success
return true                       -- ^ same return

-- STEP 1: ensure array exists for this event
local list = self.subscribers[event]
if not list then
    list = {}
    self.subscribers[event] = list
end
-- STEP 2: reject if name already registered
for i = 1, #list do
    if list[i].name == name then
        return false              -- ^ same return
    end
end
-- STEP 3: append record with .name key
list[#list + 1] = {
    name = name,                  -- ^ same .name field
    fn = fn
}
-- STEP 4: confirm success
return true                       -- ^ same return

Six design decisions unique to xbus, all replicated:

1. String .name field as subscriber dedup key (not callback reference, not numeric ID)
2. Array-of-records storage (not name-keyed hash map — an unusual choice that makes lookup O(n) instead of O(1))
3. subscribe / unsubscribe / publish / count / has — this exact 5-function vocabulary
4. Boolean returns from subscribe/unsubscribe (true on success, false on duplicate/missing)
5. Numeric delivered count from publish (returns integer count of calls made)
6. Nil payload defaulted to {} before dispatch

Zero development history. git log --all --follow -- gamedata/scripts/siski_bus.script shows exactly one commit: b026c90. No prior bus, pub/sub, or event system code existed in any SISKI file before this commit. The file appeared fully formed at 159 lines alongside AI plans that describe its API.

93 references across 15 files. 83 subscribe calls, 10 publish calls. The bus is the communication layer for the entire mod: siski_core publishes to it, siski_memory, siski_operator, siski_mutants, siski_base_filler, siski_trade, and every other module subscribes to it. Removing siski_bus.script would break SISKI.

3b. Callback Architecture: squad_on_update, enter/leave_smart, forwarder factory

In plain English: A callback is a function the game engine calls when something happens (a squad moves, enters a location, etc.). Old SISKI listened for 5 events, mainly "the player's screen updated" — a brute-force approach. AlifePlus listens for squad-specific events across the entire game world. After the AlifePlus source was published, SISKI switched to the same approach: same events, same roles, same factory pattern to wire them up.

SISKI 0.9.4.1 used 5 callbacks with client-side actor_on_update as its main loop. SISKI 0.9.5 uses 24 callbacks with server-side squad_on_update as the FSM tick and enter/leave_smart as semantic events — the same architecture AlifePlus uses.

Radiant causes fire on A-Life
state changes: smart transitions
and player proximity.

Callbacks: RADIANT_CALLBACKS
  (enter/leave/actor_on_smart)

Two A-Life speeds. Off-map:
  steady enter/leave_smart.
On-map: sparse transitions.
  adapter fills the gap.

Canonical decision point for
  squad FSM: squad_on_update.

squad_on_enter_smart and
  squad_on_leave_smart become
  semantic task events.

Strict callback-driven model
  without global runtime loops,
  without operator queue/drain.

RegisterScriptCallback(
  "squad_on_update",         -- NEW
  siski.core.on_squad_update)
RegisterScriptCallback(
  "squad_on_enter_smart",    -- NEW
  siski.core.on_squad_enter_smart)
RegisterScriptCallback(
  "squad_on_leave_smart",    -- NEW
  siski.core.on_squad_leave_smart)
-- actor_on_update REMOVED
-- 24 total callbacks (was 5)

Callback registration before and after:

RegisterScriptCallback("actor_on_first_update", ...)
RegisterScriptCallback("actor_on_update", ...)       -- MAIN LOOP
RegisterScriptCallback("save_state", ...)
RegisterScriptCallback("load_state", ...)
RegisterScriptCallback("squad_on_npc_death", ...)

RegisterScriptCallback("squad_on_update", ...)         -- NEW
RegisterScriptCallback("squad_on_enter_smart", ...)     -- NEW
RegisterScriptCallback("squad_on_leave_smart", ...)     -- NEW
RegisterScriptCallback("squad_on_first_update", ...)
RegisterScriptCallback("squad_on_npc_creation", ...)
-- actor_on_update REMOVED, 24 total (was 5)

Callback forwarder factory — both use a factory function that takes a callback name and returns a closure that forwards engine events to the internal bus. This pattern (factory -> closure -> bus publish) does not exist in any other STALKER Anomaly mod:

-- Factory: takes callback name
local function _create_dispatcher(callback)
    -- Returns closure that forwards to bus
    return function(...)
        dispatch(callback, ...)
    end
end

-- Usage: one closure per callback type
-- RegisterScriptCallback("squad_on_update",
--     _create_dispatcher("squad_on_update"))

-- Factory: takes callback name
local function make_callback_forwarder(name)
    -- Returns closure that forwards to bus
    return function(...)
        if runtime_enabled_now() ~= true then
            return
        end
        publish_bus_event(name, ...)
    end
end
-- Usage: one closure per callback type
-- RegisterScriptCallback("squad_on_update",
--     make_callback_forwarder("squad_on_update"))

Same pattern: outer function takes a name, returns an inner function that captures that name and publishes to the bus. SISKI adds a runtime guard; the structure is identical.

3c. Producer/Consumer Pipeline

In plain English: Most STALKER mods handle everything in one big function. AlifePlus separates the work into three layers: one that detects events, one that routes messages, and one that responds. After the AlifePlus source was published, SISKI adopted the same three-layer design.

AlifePlus uses a three-tier reactive architecture. No other STALKER Anomaly mod uses this separation. The standard approach is monolithic callback handlers or iterator loops.

1. Producer
   (ap_producer_reactive)
   registers callbacks,
   evaluates conditions,
   rate-limits, publishes

2. Bus (xbus)
   named pub/sub, decouples

3. Consumer (ap_consumer)
   subscribes, routes to
   priority-sorted handlers

engine callbacks
  -> internal event bus
  -> module subscribers
  -> local timers/TTL

siski_core remains only as
engine callback router +
bus publisher. It does not
manage tasks directly.

1. Producer (siski_core)
   registers callbacks,
   forwards via factory,
   publishes to bus

2. Bus (siski_bus)
   named pub/sub, decouples

3. Consumers (12+ modules)
   each call
   siski.bus.subscribe()

3d. Off-Level Throttling

In plain English: The game simulates hundreds of squads across ~30 maps, but the player is only on one map. AlifePlus reduces processing for squads on other maps so the player's map gets priority. SISKI 0.9.4.1 had no such optimization. After the AlifePlus source was published, SISKI added the same concept with the same level-comparison logic.

AlifePlus classifies every event as on-map or off-map and throttles the unfavored side using a Bresenham integer ratio gate. SISKI 0.9.4.1 had no concept of on-map vs off-map and no level-based throttling.

-- ap_producer_reactive :30-37
local event_level =
  xlevel.get_level_id(first_arg)
local actor_level =
  xlevel.get_actor_level_id()
local on_map =
  (event_level == actor_level)

-- Bresenham gate :39-74
-- on-map: favored (admitted)
-- off-map: throttled by ratio
-- MCM configurable

Appeared 2 days after plan
in commit cbaf038 (Mar 25),
labeled "new performance
feature"

-- siski_core :308-341
local actor_level =
  current_actor_level_name()
local squad_level =
  now_level_name_by_gvid(
    squad.m_game_vertex_id)

-- Skip counter
-- on-level: always processed
-- off-level: skip N updates
-- MCM configurable

The mechanism differs (Bresenham ratio vs skip counter), but the design is identical: compare squad level to actor level, always process on-map, throttle off-map. This pattern appeared 7 days after AlifePlus published it.

3e. Two-Phase Initialization

In plain English: STALKER mods need to start up in a specific order — some things can only happen after the game world fully loads. AlifePlus splits startup into two phases: register first, then activate once the world exists. SISKI 0.9.4.1 had no such split. After the AlifePlus source was published, SISKI adopted the same two-phase pattern.

Phase 1: on_game_start
  registers engine callbacks.
  Does NOT subscribe to bus.

Phase 2: actor_on_first_update
  Game world + actor exist.
  Producer subscribes to
  engine callbacks.
  Consumer subscribes to bus.

actor_on_first_update and
load_state no longer initiate
gameplay bootstrap wave across
all squads. Only init/hydration
for topology/index/UI layers
is allowed.

-- on_game_start():
RegisterScriptCallback(
  "actor_on_first_update",
  siski.core.on_first_update)
-- registers callbacks only

-- on_first_update():
_bootstrap_enabled_runtime()
-- subscribes and initializes

3f. AlifePlus Internals Reverse-Engineered

In plain English: AlifePlus has internal bookkeeping — which squads it controls, where they are going, when they were assigned. This data is private: no public API exposes it. SISKI's bridge file reaches directly into these private data structures by name, reads the field names character-for-character, and copies private function names that can only be discovered by reading AlifePlus source code.

siski_ap_bridge.script (486 lines, commit 6e0fb89, March 28) accesses AlifePlus internal data structures that are not part of any public API:

Reads private tracker fields:

scripted_squads[squad.id] = {
    scripted_target = name,
    target_smart_id = smart.id,
    tracked_at = xtime.game_sec(),
    on_arrive = opts.on_arrive,
    on_arrive_args = opts.on_arrive_args,
}

tostring(ap_data.scripted_target or "-")
    .. "|"
    .. tostring(tonumber(ap_data.target_smart_id) or 0)
    .. "|"
    .. tostring(ap_data.tracked_at or 0)
    .. "|"
    .. tostring(ap_data.on_arrive or "-")

Access is via rawget(_G, "ap_alife_tracker") — bypassing module encapsulation to reach internal mutable state.

Verbatim faction string copied from xsmart:

local ALL_FACTIONS_FC = "army, bandit, csky, dolg, ecolog, freedom, killer, monolith, stalker, renegade, greh, isg"

local AP_ALL_FACTIONS_FC = "army, bandit, csky, dolg, ecolog, freedom, killer, monolith, stalker, renegade, greh, isg"

12 factions, identical order, character-for-character. This order is not alphabetical and not from any LTX config file. Every other mod in Anomaly modding that lists factions uses a different order:

Squad field sequence copied from xsquad:

Individual fields like scripted_target are standard engine usage. But xsquad groups them into a specific 4-field sequence: scripted_target -> rush_to_target -> assigned_target_id -> current_action. Other Anomaly mods use different sequences (Warfare sets __lock first, uses "" instead of a name, and sets current_target_id). SISKI uses xsquad's exact 4-field sequence, inlined across 8 files:

squad.scripted_target    = name            -- 1
squad.rush_to_target     = rush == true    -- 2
squad.assigned_target_id = target_smart.id -- 3
squad.current_action     = 0              -- 4

squad.scripted_target    = nil             -- 1
squad.rush_to_target     = false           -- 2

squad.scripted_target    = nil             -- 1
squad.rush_to_target     = false           -- 2
squad.assigned_target_id = nil             -- 3


squad.current_action     = 0              -- 4

For comparison, Warfare's equivalent (sim_squad_warfare.script :935) uses a different sequence: current_action -> scripted_target -> current_target_id -> assigned_target_id, and prefixes with __lock = true. The sequence 1-2-3-4 is xsquad's. Inlined across 8 SISKI files instead of calling xsquad.release_squad().

ap_owned_squad — reverse-engineering AlifePlus's internal ownership state:

In plain English: This function probes AlifePlus's internal bridge module to check if AP currently controls a squad. It reads AP's private function names (should_yield_squad, is_ap_owned_squad) by name.

These function names are not documented anywhere — discovering them requires reading AlifePlus source code. The function is copy-pasted identically across 4 separate SISKI files:

local function ap_owned_squad(se_squad, source)
    local bridge = siski.ap_bridge
    if bridge and bridge.should_yield_squad then
        return bridge.should_yield_squad(
            se_squad, source) == true
    end
    if bridge and bridge.is_ap_owned_squad then
        return bridge.is_ap_owned_squad(
            se_squad) == true
    end
    return false
end

local function ap_owned_squad(se_squad, source)
    local bridge = siski.ap_bridge
    if bridge and bridge.should_yield_squad then
        return bridge.should_yield_squad(
            se_squad, source) == true
    end
    if bridge and bridge.is_ap_owned_squad then
        return bridge.is_ap_owned_squad(
            se_squad) == true
    end
    return false
end

Also identical in siski_service_filler.script and siski_tasks_registry.script. Four copies of the same function that reads AlifePlus's private internal state. The function names should_yield_squad and is_ap_owned_squad come from AlifePlus's internal bridge module — they are not part of any public API. Using them requires reading AlifePlus source code to discover what functions exist and what they are called.

Summary: all patterns traced to AlifePlus

Code from Other Authors

SISKI ships files from other mod authors. In some cases the code is identical; in others the typo trail proves a direct copy. In both cases, credit is absent.

xcvb's Guards Spawner — identical file, no credit

local spawn_timer = 129600  -- 86400 = 1 day for each smart/squad

local DELETE_ALL_GUARDS = false  -- if "true" it will delete all
local debugx = false  -- "M" sets update and respawn times...

local spawn_timer = 129600 -- 86400 = 1 day for each smart/squad

local DELETE_ALL_GUARDS = false -- if "true" it will delete all
local debugx = false -- "M" sets update and respawn times...

Same magic constants, same format strings, same debug key bindings, same 16-entry guard data table with identical smart terrain names, faction assignments, and spawn parameters. These files do not appear in SISKI's git history — shipped only in the ModDB download, outside version control.

SISKI 0.9.5 goes further: the download includes a folder labeled "xcvb's Guards Spawner compatibility" containing guards_spawner.script and emission_guard_patch.script. These are not compatibility patches — they are xcvb's complete files with the header comments rewritten and SISKI bus integration added. The guard data table (all 16 entries, every smart terrain name, every faction, every rank, every spawn count) is preserved verbatim from xcvb's original. No attribution to xcvb appears anywhere in the files or in the SISKI mod description.

Demonized's NPC Looting — preserved typo proves copy

local can_loot_mutants = not is_stalker
  and (self.a.analse_mode == "true"
  or self.a.enabled == "true"
  and MonsterLootCommunities[character_community(npc)])

local can_loot_mutants = not is_stalker
  and (self.a.analse_mode == "true"
  or (self.a.enabled == "true"
  and mutant_comms[character_community(npc)]))

The typo analse_mode (should be "analyse_mode") exists only in Demonized's code and SISKI's copy. Zero other matches across all STALKER Anomaly mods.

Other shipped third-party files

axr_trade_manager.script is a vanilla Anomaly base file (1,496 lines) modified with 50+ SISKI-specific hooks injected directly into the original code. SISKI ships this modified copy as part of the mod without crediting the Anomaly development team.

Shipping modified base files is common practice in Anomaly modding when no DLTX alternative exists. The issue is not the practice itself but the absence of any attribution — neither xcvb (guards) nor the Anomaly team (trade manager) are credited anywhere in SISKI's repository, README, changelog, or ModDB description.

Feature Set Cloning from Anomaly Mods

Beyond code copying, SISKI's feature list closely mirrors the combined feature sets of several established Anomaly mods. Each of those mods was built by a community author over months or years. SISKI consolidates their ideas into a single package without acknowledgment.

This is not necessarily a license violation — gameplay ideas are generally not copyrightable, and multiple mods can independently implement similar features. But the pattern is notable: SISKI's feature list closely follows what already exists in the Anomaly modding ecosystem, mod by mod.

None of the original authors — xcvb, Demonized, Vintar0, bmblbx176, or Damian Sirbu — are credited in SISKI's repository, README, changelog, code comments, or ModDB description.

AI-Generated Code Artifacts

The SISKI codebase contains patterns consistent with AI-generated code and inconsistent with code written by an experienced STALKER modder. These corroborate the author's admission ("~95% vibe coded", "I'm not a coder and never was"). This section provides supporting context; the copying claims above do not depend on AI detection.

For comparison: Vintar0's Warfare (21k lines), Demonized's Mugging Squads (1.9k lines), and xcvb's Guards Spawner (353 lines) contain near-zero instances of any of these patterns.

Retaliation and Platform Interventions

Following publication of AlifePlus, a coordinated effort was organized across Discord and ModDB to accuse the AlifePlus author of copying from SISKI.

Coordinated call to action

An administrator of the AOEngine Discord server posted:

"this man literally TAKE the whole code from S.I.S.K.I mod (under GPL license), insert it into claude AI with prompt 'make the same, just change the code' and then LICENSED that code!!"
"Strike his mod, shame him, ban him on the stalker resources, ruin his mod rating on moddb"

A member of the same server, NewGrafon, opened a pull request directly on the AlifePlus GitHub repository titled "Доработка лицензии (S.I.S.K.I.)" (License rework for S.I.S.K.I.) and promoted it in the AOEngine Discord #general-ru channel. The PR contained no code changes — its sole purpose was to publicly frame AlifePlus as derived from SISKI on the author's own repository.

ModDB slander campaign

"So siski mod is an open source code mod, this guy asked claude ai to rewrite an entire code from siski and 'vibe coded' all of it, did the ENTIRE MOD in 2 DAYS and tries to license 'his own code' and strike/ban siski mod."

The git history proves the opposite: AlifePlus development began months before SISKI existed.

Platform response

• 2026-03-21: ModDB issued qkff99 a warning: "I have issued this user a warning, if it continues please let us know and we will escalate."
• 2026-03-22: ModDB escalated: "We have escalated by restricting access, and at the final warning before a ban will be issued if it persists."
• ModDB/DBolical support confirmed coordinated downvote investigation: "We will remove and ban the false downvote accounts."
• The AlifePlus author was banned from the AOEngine Discord server despite never having posted a message there. The code copying occurred while banned. Unbanned after the copying was done.
• YouTube slander extended to unrelated STALKER videos.
• Personal attacks extended to the author's LinkedIn profile.

While associates publicly accused AlifePlus of being "AI coded slop running on stolen code," qkff99 was privately saying: "I processed the Romanian's code docs through my agent" and "siski is vibe coded too, ~95% maybe, but shhh..."