View Full Version : Perl DBI and Quest Scripts
Hateborne
12-26-2012, 01:37 AM
Does anyone have a reliable way (outside of qglobals) to access/update custom tables? If so, may I see an example or be directed to some reading material?
I am trying to find a way to create instances on a much longer scale in large numbers (players allowed solo, group, and/or guild instances). From what I have seen, either qglobals is not being read entirely or something related to max number of instances.
-Hate
Akkadius
12-26-2012, 01:55 AM
Does anyone have a reliable way (outside of qglobals) to access/update custom tables? If so, may I see an example or be directed to some reading material?
I am trying to find a way to create instances on a much longer scale in large numbers (players allowed solo, group, and/or guild instances). From what I have seen, either qglobals is not being read entirely or something related to max number of instances.
-Hate
Hate,
What is not reliable about Perl DBI?
Hateborne
12-26-2012, 02:13 AM
If memory serves, you said it yourself that qglobals was a trash system. Trying to find a reliable way to keep instances going past ~30min when they are somehow lost. I am still able to fight and farm in the instance, but I can never re-enter it through the normal context menu.
Perl DBI is from the ladies/gents that produce Perl (if memory serves). I am actually LOOKING for way to use that.
:-P
-Hate
Akkadius
12-26-2012, 03:18 AM
If memory serves, you said it yourself that qglobals was a trash system. Trying to find a reliable way to keep instances going past ~30min when they are somehow lost. I am still able to fight and farm in the instance, but I can never re-enter it through the normal context menu.
Perl DBI is from the ladies/gents that produce Perl (if memory serves). I am actually LOOKING for way to use that.
:-P
-Hate
I may have said it at one point in time but it is actually a pretty decent system there were just some things about it that I didn't like which were cleaned up recently.
qglobals is amazing for information that requires quick calls and it is stored in memory.
qglobals are refreshed in memory whenever a client writes a new one and can be deleted just as quickly.
As far as DBI, I've written some pretty hefty systems using it and if you need different information stored in the table I recommend using it.
I will post some stuff for you shortly, troubleshooting an issue with Secrets.
Akkadius
12-26-2012, 04:04 AM
This is a perfect example of how to use Perl DBI:
http://www.cyberciti.biz/faq/how-to-access-mysql-database-using-perl/
How I go about doing it is I load a plugin that parses the XML config of the server.
Put it in plugins folder:
Mysql.pl
sub LoadMysql{
use DBI;
use DBD::mysql;
# CONFIG VARIABLES
my $confile = "eqemu_config.xml"; #default
open(F, "<$confile") or die "Unable to open config: $confile\n";
my $indb = 0;
while(<F>) {
s/\r//g;
if(/<database>/i) {
$indb = 1;
}
next unless($indb == 1);
if(/<\/database>/i) {
$indb = 0;
last;
}
if(/<host>(.*)<\/host>/i) {
$host = $1;
} elsif(/<username>(.*)<\/username>/i) {
$user = $1;
} elsif(/<password>(.*)<\/password>/i) {
$pass = $1;
} elsif(/<db>(.*)<\/db>/i) {
$db = $1;
}
}
# DATA SOURCE NAME
$dsn = "dbi:mysql:$db:localhost:3306";
# PERL DBI CONNECT
$connect = DBI->connect($dsn, $user, $pass);
}
Example snippet:
### Read from DB
if(!$connect){ $connect = plugin::LoadMysql(); }
$query = "SELECT
cust_npc_scaling.level,
cust_npc_scaling.type,
cust_npc_scaling.hp,
cust_npc_scaling.mana,
cust_npc_scaling.mindmg,
cust_npc_scaling.maxdmg,
cust_npc_scaling.attack_speed,
cust_npc_scaling.AC,
cust_npc_scaling.STR,
cust_npc_scaling.STA,
cust_npc_scaling.DEX,
cust_npc_scaling.AGI,
cust_npc_scaling._INT,
cust_npc_scaling.WIS,
cust_npc_scaling.CHA,
cust_npc_scaling.MR,
cust_npc_scaling.CR,
cust_npc_scaling.DR,
cust_npc_scaling.FR,
cust_npc_scaling.PR,
cust_npc_scaling.hp_regen,
cust_npc_scaling.npcspecialattks,
cust_npc_scaling.spellscale,
cust_npc_scaling.healscale
FROM
cust_npc_scaling
ORDER BY cust_npc_scaling.level, cust_npc_scaling.type";
$query_handle = $connect->prepare($query);
$query_handle->execute();
$NTYPE = 0; my @SD;
while (@row = $query_handle->fetchrow_array()){ $SD[$row[0]][$row[1]] = [@row]; }
That should help alot
Thanks,
~Akkadius
thepoetwarrior
12-27-2012, 02:11 AM
Sorry for double post in other thread, but I got some issues where npc doesn't see the qglobals for the player. Seems its not refreshed. Any way to force a refresh? Maybe some undef statements?
Akkadius
12-27-2012, 02:26 AM
Sorry for double post in other thread, but I got some issues where npc doesn't see the qglobals for the player. Seems its not refreshed. Any way to force a refresh? Maybe some undef statements?
Can you explain this a little more?
Hateborne
12-27-2012, 01:54 PM
Akkadius, as always, I appreciate your assistance. Thank you for the info and reading material.
-Hate
thepoetwarrior
12-28-2012, 07:17 PM
Can you explain this a little more?
I use qglobals table for several things, mostly flags for zones. I usually have the flags set to either all zone, all npc, all player and use either account and/or char id in the name field. Other times I just have a unique value in the name field and use charid field so it would be all zone, all npc, this character.
Sometimes when hailing the NPC, it doesn't see the flag for your zone, even though it is there. Sometimes if a player goes into an instance, then hail the same npc, it seems to have refreshed what the npc sees and it can see your flag.
For Christmas I decided to give out free 'credits' that players can use while hailing an NPC to receive rewards. I used an NPC to give them a qglobal which worked, and I also set another qglobal to 'flag' the 'account' (via account ID in qglobal name field) so that they can't get more than 1 reward. Players started spending their reward credits, then going back to the Christmas NPC for more credits cause the NPC didn't see them as flagged for having gotten the credits already. For most players, it worked as intended and would tell the player they already received their Christmas gift, but when ever the NPC just didn't see the qglobal (and it was there), it would just hand out more credits. Again, didn't happen to everyone. Maybe zone was bugged or crashed? Or the NPC just isn't refreshing?
This has been an issue forever, when I use a 'cd key' style system to either reimburse items or give credits to spend on reward items. Some times players tell me when they hail the reward npc that it says the 'cd key' isn't there, so I tell the player to make an instance, and then it works. Again, seems to be a refresh issue.
Another issue that many are familiar with is the Waypoint seemingly eating the balance of plat, disappears, even though its there. Sometimes their instance is not there anymore even though it should be 24 hours, etc.
Starting to think maybe DBI would be more reliable than qglobal method?
Sorry for long story, hope it makes sense.
Akkadius
12-29-2012, 05:07 PM
Well, DBI might be more reliable in this one scenario, but for cases where you want cached information stored and called without hitting your database excessively you might want to try and troubleshoot what is going on with qglobals instead so I can fix them for you on the source side.
Some instances that I've ran into myself, is that a qglobal may not get 'updated' or 'refreshed' as you say correctly on the memory side, this can happen with qglobals that have an expire time. If the expire time is unmet and whatever is stored in the memory of that zone is true to that expire time it will not purge those qglobals.
You'd have to reproduce the issue and then use globalview to determine how to reproduce it so we can fix it on the source side. Otherwise, I do think qglobals can be very very useful given that they work correctly.
The thing also with qglobals that is also real nice is that when you use $qglobals{hashkey} it is referencing the memory of the Zone, not hitting the database which is kind of a big performance thing if you think about it.
Whenever a qglobal is set or deleted, then the zone does a refresh and the database is hit for qglobals to be read again and stored back into memory. But when it comes to constant reading of static information qglobals is the way to go, if you're having a consistency issue, I'd love for it to be troubleshot because everyone else is most likely going to experience the same issue.
You expressed whenever a player grabbed a CD key they would go into in instance to have a valid qglobal, that is like you said a refresh issue because the zone is pulling down fresh qglobal information that isn't stored into memory.
I will sift through the code a bit but I would love for this to be reproduced so it can be easily figured out.
Thanks,
Akkadius
wolfwalkereci
12-29-2012, 06:34 PM
Hmm could one possible issue the players are seeing is that the qglobal is being created at the exact same time the player is being sent to the instance?
Would adding a delay to the .pl script between creating the instance and then sending the player to the instance fix part of the problem?
thepoetwarrior
12-31-2012, 04:07 AM
Thanks Akkadius for the info. I'll see what I can find out.
The qglobal problem is mainly the key npc which is different from the instance npc so there is no need for delay.
I can see where qglobals would be faster than accessing the database every time. Just need to find out how/where players are bugging it.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.