Complaint about Lax's complaint =)

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

I zone into West Karana, and run south from the barbie camp to the beach and do a /loc (or /echo ${Me.X} ${Me.Y} )
It displays -4100 -2100 (roughly)

I then write a macro that chases spiders and bears and such.
Part of it's logic is "if ${Me.Y}>-2100 then face heading 0 and run until ${Me.Y}<-2000" so it will run north away from the water if it gets too close.

This is even worse that I first portrayed the issue, since running north will NOT CHANGE "${Me.Y}"!!!!!!!!! We will be stuck running north into the north zone wall until the zone goes down.

This is utter BS... How does this make things work BETTER?!

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

Lax wrote: Logically if you move back to X,Y,Z this should be Y.

This isn't logic, this is EQ!

Should we just call them (N)outh, (W)est, (U)p instead of X Y Z

How naming them (F)red, (W)ilma, and (P)ebbles?
This is a normal 3D coordinate system... Just because VI decided that on a map that the Y axis should be listed first because people think about map directions with the Y axis first (it is Northeast, not Eastnorth) doesn't mean it isn't a normal system.

LordGiddion · Post by **LordGiddion** » Thu Apr 08, 2004 6:44 pm

I think I agree with Lax on this one, drop xyz, yxz all together and go with NWH = Norht West Height (sorry I think Height makes more sense then up - Up down usually reffer to looking up and down)

Then we can just tell people /loc is NWH and maybe note somewhere that N is often equated to Y and etc.

XYZ is geometry and EQ clearly is not the same.

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

I have to go to dinner so I'll stew on it and you stew on it and later we'll eat some stew.

Anyway IMHO its all about the perception. If you look at it on paper as Y being the north/south axis and X being the east/west axis, then it makes perfect sense for everything to be given Y,X,Z ... except for the whole thing about ordering not being X,Y,Z. If you look at it on paper as X being first coordinate, Y being second coordinate, Z being third coordinate, it makes perfect sense for everything to be given X,Y,Z ... except for EQ uses X for north and Y for west...

So as far as MQ2Data and /commands go...

We can call them ABC for all I care but if we want it to make sense to compare directionally, NWU might be the way to go. For it to make sense to compare to /locs given in game, XYZ is natural.

IMHO XYZ + NWU = the win. If you want to compare north/south you look at N, if you want to compare west/east you look at W, if you want to compare up/down you look at U. We can even alias E to -W, and S to -N, and D to -U.. If you want first loc you look at X, second you look at Y, third you look at Z.

No confusion from the hypothetical person wanting to stop at the north side of the water because they can use N to see how far north they are and stay north of where N is whatever the boundary is.

Imperfect · Post by **Imperfect** » Thu Apr 08, 2004 7:08 pm

The initial way this was done was to be consistant with EQs screwy coords. I find NO reason to change this since that has been working forever and will offer no real benefit. It is not a perf issue. So WHY on Ro's scorched Norrath would you want to change this now?

Plazmic · Post by **Plazmic** » Thu Apr 08, 2004 7:14 pm

If you want to compare north/south you look at N, if you want to compare west/east you look at W, if you want to compare up/down you look at U.

If you want to compare north/south you look at Y, if you want to compare west/east you look at X, if you want to compare up/down you look at Z.

We can even alias E to -W, and S to -N, and D to -U..

Ok, assuming you think that has use, we can discount your entire math background.

I am standing at /loc -4100 -2100
Let's see: W = -2100, N = -4100
The values E = 2100 and S = 4100 have absolutely no use in any coordinate system other than being a mirror image around 0,0.
Since the location 0,0 bears NO use in the EQ map layout, the mirror of a coordinate value has less than zero use =)
Maybe if the zone were a regular polygon with 0,0 located at the center there would be use for your E and S values.

daerck · Post by **daerck** » Thu Apr 08, 2004 7:36 pm

This isn't logic, this is EQ!

Actually it is quiet logical.
The essence of the problem is that mathematical and geographical locations are reported in a different format.

Any coordinate on a map is reported in latitude & longitude in the form of A° B' C'' N, D° E' F'' W (so a N,W format).
The mathimatical correct form would be to report a location on a graph as (X,Y) where X usually runs horizontally and Y vertically.
In other words, they are switched around.

EQ reports the location through /loc in a geographical latitude, longitude (, and height) format, which is just logical as the average EQ player uses the loc as a form of navigation, and not to solve mathematical equations.
Therefore, I'd prefer a NWH order. Whether you name them X,Y,Z or N,H,W or Bob, Mike and Joe doesn't really matter but the input order is much more "user-friendly" that way.

ml2517 · Post by **ml2517** » Thu Apr 08, 2004 7:51 pm

We also need to decide on heading as well. Its reversed from what it was, which of course f's up almost all of my macros.

Also, things like /face fast heading 90 you face West.

