Playerbot

[Gitch]

Updated:

Pushed -> skillbot : Autoequip - new command, type /t botname or /p 'autoequip' . once to turn it on, again to turn it off if ya like.

bots will automatically upgrade their gear from the items they loot, based on 'itemlevel'.

the code is sloppy atm, I know enough about C++ to be dangerous.... thats about it.

Pushed ->skillbot : Fixed issue with bots forgetting to loot corpses if they are interupted by combat.

Please offer feedback, or even make changes to this if you see fit, just post your changes/ideas.

I'm certain there will be issues with autoequip, one of which is that I forgot to add a reply from the bots telling you whether its ON or OFF atm..

Ill add that in tomorrow along with some other updates to it!

Main focus: is it working at all for you. is it causing any major issues that need addressed?

At the moment its not precise, the bots are only comparing item level to decide whether or not to equip an item.

I'll tune that by adding some other conditions as it goes.

[Gitch]

@Kennumen,

Heya guy, yup, I opted for proto->itemlevel for comparison atm.

Sometimes they dont upgrade when it looks like an obvious choice lol, but it is working somewhat.

I have to go through the code now and pretty it up and sort things better. I went through a lot of different things

so I have some clean up to do.

I agree on using a config file setting. Would have done that, but not clear on how to yet, so I'll look into more.

I noticed 'gearscore' but didnt get in depth on it. It may be that it will help out.

there is a long list of fields to check for so it should work out great, even if it takes quite a few checks to really

make it more precise. (e.g. sellprice, armor, damages, stats(?), theres just a ton of diff checks that can be made.

The problem is figuring out the simplest, yet most efficient way lol.

anyway, I've had fun working on it, and learned a few things about the code in the process!

***Edit***

I also think this process will work for allowing/forcing the bots to sell more than just trash, like if they have a ton of items, allow them

to sell everything but their highest 2 level items, and even make it so that you can set the level diff that they will keep etc..

I'd say probably include a setting that will prevent them from autoequipping rare items etc (of course lol) so you can decide that

on your own (unless you want to let them have what they can ninja loot.. my priest is the ninja, hes always first with a full inventory)

[Nightterror]

I know its giong back a bit but did this ever get fixed?

Currently I got a small problem, when testing a simple Shaman Elemental script.

I found out, that the shaman is always going into Melee and not in to Ranged combat.

Even though I reconfigured the m_combatstyle in PlayerbotAI.ccp in PlayerbotAI::PlayerbotAI and in PlayerbotAI::ReloadAI.

Is there anywhere else configured that he should use COMBAT_MELEE over COMBAT_RANGED?

It couldn't find it

I fixed this rather crudely using a stat comparison where it sets to melee if agility is greater than int (holds for shaman and druid melee specs, at least for wrath)

Obviously there are drawbacks with this and it would be easier if it could be spec based

Is there a way to get the number of points in a tree?

I would like to do something like make it based on the highest so to allow for hybrid specs(as opposed to checking certain spells)

[blueboy]

Hi Gitch,

I'm currently testing your 'autoequip'

I first enabled it

/w ten autoequip

I then got my rogue bot to purchase a 'rogue deck' from the local auctioneer. I created a suitable 'darkmoon vest' (leather), but the rogue refuses to autoequip. It's certainly the best item he has and there are no restrictions (armour or level) preventing him from using it. One possiblity is that it is a 'bind when equipped' item. Does the code only work for ordinary items? , I haven't taken a closer look at the code yet so I can't comment

Cheers

[mookjin]

I know its giong back a bit but did this ever get fixed?

I fixed this rather crudely using a stat comparison where it sets to melee if agility is greater than int (holds for shaman and druid melee specs, at least for wrath)

Obviously there are drawbacks with this and it would be easier if it could be spec based

Is there a way to get the number of points in a tree?

I would like to do something like make it based on the highest so to allow for hybrid specs(as opposed to checking certain spells)

Unfortunately I don't know a way how to check which talent tree has the most points assigned.

But this will be the best way to check the specs.

I've done a workaround with checking if spells in the talent tree is available or not and then choose which rotation should be used.

This are the files I'm currently using:

playerbotmageai.cpp http://pastebin.com/C626yuAG

playerbotmageai.h http://pastebin.com/4nAweZRF

---

For me the Mage AI I've done feels good and plausible, and does quite good damage..

The only problem, in my opinion, is the one with the not appearing frostauras on the enemies..

By the way. Is the Spell "Blizzard" only bugged on my server or on yours also?

[Gitch]

@blueboy,

Its buggy. After you type autoequip, the next time the bot loots an item it 'should' equip its best equipment from inventory.

At the moment it doesnt do it imediately on trade etc. Just on 'looting'. The Item level comparison is just a temp one.

There may also be a problem with calling it from loot_release_response, I'll take a look when I get home. I wound up

adding a few more things last night after I pushed.

Sorry for the buggyness .

The code is only checking for can_equip, and itemlevel. Anything that shows up in the "I can equip the following items" during 'inspect', the bot should be able to autoequip.

But again, for now, its only called when they loot, and the loot_release_response is triggered. Tonight I'll add a snippet to the bot trade w/player section and call it from there

as well when the trade is over.

Try killing some low level critter or something that has loot, and see if they equip it when they loot the corpse.

I have a few minutes atm , so I'm adding some debug responses from the bot and will push this shortly after I test it:

1.) when you type 'autoequip' you SHOULD get a msg "autoequip is now ON" or if its on already, it will say its "...now OFF"

