Bots Auto-Updater Option

[Uleat]

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]

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]

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]

Are you the new Bad_Captain?

[Uleat]

Just a concerned citizen..

[provocating]

Originally Posted by Uleat

Just a concerned citizen..

Alright pilgrim...

[N0ctrnl]

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]

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.../bot.cpp#L1922

[Kingly_Krab]

'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]

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]

That matches what my table looks like as well.

[Uleat]

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=...Paste=GaJP0N80

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

[Uleat]

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]

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]

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...)