EQEmulator Forums - Quest for progression?

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Quests::Q&A (https://www.eqemulator.org/forums/forumdisplay.php?f=599)

- - Quest for progression? (https://www.eqemulator.org/forums/showthread.php?t=34950)

Quest for progression?

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!

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

Protip: opcodes solve everything.

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.

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!

Quote:

Originally Posted by Caryatis (Post 207466)

Protip: opcodes solve everything.

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

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

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.

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

Code:

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.

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

you could simply rewrite that script to update the account table.

Code:

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

}

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

Quote:

Originally Posted by sorvani (Post 207783)

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.

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.

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!