quest_globals broken?

[eq4me]

Originally Posted by Angelox

I made these changes in questmgr.cpp and compiled/tested

...

The problem still is there, quest_globals poofed.

There are more changes in embparser.cpp. See my two last posts.

[Angelox]

Originally Posted by eq4me

There are more changes in embparser.cpp. See my two last posts.

You fix them for me and I'll test?
Believe me, my time is *much* better spent with MySql database and Perl quests.

[Aerewen]

Angelox I regret to inform you that I've destroyed your quests for the tutorial :p
I'm in the process of re-writing them to flow like the live server does.. if you're around... im gonna be playing with them on the Allendium EQ server here as soon as i boot it back up

[Angelox]

Originally Posted by Aerewen

Angelox I regret to inform you that I've destroyed your quests for the tutorial :p
I'm in the process of re-writing them to flow like the live server does.. if you're around... im gonna be playing with them on the Allendium EQ server here as soon as i boot it back up

No problem, you should try and keep the names of others who worked on them in there also - aside from self-satisfaction of acompishment, the only other reward you get here is some recognition.
And, I hope you feel inclined to become more of a "public servant" and post for all. EqEmu is in desperate need of programmers, zone-spawners, perl-questors , in a "public" manner.

[Aerewen]

Unfortunately i had to write all but 1 of them from scratch. I built the quest globals into them this time around. So now you have to speak to arias, then absor, then vahlara etc etc till you have finished the orientation... then you speak to arias again and get the kobold charm just like on the live servers.

once i have all the other quests finished i'll release them in a zip pack

[eq4me]

Originally Posted by Angelox

You fix them for me and I'll test?
Believe me, my time is *much* better spent with MySql database and Perl quests.

Sorry, no time. It's the 'What was not important enough to priorize the whole year but must be done in 2006 ... somehow' time at work. I still try not to do overtime work but I am in no mood to sitting in front of a computer after work.

[John Adams]

I sympathize, eq4me. We had so many v1's out the door the last month, and my own product I am the lead on (just shipped last Fri), I barely had time to harass the noobs here lately. I think we're clear to have a life until Jan 2nd, to start meeting the unrealistic Q1 sales goals.

[totalcynic]

I'll take a look at it again later today, been called into work to fix a mail server issue even though I was on holiday. So I know exactly what you guys are on about.

[totalcynic]

Ok, there were three places that deleted from global_quests by time, there are others which don't use time and don't seem to be relevant in this situation. Using your test data Angelox, and assuming you were trying to get an infinite timeout, then I believe I have achived the objective with the patch which can be found at;

http://www.totalcynic.plus.com/globa...o-expire.patch

This requires patch -p1 to be used, but what doesn't

Give this a try, and if all is well and no one objects, then I will submit it into the development area for inclusion in a future release. It just makes the expdate of 0 never timeout, and also includes the SQL fixup for MySQL 5.1 with the items query.

I would, though, recommend using a timeout as this allows for the code to automatically manage the data set, and helps keep the number of rows in the table down, which helps to speed up look ups. If your doing a direct insert into global_quests have you tried using something like "UNIX_TIMESTAMP(date_add(now(), INTERVAL 7 DAY))" for the value of expdate, which sets it to 7 days into the future.

Hope this helps.

[Angelox]

Originally Posted by totalcynic

Ok, there were three places that deleted from global_quests by time, there are others which don't use time and don't seem to be relevant in this situation. Using your test data Angelox, and assuming you were trying to get an infinite timeout, then I believe I have achived the objective with the patch which can be found at;

http://www.totalcynic.plus.com/globa...o-expire.patch

This requires patch -p1 to be used, but what doesn't

Give this a try, and if all is well and no one objects, then I will submit it into the development area for inclusion in a future release. It just makes the expdate of 0 never timeout, and also includes the SQL fixup for MySQL 5.1 with the items query.

I would, though, recommend using a timeout as this allows for the code to automatically manage the data set, and helps keep the number of rows in the table down, which helps to speed up look ups. If your doing a direct insert into global_quests have you tried using something like "UNIX_TIMESTAMP(date_add(now(), INTERVAL 7 DAY))" for the value of expdate, which sets it to 7 days into the future.

Hope this helps.

Thank you! I will be testing and will tell you how it worked.

[Angelox]

Sorry to be late on this-
I have patch, but I guess I don't know what I'm doing (common coming from me), as It doesn'y work, I did look at the patch file and changed the lines I saw there.
Maybe in the future (if you still want to do this) compress/post the changed files and Ill replace here.
I've tested as best I could, and here's the results;
when i first logged in the zone, The table held out, intact. Then I went to an Npc that use QGlobals, and hailed;
just a snip;

sub EVENT_SAY{
  if (($text=~/hail/i)&&(${$name}==2)){
    quest::say("I'm glad you managed to escape the slave warrens in one piece. There are many [others] who were not as lucky.");
  }
  if ($amote==2){
    quest::spawn2(189119,0,0,-126.0,-295.8,3.0,124.8);
  }
  if ($bmote==2){
    quest::spawn2(189120,0,0,-385.2,-516.3,-39.3,135.1);
  }
 if (($text=~/hail/i)&&(${$name}!=2)){
    quest::delglobal("$name");
    quest::setglobal("$name","2","3","F");
    quest::summonitem(59943);
    quest::say("I have something that might save you from the same fate. Take this kobold charm. May it bring you good luck, $name.");
  }

This made the quest global for $name, and spawns two more npcs that use quest globals;
one of the two;

sub EVENT_SPAWN
{
	$x = $npc->GetX();
	$y = $npc->GetY();
	quest::set_proximity($x - 50, $x + 50, $y - 50, $y + 50);
	quest::delglobal("amote");
	quest::setglobal("amote","3","3","F");
	$amote=undef;
}

sub EVENT_ENTER
{
	quest::emote("A vast mine lays before you. From deep within the mine you can hear the clanging of pulleys and carts. It appears as though they are inhabited . . .");
	quest::depop();
	quest::delglobal("amote");
	quest::setglobal("amote","2","3","F");
	$amote=undef;
}

What normaly happens is She gives you a charm, then spawns the "emoters" so you get the emotes as you start the dungeon - she sets a global, so you don't get dupe messages, and the emoters change already set global flags so she doesn't keep spawning more emoters, when they "depop", they set globals back again. for the next player who hails the npc. This slows the emotes down and make them appear on and off, and usually to new players.

It worked a little with your fixes, but is still broken.
this works one time;

if (($text=~/hail/i)&&(${$name}!=2)){
    quest::delglobal("$name");
    quest::setglobal("$name","2","3","F"); < sets to 2 instead of wanted 3 three
    quest::summonitem(59943);
    quest::say("I have something that might save you from the same fate. Take this kobold charm. May it bring you good luck, $name.");
  }

The emoters delete their globals but do not make new ones, so they never appear again.

this works;
quest::delglobal("amote");
this doesn't
quest::setglobal("amote","2","3","F");

And even with the global set it goes to a flag where you keep getting duped with charms.

Here's the full pl so you understand the globals I did there;

http://www.nahunta.org/~angelox/files/Vahlara.pl