Difference between revisions of ".world file - M2TW"
(→Bottom Table 1) |
(→Bottom Table 3) |
||
Line 98: | Line 98: | ||
− | The picture on the right shows a point where it gets a bit more confusing. It's switched to the second structure, but then goes back to the first structure ( | + | The picture on the right shows a point where it gets a bit more confusing. It's switched to the second structure, but then goes back to the first structure (it's obviously not a new structure or complex as it's not starting at the first group) there is a chunk of the first structure within the sequence for the second structure and then it returns to first structure again..... |
''' ''Why does this all matter you may ask''!''' | ''' ''Why does this all matter you may ask''!''' |
Revision as of 00:55, 30 August 2009
Contents
- 1 Overview
- 2 File Structure
- 3 Modding Information
Overview
The .world file forms the major part of the information controlling each settlement or ambient building in M2TW. The file contains details of the 3d structures making up each building, wall or other static object. It is very closely interrelated to the .worldcollision file.
The 3d game elements are grouped into:
- Complexes Each complex is numbered (0 to n)in Table 1 and can comprise one or more structures.
- Structures Each structure can comprise one or more objects, a structure can be viewed as a Milkshape ms3d file or in Mayavi2 by use of the WorldEditor user developed modding tool.
- Objects Each object can comprise one or more groups, where an object contains more than one group the first will be the undamaged state of the 3d element and the successive groups will be the damaged states. The most common object size is two groups - a pair of undamaged and damaged versions of an element.
- Groups In game groups are the same as Milkshape ms3d groups, they are organised into objects by the .world files.
Each of the above element stages will also have an invisible bounding sphere or box which effects where it can be viewed from in game (and probably other factors like collision and animation). The complex bounding spheres are located within an Octree structure of bounding boxes described by Argantonio here.
Co-ordinates in the world files generally appear in the order x,y,z. Relative to the game the x axis is east-west (using the convention that north is up), the y axis is the height, and the z axis is north-south.
File Structure
The file layout (with names used in KnightErrant's WorldEditor is as follows:
Table 1
This table deals with the inter-relation of the bounding boxes and Complex relative locations and bounding spheres.
The image below shows a screen shot of Table 1 from Stone_Fort_C which has been coloured in Excel to try to attempt to explain contents.
The numbers in red do not exist in the file - they are notional column and row numbers added to help explain things. The notional row numbers (0-32 in the example) although not stated in the file are actually used within the table to inter-relate components.
Column 19
Column 19 gives the hierarchy level for each of the row contents.
- 0 is the top level cube for the Octree structure - the dimensions of this should contain the entire 3d world for this settlement or building.
- 1 is the second level down, the up to eight smaller cubes that can fit within the largest cube
- 2 is the third level down, theoretically up to 64 smaller cube locations that can fit within the level 1 cubes - in this file the 3d Complexes are notionally located in the level 2 cubes - they can exceed the size of the cube and overlap other cubes in some cases.
Column 20
Column 20 gives the Complex number (with the Complexes numbered 0-23 in this example, if column 20 has the entry "-1" the row doesn't reference a Complex but is instead a bounding box which contains other rows (a level 0 or 1 box as described above). These rows that only contain other rows have been marked in light blue on the diagram.
Columns 7 to 18
These columns represent the eight possible positions (the columns containing only "2" are spacers) within one bounding box cube for another smaller bounding box cube to exist in the Octree system. If the number in these columns (shown in light green on the diagram) is not "-1" then it represents the notional row number of the bounding cube or Complex that is located at that position.
You can see that the top level bounding box cube in row 0 contains all eight level 1 bounding box cubes at rows 13, 26, 24, 4, 1, 7, 17 and 9.
If you look at bounding box row 24, you will see it includes complex rows 25, 32 and 29 (so not just those displayed between it and the next level 1 row!). Viewing column 20 for those rows will show that the actual 3d Complexes contained in that level 1 bounding box are 17, 20 and 23 (with complex numbering starting at 0).
Complexes and smaller boxes are distributed into the eight possible grid positions in the larger boxes following a set pattern with the first position having the lowest x,y,z co-ordinate values and the 8th position the highest x,y,z co-ordinate values. (If you really need to understand where to place new components in the system you need to draw a 3d diagram of the relative positions)
Columns 1 to 3
The co-ordinates in these columns are the x,y,z co-ordinates for the centre of the Octree box each row relates to. The co-ordinates in row 0 represent the nominal centre for this entire world and its largest Octree box. The length of side for the largest box in this example is 90.6779251099 x 2 the number seen above the table, so the dimensions of the box will be + and - 90.6779251099 from the centre locations in row 0 columns 1 to 3.
Columns 21 to 26
The co-ordinates in these columns are the minimum x,y,z co-ordinates (in columns 21 to 23) and maximum x,y,z co-ordinates (in columns 24 to 26) that define the diagonally opposite corners of the effective bounding box applied to whatever is in that row (either smaller bounding boxes or Complexes). These bounding box dimensions can and do overlap each other and do not necessarily fill the entire Octree box size they fit within.
Table 2
Complex Information
Pathfinding Tables
Table Blocks
Wacky Table
Seven Float Table
.worldpathfinding type data
Game Objects Section
Main Object Default
Anim Strings Section
VariableIntegers Table
Six Float Table
Bottom Table 1
This table effectively gives the object numbering system. The number at the top is the total number of Objects (sets of groups) in this .world file. There are then that number of rows in the following table section, if we use notional row numbers again (not in the file but added to the screen shot in red), we can find the object number of any group set.
The number in column 1 (text in black) is the group number for the first group in the first object, starting with the first group as 0; the number in the second column is the number of groups included in that object. As the first object contains 2 groups (which will be a paired set of undamaged and damaged versions of the element) then groups 0 and 1 must be included in that object. So it starts again on the next row with group 2 as start of next object, which again includes 2 groups so next start is 4, this only includes one group so group5 is start of next object, etc, etc....
Note: the group numbering is based on the occasionally scrambled (bits of structure 2 numbered before all of structure 1) system in Bottom Table 3
Bottom Table 2
Nice and simple this one: The total number of groups (1122 for Stone_Fort_C) at the top then that number of rows below. With the number of the group (0-1121 for the example) in sequence down the first column then a 1 on each row.
Looks like a very long way of saying there's 'x' number of groups?
Bottom Table 3
In the view on the left you can see the start of bottom table 3 from Stone_Fort_C - the 1122 number at the top is the total number of groups in this settlement (this is Milkshape type groups, so there are more of these than the objects which can be made up of sets of groups).
The number in the first column represents the structure number within a complex, 0 is the first structure in a complex. The numbering in the second column is the group number - so you can see that the first structure shown has 25 groups (0-24). When the numbering in the second column restarts from 0 again that is the start of a new structure - the number in the first column at that point is still 0, so this is still the first structure in a complex = therefore this is a new complex. When the numbering in column 2 again starts from 0 the number in column 1 changes to 1 representing the second structure in a complex.
From all that you get Complex 1 has 1 Structure with 25 Groups, Complex 2 has 2 Structures, the first with 2 Groups the second with 3 Groups. (luckily that ties up with what is visible when you open those Complex Structures in Milkshape through the editor)
So far so good - you can see that the start of a new complex is signalled when the number in both columns on the same row is 0 - i.e. its the first group in the first structure, so it must be the start of a complex.
The picture on the right shows a point where it gets a bit more confusing. It's switched to the second structure, but then goes back to the first structure (it's obviously not a new structure or complex as it's not starting at the first group) there is a chunk of the first structure within the sequence for the second structure and then it returns to first structure again.....
Why does this all matter you may ask! Well the sequence of this list gives you the numbering system for the objects (once you've excluded the groups which are the second part of pairs etc). The object numbering appears in a variety of places elsewhere in this file and the collision file, you must know your objects number to give it the right collision item or structural effect.... though quite why the existing objects don't just work in structure order is a mystery!