Designing Custom Systems That Survive Pack Updates

On any actively maintained pack, whether L2JMobius, aCis, L2J or a private fork, the most expensive mistake is welding your custom features directly into core classes. The next upstream change turns every merge into archaeology. The systems we build are designed to sit beside the core, not inside it.

Isolate the feature

• Keep each system in its own package with a single entry point.
• Prefer listeners and script hooks over editing core combat or AI classes.
• Expose everything tunable through a dedicated config file with sane defaults.

Model the data deliberately

Decide early what is in-memory state and what is persisted. Persisted state needs a migration script, an index strategy and a plan for concurrent writes. In-memory state needs a clear lifecycle tied to server start, shutdown and player login/logout.

-- migrations/2025_07_02__add_faction_progress.sql
CREATE TABLE IF NOT EXISTS faction_progress (
 char_id INT UNSIGNED NOT NULL,
 faction_id TINYINT UNSIGNED NOT NULL,
 points INT UNSIGNED NOT NULL DEFAULT 0,
 updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
 ON UPDATE CURRENT_TIMESTAMP,
 PRIMARY KEY (char_id, faction_id),
 INDEX idx_faction_points (faction_id, points DESC)
);

Make it observable

Add admin commands to inspect and adjust live state, and log meaningful events. When a player reports something odd at 2 a.m., you want to answer it from the logs, not from a debugger attached to production.