PDA

View Full Version : Bots Auto-Updater Option


Uleat
09-21-2015, 08:27 PM
I spoke with Akkadius and it appears agreeable to implement an auto-updater option for bots.

I'll see what I can do to get this working over the next few days and see where it takes me (my perl is a little non-existent...)


I've gotten private messages from several people over the past months and have a lot of information on what needs to be updated.

As well, I did a 'bots' search of the forums and found a lot there as well.


I'm going to have to compile all of the information and determine what actually needs to be applied, and hopefully, something will come of it.


Someone mentioned using the peq load_bots.sql over the git repo one.

I updated that script myself and believe the git repo is actually ahead of the peq one.

PEQ db dump uses `character_` as a reference (pre-profile update)

EQEmu git repo uses `character_data` as a reference

I should be able to discriminate between the peq and eqemu load_bots scripts and have the update script apply the appropriate changes.


I will probably set up the methodology to allow the initial bots tables load when this option is selected.

It will, of course, recognize existing tables and will not overwrite existing tables..unless an update requires it.


If you have information on known bots database schema problems, please post them here and I'll review it to see if it's on the agenda yet.

I'll try not to wreck existing bots implementations with any of this..so, expedient feedback will be needed.


Thanks!

Uleat

Trackye
09-22-2015, 11:01 AM
Bot buffs table is Vastly different in what the current eqemu server requires and what the load_bots.sql provides.

With the origional one the console will fire off 'Dot_rune' complaints but a number of the other column names are incorrect as well

If it helps this is what its currently looking for as after changing the table it now saves bot buffs without console complaints.

DROP TABLE IF EXISTS `botbuffs`;
CREATE TABLE `botbuffs` (
`BotBuffId` int(10) unsigned NOT NULL AUTO_INCREMENT,
`BotId` int(10) unsigned NOT NULL DEFAULT '0',
`SpellId` int(10) unsigned NOT NULL DEFAULT '0',
`CasterLevel` int(10) unsigned NOT NULL DEFAULT '0',
`DurationFormula` int(10) unsigned NOT NULL DEFAULT '0',
`TicsRemaining` int(11) unsigned NOT NULL DEFAULT '0',
`PoisonCounters` int(11) unsigned NOT NULL DEFAULT '0',
`DiseaseCounters` int(11) unsigned NOT NULL DEFAULT '0',
`CurseCounters` int(11) unsigned NOT NULL DEFAULT '0',
`CorruptionCounters` int(11) unsigned NOT NULL DEFAULT '0',
`HitCount` int(10) unsigned NOT NULL DEFAULT '0',
`MeleeRune` int(10) unsigned NOT NULL DEFAULT '0',
`MagicRune` int(10) unsigned NOT NULL DEFAULT '0',
`dot_rune` int(10) NOT NULL,
`caston_x` int(10) unsigned NOT NULL DEFAULT '0',
`Persistent` tinyint(1) NOT NULL DEFAULT '0',
`caston_y` int(10) unsigned NOT NULL DEFAULT '0',
`caston_z` int(10) NOT NULL,
`ExtraDIChance` int(10) NOT NULL,
PRIMARY KEY (`BotBuffId`),
KEY `FK_botbuff_1` (`BotId`),
CONSTRAINT `FK_botbuff_1` FOREIGN KEY (`BotId`) REFERENCES `bots` (`BotID`)
) ENGINE=InnoDB AUTO_INCREMENT=631 DEFAULT CHARSET=latin1;

Uleat
10-05-2015, 10:23 PM
Is there an issue with bots keeping their buffs after zoning/logging out?


EDIT: I think I ran across another issue where a db function is being called that doesn't exist...

provocating
10-05-2015, 11:46 PM
Are you the new Bad_Captain?

Uleat
10-06-2015, 02:30 PM
Just a concerned citizen..

provocating
10-06-2015, 03:16 PM
Just a concerned citizen..

Alright pilgrim...

N0ctrnl
10-06-2015, 03:41 PM
I can say for sure that the botbuffs table structure from 2015_09_30_bots.sql is indeed incorrect. I have what Trackeye lists above and buffs work fine. With the one from the updated script, bot buffs don't persist. I haven't tracked down which column is incorrect yet, but I'll chase it tonight and see what I come up with.

Uleat
10-06-2015, 04:34 PM
I found a query that may or may not be working as intended - regarding buffs.


I need to make sure that I fully understand what it's suppose to do..then go through the revision history and make sure that something didn't get left out.

This is the query that I'm questioning: https://github.com/EQEmu/Server/blob/master/zone/bot.cpp#L1922

Kingly_Krab
10-06-2015, 04:54 PM
'bottimers' is a table for skill-related timers I believe, whereas 'botbuffs' is the actual buff data and is handled by Bot::SaveBuffs() and Bot::LoadBuffs() respectively.

Here's the load buffs query, it may not be correct: std::string query = StringFormat("SELECT SpellId, CasterLevel, DurationFormula, TicsRemaining, PoisonCounters, DiseaseCounters, CurseCounters, CorruptionCounters, HitCount, MeleeRune, MagicRune, dot_rune, caston_x, Persistent, caston_y, caston_z, ExtraDIChance FROM botbuffs WHERE BotId = %u", GetBotID());

