Difference between pages "Template:Expand" and "Network INI"

From SC4D Encyclopaedia
(Difference between pages)
Jump to navigation Jump to search
sc4e>Freedo50
 
sc4e>Blue Lightning
(→‎MiscNetworks: Seperated out bridges, added info)
 
Line 1: Line 1:
−
<noinclude>This template is to be used on pages which are not yet complete, to advertise that they need completion by anyone that has sufficient knowledge.
+
{{check}}
  
−
{{expand}}</noinclude>
 
  
−
<includeonly>
+
{{Infobox TGI |
−
{| width="500" cellspacing="0" cellpadding="10" align="center" style="background:#FFFFFF;"
+
| name        = Intersection Ordering RUL
−
! rowspan="2" style="background:#1E90FF;"| &nbsp;
+
| format      = Network INI/[[RUL File]]
−
! rowspan="2" | [[Image:Wiki_logo.gif|300px]]
+
| type        = 0x00000000
−
! This document is incomplete or unfinished.
+
| group      = 0x8A5971C5
−
|-
+
| instance    = 0x8A5993B9
−
| If you have knowledge on this subject, please help out by [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} editing this page]. Further information may be found on the [{{SERVER}}{{localurl:{{NAMESPACE}}_talk:{{PAGENAME}}}} discussion page].
+
| comments    = ''See also: {{NetSpecs|INI Network & Bridges}}''
−
|}
+
}}
−
</includeonly>
+
 
 +
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
 +
 
 +
<blockquote>
 +
In locales that have drive-on-left as default, the path system reverses<br />
 +
all path directions from the stored points.  This handles all cases  <<<this does not cover non-car path types<br />
 +
except the one-ways, which must remain consistent with the one-way flags<br />
 +
stored in the occupants. The normal one-way tiles are designed to be<br />
 +
bidirectional and are handled correctly by the auto-flip code, but some<br />
 +
of the intersections have pre-baked one-way paths that are incorrectly<br />
 +
flipped.  We have explicit forward and reverse versions of those, so<br />
 +
what we do here is swap the two versions for drive-on-left so that the<br />
 +
reversal code re-flips the one-way paths back to their correct<br />
 +
orientation.<br />
 +
<br />
 +
Format:<br />
 +
<br />
 +
  <anything> = <match-id>, <match-mask>, <new-id>, <add-mask><br />
 +
<br />
 +
match-id: value to look for after masking<br />
 +
match-mask: AND mask to eliminate dont-care bits from the match<br />
 +
new-id: base for new texture ID on a match<br />
 +
add-mask: bits from original ID to add to new-id<br />
 +
 
 +
</blockquote>
 +
 
 +
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<br />
 +
<code>
 +
1 = 0x03000000,0xFF000000,0x43000000,0x00FFFFFF ;rail ~ also contains some custom paths
 +
