IntersectionCells
This is extremely complex, but try to bear with me. If there are questions I'll try to edit this post instead of confusing the issue more by adding extraneous information. Some of this file is still unknown, but we know enough of it to edit most anything network related:
There are three sections. The first is the [ordering] section. This is fairly well documented by maxis:
;-------------------------------------------------------- ; Intersection ordering ; ; RotationRing = hex-id [,hex-id...] ; ; Creates a ring of rules that are cycled through via ; Home/End or automatically by the tool as it tries to ; auto-fit rules to the current mouse point. ; ; AddTypes = hex-id [,hex-id...] ; ; Attaches another ring to the last ring, creating type ; rings perpendicular to the rotation ring. Type rings ; can be cycled through via Tab/Shift-Tab. Generally, ; type rings are set up to preserve rotation as you ; cycle through rules of different network types. ; ; A given rule can only belong to ONE rotation ring and ; ONE type ring. Attempting to hook a rule into more than ; one rotation or type ring will result in the rings getting ; trashed. ;
So essentially, all of the rotations of a given intersection type are put on a single line, in clockwise order. The different network types (road, avenue, oneway, oneway reverse) are placed on successive lines so that you can tab through the network types, or home/end through the rotations. The Hex-id's are the last four digits of an instance and the first 4 digits correspond to the ButtonID (exemplar for that interchange).
The next section is odd to say the least. It simply reads:
[Intersection Tile Types] DefineType = 0x00000000,Road DefineType = 0x00000002,Highway
This section just defines type 0 and 2 as road and highway, which is consistant with the traffic exemplar, however there seems to be no use for this data as it isnt referenced anywhere we've noticed in the network cell data sections. This appears to be a backup system used by maxis prior to rush hour that is obsolete at the present for defining intersection types. Modifying the values here has no effect on building intersections in game. Infact commenting out the whole section does nothing either, so I wouldnt worry about this.
Now, on to the big boheamoth. The entire rest of the file consists of [HighwayIntersectionInfo_InstanceIDHERE] lines. The instanceIDs for these sections all have zeros in the first four places. This is necissary for anything ploppable, because of the way the buttons call the rotation rings. But for non-ploppable (automatically created) interchanges, it may not be required. Still though, the convention is preserved.
Please keep in mind that within each of these sections, these lines can come in any order. The general progression is symilar, but some things are moved around in different interchange definitions. However, It does not change how they are loaded in memory.
Maxis' comments say this:
;-------------------------------------------------------- ; ; Highway intersection rules. ; ; StepOffsets = start-offset, end-offset ; PaddingCell = x-offset, z-offset, edge-types ; CellLayout = <mix of characters> ; '+': Add invisible tile for piece ; 'n': Tile must be a new network tile from current drag ; 'p': Tile must be a previously existing network tile ; 'X': Both 'n' and 'p' apply (intersection tile) ; '.': Don't care ; 'P': Padding tile ; '<': Set center row ; '^': Set center column ; CopyFrom = source-rule-ID ; Invert = 1 ; Transpose = 1 ; ConvertQueryID = string-instance-id ; PlaceQueryID = string-instance-id
The translation: Let's look at an actual interchange RUL and pull it apart, piece by piece. That will allow us to understand it more easily.
[HighwayIntersectionInfo_0x00002130]
This defines the instanceID of the given interchange. The text before the ID must remain as "HighwayIntersectionInfo_" or else the RUL will not be recognized.
Piece = 8.0, 8.0, 0, 0, 0x02012300
The 'Piece" lines are real oddballs. They predate rush hour, and have been rendered partially useless, and however are still neccessary and commenting one out will crash the game. Previously an intersection preview was made using a single ploppable piece. Since Rush hour that has been changed so that the effect directory makes the preview, however this line is still absolutely neccessary for the game to build the intersection.
The first two values control the position of the cursor when placing the intersection, relative to the preview of the intersection. This does not affect the actual plopping position though. The first is how deep to the left, from the right side of the intersection on cell layout, the cursor should be in the form of a value with one decimal, the second is how variated to the top or bottom on the cell layout the cursor should be from the vertical center.
The 3rd is a rotation key for the preview, setting it to 1 will turn the preview of the intersection by 90 degrees and so forth for 2 and 3
The 4th is a sort of preview flipkey. Setting it to 1 instead of 0 will make it so that if you were to build a t intersection on one side of a highway with the face pointing down, hovering the intersection on that side of the highway would now show it as pointing up on the z axis instead. It has no effect on the actual plop however.
The 5th value contains the pre RH instance id for the entire intersection to use as a preview.
StepOffsets = -6, 6
The Stepoffsets line sets parameters for dragging that must be achieved before the intersection can be considered valid The Second value is how far from the intersection you must continue dragging until it is valid, the bigger the number, the further from the intersection you must drag. The first value controls the start offset or where you should be dragging from to make it a legal intersection, however it doesnt seem to work, and changing the value to a high negative, a positive, or a 0 has had no effect on the starting drag point neccessary that I can see whatsoever.
PreviewEffect = preview_gh_av_straight_par
The 'PreviewEffect' lines refference string values found in the EffectsDirectory file, which in turn refferences s3d files that are used for the semi-transparent preview ofthe interchange before you click the mouse button to plop it.
CellLayout = ab..... CellLayout = cd..... CellLayout = cd+AB.. CellLayout = ce+CD.< CellLayout = ce+CD.. CellLayout = cd+EF.. CellLayout = cd..... CellLayout = fg..... CellLayout = .^.....
The "CellLayout" lines show you where different types of tiles are located. Contrary to the included comments from maxis, there are only four predefined values for the CellLayout. First is the carrots (^,< which define what the center tile is and where your mouse will be, so that the preview can be aligned with the intersection when it's plopped. Next, there are periods (.) which tell the building engine to not look for a tile to plop in that position. Finally, there are plus signs (+) which tell the building engine to look for a tile to place there, but the tile is a non-standard road tile, because it has no tile side rules. This is true for the actual ramps between road/highway and highway/highway.
CheckType = a - groundhighway: 0x02040000,0xffff00ff check CheckType = b - groundhighway: 0x02000004,0xffff00ff check CheckType = c - groundhighway: 0x02040200 optional CheckType = d - groundhighway: 0x02000204 CheckType = e - groundhighway: 0x02000204 optional CheckType = f - groundhighway: 0x00040200,0x00ffffff check CheckType = g - groundhighway: 0x00000204,0x00ffffff check CheckType = A - avenue: 0x02040000,0xffff00ff check CheckType = B - avenue: 0x02000004,0xffff00ff check CheckType = C - avenue: 0x02040200 CheckType = D - avenue: 0x02000204 CheckType = E - avenue: 0x00040200,0x00ffffff check CheckType = F - avenue: 0x00000204,0x00ffffff check
This is where it gets hairy. The CheckType lines do not have to correspond to any alphanumeric code, any capital or lowercase letter (and perhaps other ascii characters) are recognized. For each CheckType line, there are two possible sections, one for each network type which crosses the tile. Each section has the following format:
networkname: "RULFlagByte" "check" "optional" ", HexMask"
"RULFlagByte" is identical to the flagBytes described in the other complex rules above.
"check" makes the building engine check if the given network tile is in this position. If so, it must correspond to the RULFlagByte portion that the HexMask defines.
"optional" tells the building engine to not look for a s3d file for this interchange. Rather, it looks for a network tile of that network which corresponds to the RULFlagByte, and uses that s3d or FSH. If a tile of this network is there, it must correspond to the portion of the RULFlagByte that the HexMask defines.
"HexMask" tells the check and optional conditions which sides of the tile to look at. FF deonotes that it must match, 00 denotes that it does not need to comply.
ConsLayout = ...... ConsLayout = |..... ConsLayout = |X.... ConsLayout = .X||.< ConsLayout = .X||.. ConsLayout = |X.... ConsLayout = |..... ConsLayout = ^.....
Contrary to what was originally thought, ConsLayout controlls the terrain for the intersection. Basically its there to normalize the terrain to make sure the intersection plops properly. TerrainLayout would have been a better name. Each type of usable character, including -,|,/,\,X,#,+ symbolizes a different area of the terrain to normalize, so -'s would have the terrain changed, so that all the -'s looked and acted properly and werent on an angle. The -,|,/,and \ represent the various angles of the road to correct the terrain for, the #'s are for the center of the intersection or the base, which must all be on the correct terrain to look good, and the X's are for onramps, which if not present will have the onramps on wierd angles on hilly terrain. The < and ^ are for setting the center column and row of the intersection as per CellLayout. Finally, a + tells that piece to conform exactly to the terrain its on.
AutoTileBase = 0x0C883000
This line is what tells the building engine where to look for the sliced up tiles. It refferences an Exemplar instanceID which then refferences an s3d file. The way it works is basically by placing a grid over the effected interchange. It finds the most top left tile in order to include all the (x) values which are not optional in the CellLayout, and defines that as this hex value. For each tile below it, the instance is incremented one value in the seventh digit. For each tile to the right of it, the instance is incremented one value in the sixth digit.
PlaceQueryID = 0xA0000003
This is the instance id of the text that is displayed while the interchange is hovering and ready to be placed
ConvertQueryID = 0xA0000001
This is the instance id of the text displayed in the dialog when confirming that you would like to build the current intersection
Costs = 400
This is the displayed cost of the intersection in the highway menu as well as the cost to build the intersection assuming all needed highway pieces minus the intersection pieces are already in place. The price increases substantially for each piece of highway not in place or when the intersection piece is not being built on flat land.
Autoplace = 1
Having an autoplace line states that the intersection can build without querying the user when the conditions are right such as when drawing a t intersection with a highway.
OneWayDir = 4
This specifies the direction the one way road is going out of the 8 possible radiating directions where a highway is in an intersection with a one way road.
AutoPathBase = 0x09210000
This line specifies the paths taken when a one way road interacts with a highway. It may be used in other ways though this is the only way I've seen it. It works by picking a tile in the top left most area of the intersection containing set tiles and defining that tile as this value (an instance id base), then working by increasing the 6th digit one step per tile to the right, and increasing the 7th digit one step per tile down from the prime tile to make the correct instance id to search for when locating the correct path for the tile.
HandleOffset = 2,0
This line specifies the place to build the intersection relative to where you're hovering. Both values can be any number that can fit on the map from your position both positive or negative. The first value is the distance straight out from your cursor in a line the intersection will build at, either x or z. The second value is the distance to the side that the intersection will build at, once you have reached the destination specified by the first value. IE you can have an intersection build 20 tiles out, and 15 to the side of where you are trying to plop.
ReplacementIntersection = 0, 0
The Replacementintersection line is rather useless as far as I can tell, it takes an intersection and rotates and flips it to create another intersection as needed with the first value being the rotation and the second being the flip. If there's any use for having these values in an intersection as such I havent seen them yet. Perhaps this is why all maxis use of this line is always 0,0.
[HighwayIntersectionInfo_0x00002016] CopyFrom = 0x2010 Rotate = 3 Transform = 1
These entries cover the other rotations. It copies the RUL from one instance and rotates clockwise 90 degrees * the given number, or 'transforms' which basically flips all of the tiles in thier orientation. The rotate and transform could be used together, but are not in practice, since any rotations which require both are simply transformed from an interchange which has already been rotated.
That should cover all data relating to network intersection cells. This, along with textured models, some exemplars, and a decent use of the effect directory for the previews should allow the creation of an infinite number of user definable highway interchanges. Of course they'll take a lot of time to create but this hasnt stopped anybody yet.
Table of GIDs for use with Shadow Remapping exemplars, and network Ruls/Exemplars for referencing S3D files---------------------
Power Poles: 0x088E1962 Dirtroad: ??? Streets: ??? Roads: 0x2821ED93 Onewayroads: 0xCBE084CB Avenue: 0xCB730FAC Groudhighway: 0xEBE084D1 Elevated Highway: 0xA8434037 Rail: 0xE8347989 LightRail: 0x2B79DFFB Monorail: 0xEBE084C2
Normally highway GIDs are used for intersection Exemplars. With one way road intersections, the path files should use Oneway GID's or problems will arise with traffic.
