Share [Lucera Autobots] - An Advanced Phantom AI Engine

UPDATE M84:
  • Changed Party Logic to optional:
    • Allow Party: No / Yes to Autobot creation.
    • Default is No.
    • Added persisted database field:
      • allow_party
      • 0 = No
      • 1 = Yes
    • Existing saved bots default to party-disabled.
    • Yes preserves existing real-player Party Logic behavior.
  • Olympiad bots remain party-disabled.
  • Added autobots_path.xml.
    • Added per-saved-bot custom death-return routes.
    • Added configurable <start> XYZ.
    • Added ordered custom <point> waypoints.
    • Added native Scroll of Escape fallback for failed custom routes.
    • Added maximum 256 waypoints per bot.
    • Prevented repeated formatting growth after subsequent saves.
    • Improved startup synchronization so saved-bot XML entries are handled in a single document operation instead of repeatedly rewriting the XML.
    • Fixed saved bots ignoring populated custom paths.
    • Route is now resolved from AutobotPathRepository using the bot's saved database ID when recovery begins.
    • Route definition is frozen for the current recovery cycle.
    • Replaced overly strict initial GeoEngine waypoint rejection with actual movement-progress detection.
    • Bot now attempts to physically travel toward each configured waypoint.
    • Bad waypoint detection uses a maximum 5-second no-progress window and prints a warning on the gameserver console.
    • Combat temporarily pauses route movement without restarting the route.
    • After combat, the bot continues from the same waypoint with a fresh stuck timer.
You can download the extension and view all the details regarding the latest Autobots in the original post of this thread.
 
Last edited:
Project-X said:
This system has been around for a long time in certain circles and on certain servers)
Why would Dizer waste time on something he doesn't need?
You can't even imagine how global and large the code is; the author, using AI, implemented a superficial piece of code that's only 1-2% of the full volume.
Click to expand...
It’s not a waste of time or anything like that; it’s about giving the project an update. It’s a contribution from someone—regardless of whether AI was used or not—that Lucera doesn't currently offer. If Lucera *did* offer it, then fair enough—criticize away. But right now, Lucera’s fake system or bot is abysmal. It makes no sense.

That’s why the Lucera team could take user feedback like this and use it as a basis for implementation. I can guarantee that 50% of Lucera users want a functional bot—ideally one released by the developer themselves—rather than relying on experimental tests with external tools that might not work reliably.

So, my point is: instead of being negative, they should use this as an example and update the default bot system. All the best.
 
Sami said:
It’s not a waste of time or anything like that; it’s about giving the project an update. It’s a contribution from someone—regardless of whether AI was used or not—that Lucera doesn't currently offer. If Lucera *did* offer it, then fair enough—criticize away. But right now, Lucera’s fake system or bot is abysmal. It makes no sense.

That’s why the Lucera team could take user feedback like this and use it as a basis for implementation. I can guarantee that 50% of Lucera users want a functional bot—ideally one released by the developer themselves—rather than relying on experimental tests with external tools that might not work reliably.

So, my point is: instead of being negative, they should use this as an example and update the default bot system. All the best.
Click to expand...
В
Sami said:
It’s not a waste of time or anything like that; it’s about giving the project an update. It’s a contribution from someone—regardless of whether AI was used or not—that Lucera doesn't currently offer. If Lucera *did* offer it, then fair enough—criticize away. But right now, Lucera’s fake system or bot is abysmal. It makes no sense.

That’s why the Lucera team could take user feedback like this and use it as a basis for implementation. I can guarantee that 50% of Lucera users want a functional bot—ideally one released by the developer themselves—rather than relying on experimental tests with external tools that might not work reliably.

So, my point is: instead of being negative, they should use this as an example and update the default bot system. All the best.
Click to expand...
Это не выгодно и не интересно разработчику ( Дизер давно придерживается нейтральной политики в этом плане)
Пользователям дали все инструменты для создания стороннего контента на свой вкус любые дополнения можете запилить самостоятельно нету ограничений( все упирается в ваши знания или $ возможности )
На рынке много вариантов ботов / Но не один здравый предприниматель не продаст курицу которая несёт золотые яйца за пару сотен $
 