2.) when the bot loots a corpse it SHOULD now send a msg that "..AutoUpgradeEquipment is being called"

3.) If number 2 was sucessful, you SHOULD get a msg that says " Starting AutoUpgradeEquipment Function"

This may help track down quite a few problems.

going to test this quickly and push it. Will test more thoroughly tonight.

Thanks guys for trying it out!

p.s if you do look into the code, I'll warn you its not pretty yet, and It needs to be simplified still.

[blueboy]

Sorry for the buggyness

No at all, the work is in development and you would expect issues. Sorry, I didn't understand the scope of the command (only for looting). I did try including the call code

if (AutoEquipPlug == 1 )

{

Player* const bot = GetPlayerBot();

AutoUpgradeEquipment(*bot);

}

in both TRADE_STATUS_TRADE_ACCEPT (item received through trade) & SMSG_ITEM_PUSH_RESULT (item created, bought or generally received)handlers in PlayerbotAI.cpp and I found something interesting on trading. The item appears to be equipped and then unequipped. The darkmoon vest is no longer 'bind when equipped' but is now soulbound.

EDIT@ I can confirm that my hunter auto-equipped a pair of gloves after looting

No hurry, everything is relaxed here, only do work when you want. Drive safely

Hope this helps

[Gitch]

@blueboy,

"The item appears to be equipped and then unequipped. "

Thank you!!

Yes, That does help! Obviously they made another check that I didnt intend (checked twice like santa claus) I'll need to check the conditions.

***EDIT #2***

I've found the problem guys, sorry, its my coding. I've got a section of useless code thats causing issues.

I'm working on it. Some of these functions I was guessing at.. I'm learning lol

Oh and blueboy, your report about the item equipping and unequipping led me to it. Thanks!

***Edit again***

