EQEmulator Forums

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)
-   Development::Bots (https://www.eqemulator.org/forums/forumdisplay.php?f=676)
-   -   Bot Discussion (https://www.eqemulator.org/forums/showthread.php?t=33878)

bad_captain 07-19-2011 04:59 PM

Bot Discussion
 
Since there has been some bot interest lately and I actually have a bit more time (I started a new job and am still working part time at my old job, and I have an 8-week old baby :D ), I wanted to try and organize some discussion regarding bots and some of the work being done. I was given commit access to the svn a few months ago, which was right before all of my changes, but was able to post some of my work with bot spells, healing, etc.

I would like to maintain a wishlist of enhancements for bots, with discussion, comments, and code, if anyone has any (or at least a link to a thread that contains it). This would be easier if I was a forum admin for the bots section so I could just continue to edit and maintain one post, but we'll do with what we have. I want to have opinions on some of the things we're working on and any ideas that may make bots even better than one person may envision. Criimson has a good starting list here.

From my own experiences and some of the recent discussion, I think one of the biggest improvements that can be made is handling how bots cast spells ( or not cast them ). After reviewing the work done by Pfyon and Criimson, here , here and here, I would suggest a few changes that would be more generic, but more powerful.

First, Bot roles were partially implemented, and the archetype system partially duplicates what was currently there (but not functional). I would suggest combining the 2 to eliminate redundancy. I believe Bot roles would provide more flexibility, as I stated in the pfyon thread where he introduced his archetypes. Possible roles include MT, secondary tank, main healer, secondary healer, puller, slower, etc. This would allow both buffs tailored to roles (rune on puller, Voice of Thule (agro+)on MT, etc.) and different AI based on roles (secondary healers cast other spells more than just heals, MTs taunting, beastlord without slower role would not slow, etc)

Second, I would try to remove hardcoded spells, spelltypes, or percentages as much as possible. I think loading generic spell preferences from the database with the ability change them on a class/individual basis would be preferable, as I do want my clerics or enchanters nuking; for me, they rarely run out of mana, and would prefer them to be productive instead of standing there. I move quickly, so I rarely allow my bots to get back to 100% mana when raiding. Others may be more passive, and not want their clerics to nuke no matter what, or have an enchanter that doubles as their only DD nuke source. Some of the new percentages don't really fit my play style, so I will change them back on my private server. I also like my hybrids healing, as they tend to heal themselves (they check themselves first to see if they need healing, which offloads some healing from my cleric, which especially helpful against rampagers or mobs with area affects). The change also almost eliminates the Paladin's ability to group heal, which can be a lifesaver. Regardless, something flexible would be best so everyone could tailor their bots' AI how they would want. Also, I definitely want to be able to add new spells to the bots' spell lists such as Voice of Thule and other agro management spells.


After some brainstorming on the issue of roles, buffs, and AI changes, I had a few ideas that I wanted to post to gather some comments and thoughts on what might be best.
  • First, I thought of server rules to determine how the various classes would act that could be adjusted, but I'm sure players would like to make their own to a basic system to tailor it to their needs. I don't think this would be a good approach, as it's not much better than just going in and changing it in code, and it's server-wide.
  • Second, I thought of making changes to the npc_spells_entries table to be able to store some information on who the spell should be cast on (target type), but it doesn't make much sense to change the whole table structure that will only affect bots, not all other npc types. I think for this to work, the best option may be to pull bot spells from the npc_spells and npc_spells_entries table into their own tables, and add a bitmask column for bot roles that the spell can be cast on. This may also need to be implemented for my next thought..
  • A third option would be to have presets that can be selected for the various spell types a bot can use. This would be secondary to bot roles- a beastlord must have the role slower to slow, then the aggressiveness setting would determine how often they would cast it. For example, for spelltype Heal, the bot could have Default, Passive, or Aggressive (which I believe somewhat mirrors mercs). A Cleric with Default would act as before, with Passive being more mana efficient, and aggressive less mana efficient, but faster healing (trying to keep healing target at max HP). Same for Nukes, Debuffs, Slows, etc. For spells such as slows, instead of saying one class automatically being ahead of another class, an aggressive slower may try to slow every mob, wheres as passive slower would only try to slow named-type mobs, or act the same, just with a lower priority.

I look forward to starting a discussion on bots and what others are interested in with regards to improvements that should be made. I use bots exlusively on my private server and am always looking for ways to better use them to move through PoP progression and beyond, including disciplines. The previously mentioned change to bot spells would allow melee-only disciplines be added, some of which I already have coded (I use #bot defensive), healing rotations (working on a rewrite), and if possible, battle rezs for bots..

Please feel free to post comments or thoughts. I used to be in #bots, but I don't have that option now, and so it's better to keep my discussion here (also so others can see who don't visit the irc chat).

Criimson 07-19-2011 09:05 PM

I am all for this.

Quote:

Second, I would try to remove hardcoded spells, spelltypes, or percentages as much as possible.
I had actually started planning for this. I was trying to get code in that showed itself working before I started doing changes to the DB structure. I think I mentioned it in one of my posts.
What I envisioned was a set of helps for each bot class that would list commands that relate to that class. Such as percentages and roles.

My coding is still at a learning stage so was taking it relatively slow.

Quote:

as I do want my clerics or enchanters nuking; for me, they rarely run out of mana,
Is a prime example of why bot by bot settings would be preferable. I have my exp turned to 0.1%, I have no defiant gear and gear up by fighting and questing so my bots are always OOM. Its been over a week playing this character and I am only level 15 :-) Good times though.

Quote:

Second, I thought of making changes to the npc_spells_entries table to be able to store some information on who the spell should be cast on (target type), but it doesn't make much sense to change the whole table structure that will only affect bots, not all other npc types. I think for this to work, the best option may be to pull bot spells from the npc_spells and npc_spells_entries table into their own tables, and add a bitmask column for bot roles that the spell can be cast on. This may also need to be implemented for my next thought..
I am not sure that this would be neccessary. I would need an example. With archetypes, bot roles, and class settings I think that the rest would be handled by AI thorugh the code. Reading too much from the DB, especially during large scale combat, seems like it would just slow the server down.

-----------------------
My origianl plan was this:
Work on class AI that I am familiar with and small tweaks to fluffy type things.

Once I had the AI basically behaving properly. I would focus on adding the ability of players to alter the bot AI to fit their gaming needs.

Realistically, I could have percentages of AI already coded finished in a day. I just thought that there were only a few of us interested in bots to be honest and so wasnt a priority. If you'd like I can have some class settings done by tomorrow night.

What I'd like to see in this thread and discussed is what the players who use bots would like to see or think is coded wrong. I don't use every class in my group so some bots could be behaving really incorrectly and I'd never know.

For instance, I'd like to code in a ranger ai that checks for distance to mob engaged and chooses melee/ranged based on that. I know the code has bots stop dead when I engage so I'd be annoyed if the range just stood there, but I don't know. I don't group with a ranger.

I'll post more later.

Criimson

EDIT:

As to priorities. I assume you are thinking more raids. I wasn't even trying to think of raid AI until group AI was working the way I wanted.
So for instance priorities are basically in the code. If a shaman and an enchanter are grouped: Enchanter hastes - shaman slows unless the MoB is DR resistant. That code is in there.
I would like to see healing priority worked on, but I never played a healer so was putting it off. I don't even know if a druid heals better than a shaman.
I have decided to work on adding percentage code in next. Allowing players to choose at what percentage to heal, for instance. It will be on a per bot basis (adding a healing percentage column to bots) and then gauge server load during combats. I'd assume there is a way to read that data and keep it in memory but again I am not sure if that would cause more load than just reading it each time, especially since some servers use bots and have large player populations. Although, I have tinkered a bit player side with Angelox's DB and he has some good code. (Like I'd love to know how he has his bots stand in a spaced way behind the player using his #bot move command)

I think that if we get a few coders to work on bots then we can break tasks up. I would love to see raid working for bots before I get to that point :) I am not keen on the idea of just having a bunch of bot groups when it doesn't seem that hard to be able to raidinvite the bot group leader. Havent looked at the code for this though.

Criimson 07-19-2011 11:29 PM

Before I begin on anything else I am going to wait a bit for replies to this thread. In the mean time I am going to work on something for my bots. Unsure if I'll submit it for main code though as I am not sure if it will mess with large server communities. Basically allowing my chanter to enchant my metals for me. Have been meaning to do this as I'd like to jewelcraft on my warrior.

bad_captain 07-19-2011 11:31 PM

Quote:

Originally Posted by Criimson (Post 201576)


I am not sure that this would be neccessary. I would need an example. With archetypes, bot roles, and class settings I think that the rest would be handled by AI thorugh the code. Reading too much from the DB, especially during large scale combat, seems like it would just slow the server down.

Criimson

Spell data is read only once. An example: I want Voice of Thule cast on my Main tank only. This could be put into code, but what if someone is using a custom spell file? Or Sedulous Subversion, necro mana transfer spell. I would think you would only want it cast on Cleric or maybe Enchanter. (main healer or crowd control) Also, I added in the percentage heals for Druids with my healing update a few months ago. As a backup healer, I would prefer that they stay away from them, since they take so long to cast, but if the Druid was the main healer, I would rather them use the percentage heal, since it's more efficient.

Quote:

Originally Posted by Criimson (Post 201576)
-----------------------
My origianl plan was this:

Realistically, I could have percentages of AI already coded finished in a day. I just thought that there were only a few of us interested in bots to be honest and so wasnt a priority. If you'd like I can have some class settings done by tomorrow night.

While I appreciate the offer, I suggest running up through level 65, grouping with multiple classes to get a better feel for how the classes interact, and what spells are cast when. You mentioned being level 15. At that level ( and through the 50s probably) you will be OOM a lot, since you have little to no mana regen. For the past year, on and off, I have been going through all spells, trying to get bots to level 75+, as well as add in any spells that can be with the current code, or for ideas as to what can be added in the future. While I know much more about the spells than I did before, until I grouped certain classes together running through Vex Thal or PoFire, I didn't really see how to better manage my groups to be more efficient. I'm not sure a wholesale change of percentages would be best until decisions are made as to future changes, or at least a better understanding of higher level grouping / bot group raiding would be impacted. As I said before, limiting nuking by clerics or enchanters, or healing by hybrids may seem like a great idea, but when my main cleric has 9K mana, 100+ mana regen with spells while sitting, and a 10K HP tank, my cleric would be bored if it only had to cast a complete heal every 30 seconds. Also, as I stated, Paladin group healing is crippled by having the target be less that 20% to be healed. Having the paladin group heal running when being AE Dotted is a lifesaver. Of course, there will be other examples. I just wanted to point out that a good understanding of grouping / raiding is needed before making changes within the spell code. That's why I haven't made many more changes than I have.

Quote:

Originally Posted by Criimson (Post 201576)
What I'd like to see in this thread and discussed is what the players who use bots would like to see or think is coded wrong. I don't use every class in my group so some bots could be behaving really incorrectly and I'd never know.

This is what I'm looking for. While I use all classes in different ways, other people have different play styles that I would like to learn about. That would definitely help direct how some of these things are coded.


Quote:

Originally Posted by Criimson (Post 201576)



I had actually started planning for this. I was trying to get code in that showed itself working before I started doing changes to the DB structure. I think I mentioned it in one of my posts.
What I envisioned was a set of helps for each bot class that would list commands that relate to that class. Such as percentages and roles.

I missed one option I had thought about, which was allowing players to specify the exact mana percentage that a cleric would stop nuking, or a ranger would stop healing, etc. After thinking more on it, I think I like the idea of presets that a player can select from, which would have a certain percentage already attached to it. Not as granular in control over the bot AI, but it would give a good start into the concept of mercs, who use a similar system. This is what I wanted feedback on, as to what other bot owners would prefer.


Quote:

Originally Posted by Criimson (Post 201576)
I would like to see healing priority worked on, but I never played a healer so was putting it off. I don't even know if a druid heals better than a shaman.
I have decided to work on adding percentage code in next. Allowing players to choose at what percentage to heal, for instance. It will be on a per bot basis (adding a healing percentage column to bots) and then gauge server load during combats. I'd assume there is a way to read that data and keep it in memory but again I am not sure if that would cause more load than just reading it each time, especially since some servers use bots and have large player populations. Although, I have tinkered a bit player side with Angelox's DB and he has some good code. (Like I'd love to know how he has his bots stand in a spaced way behind the player using his #bot move command)

See my above comments on percentages. If the data is saved within a bot in the database, and loaded when the bot is spawned, it wouldn't have to continuously be loaded from the database.


Quote:

Originally Posted by Criimson (Post 201576)
I think that if we get a few coders to work on bots then we can break tasks up. I would love to see raid working for bots before I get to that point :) I am not keen on the idea of just having a bunch of bot groups when it doesn't seem that hard to be able to raidinvite the bot group leader. Havent looked at the code for this though.

A decision was made to remove bot raids since some people didn't think a player should be able to run around with 71 bots and run a full raid force at raid targets. If bots were added back into raids, a lot of code would need to be rewritten to take raids into account. Not that it wouldn't be worth it, but it would be a decent effort to do.

I do not want to disuade you from working on any one area and certainly appreciate your enthusiasm for bots, but I would suggest doing some more work such as the armor tinting (great job BTW), etc. until you get a better understanding of the spell code, before making such large changes on something that is so integral into bots and their worth to users. I am not saying I can do this better or anything, or anyone else, but I would ask that we get feedback from other bot users on what they would like to see before a lot of work is put into these kinds of significant changes.

bad_captain 07-19-2011 11:35 PM

Bah, you beat me...


Anyway, as a short summary, I want to know if bot owners would rather enter percentages to control how and when a bot begins/stops casting a specific type of spell, or if they would rather have presets that would increase / decrease when and how often bots cast their spells.

I vote presets, as I think it would be easy enough for anyone to use, but would still allow changes in AI based on players' wants and needs.

Criimson 07-19-2011 11:55 PM

Quote:

Quote:

Originally Posted by Criimson
-----------------------
My origianl plan was this:

Realistically, I could have percentages of AI already coded finished in a day. I just thought that there were only a few of us interested in bots to be honest and so wasnt a priority. If you'd like I can have some class settings done by tomorrow night.
While I appreciate the offer, I suggest running up through level 65, grouping with multiple classes to get a better feel for how the classes interact, and what spells are cast when. You mentioned being level 15. At that level ( and through the 50s probably) you will be OOM a lot, since you have little to no mana regen. For the past year, on and off, I have been going through all spells, trying to get bots to level 75+, as well as add in any spells that can be with the current code, or for ideas as to what can be added in the future. While I know much more about the spells than I did before, until I grouped certain classes together running through Vex Thal or PoFire, I didn't really see how to better manage my groups to be more efficient.
I played live to 80. The only classes I didn't play were healers because they felt boring.

This does bring to mind though that roles should be a cornerstone of the AI. Especially since grouping and raiding are vastly different. In raids there are more than one of any given class and so the idea of roles grows stronger. I am primarily going to stick with group AI at the moment for two reasons. 1) I mainly group and as you say I won't be extensively testing and tweaking the code if I am not utilizing it. 2) If a bot can't act correctly in a small setting than it will almost certainly fail in a larger setting. Most of my code thus far has come from playing and noting issues that I am having.

For instance enchanter AI. One of my main characters was a chanter and so it is driving me crazy that it isnt playing like I would. That is when I noticed that the priority column in the DB is a waste on them. I keep getting distracted to other things but I have mez at highest priority and even have a simple check that it should run before casting anything but it seems to cast mezzes at random times. Sometimes Im proud of it and other times I want to just kick it from the group.

EDIT:
Also the code for healers is good to have in the code because it helps the people that can't code. With no check in place clerics were DDing till oom. Perhaps I set the % too high for some, but most of the threads I read on clerics and mana were complaining about oom issues. FOr those that have been around and can compile their own code they can change it easily and until we add a #bot commands for in game settings I think it helps.

bad_captain 07-20-2011 01:06 AM

Quote:

Originally Posted by Criimson (Post 201584)
I played live to 80. The only classes I didn't play were healers because they felt boring.

I didn't mean to question our EQ acumen, just that as you have noticed, bots behave differently than a player would, and their interaction at different levels are something you need to experience before you can truly understand how changing code can affect their behavior. Fixing something at one level may significantly impact another level in a completely different way.

Quote:

Originally Posted by Criimson (Post 201584)
EDIT:
Also the code for healers is good to have in the code because it helps the people that can't code. With no check in place clerics were DDing till oom. Perhaps I set the % too high for some, but most of the threads I read on clerics and mana were complaining about oom issues. FOr those that have been around and can compile their own code they can change it easily and until we add a #bot commands for in game settings I think it helps.

The only one I remember seeing having OOM issues since I made the healing changes was from pfyon, but I may have missed others. I think a 50% baseline would be appropriate, with the ability to adjust from there would be ideal.

Regardless, I just wanted to point out that you have to extra careful when making any DB schema changes, as some are reluctant to approve code that does so. I found out the hard way when I spend a month working on pet code allowing them to equip all equipment slots, as well as pet focus code that preequipped equipment on pets summoned with a pet focus. Since these changes required changes to the player profile in the database, they were never implemented. I'm still waiting for the required changed to the player profile for proper pet focus handling (and saving when zoning/suspending). I just wanted to point it out and help you be aware of some of the potential issues you may encounter. Plus, I just wanted feedback on my thoughts and get your (and everyone else's) view of what priorities should be.

