Bot Discussion

[blackdragonsdg]

I am all for improved bot AI as it would help make raiding easier on servers with low populations.
As soon as I started reading this thread the thought of AI driven bots trying to slow a raid mob with any sort of efficiency made my skin crawl. As it has already been stated the speed at which a raid mob is slowed can be the difference between winning and losing. Obviously shamans have the strongest slows but it doesn’t matter one bit when the raid target mitigates the slow to a much lower percentage which happens more often than not. One shaman and one enchanter should always be on resist debuff duty and the rest of the classes that are able to cast slow should cast and keep on casting slow till it lands. That is the easy part…now how are the bots going to know when to cast a magic based slow or a disease based slow(Emperor Ssraeshza)? How will the bots know when a belly cast(Sontalak) is required versus just melee range? How will the bots know when to use single target slow or aoe slow? Grant it AOE slow is mostly used when you have a suicidal shaman in the mix but sometimes it is used in the Corinav event to help slow the damage the aoe stunners and aoe damage casters might take. Another issue I can see from live is some mobs are highly resistant to slow or even magic based spells but they are not flagged as immune….Gaukr Sandstorm is a good example of this…while not immune to magic he is so highly resistant most never bothered trying to slow him. It raises the question as to when will be bots stop trying to cast debuffs or will they just keep casting till they are out of mana. Seems like some tricky AI is headed someone’s way.
To answer a question about slow spells on live the spell with the strongest effect had priority and would overwrite the lower powered spells.

[Criimson]

now how are the bots going to know when to cast a magic based slow or a disease based slow(Emperor Ssraeshza)?

There is already code that can be used to check a mobs resists and cast based on that. It is used atm in DDs and in slows.

How will the bots know when to use single target slow or aoe slow

Now this code is not in atm as far as I can tell. I did notice a mob count function that was related to fear. If I am corect it checks how many mobs are in close proximity and not agroing and if its a certain number then fear isnt cast. I was looking at it thinking I might alter it to to start an agro check for aoe spells like aoe mez.

Another issue I can see from live is some mobs are highly resistant to slow or even magic based spells but they are not flagged as immune….Gaukr Sandstorm is a good example of this…while not immune to magic he is so highly resistant most never bothered trying to slow him. It raises the question as to when will be bots stop trying to cast debuffs or will they just keep casting till they are out of mana. Seems like some tricky AI is headed someone’s way.

IMO this is exactly what this thread is about. Each of us probably has a different way of thining about this. As the contributers to this thread we all have a love of bots and we can come to some agreement about a structure that suits the needs/desires of each of us and then start a-codin'.
Using your last question as an example: Code could be implimented that checked a certain amount of casts before giving up on that spell and as resist checks are pretty easy to code there could be a range in which it is basically seen as immune. To me bot AI isn't very difficult to break down. A thought process is basically a tree and the branches are far from infinite.

[Criimson]

A thought before I hit the hay.

bad_captain mentioned that raidbots were removed because some servers didnt like it/want it. I personally would like it and I know that there are others. I suggest a variable in the rule_values table to allow or disallow it. It could be checked when a player does a raid invite and checks that the person getting invited is a player or a bot. DOesn't seem too hard to impliment.

Anyway
Night all

[Congdar]

Originally Posted by Criimson

...because some servers didnt like it/want it.

That's not why. DB rules for how many bots you can spawn are already in place, so if a server has enabled the bots they can also control how many you can spawn.

The real reason is probably a combination of time and desire. I had raids working in the bot system at one time but the code was all in #ifdefs and scattered throughout the source files. See svn 772-4 and before for that version of the bots. The "Repository owner and principal project developer" organized all the #ifdefs into proper classes and then vanished pretty much leaving the bots in a crippled state without completing the bot raid parts.

Back then I was the only one working on them and the bots are a complex beast, so the ai was something I didn't focus a lot of time on. I'm happy that you and others are interested enought to do some serious fixing and maybe raids will be coded again using the actual raid UI instead of what I had slapped together.

[Criimson]

Originally Posted by Congdar

That's not why. DB rules for how many bots you can spawn are already in place, so if a server has enabled the bots they can also control how many you can spawn.

The real reason is probably a combination of time and desire. I had raids working in the bot system at one time but the code was all in #ifdefs and scattered throughout the source files. See svn 772-4 and before for that version of the bots. The "Repository owner and principal project developer" organized all the #ifdefs into proper classes and then vanished pretty much leaving the bots in a crippled state without completing the bot raid parts.

Back then I was the only one working on them and the bots are a complex beast, so the ai was something I didn't focus a lot of time on. I'm happy that you and others are interested enought to do some serious fixing and maybe raids will be coded again using the actual raid UI instead of what I had slapped together.

Ah well that is good then. The last thing I want is start creating things that others would be upset about.

I did notice raid in some of the code for bots and figured it had been in there at some point. Like in the shrink command I noticed raid casting was commented out.

[Criimson]

As to the Necro AoE.

I didn't scan the entire DB for aoes, but I did remove the AoE 365 and here is the sql:

DELETE FROM `npc_spells_entries` WHERE `id`=6838 LIMIT 1;

In case anyone wanted it

Criimson

[bad_captain]

EDIT: Oh yea since we are discussing
I had an idea that I am going to work on but want to know if you all would like to see it in the main code or as custom code
WHen grouped with a live ranger/druid or bard and they track something they say like its to the left or right or whatever. I was thinking of altering the bot tracking window to function like the find function. That goofy gold trail. Its like someone say go left. It kind of points you in the right direction but its AI is so goofy that its more like getting directions from someone. It isnt live like just knowing a mob is up somewhere imo. What do you guys think?