Okay, Last of the compile errors taken care of... sheesh (if it just didn't take so long to recompile heh)

I scrapped the code I used initially, and rethought things.. I think for the better (and a whole lot simpler)

The way it was, it was mere chance if it actually compared two items of the same slot type... geez

running some more tests and looking at more comparisons. I keep running across functions and getting

sidetracked with ideas lol. Will push when stable.

[blueboy]

sheesh (if it just didn't take so long to recompile heh)

The code your recompiling doesn't contain ScriptDev2 code too, does it. When I'm doing development work, I leave that out and the code recompiles much quicker. It's a pain when you edit header files because the compiler will insist on a complete rebuild. Just a thought

[Gitch]

The code your recompiling doesn't contain ScriptDev2 code too, does it

No it doesn't, but I agree on editing header files..

Anyway, its looking up now, and I still have some hair left haha.

Still debugging some problems

[Nightterror]

For me the Mage AI I've done feels good and plausible, and does quite good damage..

The only problem, in my opinion, is the one with the not appearing frostauras on the enemies..

By the way. Is the Spell "Blizzard" only bugged on my server or on yours also?

That does seem to work quite nicely

(though it took me a while to realise they had to be on assist to do anything, lol)

For me my mage kept evocating at high levels of mana? shouldnt this line

if ( EVOCATION > 0 && ai->GetManaPercent() >= 10 && !m_bot->HasSpellCooldown(EVOCATION) )
       {
           ai->CastSpell(EVOCATION);
       }

be less than 10?

Its also done again in non combat actions(with a different mana %)

Regarding blizzard, it seemed to work fine for me, at least when I manually tell the mage to cast it

The only other major thing I had with the mage ai is they don't conjour the appropriate level food/water

[Gitch]

UPDATED: AutoEquip Pushed to branch skillbot

Now works with loot AND trade. Bots will auto equip an item they loot, or that is given to them in trade, if its better than they have equipped. See below for the comparisons

being made at the moment.

1.) type /t botname 'autoequip' - Sets That individual bot to autoequip when they loot OR TRADE with player, if the item is better than they have equipped already.

2.) type /p 'autoequip' - Same thing as above except it flips the switch for ALL bots. IF you have set bots individually, it will flip their switch to the opposite you already had

it set to. (e.g. 1 bot had autoequip turned on by /t botname autoequip, and you then type /p autoequip, that bot will be turned off, while the others turned on.)

3.) Bots will whisper in reply to 'autoequip' command either saying its ON, or OFF.

4.) remember, typing it again, flips the switch to on or off, depending on previous setting.

5.) AutoEquip defaults to OFF if you log a bot out (or you log out) for that particular bot(or all bots if you log out the master character)

6.) Bots will use the following comparisons to decide if they should equip a new item:

does the item have a higher itemlevel?

if so, does it have an equal or higher armor rating?(for weapons, will be equally 0)

Then equip it.

Is the itemlevel equal?

if so , does it have a higher quality rating?

If so, does it have the same or higher armor rating? (IF it has NO armor rating (i.e. weapon or jewelry etc) it will be equal. if its less, we dont want to equip it, no warriors with robes on!)

Equip it.

thanks for your patience guys, please offer feedback.

**Edit 1.0**

Thanks Blueboy! - Added condition when calling autoequip from a trade. Autoequip was ON all the time for trades. Fixed.

Also tidied up code somewhat, (thanks blueboy for sharing some tips on that as well!).

Once we know this foundation is sound enough, we can add checks for stats/resists etc. for particular classes.

[mookjin]

if ( EVOCATION > 0 && ai->GetManaPercent() >= 10 && !m_bot->HasSpellCooldown(EVOCATION) )
       {
           ai->CastSpell(EVOCATION);
       }

be less than 10?

Its also done again in non combat actions(with a different mana %)

Regarding blizzard, it seemed to work fine for me, at least when I manually tell the mage to cast it

The only other major thing I had with the mage ai is they don't conjour the appropriate level food/water

Thanks for testing nightterror!

I will have a look at these problems. I don't think it shouldn't be to hard to figure it out.

Blizzard is channeling on your server?

Hm.. Then there must be another problem with the blizzard on my server..

[blueboy]

Hi Gitch,

Problems. After about ten minutes play the server crashes. I have checked this several times. It looks like it might be connected to 'autoequip'

I have a snippet of the crash log that I hope will help. I does look like a NULL pointer error.

#0 0x0853f2c0 in Object::GetUInt32Value (this=0x0, index=3)

at /home/mangos/wow/playerbot/source/portal/src/game/Object.h:183

__FUNCTION__ = "GetUInt32Value"

__PRETTY_FUNCTION__ = "const uint32& Object::GetUInt32Value(uint16) const"

#1 0x08551003 in Object::GetEntry (this=0x0)

at /home/mangos/wow/playerbot/source/portal/src/game/Object.h:146

No locals.

#2 0x0862d5e3 in Item::GetProto (this=0x0)

at /home/mangos/wow/playerbot/source/portal/src/game/Item.cpp:568

No locals.

#3 0x0867423d in PlayerbotAI::AutoUpgradeEquipment (this=0xa07be600)