Criimson 07-20-2011 01:50 AM

Quote:

The only one I remember seeing having OOM issues since I made the healing changes was from pfyon, but I may have missed others. I think a 50% baseline would be appropriate, with the ability to adjust from there would be ideal.
Yea I read the AXClassic forums as well and I think it was mentioned there the most. Seems that people that use bots prefer his repack because it has bots at a more functional level and repacks make a new persons life so much eaiser.

bad_captain 07-20-2011 10:09 AM

Quote:

Originally Posted by Criimson (Post 201576)

So for instance priorities are basically in the code. If a shaman and an enchanter are grouped: Enchanter hastes - shaman slows unless the MoB is DR resistant. That code is in there.

I just wanted to add this for my reference more than anything. Since I do raid with bots and take on tough mobs with sometimes just one group, I don't have a problem with both enchanters and shaman slowing (or beastlords, or any of the specialty slows), and here's why: Oftentimes, the difference between winning and losing is how quickly a slow lands. Shaman have Malo, Enchanters have tash, which sometimes is almost required before a slow will land. I know the logic could be tweaked from what it was, but it allowed the Shaman to cast the debuff, and the enchanter could cast the slow. (The enchanter could tash as well, but you get the point) If a slow was resisted, you would have to wait until the Shaman was finished casting, then cast again. I don't care who gets the slow first, just as long as the mob is slowed. I would even take a beastlord slow to help get the mob under control. The AI could also allow the slow to be overwritten if a bot has a better slow than what's currently on the mob (I assume this is how things work on live- I don't believe the second slow doesn't land because there's already a slow on.)


A possible example of healing/nuking presets: A cleric on Normal Nuking would only nuke when mana > 50%, Aggressive when mana > 25%, passive when mana > 75%. Hybrid healing: normal- heal when bot/player HP <25%, passive self heals only, aggressive- HP < 50%. (I would rather my hybrids heal than nuke- almost all hybrid nukes except those with stuns are horrible and terribly inefficient...).

Criimson 07-20-2011 02:16 PM

Quote:

Originally Posted by bad_captain (Post 201588)
I just wanted to add this for my reference more than anything. Since I do raid with bots and take on tough mobs with sometimes just one group, I don't have a problem with both enchanters and shaman slowing (or beastlords, or any of the specialty slows), and here's why: Oftentimes, the difference between winning and losing is how quickly a slow lands. Shaman have Malo, Enchanters have tash, which sometimes is almost required before a slow will land. I know the logic could be tweaked from what it was, but it allowed the Shaman to cast the debuff, and the enchanter could cast the slow. (The enchanter could tash as well, but you get the point) If a slow was resisted, you would have to wait until the Shaman was finished casting, then cast again. I don't care who gets the slow first, just as long as the mob is slowed. I would even take a beastlord slow to help get the mob under control. The AI could also allow the slow to be overwritten if a bot has a better slow than what's currently on the mob (I assume this is how things work on live- I don't believe the second slow doesn't land because there's already a slow on.)


A possible example of healing/nuking presets: A cleric on Normal Nuking would only nuke when mana > 50%, Aggressive when mana > 25%, passive when mana > 75%. Hybrid healing: normal- heal when bot/player HP <25%, passive self heals only, aggressive- HP < 50%. (I would rather my hybrids heal than nuke- almost all hybrid nukes except those with stuns are horrible and terribly inefficient...).

I totally agree. That is the problem that I saw even when grouping. The current setup I think was added for simplicity and wide reaching needs.
So what kind of variable is loaded from the DB and kept in memory? My C++ isn't as developed as most of you. I think using your presets is a great idea.

Add columns to the bots table. Healing, DD, Slow, Debuff, Stun, Mez and then we can use a system similar to the slots (ie HEALING_AGGRESSIVE = 0) and use switch and case in the botspellsai. This would actually help in the long run for bot ai as I have begun to accept that the bots with a range of options don't seem to follow a set way of casting during combat. The casting order seems almost random at times.

There also need to be a place in the DB to store roles. Add columns to bots for MT, MA, etc : 0/1 and to avoid two MTs being loaded into a group have these settings reset to 0 when the bots camp. This will prevent any AI goofiness by accidentaly having two MTs in a group/raid.

Just some thoughts (pre coffee).

Criimson

EDIT:
AS I was outside drinking coffee and having a smoke it came to mind that this system could help add a CH rotation as well.
For raids/groups with more than one healer you could set them as CH1 CH2 and add into the casting of CH a send that sets a timer of however many seconds for the next healer in the roation to begin casting.
Example cleric CH1 begins casting send a signal to cleric CH2 that tells them to start then they send a signal to CH3, etc

Criimson 07-20-2011 07:23 PM

Another setting we need to add. AoE. I created a necro and had it grouped and mezzes kept breaking. I was like wtf are these pets going apesh*t or what? Then I looked at the log and saw my necro was AoEing a disease spell. I can see that sometimes AoE is nice, but it wasnt welcome at the time :)

I am liking the way mez is at now. Eventually when we work in a system for spell AI on a by bot basis we can have a switch for automez. As it stands now though the chanter is doing nicely...she bugged me before.

pfyon 07-20-2011 09:01 PM

I agree that roles are probably the next step, but disagree that they need to be infinitely customizable. I think for the average user, it would be sufficient to provide some basic roles (eg melee dps, ranged dps, healing, etc) with secondary roles (which could be the same as the list of primary roles).

Primary/secondary roles would just define the expected behaviour of the bot.

I think, if people want to be able to finely customize their bots' behaviour, it would be easier to just write a text only client which would run on the player's computer and allow people to write scripts for their own bots. We already have all the opcodes and knowledge of how the client communicates with the server, so it shouldn't be hard to write a client like this.

bad_captain 07-21-2011 12:25 AM

Quote:

Originally Posted by Criimson (Post 201606)
Another setting we need to add. AoE. I created a necro and had it grouped and mezzes kept breaking. I was like wtf are these pets going apesh*t or what? Then I looked at the log and saw my necro was AoEing a disease spell. I can see that sometimes AoE is nice, but it wasnt welcome at the time :)

