quest_globals table - id field

[thepoetwarrior]

id` int(11) NOT NULL auto_increment

I have several different quest written up in efforts to stop trains, most of them using quest globals that expire after x number of seconds in order to make a queue, mobs aggro per minute, among other techniques too.

The id field in quest_globals table has an auto_increment. This increases every time a new record is added. The ids for the records that get deleted from being set to expire after x seconds are not getting reused, and the id auto increment just gets bigger forever.

I know how to reset the auto increment to 1, which will make it start at the highest id number + 1, but that wouldn't fix anything.

I did lots of goggle searches about reindexing a table, basically, reset all the id field that auto increments for each record. Would this affect the server at all? Does the database need the id field to not change in each record of the quest_globals table? What is the purpose having having a this field?

My main concern is if the id auto increment goes up every time a player aggro a mob, then would the id number eventually get too big and crash? What is the max number used? What happens if it reaches that number?

Hope this makes sense.

[KLS]

Eventually yes you would get an overflow around the 2.1 billion point. I'm not sure it will cause the server to crash but I suspect mysql wont be happy about it. You can probably write a script to re-index the server every time you take it down for maintenance (in fact that sounds like an overall good idea)... but...

If you're using a global every second in combat perhaps that isn't the best course of action either. Remember that every time you create/delete a global there's a DB hit so perhaps there's another way to do what you want to accomplish.

[thepoetwarrior]

I agree that create / delete global is probably bad idea, but would edit on a perminate global be less bad?

For example, I would make 10 perminate globals per char, and just change the value to reflect if its in use, and of course by using date/time stamps to check how much time has passed instead of a global that expires after x seconds.

My big question is, if I re-index the quest_globals table, those primary id that auto increment, would that hurt the server? Or does the server need those ids to not change? If the id really doesn't matter then a re-index might be good thing for every GM to do.

Thanks in advance.

[cavedude]

I agree that create / delete global is probably bad idea, but would edit on a perminate global be less bad?

For example, I would make 10 perminate globals per char, and just change the value to reflect if its in use, and of course by using date/time stamps to check how much time has passed instead of a global that expires after x seconds.

No, you're still performing a database write every second or however long you have it set. Globals aren't designed to be used the way you are. It's too much strain on the database. You are better off using a function that accesses memory, and doesn't need to hit the hard drive.


My big question is, if I re-index the quest_globals table, those primary id that auto increment, would that hurt the server? Or does the server need those ids to not change? If the id really doesn't matter then a re-index might be good thing for every GM to do.

Thanks in advance.

Re-indexing the IDs has no affect on server functionality, so it's safe to do. I do it on PEQ every couple of months or so.

[thepoetwarrior]

The info was very helpful. Thanks Cave Dude so much!

[Thovar]

This is an interesting topic. I would like to know what you come up with.


on a side note, why do you want to stop trains? why is that a goal for your server???

[thepoetwarrior]

I have a "Prestige Quest" that people basically get deleveled back to level 1, to increase the rank of an item, that currently goes up to Rank 100. So people are leveling up level 1-70 x 100 now, gives users something to do when not raiding, but obviously makes some players power level by using a bard to train the whole zone which ends up crashing the zones.

I have two types of anti train code.

1) A queue of mobs that when full, the oldest mob on the queue loses interest, WipeHateList, etc while newest mob gets onto the aggro queueu.

2) If players Aggro queue is too high, maybe 8-10 mobs actively aggroed, boots the player to another zone.

[thepoetwarrior]

I got another question which I guess relates to quest globals.

What is the consequence of

UPDATE npc_types SET qglobal = 1;

Which is kinda needed for anti train code to work.

[Lillu]

Nice idea about train controll. I was about to do UPDATE npc_types SET qglobal = 1;
a while before, but not sure either whats the consequesnce. Thanks in advance.

[thepoetwarrior]

Yeah, I'll wait to see what the experts say about SET qglobal = 1.

[joligario]

There is no consequence... unless you accidentally write scripts that will have an NPC modify globals that it shouldn't. It is more good programming practice. Kind of like deciding whether or not a variable should be global or not. Why make it global if it doesn't have to be? If you do make it global, you run the risk of the variable being changed by something that it shouldn't be able to change it. If you don't make it global, you are safe.

[cavedude]

Slighter higher CPU usage is the consequence because then you'll have every NPC in the game iterating through your globals to see if they can use one. I don't recommend it.