at /home/mangos/wow/playerbot/source/portal/src/game/playerbot/PlayerbotAI.cpp:557

pItem2 = 0x0

pProto = 0xac5fc078

pProto2 = 0xac5cb3e8

it =

itemListForEqSlot = 0xa7717f00

equipSlot = 15 '\\017'

GitOldMaxValue = 5

GitNewQuality = 1

GitNewArmor = 10

equip = {0x0, 0x0, 0x0, 0x0, 0x0, 0xa7717f30, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,

0xa7717f00, 0x0, 0x0, 0x0}

GitNewMaxValue = 10

GitOldQuality = 1

GitOldArmor = 19

#4 0x086775b0 in PlayerbotAI::HandleBotOutgoingPacket (this=0xa07be600, packet=...)

at /home/mangos/wow/playerbot/source/portal/src/game/playerbot/PlayerbotAI.cpp:1475

bot = 0xa0a3e080

p = {<ByteBuffer> = {static DEFAULT_SIZE = <optimized out>, _rpos = 4, _wpos = 4,

_storage = std::vector of length 4, capacity 4 = {4 '\\004', 0 '\\000', 0 '\\000',

0 '\\000'}}, m_opcode = 288}

status = 4

possibly a trap for !pItem2 here,

Item* const pItem2 = m_bot->GetItemByPos(INVENTORY_SLOT_BAG_0, equipSlot);

if(!pItem2)

continue; // or return;

ItemPrototype const *pProto = pItem2->GetProto();

Hope this helps

[Gitch]

if(!pItem2) continue;

I must have deleted that in changing things around last night.. Thanks for pointing it out! :8

For now, if a bot wins the roll on an item , or receive it as quest reward, it will not equip it (if its better) until he loots or is traded something. Minor issue, I'll look at it later.

**Edit**

Fixed this, and added some options for 'autoequip' command.

I've made changes and will be pushing shortly as soon as I have it compiled/tested.

Let me know guys which way you prefer to have this. At the moment we have the following options for using the 'autoequip' command:

/t or /p 'autoequip' - toggles the bot or party to ON or OFF depending on their current setting.

/t or /p 'autoequip on' - turns one bot, or all bots in party to definite ON setting.

/t or /p 'autoequip off' - turns one bot, or all bots in party to definite OFF setting.

If bot dies, autoequip resets to OFF

**EDIT 3.0**

Pushed these changes to branch skillbot

@blueboy By the way, taxis are working fine for bots.. not sure what caused the problem I had before but was probably quest related (first time quest for night elves).

**EDIT 4.0**

Found a significant error in code, causing very random choices on equipping loot.

Will push a fix soon.

[Nightterror]

Hey guys,

I just pushed a new method that returns the spec of the bot based on the talent tree with the deepest talent

It works based on the talent tiers which was about as good as I could get it to allow for hybrd specs

The code works as follows:

//Class Spec numbers(return values) for testing/whatever (temporary, will update each class with enums or something)

//WARRIOR: 161 ARMS, 163 PROTECTION, 164 FURY

//PRIEST: 201 DISCIPLINE, 202 HOLY, 203 SHADOW

//SHAMAN: 261 ELEMENTAL, 262 RESTORATION, 263 ENHANCEMENT

//DRUID: 281 FERAL, 282 RESTORATION, 283 BALANCE

//MAGE: 41 FIRE, 61 FROST, 81 ARCANE

//DEATH KNIGHT: 398 BLOOD, 399 FROST, 400 UNHOLY

//HUNTER: 361 BEASTMASTERY, 362 SURVIVAL, 363 MARKSMANSHIP

//WARLOCK: 301 DESTRUCTION, 302 AFFLICTION, 303 DEMONOLOGY

//PALADIN: 381 RETRIBUTION, 382 HOLY, 383 PROTECTION

//ROGUE 181 COMBAT, 182 ASSASSINATION, 183 SUBTELTY

uint32 Player::GetSpec()

