Network INI

TGI Info
Name	Intersection Ordering RUL
Format	Network INI/RUL File
Type Group Instance	0x00000000 0x8A5971C5 0x8A5993B9
Comments
See also: INI Network & Bridges

The Network INI is a file which handles a number of different functions related to the game's transit and utility networks. While technically a different file type, as evidenced by its Type ID, it bears some resemblance to the RUL Files.

History

Prior to the Rush Hour expansion in 2004, the Network INI carried all of the game's network RUL code. With Rush Hour and the expansion of the transit network systems it entailed, Maxis decided to modularize some of the more common and intensive operations into separate RUL files, leaving the more specialized functions in the INI. Theoretically, code from the post-Rush Hour RUL files can still be run from the INI.

Sections

The Network INI file is divided into eight separate sections, each handling a certain type of functionality.

Debug Rules

The DebugRules section contains debug settings (as the name entails) that Maxis used during testing. Changing the values now have no effect.

Keys

Reload

Unknown

Default Value: 0

Trace

Unknown

Default Value: 0

Debug

Unknown

Default Value: 0

UK Path Remapping

This section handles Left Hand Drive (LHD) conversion for certain networks and pieces; namely rail-type networks. Maxis in the code says about this section

In locales that have drive-on-left as default, the path system reverses
all path directions from the stored points. This handles all cases <<<this does not cover non-car path types
except the one-ways, which must remain consistent with the one-way flags
stored in the occupants. The normal one-way tiles are designed to be
bidirectional and are handled correctly by the auto-flip code, but some
of the intersections have pre-baked one-way paths that are incorrectly
flipped. We have explicit forward and reverse versions of those, so
what we do here is swap the two versions for drive-on-left so that the
reversal code re-flips the one-way paths back to their correct
orientation.

Format:

<anything> = <match-id>, <match-mask>, <new-id>, <add-mask>

match-id: value to look for after masking
match-mask: AND mask to eliminate dont-care bits from the match
new-id: base for new texture ID on a match
add-mask: bits from original ID to add to new-id

Reading the notes that Tropod and other modders have written into the NAM's Network INI will explain further about minor quirks and NAM conventions regarding this section.

An example line from this section looks like this
1 = 0x03000000,0xFF000000,0x43000000,0x00FFFFFF ;rail ~ also contains some custom paths
On the left side of the equal (=) sign can be anything, but by convention it is a number counting up for each subsection of code. The first value to the right of the equal sign is the source IID. This in conjunction with the second value tells the game which IIDs this line affects. This is calculated with a bitwise AND. Therefore, this line only applies to path files with an IID starting with 0x03. The rest of the digits can be any value, since all the game cares about is the first two digits.

The third and fourth values is the target IID and corresponding mask. This time, the bitwise AND is used by the game to determine which digits of the target IID are insignificant and are to be replaced with the source IID's values.

In summary, this line will be evaluated as such:

1. Game in LHD mode loads up path 0x03001400.
2. Game checks Network INI to see how the path should be replaced.
3. Game evaluates a line by taking the bitwise AND of the first value and the second, and the path-in-question IID and the second value.
3a. If the two are equal, do a bitwise AND on the path-in-question and do another one on value three and the inverse of value four. Add the two results to get the final IID. Finish.
3b. If the two are not equal, evaluate the next line. If the end of the section is reached, the path file is not replaced.

Texture Remapping

The texture remapping section handles special preview textures for draggable networks. Normally, when a network is dragged, the texture that you see is the texture that will be placed, disregarding wealth. If there are models that will be placed on a tile, then the game will look for a texture at the same IID as the model exemplar. If no texture is found in either case (texture network or model network), then an orange-brown square is drawn.

There are issues with using textures at the same IID as the model, usually with wealthing. To avoid this, preview textures can be remapped, which is what this section does. Maxis uses it to provide previews for ground highways and elevated highways.

The syntax for this section is as follows
<anything> = <source IID>, <mask>, <target IID>, <mask>, <OPTIONAL: rotation>, <OPTIONAL: flip>
The masking method used here is the same one used by UK Path Remapping (see above). Rotation and flip rotate and flip the texture, and are optional. If one is to be used, the other must also be specified.

The NAM uses this section to provide preview textures for ERHW-4 and E-STR, as well as custom maxis highway pieces such as tight s bends.

Shadow Remapping

Shadows for networks in SC4 are handled in three ways: Using the Shadow Remapping section in the Network INI, using the Shadow Edge Remapping section in the Network INI, and providing a shadow texture at the same IID as the item. These are evaluated in order.

For this section, Maxis notes it as such:

Many of the shadows in the network system have similar or identical graphics.
This section provides a general mechanism for remapping shadow textures, using
entries of the form:

<anything> = <match-id>, <match-mask>, <new-id>, <add-mask> [, <rotation>] [, <flip>] [, <continue>] [, <submask>]

match-id: value to look for after masking
match-mask: AND mask to eliminate dont-care bits from the match.
new-id: base for new texture ID on a match
add-mask: bits from original ID to add to new-id
sub-mask: bits from original ID to subtract from new-id
rotation: rotation to apply to remapped texture before applying tile rot/flip
flip: flip to apply to remapped texture before applying tile rot/flip
continue: if '1', continue processing rules after this one

For instance, if we wanted to map textures 12340000 through 1234000F to
00010000:0001000F:

dummy = 0x12340000, 0xFFFFFFF0, 0x00010000, 0x0000000F

Or, to map all zoom 2 and 3 textures to zoom 1:

z2to1 = 0x00000001, 0x0000000F, 0x00000000, 0xFFFFFFF0
z3to1 = 0x00000002, 0x0000000F, 0x00000000, 0xFFFFFFF0

Higher entries have precedence.

This is extremely similar to the UK Path Remapping section. The difference is the addition of the submask, which is usually unused anyways. Continue is always implied to be 1 unless otherwise specified. Maxis's final comment regards the line number of a line. Because lines are evaluated sequentially, a line at the very top of the section will override a line below it that has the same IID match.

This section is ended by the line default = 0,0,0,0 ;use edge remapping for all other shadows, which passes off all non-matched remaps onto the next section.