sc4e>CasperVg |
sc4e>JoeST |
| Line 1: |
Line 1: |
| − | {{NetSpecsNav}}
| + | <nowiki> • </nowiki> |
| − | {{Infobox TGI
| |
| − | | name = RUL Overrides
| |
| − | | format = [[RUL File]]
| |
| − | | type = 0x0A5BCF4B
| |
| − | | group = 0xAA5BCF57
| |
| − | | instance = 0x10000001
| |
| − | | comments = {{also|RUL_0x10000001}}}}
| |
| − | This is the file which dictates what happens when one network type is drawn over a different network (note the use of the word “different”; this is important). The network building engine calculates how network piece(s) are laid, as if no other networks are present. Then it looks to see if there are other network tiles of a different network in the way. If there are, it searches for a solution in this file and thus the intersecting piece(s)’ Rules are applied. If no Rules are found for the two different networks to intersect though, it results in an impossible network draw (red line). Format is as follows:
| |
| − |
| |
| − | | |
| − | ==Maxis' comments==
| |
| − | <font color="green" face="Courier New">
| |
| − | <nowiki>;</nowiki> format:<br>
| |
| − | <nowiki>;</nowiki> name=roadMajorTypesFlag,streetMajorTypesFlag,textureId,rotation,flip<br>
| |
| − | <nowiki>;</nowiki><br>
| |
| − | <nowiki>;</nowiki> name is really not used and is just for our reference. <br> | |
| − | <nowiki>;</nowiki> the flag byte order is SENW (I think?)<br>
| |
| − | <nowiki>;</nowiki><br>
| |
| − | </font>
| |
| − | | |
| − | ==Translation==
| |
| − | The file is separated into sections by titles in [brackets]. The title has the following format:
| |
| − |
| |
| − | <font color="green" face="Courier New">['''''Network1Network2'''''IntersectionSolutions]</font>
| |
| − |
| |
| − | Network1 and Network2 are the two networks which are being overlapped. Valid network names are: DirtRoad, Street, Road, OneWayRoad, Avenue, GroundHighway, Highway, Rail, LightRail [aka EI-train], & MonoRail [& some others]. There must be no spaces or punctuation of any kind in the title.
| |
| − | | |
| − | *A note about Loading order; the IntersectionSolutions header for each intersection section needs to have its network names in a proper order, otherwise any rules created under that section may not work at all. For example; [OneWayRoadGroundHighwayIntersectionSolutions] header is valid, but the [GroundHighwayOneWayRoadIntersectionSolutions] header is not. So if a set of rules doesn’t seem to be working (& no other rules exist in the section), then this may be something to look closer at.
| |
| − | | |
| − | 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:
| |
| − | | |
| − | <font color="green" face="Courier New">
| |
| − | <nowiki>;</nowiki>straight road, diagonal rail<br>
| |
| − | rot0flip0=0x02000200,0x00030100,0x03010200,0,0</font>
| |
| − | | |
| − | | |
| − | ==Format==
| |
| − | <font color="green" face="Courier New">name=<font color="black">0x</font><font color="blue">N1s</font><font color="orange">N1e</font>N1n<font color="purple">N1e</font>,<font color="black">0x</font><font color="blue">N2s</font><font color="orange">N2e</font>N2n<font color="purple">N2e</font>,texture/path/ExemplarID,Rotation,Flip</font>
| |
| − | | |
| − | name = doesn't matter, generally anything is valid.<br>
| |
| − | N1=Network1<br>
| |
| − | N2=Network2<br>
| |
| − | s,e,n,w = South, East, North, West<br>
| |
| − | Each S/E/N/W holds the RUL edge values for each network, which are:<br>
| |
| − | 00 - no connection<br>
| |
| − | 01 - left at 45degree angle<br>
| |
| − | 02 - straight<br>
| |
| − | 03 - right at 45degree angle<br>
| |
| − | 04 – median
| |
| − | Texture/PathID/ExemplarID = the InstanceID of the resulting transit tile put in this spot.
| |
| − | Where an Exemplar file is referenced, this Exemplar file subsequently references an S3D (or Model) file.<br>
| |
| − | '''Rotation = the rotation of the new transit tile 0-3'''<br>
| |
| − | '''Flip = the flip of the new transit tile 0-1'''<br>
| |
| − | | |
| − | *Note; Some in-game network intersections rely on having various IntersectionSolution rules in place in order for them to work. Some intersections/junctions may need two different sets of intersectionsolution rules, that effectively work together for an intersection to work. Some intersections/junctions rely on the RuleOverrides rul in order to work effectively. Some examples of this can be seen in these files themselves.
| |
| − | | |
| − | ==Allowed Overrides Section==
| |
| − | <font color="green" face="Courier New">[AllowedOverrides]<br>
| |
| − | 1=Road,Street<br>
| |
| − | 2=Avenue,Road<br>
| |
| − | 3=Avenue,Street<br>
| |
| − | 4=Avenue,GroundHighway<br>
| |
| − | 5=Highway,GroundHighway<br>
| |
| − | 6=OneWayRoad,Road<br></font>
| |
| − | | |
| − | This controls what networks may be drawn on top of other networks. Unfortunately, the rules here in this last section are also read in reverse by the exe. And because of the hierarchy that exists with the networks, a lower hierarchical network can’t replace a higher hierarchical network when actively dragging one network over another (in a parallel overlapping fashion). So having X=Street,Road won’t force Street to replace Road as the Street tool is dragged over a stretch of road. Rather, X=Street,Road will effectively be read as X=Road,Street at run-time & thus allow Road to replace Street if the Road tool is dragged over a section of Street.
| |
| − | {{NetSpecsNav}}
| |
| − | | |
| − | [[Category:Transit Modding]]
| |
