where you getting the message that you were being moved to a safe point? that's what i was seeing.

where you getting the message that you were being moved to a safe point? that's what i was seeing.

The only time ive experienced this is when I have zoned in under the world, or slightly under the world using #goto x, y, z and the z was just an inch under the world. The bot code doesn't specifially use zoning code or zoning xyz coords. Maybe the db zonepoints need to be updated for the zone you are in?

Either that or your strength buffs have worn off. ;)

No joke, I've done it before. :oops:

I'm not sure this is the right approach. If i use those three files, the problem occurs, if i don't, it doesn't, if i do it comes back and so on. It's nothing to do with buffs. I can use goto or zone to alter my coords, i can change my size using #size but i can't get around this issue. I am unable to comment on it being an incompatibility with the database as i don't see anything that marks the version name or number.

However, if georgeS and i get the same symptoms when we use those 3 files, and our systems work as soon as we stop doing it, then i think there's more going on. I can't investigate, i don't have the skills but if anyone working on that code could do so, it would be much appreciated.

I've updated the source and binaries with the workaround for Group Heals. There are many Cleric and some Paladin group heals that report as ST_GroupTeleport for some reason.
I also made a change to trading that may fix the refresh on appearance when giving items to the bots.

My changes are running on The Realm server. If you can log in there and still get stuck then I can look at log files to see why.

I'm running whatever came with the minilogin package. Are those three files incompatible?

yes, incompatible.

your loginserver.ini file should look something like this:
and you should use the *.conf files that come from the main download of the win32 binaries(not source). Only use the minilogin.exe from that zip file.

Is there any way i can use the bots with minilogin then? My database is ready to i think.

if you can get the emu up and running with minilogin, then the only thing you need to do is copy in the bot binaries.

Why the change to a hard limit on the number of bot groups, out of curiosity?

I realize that if 12 groups isn't enough to take down something, a player's got more problems than just bot count, but why add the hard limit when you were running on a LinkedList before?

If the problem was not being able to iterate through raid groups, this is what I was using for that:

also adding new groups:

that's not why I got away from the linkedlist, I just thought that 72 was the max raid in eq anyway.

I've updated the source and binaries for build 1110

There was some discussion earlier in this thread about incorporating this into the main eqemu source as a rule or something. Is this still a possibility, or should we keep searching this 39 page thread for builds?

I noticed the bot entries were in my database when i first installed it although i couldn't figure out what they were for, so i assume it was half done. I've tried replacing my binaries with the ones listed but that just crashes my game so i am not sure how to proceed.

If there's a way to backup my characters and install a version like minilogin that i can solo on and use bots i'd be very interested! :-D

1 you need to check through the changelogs and enter the required mysql changes in it before trying to upgrade any of your binaries without those changes as soon as you try zoning in youll crash the bots work fine with minilogin just backup your character_ account, and inventory tables but you dont need to just run the needed mysql statements in the changelogs and itll work fine

heck atleast make a forum specificly for this as a alternate version or something hes right searching this thread is a bit of a pain in the ass.

Ah, you may have a point there. Now that you mention it, I seem to remember them having that kind of limit, like the hate list depth, so people involved in stupidly huge raids weren't getting credit or something like that.

I've been working on command sets which operate on the entire raid (including loading and saving intact raids on a per-player basis) which used the linked list iterators heavily. ("#raid load fivegroup" loads the raid I saved as "fivegroup," complete with main tank and second tank flags).
Some of the stuff I've been doing (like adding a pacifist flag so the raid can't attack) I see you've already either been working on or finished.

This stuff still needs a bit of work though, although I think the new movement code for the bots I'm working on will be done in a week or so.

I've just integrated the code in your 1108 release into my codebase (but converted it all to linked list.)
When I update to your 1110 release, I'll switch back to arrays. Shouldn't set me back more than a few hours.

Gah, five minute edit rule strikes again.

I've been simplifying the interface for a lot of commands ("#bot raid order task attack"? really?) to a #bot, #bot group, and #raid command structure, and I've stuck all of the commands into two separate included .h files ("botcommands.h" and "botraidcommands.h") which can be included in "commands.h" to make merging a bit easier, etc.

Let me know if you'd like to work together on this stuff or what things you're working on now so we're not duplicating work.

I would love to see the commands simplified and made more intuitive. Nice work!

That sounds like some great work your're doing. If you can get the linkedlist thing to work that's awesome. I was getting too many zone crashes cuz dead bots were linked everywhere and ended up having code try and execute on bot objects that no longer existed when they got killed, especially when working 12 group raids(71 bots + me). I left live... i think the expansion after PoP and at that time I thought the raid limit was 12 groups. Before I set that hard limit I did some research into what the limit was and all I could find was that in later expansions they tried to move from 72 down to 48 max players in a raid. If you can find some info that says more than 72 is allowed it isn't hard to bump the constant up from 12.

Just thought I would take this opportunity to give credit to Magoth78 for this bot code he gave the community around build 992. reading some of the posts, it seems people think i wrote all of this stuff. I've just kind of maintained it through the latest builds and tried to figure out how to fix some of the crashes. C/C++ is not my strongest language so I may have made some poor design choices. I think some of the crashes came from bugs I introduced myself when trying to fix other things.

The #bot command structure was inherited from the original bot source, it definitly could use the reorg you are talking about. I have left most everything the same as Magoth78 coded it except where I fixed crashes and the big change to raids with the linkedlist or array decision, and fixing stat bonuses from items and adding AA's.

There was talk of merging the bot source into the emu source and that is when I did all the #IFDEF EQBOTS around all the bot source since the original source was not ifdef'd. The ifdefs would make it really easy to put into the main emu source tree, but I recommended against it at the time since the bot source was really crashing a lot. Now that it has stabalized some, maybe it might be ok, but since there is still some fluidity to the code, it seems easier to work on it this way than do code submission requests through the emu devs.

The next big issue is to complete separate spell lists in the database for bot casters. Some work has been done in this area but a lot more is needed and I just haven't got there since I'm more focused on code bugs than db updates.

I'm all for extra help from the community on the bot source. I don't own it, just trying to keep it going. Happy to work with anyone that wants to help out.

From memory, EQLive raids had a max of 72 players in the Raid UI. However, some zones (I believe) limited the number of entrees to specific numbers - i think PoTime was one of those? I'm sure there are more seasoned raiders out there that know more.

But 72 is the number I remember. You could zerg with 200 if you wanted, but only the 72 in the raid UI got credit/loot (unless of course the loot lockout timer expired yadda yadda)


As for the #ifdef work... I know I've said this before. Is it possible to move all BOT code external into it's own cpp/h files, and use #ifdef / #includes like the GuildWars system uses? There would be lots of #ifdef BOTS...do this... but maybe with a few nicely placed #includes, it could be less intrusive to the core - and can be easily switched off at compile time.

It is easily switched off at compile time now with the existing #ifdef EQBOTS I coded. It may be possible to move some, but not all bot code to it's own files. Not sure if that effort would make much of a difference.

#raid should be #bot raid
I think everything should be prefaced with #bot because eventually the emu is going to have it's raid stuff fixed and there may be gm commands like #raid and we don't want to preclude the emu from using them. Just my .02 on the commands.(unless it was just a typo... I see you have #bot group).

What about a separate release thread on these forums for the bot source and binaries, so it is easier for people to find them and know exactly when it has been updated. This thread is growing fast and sometimes it is easy to miss releases if you don't check every day.

Keep this thread as the discussion thread and only let the people working on the code post in the release thread.

is there an easy way to take the masters guild tag and slap it into the bots "last name"

because the "last name" currently is what it displays as the "guild tag" for the bot. with the default being "bot"

I couldn't find an easy way to do that.

That could make it easier... if the forum mods are reading this, could you add a new thread that could be updated with just the source locatios like he suggests?

I was thinking that I would start working on the BOT Spells again, but WHERE are they going to be designated in the DB? I thought it was agreed on that the 600's were ok but other spells are showing up there now. Going to have to remove all the FEAR LINE of spells now that the Fear Fix is in. It will be easy to change what I have already in the 601 to 6xx to another number using GeorgeS's tools, but it would be good to have a designated area, yes?

Maybe 1001 on up? that would leave lots of room for some expasion? Don't remove fear line... but add snare/root line ;)

That's a really good point. I was just doing it that way to reduce the amount of typing with raid commands, but it seems like that sort of stuff is going to get macroed by players anyway.
I agree that compatibility should definitely trump brevity. I quit EQ far before they put in the raid interface (about a year before PoP), so honestly I'd forgotten there was one. :oops:

Yeah, after switching to linked lists, I've had to catch and kill a lot of crash bugs - mostly related to me dealing with linked lists incorrectly, I believe. I need to build some test cases where I ensure the LinkedList and LinkedListIterator classes actually behave the way I think they do.

I've been doing a lot of what I see you've been doing (while comparing the older code with what you've been making) - adding checks to catch null pointers and finding the behavior that can result in creating them.

I'm still in awe of what Magoth78 put out - and how easy it is to follow the logic. Most of what I've done with the codebase to make it work the way I want is just simplifying commands and catching some stray crash bugs.

From a dev chat log about The Serpent's Spine, I guess we can fairly call the limit 72. Smaller limits seem to be for various raid Tasks, which aren't really implemented yet.

Has anyone else noticed an issue with the bots not being able to keep agro? I played my wizard lastnight and had 2 bots (a warrior and a cleric), I would do #bot group order attack and send the warrior to tank the mob. I can see the warrior saying "taunting", I am waiting until the mobs are at least 80% before I cast and as soon as I cast my first spell the mob immediately runs to me. The warrior bot will run over and continue to attack and taunt but the mob never leaves me.

I have tried with other characters as well, with my ranger I can send in the warrior and if I am even standing close by not attacking I still catch agro. I can stand still not attacking at all and the warrior bot can never taunt the mob away.

try a test... set your server rule and see if it helps:

Aggro:SmartAggroList = false

After adding the rule my bots can now hold aggro. Thanks!

Just wanted to say thanks to those of you shepherding the bots code along. I've enjoyed using the bots quite a bit and, while not perfect, they are pretty darn good.

C++ isn't my best language either but if you need any help Congdar don't hesitate to throw me a PM.

Emu0.7.0-1118-Source With Bot Code
 

For anyone interested, I have merged all of the 1118 Changes in with the BOT Code and have successfully compiled it under Debian Linux and Windows C++ 2005 Express. Here is the link for the files... The Makefiles have been setup to include the bot code for Linux compiles.

http://www.mediafire.com/?yzgwlxkgdgz

On another Note, The implementation of fear has caused the Bot code to really spam the so and so is under attack when the mob gets feared away so much that it really lags out the zone bad.

Just an FYI.

Thanks, Aramid. I've been writing a script that does it for me but the results have been inconsistent enough for me to not submit it yet.

Thanks a lot Aramid, I'll give this a try later this week. I wonder whether simply commenting out the "... is under attack" notifications will help with the lag?