I think that would be categorized as custom, but I think the current tracking code could be tweaked to at least give the direction, as it's fairly worthless as is. It basically only tells you if a mob has spawned or not (and the common spawn filter is pretty bad)..

[bad_captain]

Originally Posted by Criimson

Now this code is not in atm as far as I can tell. I did notice a mob count function that was related to fear. If I am corect it checks how many mobs are in close proximity and not agroing and if its a certain number then fear isnt cast. I was looking at it thinking I might alter it to to start an agro check for aoe spells like aoe mez.

AOE spells definitely need to be thought out and added in. AOE nukes would most likely need to be togglable, since I can see the usefulness on AEing for faction or questing, but think the AI would be difficult to get right so it doesn't break mez, root, or otherwise affect mobs you wouldn't want it to.

[bad_captain]

Originally Posted by Criimson

Using your last question as an example: Code could be implimented that checked a certain amount of casts before giving up on that spell and as resist checks are pretty easy to code there could be a range in which it is basically seen as immune. To me bot AI isn't very difficult to break down. A thought process is basically a tree and the branches are far from infinite.

Wizard nuke code already does somethign similar. It compares the mob's resists, and determines which is lower, but must be a certain amount lower to coose one group of nukes over another. We would just have to determine at which point it's pointless to continue casting a magic or fire based spell. But we would also have to factor in lure type spells, just in case there are custom spells, or spells added later that use them.

I see preventing in the first place as better than tracking how many times a certain spell fails to land. Less to keep track of and more efficient.

[bad_captain]

Originally Posted by Congdar

That's not why. DB rules for how many bots you can spawn are already in place, so if a server has enabled the bots they can also control how many you can spawn.

The real reason is probably a combination of time and desire. I had raids working in the bot system at one time but the code was all in #ifdefs and scattered throughout the source files. See svn 772-4 and before for that version of the bots. The "Repository owner and principal project developer" organized all the #ifdefs into proper classes and then vanished pretty much leaving the bots in a crippled state without completing the bot raid parts.

Back then I was the only one working on them and the bots are a complex beast, so the ai was something I didn't focus a lot of time on. I'm happy that you and others are interested enought to do some serious fixing and maybe raids will be coded again using the actual raid UI instead of what I had slapped together.

Hmm.. I thought someone said he took it out because it was decided we shouldn't be able to have bot raids. Maybe I'm going crazy.. lol

This is a very good thing to hear. I'll definitely be looking into this.

[Criimson]

Originally Posted by bad_captain

AOE spells definitely need to be thought out and added in. AOE nukes would most likely need to be togglable, since I can see the usefulness on AEing for faction or questing, but think the AI would be difficult to get right so it doesn't break mez, root, or otherwise affect mobs you wouldn't want it to.

I was thinking about something related to this and it fits well into this idea.
I was pondering this:

How will the bots know when a belly cast(Sontalak) is required versus just melee range?

I am assuming that certain functions will simply have to be added as bot commands. Belly cast and AoE allowed being two of them. Bot AI could be added for MoBs like bosses but at times it will fail. For instance, I remember AoEing for exp in Seb, but a bot isnt able to determine if we are on an AoE exping trip to seb or a slow going mez stuff trip. Having commands to turn off mez and turn on AoE would be neccessary.

[bad_captain]

Originally Posted by Criimson

I was thinking about something related to this and it fits well into this idea.
I was pondering this:


I am assuming that certain functions will simply have to be added as bot commands. Belly cast and AoE allowed being two of them. Bot AI could be added for MoBs like bosses but at times it will fail. For instance, I remember AoEing for exp in Seb, but a bot isnt able to determine if we are on an AoE exping trip to seb or a slow going mez stuff trip. Having commands to turn off mez and turn on AoE would be neccessary.

I'm not sure belly casting is required for bots. I remember taking some of the dragons out, but not having to be under them for bot spells to land. I may be wrong, but I think it's only checking for clients. I'd have to look to be sure, though.

[Criimson]

Originally Posted by bad_captain

I'm not sure belly casting is required for bots. I remember taking some of the dragons out, but not having to be under them for bot spells to land. I may be wrong, but I think it's only checking for clients. I'd have to look to be sure, though.

That makes sense since bots arent restricted by regeants and can bypass other things as well according to comments in the code.

[pfyon]

Originally Posted by bad_captain

I think that would be categorized as custom, but I think the current tracking code could be tweaked to at least give the direction, as it's fairly worthless as is. It basically only tells you if a mob has spawned or not (and the common spawn filter is pretty bad)..

I think it would be easier/more live-like to just call whatever functions are required to track on the client so the player would get the tracking messages like they would if they were a ranger/druid doing the tracking themselves.

[Criimson]

Originally Posted by pfyon

I think it would be easier/more live-like to just call whatever functions are required to track on the client so the player would get the tracking messages like they would if they were a ranger/druid doing the tracking themselves.

Sounds good to me. I was looking for input on this before I started.

I think the next thing I am going to work on is more investigative anyway. I have noticed that the chanter's pet (and only chanter's pet) seems to be grabbing strange agro and I have no clue on what or why. It keeps giving messages about invalid target and the chanter begins trying to mez her pet. Its odd. I added a string to the invalid target message so later I'll see what it is trying to attack.