Jump to content

[patch] Allow ScriptedAI to be used by summoned


Auntie Mangos
 Share

Recommended Posts

What bug does the patch fix? What features does the patch add?

- Allow scripting AI for pets/guardians if exist - needed in spells like mirror image, Summon Gargoyle, Snake trap, etc.

This used to be part of http://getmangos.eu/community/viewtopic.php?id=10150 split due to request.

For which repository revision was the patch created?

8526

Who has been writing this patch? Please include either forum user names or email addresses.

Me

Patch:

diff --git a/src/game/CreatureAISelector.cpp b/src/game/CreatureAISelector.cpp
index e446f72..4cfd8e3 100644
--- a/src/game/CreatureAISelector.cpp
+++ b/src/game/CreatureAISelector.cpp
@@ -32,10 +32,9 @@ namespace FactorySelector
{
    CreatureAI* selectAI(Creature *creature)
    {
-        // Allow scripting AI for normal creatures and not controlled pets (guardians and mini-pets)
-        if ((!creature->isPet() || !((Pet*)creature)->isControlled()) && !creature->isCharmed())
-            if(CreatureAI* scriptedAI = Script->GetAI(creature))
-                return scriptedAI;
+        // Try to get scripting AI first - go on only if there is none assigned
+        if(CreatureAI* scriptedAI = Script->GetAI(creature))
+            return scriptedAI;

        CreatureAIRegistry &ai_registry(CreatureAIRepository::Instance());

Link to comment
Share on other sites

Every subtype of pets (aka : guardians, huter's, mini, controlled, whatever), considered to be a pet, created directly as Pet() class.

So, no - there is no way currently assigning any scripted ai to any of them besides petAI.

Hmm, this is not correct as I think. Have a look at the code one more time. Non-controlled pet could already be controlled by a special script.

That is -by the way- the reason why I asked about this line at the beginning.... I'm not sure if there are really and controlled pets, that require a special AI...

Edit: Found my old patch :P : http://getmangos.eu/community/viewtopic.php?id=753&highlight=Guardian

Link to comment
Share on other sites

  • 39 years later...

Looks quite promising from first view, thank you :-)

One hint:

*      CreatureAI* selectAI(Creature *creature)
*      {
* -        // Allow scripting AI for normal creatures and not controlled pets (guardians and mini-pets)
* -        if ((!creature->isPet() || !((Pet*)creature)->isControlled()) && !creature->isCharmed())
* -            if(CreatureAI* scriptedAI = Script->GetAI(creature))
* -                return scriptedAI;
* +        // Try to get scripting AI first - go on only if there is none assigned
* +        if(CreatureAI* scriptedAI = Script->GetAI(creature))
* +            return scriptedAI;
*  
*          CreatureAIRegistry &ai_registry(CreatureAIRepository::Instance());

No good idea. Imagine creatures with scripted ai, that can also exist as hunter pets.

Edit: This thread has been splitted. Post #9 is the real starting post.

Link to comment
Share on other sites

Looks quite promising from first view, thank you :-)

One hint:

*      CreatureAI* selectAI(Creature *creature)
*      {
* -        // Allow scripting AI for normal creatures and not controlled pets (guardians and mini-pets)
* -        if ((!creature->isPet() || !((Pet*)creature)->isControlled()) && !creature->isCharmed())
* -            if(CreatureAI* scriptedAI = Script->GetAI(creature))
* -                return scriptedAI;
* +        // Try to get scripting AI first - go on only if there is none assigned
* +        if(CreatureAI* scriptedAI = Script->GetAI(creature))
* +            return scriptedAI;
*          CreatureAIRegistry &ai_registry(CreatureAIRepository::Instance());

No good idea. Imagine creatures with scripted ai, that can also exist as hunter pets.

Actually I just made a little test, adding Gargoyle script to mage's water elemental. Well, it works pretty well to my surprise. They do co-exist. After all, script calls are just hooks.

However there may be other problems with the idea. Like the tamed pet case.

But I guess the responsibility should be on script writer. I mean, sure I can create situation inside my AI script that will totally ruin something. But at the moment there's no option at all adding complex scripts for guardians or/and pets.

In general, those lines are not directly connected to main patch idea, just little auxiliary thing for related development.

In any case, we need to find proper solution to this issue. If anyone have better idea, I'll be more than glad to hear it.

Link to comment
Share on other sites

Actually I just made a little test, adding Gargoyle script to mage's water elemental. Well, it works pretty well to my surprise. They do co-exist. After all, script calls are just hooks.

Hmm, very strange. You mean it is possible that an creature can have two ai's at same time (stack!?).

Anyway besides that: As I understand the current code, the AI is selected by CreatureInfo->ScriptID. Imagine any creature that uses e.g. eventAI. The same creature (or at least a unit with the same creature template) can be summoned by a hunter. Your provided code will use the ai provided in CreatureInfo (eventAI in this example), but not the PetAI.

This is a normal case and has nothing to do with the responsibility of the script writer. You can not simply claim, that beasts do not have any ai, because they can also exist as pets^^

I know that this is not the main idea of the patch ^_^ Just want to clarify that because I started to comment on this.

Also possible that I am totally wrong...

Link to comment
Share on other sites

I made poor choice of words "co-exist" .

It doesn't stack. Instead of assigning to i_AI (thou which all calls are made) petAI, it adds ScriptedAI.

No petAI calls are made whatsoever.

When I said " responsibility should be on script writer" I mean exactly this.

When you register your script (inside the script itself - newscript->GetAI = &GetAI_whatever; - inside GetAI_whateve), you can always check if this creature is controlled or not. If it is, and you want your custom script to run, you return it, otherwise, you just return petAI. This way, you specify for every creature how to act in every situation.

Both pet and whatever script you make inherited from ScriptedAI anyway. I mean, you can even return custom petAI script inherited from petAI itself. Possibilities here are limitless. Disallowing such freedom in the first place is shame in my opinion.

Thats just my idea, If anyone has better, feel free to share.

The only other thing i can think of is having another field in DB to have separate scripts for every case - just redundant.

I really don't see the problem here. If I'm mistaken and someone can point me whats wrong I'll gladly adapt.

If anyone who understands creature ai in general better would participate the "debate", that would be awesome.

This is really good you bringing such points - that is the only way we can make better solutions.

Thanks in advance.

Link to comment
Share on other sites

I actually find AI enabling for pets very usable, Snakes from Snake Trap for example, hardcoding doesnt look good for it

though

"When you register your script (inside the script itself - newscript->GetAI = &GetAI_whatever; - inside GetAI_whateve), you can always check if this creature is controlled or not. If it is, and you want your custom script to run, you return it, otherwise, you just return petAI"

Qsa, i doubt its possible like that cause AI is loaded while loading core, You cant get pointer to creature itself from that point of code

Link to comment
Share on other sites

Qsa, i doubt its possible like that cause AI is loaded while loading core, You cant get pointer to creature itself from that point of code

It is loaded at startup, but it is assigned when creature created ( or summoned in our case ).

Check Creature::AIM_Initialize() : FactorySelector::selectAI() : Script->GetAI(creature) :: well that GetAI is the pointer in your script and you do have the creature right there - a new copy just created.

You can use it right now to make your snake trap or whatever :) ( assuming you're using this change) I have ebon gargoyle working just fine.

There is no problem with creatures that can have only one type of ai sctipt ( as far as I know , heh )

If we're speaking technically, I'm more worried about the support needed to allow assigning petAI from scripts. At the moment its dug out using CreatureAICreator which I doubt accessible from the scripts.

We have chain of ~10 posts talking about some minor option. Guess it should be moved into topic on its own. I know I should have spliten it to 3-4 different patches :/

Which reminds me : anyone found any other problems?

Link to comment
Share on other sites

- Allow scripting AI for pets/guardians if exist - needed in spells like mirror image, Summon Gargoyle, Snake trap, etc.

I thought that mirror image or snake trap summons GUARDIANS, not combat pets, so they should've been scriptable even before your patch, or? (according to comment - "// Allow scripting AI for normal creatures and not controlled pets (guardians and mini-pets)") :o

Link to comment
Share on other sites

I thought that mirror image or snake trap summons GUARDIANS, not combat pets, so they should've been scriptable even before your patch, or? (according to comment - "// Allow scripting AI for normal creatures and not controlled pets (guardians and mini-pets)") :o

Every subtype of pets (aka : guardians, huter's, mini, controlled, whatever), considered to be a pet, created directly as Pet() class.

So, no - there is no way currently assigning any scripted ai to any of them besides petAI.

Link to comment
Share on other sites

You are right, I totally overlooked that iscontroled() check.

Strangely it didn't work in my tests prior to this change, but thats maybe be due to wrongly handled summons, or some custom additions of mine.

In any case, I think it still can be good having this option for controlled pets.

Link to comment
Share on other sites

yes there is acually no need for this you could just add a spell to a guardian if it is summoned with autocast_flag and everything is handled by guardian_ai so there is no need for this kind of patch... trinity soluted it this way but i think this is complete wrong way to handle this...

Link to comment
Share on other sites

if this was so your guardian pet would do nothing like a passive pet... adding spell with autocast flag is enough a separated ai would be waste of code

i can give you exampple how i soluted snake trap or ghost wulve adds of shaman for example temporary the hardcoded way... but i can give also example how to do this more generic with database support or dbc(if this is possible, i got to investigate dbcs first)

Link to comment
Share on other sites

  • 1 month later...
As i understand from discussion all referecned cases is guardians in fact and then already work with current code anyway.

I see only single less stricted check maybe: allow scriting for charmed/controlled pets with creatures owner.

They anyway work as guardians mostly.

unfortunatelly not :( if you apply any action in ScriptedAI npc leave MotionMaster->MoveFollow() and standing in one place. Hacks like this http://www.scriptdev2.com/dev-small-pet-t4609.html rewriting whole Pet behaviour are needed than.

Link to comment
Share on other sites

unfortunatelly not :( if you apply any action in ScriptedAI npc leave MotionMaster->MoveFollow() and standing in one place. Hacks like this http://www.scriptdev2.com/dev-small-pet-t4609.html rewriting whole Pet behaviour are needed than.

no you are wrong it is working as intended if you use core implemented guardian ai :)

just as i said spells have to be added with autocastflag when guardian is created and everything is working fine ;)

as far as i can see scripted ai maybe usefull for runeblade summon but nothing else... others can be soluted better with no waste of code :)

Link to comment
Share on other sites

  • 2 years later...
Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...

Important Information

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. Privacy Policy Terms of Use