Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Bots

Development::Bots Forum for bots.

Reply
 
Thread Tools Display Modes
  #1  
Old 07-19-2011, 09:05 PM
Criimson
Hill Giant
 
Join Date: Sep 2006
Posts: 172
Default

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.
Reply With Quote
  #2  
Old 07-20-2011, 10:09 AM
bad_captain
Developer
 
Join Date: Feb 2009
Location: Cincinnati, OH
Posts: 512
Default

Quote:
Originally Posted by Criimson View Post

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...).
Reply With Quote
  #3  
Old 07-20-2011, 02:16 PM
Criimson
Hill Giant
 
Join Date: Sep 2006
Posts: 172
Default

Quote:
Originally Posted by bad_captain View Post
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
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 09:51 AM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3