I am liking the way mez is at now. Eventually when we work in a system for spell AI on a by bot basis we can have a switch for automez. As it stands now though the chanter is doing nicely...she bugged me before.

Do you know which spell it was? There shouldn't be any AOE spells in there, since there's no code to account for it. I had that issue once, but realized I gave my bot an AOE proc weapon. I was trying to figure out why I had a Thall Va Xekra coming through the wall at me and killing everyone..

Criimson 07-21-2011 12:42 AM

Quote:

Originally Posted by bad_captain (Post 201611)
Do you know which spell it was? There shouldn't be any AOE spells in there, since there's no code to account for it. I had that issue once, but realized I gave my bot an AOE proc weapon. I was trying to figure out why I had a Thall Va Xekra coming through the wall at me and killing everyone..

It is spell 365 Infectious Cloud and it is in the Necro bots spell lineup

Criimson 07-21-2011 12:46 AM

Quote:

Originally Posted by pfyon (Post 201608)
I agree that roles are probably the next step, but disagree that they need to be infinitely customizable. I think for the average user, it would be sufficient to provide some basic roles (eg melee dps, ranged dps, healing, etc) with secondary roles (which could be the same as the list of primary roles).

Primary/secondary roles would just define the expected behaviour of the bot.

I think, if people want to be able to finely customize their bots' behaviour, it would be easier to just write a text only client which would run on the player's computer and allow people to write scripts for their own bots. We already have all the opcodes and knowledge of how the client communicates with the server, so it shouldn't be hard to write a client like this.

