Difference between revisions of "Network INI"
sc4e>Blue Lightning (→Texture Remapping: Fleshed out info) |
sc4e>Blue Lightning (→Texture Remapping: Fleshed out info) |
(No difference)
|
Revision as of 06:01, 25 June 2012
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.
Contents
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
Shadow Edge Remapping
PowerPoles
MiscNetworks (Bridges)
TileVerifiers
|