quest_globals broken?

[Angelox]

When it comes to c++, i'm still at the "what if" stage; you know, "what if i took this line here, and put it there ...", "ooops! doesnt work now" . Ok then, "What if ...", or "what if ...".
This can go on for days, and is an indicates i don't know a rat's-ass of what I'm doing .
Probably, it's sort of a "romantic" era of programing, when something actually works , it feels like a child finding the prized easter-egg in a Easter-hunt.
Eventually, all the pieces of C might begin to fall in place, then I'll move into the "What does this mean?" stage, which can be very annoying to some people.
Anyways, I hope you all figure it out. I must have made 50+ pl's that use quest_globals.

[totalcynic]

This maybe off base, but I think the reason that the items are getting deleted is because the expdate field should be set to the current time, in UNIX_TIMESTAMP format, + the number of seconds you want to retain it. Setting it to 0, as in the examples, will result in the code deleting the rows because of the condition.

Are you trying to create infinite timeouts ? If so then this would be a simple fix to the SQL, just with an expansion on the condition so that it read;

where (expdate < UNIX_TIMESTAMP() and expdate != 0)

This would allow for expdate=0 to be inifinite, assuming its just the timeout that is at fault.

[Angelox]

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

"DELETE FROM quest_globals WHERE expdate < UNIX_TIMESTAMP() and expdate != 0) || (name='%s' && npcid=%i && charid=%i && zoneid=%i))"

there was two entries like that so I changed it also,

"DELETE FROM quest_globals WHERE expdate < UNIX_TIMESTAMP() and expdate != 0) || (name='%s' && npcid=%i && charid=%i && zoneid=%i))"

The problem still is there, quest_globals poofed.

[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

[John Adams]

Ax, let me chime in for a moment. I ran the Wizard Epic quest, Camin NPC in Erudnext to be exact. He sets a quest global when you hand him 1000pp. Before my test, I had no records in the table. After handing him the 1kpp, a record was inserted:

id  1
charid  1
npcid  24004
zoneid  24
name  wizepic 
value  1 
expdate  2147483647

The PL file that set this looks like this:

quest::setglobal("wizepic",1,0,"D30");

(assuming D30 means 30 days?)

To delete the global, you hand him Ro's Breath (item 14330):

	#Ro's Breath handin
	if(int($wizepic) == 1 && $itemcount{14330} == 1){
		quest::say("Very interesting... I've seen this work before. Yes, yes! It's the work of Arantir Karondor! Give this back to the person you got it from. Maybe he will have a clue to Arantir's location.");
		quest::faction(342, 30); #Truespirit
		quest::exp(10000);
		quest::summonitem(14331);
		quest::delglobal("wizepic");
	}

This is where my test fails. The handin of item 14330 is true, but the test if $wizepic seems to be failing. I feel the int($wizepic) value is not getting set.

I removed that check, and the script (including the delglobal) works perfectly.
So, this worked:

	#Ro's Breath handin
	if($itemcount{14330} == 1){
		quest::say("Very interesting... I've seen this work before. Yes, yes! It's the work of Arantir Karondor! Give this back to the person you got it from. Maybe he will have a clue to Arantir's location.");
		quest::faction(342, 30); #Truespirit
		quest::exp(10000);
		quest::summonitem(14331);
		quest::delglobal("wizepic");
	}

I noticed the $itemcount uses curly {} instead of parens. Must be some perl'esque thing.

I also turned on #mlog setcat QUESTS on to see what shows up. I am getting feedback in eqemu_quest_zone.log that looks like this:

5685 [12.28. - 21:50:08] Use of uninitialized value in numeric eq (==) at quests/erudnext/Camin.pl line 14.
5685 [12.28. - 21:50:08] Odd number of elements in anonymous hash at quests/erudnext/Camin.pl line 19.
5685 [12.28. - 21:50:08] Use of uninitialized value in anonymous hash ({}) at quests/erudnext/Camin.pl line 19.

Confident I created the last 2 warnings by putting curlies {} around $wizepic just to see what happened.

Not completely sure what that means. I'm a bit sleepy, so the test on int($wizepic) is the only thing I find that's failing right now. Does this jive with what you're finding?