Datatable Coordinates Explained

In most of the datatables you'll see different types of spawning mechanisms. The first mechanism is to spawn in the world or another container. Containers will be either a structure (i.e. a house, starport or cantina) or they could be a "cell" container. A Cell container is a generic container that satisfies two things:

1. A holder for what the client knows about. the client may know a "thing" like a table, chair, npc, terminal, painting, etc. is at a certain location, but it also knows if it's contained in a particular container. Generally this container is a "cell".
2. A holder that allows you to establish a new coordinate origin. This is helpful if you know you want a particular thing spawned at a particular location, but you only know parts of info about it. For example, you may know a terminal is 10 meters away from another terminal, but the parent container my be skewed. Instead of calculating angles and azimuth's within the parent container, do it for ONE object and put a cell there. Then, the cell can hold other items, but their coordinates are relative and easier to place things in.
3. A holder that represents a particular room of a building. Most buildings have multiple "rooms" or "zones". Each cell added to a building will represent the particular space a building considers to be a room or zone. Each cell's index directly corresponds to the building's room index. Therefore, in example, all Starports have their central "room" or "zone" at index 4. When you see a cell with an index of "4" that is contained within a starport, you know that is the central zone of the starport where ticket terminals, space terminals and chassis vendors are located. [TODO: Add buildings and indexes that show which rooms correspond to which index numbers.]

How Containers Work

Containers are just things like buildings or inventories. Basically, they hold other stuff. Buildings are geometric containers, or containers that have coordinate systems for layouts. Things like inventories ignore coordinates and just show what's in them. Containers have coordinates that define position within the container of Px, Py, Pz. Items may be placed within containers at a particular position that fits within a coordinate distance of 16384 wide (Px), 16384 tall (Py) and 16384 deep (z) (assumed limits). Inventory containers ignore their coordinates.

World Containers

World containers are the highest level of container. Each world (space regions are considered "world" regions) has an object ID of 0 since they are the highest level. The ground in a non-space world is planar (parallel) with the Px and Pz axis with Px pointing North/South and Pz pointing East/West. The Py axis is elevation from the ground. All coordinates for layout can be positive or negative. Additionally, items may be rotated within the world container (see "Rotation" below). Each World container "shows" a space of 16000 wide by 16000 long, but that is just the graphical map size. The actual layout size does not consider a 320m "no travel" border that wraps around the entire map nor does it count extra space past the map graphic itself. In fact, the 0,0 point for layout consideration is actually at -8192, -8192 (lower left map corner) and the upper right corner is at 8192, 8192 (upper right corner). It's here that the layout TAB files also begin their own layouts. See this attached PDF file for a visual reference:

Planetary_Grid_System.pdf

TAB Map Grid

You'll notice that in the server buildout folders there are layout files that end with two numbers. These numbers correspond to their grid layout section on a planet map. The first "block" (or tab file) for layout is <planetname>_1_1.tab. This means it's the first block of the map starting from the lower left corner. <planetname>_8_1.tab is the lower right corner, <planetname>_8_8.tab is the upper right corner and <planetname>_1_8.tab is the upper left corner of the map.

TAB Layout Coordinates

Each TAB file has a coordinate system as well, but that coordinate system starts at 0,0. As the world coordinate system applies, the coordinates within the tab ADD to the world coordinates to determine where an object spawns in the world. For example, <planetname>_7_2.tab starts it's 0,0 location at 3840, -6080. For this grid location, the object must fall within the coordinate space of 3840, -5760 and 5760, -3840 (the 1920 x 1920 block). Which means, layout coordinates for planetary buildouts should always be positive and less than or equal to 1920.

Building Containers

Buildings are placed in the World at a specific Px, Py and Pz location relative to the World container's coordinate system. Additionally, buildings can be rotated within the world container using a Qw, Qx, Qy, Qz rotation (see "Rotation" below.)

Tab Layout Coordinates

Buildings have their own coordinate system that totally ignores the world coordinate system. The coordinate system is the same, but it's relative to where the building is placed within the world and at what rotation it is placed in. The reason the building has its own coordinate system is to maintain the ability to keep item location integrity in place. For example, if you place a space terminal in a starport at position 100, 0, -100, you know that no matter what rotation or position the building has in the world, the items located within a building (i.e. our terminal in our starport) will stay in the right spot in the building. Coordinates are relative to their container with 0,0 starting at the location of the container within the building.

Cell Containers

Cell containers are essentially the same as building containers. In fact, every container in game is considered a cell container - including buildings and most likely worlds as well. Cell containers allow the client to place items it knows about into the world. Cell containers also allow you to place items within a building's particular room or zone, but they also allow you to redefine a new coordinate system within a building allowing you to place items easier and with consistency (i.e. starports have space terminals, ticket terminals and GCW Network terminals all in the same locations - typically).

Rotation

Items placed in containers can be placed at a particular spot, but they can also (and generally need to be) be rotated in their position. There are two ways to place an item in a container with a rotation. In snapshot tab files you may see two types of rotation - rotation with "Qw, Qx, Qy, Qz" or a specific rotation angle. The latter is the easier to understand and calculate, but the former is more in line with 3D layout. The "Q" stands for Quaternion and is the rotation calculation that explains rotation in 3D space. Quaternions can be explained via this link:

https://en.wikipedia.org/wiki/Quaternion

Quaternion calculation is not simple. You can download an excel spreadsheet that will allow you to convert X, Y and Z axis rotation to Quaternions from this location:

https://15254b2dcaab7f5478ab-24461f391e20b7336331d5789078af53.ssl.cf1.rackcdn.com/robotstudio.vanillaforums.com/FileUpload/db/c14143d7a06963c4dca596ce987cdc.zip

In addition, where possible, consult the client TRE patch files to see if an item has been added client side. If so, grab the coordinates of said item from the TRE's and duplicate on the server to maintain consistency in locating items within game. You can count that the client's location was the intended location of said item.