Quest for progression?

[Valdis01]

I recently ran across a few forum posts stating there is a way to lock out progression based on the status of the account (I.E status 1 = Kunark, Status 2 = Velious) things like that, I was wondering if there was a way to set up a quest script to actually grant them a higher account status based on items they turn in... I mean, I know in game you can #setaccountstatus and what not, but is there a way to turn it into a Task Master? Or a Quest?You know? Let me know...

Thanks!

[Noport]

Here is your new opcode Progression=0x2071 for your server

[Caryatis]

Protip: opcodes solve everything.

[joligario]

Personally, I don't like the idea of using account status to conduct flagging. I would rather use things like globals to lock certain content. Unless, of course, you want it by account rather than by character.

[sorvani]

If I was going to play on a progression style game, I like the idea of opening it up to an entire account. I do not want to unlock Kunark, then have to do it again for my alt.

I tried to add a $client->SetAdmin(value) (sint16 i noticed) feature on my test server last night, but my understanding of how to expose things to perl is lacking. There is a GM command for it already.



P.S. So true!
Protip: opcodes solve everything.

[Valdis01]

Yar it's to be account based... Just in the process of trying to figure it out, is being a pita, no lies.

[Valdis01]

So yeah, still can't figure this out... Lol... Bump.

[sorvani]

At the moment there is no method of changing an account's status in perl. Only the GM command as far as I can see.

edit: actually i remember someone on here showing a way to use DBI in a quest file. using that, you could create a SQL statement to do the update you need, but it would be better if someone can simply add in the existing code that the GM command references to perl.

[blackdragonsdg]

A couple of years ago I toyed around with level restricted and status based progression and while I never mastered controlling the sql execution with in a quest script the following might help you get started.

Using the example below....After Cazic Thule was killed I would spawn the Ghost_of_Fear which would cause the entire script to execute. The sql execution is uncontrolled once this script starts which is the part I never mastered.

Ghost_of_Fear.pl
sub EVENT_SPAWN {
quest::settimer(55,1200);
quest::shout2("Cazic Thule has fallen...Ruins of Kunark is now available")
}

use DBI;

# connect
my $dbh = DBI->connect("DBI:mysql:database=peq;host=localhost", "root", "password", {'RaiseError' => 1});

# execute update query
my $columns = $dbh->do("update zone set min_level = 0 where expansion = 2;");

# disconnect
$dbh->disconnect();


sub EVENT_TIMER {
if($timer == 55) {
quest::stoptimer(55);
quest::depop();
}
}


If you can make the sql execution controllable then you would be set and can do so from within Cazic Thules script instead of a secondary spawns script. You will need a couple of add ons for perl to get this to work...DBD-mysql and DBI I think were the only ones that were required but I added the following as well DBD-mysqlPP, MySQL-Config, MySQL-DateFormat, MySQL-Easy, MySQL-Insert, MySQL-Locker, MySQL-Log-ParseFilter, MySQL-NameLocker, MySQL-Sandbox and MySQL-SlowLogFilter.

[Valdis01]

Hmmm.... That looks like it could be a fun little script to dive into... Even if it's not account based, a simple Character base progression would be good, I can easily #setstatus their alts, (Or they can go kill the mobs they need to kill...)

[sorvani]

you could simply rewrite that script to update the account table.
my $NewStatus = $status;
my $AcctID = $client->AccountID();
my $SQLQuery = '';

event_whatever {
$NewStatus = $NewStatus + 1;
$SQLQuery = 'update account set status = '.$NewStatus.' where id = '.$AcctID.';';
$dbh->do($SQLQuery);
}

[sorvani]

be careful to make sure they can't repeat an event to get more status that you don't want them to have.

[chrsschb]

be careful to make sure they can't repeat an event to get more status that you don't want them to have.

Like sorvani said, add a flag check so this can only ever be completed once. People will exploit anything given the chance.

[blackdragonsdg]

The possibility of it being exploited is why you would not use something like status2 = status + 1. It would be better to hardcode the status updates to something like status = 5. That way it would not matter how many times they triggered the script they would still have the same or worse status depending on how the script is written. One could also use qglobals as a check to prevent it from being exploited.

I tried more than a few times to put the sql execution inside of event_whatever and it never worked. I probably just did something wrong but I never figured out what.

[Valdis01]

So, tried to put this in, and something messed up somewhere, it's not working... I might have messed up the Script..... Is there a way you can email me or send me a Private Message and we can see where I messed up...

Thanks!

[sorvani]

if you do not want to post your script, just PM it to me. I'll look at it later tonight sometime

[blackdragonsdg]

Well I got it to work in a controlled manner. If anyone else wants to know how here ya go:
use DBI;
my $dbh = DBI->connect("DBI:mysql:database=peq;host=localhost", "root", "password", {'RaiseError' => 1});

sub EVENT_SAY {
if($text=~/Hail/i) {
$AcctID = $client->AccountID();
$query = "update account set status = 5 where id = $AcctID;";
$dbh->do($query);
quest::emote("'You now have access to the Kunark Expansion.'");
}
}

Thank you Sorvani for the suggested rewrite of the script. It help me clean up my original script.

[sorvani]

great that it helps.
To the OP: you will also want to think about spacing out your status per expansion in case you want to give anything else to them or something down the road. If you are sure you won't then just 0-10 or whatever would work fine.

Also in a default DB there are a lot of # commands available to the genreal public (status 0).

[Valdis01]

my $NewStatus = $status;
my $AcctID = $client->AccountID();
my $SQLQuery = '';

sub EVENT_ITEM
{
if(plugin::check_handin(\%itemcount, <itemid> => 1, <itemid> => 1, <itemid => 1))
{
$NewStatus = $NewStatus + 1;
$SQLQuery = 'update account set status = '.$NewStatus.' where id = '.$AcctID.';';
$status = idk;
$dbh->do($SQLQuery);
$client->Message(315, "$NPCNAME whispers to you, 'Congratulations, you now have flags for <enter name>.'");
}
else
{
$client->Message(315,"$NPCNAME whispers to you, 'What is this carp?'");
plugin::return_items(\%itemcount);
}
}

is a template my coder worked out... Not sure if it's okay, or....

[sorvani]

you need the use DBI and $dbh = lines at the top. also you REALLY need to take into account someone getting the items again and repeating the quest. as is, if i did this quest 250 times I would have pretty much maximum gm powers.

[Valdis01]

And how do you prevent that from happening?

[Valdis01]

And how would we go about doing that? Email me, sinclipse@gmail.com

[lerxst2112]

Query their existing status, and if it is equal or greater than the status they should have from turning in a specific item or killing a specific mob don't add any more to it.