Difference between pages "FSH Format" and "Individual Network RULs"

From SC4D Encyclopaedia
(Difference between pages)
Jump to navigation Jump to search
sc4e>Null45
(Imported from MTS2)
 
sc4e>Whatevermind
(→‎Header: merged with network specs info)
 
Line 1: Line 1:
EA PC SHAPE FORMAT - By Darkmatter and Karybdis
+
'''Individual Network RULs''' are [[RUL]] files that deal exclusively with one network, covering the basic placement and single-network intersections. Each network has two separate RUL files: a basic RUL file that covers basic placement, and an advanced RUL file that handles more complicated setups. Intersections involving multiple network types are handled by the [[RUL File#Multi-Network RUL Files|Multi-Network RUL Files]].
  
 +
==List of Files==
 +
All of the Individual Network RUL files are listed below, by [[Instance ID]]. All of them have [[Type ID]] ''0x0A5BCF4B'' and [[Group ID]] ''0xAA5BCF57''. These RUL files cover all of the transit networks, as well as water pipes. They do not, however, cover power lines. Note that it is not possible to create new Individual Network RUL files, however these files may be modified.
  
 +
*0x0000001 - Elevated Highway Basic RUL
 +
*0x0000002 - Elevated Highway Advanced RUL
 +
*0x0000003 - Subway Basic RUL
 +
*0x0000004 - Subway Advanced RUL
 +
*0x0000005 - Rail Basic RUL
 +
*0x0000006 - Rail Advanced RUL
 +
*0x0000007 - Road Basic RUL
 +
*0x0000008 - Road Advanced RUL
 +
*0x0000009 - Street Basic RUL
 +
*0x000000A - Street Advanced RUL
 +
*0x000000B - Pipe Basic RUL
 +
*0x000000C - Pipe Advanced RUL
 +
*0x000000D - Avenue Basic RUL
 +
*0x000000E - Avenue Advanced RUL
 +
*0x000000F - Elevated Rail Basic RUL
 +
*0x0000010 - Elevated Rail Advanced RUL
 +
*0x0000011 - One-Way Road Basic RUL
 +
*0x0000012 - One-Way Road Advanced RUL
 +
*0x0000013 - [[RHW]] ("Dirt Road") Basic RUL
 +
*0x0000014 - [[RHW]] ("Dirt Road") Advanced RUL
 +
*0x0000015 - Monorail Basic RUL
 +
*0x0000016 - Monorail Advanced RUL
 +
*0x0000017 - Ground Highway Basic RUL
 +
*0x0000018 - Ground Highway Advanced RUL
  
== FSH SHPI Header ==
+
Changing the Subway RULs will either cause a CTD when you start the game, or not make any changes, the same is probably true for Pipe RULs. There are hints that Subway RULs are located inside the EXE, especially as the straight open top subway section is not handled by any of the RUL Files.
  
SHPI (4 bytes)
+
==Format==
 +
{{MTS2}}
  
INT32 - File Size
+
The Individual Network RUL Files all have the same format, which is unique to this type of RUL file. The general layout consists of a header, followed by repeating blocks of data that contain the actual rules for that network type.
  
INT32 - Number of Entries
+
===Header===
 +
Each file begins with the header on the first line. There is only one header per file, and it can come in two formats. The game engine recognizes the different names used in the header section, and the header does have an impact/influence on the network tool(s) used.
  
Directory ID (4 bytes)
+
The first type of header looks like:
 +
#(transittype)Rules#
  
 +
The second type of header looks like:
 +
#Transmogrify
  
'''Directory ID legal entries''':
+
A #Transmogrify# header can be used in order to automate the rules rotations and flips where applicable. It will take the supplied rule and rotate/flip it for all directions. However, in special cases such as designing turning lanes, this produces improper results in viewing. For those interested, Transmogrify means to change something with weird and often humorous results.
  
G354 - Building Textures
+
Common examples of headers are:
 +
 
 +
#HighwayRules#
 
   
 
   
G264 - Network Textures, Sim Textures, Sim heads, Sim animations, Trees, props, Base textures, Misc colours
+
#RoadRules#
 
 
G266 - 3d Animation textures (e.g. the green rotating diamond in loteditor.dat)
 
 
 
G290 - Dispatch marker textures
 
 
 
G315 - Small Sim texture, Network Transport Model Textures (trains etc)
 
 
 
GIMX - UI Editor textures
 
 
 
G344 - BAT gen texture maps
 
 
 
 
 
== FSH Directory ==
 
 
 
Entry Name (4 bytes)
 
 
 
INT32 - Offset of the entry in the file
 
 
 
 
 
'''Entry names''':
 
 
 
!pal - Global palette for 8-bit Indexed Bitmaps.
 
 
 
0000 - Buildings, props, network intersections,and terrain textures.
 
 
 
rail - Always used for a rail texture, whereas for street road intersections its always by instance.
 
 
   
 
   
TB2 - First sprite animation entry in a directory.
+
  #RailRules#
 
 
TB3  - Any sprite animation entries in a directory after TB2.
 
 
 
 
 
== FSH Entry Header ==
 
  
BYTE - Record ID (logically anded by 0x7f for bitmap code or 0x80 to check if the entry is QFS compressed (unused by SC4))
+
===Comments===
 +
These files support comments, which are simply lines preceded by a semicolon. In some instances it is simply a single line, in others a blank comment line is used both before and after the comment line itself, for example:
  
INT24 - Size of the block (= width x length + 10h(hex)), Not used for a long time.
+
;
 +
;Comment or description
 +
;
  
UINT16 - Width
+
Typically, the comment simply describes the block(s) that follow the comment.
  
UINT16 - Height
+
===RUL Blocks===
 +
'''RUL Blocks''' consist of some combination of '''Type 1''', '''Type 2''', and/or '''Type 3''' Lines. These types are so named because each line begins with either a 1, 2, or 3. Each block begins with a Type 1 Line, and may be followed by several Type 2 Lines, which are then followed by a Type 3 Line for each Type 1 or Type 2 Line. The Type 1 Line defines the central tile of the rule pattern, while the Type 2 Lines (if present) define tiles adjacent to the central tile. Type 3 Lines define additional information about each of the tiles involved in the rule. Together, each block of lines consist of the complete rule. For example:
  
UINT16 - X axis coordinate for center of image or for image to spin around. 65535 Max.
+
Type 1
 
+
  Type 3
UINT16 - Y axis coordinate for center of image or for image to spin around. 65535 Max.
 
 
 
UINT16 - X axis position to display the image from the left.
 
 
 
UINT16 - Y axis position to display the image from the top.
 
 
 
 
 
== Bitmap or palette data ==
 
 
 
After the entry header is the bitmap or palette pixel or color information. Palettes are generally arrays of 1 byte each, 256 entries long. Bitmaps may store their pixel data in one of many ways. FSH images can store their pixel data raw, or they can make use of Microsoft DXTC compressed formats.
 
 
 
 
 
'''Bitmap codes''':
 
 
 
0x7B - 8-bit indexed Palette: directly follows bitmap or uses global palette Compression: none
 
 
 
0x7D- 32-bit A8R8G8B8 Palette: none Compression: none
 
 
 
0x7F - 24-bit A0R8G8B8 Palette: none Compression: none
 
 
 
0x7E - 16-bit A1R5G5B5 Palette: none Compression: none
 
 
 
0x78 - 16-bit A0R5G6B5 Palette: none Compression: none
 
 
 
0x6D - 16-bit A4R4G4B4 Palette: none Compression: none
 
 
 
0x61 - DXT3 4x4 packed, alpha premultiplied, Palette: none Compression: 4x4 grid compressed, half-byte per pixel
 
   
 
0x60 - DXT1 4x4 packed, Opaque or 1-bit alpha, Palette: none Compression: 4x4 grid compressed, half-byte per pixel
 
  
 +
is a valid RUL block.
  
'''Palette codes''':
+
Type 1
 +
Type 2
 +
Type 2
 +
Type 2
 +
Type 3
 +
Type 3
 +
Type 3
 +
Type 3
  
0x22 - 24-bit DOS
+
is also a valid RUL block.
  
0x24 - 24-bit
+
====Type 1 Lines====
 +
'''Type 1 Lines''' are lines that describe the basic boundaries of the central tile. The format is:
  
0x29 - 16-bit NFS5
+
1,A,B,C,D (i.e. 1,13,2,0,2)
  
0x2A - 32-bit
+
The first value, "1", defines the line as Type 1.
  
0x2D - 16-bit
+
''A,B,C,D'' are unique values that must match the value of the tile next to it (i.e. a 2 touches a 2). Known acceptable values are:
 +
*0 - No connection
 +
*1 - Left at 45 degree angle
 +
*2 - Straight connection
 +
*3 - Right at 45 degree angle
 +
*4 - Shared median for 2 tile wide networks
 +
*11 - Off centre "blend" for left angled 1 to straight 2
 +
*13 - Off centre "blend" for right angled 3 to straight 2
  
 +
Each of these four values corresponds to a specific side of the tile. Side A is the west side, side B is the north side, side C is the east side, and side D is the south side of the tile. In theory these IDs can be arbitrary as demonstrated in [[Rush Hour]].
  
'''Text codes''':
+
If one draws a little text art for the values shown in the format above, one gets:
 +
<pre>
 +
+-----+
 +
|  2  |
 +
|13  0|
 +
|  2  |
 +
+-----+
 +
</pre>
  
0x6F - Standard Text file
+
====Type 2 Lines====
 +
'''Type 2 Lines''' describe the squares that must be adjacent to the tile defined in the Type 1 line. Their format is:
  
0x69 - ETXT of arbitrary length with full entry header
+
2,X,A,B,C,D
  
0x70 - ETXT of 16 bytes or less including the header
+
The first value, "2", defines the line as Type 2.
  
0x7C - defined Pixel region Hotspot data for image.
+
The "X" value describes the relationship of this "limiting tile" in relationship to the reference tile.  There are 24 possible values for ''X'' using the following convention:
 +
<pre>
 +
1 - West
 +
2 - Northwest
 +
3 - North
 +
4 - Northeast
 +
5 - East
 +
6 - Southeast
 +
7 - South
 +
8 - Southwest
 +
9 - West 2 tiles from center
 +
10 - West-northwest 2 tiles from center
 +
...
 +
24 - West-southwest 2 tiles from center
 +
</pre>
  
 +
A,B,C,D follows the same convention as Type 1 Lines.
  
This entry can also contain Binary data, however the identifier byte for different binary types anything that isn't already defined with a type so make sure to try and get all codes down correctly. Examples of binary data consist of Palette animations, binary links to outside files, or plain binary data.
+
So, expanding on the example used above for a Type 1 line, if that line was followed by the following three Type 2 lines:
  
 +
2,1,0,1,13,0
 +
2,6,13,0,0,1
 +
2,7,0,2,13,2
  
== Overview of DXT compression ==
+
These three tiles would have to be adjacent to our reference (Type 1) tile for this "rule" to be valid.
  
 +
The little text art picture looks like:
 +
<pre>
 +
+-----+-----+
 +
|  1  |  2  |
 +
|0  13|13  0|
 +
|  0  |  2  |
 +
+-----+-----+-----+
 +
      |  2  |  0  |
 +
      |0  13|13  0|
 +
      |  2  |  1  |
 +
      +-----+-----+
 +
</pre>
  
Microsofts DirectX Texture Compression uses what they call a 4x4 encoding. Basically, an image must be a multiple of 4 in width and height, because 4x4 blocks of pixels are compressed at a time, similar to encoding used in AVI/MPEG files. Each 4x4 block contains 16 pixels, each pixel using either 24bits or 32bits before compression. All 16 pixels use 512 bits of storage before compression. After compression, that block of 16 pixels is reduced to 64 bits, for an 8:1 compression ratio. The nice thing about DXT compression is its hardware accelerated by nVidia and ATI GPU's all the way back to the GeForce2 and Raedon 8000 series, leaving the CPU free to simulate.  
+
Notice how the sides line up nicely.
  
The compression itself works in the following way. First, all 16 pixels in the 4x4 block are checked, and unique colors stored in a vector (usually just an array of 16 unsigned ints). Once all the pixels in a block are checked, the two color extremes are found among all the unique colors. (This is something I had a hard time with in my own version, so I'm currently just using the method from FSHTool.) These two color extremes make up color1 and color2.
+
====Type 3 Lines====
 +
'''Type 3 Lines''' state what FSH images to load into which tiles and if any manipulation is needs to be done to the image before it is place (rotated or flipped). So basically this is responsible for making sure curves work (as well as highways that often take up 2 tiles). They have the following format:
  
Once color1 and color2 are found, they are reduced from 32bit color to 16bit color (RGB 5:6:5), and stored in the first 32bits of the compressed 64bit chunk of data. The rest of the colors in the 4x4 block are interpolated between thse two colors. Each pixel is only represented by two bits of information, as follows:
+
3,Y,FSH,ROTATE,FLIP
  
bits    color used for pixel
+
The first value, "3", defines the line as Type 3. The attributes that follow are:
---------------------------------
+
*''Y''  - Works just like ''X'' from the Type 2 lines, with the exception that zero (0) is now a valid field.  A "0" denotes the image to load into the reference tile.
00      color1
+
*FSH - This value points to the [[Instance ID]] of a [[FSH]] texture that will be used for the tile in question. It can also point to an [[exemplar]] IID for this network type.
01      color2
+
*ROTATE - Rotation to be applied to the image before it is placed in game, if any. This standard specifies the rotation of the tile as well. Valid values are 0-3 with each increment being a 90 degree clockwise turn. 0 is the default of 0 degree turn. Changing this key just says what angle the tile is being viewed from in game in the most basic sense.
10      2/3 color1 + 1/3 color2
+
*FLIP - Flip the texture horizontally and vertically like a mirror image, however retain the rotation in-game of the piece in question. This helps to cut down on the textures needed. Values are 0 and 1 - False and True.
11      1/3 color1 + 2/3 color2
 
  
Here is the layout of a 64bit compressed block:
+
==References==
 +
#[[Network Specs]]
  
|----------------------------|
 
| 16bit RGB (5:6:5) color1  | <- 2 bytes
 
|----------------------------|
 
| 16bit RGB (5:6:5) color2  | <- 2 bytes
 
|----------------------------|
 
|  00  |  01  |  01  | 11  | <- 1 byte, first 4 pixels
 
|----------------------------|
 
|  01  |  11  |  00  | 11  | <- 1 byte, second 4 pixels
 
|----------------------------|
 
|  00  |  01  |  01  | 01  | <- 1 byte, third 4 pixels
 
|----------------------------|
 
|  11  |  11  |  00  | 00  | <- 1 byte, fourth 4 pixels
 
|----------------------------|
 
  
You can see the second part of the block is very basic. Its a simple bitmap of 2 bits each representing 1 of four possible color values. A 00 means use color1, 01 means use color2, 10 means use two-thirds of color1 mixed with one-third of color2, and 11 means use one-third of color1 mixed with two-thirds of color2. This is DXT1 compression, as no alpha information is saved. DXT3 compression uses the same technique, but also stores another 64bits of information for the alpha component of each pixel, in a similar block. So DXT3 compression achieves a 4:1 compression ratio with alpha information included, rather than the 8:1 compression ratio without.
+
[[Category:NAM]]
 +
[[Category:RUL Files]]
 +
[[Category:MTS2]]

Revision as of 22:31, 20 October 2012

Individual Network RULs are RUL files that deal exclusively with one network, covering the basic placement and single-network intersections. Each network has two separate RUL files: a basic RUL file that covers basic placement, and an advanced RUL file that handles more complicated setups. Intersections involving multiple network types are handled by the Multi-Network RUL Files.

List of Files

All of the Individual Network RUL files are listed below, by Instance ID. All of them have Type ID 0x0A5BCF4B and Group ID 0xAA5BCF57. These RUL files cover all of the transit networks, as well as water pipes. They do not, however, cover power lines. Note that it is not possible to create new Individual Network RUL files, however these files may be modified.

  • 0x0000001 - Elevated Highway Basic RUL
  • 0x0000002 - Elevated Highway Advanced RUL
  • 0x0000003 - Subway Basic RUL
  • 0x0000004 - Subway Advanced RUL
  • 0x0000005 - Rail Basic RUL
  • 0x0000006 - Rail Advanced RUL
  • 0x0000007 - Road Basic RUL
  • 0x0000008 - Road Advanced RUL
  • 0x0000009 - Street Basic RUL
  • 0x000000A - Street Advanced RUL
  • 0x000000B - Pipe Basic RUL
  • 0x000000C - Pipe Advanced RUL
  • 0x000000D - Avenue Basic RUL
  • 0x000000E - Avenue Advanced RUL
  • 0x000000F - Elevated Rail Basic RUL
  • 0x0000010 - Elevated Rail Advanced RUL
  • 0x0000011 - One-Way Road Basic RUL
  • 0x0000012 - One-Way Road Advanced RUL
  • 0x0000013 - RHW ("Dirt Road") Basic RUL
  • 0x0000014 - RHW ("Dirt Road") Advanced RUL
  • 0x0000015 - Monorail Basic RUL
  • 0x0000016 - Monorail Advanced RUL
  • 0x0000017 - Ground Highway Basic RUL
  • 0x0000018 - Ground Highway Advanced RUL

Changing the Subway RULs will either cause a CTD when you start the game, or not make any changes, the same is probably true for Pipe RULs. There are hints that Subway RULs are located inside the EXE, especially as the straight open top subway section is not handled by any of the RUL Files.

Format


The Individual Network RUL Files all have the same format, which is unique to this type of RUL file. The general layout consists of a header, followed by repeating blocks of data that contain the actual rules for that network type.

Header

Each file begins with the header on the first line. There is only one header per file, and it can come in two formats. The game engine recognizes the different names used in the header section, and the header does have an impact/influence on the network tool(s) used.

The first type of header looks like:

#(transittype)Rules#

The second type of header looks like:

#Transmogrify

A #Transmogrify# header can be used in order to automate the rules rotations and flips where applicable. It will take the supplied rule and rotate/flip it for all directions. However, in special cases such as designing turning lanes, this produces improper results in viewing. For those interested, Transmogrify means to change something with weird and often humorous results.

Common examples of headers are:

#HighwayRules#

#RoadRules#

#RailRules#

Comments

These files support comments, which are simply lines preceded by a semicolon. In some instances it is simply a single line, in others a blank comment line is used both before and after the comment line itself, for example:

;
;Comment or description
;

Typically, the comment simply describes the block(s) that follow the comment.

RUL Blocks

RUL Blocks consist of some combination of Type 1, Type 2, and/or Type 3 Lines. These types are so named because each line begins with either a 1, 2, or 3. Each block begins with a Type 1 Line, and may be followed by several Type 2 Lines, which are then followed by a Type 3 Line for each Type 1 or Type 2 Line. The Type 1 Line defines the central tile of the rule pattern, while the Type 2 Lines (if present) define tiles adjacent to the central tile. Type 3 Lines define additional information about each of the tiles involved in the rule. Together, each block of lines consist of the complete rule. For example:

Type 1
Type 3

is a valid RUL block.

Type 1
Type 2
Type 2
Type 2
Type 3
Type 3
Type 3
Type 3

is also a valid RUL block.

Type 1 Lines

Type 1 Lines are lines that describe the basic boundaries of the central tile. The format is:

1,A,B,C,D (i.e. 1,13,2,0,2)

The first value, "1", defines the line as Type 1.

A,B,C,D are unique values that must match the value of the tile next to it (i.e. a 2 touches a 2). Known acceptable values are:

  • 0 - No connection
  • 1 - Left at 45 degree angle
  • 2 - Straight connection
  • 3 - Right at 45 degree angle
  • 4 - Shared median for 2 tile wide networks
  • 11 - Off centre "blend" for left angled 1 to straight 2
  • 13 - Off centre "blend" for right angled 3 to straight 2

Each of these four values corresponds to a specific side of the tile. Side A is the west side, side B is the north side, side C is the east side, and side D is the south side of the tile. In theory these IDs can be arbitrary as demonstrated in Rush Hour.

If one draws a little text art for the values shown in the format above, one gets:

+-----+
|  2  |
|13  0|
|  2  |
+-----+

Type 2 Lines

Type 2 Lines describe the squares that must be adjacent to the tile defined in the Type 1 line. Their format is:

2,X,A,B,C,D

The first value, "2", defines the line as Type 2.

The "X" value describes the relationship of this "limiting tile" in relationship to the reference tile. There are 24 possible values for X using the following convention:

1 - West
2 - Northwest
3 - North
4 - Northeast
5 - East
6 - Southeast
7 - South
8 - Southwest
9 - West 2 tiles from center
10 - West-northwest 2 tiles from center
...
24 - West-southwest 2 tiles from center

A,B,C,D follows the same convention as Type 1 Lines.

So, expanding on the example used above for a Type 1 line, if that line was followed by the following three Type 2 lines:

2,1,0,1,13,0
2,6,13,0,0,1
2,7,0,2,13,2

These three tiles would have to be adjacent to our reference (Type 1) tile for this "rule" to be valid.

The little text art picture looks like:

+-----+-----+
|  1  |  2  |
|0  13|13  0|
|  0  |  2  |
+-----+-----+-----+
      |  2  |  0  |
      |0  13|13  0|
      |  2  |  1  |
      +-----+-----+

Notice how the sides line up nicely.

Type 3 Lines

Type 3 Lines state what FSH images to load into which tiles and if any manipulation is needs to be done to the image before it is place (rotated or flipped). So basically this is responsible for making sure curves work (as well as highways that often take up 2 tiles). They have the following format:

3,Y,FSH,ROTATE,FLIP

The first value, "3", defines the line as Type 3. The attributes that follow are:

  • Y - Works just like X from the Type 2 lines, with the exception that zero (0) is now a valid field. A "0" denotes the image to load into the reference tile.
  • FSH - This value points to the Instance ID of a FSH texture that will be used for the tile in question. It can also point to an exemplar IID for this network type.
  • ROTATE - Rotation to be applied to the image before it is placed in game, if any. This standard specifies the rotation of the tile as well. Valid values are 0-3 with each increment being a 90 degree clockwise turn. 0 is the default of 0 degree turn. Changing this key just says what angle the tile is being viewed from in game in the most basic sense.
  • FLIP - Flip the texture horizontally and vertically like a mirror image, however retain the rotation in-game of the piece in question. This helps to cut down on the textures needed. Values are 0 and 1 - False and True.

References

  1. Network Specs