Netcode, geodata, pathfinding, movimiento, IA de NPCs y fixes del core Java se trabajan del lado del servidor para reducir fricción y problemas clásicos de L2J manteniendo compatibilidad con cliente y System originales de Interlude.
Packet handling, respuesta de acciones y sincronización se revisan junto con geodata y pathfinding. Jugadores y NPCs siguen obedeciendo validaciones, obstáculos y rutas válidas mientras se reduce el desync y la fricción heredada de L2J.
Los problemas se corrigen donde realmente pertenecen: fórmulas, estados, scheduling e IA pueden ir al core Java, mientras XML, SQL y datapack mantienen los datos. Los cambios jugables siguen del lado del servidor y no se trasladan al cliente.
Los cambios no parten de valores arbitrarios. Se contrastan comportamiento documentado de Interlude, implementaciones L2J/Orion, código Java/XML/SQL y pruebas sobre el propio servidor. La IA se usa para localizar inconsistencias, comparar fórmulas y acelerar auditorías de código; cada cambio se revisa, compila y prueba ingame antes de considerarlo válido.
Guardias y mobs usan estados más limpios de threat, persecución, disengage, retorno y coordinación. La IA de nivel superior solo puede proponer opciones cerradas o narrar hechos verificados; Java valida y ejecuta cualquier acción, reward o decisión real.
El objetivo sigue siendo cliente Interlude y carpeta System sin modificar: sin interfaz custom, packs de DLL sustituidas ni l2.ini editado. El servidor puede evolucionar sin pedir al jugador instalar un ejecutable opaco.
Combate, bosses, movimiento, lógica de NPCs, eventos dinámicos e IA se prueban como sistemas conectados. Un arreglo no se considera terminado si resuelve un problema creando otro en otra parte.
