well my file has some noticeable differences... i removed the nested-if os thing because i only use windows... but...

if(-e "eqemu_server_skip_update.txt"){
$skip_self_update_check = 1;
}

this looks like something simpler than 2 pl files.

Woot, i didn't know there was a .bot version... that's definitely zero right now.

okay, good thing the previous values were all 3006 as i've changed the wrong thing... i see why the loop i saw happened since, their is crossover between 9010 and 9014... only a problem if it runs a second time without a version value, i assume, like me. i did do a complete new install and ran through them by hand after i saw the same errors...

i've run that 9015 sql containing:

-- Update npc_spells_id to new values
UPDATE `bot_spells_entries` SET `npc_spells_id` = '3002' WHERE `npc_spells_id` = '701';

as i pasted above... but this time i ran as it is read... it did not change the values for some reason? i will figure it out, i dont say it as a request, but in case it's useful info.

i totally missed this reply somehow, sorry it's belated even though i replied to other things previously.

Guys really shouldn't be disabling the eqemu_server.pl script from updating, that is what it is designed to do.

However if there is an update logic in a loop then obviously someone needs to address it and fix it (a dev)

If you need to disable update checking, there are ways to do it but not recommended.

The update routine should not be invasive at all, if it is please report what you're seeing

What does..
..return?


EDIT: Forgot the GROUP BY..

already uncommented... i realized the mistake i caused... there wasn't a loop, the revision wasn't set, so when each time booted up, it thought i needed an update.

since 9010 and 9014 change some or all of hte same things, after 9014 was good to go, it came along to 9010 and the check for it was missing, so it went ahead and ran 9010 it removes the revision line from 9014 or whatever... sorry for bad vocab..

anyway, all user error....i may just go back to svn checkout, compile, move. although i never used the languages i learned, the familiarity makes that stuff easy enough.

No, you are correct about the 2nd run trigger..I've already had someone report that.

The constant looping, however, is a completely different beast...

well i used the setup_bots version with a new db. but i wasn't sure if the 9010/9014 thing get reversed on me, so...

then i went through and ran each update sql in order based on manifest file. i set db and bot version to 9107/9015 and everything seems fine.

if you can tell by that order of behaviour soemthing will be wrong, let me know.. otherwise, thanks for the help again.

edit: about the loop-ish thing -- "DROP TABLE IF EXISTS `bot_spell_casting_chances`;" is the cause i think, because it removes the versioning line from 9014.

can update #9010 - 2017-02-23_spell_casting_chances have a condition on that to check for the versioning entry with "255" etc from 9014?

that would prevent what is happening. or something besides "if exist, drop".

i learned sql 20 years ago in college... lol remember basic concepts only

IIRC, I dropped the 'value' column in the newer table..and since it doesn't exist if the older table doesn't, the query errors out.

What I should do is just replace:
..with an `information_schema` table check for that column and it shouldn't error out due to the table not being there.

SHOW COLUMNS is convenient to use..but, it doesn't play well when the table doesn't exist...


EDIT: Lol! I wish I had learned it 20 years ago..I was too busy loading 500/2000 pound munitions on F-15s/16s

Ok...

I added a second trigger for that script file to be applied.

One or the other should catch depending on the versioning of the database being updated.

they both "caught" for me. when i ran update, not sure if i am having same issue, then... or was...

no bot version, so it repeated proces... since they both edit that table and one drops it, after it gets dropped the 9014 has to run again.

