Remapping
The file contains 9 distinct sections. All bridge exemplars are considered a single section for the sake of argument and since they hold the same structure.
[DebugRules] This section actually is pretty much useless to us, it contains a reload file command, a trace error command, and a debug command. Only useful with debug builds of the game though.
[UK path remapping] Better to quote maxis to explain this one.
- In locales that have drive-on-left as default, the path system reverses
- all path directions from the stored points. This handles all cases
- 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>
An example is : 1 = 0x09201000,0xFFFFF000,0x09209000,0x00000FFF
Anything: any id that you think will help you remember this line match-id: the instance string to search for match-mask: the F's signify the parts of the matchid that are important in the search. 0 areas are not important to the search. new-id: the new instance id set to use. add-mask: the parts to take from the results of the original search and replace on the new instance id set.
[Texture remapping] groundhighways = 0x0AC00A00,0xFFFFFF00,0x02001500,0x000000FF,2,0
This is the header and first line in the texture remapping section. Much like the above the data is mapped out as follows <name> = <matchid>, <bits of matchid to pay attention to>, <newid range>, <bits to add from the original ID>, <rotation>, <flip>
[Shadow remapping]
- Many of the shadows in the network system have similar or identical graphics.
- This section provides a general mechanism for remapping shadow textures
This is the intro to the shadow remapping section. All the data is the same as the previous exception with the addition of <continue> and <submask> optionary's at the end of the data lines. A Sample would be: intx_straightclover = 0x0C004080, 0xFFFFF080, 0x0C0040D0, 0x00000F00, 2, 1, 1, 0x000000F0
The last 1 here is the continue which means to continue processing rules after this rule and the 000000f0 is the submask. The submask is bits from the original result ids of the search that you dont want added to the new ids
It ends on this line: default = 0,0,0,0 ;use edge remapping for all other shadows Which just tells it to start using the next section for things not covered above.
[Shadow edge remapping]
- 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>]
This is the intro for shadow edge remapping and here is two sample lines: hidiagcen = highway, 01030103, 0AC00000, 00000000, 0, 0 mostraight = monorail, 02000200, 0D031500, 0000000F, 0, 0
anything is the same as always <network-type> is the network the rule belongs to, highway, monorail, lightrail etc. <edge-conditions> rule maps for the edge of the tile using the standard rule format. <new-texid> is the texture id for the new shadow The rotation and flip are the same as always
- The edge remapping table is used whenever the rule entry in the
- regular shadow table has a <new-mask> of 0.
[PowerPoles]
- 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)
- These lines specificy the directions. Now the format
Bitflag=ModelResource ModelResourse: An instance ID for an exemplar of the powerpole containing more info for said power pole includine resource keys and monthly upkeep. Bitflag: Each possible power pole connection is defined by a 4 bit flag preceeded by a 0, the flag is in binary with each of the 4 bits representing a direction, turned on or not. These define all 15 possible power pole connections from none allowed to all 4 directions allowed. An example 0x0d=0x05000305 - d is 1101 so all but connections in direction 2 are possible
[MiscNetworks]
- Road/rail/highway are drawn these many meters above terrain as a temporary solution for
- z-fighting. If the value is zero, then we don't need this system any more --Paul P.
HtOfNetworkAboveTerrain=0.0
Pauls explanation is self explanitory. Z-fighting is when two things try to render in the same space and one gets cancelled out.
Bridge exemplar data Bridge Exemplar data contains multiple sections in brackets having the following format --- [NetworkBridgeExemplars] Where network is any usable network (Road, Rail, Highway, Avenue, GroundHighway, LightRail, MonoRail) Bridgenumber = 0xTID, 0xGID, 0xIID, Bridge Name 4 = 0x6534284a, 0xa82ca30f, 0x0a000004, medium suspension highway bridge
Bridgenumber: The id number of this bridge in its respective BSPEC file, IE bridge 1, bridge 16 etc. TID,GID,IID: type group instance Bridge Names: The Chosen name for the bridge. May be in any order and is for identification purposes with the person working on this file. This name doesnt appear to have any other references in the game.
[TileVerifiers]
For purpose its best to quote Maxis:
- Tile pattern verifiers are workarounds for the fact that
- we don't have full multitype rules -- basically, they
- enforce that a multistep patching solution completes.
- If all of the specified neighbor tiles aren't present,
- the center tile is booted as unsolved and the draw fails.
The format is: base-pieceID = pos,pieceID,rot,flip [,pos,pieceID,rot,flip] [,pos,pieceID,rot,flip]... --Each (pos,pieceid,rot,flip) represents another tile to check for to validate the center tile
base-pieceID: The instance of the exemplar for the base (center) tile to check outwards from pos: position of the check tile outwards from the center tile in a standard rotation starting at the top, if multiple matches exist, any of them may pass the check tile validation rot: The rotation of the check tile to validate flip: the flip or lack there of, of the check tile to validate
Example:
- avenue to el highway prevent
0x04011300 = 1,0x04011400,0,0, 8,0x04011400,2,1, 7,0x04011300,2,1, 6,0x04011200,2,1, 5,0x04011200,0,0 --This checks tile 04011300 to make sure all the other 5 check tiles are present in relation to itself or it cant be placed
This covers all data in the Network INI remapping file :)
