blueboy

Hi hurrensohn,

Thanks for the heads up on the portalone repo. There wasn't much activity with core changes, so I didn't bother updating the repo. I have now done so and all merge errors are fixed.

Hope this helps

I suppose it's complicated to merge remote branch 'origin/master' into sharedbots ? Because I see the sharedbots branch has not been updated since 9 february.

I'm gonna try the botguy and let you know.

merge remote branch 'origin/master' into sharedbots, done...

Hope this helps

I only tried the commandline, never used the botguy (don't have it in my version).

Is there a way to see what files exactly have been modified by playerbot ? Like the "compare" feature of Github, which, as far as I know, can't compare two repos.

As far as I know the compare feature on github will compare the code on each sub-branch with that on the master. If for instance you compare the sharedbots branch with the portal master, you will get a snapshot of the sharedbots patch. I hope that makes sense

Cheers

Hmm that strange. I called a bot A from my account, then a bot B from another account, and then a bot C from my account. It worked.

Have you tried summoning bots from the commandline and via 'botguy' ? I seem to remember it worked the one way, but not the other. I would be interested to know if it works for you?

Cheers

Hmm that was not really my point but anyway, thanks (I have conflicts with shared bots)

By the way, couldn't it be possible to have shared bots with all branches ? as you can activate/deactivate it in the conf anyway.

I'm a little puzzled In your first post you wanted to include 'talent spec' code in your existing playerbot. You didn't mention that you were using sharedbots. The current sharedbots branch includes the 'talent spec' code. Have you tried just merging the current sharedbots branch into your code. If you get any conflicts, I will do my best to resolve them for you.

@Edit

Are these the only lines I need to add to have the "sharedbots" enabled ? That'd be great... but too easy I guess

Yes this is the part of the sharedbots patch that enables the code, based upon the playerbot.conf setting. Remember to follow

Sharing bots across accounts:

======================

It is possible to a load a bot from another account. This must be done by a player from a second account adding the master player to their friend's list and set a note with the keyword 'shared' on that player. After it is setup the bot can be added using either the botguy menu or the .bot add command if enabled.

Example: Frank and Bob are characters owned by different accounts. Bob would like to use Frank as a playerbot. Frank must add Bob as a friend then right click on Bob in the friend's list, click Set Note, then type 'shared'. Frank would not be able to use Bob as a playerbot until Bob setup Frank as above.

The reason it isn't included in all the branches yet is because it's still buggy. Although you can load bots from other accounts, it then refuses to load bots from your own account I did find a fix for this, but it was thought to cause a security issue so wasn't implemented.

Hope this helps

Hi Blueboy,

thanks for your quick reply and confirm about the spell casters' bug. In aditional I tried to make the autobot enabled, but when I type for instance ".autobot add worldpvp dps", it seemed like it automaticly adds a random bot with a success report. Howerver I couldn't find any bots from player list nor in area around my character. when I check the character database, I found those bots were successfully added into a specifc account which GM level is player.

I am totally lost to make autobot system work. Thanks in advance if some1 could enlighten me a bit.

Yeah the autobot code is a 'work in progress' and I'm not sure whether it is operational yet. The best person to speak to would be kennumen, as it's his code.

Hope this helps

Noobish question : I have compiled an old version of playerbot, but I'd like to add the feature "/t BOTNAME talent spec", which I currently don't have. What files would I need ? Is there a simple way to do that without to spend a night to understand errors and merge conflicts ?

The talent spec code is available in all playerbot repos. Here is the read_me for our release code, that holds our oldest active code. Depending on how old the version of playerbot is and it's source, you shouldn't get any merge conflicts. As a demonstration I have merged the alpha branch 'new-ai' into our release code without conflict. Here is the script,

#!/bin/bash -x

git clone git://github.com/mangos/mangos.git playerbot

cd playerbot

git fetch git://github.com/playerbot/mangos.git master:portal

git fetch git://github.com/blueboy/portal.git new-ai:new-ai

git checkout portal

# git merge new-ai

Merge made by recursive.

bot_readme.txt | 41 +-

src/game/Player.h | 4 +

src/game/playerbot/PlayerbotAI.cpp | 1942 +++++++++++++++++++++----

src/game/playerbot/PlayerbotAI.h | 93 ++-

src/game/playerbot/PlayerbotDeathKnightAI.cpp | 1 -

src/game/playerbot/PlayerbotDeathKnightAI.h | 64 +-

src/game/playerbot/PlayerbotDruidAI.cpp | 799 ++++++-----

src/game/playerbot/PlayerbotDruidAI.h | 17 +-

src/game/playerbot/PlayerbotHunterAI.cpp | 13 +-

src/game/playerbot/PlayerbotMageAI.cpp | 1 -

src/game/playerbot/PlayerbotMgr.cpp | 98 +-

src/game/playerbot/PlayerbotPaladinAI.cpp | 39 +-

src/game/playerbot/PlayerbotPaladinAI.h | 4 +-

src/game/playerbot/PlayerbotPriestAI.cpp | 86 +-

src/game/playerbot/PlayerbotPriestAI.h | 3 +-

src/game/playerbot/PlayerbotRogueAI.cpp | 2 +-

src/game/playerbot/PlayerbotShamanAI.cpp | 553 +++++---

src/game/playerbot/PlayerbotShamanAI.h | 128 ++-

src/game/playerbot/PlayerbotWarlockAI.cpp | 1 -

src/game/playerbot/PlayerbotWarriorAI.cpp | 16 +-

20 files changed, 2878 insertions(+), 1027 deletions(-)

# git status

# On branch portal

nothing to commit (working directory clean)

N.B. If you are trying to merge our code into the code used on R2, there are guarantees that you won't get some merge conflicts.

@Edit If for instance you are using a very old version of playerbot, I would recommend that you build fresh. If it's recent code, after the merge;

linux;

Re-run cmake, before running make

Windows;

Rebuild the project using the *.sln file

Hope this helps

Hi blueboy,

followed by your last update post, I successfully integrated playerbots into my server, everything looks fine, but I noticed a bug from my spell caster bots, when I duel a spell caster or team with spell caster to fight mobs, the caster can cast all spells which need cast time instantly. e.g mage bot cast fireball without cast time, priest casts heal instantly. But when I logged in my mage or priest character, all those spell cast correctly based on their talent or Glyphs.

So is it a general bug so far or only my error.

Thanks for the info. I believe this is a real problem. Briefly looking at the AI for Mages,Warlocks,Priests, etc it is clear that the spell sequence (rotation) for duels is still quite primative.

e.g PlayerbotMageAI.cpp

switch (ai->GetScenarioType())

{

case PlayerbotAI::SCENARIO_DUEL:

if (FIREBALL > 0)

{

ai->CastSpell(FIREBALL);

ai->SetIgnoreUpdateTime(3);

}

return;

}

So mage attack will be a steady stream of fireballs, with no disernible break between each cast. For non-duel attack, the spell rotation is more elaborate, so there will appear to be a reasonable delay between each fireball.

It's agreed that there needs to be more work done on developing AI for duel combat. As a temporary solution you might try including a small delay in the AI to slow things down a bit (In green). One issue I have noticed while messing about with arenas was that warlock pets are unattackable with 'Phase Shift'. This is also true for duels, so it would be appropriate to disable this aura, while in these scenarios.

If it works, you can apply it to the other AI. Either way, I would like you to let me know how you get on

Hope this helps

hmm oke now i tried even the wiki guides but im just too dumb to manage with it...but mabye if anyone have a bit time and help me out with full patch file ....i tryed to make it myself but command had some keys in it what i cant find on my keyboard...mabye anyone can get full playerbot patch what have all sharebots,chatbot and so on in it...

i will be very thankful:d

A full patch to include all developemt code is not possible. You'll either have to be patient until such time when we merge the develpment code, or do the merge directly as Gitch suggests. I have created a small bash script to facilitate a multiple merge. You will still need to resolve some minor conflicts, but these are very simply fixed.

bash script

#!/bin/bash -x
git clone git://github.com/mangos/mangos.git portal
cd portal
git fetch git://github.com/blueboy/portal.git master:portal
git fetch git://github.com/blueboy/portal.git skillbot:skillbot
git fetch git://github.com/blueboy/portal.git new-ai:new-ai
git fetch git://github.com/blueboy/portal.git autobot:autobot
git checkout master

# cd portal

# git branch

autobot

* master

new-ai

portal

skillbot

We will first switch to the portal branch.

# git checkout portal

Switched to branch 'portal'

then..

1. new-ai merge

# git merge new-ai

Auto-merging src/game/playerbot/PlayerbotAI.cpp

Merge made by recursive.

src/game/playerbot/PlayerbotAI.cpp | 31 ++-

src/game/playerbot/PlayerbotAI.h | 14 +-

src/game/playerbot/PlayerbotDeathKnightAI.h | 64 +++-

src/game/playerbot/PlayerbotDruidAI.cpp | 2 +-

src/game/playerbot/PlayerbotShamanAI.cpp | 524 ++++++++++++++++-----------

src/game/playerbot/PlayerbotShamanAI.h | 128 +++++++-

6 files changed, 527 insertions(+), 236 deletions(-)

2. skillbot merge

# git merge skillbot

Auto-merging src/game/playerbot/PlayerbotAI.cpp

CONFLICT (content): Merge conflict in src/game/playerbot/PlayerbotAI.cpp

Automatic merge failed; fix conflicts and then commit the result.

To fix this conflict, open PlayerbotAI.cpp with your text editor and search for the pattern HEAD

i. PlayerbotAI.cpp

<<<<<<< HEAD

HERB_GATHERING = initSpell(HERB_GATHERING_1);

MINING = initSpell(MINING_1);

SKINNING = initSpell(SKINNING_1);

=======

HERB_GATHERING = initSpell(HERB_GATHERING_1);

MINING = initSpell(MINING_1);

SKINNING = initSpell(SKINNING_1);

>>>>>>> skillbot

ii. PlayerbotAI.cpp

<<<<<<< HEAD

=======

// return true;

>>>>>>> skillbot

Remove the text in red and save. To apply the merge after fixing the conflicts

# git commit -a

Your default text editor will open giving you the opportunity to change the commit header. For simplicity, just save the file and your done.

3. autobot merge

# git merge autobot

Removing sql/playerbotai/playerbotai_characters_r1.sql

Auto-merging src/game/playerbot/PlayerbotAI.cpp

Auto-merging src/game/playerbot/PlayerbotAI.h

Auto-merging src/game/playerbot/PlayerbotMgr.cpp

Auto-merging src/game/playerbot/PlayerbotMgr.h

Auto-merging src/game/playerbot/config.h

CONFLICT (content): Merge conflict in src/game/playerbot/config.h

Auto-merging src/game/playerbot/config.h.in

CONFLICT (content): Merge conflict in src/game/playerbot/config.h.in

Auto-merging src/game/playerbot/playerbot.conf.dist.in

CONFLICT (content): Merge conflict in src/game/playerbot/playerbot.conf.dist.in

Automatic merge failed; fix conflicts and then commit the result.

You will see that there are three files causing conflicts. Repeat the process described for merge 2.

i. config.h

<<<<<<< HEAD

#define PLAYERBOT_CONF_VERSION 2012021401

=======

#define PLAYERBOT_CONF_VERSION 2011112001

>>>>>>> autobot

ii. config.h.in

<<<<<<< HEAD

#define PLAYERBOT_CONF_VERSION 2012021401

=======

#define PLAYERBOT_CONF_VERSION 2011112001

>>>>>>> autobot

iii. playerbot.conf.dist.in

<<<<<<< HEAD

ConfVersion=2012021401

=======

ConfVersion=2011112001

>>>>>>> autobot

<<<<<<< HEAD

PlayerbotAI.SellAll.LevelDiff = 10

=======

line space

PlayerbotAI.Autobot.MaxBots.Server = 100

PlayerbotAI.Autobot.AccountId = 4

PlayerbotAI.Autobot.NamesInUseReset = 0

>>>>>>> autobot

Remove the text in red and save.

To apply the merge after fixing the conflicts

# git commit -a

Your default text editor will open giving you the opportunity to change the commit header. For simplicity, just save the file and your done. I haven't merged all branches, but it will get you started.

Hope this helps

first I want to say "Please forgive me for the offtopic question"

Blueboy, do u still continue to update the minimanager git? or can u advise me to use a specific manager or site?

With respect,

Axxl

Not at all, I still actively use MiniManager myself. I only update if there is a problem, normally if they try to restructure the databases. If there is, let me know and I'll try to sort it out.

Cheers

... the test to see whether the bot can equip the item's armour class and not greater (i.e Paladin can wear mail; if the item is leather or cloth it will return false as it's not the best armour for the bot).

Yes sorry it will work with plate armour too, but if I had mentioned plate in my example, someone would have pointed out that this is only available at level 40 Before, the paladins having all armour classes would grab everything. If you were equipping a paladin manually, your more likely to choose mail over leather and cloth. Once available, plate would be the preferred choice

Hope that's clear

Hi Gitch,

I not sure whether you have tried copying/pasting your patch, but with the code box formatting 'Diff' you endup including line numbers and no (cr/lf)s. I had problems with this myself. It's very pretty to read, but for practicality it's better to post code boxes in raw format.

Cheers

Hi Gitch,

Sorry, I should take more time reading posts (Too many late nights). I saw '"follow" and on the "fly" and thought you wanted to reduce the distance between player and bots during flight. Obviously you can set the general follow distance in the config file, but I agree it would be nice for users to be able to change this as they play. Hopefully I'll have a chance this weekend to do some more gaming Believe me whitespaces in code are like cancer, if you don't keep a check on them they take over. I remember creating a standalone patch for movemaps before it's inclusion in the core, it took well over an hour to clean the code.

Cheers

Hi Gitch,

Sound like a good idea. Be careful though, when I was testing the flight code, if the bot delay in following is too short the bots can catch up with the player and the display becomes very ugly as everything merges. Have a play and see what you come up with

Cheers

We did have a sister forum for playerbot that provided all that, but they had big problems with 'spanners' (Not a typo, but a description) and it has been taken offline. here's the link should it ever be active again

http://mangos.osh.nu/forums/index.php?app=uportal

Cheers

Hi Guys,

Something must have been going right yesterday.

If you still have problems, wait until 'movemaps' is integrated into the core

I must have had a crystal ball. Anyway, I have now updated all the repos and also the 'new-ai' branch with the latest core and with MoveMaps Yaaah..

Hope this helps

Hi Gitch,

I found some more information on the trade HLINK. I'm sure whether it will help any

UI escape sequences

To examine the HLINKs using the playerbot code

First, At line ~ 6850 in PlayerbotAI.cpp uncomment the following line

// DEBUG_LOG("chat(%s)",text.c_str());

Then rebuild code and send a dumby command to the bot chat handler ([Cooking] link from player spellbook)

/p cast <SHIFT><LEFT CLICK>[Cooking]

chat(cast |cffffd000|Htrade:2550:1:75:80000084:HAAAAABAEAAAAAAAAAAAAAAAAAAAAAA|h[Cooking]|h|r)

These recipe are initially learnt with the cooking skill

Herb Baked Egg

Roasted Boar Meat

Charred Wolf Meat