it was only a problem that i saw because i went through he update multiple times without reason (i didn't have a version # for bots).

just making sure the info i gave was communicated properly. i only perceive a small portion of the picture.

you drop the whole table in the 9010 sql update, not just removing a column - but only a problem for a dummy who doesn't have the bot.version. otherwise, it wouldn't run back through sql updates that have already run properly 1 time.

* as you probably know, "learning" a language or something like sql in a classroom environment is not very thorough... the main benefit is organizational concepts, structure etc etc. you learn the "right" way before you develop bad habits.

what are there 7 tenets to a relational database? the first 4-5? are all that's important to all but the most sophisticated setups and are common sense. i couldn't recite them, but i would probably adhere to them in practice, because it's the logical way to make it.

so, i use "learn" very loosely. i am familiar enough to google and recall some voacb and find an example of the sql command. the order of some things is not a fresh memory at all. i know enough to be very dangerous to my server's health :p

9011 and 9014 don't trigger off of the same table..are you sure that it's not 9015 and instead of 9014?


The trigger process searches for required updates from newest to oldest..then applies from oldest to newest.

Since update 9015 'assumes' that 9011 is in-place, and that it is possible for that case not to be true, I added the 9016 query.


If 9014 isn't triggering the first time around..but, is on the second..I'm not sure what's going on there.


EDIT:

Oh, I see now..I was stuck on the issue that someone else reported..and 9016 should fix that.

Yes, I do see where 9010 and 9014 are tied..lemme look at that now.

That's a critical update for bot bard spells (songs) that must be done in a very specific order.

If 9014 is applied (as in actual changes/rows affected != 0) before 9010 makes its changes, there will be issues.


Update 9009 is the same as what's in the 'normal' database updates. This was done to keep both versions on the same page. (Otherwise, the normal version
would still have bot id's listed.)

Update 9010 only deletes entries for the old designation of bot bard spells id (711.) It then applies the new spells under the old designation.

Update 9014 changes all spells ids to the new format:

I'll mull this one over for a while...

okay, i dropped it manuall (couldn't use drop bots schema sql in eqemu-server.pl due to primary key constrain error?) I couldn't copy/paste it into the query without errors, either.. so i just went through line by line and dropped those tables.

then, i went through and sourced each SQL from your online repository in order based on manifest file. i had to copy/paste a few of the sql files ... the manifest points to the same file for 9015-9016, if that's a concern.

i think anyone who made a fresh server like me in that time period, possibly still?, is probably running into a problem, like me. but, if you had an existing server and as long as the updates haven't piled up it wouldn't occur. if you had to do those 2 updates at same time, then they will run into a similar problem.

(right? during automated update process it cycles through manifest 2 times from what i see on the screen. so, if the versioning line is removed by a newer update, when it cycles through a second time it thinks it's missing, even though it's been run.. loop)

Anyway, i was wrong the last time about fixing it.. i think i got it now... if anythign below seems off let me know... otherwise, thanks again (again).

Bard works fine... casting ooc spells at least. i didn't get into combat.

i had to copy/paste a few of the sql files ... the manifest points to the same file for 9015-9016, if that's a concern.

anyway... if bard is the only class with working castable spells at the moment... I think i got it working properly, lol. i noticed the shaman still SoWs but that may be a different beast than healing and combat spells.

i saw a few "warnings" while sourcing the sql files, but i think everything loaded fine... the one that didn't went in and it had already placed bot classes at 3001 - warrior etc... (whichever update that is). so, the changes were present, but not sure how that's possible, lol.

The 9009 update performs a move of all existing bot spells from the npc table to the bot table.

At this point nothing has changed but the location of existing bots spells in the database.


Update 9010 actually drops the old bot bard spells and inserts the new ones.

At this point, all classes that could cast before should still have spells - original or modified list.


If you happened to drop your `bot_spells_entries` table, then no bots will have spells except for when the new bard ones that are added in update 9010. You'll
need to re-acquire them from an old database and make the id adjustments - if that is the case.

Cool beans, thanks.

what you said makes sense. thnk i got the whole picture, now.. i can dink around more later when motivated.

starting over from scratch isn't much of a problem, if it comes to that. one thing is for sure, those maps are up-to-date!

funny, when i've compiled in the past there's no problems, and that's the more complicated process... just my kind of luck.. worth the effort in long-run, though.