Complaint about Lax's complaint =)

Plazmic · Post by **Plazmic** » Thu Apr 08, 2004 4:20 pm

Say you want to know what direction to move to get to your target. With MQ2Parm, you would use "$target(headingto)" or "$heading($target(y),$target(x))" -- or maybe it was $heading($target(x),$target(y)), but I cant even tell you that because of the mechanics of x y and z in MQ2Parms. The problem with x y and z is that MQ2's x isnt the same as what you would call EQ's x, for a very silly reason. Someone decided that EQ's x is "wrong" and that x most definitely must be a certain direction on the map, and y most definitely must be another certain direction on the map. This led to $char(x), $char(y) not being the same as you would see in /loc.

Whatever... EQ is messed up, MQ just followed their rules...

Copied from CVS:

Code: Select all

    // $target(x)
    } else if (!strncmp("target(x)",szVar,9)) {
        CHAR szTemp[MAX_STRING] = {0};
        i+=8;
        if (!psTarget) {
            strcpy(szOutput,"0");
        } else {
            sprintf(szTemp,"%1.2f",psTarget->X);
            strcpy(szOutput,szTemp);
        }

    // $target(y)
    } else if (!strncmp("target(y)",szVar,9)) {
        CHAR szTemp[MAX_STRING] = {0};
        i+=8;
        if (!psTarget) {
            strcpy(szOutput,"0");
        } else {
            sprintf(szTemp,"%1.2f",psTarget->Y);
            strcpy(szOutput,szTemp);
        }

and if I remember correctly, South and East are positive numbers... which is why heading was such a code fuck.

Lax · Post by **Lax** » Thu Apr 08, 2004 4:26 pm

Yeah I know

As far as people using macros or such though, seeing something different with X Y Z than you would see with /loc is confusing, and the heading is counterclockwise which doesnt make sense to most people

Ahh well, no big deal. I put it in-game order so it shouldnt be as confusing on the outside... no matter how much we cringe at things internally

Plazmic · Post by **Plazmic** » Thu Apr 08, 2004 4:35 pm

As far as people using macros or such though, seeing something different with X Y Z than you would see with /loc is confusing

EQ's /loc command returns Y X Z in that order...

the heading is counterclockwise which doesnt make sense to most people

Heading was directly based off of EQ's heading

Lax · Post by **Lax** » Thu Apr 08, 2004 4:47 pm

Yes thats exactly the problems!

To a player that doesnt inherently know that x and y are flipflopped and y is itself flipflopped, /loc reads "x, y, z"... and a compass heading is clockwise with 0/360 to the north, 90 to east, 180 south, etc.

Anyway, to the player, the expected way is the right way. To EQ, their geometry is the right way. So really there's two right ways, MQ2Data is displaying the player-expected right way.. EQ has the EQ-expected right way

Plazmic · Post by **Plazmic** » Thu Apr 08, 2004 4:55 pm

And who using MQ doesn't have their brain trained to EQ geometry?
Everyone I know that played EQ (including the non-MQ crowd) before the New UI came out KNOWS without thinking that it's Y,X... switching it now will confuse people more.
How many people did a /loc, step /loc to find out heading?

Oh, and:

To EQ, their geometry is the right way.

Nope, look at OOT =)

Also: semi-correction from earlier.. North and West are positive, my post before was backwards.

Lax · Post by **Lax** » Thu Apr 08, 2004 4:59 pm

probably 80% of MQ users dont have their brain trained to eq geometry and/or are confused about how the hell its working

better now than never, while people are converting their stuff to mq2data anyway

Amadeus · Post by **Amadeus** » Thu Apr 08, 2004 5:00 pm

I can safely say I don't give a fuck

....but it's kindof fun to watch you guys fuss over this

Plazmic · Post by **Plazmic** » Thu Apr 08, 2004 5:02 pm

yup, better train them now to use EQ's system.

You expect people to have to translate /loc coordinates into MQ coordinates to write a macro?
Or do you propose to switch the West positive system along with the /loc command to display X,Y ... causing discrepancies between running MQ and not running MQ?

Plazmic · Post by **Plazmic** » Thu Apr 08, 2004 5:03 pm

Amadeus wrote:I can safely say I don't give a fuck :lol: ....but it's kindof fun to watch you guys fuss over this ;)

This is actually kind of important at a fundamental level =)

Lax · Post by **Lax** » Thu Apr 08, 2004 5:16 pm

You expect people to have to translate /loc coordinates into MQ coordinates to write a macro?
Or do you propose to switch the West positive system along with the /loc command to display X,Y ... causing discrepancies between running MQ and not running MQ?

I don't change west-positive, ${Me.X}, ${Me.Y}, ${Me.Z} is the same as you see in /loc

Someone said we should just flop /loc around but then imagine trying to direct someone to your loc and you're saying 10000, 0 when you're really at 0, 10000