I actually like bad_captains ideas about having presets. It allows customization (and keep in mind I would like to give some options to those that couldn't code Hello World in a GUI) without making it over complicated. After thinking about the "aggressive/passive/balanced/off" idea I began to see it as a nice way of allowing freedom and control without undue complexity for the average user.
This would also allow for a personal connection with the bots and encapsulate an individual players style in a given situation.

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?

blackdragonsdg 07-21-2011 02:02 AM

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 07-21-2011 03:25 AM

Quote:

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.

Quote:

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.

Quote:

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 07-21-2011 04:45 AM

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 07-21-2011 05:21 AM

Quote:

Originally Posted by Criimson (Post 201618)
...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 07-21-2011 01:08 PM

Quote:

Originally Posted by Congdar (Post 201619)
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 07-21-2011 03:00 PM

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 07-21-2011 06:32 PM

Quote:

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 07-21-2011 07:04 PM

Quote:

Originally Posted by Criimson (Post 201615)


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 07-21-2011 07:10 PM

Quote:

Originally Posted by Criimson (Post 201615)

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 07-21-2011 07:14 PM

Quote:

Originally Posted by Congdar (Post 201619)
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 07-21-2011 07:30 PM

Quote:

Originally Posted by bad_captain (Post 201648)
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:
Quote:

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 07-21-2011 08:18 PM

Quote:

Originally Posted by Criimson (Post 201653)
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 07-21-2011 08:37 PM

Quote:

Originally Posted by bad_captain (Post 201655)
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 07-21-2011 08:54 PM

Quote:

Originally Posted by bad_captain (Post 201647)
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 07-21-2011 10:04 PM

Quote:

Originally Posted by pfyon (Post 201659)
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.

blackdragonsdg 07-21-2011 10:06 PM

Quote:

Originally Posted by bad_captain (Post 201649)
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.

This raises another issue with AOE's....if you are checking your targets stats then you are only checking one target so what about the others? Your target could be more resistant to one specific resist type but the rest of the npc's could be getting hit by that spell. I bring this up because a common tactic for the Corinav event is to pull 20+ mobs into a small space then aoe nuke them to death.
If there is a way to do a resist check for all npc's in close proximity to your target then it would give a more realistic view of what spell needs to be used.

sorvani 07-22-2011 04:09 AM

I do not run bots but all your talking lately has me wondering. What purpose are bots going to service once the merc code starts coming in? Will some / all of the bot code be useful for that?

Burningsoul 07-22-2011 05:48 AM

Merc code is a hard guess at this point, if and when they're implemented. I (believe) Congdar was in charge of the mercs - Which after coding the bots and having people change/modify his code and run away, leaving him to pick up the pieces, is a tricky mess at best. I'd say don't worry about Mercs for now. Be happy these people have come together to discuss/implement changes to better the bots. Roll with it and be happy.

I've been watching EQEmu from its' inception WAY back, I'm honestly shocked how far it's come - from 4.4DR-1 TCSMyworld's DB releases (with MOVING(!?!) NPC's, to 5.7DR6 on the Scorp2k Server, and forward to working LDONs and countless other things. Things will happen in time, just help where you can.

bad_captain 07-22-2011 09:00 AM

Quote:

Originally Posted by Criimson (Post 201662)
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.

Check IsBotAttackAllowed(). I know it needs work, as I had a report of a bot's dire charmed pet attacking itself. I never got around to trying to figure it out. I made a couple changes in there before to allow bots to cast spells and bot pets to attack in the arena (I was trying to parse some stuff and they wouldn't attack the test dummies correctly).