{

uint32 row = 0,spec = 0;

//Iterate through the 3 talent trees

for (uint32 i = 0; i < 3; ++i)

{

for (PlayerTalentMap::iterator iter = m_talents[m_activeSpec].begin(); iter != m_talents[m_activeSpec].end(); ++iter)

{

PlayerTalent talent = (*iter).second;

//If current talent is deeper into a tree, that is our new max talent

if (talent.talentEntry->Row > row) {

row = talent.talentEntry->Row;

//Set the tree the deepest talent is on

spec = talent.talentEntry->TalentTab;

}

}

}

//Return the tree with the deepest talent

return spec;

}

As you can see the return values are based on dbc so the numbers are annoying (i'm also not sure if they will hold for vanilla/bc)

I still think this could be quite useful

If anyone finds anything wrong with it please let me know

[Gitch]

Updated AutoEquip:

Changed the way the comparisons were being made for better accuracy of choice.

Bots will now autoequip after receiving quest rewards (still working on loot from winning a loot roll)

Bots will now autoequip items if the equipment slot is currently empty (weren't before)

Bots will also autoequip items given to them using the '.add [item]' command (could come in handy for autonomous bots?)

Pushed to branch skillbot.

[blueboy]

Hi Gitch,

The code is working well and it is understood that the current item comparison is still only at the early stages of developement. The factors to consider in item comparison are too numerous to list and from a human point of view it can be purely personal preference that you can't measure.

I haven't had a chance to try out your changes yet, but last night I was looking item comparison for weapons. The issue here being; which is better (for say a warrior to use), a sword or a dagger. By far the most important factor here would be DPS and or possibly skill level (i.e. User can train the bot with the preferred weapon type) or bot Class (i.e Rogue would be better off with a dagger). Item level on it's own leads to unexpected results

Initially equipped with

[brushwood Blade]

One-Handed Sword

11-21 Damage

5.3 damage per sec

+1 Stamina

Speed 3.00

(Wowhead has this listed as a level 10 item)

Autoequip insists on equpping him with

[Fiisherman's Knife]

One-Handed Dagger

4-8 Damage

4.3 damage per sec

Speed 1.4

Requires Level 9

(Wowhead has this listed as a level 14 item)

Cheers

[kennumen]

The factors to consider in item comparison are too numerous to list and from a human point of view it can be purely personal preference that you can't measure.

... Yes and no. Statically speaking it's easy to figure out which item is best for a given class + talent spec. Dynamically speaking it would be difficult to factor in future set items (i.e. this item is slightly worse but a likely future set would significantly boost this one item - you just don't have the other set item(s) yet), or also to use a slightly worse but more focused item (say +50 hit) over a better, more spread item (say +30hit, +30crit) because another item's upgrade might 'cap' (wow has a maximum for statistics, where any extra stats are useless - in this example, we'd be trying to foresee a +crit cap).

There are people on the WoW forums who do nothing but theorycraft, figuring out the best combination of equipment, stats, cap limits, etc... The big problem is finding this data for WoW 3.3.5a. A lot of what I mention above is applicable to level 80s, but there are sub-80s hierarchies of stats as well - sub-80 and 80 are slightly different, as I recall +hit is more or less ignored sub-80, and so on.

Item level on it's own leads to unexpected results

Good job finding an actual example. Another one might be a warrior using a +70 spirit item over a +20 sta, +30 str one. But like you said, autoequip is still in its infancy as far as ideal selection goes - itemlevel is the best attribute when using only one and a great starting point. I, like you, have no doubt Gitch realizes this imperfection and will soon get to work on it

Blueboy does make a solid point that for weapons, DPS is more or less the main attribute for melee characters. (... although in some situations speed is also very significant - slow (high) = better for pvp; pve rogues with the right talent spec would seek out the fastest weapons if they depend on per-hit triggers). Yeh, it's anything but simple. Seriously, we could really use some archived 3.3.5 theorycrafting

[Gitch]

Haha! Thats too funny. Thanks for sharing that! I laughed out loud :lol:

Before last night, my hunters kept insisting they wear that robe with a higher itemlevel than their Leather Vests with higher armor level...

Itemlevel is only the first check now, if its higher item level, it has to pass quality and armor check (yeah weapons can pass right through this one)

I'll locate a few good basic comparisons for weps to start it off. (I like the suggestion of DPS.)

One problem is deciding in which order to make certain checks.. it was pretty easy to come up with the basic

especially for armor items. I'm going to setup a test server just for testing this stuff.

**question**

Along with autoequipping, I thought about looking at having bots auto *drop* certain trash if their inventory was full, to always

have 1 or 2 slots open in case something they really could use dropped. Thoughts?

I've noticed some odd choices too, but if this happened previous to the last push, then I know why it happened.

The manner that I was setting, checking, and resetting variables was so wrong, I don't see how any decision was

being made at all.

It was (before last push) doing the following , and I think you'll recognize having seen this happening:

if newitemlevel > olditemlevel

equip new item

set olditemlevel to newitemlevel

...okay, fine,, except I followed this with another check..Not thinking!

if newitemlevel = olditemlevel

but newitem is better than olditem

equip new item

There was more to it than this, just an example of what was happening.

this , if I understand the function right, caused the item to meet two different conditions, and so the bot equipped the item, and then equipped the same item again, which UNequipped it. While it may not have happened every time,

(and I can't see why it didn't) it happened sporadically.

I removed the code which set the variables to equal after equipping.. there was no need as it would automatically recheck them

in the loop and set them accordingly.

Thanks for bringing this up, Weapons and possibly accessories, are going to need more in depth comparisons to figure out.

You're both right in pointing out that some items have a higher itemlevel, yet are trash in all but maybe a tradeskill use (but not fit for combat )

@Kennumen, I'm still looking at gearscore too, to see if it might be useful in this.

Things 'SHOULD' be more appropriate after last nights push, but I've already seen (and so have you obviously ) items that require a bit more

stopgate work.

Was hoping to have more checking included last night, but I got sidetracked figuring out the best places to call autoequip from for quest turnins and

won item loot.

Then got distracted because I realized the bots don't list all the items they could sell from their backpacks and I chased after a cure for that lol.

Anyone else have an issue with that? If not, its the bags I use (huge brown sack).

Okay, back to topic, due to storms yesterday, theres not much else I can do today than tinker, so I'm looking at the code now.

[blueboy]

Hi Gitch,

Like I said in my previous posts, I have been looking at choice of weapons with autoequip. I'm not sure whether this will help, but it seems to work well on my server. Regardless of the type and quantity of weapons in the bot's inventory, it will equip the bot with the weapon having the highest DPS. I found that only the first highest DPS item was being equipped from the item list. By assigning 'pProto2' item prototype pointer to 'pProto' solved this. The use of the 'item class' switch statement stopped the weapon and armour comparison code from conflicting. I also included an InspectUpdate() at the end of AutoUpgradeEquipment() to refresh the inspect window if it just happens to be open during the equip process.

// DEBUG_LOG("Item Class (%s)",(pProto->Class == ITEM_CLASS_WEAPON ? "Weapon" : "Not Weapon"));

switch (pProto->Class)

{

case ITEM_CLASS_WEAPON:

{

// DEBUG_LOG("Current Item DPS (%f) Equippable Item DPS (%f)",pProto->getDPS(),pProto2->getDPS());

// m_bot->GetSkillValue(pProto->RequiredSkill) < m_bot->GetSkillValue(pProto2->RequiredSkill)

if (pProto->getDPS() < pProto2->getDPS()) // if new item has a better DPS

{

EquipItem(*it);

pProto = pProto2; // ensure that the item with the highest DPS is equipped

}

break;

}

case ITEM_CLASS_ARMOR:

{

if (GitNewMaxValue > GitOldMaxValue && GitNewArmor >= GitOldArmor) // itemlevel

{

I promise that I won't interfere again, sorry :8 I just love your 'autoequip' idea and wanted to help.

@nightterror Great idea of yours to toggle MELEE and RANGED modes in the AI. I'm testing this at present too.

Cheers

[Gitch]

@blueboy,

I could only click the thank you button once, or I would have spammed it a few times!

I've been working on the exact same thing, and I love the way you did it!

I promise that I won't interfere again, sorry ops

I hope you don't keep that promise! 8)

My C++ knowledge is very little. I need all the help I can get.

Adding your code into mine. Working on some checks by class type (caster/melee) it will be basic to begin with.

I've been digging through the itemstattypes and have some other ideas for tests as well.

This list may not be very useful , if any use at all, but It helps me keep track ...

thought I'd post it if anyone else might find use for it.

item stat types and their value

useful snippits to use with item types

uint32 statType = 0;       
int32  val = 0;         
statType = proto->ItemStat[i].ItemStatType;        
val = proto->ItemStat[i].ItemStatValue; 

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

0- mod mana

1- mod health

3- mod agility

4- mod strength

5- mod intellect

6- mod spirit

7- mod stamina

12- mod defense

13- mod dodge

14- mod parry

15- mod shield block rating

16- mod hit melee

17- mod hit ranged

18- mod hit spell

19- mod crit melee

20- mod ranged critical strike

21- mod crit spell

22- mod hit taken melee

23- mod hit taken ranged

24- mod hit taken spell

25- mod crit taken melee

26- mod crit taken ranged

27- mod crit taken spell

28- mod haste melee (attack speed, 'speed' in character melee stats tab)

29- mod haste ranged(ranged attack speed, 'speed' in stats tab)

30- mod haste spell(spell casting speed, 'haste'in character spells tab)

31- mod hit rating(overall)

32- mod critical strike rating(overall)

33- mod hit taken(overall)

34- mod crit taken(overall)

35- mod resilience rating

36- mod haste rating ( mods melee, ranged and spell haste)

37- mod expertise rating

38- mod attack power

39- mod ranged attack power

43- mod restore mana 'mana amount' every 'x seconds'

44- mod armor penetration rating

45- mod spell power

47- mod spell penetration

48- mod block value

deprecated item mods:

40- mod feral attack power

41- mod spell healing done

42- mod spell damage done

[Gitch]

@blueboy,

I want to thank ya again for posting that change, I can see so many changes I need to make in code, doing that now.

all the variable definitions and conditions I've been doing from my scripting knowledge..

It can be sooo much simpler.. thanks for the lesson! and by all means, if any of you see changes that should be made,

Please do. for me this is as much about working together as it is learning (and having a dance in the office when it works like it should!!)

**Edit**

Need some opinions... I'm looking at adding checks for item stats. I need input on what to check and what importance to put on that stat for caster/melee.

I've posted the item stats list above in previous post.

As blueboy has found out, DPS will rule mostly for weapons for melee(will check whether bot is melee or caster as casters dont need the DPS)

I really don't want to check every single stat .. any ideas which ones would be good to focus on?

@blueboy,

Mind pushing what you have on this?

[kreegoth]

Well the problem your going to encounter with that is the same as is encountered with the AI itself. Not everyone plays the characters or the bots the same.

For instance It is conceivable that you could implement a code such as checking players class. For example Warriors would MOST often be interested in getting Ac and Stamina but if they are fury specd they would want Attack and Agi/Str (I believe.. <--- Does not play DPS warr)

So you may have to insert a code that behaves as combat orders does where you can set Loot type DPS or TANK or HEAL

Which means alot more work. But you could say if LootOrders= Tank then If class = 1 then compare items and take item with most AC and Stamina

But if lootOrders= DPS then Take item with most Agi/Str and Attack.

Perhaps it could be simplified I dont know.

But with a single check for whether the item is improved it will impossible to appease everyone.

I wonder how if you could take a look at the code that works for the addon that compares the gear and shows green for improvements and red for minus's, Then base a code that uses that to choose which item. Something like if more of the Stats are green in the comparison it takes that item.

I dont know just rambling lol.

[Gitch]

@Kreegoth,

I LOVE the idea of being able to set type by a command like combat orders....

Would really help I think.. instead of trying to make the bots figure it out, YOU can set the type of gear they aim for...

Really, thanks Kreegoth

Am also going to play with auto settings, for autonomous bots for things like arena, mercs, etc.

BTW I have the code in place for checking class at the moment, working on tweaks, new code, new checks..

Probably won't push again until I have a good stable version of the new checks in place.

and now your ideas have tossed a whole new ball of wax into the soup.. This could get big haha.

@Blueboy,

I've added your code addition and am reformatting my own lol.

Should have something ready to push later tonight with some new basic checks to try out.