Behavior of mobs, agro.

We make the behavior of mobs like l2off.

Karakan is on your topic.


Add to L2AttackableAI.java --> thinkActive

For the place.

Code:

            // Set the L2Character movement type to run and send Server->Client packet ChangeMoveType to all others L2PcInstance
            if (!_actor.isRunning())
            {
              _actor.setRunning();
            }

On this.

Code:

               // Set the L2Character movement type to run and send Server->Client packet ChangeMoveType to all others L2PcInstance
             ThreadPoolManager.getInstance().scheduleGeneral(new Runnable()
             {       
            @Override
            public void run()
            {
              _actor.setRunning();
            }
          },3000);

We get a delay of 3 seconds from the aggressive monsters, first they go, and then they run.

Next, we go L2AttackableAI.java --> onEvtAttacked

For the place.

Code:

            // Set the L2Character movement type to run and send Server->Client packet ChangeMoveType to all others L2PcInstance
            if (!_actor.isRunning())
            {
              _actor.setRunning();
            }

On this.

Code:

      // Set the L2Character movement type to run and send Server->Client packet ChangeMoveType to all others L2PcInstance
      if (!_actor.isRunning() & !_selfAnalysis.isArcher)
      {      
         ThreadPoolManager.getInstance().scheduleGeneral(new Runnable()
         {       
        @Override
        public void run()
        {
          _actor.setRunning();
        }
      },3000);
      }
      else if (!_actor.isRunning() & _selfAnalysis.isArcher)
      {
         _actor.setRunning();
      }

We get that the mobs after our attack first go 3 seconds, and then start to run.

DnR, please consider this, in block 2, a revision is required in order for the mob to start running if it has less than 80-85% hp.

Jeah i've added something similar.
But i am waiting for DnR since he has way more knowledge about Java then us.

He'll come up with something good i'm sure.

Karakan wrote:Jeah i've added something similar.
But i am waiting for DnR since he has way more knowledge about Java then us.

He'll come up with something good i'm sure.

I checked my code, it works, if it is not difficult to check and you are in the sense of whether or not it was like l2off. It remains to hear the answer DNR about all this, but he is silent(

I checked my code, it works, if it is not difficult to check and you are in the sense of whether or not it was like l2off. It remains to hear the answer DNR about all this, but he is silent(

Noone said it doesnt work.

Just be patient.
People have jobs and real life.

Karakan wrote:

I checked my code, it works, if it is not difficult to check and you are in the sense of whether or not it was like l2off. It remains to hear the answer DNR about all this, but he is silent(

Noone said it doesnt work.

Just be patient.
People have jobs and real life.

I just clarified that it works and ask to check the similarity to the original l2off. And the fact that everyone has personal time and his affairs, I agree 100%.

xlinkinx wrote:
I checked my code, it works, if it is not difficult to check and you are in the sense of whether or not it was like l2off. It remains to hear the answer DNR about all this, but he is silent(

Your code is really fine and would definitely work. However, let me explain why I'm not going to use it.
The problem is task itself. Adding a threadpool executor to each monster that would run after so little time would probably be overheading, especially for a populated server.
Just think of multiple warlords inside a server trying to cast aggro to multiple groups of mobs at the same time.

Sleeping thread would be a lighter approach but it's also a bad practice since ai task gets paused for those 3 seconds.
If you think about it, we already have a running task per second which is ai task itself so we could use this to our advantage.
I'm already working on this, and thanks to you I know which code blocks I should specifically change.

P.S. About delay, would it be more accurate if it was random from 1 to 3 seconds?

Best regards,
DnR

P.S. About delay, would it be more accurate if it was random from 1 to 3 seconds?

I would suggest min. 2 / max. 3 secs.



We could even go further and give a random chance to the whole thing.
So not every monster does it each time.

Could save some CPU cycles. ^^

I think for a good layout it is better to make the dependence on the distance agro, max range agro> 3 seconds, 75% aggro> 2 seconds, 50% and less without delay, but this is only for aggressive monsters, and if we attack the monster ourselves, it’s better to use as I already wrote above, when the monster has more than 80-85% xn then 3 seconds, and when less it is without delay.

DnR wrote:

xlinkinx wrote:
I checked my code, it works, if it is not difficult to check and you are in the sense of whether or not it was like l2off. It remains to hear the answer DNR about all this, but he is silent(

Your code is really fine and would definitely work. However, let me explain why I'm not going to use it.
The problem is task itself. Adding a threadpool executor to each monster that would run after so little time would probably be overheading, especially for a populated server.
Just think of multiple warlords inside a server trying to cast aggro to multiple groups of mobs at the same time.

Sleeping thread would be a lighter approach but it's also a bad practice since ai task gets paused for those 3 seconds.
If you think about it, we already have a running task per second which is ai task itself so we could use this to our advantage.
I'm already working on this, and thanks to you I know which code blocks I should specifically change.

Best regards,
DnR

Yes, I understood what you are talking about and without a doubt I understand that this can bring problems, therefore your knowledge is very important in this and I hope that you can do it more correctly. Thanks for your work.

xlinkinx wrote:I think for a good layout it is better to make the dependence on the distance agro, max range agro> 3 seconds, 75% aggro> 2 seconds, 50% and less without delay, but this is only for aggressive monsters, and if we attack the monster ourselves, it’s better to use as I already wrote above, when the monster has more than 80-85% xn then 3 seconds, and when less it is without delay.

This seems like a good approach.

I uploaded my patch in revisions 623 and 624.
This patch contains support for this issue, and archer flee issue (I'm going to give an answer to corresponding topic).
I set chance of monster walking to 50% and delay to 2 seconds instead of 3, because I noticed a slight schedule delay. You can test it and let me know.

DnR wrote:

xlinkinx wrote:I think for a good layout it is better to make the dependence on the distance agro, max range agro> 3 seconds, 75% aggro> 2 seconds, 50% and less without delay, but this is only for aggressive monsters, and if we attack the monster ourselves, it’s better to use as I already wrote above, when the monster has more than 80-85% xn then 3 seconds, and when less it is without delay.

This seems like a good approach.

I uploaded my patch in revisions 623 and 624.
This patch contains support for this issue, and archer flee issue (I'm going to give an answer to corresponding topic).
I set chance of monster walking to 50% and delay to 2 seconds instead of 3, because I noticed a slight schedule delay. You can test it and let me know.

Good news, now go check it out right away.

By the way, did you notice that there is such code in another place? the truth of his appointment is not yet clear.

Code:

            // Set the L2Character movement type to run and send Server->Client packet ChangeMoveType to all others L2PcInstance
            if (!_actor.isRunning())
            {
              _actor.setRunning();
            }

xlinkinx wrote:
Good news, now go check it out right away.

By the way, did you notice that there is such code in another place? the truth of his appointment is not yet clear.

Code:

            // Set the L2Character movement type to run and send Server->Client packet ChangeMoveType to all others L2PcInstance
            if (!_actor.isRunning())
            {
               _actor.setRunning();
            }

This is probably a code block in onEvtAggression, if I'm correct.
In most cases, aggression event will run together with an attacked event so there is no noticeable difference.
Either way, I added a check there too for those rare cases that attacked event won't execute.

DnR wrote:

xlinkinx wrote:
Good news, now go check it out right away.

By the way, did you notice that there is such code in another place? the truth of his appointment is not yet clear.

Code:

            // Set the L2Character movement type to run and send Server->Client packet ChangeMoveType to all others L2PcInstance
            if (!_actor.isRunning())
            {
               _actor.setRunning();
            }

This is probably a code block in onEvtAggression, if I'm correct.
In most cases, aggression event will run together with an attacked event so there is no noticeable difference.
Either way, I added a check there too for those rare cases that attacked event won't execute.

Yes, it was about this, thanks for the clarification and your work, I'll go watch))

It works very well as aggro for mobs and archers, I liked it a lot! keep it up.

DnR wrote:

xlinkinx wrote:I think for a good layout it is better to make the dependence on the distance agro, max range agro> 3 seconds, 75% aggro> 2 seconds, 50% and less without delay, but this is only for aggressive monsters, and if we attack the monster ourselves, it’s better to use as I already wrote above, when the monster has more than 80-85% xn then 3 seconds, and when less it is without delay.

This seems like a good approach.

I uploaded my patch in revisions 623 and 624.
This patch contains support for this issue, and archer flee issue (I'm going to give an answer to corresponding topic).
I set chance of monster walking to 50% and delay to 2 seconds instead of 3, because I noticed a slight schedule delay. You can test it and let me know.

Awesome !!!
One step closer to retail gameplay


Note : Maybe this topic should be moved to contributions (just for better overview)

Karakan wrote:
Note : Maybe this topic should be moved to contributions (just for better overview)

Done.

DnR, we completely forgot to add the switch for the agro skill to the exception in both cases.

xlinkinx wrote:DnR, we completely forgot to add the switch for the agro skill to the exception in both cases.

So aggression should always force monsters to run, right?
I'm going to take a look at this. Thanks.

DnR wrote:

xlinkinx wrote:DnR, we completely forgot to add the switch for the agro skill to the exception in both cases.

So aggression should always force monsters to run, right?
I'm going to take a look at this. Thanks.

Yes, you understood correctly, with a delay in running, there may be problems for players with a spear.

DnR wrote:
So aggression should always force monsters to run, right?
I'm going to take a look at this. Thanks.

Yes, aggression is a exception.

Rest of the skills (magic/debuffs/dots) are not.