I am curious, with the #bot gate cmd, the actual ports, (druid), I couldn't find any of those
in the bot spell tables (707 for druid). I am wondering exactly what that cmd is using to port it's owner ? Currently, a lvl 51 monk with a druid bot, can port to wall of slaughter. Thats a lvl 64 spell. I figured you must have that porting set up some different way ? Just curious, hahaha |
Those are coming directly from the `spells_new` table.
The bot spells table are explicitly for use by the bot ai. EDIT: (Not sure if that is suppose to be true or was true at some point, however...) This is a draft script for those spells: https://github.com/EQEmu/Server/blob...art_spells.sql |
OH ok, I was also wondering, (long shot here), is it possible to stop all of the bot pets
from being spawned at all ? Even if I have to alter/recompile the source if needed. I don't want to stop players from being able to summon pets, just the bots. |
I have very little experience with the spell casting ai..although...
You could 'try' remarking out this line: https://github.com/EQEmu/Server/blob...lsai.cpp#L1007 and its scope closer here: https://github.com/EQEmu/Server/blob...lsai.cpp#L1019 to see if that works. That would keep you out of the database modifications. |
Quote:
what happens. Its a quick fix for the bot pet agro thing. Players don't seem to care about bot pets, if they are just going to wreak havoc, haha |
Quote:
have existing bots with pets and want to keep them. What it does now, any existing bots will still summon that mean old agro pet, but if one deletes the bot and creates a new one, it will not spawn a pet. THANK YOU :) |
If anyone is keeping up with this thread: https://github.com/EQEmu/Server/tree/dev_bot_commands
That's a pre-alpha version of what's coming. There's still a lot to do and even more tweaking afterwards. It will compile and the system itself can be tested..but, it should not be run on a live server - nor should a live database be used as data corruption is almost certain. The old method of using '#bot command' still works through a re-director..though, all usage/help examples use the new '^command' syntax. |
Still waiting for a power supply for my test box, its been down for a week now while I wait for the
"shipper" lag to get the new one to me, but I would be more than willing to test the new stuff out, when I get that box running again. Personally, whether it's # or ^ or @ to play with bots, I have no special preference, it's just another key on the board, hahaha The overall function of the bots is where my "wishlist" is. (Joining raids, casters staying at camp, getting me coffee, etc), you know, the basics, lol |
You missed one of the 'basics' .. but, I don't think it's appropriate conversation for a public forum :P
|
Quote:
|
Ok..I think that I've got the basics encapsulated to the point of not needing to replicate checks across every command:
Code:
void bot_command_bind_affinity(Client *c, const Seperator *sep) Still needs to be fully tested/tweaked..but, it should make adding new commands easier in the long run. |
Status Update:
75% coding complete.. 25% alpha testing complete.. |
We appreciate your time and dedication to this, we use bots on our server and this will greatly improve the experience.
|
Np - benefits me as well :)
Here's a log record of bottogglearcher and findaliases command use: Quote:
EDIT: And this using bot command list with filters: Quote:
EDIT2: This shows the #bot command redirect and bot sub-command implementation: Quote:
On sub-commands, almost all actions are implemented within a 'command' function. These 'sub-commands' essentially form a command 'group.' |
The new HealRotation class appears to work:
Quote:
|
All times are GMT -4. The time now is 12:42 AM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.