From SimsWiki
Jump to: navigation, search
This article is imported from the old MTS2 wiki. You can help Sims2Wiki by cleaning it up. It's original page with comments can be found at
The INI file that's been classified as Network remapping actually controls much more than this, but as its the first section, it seems the easiest thing to call it. A better name would probably just be Remapping file.

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
<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.


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


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.


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.


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


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 :)

Personal tools

game select