"Heading" issue

[John Adams]

I've been fixing doors in the emu for a year, and one thing I've noticed is that sometimes they swing the right way, but most times (90%, no kidding), I have to fix the open_heading to be 180 degrees from what I get from Live. All along, I assumed this was just some bad math in the collector, parser, or world... and didn't cry too much. But something came up today that makes me think World is the bad guy. Here's what happened.

I was setting up zone-in coords for Thieve's Way for our Freeport hoods. Had a client opened to my Live account, and another to Emu. I would click the manhole in a hood to go to Thieve's Way, do a /loc of the Live characters landing coords, and plug them into the spawn_sign record in Emu. When I would then test this new setting, I am finding that using the EXACT coords in Live, my character is always facing 180 degrees the wrong way. Even though both /loc statements are identical.

I can proving scientific proof of this if forced to, or you can just believe my extensive analysis. Thing is, not all "heading" values in Emu seem wrong... since NPCs obviously spawn the right way from parsed data (well, most of the time). In situations where there is a double-door, one usually swings the correct direction while the other swings the opposite - requiring a door fix in the DB. I would say almost everything EXCEPT door swinging and player zoning, heading is right on.

Any thoughts? If this turns out to NOT be a bug, we can move the thread elsewhere to help educate me and others on how heading works.

Thanks for thinking it over.

[LethalEncounter]

If I remember correctly, the parser tries to determine the correct open heading, but sometimes it doesn't get them right. About the signs, is this only an issue for zone points based on signs? Also when you "land" in the new zone, the client tells you it is heading in the exact same heading as on Live, but the directions aren't the same?

[John Adams]

If I remember correctly, the parser tries to determine the correct open heading, but sometimes it doesn't get them right.

You are right on about this. open_heading is right maybe 50% of the time for doors.

About the signs, is this only an issue for zone points based on signs?

Yes, sign post signs and shop signs never appear to be the wrong direction - though some do not show up at all in the visible zone, but off-boundaries in that mysterious 0,0,0 location (like if include_location = 0). Still working on that. I got some prime examples of this oddity in North Freeport right now. Zone from N.Freeport to Stonestair for instance, the "size" (zone) is spawned, just off the screen somewhere.

Also when you "land" in the new zone, the client tells you it is heading in the exact same heading as on Live, but the directions aren't the same?

This is correct. Example of this is Thieve's Way to Stonestair. In live, both chars are facing 220 degrees (I think) but physically, standing 180 degrees different... even tho /loc shows exact same coords. I'll do more testing on other zone points to see if it happens everywhere, or just this one zone(?)

[LethalEncounter]

That is definitely strange then, because the /loc command is a client side command. I'm not sure how we are able to confuse the client into thinking it is facing a direction that it is not.

[John Adams]

My theory is that we're just zoning wrong, though the proper coords were sent. What I'll try do to next time is nudge my toon forward a step and take a new /loc, see if the value for heading changes much.. expecting a 180.

Either that, or there's something about client-side heading we do not yet understand. Maybe our world is backwards!