bad_captain 07-22-2011 09:06 AM

Quote:

Originally Posted by sorvani (Post 201670)
I do not run bots but all your talking lately has me wondering. What purpose are bots going to service once the merc code starts coming in? Will some / all of the bot code be useful for that?

Wildcard had begun work on mercs, but has been missing sicne.

Quote:

Originally Posted by WildcardX (Post 192585)
Okay so now that the SoD client is getting supported, it seems now is the time to implement the merc system as the SoD client implements it anyway. Instead of doing a Bot 2.0 upgrade, I am going to rewrite the system again as I believe it is best for the code base in general if mercs are implemented and then bots inherit their functionality from mercs. So yes we will support mercs as consistent with eq live (I still maintain Sony stole the idea of mercs from this community...) and there will still be a bot system, but that bot system will be an optional system, as it is today and it will be built on top of mercs, instead of mercs built on top of bots and then dummied down some.

In a lot of ways, merc logic is very similar to bot logic as it is really a group only ai system.

Basically, mercs would be built in on top of the mob objects, created live-like, then bots on top of mercs (taking out merc only stuff such as upkeep and stuff, but adding in bot specific code, such as class specific code, raid support, etc.)

If anyone wants to take a look, there's a branch in the svn that he created for mercs and bots, but I'm not sure what if anything was done on it.

