quest::movepc()

[Lillu]

Thanks for the workaround Derision, works perfectly!

[neiv2]

Thanks, Derision, but for some reason it's still not working. Here is the script for my transporter NPC:

sub EVENT_SPAWN
	{
	$x = $npc->GetX();
	$y = $npc->GetY();
	quest::set_proximity($x - 60, $x + 60, $y - 60, $y + 60);
	}

sub EVENT_ENTER
	{
	$client->SetHeading(0);	
	quest::movepc(16,-63,-802,59);
	}

The transporter stands at a point that forces a PC to enter his proximity at a heading of SE. When the PC enters the proximity of the transporter, I can see by my compass that the heading changes from SE to N right before zone (hence, the $client function is working, at least initially). However, when I land in the destination zone, I end up facing SE again.

Lillu, I'd be interested in knowing if my script works on your server (particularly, whether you end up facing North in Beholder coming from a heading of SE in the sending zone as you enter the transporter's proximity using my script). I'd also like to see if I can reproduce your results with the script that you said works perfectly. Could you post that script here? Thanks.

[Derision]

You will need to put a heading parameter in the quest::movepc call. Any heading, it doesn't matter what. If you leave the heading parameter off, it will default to a heading of zero.

If there is a heading there, the bug in the code prior to 1063 will mean it will use whatever heading you are currently facing, which should be the heading you set with $client->setheading().

This is the quest I used to to test the workaround:

sub EVENT_SAY {
        if($text=~/Hail/i){
                quest::say("I am Guard Philbin.");
                $client->SetHeading(45);
                quest::movepc(2, -223, 694, 4, 128);
        }
}

And I ended up in North Qeynos with a heading of 45.

Edit: After reading your post again, my explanation doesn't make sense, but try putting a random heading in the movepc call and see if it uses the heading from your $client->SetHeading call

[neiv2]

Thanks, Derision; that failed to work as well. My code now looks like this:

sub EVENT_SPAWN
	{
	$x = $npc->GetX();
	$y = $npc->GetY();
	quest::set_proximity($x - 60, $x + 60, $y - 60, $y + 60);
	}

sub EVENT_ENTER
	{
	$client->SetHeading(0);	
	quest::movepc(16,-63,-802,59,0);
	}

I also tried plugging in your headings, and placing the $client function after the quest::movepc function, and got the same results.

[neiv2]

I did some further testing on this and found an oddity. I changed the event from an ENTER to the following SAY, and it works:

sub EVENT_SAY
	{
	if($text=~/Hail/i)
		{
		quest::say("You are taking a dangerous road, $name.Beware.");
		$client->SetHeading(255);
		quest::movepc(16,-63,-802,59,255);
		}
	}

The PC successfully faces north (incidentally, I tried 0 in place of 255--which should also face north--and it it ignored). When I change it back to an ENTER event, . . .

sub EVENT_SPAWN
	{
	$x = $npc->GetX();
	$y = $npc->GetY();
	quest::set_proximity($x - 60, $x + 60, $y - 60, $y + 60);
	}

sub EVENT_ENTER
	{
	quest::say("You are taking a dangerous road, $name. Beware.");
	$client->SetHeading(255);
	quest::movepc(16,-63,-802,59,255);
	}

. . . the heading is again ignored, and I simply land in Beholder facing SE again. The only difference between these scenarios is the event I am using. I am facing the same direction when triggering both events, and the functions are otherwise identical. Is it possible it it the ENTER event that is broken and not the quest::movepc() function?

[Derision]

I found the same thing (works in EVENT_SAY but not EVENT_ENTER). Even the fix I made in Rev1063 behaves oddly in EVENT_ENTER, even though it worked fine in EVENT_SAY.

I'll take another look at it in the next day or two.

[Derision]

I've spent some time looking at this and it appears to be a timing issue.

I.e., we call $Client->SetHeading(0), but then the server receives an update packet from the client with it's current x,y,x location and heading, so we set the heading back to what it was.

Even if I call $client->SendPosUpdate(2) after $client->SetHeading, the server receives a packet from the client with the old heading.

I assume the client is sending updates faster when moving, which is why the problem is seen using EVENT_ENTER and not using EVENT_SAY (when the client is typically standing still to hail the NPC).

I can't think of any easy workaround, other than to set a flag indicating that the client is about to zone and ignoring any client update packets if that flag is set.

[Akkadius]

Originally Posted by neiv2

I did some further testing on this and found an oddity. I changed the event from an ENTER to the following SAY, and it works:

sub EVENT_SAY
	{
	if($text=~/Hail/i)
		{
		quest::say("You are taking a dangerous road, $name.Beware.");
		$client->SetHeading(255);
		quest::movepc(16,-63,-802,59,255);
		}
	}

The PC successfully faces north (incidentally, I tried 0 in place of 255--which should also face north--and it it ignored). When I change it back to an ENTER event, . . .

sub EVENT_SPAWN
	{
	$x = $npc->GetX();
	$y = $npc->GetY();
	quest::set_proximity($x - 60, $x + 60, $y - 60, $y + 60);
	}

sub EVENT_ENTER
	{
	quest::say("You are taking a dangerous road, $name. Beware.");
	$client->SetHeading(255);
	quest::movepc(16,-63,-802,59,255);
	}

. . . the heading is again ignored, and I simply land in Beholder facing SE again. The only difference between these scenarios is the event I am using. I am facing the same direction when triggering both events, and the functions are otherwise identical. Is it possible it it the ENTER event that is broken and not the quest::movepc() function?

Perhaps have the '$client->SetHeading();' process AFTER quest::movepc();

[wwarff]

Thanks Akkadius. I tried that too, same result. It works with a SAY command but since I'm trying to use the ivisible man proximity script it makes the "hail" portion useless. I can get them to speak and port me, but not set my heading right. I have been trying to find an easy way to find all of the 0,0,0,0 hardcoded zonepoints somewhere. (That way I wouldn't need to even use the proximity method for zoning) I've slowly been logging into live and grabbing them but with over 1000 of them in the database it will take quite some time to do.