If you then do a ${Me.Heading.Degrees} it will spit out 270. The two need to be synced up. Personally I'm at the point now where I just want it back to the old way so that I don't have to rewrite half of the logic of my macros.

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

How do changes get made in a large community? Doesn't someone lay out the current scenario, and present arguments of why a new scenario is better?

Current facts:
Graphing coordinates: X = horizontal axis, Y = vertical axis.
Map coordinates: Lat(N) = veritical axis, Long(W) = horizontal axis.
Per axis direction: N = Y, W = X
/loc displays N W H, which yields Y X Z (logicially odd for graphing coordinates)

I don't remember any reasons for the YXZ -> XYZ change other than coords are supposed to be ordered X,Y,Z, and since renaming the X axis and Y axis to the Y axis and X axis as the sole remedy appears to have no merit other than to thoroughly confuse people, I will not argue it anymore, and hope everyone throws it out as a possible solution.

YXZ is the status quo (has been for the last 3 years) and as such doesn't need to prove its merit.
NWH would be no more functional, no faster, and require everyone to relearn how they think about coords.

NWH supporters need to make some points about WHY to change.
The only argument made for NWH is that the axis names are more appropriate.
Why go through the hassles of forcing everyone to relearn how to draw a map when the end result yields NO benefits?
What is the BENEFIT of changing from YXZ to NWH?

[As a side note, both the user variables and parm parser had been proven to suck serious ass before they were rewritten]

daerck · Post by **daerck** » Thu Apr 08, 2004 9:37 pm

Well, that's pretty much the reason why I rarely used $char(x) or $char(y) in my macros because it's confusing the shit out of me in the current system.

I used EQ for 3 years without MQ and got the system knocked into my head that the first coordinate (X) = N/S, the second one (Y) = W/E. Therefore all the commands asking for y x seemed to be backwards to me. Likewise, if I wanted to get my North-loc I would tend to use $char(x) since it's the first coordinate I'm using for navigation.
Axis and vars should be named in logically sequence of occurence. X, Y, Z is logical as the alphabetic sequence is the same as the sequence in which you get the values from EQ. N W H is descriptive and logical. Y, X, Z is logical when using a 3-d graph as the basis, but not logical in alphabetic sequence. I would guess that most people do not read a (EQ) map as a mathematical graph, but rather as a map, i.e. (1) horizontal, (2) vertical. Therefore labeling the coordinates in the order they are being read/used makes more sense to me.

NWH would be no more functional, no faster, and require everyone to relearn how they think about coords.

Faster? More Functional? certainly not. We are renaming something, not reinventing.
Requiring everyone to relearn how they think about coords? That's something we can argue about because the current system makes me rething the way I consider normal maps and var naming.
For you Y means the vertical axis, for me (and probably everyone else without a math degree) it rather implies 2nd variable.
And actually, I almost never label my axis' X and Y, but rather give them a name depending on what quantity/function they are representing - and the axis' themselves are called abscissa and ordinate; z-axis would be depth or elevation but I'm working wih statistical graphs rather than actual 3 dimensional spaces.

What is the BENEFIT of changing from YXZ to NWH?

As I mentioned before, it's more user friendly as the axis naming actually has a meaning and logical association in a map context.
It's probably of a matter of having more math geeks or more navigators around, though.

On a side note, can't YXZ and NWH coexist?

If you find any logical flaws or spelling mistakes you can keep them, it's 3am for me.

ml2517 · Post by **ml2517** » Thu Apr 08, 2004 9:39 pm

ml2517 wrote:We also need to decide on heading as well. Its reversed from what it was, which of course f's up almost all of my macros.

Also, things like /face fast heading 90 you face West.

If you then do a ${Me.Heading.Degrees} it will spit out 270. The two need to be synced up. Personally I'm at the point now where I just want it back to the old way so that I don't have to rewrite half of the logic of my macros.

Then again I guess I will just do:

Code: Select all

${Math.Abs[${Math.Calc[${Me.Heading.Degrees}-360]}]}

To convert the new style heading to the old parm heading. Its better than having to rewrite all of the logic in my macros.

Lax · Post by **Lax** » Thu Apr 08, 2004 11:00 pm

what you want isnt ${Math.Abs[${Math.Calc[${Me.Heading.Degrees}-360]}]} its ${Math.Calc[360-${Me.Heading.Degrees}]}

ok, going back over this since i'm home and a bit toasty/drunk/etc

first off mq2data is in phase 1 so obviously this is still up for debate, not laid in stone. either way, someone is going to end up having their way and the other isnt, and it really doesnt matter to me

#1 "it's been like this forever, why change it now" -- we're already breaking every macro and custom mq2 ui, now is the time for change if ever. if we are only talking about change and change is bad, we might as well keep mq2parm in the first place

#2 NW(U/H)/XYZ/YXZ really doesnt matter. there is obviously no speed benefit, there is obviously no technical merit, it all has to do with the way the information is presented to the end user. X and Y in MQ2Data at this point are exactly the same as Y and X in MQ2Parm. YXZ has been the "norm" for years de facto, not because it's better, or faster, or easier to understand, or any of the above. It's just because "well, we should use Y to mean north/south because that makes more sense". The simple fact is that neither XYZ or YXZ makes more sense, because there is a relevant argument against both, and in reality neither of us is ever going to win this kind of argument. Argument 1 is that "we've done it like this forever, why change it now, and X for east/west makes more sense on a cartesian plane than Y for east/west... why change it?". . Argument 2 is "Why is the second loc the first loc? Dont you read left to right instead of middle left right? And the cartesian plane is still backwards as it is because negative Y is east".. So it's a never-ending cycle. I'll change it back simply because the argument is impossible for either side to win, so someone has got to give. I'll give up my ego on this one and return to YXZ and keep friends.

There's no reason to drop XYZ or YXZ in favor of NWH/NWU, they would be one and the same. Just ways of saying the same thing in a different fashion, just like string.Equal[text] is the same as string.Compare[text]!=0. I would not be in favor at all of completely dropping the scheme for NWH/NWU.

As far as heading, clockwise is going to be the norm from now on, BUT I will add a counterclockwise option to the "heading" object... I'm not going to debate on this one about how people think in clockwise and MQ goes counterclockwise, sorry if you wanted to make that case ml2517

Notes:
graphing coordinates and people/map coordinates directly conflict as you and I have shown. I would opt in favor of the people coordinates for people functionality, and in favor of graphing coordinates for graphinc functionality... but I guess thats just me.

The values E = 2100 and S = 4100 would be of use to more easily represent being east/south of the origin. I'm just making the case for people here, people dont think in -W being E, they think in +E being E. An example use would be a UI that displays "###N ###W", "###S" "###W", "###N" "###E" etc as your loc, without having to ${Calc[-${Me.W}]}. I'd be the last one you have to explain to that they have no use other than that. On the other hand, this relieves said person of having to know in the first place that the coordinate system is based on NWH. Relieving the person of needing to know something in order to accomplish a task, without giving up basically anything, is good in my book. If we were talking about a big decrease in efficiency we'd obviously not be catering. There is no "technical" merit to having it, this is "aesthetic" merit without having a notable technical penalty.

Virtuoso65 · Post by **Virtuoso65** » Fri Apr 09, 2004 12:03 am

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

To solve the issue with pos and neg values for heading why not just use the values in terms of radians? This way you always have a posative value in terms of numaric heading.
Example, Pi=Π the board font doesnt like my Pi symbol.
North=0=2Π
West=Π/2
South=Π
East=3/4Π

Lax · Post by **Lax** » Fri Apr 09, 2004 12:25 am

Because people dont think in radians. This is a non-issue internally, the point is what to show people.

htw · Post by **htw** » Fri Apr 09, 2004 6:48 pm

I don't really see the point to change it, but that's not up to me. :-) Those (including myself) who do not like it, can change it back in code.

I've played EQ since beta, fairly hardcore since release at least. One of the early things to "learn" was that EQ was y,x,z with respect to anyone who knew even the basics about a 2 dimensional plot (with respect to y/x only of course).

Since cheating with 3rd party programs was little to none, and most used their compass and /loc to do their movement/course plotting, then people learned quickly that N/S was X, and E/W was Y.

I don't really see the need for such a change, which seems to be that it confuses some people the old way. Are their other reasons? I mean, let's be honest here, we've all see the STFU noob, you're too stupid to use MQ, etc. type comments, and I do feel that the responses are in general like the showeq community always was: If you're too stupid to figure it out, too fucking bad (I feel the same, btw... lol).

For the opposite reason, showeq long ago implemented the "Use Retarded EQ Coodinates" as an option. SEQ coords (x,y,z) did not match EQ coords (y,x,z), so they got swapped.

I've gotten used to MQ's use of coordinates. Do you know, at first, I kept screwing up things in MQ sometimes, because I automatically was using y, x, z, even though the plugin in use expected x,y,z, and did the swapping for you, to "save you the trouble"! :-)

I suppose it depends on your thought process, and they way things get done in your own code/scripts, that would hammer it out for you:

1) Do you think in EQ y,x,z? Then you take that into consideration, and write appropriately. For example, in a custom mob loc reporting shiznit, you'd report y, x, z. Now, you must change it to x, y, z, so that it matches what EQ shows you. I think...

2) Do you think in normal x,y,z? WTF? Haven't you been playing EQ too long ya fucking noob?!? HAHA.

Honestly, what the fuck ever. Change it around in a few spots in your custom plugins/scripts, get used to calling them opposite, or make your own patch that modifies it back to the old way every time you CVS checkout or grab a zip.

htw