Hellcat said:

Lucera2 Autobots Extension — M84

Persistent AI-controlled players for Lucera2 Interlude​


Overview
The Autobots Extension adds persistent and configurable AI-controlled players to Lucera2. The built is on top of Lucera’s existing Phantom infrastructure.
Autobots are created and managed through an in-game admin panel and can be permanently saved in the database as an option.
Once the bot/bots are saved, they can automatically respawn after a server restart while preserving their configured:
  • Class and level
  • Equipment
  • Combat behavior
  • PvP mode
  • Farming location
  • Party Logic
  • Clan Logic
  • Olympiad behavior
  • Recovery settings
The extension is designed to work through Lucera-native systems wherever possible.
It does not modify or replace:



Main Features
Autobots can be configured from low level 1 up to level 80 third-class characters.
Available configuration includes:
  • Name
  • Level
  • Class
  • Sex
  • Title
  • Recommendations
  • Clan - The clan can be added as clanID through lucera_autobots DB table, the clan has to be owned by a real player.
  • Farming radius
  • Respawn delay
  • Weapon enchant
  • Armor enchant
  • Jewelry enchant
  • Custom equipment
  • Hero status
  • Visual weapon augmentation
  • Buff profile
  • PvP mode
  • Party permission
  • Olympiad mode
  • Auto-spawn
  • AI enable / disable
Saved Autobots keep their configuration after server restart.


PvP Modes
Each bot can use one of the available PvP modes:
  • Idle
  • Attack Flagged
  • Attack Everyone
These modes are also respected by the existing combat and Party Logic where applicable.


Party Logic
Each Autobot can individually control whether Party Logic is available.
Creation option:


Default:

If enabled, the bot can accept party invitations from real players and use the Party Logic system.
Party Logic includes:
  • Following the real player party leader
  • Randomized 70–100 range positioning
  • Assisting the appropriate damage dealer
  • Dedicated support/healer behavior
  • Temporary main assister selection if the leader dies
  • Temporary assister selection when the real leader is a support class
  • Existing PvP mode integration
  • Idle farming near the leader
  • Resurrection waiting
  • Party cleanup
  • Return-to-farm handling
If:

the bot refuses party invitations from real players.
Olympiad Autobots are always party-disabled.

Olympiad Autobots
The extension includes a dedicated Olympiad subsystem.
Currently supported Olympiad classes:
  • Sagittarius
  • Moonlight Sentinel
  • Ghost Sentinel
  • Adventurer
  • Wind Rider
  • Ghost Hunter
  • Archmage
  • Soultaker
  • Mystic Muse
  • Storm Screamer
Olympiad Autobots use Lucera's native Olympiad system.
They do not replace or bypass the native competition lifecycle.
Registration uses:
Code: 
CompetitionType.CLASS_FREE
and respects native Olympiad handling such as:
  • Registration
  • Competition state
  • Stadium teleport
  • Match start
  • Match end
  • Native scoring
  • Match limits
  • Olympiad points
  • Equipment restrictions
  • Skill restrictions
Olympiad combat reuses the existing global Autobots combat engine rather than maintaining a separate combat implementation.


Equipment System
Equipment overrides are stored separately from the main saved-Autobot table.
Supported equipment slots include:
  • Weapon
  • Shield
  • Helmet
  • Chest
  • Legs
  • Gloves
  • Boots
  • Necklace
  • Left / Right Earrings
  • Left / Right Rings
Equipment entries are linked using the saved bot database ID, rather than duplicated character names.
This prevents equipment configuration from becoming inconsistent if a bot's name changes.


External Buff Profiles
Buff packages are stored externally in:

This allows server administrators and developers to modify buff packages without recompiling the extension.
Available profile categories include:
  • Fighter
  • Warrior
  • Tank
  • Archer
  • Dagger
  • Mage
  • Support
The XML file remains the authority for the configured buff packages.


Custom Death-Return Paths
Saved Autobots can optionally use manually configured routes when returning to their farming location after death.
Configuration file:
gameserver/config/autobots_path.xml
Each saved bot automatically receives an XML entry containing:
  • Database ID
  • Name
  • Class
  • Level
  • Custom route starting position
  • Ordered waypoint path
Example:
XML: 
<bot classId="94" id="91" level="76" name="BotName">

  <start x="123456" y="-12345" z="-1234"/>  <!-- Set where the bot teleports after TOWN_IDLE state here. -->

  <path>
    <!-- Add ordered waypoint coordinates here. Maximum: 256 waypoints. -->
    <point x="123456" y="-12345" z="-1234"/>
  </path>
</bot>
The <start> coordinates define where the bot will be teleported after finishing its configured town-idle recovery period.
The <path> section contains the ordered coordinates that the bot should follow for reaching it's initial configured farming location.
Maximum supported route size:

If <path> contains no valid waypoints, the custom route remains disabled and the bot uses the normal recovery system.
When a custom path is configured, the recovery flow becomes:

The custom starting point does not replace the bot's permanent saved farming location.
It is used only as the starting point of the custom recovery route.

Bad Route Protection
Custom paths include a fail-safe system.
If a bot cannot make meaningful progress toward its current waypoint for approximately:

the route is considered invalid or unreachable.
The gameserver console prints a warning similar to:

The bot then performs:

This prevents incorrectly configured XML coordinates from permanently trapping an Autobot.
The custom path is skipped only for that recovery cycle.
After a future death, the bot is allowed to try its configured custom route again.


Party Death Recovery
Party Logic includes its own death-recovery handling.
If a bot that is inside a party dies:

If the bot is resurrected, it resumes Party Logic normally.
If no resurrection occurs:

Party Logic bots therefore also support:
autobots_path.xml


Automatic Database Setup
The extension automatically creates and maintains its required database structure when it loads.
Normally, no manual SQL installation is required.

Main table:
lucera_autobots
This table stores the saved configuration for each Autobot.
When newer Autobots builds introduce additional database fields, the extension can automatically add missing columns to an existing installation.
This allows older Autobots databases to migrate to newer builds without requiring the administrator to manually modify the table structure.

Equipment Table
The extension automatically creates:
lucera_autobots_items
This table stores equipment overrides for saved Autobots.
The table uses:
bot_id
as its primary identifier and links directly to:
lucera_autobots.id
with database foreign-key protection.
Deleting a saved Autobot also removes its associated equipment row automatically.
Equipment Database View
For easier database inspection, the extension also creates:
lucera_autobots_items_view
The view combines information such as:
bot_id
bot_name

equipment columns
This makes it easier for administrators to identify which equipment configuration belongs to each saved Autobot.
If the SQL view cannot be created for any reason, the actual Autobots equipment system continues to function normally.

Important notes:



Compiling for Another Lucera Revision
The compiled extension should not simply be copied blindly between different Lucera revisions.
The correct approach is to compile the source against the target revision's current dependencies, including:

and any other Lucera libraries/extensions required by that revision.
If your Lucera revision differs from the one this build was compiled against, for example in:
  • Method names
  • Method signatures
  • Class locations
  • Visibility
  • Internal APIs
  • Phantom APIs / lifecycle
  • Olympiad internals[
The affected Autobots integration points must be adapted before recompiling.
A successful compilation against a different revision than mine does not always guarantee full runtime compatibility, so the extension should also be tested after recompiling, especially:
  • Bot spawning
  • Movement / combat
  • Party Logic
  • Recovery logic
  • Equipment
  • Olympiad


Latest Version — M84


The extension is designed to remain isolated from Lucera core files and to use Lucera-native server systems wherever possible.

On in-game, use //autobots command and create bots normally through the panel's options.

NOTE: The bots will not attack a gm character.

The extension has only been tested locally and it currently is an on-going development project. It is NOT recommended to be loaded in a live server yet and needs more testing.​


View attachment 9188View attachment 9255View attachment 9190View attachment 9191
Click to expand...
ну, если уж делать ботов так делать так что бы на большинство ревизий вставали а не только на твою текущую :D
 
NovaDes said:
ну, если уж делать ботов так делать так что бы на большинство ревизий вставали а не только на твою текущую :D
Click to expand...

I am not sure what are you trying to trigger here, your expectation is totally unrealistic for a custom extension of this scope.
This is not a small script or a cosmetic add-on. Any serious extension with this many integration points can be affected by revision changes in many many points.
There is no custom bot engine with this level of functionality that you can blindly drop into "most lucera revisions" or the unknowingly future revisions and expect zero compatibility adaptation. Even if it successfully compiles, runtime behavior can still differ between revisions.

You are basically asking me to support a defined huge range of lucera revisions with either conditional compatibility code or separate compiled builds while keeping the list updated for any future revisions.

I am sharing the extension and source completely free of charge. If your revision differs and you are not in position to make it compatible, then either pay a developer who can port it for you, or spend $1-3k++ for a similar commercial bot engine that officially supports your target revision + it will probably be ready for a live server aswell. (i have no idea how my extension would perform in a live server).

What is NOT reasonable in your comment is expecting a free custom extension with this many features to be universally compatible with every lucera revision releases out of the box.
You are receiving the full extension with the source for free, the appropriate response is to treat that as a grateful opportunity and work from it. Not complain that it was not pre-adapted to your revision.
 
Last edited:
Hellcat said:
I am not sure what are you trying to trigger here, your expectation is totally unrealistic for a custom extension of this scope.
This is not a small script or a cosmetic add-on. Any serious extension with this many integration points can be affected by revision changes in many many points.
There is no custom bot engine with this level of functionality that you can blindly drop into “most lucera revisions” or the unknowingly future revisions and expect zero compatibility adaptation. Even if it successfully compiles, runtime behavior can still differ between revisions.

You are basically asking me to support a defined huge range of lucera revisions with either conditional compatibility code or separate compiled builds while keeping the list updated for any future revisions.

I am sharing the extension and source completely free of charge. If your revision differs and you are not in position to make it compatible, then either pay a developer who can port it for you, or spend $1-3k++ for a similar commercial bot engine that officially supports your target revision + it will probably be ready for a live server aswell. (i have no idea how my extension would perform in a live server).

What is NOT reasonable in your comment is expecting a free custom extension with this many features to be universally compatible with every lucera revision releases out of the box.
You are receiving the full extension with the source for free, the appropriate response is to treat that as a grateful opportunity and work from it. Not complain that it was not pre-adapted to your revision.
Click to expand...
понял
 
i would suggest you to add different bot personalities and behaviours so they will not just react to attacks but actively decide based on their behaviour. Furthermore, in order this to be useful they need to start from level 1 like real players and progress the same way like real players select zones when collecting x amount of items or after few hours rotate to different zone and always maintain their progress and continue. There is no point to share it with others they will criticize you to demotivate you just do what you like for your own and find a way to test it with live players
 
There are several people in the community who are using your code as a basis to sell it. I think that's pretty “shitty,” but here I am, bumping this thread so that all the developers here can contribute or share a piece of code to help out.
 
fa1thDEV said:
There are several people in the community who are using your code as a basis to sell it. I think that's pretty “shitty,” but here I am, bumping this thread so that all the developers here can contribute or share a piece of code to help out.
Click to expand...
Увы и ах люди будут брать его за основу для этого автор и выложил его в общий доступ, другое дело что этот код не жизни способен для живого проекта, для локальной среды как игрушка да , для лайфа вообще нет и ещё раз нет, я смог уронить сервер спустя 7 минут активной жизни этих ботов
Код автора показывает хороший пример того, что можно было реализовать при грамотном подходе, но в нем столько рефлексией и скрытых подмен ... Без наличия исходного кода самой сборки это очень чревато 1 исправление в ядре от Дизера и половина системы рухнет после обновы
+ Модуль слишком глобальный для его поддержание и отслеживания слишком много пулов
 
fa1thDEV said:
There are several people in the community who are using your code as a basis to sell it. I think that's pretty “shitty,” but here I am, bumping this thread so that all the developers here can contribute or share a piece of code to help out.
Click to expand...
Unfortunately, selling free available code has always been a common thing in the market, and its certainly not limited to this community. I appreciate your support and your willingness to encourage other developers to contribute.

Project-X said:
Alas, people will use it as a basis for this author and made it publicly available, another thing is that this code is not suitable for a live project, for a local environment as a toy yes, for life at all no and again no, I was able to crash the server after 7 minutes of active life of these bots
The author's code shows a good example of what could have been implemented with a competent approach, but it contains so many reflections and hidden substitutions... Without the source code of the assembly itself, this is very fraught with the risk of one fix in the kernel from Dizer and half the system will crash after the update.
+ The module is too global to support and track too many pools
Click to expand...
I agree that the architecture has room for improvement, particularly regarding maintainability and unnecessary complexity. The project is still evolving, and constructive feedback from experienced developers is always appreciated. Can you provide the stack trace or identify the exact cause for the crash? I have an autobots build for the latest interlude revision which for me works without any issues (again in my local server). Unfortunately i do not have an active vps to make my own tests for autobots or i don't know anyone that would want to test it out on his live server, so i can only deal with it locally and thats it.
 
Hellcat said:
Unfortunately, selling free available code has always been a common thing in the market, and its certainly not limited to this community. I appreciate your support and your willingness to encourage other developers to contribute.


I agree that the architecture has room for improvement, particularly regarding maintainability and unnecessary complexity. The project is still evolving, and constructive feedback from experienced developers is always appreciated. Can you provide the stack trace or identify the exact cause for the crash? I have an autobots build for the latest interlude revision which for me works without any issues (again in my local server). Unfortunately i do not have an active vps to make my own tests for autobots or i don't know anyone that would want to test it out on his live server, so i can only deal with it locally and thats it.
Click to expand...
Тоже стало интересно причина утечки, но пока не было времени для детального разбора - после запуска 600+ боотов в многозадачном режиме в разных локациях сервер просто начал жестоко фризить и по итогу просто подвис
 
Project-X said:
Тоже стало интересно причина утечки, но пока не было времени для детального разбора - после запуска 600+ боотов в многозадачном режиме в разных локациях сервер просто начал жестоко фризить и по итогу просто подвис
Click to expand...
On the latest revision i am getting a random runtime issue that i’m having trouble classifying too after i recompiled autobots for the latest revision. I ran ~500 bots and the server was having a random runtime issue which caused something like a partial AI/npc/player-state stall and after some time (~1 minute) , it can recover on its own. I captured multiple JVM thread dumps while the freeze was actively happening and no issues about leakage/overloads were found. I never experienced a full crash as you are saying and my issue is only happening on the latest revision. On my old rev16144 this never happens and everything is going smooth so i am assuming it is only happening due to a bad compile/compatibility to the latest revision.

edit: nevermind, this was caused by another extension i had.
 
Last edited:
А можно инструкцию по установке а так же было бы круто если бы данный проект был переведен на Русский язык (думаю создавая такой продукт мультиязычность уже должна быть заложена).
 
MANUAL said:
А можно инструкцию по установке а так же было бы круто если бы данный проект был переведен на Русский язык (думаю создавая такой продукт мультиязычность уже должна быть заложена).
Click to expand...
там собственно говоря и не чего на русский переводить )
 
You must log in or register to reply here.
Back
Top