Mechanics:Coordinate Systems
Source
- This article was retrieved via the Wayback machine in February of 2018 from the Lorebook as of July 2012.
- The original author of the piece is not available from the Wayback information.
New Output Format
- Update 26.2.2 changed the /loc command. The following quote was taken from the release notes for that update:
- "The /loc command has been modified to include the player's server ID and timestamp. Including this information with GM correspondence could help us expedite your request."
- Update 27.2 changed the /loc command again. The following quote was taken from the release notes for that update:
- "The /loc command has been modified to include the world name."
- The new format for the output of the /loc command is:
You are on Gladden server 22 at r1 lx1006 ly894 i44 ox125.71 oy134.13 oz388.48 h225.0. Game timestamp 417463663.310.
- The meaning of the server ID number is not public information; it is only useful to SSG support personnel.
- The timestamp is the server-specific timestamp returned by the Turbine.Engine.GetGameTime() function in the Lua API. In combination with the server ID number, it allows SSG support personnel to pinpoint exactly when the /loc command was executed.
- The explanation of /loc provided below appears to be correct for the other components of the output.
Mechanics: Coordinates System
If a player types "/loc" into chat and hits [Enter] some unusual data appears in the chat window that seems to contain no information about a player location. The intent of this article is to demonstrate how the data that emerges from the “/loc” command can be interpreted, converted into useable coordinates and reconciled against other data sets within the game.
The information presented here represents the best understanding and widest sampling available to the author. Though much data has been collected to support the findings presented here it is impractical to test the presented hypothesis literally everywhere. Input from the community is encouraged and welcomed. This Lorebook entry will be updated as warranted.
Introduction
In The Lord of the Rings: Online there are two coordinate systems available to the player. The first coordinate system is the one most players are familiar with – it’s the one under the mini-map that shows how far north, south, east or west you are. For the purposes of this Lorebook entry these coordinates will be referred to as “Player Coordinates”. The second set of coordinates are not as visible as the first but are far more accurate – it’s the data you see when you enter “/loc” in the chat window in-game. Since this data also gets submitted with every bug report, this second set of coordinates will be referred to as “Developer Coordinates”.
The player coordinates are delivered in an unconventional fashion. Typically, 2 dimensional coordinates are delivered as pairs of numbers: (X,Y). Either (or both) of these numbers may be positive or negative. However, you’ll never see negative values in player coordinates - their sign is masked by a compass point. Instead of seeing a negative number, you’ll see a number delivered with either an “S” or a “W”. Positive values are delivered with an “N” or “E”. Additionally, the player coordinates are delivered in an unconventional Y,X format. The diagram with compass points at right should help illustrate how player coordinates are delivered.
The diagram also contains Quadrant labels (Q1, Q2, etc). Quadrants are nothing more than areas where all the coordinates appear with the same pattern of polarity. If you look at the figure above you’ll see that the green dot is in the area labeled Q1 – quadrant 1. Both coordinates for the green dot are positive. This is true of any point found in quadrant 1. The red dot is in quadrant 4. The first coordinate for the red dot (X) is negative and the second coordinate (Y) is positive. Every point in quadrant 4 will have a negative X value and a positive Y value. The blue dot is in quadrant three and represented by two negative coordinates. Again, any point within quadrant 3 will have negative values of X and Y. These patterns of positive and negative coordinates are consistent throughout each quadrant.
There are two reasons why the concept of quadrants is important in this context. First, it’s important to understand that the player coordinate system is actually delivering coordinates in all 4 quadrants. This is not immediately apparent however, because player coordinates are always delivered with positive values.
Secondly, it’s also important to understand that most computer-aided design work takes place in quadrant 1. All the values in quadrant 1 are positive and working with positive values is typically easier than not. This is true of many industries that use coordinate systems including; engineering, design, survey. It therefore seems reasonable to assume that the in-game world of LotR:O was also designed in quadrant 1 with positive (and possibly very large) coordinates.
Developer Coordinates
The Data
Raw Developer coordinates bear little resemblance to Player coordinates. Here’s a sample reading taken at the Hunter port-in spot in Esteldin.
You are at: r1 lx1046 ly1147 ox129.00 oy75.72 oz417.78 h358.6
Though it may look indecipherable at first there is a method to this madness. Somewhere within this data is a cleverly hidden set of X, Y, Z coordinates. The data itself is composed of several small pieces of information separated by spaces. Each of these pieces of information begins with one or two lowercase letters and ends with a number (with 1 exception). These pieces of information will be referred to as "terms" for the purposes of this Lorebook entry.
In the example above there are 7 terms present. However, only 5 of these terms have anything to do with X, Y, Z coordinates. The two terms that are not related to the X, Y, Z coordinates are the "r" and "h" terms.
The ‘r’ term
The first term is “r1”. Each iteration of the “r” variable represents a different map that uses the same set of coordinates. The maps don’t exist side-by-side except in a conceptual sense. In fact the maps line up one directly on top of the other. You could think of “r2” being a recycled version of “r1” where they just cleared off the landscape and started over. That’s why some areas of the game share the same coordinates. The brief table below details the known values of "r".
| Term | r1 | r2 | r3 | r4 | r5 | r14 |
|---|---|---|---|---|---|---|
| Value | Eriador | Rhovanion | Gondor | Mordor | Haradwaith | Tales of Yore |
The “h” term:
The last term in the data is “h358.6”. The “h” term only changes when the player rotates left or right. Thus, the “h” term represents a player's heading. It’s presented in 360 degrees, to one decimal place and measured as an azimuth. (North is 0, East is 90, South is 180, etc.). However, there seems to be a blind spot in the reporting of headings. If the player happens to be oriented within 1.3° of due north (i.e. between 358.7° and 1.4°) the “h” value is not reported in the “/loc” data set.
The five remaining terms must be combined in order to reconstruct the X, Y, Z coordinates.
Combining Terms
“lx”, “ly”, “ox”, “oy” “oz” terms:
You are at: r1 lx1046 ly1147 ox129.00 oy75.72 oz417.78 h358.6
The remaining terms are used to reconstitute the X, Y, Z coordinate data. Consider first a fundamental difference between the terms that start with “l” and the terms that start with “o”. The terms “lx” and “ly” are always represented as integer numbers (no decimals), whereas “ox”, “oy” and “oz” are always represented to two decimal places.
Though the meanings of the "l" and "o" terms can only be guessed at it does seem clear that they serve to distinguish between two different types of data. It appears that the “o” terms represent the base scale (1:1 or the finest definition the game is capable of) whereas the “l” terms serve as modifiers or multipliers to the “o” terms (at 1:20).
The "oz" term is unique in that there is no "lz" term to modify it. The “oz” term appears to vary with elevation and also appears to have no upper or lower bounds. This leads me to believe that Z (elevation) is being reported at scale by the “oz” term.
If “oz” is excluded, an interesting relationship between the “l” and “o” terms can be described. It appears that the “o” terms are always represented as numbers between 0 and 159.99. If you monitor the “ox” term as you walk east you will see that the value rise steadily till it reaches 159.99 at which point it will roll over to 0 and begin increasing again. Furthermore if you watch the “lx” as you walk east you’ll see it increase too, but at a much slower rate. The rate at which they both increase is uniform and directly proportional to each other. In the same distance it takes the “ox” term to increases from 0 to 159.99 the “lx” term will increase by exactly 8.
Because the "o" terms never fall below 0 or rise above 159.99 they can be thought of as existing within a square block that is 160 wide on each side. However, since the "l" term rises or falls at a uniform rate it can be used to "count" the 160x160 blocks. The relationship between the "o" and "l" terms can be thought of as a ratio of 8:160 (or 1:20) and described by the following formulae.
X = INT ( lx/8 ) * 160 + ox Y = INT ( ly/8 ) * 160 + oy
Setting up the formulae and solving for X and Y.
X = INT ( 1046/8 ) * 160 + 129.00 Y = INT ( 1147/8 ) * 160 + 75.72
Solve inside the parenthesis.
X = INT ( 130.75 ) * 160 + 129.00 Y = INT ( 143.375 ) * 160 + 75.72
Note: “INT” is a function available in many languages, software and calculators. The “INT” function turns a value with a decimal into an integer by eliminating the decimal portion of the number. By using the INT function 3.14159265487 becomes 3, 1.61803399 becomes 1, etc.
Perform the INT function.
X = 130 * 160 + 129.00 Y = 143 * 160 + 75.72
Multiply both terms by 160.
X = 20800 + 129.00 Y = 28600 + 75.72
Do the addition and coordinates emerge.
X = 20929.00 Y = 28675.72
These are the X, Y coordinates for the hunter port-in spot in Esteldin.
Calculating Distances
Calculating distances between two sets of coordinates can be accomplished by use of the Pythagorean theorem: A^2 + B^2 = C^2. Consider the following two examples of Developer coordinates. .
Esteldin Suri-kyla X1 = 20929.00 X2 = 15307.64 Y1 = 28675.72 X2 = 28691.04
To calculate the distance between these two sets of coordinates set up Pythagorean theorem using the derived X and Y values.
Distance = SQR ( ( X1 - X2 )^2 + ( Y1 – Y2 )^2 )
Or, distance equals the square root of the sum of the square of the difference in X values and the square of the difference in Y values.
Note: "SQR" is another function that finds the square root of a given number.
Substituting the derived values the formula looks like this:
Distance = SQR ( ( 20929.00 – 15307.64 )^2 + ( 22955.72 – 28691.04 )^2 )
Perform the subtraction inside the parenthesis
Distance = SQR ( ( 5621.36 )^2 + ( –5735.32 )^2 )
Square the result of the subtraction operations inside the parenthesis above.
Distance = SQR ( ( 31599688.2496 ) + ( 32893895.5024 ) )
Perform the addition inside the outer parenthesis.
Distance = SQR ( 64493583.752 )
Finally, find the square root with the "SQR" function.
Distance = 8030.78973401744
When the above result is rounded to the nearest whole number it becomes: 8031. 8031 is exactly the same distance reported by the game when two players are grouped with one in each location. The agreement between calculation and obeservation suggests that the original formulae are sound. So, the final formula to calculate the distance between two sets of coordinates looks like this:
Distance = ROUND ( SQR ( ( X1 - X2 )^2 + ( Y1 – Y2 )^2 ) , 0 )
Note: "ROUND" is another common function that will round a given decimal number to a specified number of decimal places. In this case the “, 0” at the end tells the "ROUND" command to round the nearest integer and leave no decimal at all.
Reconciling Two Coordinate Systems
Reconciling the developer coordinate system against the player coordinate system is tricky for a couple reasons. The two coordinate systems operate on very different scales. Developer coordinates are composed of much higher values than player coordinates. Compare the two sets of coordinates for the Esteldin hunter port-in spot:
Developer coordinates Player coordinates X = 20929.00 42.2W Y = 22955.72 9.6S
Not only is one set clearly larger than the other, these sets of coordinates are not even in the same quadrant – remember, “W” and “S” denote negative values. So really, the Player coordinates look more like this.
Developer coordinates Player coordinates X = 20929.00 -42.2 Y = 22955.72 -9.6
This is a clear indicator that the two coordinate systems do not share the same origin (The origin is nothing more than the center of the coordinate system – the place represented by the coordinates 0,0). In the case of the Player and Developer coordinate systems, their origins are not on top of each other. They are, In fact, very far apart.
However, by taking readings at 0 N/S and 0 E/W (Player coordinates) it is possible to discern the offset of the two coordinate systems. The player coordinate system origin lies at the following developer coordinates:
X = 29360 Y = 24880
These numbers represent how far apart the two origins are. In order to begin reconciling the developer coordinates to the player coordinates you must first subtract the values above from any derived X, Y coordinates. This will effectively “line up” the two coordinate systems. Performing this subtraction leaves something like this:
Developer coordinates Player coordinates -8431.00 = 20929.00 - 29360 -42.2 -1924.28 = 22955.72 - 24880 -9.6
Now that the two coordinate systems are “lined up” the only difference left to account for is scale. A scale factor can be hinted at by dividing the developer coordinates by the player coordinates.
Developer coordinates Player coordinates Scale Factor X -8431.00 / -42.2 = 199.78672 Y -1924.28 / -9.6 = 200.44583
This clearly suggests a scale factor of 200. Dividing both the X and Y terms from the developer coordinates by 200 yields:
Developer coordinates Player coordinates -42.155 = -8431.00 / 200 -42.2 -9.6214 = -1924.28 / 200 -9.6
Rounding the developer coordinates to the nearest tenth, the two sets become identical. So, the formulae for converting from Developer Coordinates to Player Coordinates look like this:
Player Coordinate X = ROUND ( ( Developer Coordinate X – 29360 ) / 200 , 1) Player Coordinate Y = ROUND ( ( Developer Coordinate Y – 24880 ) / 200 , 1)
NOTE: The “, 1” at the end of the formulae tells the ROUND command to round the answer to 1 decimal place.
Interior Spaces
“cInside” term:
Everything discussed so far only applies to the outside world – the landscape. The data returned from the “/loc” command works a little differently when the player is in an interior space. However, there is also a term associated with interior spaces to let players know when they’re in one. An easily accessible example of an interior space is Thorin’s Hall.
The reading just outside the entrance to Thorin’s Hall is shown below:
You are at: r1 lx435 ly1106 ox77.42 oy47.32 oz654.30 h180.0
The reading just inside the door to Thorin’s Hall looks like this:
You are at: r1 lx1944 ly2000 cInside ox-5.15 oy-30.36 oz-191.71
The second data set has some unique features. A few things leap out when you compare the two sets of data.
- The “l” values vary greatly between the two sets.
- There’s a new term: cInside
- There are negative numbers present.
The first point serves to demonstrate that things are not always as they appear. When a player moves through the door to Thorin’s Hall it appears they've traveled only a short distance – from one side of the door to the other. However, the calculations show that the player actually traveled 35040m! That’s a very long way indeed!
The term “cInside” only seems to appear when the player is in an interior space. Furthermore, Developer coordinates are reported differently in interior spaces than they are for the landscape. This leads to the final point.
In an interior space the “o” values are no longer limited to the typical 0-159.99 range but instead can be any number at all. However, the “l” values appear fixed throughout the interior space. It cannot be said that this is the case in literally every interior space but it has been true in all observations to date.
Interestingly, given that the “l” values remain fixed and do not vary throughout the interior space and the "o" values are no longer limited between 0 and 159.99, the previously described formulae still generate a quite useable and contiguous set of coordinates.
Instances
the “i” term:
There’s one more term players are likely to see and it’s a very straightforward term. The “i” term only appears when you’re in an instance. And the number that follows it represents the number of the instance you’re in. Here are two likely samples:
Carn Dum, Port-in spot just inside main entrance:
You are at: r1 lx1131 ly1359 i43 ox79.88 oy153.37 oz629.97 h181.4
Bree-Land Neighborhood, Port-in spot just inside 2 Long Street:
You are at: r1 lx1880 ly1816 i31 cInside ox-51.30 oy16.84 oz-197.27
It is possible for a player to be in an instance whether they are on the landscape or in an interior space. However, being in an instance by itself does not seem to have any impact on the way Developer coordinates are reported.
The “i” term can yield some interesting information though. For example, if players observe the instance number of a particular neighborhood at several times throughout the course of a day they will likely find that the instance number is different every time they check. This suggests that neighborhood instances collapse when empty and are only reinitialized as needed.
Potential Uses
The potential usefulness of Developer coordinates to the average player is debatable. The cryptic way in which Developer coordinates are delivered makes them almost useless in a real-time sense to players in the game. However, the Developer coordinates describe the game world in the highest degree of detail available to the player and this leads to some interesting possibilities.
For example, Developer coordinates can be used directly in modern survey techniques to produce a topographic survey. With a large enough data set it would be possible to create a terrain map with elevation lines depicting the relief across the world of middle-earth.
Using the same techniques it is also possible to create an detailed rendering of an interior space like the one at right. These techniques can be used in conjunction with Developer coordinates to accurately map out almost any area of the game.
Players who are interested in manipulating Developer coordinate data could build upon the Precise Coordinates plugin by Thurallor.
For a more detailed example of what can be done using Developer coordinates please refer to the archived Haunted Burrow Maps thread.
Credits
Thanks to Lotro Community member Digital_Utopia for pointing out that the first formula was wrong, discovering the blind spot in the heading reporting and for general support during the production of this entry and associated maps.
The coordinate system image has been modified and is used with permission under the GNU Free Documentation License.