Jump to content

Question

Posted (edited)

Hello people,

i've tried to make a code for L2GuardInstance. I wanted add some checks to guard's target list and make them give more hate (focus) on targets that have the proper checks.

Example if a player hit a guard the guard will attack him and by that time a Karma player can move in tower without guard change target and him him.

 

So basically what i did. 

 

In L2GuardInstance.java i added some small code:

public ScheduledFuture<?> getScheduler()
{
	return _schedule;
}

public void setScheduledTask(ScheduledFuture<?> task)
{
       _schedule = task;
}

and then i made a ThreadPoolManager (check every 1250 ms) 

for (PcInstance player : guard.getKnownList().getKnownPlayers().values)
{
     if (player.getKarma > 0)
     {
        guard.setTarget(player);
        guard.dotAttack(player);
     }
{

The threadpool is activated upon @Override addKnonwObject  and stop  at @Override removeKnownObject. (Like bellow)

@Override
public boolean addKnownObject(final L2Object object)
{
      //blablabla

       getActiveChar().setScheduled(ThreadPoolManager.getInstance().scheduledAiFixedRate(new CheckForKarma(getActiveChar()), 1000, 1000);
}

So basically whenever a object enter in knownList, if task == null it will start scheduler. 

 

It didn't work at all.. Any advice or how i should do this? 

Edited by Ο Χάρος

4 answers to this question

Recommended Posts

  • 0
Posted (edited)

You should forget the whole idea, Guards already have a AI, and that AI is called every second. L2J is legendary wrong about crafting AI system, no need to spread it more. Moreover you schedule a different task EACH TIME ANYONE is entering inside his range.

 

You only have to tweak AggroList in order first entry becomes second, and the PK becomes the first. I'm lazy to check, but by default the whole system already exists... Guards aggro at sight, probably adding 1 hate. The only problem is the value is too low, so whoever hits him will turn the aggro down. Simply put max value allowed as hate value, if the Ai is correctly done it will choose the new target accordingly his aggroList during the next ATTACK intention.

 

You can also override aggrolist system for guards and add a lock system if you want guards keep aggro no matter what. The lock/release could be done if "most hated" is/isn't a PK. That will avoid things like "confusion" and other operations on aggrolist to work (even if biggest allowed value is probably extremely hard to deny even using aggro skills).

Edited by Tryskell
  • 0
Posted (edited)

You should forget the whole idea, Guards already have a AI, and that AI is called every second. L2J is legendary wrong about crafting AI system, no need to spread it more. Moreover you schedule a different task EACH TIME ANYONE is entering inside his range.

 

You only have to tweak AggroList in order first entry becomes second, and the PK becomes the first. I'm lazy to check, but by default the whole system already exists... Guards aggro at sight, probably adding 1 hate. The only problem is the value is too low, so whoever hits him will turn the aggro down. Simply put max value allowed as hate value, if the Ai is correctly done it will choose the new target accordingly his aggroList during the next ATTACK intention.

 

You can also override aggrolist system for guards and add a lock system if you want guards keep aggro no matter what. The lock/release could be done if "most hated" is/isn't a PK.

 

 

actually its supposed to be like this. guard is not changing aggro unless the target is dead since c4.

 

Thanks for respond both.

 

Tryskell i would like to ask since im not familiar with big structure code, where exactly it check the aggro in which file, current i check guardKnownList and l2guardInstance

 

I smell something like L2Attackable as im checking now. but where it has the Next intention and check the aggroList? 

Edited by Ο Χάρος
  • 0
Posted (edited)

Regular guards use AttackableAI (L2AttackableAI on other forks), castle guards use their own system. AI system works based on intentions (ATTACK, CAST, ACTIVE, etc).

 

The generic behavior is handled by AbstractAI and underlayers, but it's overidden on AttackableAI on thinkActive() / thinkAttack().

 

AggroList is stored on Attackable (L2Attackable on other forks) under _aggroList. Useful methods used by AI (at least on aCis) include getMostHated(), addDamageHate(), reduceHate(), stopHating().

 

PS : naming conventions can and will differ.

	protected void thinkAttack()
	{
		final Attackable npc = getActiveChar();
		if (npc.isCastingNow())
			return;
		
		// Pickup most hated character.
		Creature attackTarget = npc.getMostHated();
		
		// If target doesn't exist, is too far or if timeout is expired.
		if (attackTarget == null || _attackTimeout < System.currentTimeMillis() || MathUtil.calculateDistance(npc, attackTarget, true) > 2000)
		{
			// Stop hating this target after the attack timeout or if target is dead
			npc.stopHating(attackTarget);
			setIntention(CtrlIntention.ACTIVE);
			npc.setWalking();
			return;
		}
Edited by Tryskell

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Posts

    • Update M54: Global HP/MP/CP consumable handling expanded beyond combat-only usage. Offensive mage idle recovery with learned skill Battle Heal. Spellhowler/Storm Screamer prioritizes Hurricane, using Vampiric Claw mostly below 90% HP. Major structural refactor initialized: Added category/class organization such as Archer, Dagger, Tank, Mage, Healer, Support and Specialized class files. Further structural cleanup. Extracted combat memory/state and more class-policy logic from the main controller. Added global stuck/inactivity watchdog for bots blocked by terrain/geodata. Added unreachable dropped ground-item timeout/temporary blacklist. Reworked Necromancer/Soultaker PvP: Dominator level 78+ maintains learned Arcane Power toggle on. Overlord/Dominator level 44+ maintains learned Soul Guard toggle automatically. Stability/scalability update: Bot controller ticks staggered instead of all starting in the same phase: Same 350 ms update rate retained Reduces simultaneous AI workload bursts. Removed the old manual aggressive-monster EVT_AGGRESSION bridge. Phantoms now use native Lucera setActive() behavior so monsters aggro them naturally. Reduced unnecessary NPC scans and native AI event pressure. Added saved-bot equipment overrides using a separate database table:         lucera_autobots_items Existing lucera_autobots remains the main saved-bot identity/state table. Equipment rows are linked to saved bots through bot_id. Added optional convenience view to show bot name together with equipment overrides:         lucera_autobots_items_view Added editable equipment slots in columns: Weapon Shield Helmet Chest Legs Gloves Boots Necklace Left/Right Earrings Left/Right Rings Equipment override values: 0 = use normal class/level profile item -1 = force slot empty >0 = equip that Item ID Custom equipment works only for saved database bots. Default class/level equipment profiles remain unchanged. Supports custom equipment from No Grade to S Grade, regardless of the bot's current level. Added validation for invalid item IDs and incompatible equipment slots. Added handling for: Two-handed weapons vs shields Full-body armor vs separate leggings Added all-grade Soulshots and Spiritshots to bot inventory/replenishment so custom lower-grade weapons still use the correct shots. Mage profiles that already use Blessed Spiritshots keep that behavior with all relevant grades available. First save the bot normally so it exists in table:         lucera_autobots Then open:         lucera_autobots_items Find the row with the same bot_id and edit only the equipment slots you want. Example: weapon_id = 6608 shield_id = -1 helmet_id = 0 chest_id = 0 legs_id = 0 gloves_id = 0 boots_id = 0 This means: weapon_id 6608 → custom weapon shield_id -1 → no shield all 0 values → keep normal default profile equipment After editing the DB, despawn and respawn the saved bot so M54 reloads its equipment overrides. Do not edit bot_id. Use it only to identify which saved bot the equipment row belongs to.   DOWNLOAD
    • It will be multi client so it will detect the client from the files and adapt the packets and asset loading. I am aiming for C4 and H5 after IL
    • this is just to simplify your life, time, and can be done for free by yourself just watch some tutorials, in case you don't wanna waste time check it out!   https://l2getwork.art   https://l2getwork.art/showcase.html  
    • Good job! Any chance for it to be downgradeable or at least compatible with older chronicles?
    • Fermata now runs in a web browser too. Try it here: https://web.fermata.gg/    
  • Topics

×
×
  • Create New...

Important Information

This community uses essential cookies to function properly. Non-essential cookies and third-party services are used only with your consent. Read our Privacy Policy and We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue..