DISCOVERY: File Formats, The Positioning formats (RUL, and Sc4path)

[RalphaelNinja 244]

 

This reminds me of magic eye where if you cross your eyes and relax, the 3d image slowly comes into focus.... then you lose it and you try again....

 

You do realize 7 that MaxisMike has this nifty program (that we don't have) that allows him to draw up these wonderful ruls and paths without these mind numbing mind gyrations.

 

Thanks for sharing the knowledge..

Ralphael

[DarkMatter 21]

Hopefully soon, thanks to 7ths mind numbing girations, we'll have a tool that can do it all for us, too! I needed this information to write our own tool to to it all for us.

[the7trumpets 10]

Just thought I'd add something:

 

The official name for sides 11 and 13 are 'blends'.  I guess this is because they are used to blend between diagonal 01/03 sides and straight 02 sides.

[DarkMatter 21]

Any way you could give me a visual representation of 11 an 13? I still don't really understand how they differ, visually, from a 1 or a 3.

[Karybdis 34]

Hmm...I think this is the simplest way to put it DM. For things other than 11,13 the edges of the road, will be such that the sidewalk on each side of the road is the exact same thickness for that edge

For 11,13, the sidewalk will not be the same thickness on each side of the road. IE the road is offcentered on the edge it has come into contact with. It is imperfect if you will

This is more or less. There can be minute offsets as you can see from 7's diagrams.

[the7trumpets 10]

Yes Karybdis, that is right.  One more addition:

 

As previously mentioned, 04 is a 'median' flag.  This is present only for two tile wide networks (avenues and highways).  Whenever a piece is only half (or a third) of the network width, the tile side is 04.  This is true even for the end turnaround sections of the avenue, which look like they have two 02 ends.  In fact, one of the sides is a 02 side, and the other is a 04 side, which connects to the other side of the avenue.

[DarkMatter 21]

Words still arn't explaining it enough. A picture would REALLY help, but it kind of seems that you guys don't even know how to represent 11 and 13 visually. I don't see how the road beeing slightly offset from the center requires a special representation in RUL files. You drew green lines in your figure to represent 1, 2, and 3 type connections. Where would the green lines go for 11 and 13?

[redlotus 16]

OK.  I think that I've finally got a grip on all of this.  However, I do have one question.  Looking at all of the diagrams, is it safe to assume that a type 11 edge will have to 'mate up' with a type 13 edge and vice-versa?

[DarkMatter 21]

Well, the numbers specify what edges "match". A 13 matches a 13, an 11 matches an 11, a 2 matches a 2.

[redlotus 16]

That's what I had first assumed, as well.  The only problem is that type 11s, as 7 describes them, will not match up.  Take the road texture 0x00026300 from 7's post above.  The edges of this piece are 2,11,3,11 so that would mean that the north and south edges would connect.  However, if you try placing two of these pieces, one on top of the other, this is what you get:

 

Notice the areas that I circled in red.  There is no way that these two type 11 edges can match up with each other.    Am I missing something?

[Karybdis 34]

In a sense, yep you are. You're forgetting that you have "2," lines in the rules. The adjacent tile limiters. Using these you can say that the adjacent tile must be a straight piece, or must have exactly these edge types for it to be allowed, regardless of if the numbers on the edges match up or not in the "1," lines.

[the7trumpets 10]

----------------

On 10/28/2003 8:34:28 AM redlotus wrote:

That's what I had first assumed, as well.  The only problem is that type 11s, as 7 describes them, will not match up.  

 

 There is no way that these two type 11 edges can match up with each other.

    Am I missing something?

----------------

Basically there are two pieces of information necissary for tiles to 'match up'.  One is the direction the road is going in, and the other is where along the border the road is centered.  It is true that there are some 11 sides with the center shifted to the right, even though the road goes to the left.  Likewise there are some 13 sides with the center of the roadway shifted to the left instead of the right.

I'll draw up some pictures when I get a chance, but the gist of it is that the 11 or 13 designation denotes which direction the tile is going and whether it is a 'blend' or not.  It does not describe whether the road is centered toward the left or the right of the center of the tile side in question.  The rest is taken care of by the RULes.  So, not all 11 sides will match up with other 11 sides, but some of them will.  Which ones are valid are described in the rules.

[the7trumpets 10]

Here goes.  I'll start my explination of the complex Rules.

 

 

Let's start with 0x10000001.  This is the file which dictates what happens when one network is drawn over a different network.  The network building engine calculates how the new network will be laid, as if no other networks were present.  Then it looks to see if there are other network tiles of a different network in the way.  If they are,  it searches for a solution in this file.  If none is found, it results in an impossible network draw (red line).  The format is as follows:

 

Maxis' coments:

; format:
; name=roadMajorTypesFlag,streetMajorTypesFlag,textureId,rotation,flip
;
; name is really not used and is just for our reference.
; the flag byte order is SENW (I think?)
;

 

Translation:

 

The file is separated into sections by titles in [brackets].  The title has the following format:

 

[Network1Network2IntersectionSolutions]

 

Network1 and Network2 are the two networks which are being overlapped.  Valid network names are Road, Highway, Street, Rail, Avenue, OneWayRoad, LightRail (which is the el-train), and MonoRail.  There must be no spaces or punctuation of any kind in the title.

 

Within each section, there are lines which describe the tile to place in the case where tiles of network1 and network2 are placed on top of each other, with the defined RUL edge values.  The format of these lines is as follows:

 

name=Network1MajorTypesFlag,Network2MajorTypesFlag,textureId,rotation,flip

 

textureID = the InstanceID of the resulting transit tile put in this spot

rotation = the rotation of the new transit tile

flip = the flip of the new transit tile

name = doesn't matter, anything is valid.

 

 

The format of the 'MajorTypesFlag' entries is the following:

 

Network1TypesFlag = 0xN1sN1eN1nN1w

Network2TypesFlag = 0xN2sN2eN2nN2w

 

N1=Network1

N2=Network2

s,e,n,w = South, East, North, West

 

It holds the RUL edge values for each network, which are:

00 - no connection

01 - left at 45degree angle

02 - straight

03 - right at 45degree angle

04 - median

 

The blends (11, 13, and others for non-road networks) are simply not used in this file.  This is because you cannot create intersections between networks at curves, it must be a straight diagonal or orthagonal section of both networks.

 

 

 

Example:

 

This is in the [RoadOneWayRoadIntersectionSolutions] section:

 

;piece 71 for elbow one-way/elbow road
;
TYPE1=0x00020200,0x02000002,0x09020700,0,0

 

This occurs when we have a road with a 02 side to the East and North, like this:

 

Intersecting with a OneWayRoad which has a 02 side to the West and South, like this:

 

 

The resulting intersection:

 

 

 

 

There is a small section at the end of the file which reads:

 

[AllowedOverrides]
1=Road,Street
2=Avenue,Road
3=Avenue,Street
4=Avenue,GroundHighway
5=Highway,GroundHighway
6=OneWayRoad,Road

This controls what networks may be drawn on top of other networks.  If the RUL tile sides are the same for both networks, it allows you to replace a tile from the second network mentioned with a tile from the first network mentioned.  The only exception to this is that 04 bytes are ignored for streets and roads when drawing avenues over them.  I presume this is a hardcoded exception.

[the7trumpets 10]

RUL (INI Type) 0x10000002

 

 

This file has one large section, titled [RuleOverrides].  It works by saying that if two textures are aligned next to each other like this:

 

Tex1|Tex2

 

Then the resulting textures will be applied Tex1a|Tex2a

 

 

This is the format:

 

ID1,Rot1,Flip1,ID2,Rot2,Flip2=ID1a,Rot1a,Flip1a,ID2a,Rot2a,Flip2a

 

ID1=InstanceID of the left tile

ID2=InstanceID of the right tile

ID1a=InstanceID which replaces the left tile

ID2a=InstanceID which replaces the right tile

 

 

These particular rules are VERY powerful, since one line makes them work in all four cardinal orientations.  The left/right perspective is not set in stone to a cardinal direction.  Rather, the right side of Tile1 has to border the left side of Tile2.

 

 

Also, having zeros in the ID1a and ID2a spots causes a bad draw (red line).  This is to keep things from being constructed which don't look right, but still conform to all the other RULes.

 

Highway intersection rules (0x10000000) will have to wait.  This is just a warm-up compared to those

[Karybdis 34]

Woooo. thanks 7. Those two actually make sense now

Will be eagerly awaiting the specifications for the other two.

[the7trumpets 10]

----------------

On 11/7/2003 10:44:34 AM Karybdis wrote:Woooo. thanks 7. Those two actually make sense now

Will be eagerly awaiting the specifications for the other two.

----------------

Other "two" ???

I thought there was just one more (RUL 0x10000000).  What am I forgetting?

[Karybdis 34]

8a5993b9 Its the UK path remapping Network INI file.

I thought you were doing this but if you arent no biggie lol. I've just been staring at it for awhile

[Andy80586 1]

well... it took me like 5 hours to determine how the CheckType worked... and that was more than a week ago. You fixed one major issue in 0.19 that has held me to building cities almost flawlessly as my sims can just make left U-turns one tile away instead of seven...

Anyway, the CheckType directional bits (where it says 0x04020002 or something along that line) work the same way as you described earlier with 0x10000001. I meant to do more experiments with the constructions but ran out of time and I haven't really found any since.

I'm sure you know this already (lol) but it might save you some double-checking or triple-checking time. Cheers... and nice work everyone.

[DarkMatter 21]

I learned the Rich Text Format codes, and changed the normal text viewer to an RTF viewer in DatGen. This will let me perform syntax highlighting on files, like LUA and INI. I was thinking of highlighting RUL and SC4Path files too, and was wondering what you guys, 7th and Karybdis, think would be the best way (colors/bolding/italics) to highlight them so its easier to pick out certain parts. Let me know and I'll write parsers for them and upload a new version of DatGen.

[the7trumpets 10]

The one you've all been waiting for....

 

RUL (INI filetype) 0x10000000

 

 

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 next section I have no clue on.  It simply reads:

 

[intersection Tile Types]
DefineType  = 0x00000000,Road
DefineType  = 0x00000002,Highway

I suspect it's just the definition of road and highway tiles as the 00 and 02 network (which corresponds to the traffic exemplar order).  However, there are no entries for oneways, avenues, or ground highways.  This makes me think that this part of the file was only necissary or used prior to Rush Hour, and now this info is gathered somewhere else.

 

 

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 were probably only used prior to Rush Hour.  They refference the s3d file which includes the entire interchange and was used as the plopping piece prior to Rush Hour.  Now that tile is only used for the preview, and it is defined in the EffectsDirectory file, not in this RUL.  As you will see, the interchanges in Rush Hour are all pieced together by smaller tile sized s3d files and paths.

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 (^,&lt 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 = ^.....

 

As near as I can tell, the ConsLayout lines (construction layout) don't have too much effect.  Commenting them out, you can still build the interchange.  They might have something to do with the automata which builds the onramp (buldozers, etc), or they might define where the dust rises from constructing it.  I just haven't looked in to this too much since it doesn't have any bearing on the feasibility of constructing or using these interchanges.

 

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 and CheckType 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

 

I believe this controls what your querry tool shows when you are placing the interchange?  I haven't looked into it much.

Costs       = 400

 

This effects the cost in the game, displayed and actual cost.  I'm not sure how exactly, I haven't dug into it yet.

 

 

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

 

 

 

PHEW!!!

 

Okay, I must leave, like NOW.  Ask any questions you wish, but I probably won't be able to get back to you until after this weekend.  Good luck!

 

Also, I know there are a few line types that this example didn't cover.  I'll get to those later, sorry I don't have time now.

[GoaSkin 2]

Regarding the simulator exemplars, there are parameters describing which path ID construction vehicles for each kind of network use. There is the only hint to ID 5.

Construction vehicles of streets, roads, oneway-roads and avenues use ID 1; on railroads ID 3; on lightrail ID 6; on monorail ID 7 while the construction ID 5 is used by construction vehicles when building elevated highways or ground highways.

So path ID 5 is used by street vehicles too. Possibly, ID 5 means only vehicles which can go on highways while on paths with vehicle ID 1 can be used by any street vehicle.

[BBGun06 0]

    I found this thread by a search, but then looked back in the forum and discovered that it doesn't exist (insert creepy Twilight Zone music here)

this post is a test

    <edit> okay, It just appeared at the top of the list.  Anyway, it needed to be bumped, its important. </edit>

[moganite 4]

I have sent a message ti ski geek that this thread isn't sticked when it should be as it covers file types and the other filetyps are stickied. hopefully it will be stickied for now bump

I am planning a transposrt netwrok but it will be a while before i get my head round this and have it built

[Karybdis 34]

I suppose that's fine. The idea was originally that only threads containing incomplete information should be stickied since only threads like this should be in this forum

However since threads like this are NOT the only thing in this forum at the moment, heh... well...

If anything has been lost in the many site upgrades, it can be replaced.

Generally, if you check the other threads, copies of the file formats are all found on the simcity4 modding wikipedia over on Modthesims2... I think only the old one has formatted scripts though. When they moved to the new format, they lost formatting.

[RippleJet 36]

Reposting the 2nd post by Karybdis, which was truncated in the crash May 2008:

---

Originally posted by: Karybdis (((This is a copy of Teirusu's pathing formats post from the Sc4path thread. It was copied here do to the great amount of work and thought he/she has put into these formats )))

I would suggest to start out small. After looking through the most of the highway examplars myself things look... well... complex. Quite complex.

I think a good place to start is with the country roads in the exchange and make them functional. They would work much like streets, (No diagonals and such...) and as far as I can tell, would be the easiest to work with.

In fact, with what I know already, I think *COULD* add my own type of transportation already, however, I'm missing a few key points. And if I did know all the key points it would be a very simple form of transportation mind you.

So, in an effort to see if anyone knows more then I do at the moment (Which I'm sure there is.) I'm going to outline just what I do know at the moment.

First, the FSH files.

As most of you already know many (If not all) of the road FSH files are in Simcity_5.dat file. In fact at very beginning of it, starting with Instance 00000100

00000100 is the single road/street piece at the farthest zoom level. The other four instances 101, 102, 103, and 104 are for it's closer zoom levels. Now look at 110 - 114. They are the samething except with an alpha around the road, and so are 121 - 124 and 131 - 134.

Now go down to 00000200. It's a diagonal road end piece and everything up to 234 in Simcity_5.dat is also the same piece. The only difference is zoom level and how green the grass is... Ah-ha! Wealth levels!

So to recap, there are four types of the same piece. Default/concrete sidewalk, $ wealth, $$ wealth, and $$$ wealth. Furthermore, for each type there are 5 FSH files for each zoom level. That's 20 FSH files total for each piece of roadway!

So the format goes:

Default/concrete sidewalk

XXXXXX00 - farthest zoom

XXXXXX01 - 4 zoom

XXXXXX02 - 3 zoom

XXXXXX03 - 2 zoom

XXXXXX04 - closest zoom

$ wealth

XXXXXX10 - farthest zoom

XXXXXX11 - 4 zoom

XXXXXX12 - 3 zoom

XXXXXX13 - 2 zoom

XXXXXX14 - closest zoom

$$ wealth

XXXXXX20 - farthest zoom

XXXXXX21 - 4 zoom

XXXXXX22 - 3 zoom

XXXXXX23 - 2 zoom

XXXXXX24 - closest zoom

$$$ wealth

XXXXXX30 - farthest zoom

XXXXXX31 - 4 zoom

XXXXXX32 - 3 zoom

XXXXXX33 - 2 zoom

XXXXXX34 - closest zoom

Now for the RUL files. Precisely Number 113, it's the main road rules file.

Lets start at the top of the file:

1,00,00,00,00

3,0,0x00000100,0,0

What does it mean? Well I see the Instance ID I first talked about, that's a start

Now lets look at the 90-degree turn piece... 0,0x00000F00

Looking at the RUL file there are 4 mentions of it.

1,00,00,02,02

3,0,0x00000F00,0,0

1,00,02,02,00

3,0,0x00000F00,3,0

1,02,00,00,02

3,0,0x00000F00,1,0

1,02,02,00,00

3,0,0x00000F00,2,0

See a pattern yet? Here, let me help you...

1,00 (left),00 (top),02 (right),02 (bottom)

3,0,0x00000F00,0,0

Now rotate it 90 degrees clockwise.

1,02 (left),00 (top),00 (right),02 (bottom)

3,0,0x00000F00,*1*,0

Rotate it again.

1,02,02,00,00

3,0,0x00000F00,*2*,0

And a third time!

1,00,02,02,00

3,0,0x00000F00,*3*,0

And here's the straight road:

1,00,02,00,02

3,0,0x00004B00,0,0

1,02,00,02,00

3,0,0x00004B00,3,0<

[Meg 368]

Originally posted by: RippleJet

 Reposting the 2nd post by Karybdis, which was truncated in the crash May 2008quote>

I think I have this thread restored.   Let me know if there are any problems.