If we have any opcodes and such for some of the merc functions, I would be willing to try and get a working merc (but I'm sure it would take a while, as I don't have the most time in the world now). I'm just not sure I want to take the time to figure out how to do opcodes at the moment.

EDIT: I checked out the code, and it appears as if he just added a header file with constructor and destructor declarations.. lol

bad_captain 07-22-2011 09:43 AM

Quote:

Originally Posted by bad_captain (Post 201651)
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.

Quote:

Originally Posted by laxative (Post 180582)
Greets,

I just updated to the new BOT system. I understand and support the direction, but I'm already missing the:

#bot spawnraid
#bot groupraid

commands. Prior to the first revamp I had like 20 macros that setup my raid. That got streamlined to the #bot groupraid command.

Will I need to issue a stream of #bot botgroup macros to formulate a raid?

I'm also looking forward to guild'ing.

Will we have the ability to use Guild Favor with our Bots?

Thanks for the hard work.

Lax.

Quote:

Originally Posted by WildcardX (Post 180583)
So I thought about this feature long and hard. I really did. The way I see it, if you make a bot enabled server and give the players a feature that allows them to one click spawn an entire raid force of buff and bot ready bots and all strctured in their groups and a raid, didn't you just make a server of zerg-style raids? That was my principle thinking in not providing similiar commands.

