Perl Flags

[mollymillions]

Whats the status of the Perl quest flags?
I have done a lot of testing with the flagging over the past months but as yet have had no luck. This is the code I used to test the current implementation of the flags (as per the How To posts):
sub EVENT_SAY {
if($text=~/showflags/i){
quest::flagcheck(1,1);
quest::say("NPC flag 1 = $returnflag");
quest::flagcheck(0,1);
quest::say("Client flag 1 = $returnflag");
}
if($text=~/flagnpc/i){
quest::say("Setting NPC flag 1");
quest::flagnpc(1,1);
quest::flagcheck(1,1);
}
if($text=~/flagclient/i){
quest::say("Setting client flag 1");
quest::flagclient(1,1);
quest::flagcheck(0,1); }
}

[Lurker_005]

Well I havn't been able to spend any time checking the flag stuff yet, but 2 things. Keep in mind the odd behavior of flagcheck as posted by Valdain (http://www.eqemulator.net/forums/viewtopic.php?t=12317), and your checking flag 0 for the client not flag 1

change quest::flagcheck(0,1); to quest::flagcheck(1,0);

Actually try this
sub EVENT_SAY {
if($text=~/showflags/i){
quest::say("NPC flag 20 = $returnflag");
quest::say("Client flag 10 = $returnflag");
}
if($text=~/flagnpc/i){
quest::say("Setting NPC flag 20 to 6");
quest::flagnpc(20,6);
quest::flagcheck(20,1);
}
if($text=~/flagclient/i){
quest::say("Setting client flag 10 to 5");
quest::flagclient(10,5);
quest::flagcheck(10,0); }
}

[mollymillions]

I don't think Valdain's mods have been merged into the CVS code - I was basically fishing for confirmation :). I could not locate any reference to 'flagclient' in the source but this may be due to incompetence on my part.
Your right, i had the parameters switched it the client flagcheck, but changing it won't make it work. Thanks for the help though.
Can someone 'in the know' confirm that this is how the flags are currently implemented in the 5.3.3 code? If it has been implemented differently can we get the details? (I know the DR code is unsupported, so i don't expect anything, but i have been good and waited a long time for the details regarding flagging to become clear before posting).

I am also interested in the scope of these flags, variables defined in #peval commands and variables defined in plugins, but i will do some testing before asking questions with a bit of luck i will work it out.

[mollymillions]

Regarding the scope of variables, i found that a variable used within a quest is available to that NPC only. Variables declared in plugins or with peval have zone wide scope (cleared when the client zones and I imagine they are all specific to the client, but i hav'nt tested this). The plugin and peval variables are restored once you re-enter that zone, somehow(?). With this knowledge i knocked up a small plugin to handle an associative array to be used for zone-wide flags.

Pugin.plsub get_flag { return $flags{$_[0]}; }
sub set_flag { $flags{$_[0]} = "$_[1]"; }
Use plugin::set_flag("anyname","anyvalue") to set a flag and plugin::get_flag("anyname") to return a flag. The number od flags is limited to the limit for an associative array and the flag names and values can be anything.

Test example:
sub EVENT_SAY {
if($text=~/getflag/i){
$flag = $text;
$flag =~ s/(getflag)\s(\S+)/$2/;
$flagvalue=plugin::get_flag("$flag");
quest::say("$flag = $flagvalue"); }
if($text=~/setflag/i){
$flag = $text;
$flag =~ s/(setflag )(\S+)\s(\S+)/$2/;
$flagvalue = $text;
$flagvalue =~ s/(setflag )(\S+)\s(\S+)/$3/;
plugin::set_flag("$flag","$flagvalue"); }
}
Say "setflag name value" and "getflag name" to test flags with this test example.

Is it possible to declare a variable that will have world -wide and/or client-wide scope?

Also, do the Devs want us users to test the Perl flags as implemented in the code or do the Devs know that- A) it works so dont bother, B) its not implemeted so dont bother, or C) its really low priority so dont bother?

[Eglin]

re. your questions of variable scope: the normal perl scoping policies are in tact. That means that variables will be scoped as globals in the current package unless declared with the my or local modifiers (although there may be other ways to modify scope, like enclosing in brackets). Your confusion is probably related to the way that the interpreter sets it up so that each npc's quest script is loaded into its own package - i.e... creating a global variable inside a function inside a script for npc 1234 results in a fully-qualified scope name of something like "$qst1234::somevar". While inside the qst1234 package, it can be accessed as $somevar. To access that same variable from another npc's script or a plugin or whatever, you would want to make sure to refer to it as "$qst1234::somevar" or include/use the qst1234 package. The same is true for functions (which explains how the interpreter knows to call the appropriate sub event_ or whatever function). I would have to do some review work to be able to say for certain how the plugin namespaces work, but OTTOMH, I would say that plugins are executed in the plugin:: package by default. This means that having a plugin to manage a global hash is probably wasted effort. It would make more sense to pick a reasonable namespace and just create a variable there.

If that sounded patronistic, I apologize. If it was, OTOH, instructive, then I suggest that you go back and review my initial comments on plugins and see why I was so excited about them. You can use the same namespace trickery to redefine variables and even redefine subroutines outside of your own namespace. You can alter one npc's behavior via another or via plugin or via #peval on the command-line.

As far as the flag stuff goes, I have been reticent to comment. My personal opinion is that the code I saw for it was kludgy and fundamentally broken. Moreover, I am not the maintainer of the code and have no control over what goes in and what does not. Since your question was kind of leading w/ the stipulations of being "in the know" and whatnot, I wasn't sure I should comment.

[mollymillions]

Thanks Eglin.