After learning Spiced Bread the recipe list looks like this

chat(cast |cffffd000|Htrade:2550:1:75:80000084:HAAAAABAEAAAAAAQAAAAAAAAAAAAAAA|h[Cooking]|h|r)

According to the link above, the recipe list is a Base64 encoded string, presumably using a custom inhouse algorithm. I tried a direct conversion from Base64 to ASCII and got only garbage.

Cheers

Hi Gitch,

and everyone else I have responded to today. Sorry, it's been one of those days, which I should have taken off

I understand that it would be a nice idea to open dialog boxes on the client to service bots for various tasks, but it's not going to happen. The main problem is the system expects each player to have it's own world session and a screen to display it on. In theory you could get the system to open a window for the bot on the client, but you wouldn't see it. If you were to redirected the output to the player's session, you probably couldn't interact with it and it would almost certainly cause a crash. This is the reason why most command output is through the chathandler.

Cheers guys

Hi Guys,

@Gitch

Perhaps I didn't document these very well, but the ablity to view bot tradeskills and associated spell/recipes already exists.

To learn a tradeskill (2 primary skills per bot)

(from bot_readme.txt)

/t BOTNAME skill (lists all [PROFESSION LINK] bot Primary profession skills)

/t BOTNAME skill learn (lists [TRAINING LINK] available class, weapon & profession (Primary or Secondary) skills & spells, from selected trainer)

/t BOTNAME skill learn [TRAINING LINK] (learn selected skill or spell, from selected trainer)

/t BOTNAME skill unlearn [PROFESSION LINK] (unlearn selected primary profession skill & all associated spells)

Remember that [HLINK]s are selected by holding down the <Shift Key> and left clicking with the mouse

1. Select a suitable trainer with the bot closeby.

/w botname skill learn

The trainer will reply something like

I can teach you: // I know this is not word perfect, but you get the idea

[Apprentice BlackSmith]

To learn;

/w botname skill learn [Apprentice BlackSmith]

If the bot has the cost to learn the skill, there will be a 'black powder' flash and the skill will be learnt. Note that all associated spells are learnt in the same way.

To check which tradeskills a bot has

/w botname skill

[botname] Whispers: My Primary Professions: [blackSmithing]

2. To use these skills and view known abilities, you need to use the 'craft' command.

(from bot_readme.txt)

/t BOTNAME craft < alchemy | a > (List all learnt alchemy [RECIPE]..)

< blacksmithing | b > (List all learnt blacksmith [RECIPE]..)

< cooking | c > (List all learnt cooking [RECIPE]..)

< engineering | e > (List all learnt engineering [RECIPE]..)

< firstaid | f > (List all learnt firstaid [RECIPE]..)

< inscription | i > (List all learnt inscription [RECIPE]..)

< jewelcrafting | j > (List all learnt jewelcrafting [RECIPE]..)

< leatherworking | l > (List all learnt leatherworking [RECIPE]..)

< magic | m > (List all learnt enchanting [RECIPE]..)

< smelting | s > (List all learnt mining [RECIPE]..)

< tailoring | t > (List all learnt tailoring [RECIPE]..)

/t BOTNAME craft [RECIPE] (craft any recipe that consumes reagents)

/t BOTNAME craft [RECIPE] all (craft all instances of a particular recipe, indicated by it's [charge])

Knowing that the bot has blacksmithing as a tradeskill

/w botname craft <blacksmithing | b>

I know: [Copper Vest]

Will list all known blacksmithing spells/recipes learnt by the bot.

I make the item;

/w botname craft [Copper Vest]

If the bot has the relevant tool (BlackSmith's Hammer, has the raw materials i.e. Copper Bars, and close to an Anvil) the bot will create the item [Copper Vest].

If the bot needs raw materials too;

/w botname craft <smelt | s>

To smelt, the bot will also need to know Mining or trade the raw materials with a bot or player that does.

@macks

To view the item damage for a bot, use the 'stats' command. It doesn't list all damaged items, but does tell you the total cost to repair them.

Yes, Gitch has an good idea auto-replacing damaged items if the durability drops.

Hope this helps

@blueboy,

Some handy modifications to IsItemUseful() would be:

1.) if (pProto->SubClass == ITEM_SUBCLASS_WEAPON_MISC) // tradeskill weapons, mining picks, skinning knife etc. Looks like this subclass covers all the tradeskill tools.

2.) support for the use of comparing items requiredlevel to m_bot->getlevel which isnt possible atm, (to my knowledge anyway!)

for example:

if (pProto->FoodType != 0 && (pProto->RequiredLevel < (m_bot->getLevel() - 10)))

return false;

Just suggesting!

For now I've added the necessary code to cover this from within _dosellitems() itself.

Think it would be easier to call IsItemUseful() for the majority of the checks if possible.

Getting close to a push I think, will up date when I do.

Hi Gitch,

I've just been testing the latest autoequip code with a new party of bots. For some reason the priest was not replacing a low level neophyte's robe( armor 3, cloth class ) with the unkempt robe( armor 8, cloth class ). The problem is the IsItemUseful() function. It contains a filter for low quality items. I don't wish to alter this, as it is used elsewhere. However, you can still utilize the armour comparison code from the function in your AutoEquipComparison() function. You will need the declaration of the relational array 'item_armor_skills' and of course the test to see whether the bot can equip the item's armour class and not greater (i.e Paladin can wear mail; if the item is leather or cloth it will return false as it's not the best armour for the bot). I have included a patch below for you to try

diff --git a/src/game/playerbot/PlayerbotAI.cpp b/src/game/playerbot/PlayerbotAI.cpp
index b29c909..ff30c42 100644
--- a/src/game/playerbot/PlayerbotAI.cpp
+++ b/src/game/playerbot/PlayerbotAI.cpp
@@ -543,6 +543,11 @@ void PlayerbotAI::AutoUpgradeEquipment(Player& /*player*/) // test for autoequip

void PlayerbotAI::AutoEquipComparison(Item *pItem, Item *pItem2)
{
+    const static uint32 item_armor_skills[MAX_ITEM_SUBCLASS_ARMOR] =
+    {
+        0, SKILL_CLOTH, SKILL_LEATHER, SKILL_MAIL, SKILL_PLATE_MAIL, 0, SKILL_SHIELD, 0, 0, 0, 0
+    };
+
    // get itemlevel for current item equipped in slot

    ItemPrototype const *pProto = pItem2->GetProto(); // equipped item if any
@@ -567,11 +572,13 @@ void PlayerbotAI::AutoEquipComparison(Item *pItem, Item *pItem2)
        }
    case ITEM_CLASS_ARMOR:
        {
-            if (pProto->ItemLevel < pProto2->ItemLevel && pProto->Armor <= pProto2->Armor && IsItemUseful(pProto2->ItemId)) // itemlevel
+            if (pProto->ItemLevel < pProto2->ItemLevel && pProto->Armor <= pProto2->Armor &&
+            m_bot->HasSkill(item_armor_skills[pProto2->SubClass]) && !m_bot->HasSkill(item_armor_skills[pProto2->SubClass + 1])) // itemlevel + armour + armour class
                EquipItem(pItem);

            // now in case they are same itemlevel, but one is better than the other..
-            if (pProto->ItemLevel == pProto2->ItemLevel && pProto->Quality < pProto2->Quality && pProto->Armor <= pProto2->Armor && IsItemUseful(pProto2->ItemId))
+            if (pProto->ItemLevel == pProto2->ItemLevel && pProto->Quality < pProto2->Quality && pProto->Armor <= pProto2->Armor &&
+            m_bot->HasSkill(item_armor_skills[pProto2->SubClass]) && !m_bot->HasSkill(item_armor_skills[pProto2->SubClass + 1])) // itemlevel + armour + armour class
                EquipItem(pItem);        
            break;
        }

Hope this helps

Hi Guys,

I've tidied the code on the 'master' and 'new-a' branches if your interested.

@nightterror I have now merged the 'master' code into the 'new-ai' as I suggested on PM.

Cheers

Hi Gitch,

Sounds peculiar. Are you sure the bot is a member of the curent group. The system might have got confused as to who is a party member or not. If for instance you change who the master is (As a player if you logout and back in as one of other bots), it might require that you recreate the party. If you right click on the player avatar and select 'leave party'. Then invite the bots again with the new master. If the offending bot is not in the party and a command is directed to the party (/p) it will be ignored. Just an idea

Hope this helps

Hi Guys,

Thanks for all your contributions, we're going to be busy this weekend testing

Cheers

Hi Gitch,

One additional thing you could use that I'm trying at present with your code is the function IsItemUseful() that was created to control which bot gets what while looting. A problem with paladins is that they can equip all classes of armour. You have already mentioned that some of your bots appear to be cross-dressers (no accounting for taste) :lol: Ideally you only want paladins to equip mail (plate when available). I recently updated the code for IsItemUseful() to enforce this behaviour. So all you need to do is add this to your conditions.

if (GitNewMaxValue > GitOldMaxValue && GitNewArmor >= GitOldArmor && IsItemUseful(pProto2->ItemId)) // itemlevel

EquipItem(*it);

// now in case they are same itemlevel, but one is better than the other..

if (GitNewMaxValue == GitOldMaxValue && GitNewQuality > GitOldQuality && GitNewArmor >= GitOldArmor && IsItemUseful(pProto2->ItemId))

EquipItem(*it);

This should stop hunters, rogues, warriors and paladins from donning cloth robes.

Hope this helps

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