[Bulle]

Your post triggered the "WEIRD" warning to me Trevius, so I spent a while today to look into it. I would like my conclusions to be validated by other EQEmu "hackers", so take them with the adequate grain of salt, but here they are.

To make it short I have two news : one good and one bad.
The good one is that there is a solution to your problem : switch from "$max_level" to "$qglobals{max_level}", supposedly the up-to-date way of checking quest globals. For all your variables, no exception.
The bad one is : checking quest globals through the use of "$XXX" variables is bugged. This is especially bad for PEQ quests, because there are a lot that work this way.

I have tried to reproduced your way of working on one NPC (the guard in the room in front of Neriak entrance, DVin L`Crit, who had qglobal set to 1 of course). Here is the code :

my $LevelItemId = 1038; # Tattered Cloth Sandal
my $DefaultMaxLevel = 70;

sub EVENT_SAY
{ print $maxxx_level;

  if(($text=~/65/i) && ($ulevel >= 70))
  { quest::say("Remember, DO NOT lose that trinket ! Welcome to level 65 !");
    quest::summonitem(1038);
    quest::level(65);
  }
  
  if($text=~/make me level 71/i)
  { quest::say("OK, you're the boss after all *sigh*");
    quest::level(71);
    quest::setglobal("maxxx_level", 71, 5, "F");
  }
  
  if($text=~/make me level 72/i)
  { quest::say("OK, you're the boss after all *sigh*");
    quest::level(72);
    quest::setglobal("maxxx_level", 72, 5, "F");
  }
  
  if($text=~/make me level 73/i)
  { quest::say("OK, you're the boss after all *sigh*");
    quest::level(73);
    quest::setglobal("maxxx_level", 73, 5, "F");
  }
  
  if($text=~/make me level 74/i)
  { quest::say("OK, you're the boss after all *sigh*");
    quest::level(74);
    quest::setglobal("maxxx_level", 74, 5, "F");
  }
  
  if($text=~/make me level 75/i)
  { quest::say("OK, you're the boss after all *sigh*");
    quest::level(75);
    quest::setglobal("maxxx_level", 75, 5, "F");
  }
}


sub EVENT_ITEM
{ if (plugin::check_handin(\%itemcount, $LevelItemId => 1))
  { if(defined($qglobals{maxxx_level}))
    { quest::say("Welcome back to level $qglobals{maxxx_level}, $name");
      quest::level($qglobals{maxxx_level});
    }
    else
    { quest::say("Welcome back to level $DefaultMaxLevel, $name");
      quest::level($DefaultMaxLevel);
    }
  }
  else
  { plugin::return_items(\%itemcount);
    quest::say("I have no use for this item, $name.  Take it back.");
  } 
}

Yeah I have used tattered sandals for the levelling item, I have been a fisher on Live for too long

As it is there is no side-effects across PCs. If you replace the $qglobals{maxxx_level} by $maxxx_level there is a side-effect from one PC to another if the PC has no $maxxx_level set for himself. Basically if your PC already has a maxxx_level (of say 72) Perl will use it. If the PC has never done your quest and set the $maxxx_level, then it uses the one the NPC has seen last, ie the variable is not reset to "undef". May be this is why you tried to "undef" it, but I did not try this, and from your experience it does not work that well. My experience is that the Emu does not "undef" a variable (which answers a question I had a few months ago in fact).

I had a quick look at the C++ code in the server, and it confirmed my suspicions : the "$qglobal" map is created anew each time the NPC evaluates its scripts (in fact for each event), it is a C++ variable globhash that is redeclared, hence reinitialized with each call. This is not the case for the $variables, which are only overwritten with new values. They are not undef'ed first (file embparser.cpp, lines 189+), there is no call to something reinitializing the Perl local/global environment, if it were at all possible anyway.

I see only two ways to address this :
* everybody switches to $qglobals{XXX} and we forget about the old "unperfect" bugged way. It has been hinted at for a long time, but I guess legacy quests slowed this to a halt.
* the C++ code is fixed to clean the Perl environment of all "stale" variables from a previous call to the event before the new one is run. It may be impossible (or very hard and unclean) to do.

As it is though, the problem may impact PEQ quests as it is general. Finding an example of a "broken" behaviour may be tough, but the potential is there. Think "exploit" here.

It would be nice if a developer or a PEQ maintainer could express their views on the subject.

As to me, I will be switching to $qglobals for my generated quest code.

I hope this long diatribe clears it up for you.