Uleat
10-06-2015, 05:00 PM
That makes sense, thanks!


If the buffs are failing for the missing field, that should be addressed in an upcoming change..if people haven't updated it already themselves.

N0ctrnl
10-07-2015, 10:15 AM
That matches what my table looks like as well.

Uleat
10-07-2015, 04:13 PM
Ok..here is the absolute first draft of the new bots script.

It still needs to be fully reviewed and tested..but, I'm putting it out there so I can make feedback-based changes as early as possible.

-- Still need to look at the 'Alter' tables criteria --


http://wiki.eqemulator.org/i?Module=Pastebin&Paste=GaJP0N80

(I did add a few 'extra' columns for future changes..stuff that should probably be implemented and hasn't yet.)

Uleat
10-07-2015, 05:03 PM
Ok..I see the `caston_#` changes..I'll update that.


EDIT: Please note that the above link is being updated as I make changes..so, it should always point to the most recent script that I have posted.

Trackye
10-07-2015, 11:33 PM
Did you change in the Server code from "ExtraDIChance" as a column in Bot buffs to "extra_di_chance"? As right now "ExtraDIChance" is what its looking for.
'EDIT" nevermind i see where you changed alot of the columns to use a _ format.

My Bot Buffs table has no column for `caster_aa_rank` and runs efficiently with no errors.

Uleat
10-08-2015, 01:56 PM
Yes, all of the columns are using a 'standardized' naming convention.

I'm adding conditional checks to update the new tables where a possible column was added to fix an issue..but, was not part of the original schema.


These types of 'special cases' are what I really need help in catching.


The server code is being updated for the new schema as well.

Afterwards, implementing updates should (hopefully) be a little easier.


(I will remove the `caster_aa_rank` column if I don't find any obscure references to it in the code..kinda like I found one that still uses `GetMobTypeByID`() ..
and that function was taken out of the bots schema before I ever came on...)

Uleat
10-09-2015, 09:52 PM
I 'think' the script is done except for tweaking against server run-time expectations.

Now, for the hard part..TESTING!


The 'bots_updater' branch has the script, as well as all other changes, committed to it..so, take a look if you're interested, give some feedback if you care! :D

https://github.com/EQEmu/Server/tree/bots_updater


EDIT: Updated script pushed to remote branch fixes special case column updates.

rencro
10-11-2015, 02:52 PM
Sorry its taken me so long to look at this, there is an issue I ran into on a virgin DB.

I get an error "Your server binaries (world/zone) are not compiled for bots..."

The updater quits at this point. I tracked the error to line 845 of eqemu_update.pl


sub bots_db_management{
#::: Main Binary Database version
$bin_db_ver = trim($db_version[2);

#::: If we have stale data from main db run
if($db_run_stage > 0 && $bots_db_management == 0){
clear_database_runs();
}

if($bin_db_ver == 0){
print "Your server binaries (world/zone) are not compiled for bots...\n";
return;
}


I changed the 2 to a 1 and all works well as far as updating.

EDIT:: I deleted the manifest and 2015_9_30.bots sql from my db_update folder and the script now pulled the latest sql and now there are no views or functions being created. Was working fine with the old 2015_09_30_bos.sql from before the latest push.

Edit2: Started over, and all working this run, so only issue is the perl edit to point to the second element instead of non-existing third in db_version on clean db.

Uleat
10-11-2015, 04:00 PM
$db_version[2(missing bracket?)


There's an additional parameter being passed that will tell the script what the current 'bots' version is set to.

It's currently disabled so that the script will not apply what's in the 'master' branch due to its not being ready.

https://github.com/EQEmu/Server/blob/master/world/net.cpp#L124
https://github.com/EQEmu/Server/blob/master/common/version.h#L35


There are a lot of changes that have to occur in the master branch before the 'conversion' will work properly.

I've got a backup db that I'm testing the conversion process on, as well as binaries from both master and bots_updater.

(Not sure why views and functions wouldn't be created, even with the current scripts, unless the script is erroring out.)


The 'bots_updater' branch has the most up-to-date code/scripts..but, it's still in testing phase.

Uleat
10-11-2015, 04:02 PM
Speaking of testing...

I noticed with the current system that bot pets are not saving inventories or buffs.

In addition, bot groups are being saved..but, not bot group members...


Are these problems that other bots users are experiencing?


FINAL EDIT: 3 issues resolved

rencro
10-11-2015, 04:41 PM
$db_version[2

Thats my lame attempt at making the 2 red, the bracket is there in the code.

Uleat
10-11-2015, 04:43 PM
That's forgivable... You should have seen some of my lame attempts at making this script :P

Akkadius
10-11-2015, 06:06 PM
$db_version[2

Thats my lame attempt at making the 2 red, the bracket is there in the code.

The 2 is a good spot, I very hastily made the changes because I had to leave the house for the night but I wanted to get things ready for Uleat. It is supposed to be 1 on the split.

https://github.com/EQEmu/Server/commit/71d36af3efcdfcb88f4a1578a5b3450d01265f2a

When Uleat is actually ready to make use of that portion of the update script, we'll push another binary and script update.

Akkadius
10-11-2015, 10:59 PM
Cancel that, it was right originally. :P