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.