I do get it though. The convenience of having similar commands. Perhaps in the future, maybe I or someone else can add it but include another BOT rule to regulate this feature..

I found it.. lol I'm not going completely crazy..

Congdar 07-22-2011 10:01 AM

There is a bot rule in place to activate a quest that makes acquiring bots tougher. Maybe he didn't know about this and thought you could just make 71 bots and go.

Congdar 07-22-2011 10:04 AM

RULE_BOOL ( Bots, BotQuest, false ) // Optional quest method to manage bot spawn limits using the quest_globals name bot_spawn_limit, see: /bazaar/Aediles_Thrall.pl

Congdar 07-22-2011 10:22 AM

The reason the convienence methods were made was due to the fact that making macros to spawn an entire raid almost used up all your available macro slots and you hardly had any left for #bot group attack commands etc. Either way you would still be able to get a bot raid force up with or without the newer macro.

Criimson 07-22-2011 11:11 AM

Quote:

Originally Posted by sorvani (Post 201670)
I do not run bots but all your talking lately has me wondering. What purpose are bots going to service once the merc code starts coming in? Will some / all of the bot code be useful for that?

Here is a good page on mercs

I didn't mess with mercs much after they went live as by this time I mainly played my necro because of time constraints. However, I think that a player only can hire one at a time which is why bots will still be useful. Now I am mainly thinking of players like myself that play solo, but I know I'd like to raid and such and from the merc page classes like enchanters aren't an option with the merc system. This leaves room for bots in the future.

------------------------------------------------------------
Anyone know of a page that lists raids and what size raid force is required? I would like the challenge of gearing up a 3 group raid force and tackling raids and only use 4+ group raids when neccessary. I definately don't like the idea of filling 7 groups with wizards and monks to zerg something and would rather slowly take on smaller raids for gear as I work my way towards larger scale raids.

--------------------------------------------------------------

I was wondering if someone with more experience in engine/spatial coding could look at the movement/spacing code for bots. I love the way angelox has hits bots spaced behind the player and x,y,z code is something I have no experience with.


All times are GMT -4. The time now is 01:52 PM.

Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.