</code><br />
 +
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 [http://en.wikipedia.org/wiki/Bitwise_AND#AND 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.<br />
 +
2. Game checks Network INI to see how the path should be replaced.<br />
 +
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. <br />
 +
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.<br />
 +
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.<br />
 +
 
 +
===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<br />
 +
<code>
 +
<anything> = <source IID>, <mask>, <target IID>, <mask>, <OPTIONAL: rotation>, <OPTIONAL: flip>
 +
</code><br />
 +
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:<br/>
 +
<blockquote>
 +
Many of the shadows in the network system have similar or identical graphics.<br />
 +
This section provides a general mechanism for remapping shadow textures, using<br />
 +
entries of the form:<br />
 +
<br />
 +
<anything> = <match-id>, <match-mask>, <new-id>, <add-mask> [, <rotation>] [, <flip>] [, <continue>] [, <submask>]<br />
 +
<br />
 +
match-id: value to look for after masking <br />
 +
match-mask: AND mask to eliminate dont-care bits from the match.<br />
 +
new-id: base for new texture ID on a match<br />
 +
add-mask: bits from original ID to add to new-id<br />
 +
sub-mask: bits from original ID to subtract from new-id<br />
 +
rotation: rotation to apply to remapped texture before applying tile rot/flip<br />
 +
flip: flip to apply to remapped texture before applying tile rot/flip<br />
 +
continue: if '1', continue processing rules after this one<br />
 +
<br />
 +
For instance, if we wanted to map textures 12340000 through 1234000F to<br />
 +
00010000:0001000F:<br />
 +
<br />
 +
dummy = 0x12340000, 0xFFFFFFF0, 0x00010000, 0x0000000F<br />
 +
<br />
 +
Or, to map all zoom 2 and 3 textures to zoom 1:<br />
 +
<br />
 +
z2to1 = 0x00000001, 0x0000000F, 0x00000000, 0xFFFFFFF0<br />
 +
z3to1 = 0x00000002, 0x0000000F, 0x00000000, 0xFFFFFFF0<br />
 +
<br />
 +
Higher entries have precedence.
 +
</blockquote>
 +
 
 +
This is extremely similar to the UK Path Remapping section. The difference is the addition of the <code>submask</code>, which is usually unused anyways. <code>Continue</code> 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 <code>default = 0,0,0,0 ;use edge remapping for all other shadows</code>, which passes off all non-matched remaps onto the next section.
 +
 
 +
===Shadow Edge Remapping===
 +
This section handles remapping by checking network edge connection flags (see [[RUL 0x10000000]] for details about edge flags).
 +
 
 +
Maxis says...
 +
<blockquote>
 +
For certain pieces in complex intersection models it is inconvenient<br />
 +
to map shadows by piece IDs, particularly those on diagonals.<br />
 +
Here we map pieces to shadows by edge flags instead:<br />
 +
<br />
 +
  <anything> = <network-type>, <edge-conditions>, <new-texid>, <add-mask> [,<rotation>] [,<flip>]<br />
 +
<br />
 +
network-type:  'highway', 'lightrail', etc.<br />
 +
edge-conditions: 32-bit edge mask (0xbbrrttll)<br />
 +
new-texid: base texture ID for new shadow<br />
 +
add-mask: bits from piece ID to add to base texture ID<br />
 +
rotation: pre-rotation to apply to new shadow<br />
 +
flip: pre-flip to apply to new shadow<br />
 +
<br />
 +
The edge remapping table is used whenever the rule entry in the<br />
 +
regular shadow table has a <new-mask> of 0.<br />
 +
</blockquote>
 +
 
 +
Should be self explanatory at this point. This section is strange that it does not use the hexadecimal prefix ''0x'' in its values.
 +
 
 +
An example line: <code>histraight = highway,  04020002, 02001500, 0000000F, 0, 0</code>
 +
 
 +
===PowerPoles===
 +
This section is not very well understood even given Maxis's comments:<br/>
 +
<blockquote>
 +
This section lists the different power pole models present and indicates the connection<br/>
 +
directions supported by those models. The supported directions are represented using a 4-bit<br/>
 +
flag. Bit0  (LSB) is set to 1 if the pole supports connection in direction 0, Bit1 is set to<br/>
 +
1 if the pole supports connection in direction 1 and so on..<br/>
 +
<br/>
 +
<code>
 +
    +------>x<br/>
 +
    |<br/>
 +
    |<br/>
 +
V<br/>
 +
    z<br/>
 +
</code>
 +
direction 0 : parallel to x axis<br/>
 +
direction 1 : line connecting (-k, -k) to (k, k)<br/>
 +
direction 2 : parallel to z axis<br/>
 +
direction 3 : line connecting (-k, k) to (k, -k)<br/>
 +
</blockquote>
 +
 
 +
===MiscNetworks===
 +
This section is depreciated and has no function.
 +
 
 +
===TileVerifiers===
 +
 
 +
 
 +
{{Navbox/FORMAT}}
 +
 
 +
[[Category:File Formats/SC4]]

Revision as of 07:25, 25 June 2012

Template:Check


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.

Shadow Edge Remapping

This section handles remapping by checking network edge connection flags (see RUL 0x10000000 for details about edge flags).

Maxis says...

For certain pieces in complex intersection models it is inconvenient
to map shadows by piece IDs, particularly those on diagonals.
Here we map pieces to shadows by edge flags instead:

<anything> = <network-type>, <edge-conditions>, <new-texid>, <add-mask> [,<rotation>] [,<flip>]

network-type: 'highway', 'lightrail', etc.
edge-conditions: 32-bit edge mask (0xbbrrttll)
new-texid: base texture ID for new shadow
add-mask: bits from piece ID to add to base texture ID
rotation: pre-rotation to apply to new shadow
flip: pre-flip to apply to new shadow

The edge remapping table is used whenever the rule entry in the
regular shadow table has a <new-mask> of 0.

Should be self explanatory at this point. This section is strange that it does not use the hexadecimal prefix 0x in its values.

An example line: histraight = highway, 04020002, 02001500, 0000000F, 0, 0

PowerPoles

This section is not very well understood even given Maxis's comments:

This section lists the different power pole models present and indicates the connection
directions supported by those models. The supported directions are represented using a 4-bit
flag. Bit0 (LSB) is set to 1 if the pole supports connection in direction 0, Bit1 is set to
1 if the pole supports connection in direction 1 and so on..

+------>x
|
|
V
z
 direction 0 : parallel to x axis
direction 1 : line connecting (-k, -k) to (k, k)
direction 2 : parallel to z axis
direction 3 : line connecting (-k, k) to (k, -k)

MiscNetworks

This section is depreciated and has no function.

TileVerifiers

SimCity 4 File Formats
Specialty Formats
DBPF • DBDF • RUL File • LTEXT • MXF
Common Formats
Retrieved from "https://wiki.sc4devotion.com/index.php?title=Template:Expand&oldid=4114"