All I've done is made the MQ2Data system use X and Y in the order you would expect something to use them under normal circumstances... I wrote Math.Distance for example to take X,Y because i didnt realize the MQ2Parm's $distance took Y,X, so there was some problems reported when someone was trying to use the backwards coords to get the distance to a loc. Whether - or + means left right up or down really makes no difference, but it's nice to be able to see it in the same order as /loc and have the heading clockwise from north. This is all just cosmetic changes on the outside of MQ2Data, the heading type takes in the backwards heading that EQ uses and does 360-heading to get the expected heading.

Plazmic · Post by **Plazmic** » Thu Apr 08, 2004 5:26 pm

I wrote Math.Distance for example to take X,Y because i didnt realize the MQ2Parm's $distance took Y,X, so there was some problems reported when someone was trying to use the backwards coords to get the distance to a loc.

So you propose a half breed system where things are reported Y,X and input is formatted X,Y?

As per what you said earlier

To a player that doesnt inherently know that x and y are flipflopped and y is itself flipflopped, /loc reads "x, y, z"...

So, if people THINK /loc reports X,Y ... and then try to use your (commented/documented) function of X,Y ... they will be fucked.
If they don't read the documentation, and just put use the same order (as they could do before), they are still fucked...
...which means the "80% of MQ users dont have their brain trained to eq geometry" are going to be posting support questions.

How exactly will this create LESS confusion?

I have no issues on Heading... I never took time to massage that one, and since it isn't reported by EQ, it's not a discrepancy to any "official" game data.

Lax · Post by **Lax** » Thu Apr 08, 2004 5:49 pm

Sort of.. What I'm saying is MQ2Data operates on the assumption that /loc reports X, Y, Z.. All in-game commands or MQ2Data objects should use that same assumption. I can't think of any actual /commands that use locs as parameters off the top of my head (possibly part of searchspawn), but anything showing up in game should shoot for this.

Everything in the actual MQ2 code, including the structs, still uses Y,X,Z.

So what happens is...
/echo ${Me.X}, ${Me.Y}, ${Me.Z} shows your loc the same as /loc
/echo ${Spawn.X}, ${Spawn.Y}, ${Spawn.Z} shows the spawn's loc as though you were there typing /loc
/echo ${Distance[${Spawn.X},${Spawn.Y}]} shows the distance from you to the spawn's loc, same as ${Spawn.Distance}
/echo ${Distance[0,10000]} shows the 2d distance from you to someone who says their loc is 0,10000
/echo ${Heading[${Spawn.X},${Spawn.Y}]} shows the heading from you to the spawn's loc, same as ${Spawn.HeadingTo}
/echo ${Heading[0,10000]} shows the heading from you to someone who says their loc is 0,10000

... so instead of the human having to swap X and Y in their head, MQ2 is doing it for them

All of these are documented as X,Y with this operating assumption. The old $parms are documented as Y,X..

$heading(y,x)
Returns the heading to a location

Plazmic · Post by **Plazmic** » Thu Apr 08, 2004 6:03 pm

Ok, you renamed X to Y and Y to X... the parameters are still (internally) the same. Just the user view of the name of the axis is different?!
This is even MORE asinine!!1!!one!!!tilde~

Now, all the good smart people who read the doc and know how the /loc command works get things wrong
(the doc says Heading[X,Y], so I flipped the coords I got from /loc since those are Y,X)

Did you think about other commands that accept Y/X coordinates (ie. /face loc y x)? I know they will "work" with your current setup, but you would stlil have to change the documentation for them and help syntax.

What about people mapping a route by using a map... another case to get the coordinates backwards using the new documented ordering.

The kicker:
What about a hypothetical macro that wants to stay out of the water in WK by making sure it doesn't go too far south (Y axis)... they have to compare against X now for south?!
I don't think it can get less logical than this.

Lax · Post by **Lax** » Thu Apr 08, 2004 6:15 pm

Yes. The documentation should be switched up to say x,y,z and not confuse people with saying the loc says y,x,z

For the Y=West thing, ignore the X Y Z that we all know are misnomers and lets call them 1 2 3. When you type /loc, you see (1), (2), (3). When you want to know how far on the 2nd plane you are moving in either direction, you compare to the second coordinate. Logically if you move back to X,Y,Z this should be Y.

Should we just call them (N)outh, (W)est, (U)p instead of X Y Z, since X Y and Z don't really imply any sort of direction?

How far north are you, how far west are you, how far up are you, etc... -1 would obviously mean the opposite direction. Or we could just add members called N W and U.

ml2517 · Post by **ml2517** » Thu Apr 08, 2004 6:16 pm

I'm sorry, this all started out with me asking to have the new parm stuff swapped from the x,y he had it at to y,x so it jived with the old parm.

Personally I don't have a problem with the new x,y,z format as long as the non-parm stuff that used locs gets updated to be the same. Otherwise, it'd just end up getting more confusing that it already is.