EQEmulator Forums - quest::movepc()

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Quests::Q&A (https://www.eqemulator.org/forums/forumdisplay.php?f=599)

- - quest::movepc() (https://www.eqemulator.org/forums/showthread.php?t=30155)

neiv2

12-25-2009 08:10 PM

quest::movepc()

Is there some way to determine the heading a PC ends up facing when using quest::movepc()? The current syntax allows for zoneid, x, y, z, but not heading; e.g.,

quest::movepc(117,-931,-3471,182);

Any workaround for this?

cavedude

12-25-2009 08:28 PM

movepc does allow for heading. I added it myself ages ago.

neiv2

12-26-2009 12:28 PM

I'm using this list, which I assume is current. Taking my former example, namely:

quest::movepc(117,-931,-3471,182);

I want the pc to zone into Beholder at the specified x,y,z coords and face north. Here is what I've tried so far:

quest::movepc(117,-931,-3471,182); works, but faces south.

quest::movepc(117,-931,-3471,182, 3); works, but faces south. Faces south no matter what value I enter in place of 3.

quest::movepc(117,-931,-3471,182, heading=3); breaks quest script, will not zone pc.

The final example is the one provided in the QuestTutorial linked above. Am I misreading this somehow?

Wesell

12-26-2009 02:13 PM

What happens when you try this?

Code:

quest::movepc(117,-931,-3471,182, $client->GetHeading())

neiv2

12-26-2009 03:54 PM

That didn't make a difference since the client direction in the sending zone is opposite the intended client direction in the destination zone. The client direction when zoning is SE, but I want the client to face north in the destination zone.

joligario

12-26-2009 05:35 PM

Create a second spawnpoint, despawn the NPC when it arrives and respawn it on that spawnpoint with whatever heading you want.

cavedude

12-26-2009 07:01 PM

The syntax is quest::movepc(zone,x,y,z,h); I did update the wiki when I made the change, but it looks like those changes have been lost over time...

Heading worked when I was playing with it although I do remember it being buggy. I didn't actually work with the heading code, I just allowed movepc to have a user defined heading variable. If I remember, I had trouble too with north, but I think I finally got it by using a number out of the "normal" range (500 comes to mind for some reason) I find NPCs have the same trouble, and sometimes when I do a #spawnfix in-game, the NPC is given a really high heading number. It seems to work, though. I'm thinking it's because the client and the server have a different view on heading.

But then again, the change I made was probably over 2 years ago now. It is plausible that somebody could have made a change to something else that broke movepc, or heading in general.

neiv2

12-26-2009 11:15 PM

Yeah, it appears it is indeed broke. I tried using 255 (which generally faces north as well) in place of the 3, and then tried 500 (per your suggestion), and neither one makes any difference in the heading.

fyi, joligario, it looks like your reply was intended for a different thread : )

Wesell

12-27-2009 12:58 AM

Is the client turned to face south after movepc or is the heading simply left at whatever it was?

KLS	12-27-2009 02:38 AM

I'll take a look at it when I get a chance, I'm working on something else atm so it might be a bit if anyone else wants to.

Derision

12-27-2009 07:05 AM

This should be fixed in Rev1063.

joligario

12-27-2009 07:34 AM

Quote:

Originally Posted by neiv2 (Post 181996)

fyi, joligario, it looks like your reply was intended for a different thread : )

Sorry, wasn't paying attention. Thought you were moving an NPC rather than PC... That's what I get for using an iPod!

neiv2

12-27-2009 04:36 PM

Wessel, the client faces the same direction in the destination zone that he faced when he ran into the proximity of the transporter from the departing zone (south in both cases). I'm trying to force him to face north in the destination zone.

KLS, thanks for your response.

Derision, I'm using the latest AX repack, which appears to be based on r1048.

Derision

12-28-2009 05:44 AM

As a workaround, until you are able to upgrade, you could call $client->SetHeading(<heading>) right before quest::movepc.

Lillu

12-28-2009 06:56 AM

Thanks for the workaround Derision, works perfectly!

neiv2

12-29-2009 02:43 PM

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

Code:

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

12-29-2009 03:30 PM

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:

Code:

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

12-29-2009 04:33 PM

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

Code:

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

12-29-2009 05:08 PM

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:

Code:

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, . . .

Code:

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

12-29-2009 05:25 PM

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

12-30-2009 11:48 AM

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.

wwarff

08-31-2010 04:36 PM

Has anyone been able to figure out a way to fix the heading coord error using an EVENT_ENTER yet? Derision, How would I go about setting a flag for something like what you mention here?

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.

Sorry to open an old can of worms but sometimes entering your target zone will put you in the completely opposite direction pointing you right back to the zone you came from and it has been awhile since the last post on this thread.... Thanks for any suggestions. :)

Akkadius

08-31-2010 05:04 PM

Quote:

Originally Posted by neiv2 (Post 182128)

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:

Code:

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, . . .

Code:

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);

        }

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

wwarff

08-31-2010 09:19 PM

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.

Packet

04-27-2011 08:04 PM

I know this is an old post but I thought I might add some input on this. For those of you working on quest::movepc and getting frustrated with heading not working, I wrote up this work-around.

quest::movepc() still does not work with changing the heading upon zone-in as of 5/27/2011 so I wrote this up real quick. It modifies the /template/player.pl to check coords upon zone in. If the X & Y coords match perfectly, it will update your heading to whatever is specified in the var under each if statement. There are better ways to accomplish this I am sure however this is how I got around it.

Also if you are considering adding this in, I might recommend adding a zone_id check before running the coord checks considering it would be highly unnecessary to run a massive list of coord checks on every single zoneline that is hit.

/quests/template/player.pl
------------------------------

Code:

sub EVENT_ENTERZONE {

#Zone Name - X  - Y or it jacks up the $cy/$cx variables. Last time I used one, it gave me a 324.24920492094 for $cx in freeport.

my $cx =  $client->GetX();

my $cy = $client->GetY();



if($cx == "324" && $cy == "-432") { #Freeport Port-in XY coords

my $fp_head = 220; #Var containing heading.

$client->SetHeading($fp_head);

$client->SendPosUpdate($fp_head);

$client->Message(15, "Your XY Coords are - X: $cx Y: $cy"); 

$client->Message(15, "Sucessfully modified your heading to $fp_head. Check by typing #loc."); 

}

if($cx == "-66" && $cy == "658") { #Qeynos Port-in XY coords

my $qy_head = 220; #Var containing heading.

$client->SetHeading($qy_head);

$client->SendPosUpdate($qy_head);

$client->Message(15, "Your XY Coords are - X: $cx Y: $cy"); 

$client->Message(15, "Sucessfully modified your heading to $qy_head. Check by typing #loc."); 

}

}

And this is a teleporter to test with if you'd like to try it.

Code:

sub EVENT_SAY {

if($text=~/hail/i) {

quest::say("Hi! I can take you to [Qeynos] or [Freeport]. Choose whichever you would like.");

}

if($text=~/qeynos/i) {

quest::movepc(2,-66, 658, 3, 113); #Qeynos Coords

}

if($text=~/freeport/i) {

quest::movepc(9, 324, -432, -24, 202); #Freeport Coords

}

}

Anyways, I apologize for reviving an old thread. This was irritating me earlier and I hope it may help someone else.

(Edit: Final note, if this doesn't work then you probably have a player.pl file already in the zone folder (/quests/zonename/) which is causing /templates/player.pl to not run.)

All times are GMT -4. The time now is 10:40 AM.