Simcity 2000 Special Edition DAT IDX: Difference between revisions

From XentaxWiki
Jump to navigation Jump to search
imported>Tgp1994
m (→‎SC2: Grammar. Started writing up XTER description. I need to take a break. Someone else take over, please...)
imported>Ikskoks
 
(30 intermediate revisions by 3 users not shown)
Line 1: Line 1:
* [[GRAFs|Return to the list of games]]
{{GRAFPageHeader}}


Choose archive extension:
= IDX + DAT =  
 
== IDX + DAT ==  


* ''' Format Type ''':    Archive <br>  
* ''' Format Type ''':    Archive <br>  
Line 9: Line 7:




=== Format Specifications ===  
== Format Specifications ==  


<code><b>
<code><b>
Line 19: Line 17:
</code>
</code>


=== MultiEx BMS Script ===  
== MultiEx BMS Script ==  


Not written yet<br><br>
Not written yet<br><br>


=== Notes and Comments ===  
== Notes and Comments ==  


* The *.idx file contains the directory, the *.dat file contains the file data
* The *.idx file contains the directory, the *.dat file contains the file data
<br><br>
<br><br>
=== Compatible Programs ===  
== Compatible Programs ==  


* [[Game Extractor|Game Extractor]]<br>
* [[Game Extractor|Game Extractor]]<br>




== SC2 ==
= SC2 =
* '''Format Type:''' [https://en.wikipedia.org/wiki/Interchange_File_Format Interchange File Format (IFF)]
* '''Format Type:''' [https://en.wikipedia.org/wiki/Interchange_File_Format Interchange File Format (IFF)]
* '''[http://en.wikipedia.org/wiki/Endianness Endian Order]''': Little Endian
* '''[http://en.wikipedia.org/wiki/Endianness Endian Order]''': Big Endian


=== Format Specifications ===
== Format Specifications ==
<code><b>
<code><b>


Line 74: Line 72:
</b></code>
</b></code>


=== Notes and Comments ===
== Notes and Comments ==
* This is the file format in which cities are stored. See the IFF page on Wikipedia (linked above) for more information on the format, although it is essentially a generic container file format.
* This is the file format in which cities are stored. See the IFF page on Wikipedia (linked above) for more information on the format, although it is essentially a generic container file format.
* All of this information is thanks to the research done by David Moews, with a document [http://djm.cc/simcity-2000-info.txt here].
* All of this information is thanks to the research done by David Moews, with a document [http://djm.cc/simcity-2000-info.txt here].
Line 84: Line 82:
** Therefor, the maximum size of an uncompressed ''sub-''chunk can be 127 bytes.
** Therefor, the maximum size of an uncompressed ''sub-''chunk can be 127 bytes.


=== Segment Types ===
== Segment Types ==
* The following table is a list of segment types in the order they typically appear. Unless noted, they are compressed using the above algorithm. The lengths given are their '''uncompressed''' lengths.
* The following table is a list of segment types in the order they typically appear. Unless noted, they are compressed using the above algorithm. The lengths given are their '''compressed''' lengths.


{| class="wikitable"
{| class="wikitable"
! Seg. type
! Seg. type
! Length (bytes)
! Length (bytes)
! Description
|-
|-
|CNAM
|CNAM
|32 (Uncompressed)
|32 (Uncompressed)
|City name
|-
|-
|MISC
|MISC
|4800
|4800
|
|-
|-
|ALTM
|ALTM
|32768 (Uncompressed)
|32768 (Uncompressed)
|Altitude map
|-
|-
|XTER
|XTER
|16384
|16384
|Terrain
|-
|-
|XBLD
|XBLD
|16384
|16384
|Building
|-
|-
|XZON
|XZON
|16384
|16384
|Zones (eg: residential, industrial, commercial, ...)
|-
|-
|XUND
|XUND
|16384
|16384
|Underground (eg : pipes)
|-
|-
|XTXT
|XTXT
|16384
|16384
|User-defined signs
|-
|-
|XLAB
|XLAB
|6400
|6400
|Labels (eg: mayor's name)
|-
|-
|XMIC
|XMIC
|1200
|1200
|
|-
|-
|XTHG
|XTHG
|480
|480
|
|-
|-
|XBIT
|XBIT
|16384
|16384
|Bit fields per square (eg : powered, has water)
|-
|-
|XTRF
|XTRF
|4096
|4096
|Traffic
|-
|-
|XPLT
|XPLT
|4096
|4096
|Pollution
|-
|-
|XVAL
|XVAL
|4096
|4096
|
|-
|-
|XCRM
|XCRM
|4096
|4096
|Crime rate
|-
|-
|XPLC
|XPLC
|1024
|1024
|Police power
|-
|-
|XFIR
|XFIR
|1024
|1024
|Fire power
|-
|-
|XPOP
|XPOP
|1024
|1024
|Population
|-
|-
|XROG
|XROG
|1024
|1024
|Rate of grow
|-
|-
|XGRP
|XGRP
|3328
|3328
|
|}
|}


'''Additional notes on segment types:'''
== Additional notes on segment types: ==
=== MISC ===
Contains miscellaneous statistics. These are represented as 1200 4-byte integers, noted here as #0 through #1199. The values are stored big-endian. Here are the known values:
{| class="wikitable"
{| class="wikitable"
!ID
!ID
!style="text-align:left;"| Comments
!Description
|-
|2
|Rotation (??)
|-
|3
|Founding year of the city
|-
|4
|Days elapsed since founding. Every month is 25 days.
|-
|5
|Money
|-
|20
|SimNation population (in 1,000's)
|-
|124-379
|Number of squares with a given tile type (i.e, XBLD; from 00 to FF)
|-
|439
|Neighboring city 1 population
|-
|443
|Neighboring city 2 population
|-
|447
|Neighboring city 3 population
|-
|451
|Neighboring city 4 population
|}
 
=== ALTM ===
Altitude map, which is uncompressed. Each "square" is two bytes, with them being scanned in top to bottom, and from right to left in each row. In my testing, this seems to mean that the first square is at the northern-most corner of the screen. Following that, squares proceed to the south-west, or left in this case. Let every two bytes represent a [http://wiki.xentax.com/index.php?title=DGTEFF#-bit_.282-byte.29_numbers 16 bit integer], MSB first, such that bits 4-0 represent the altitude from 50 to 3150 feet. Taking the bit to an integer, multiply it by 100 then add 50 to get the altitude in feet. Bits 6-5 are unknown. Bit 7 seems to be set if a square is covered by water. Bits 15-8 are unknown.
 
{| class="wikitable"
!Bit(s)
!Purpose
|-
|15-8
|Unknown
|-
|-
|CNAM
|7-5
|The name of the city, uncompressed, and also optional it seems. When it's present, the length byte is a number 0 to 31, with that many bytes of city name. It's padded to 32 bytes with zeroes.
|Something to do with water coverage, see below
|-
|-
|ALTM
|4-0
|<p>Altitude map, which is uncompressed. Each "square" is two bytes, with them being scanned in top to bottom, and from right to left in each row. In my testing, this seems to mean that the first square is at the northern-most corner of the screen. Following that, squares proceed to the south-west, or left in this case. Let every two bytes represent a [http://wiki.xentax.com/index.php?title=DGTEFF#-bit_.282-byte.29_numbers 16 bit integer], MSB first, such that bits 4-0 represent the altitude from 50 to 3150 feet. Bits 6-5 are unknown. Bit 7 seems to be set if a square is covered by water. Bits 15-8 are unknown. '''Notes from my own testing (in SCURK 1.0):''' By default, it seems that the default altitude of a square (starting in SCURK) is 4 "units" high, as is represented by a binary 00100. Raise that square by one, and it will become decimal 5, or binary 00101. At some point along a row of empty level squares, <code>hex 0x0084</code> squares show up in groups of 22 bytes, or 11 squares. This is <code>bin 10000100</code>, which is still the usual four squares high, although bit 7 is set despite the square not being under water.</p>
|Altitude, see above
|}
 
'''Notes from my own testing (in SCURK 1.0):''' It seems that the default altitude of a square (starting in SCURK) is 4 "units" high, represented by a binary 00100 which equals 450 feet. Raise that square by one, and it will become decimal 5, or binary 00101. At some point along a row of empty level squares, <code>hex 0x0084</code> squares show up in groups of 22 bytes, or 11 squares. This is <code>bin 10000100</code>, which is still the usual four squares high, although bit 7 is set despite the square not being under water.


<p>Furthermore, in a totally unmodified city (with only the name/year/budget having been set), the first eight bytes of ALTM data (or four squares) have this <code>hex 0x0084</code> pattern, followed by 20 bytes (10 squares) with the <code>hex 0x0004</code> pattern. Eight more bytes follow that with <code>hex 0x0084</code>, and the alternation continues although the number of squares in each set does not seem to correlate with anything. Upon generating another city with a different name, but with all other parameters the same, the alternating pattern is also exactly the same. Starting with hex 84 then hex 4 and repeating, the number of squares is: 4, 10, 4, 13, 3, 3, 31, 25, 8, 27, 3, 11, ... Bit 7 apparently does not seem to indicate water coverage, although it ''could'' indicate that water was on this tile at one time. Raising terrain as in the previous example does appear to disturb this pattern, with squares of hex 4 becoming more abundant. Adding a pond of water to a square sets bits 7 '''and''' 6. Interestingly, bulldozing the pond, or changing the elevation of the square (which visually removes the pond) does not ''unset'' those bits, despite the pond apparently being gone. '''Further testing conducted in SC2000 Win 95 version:''' Lowering the tile but adding the pond back leaves only bit 7 set, unsetting bits 6 and 5 if they were set. Raising it once again and adding the pond sets bit 5.</p>
Furthermore, in a totally unmodified city (with only the name/year/budget having been set), the first eight bytes of ALTM data (or four squares) have this <code>hex 0x0084</code> pattern, followed by 20 bytes (10 squares) with the <code>hex 0x0004</code> pattern. Eight more bytes follow that with <code>hex 0x0084</code>, and the alternation continues although the number of squares in each set does not seem to correlate with anything. Upon generating another city with a different name, but with all other parameters the same, the alternating pattern is also exactly the same. Starting with hex 84 then hex 4 and repeating, the number of squares is: 4, 10, 4, 13, 3, 3, 31, 25, 8, 27, 3, 11, ... Bit 7 apparently does not seem to indicate water coverage, although it ''could'' indicate that water was on this tile at one time. Raising terrain as in the previous example does appear to disturb this pattern, with squares of hex 4 becoming more abundant. Adding a pond of water to a square sets bits 7 '''and''' 6. Interestingly, bulldozing the pond, or changing the elevation of the square (which visually removes the pond) does not ''unset'' those bits, despite the pond apparently being gone. '''Further testing conducted in SC2000 Win 95 version:''' Lowering the tile but adding the pond back leaves only bit 7 set, unsetting bits 6 and 5 if they were set. Raising it once again and adding the pond sets bit 5.


Ultimately, it seems clear that bits 7 thru 5 have something to do with water. What exactly that is remains unclear; perhaps it was supposed to be used in a feature that was never implemented.
Ultimately, it seems clear that bits 7 thru 5 have something to do with water. What exactly that is remains unclear; perhaps it was supposed to be used in a feature that was never implemented.
=== XTER ===
This determines if there is land or water in the square, and how it slopes. Each square is represented by one "code" byte (keep in mind that the data here is compressed). For basic slope information, refer to the following graphic:
[[File:Xtercodes.png]]
Note that bytes <tt>'''0E'''</tt> and <tt>'''0F'''</tt> are considered unknown/unused and may produce unexpected results.
{| class="wikitable"
! Byte(s)
! Result
|-
|00-0D
|Dry land, possibility of an incline.
|-
|0E-0F
|Unused?
|-
|10-1D
|Slopes like the 0''x'' set, although the tile is submerged in water.
|-
|1E-1F
|Unused?
|-
|20-2D
|Partially submerged
|-
|-
|XTER
|2E-2F
|One "code byte" per square. This determines if there is land or water in the square, and how it slopes. To describe how the terrain slopes, we'll use these four letters in a square:
|Unused?
{|
|-
|30-3D
|Not submerged, but may have water on top via placement by the water tool.
|-
|3E
|Waterfall
|-
|3F
|Unused?
|-
|40-41
|Surf/canals, running either up/down or left/right.
|-
|42-45
|Surf/bays, one opening which is surrounded by land.
|-
|46-54
|Unused/gaping hole in the ground
|-
|55-FF
|Unused?
|}
 
[[File:Xterspecial.png]]
 
=== XBLD ===
Like XTER; each square is assigned one "code byte". This section is also compressed. In general, simply changing a value will result in an inconsistent simulation: buildings here are subject to the simulation and may not be permanent, or may have unintended consequences on other parts of the simulation.
 
When dealing with generic network-like objects (such as power lines, roads, and rails), the below image gives you an idea of what the intersection looks like. 0 means the code has zero offset in the category (e.g for powerlines 0E-1C, offset zero equals 0E).
 
[[File:XBLDCodes.png]]
 
'''Non-buildings:'''
{| class="wikitable"
! Byte(s)
! Result
|-
|00
|Clear/empty
|-
|01-04
|Rubble
|-
|05
|Radioactive waste
|-
|06-0C
|Trees, in increasing density
|-
|0D
|Small park (set XZON for 1x1 building)
|-
|0E-1C
|Power lines (refer to the network diagram above)
|-
|1D-2B
|Roads (refer to the network diagram above)
|-
|2C-3A
|Rails (refer to the network diagram above)
|-
|3B-3E
|Complements the above rail pieces by providing ramps prior to a slope (order is top, right, bottom, then left)
|-
|3F-42
|Tunnel entrances (north, east, south, west)
|-
|43-44
|Road/powerline crossings (road traveling east/west or north/south, vice versa for the powerline)
|-
|45-46
|Road/rail crossings, same pattern as above
|-
|47-48
|Rail/powerline crossings, same pattern as above
|-
|49-4A
|Highway east/west or north/south, set XZON for 1x1 building
|-
|4B-4C
|Road/highway crossings, set XZON for 1x1 building
|-
|4D-4E
|Rail/highway crossings, set XZON for 1x1 building
|-
|4F-50
|Powerline/highway crossings, set XZON for 1x1 building
|-
|51-55
|Suspension bridge pieces
|-
|56-59
|Other road bridge pieces
|-
|5A-5B
|Rail bridge pieces
|-
|5C
|Elevated power lines
|-
|5D-60
|Highway on-ramps
|-
|61-69
|Highways (various directions, sloping, 2x2 size; set XZON for 2x2 building)
|-
|6A-6B
|Highway bridges (reinforced) Set XZON for 2x2 tile
|-
|6C-6F
|Sub/rail connections (set XZON for 1x1 building) in order: rail at east, west, north, south
|}
 
'''Buildings:'''
{| class="wikitable"
! Byte(s)
! Result
|-
|70-7B
|Residential 1x1, lower to upper class, 4/class
|-
|7C-83
|Commercial 1x1; gas station, B&B, store, gas station, small office, office, warehouse, toy store
|-
|84-87
|Industrial 1x1; warehouse, chem. tank, warehouse, substation
|-
|88-89
|1x1 Construction
|-
|8A-8B
|1x1 Abandoned
|-
|8C-93
|Residential 2x2; cheap apartments, 2 apartments, 2 nice apartments, 3 condominiums
|-
|94-9D
|Commercial 2x2; Mall, store, office, resort, office, retail, 4 office buildings
|-
|9E-A5
|Industrial 2x2; warehouse, chem. processing, 6 factories
|-
|A6-A9
|Construction
|-
|AA-AD
|Abandoned building
|-
|AE-B1
|Residential 3x3; 2 apartments, 2 condominium
|-
|B2-BB
|Commercial 3x3; office park, office tower, mall, theater, drive-in, 2 office towers, parking lot, office building, headquarters
|-
|BC-C1
|Industrial 3x3; chem. processing, factory, thing, factory, warehouse, warehouse
|-
|C2-C3
|Construction
|-
|C4-C5
|Abandoned
|-
|C6-C8
|Power plants 1x1; 2 hydro, 1 wind
|-
|C9-CF
|Power plants 4x4; nat. gas, oil, nuclear, solar, microwave, fusion, coal
|-
|D0-D8
|City services; city hall, hospital, police, fire, museum, big park, school, stadium, prison, college, zoo, statue
|-
|DC
|Water pump
|-
|DD-DE
|Runway
|-
|DF
|Pier
|-
|E0
|Crane
|-
|E1-E2
|Control tower
|-
|E3
|Warehouse (seaport)
|-
|E4-E5
|Building (airport)
|-
|E6
|Tarmac
|-
|E7
|F-15b
|-
|E8
|Hangar
|-
|E9
|Subway station
|-
|EA
|Radar
|-
|EB
|Water tower
|-
|EC
|Bus station
|-
|ED
|Rail station
|-
|EE-EF
|Parking lot
|-
|F0
|Loading bay
|-
|F1
|Top secret
|-
|F2
|Cargo yard
|-
|F3
|Mayor' house
|-
|F4
|Water treatment plant
|-
|F5
|Library
|-
|F6
|Hangar
|-
|F7
|Church
|-
|F8
|Marina
|-
|F9
|Missile silo
|-
|FA
|Desalination plant
|-
|-
|a
|FB-FE
|b
|Arcologies (plymouth, forest, draco, launch)
|-
|-
|c
|FF
|d
|Braun Llama-dome
|}
|}
a, b, c, and d are the relative heights of the corners of the square. Codes are given in hex:
 
=== Other ===
{| class="wikitable"
!ID
!style="text-align:left;"| Comments
|-
|CNAM
|The name of the city, uncompressed, and also optional it seems. When it's present, the length byte is a number 0 to 31, with that many bytes of city name. It's padded to 32 bytes with zeroes.
|}
|}
{{GRAFPageFooter}}
[[Category:Complete WIP|Simcity 2000 Special Edition]]
[[Category:BMS None|Simcity 2000 Special Edition]]
[[Category:CE Compressed|Simcity 2000 Special Edition]]
[[Category:Big-endian formats|Simcity 2000 Special Edition]]
[[Category:PC formats|Simcity 2000 Special Edition]]
[[Category:Platform PC|Simcity 2000 Special Edition]]
[[Category:File Format]]

Latest revision as of 12:02, 21 January 2021

Back to index | Edit this page

IDX + DAT


Format Specifications

// for each file

uint32 {4}   - ID
uint32 {4}   - File Offset


MultiEx BMS Script

Not written yet

Notes and Comments

  • The *.idx file contains the directory, the *.dat file contains the file data



Compatible Programs


SC2

Format Specifications

// HEADER

char {4} - Chunk Type ID ('FORM')
int32 {4} - Total count of bytes in file minus first 8 in the header
char {4} - File type (always 'SCDH' for SimCity 2000)

// Begin segments/nested chunks. For each nested chunk:

// Segment header

char {4} - Segment type
int32 {4} - Byte count of the data in this segment (excluding this header)

// Segment data, begin sub-segment bytes (let x = the byte's value)

byte {1}
// If 1 <= x <= 127:
byte {x} - Raw, uncompressed data
// If 129 <= x <= 255:
byte {1} - The following byte repeats x-127 times.
// Repeat for the rest of this segment's data length.

Notes and Comments

  • This is the file format in which cities are stored. See the IFF page on Wikipedia (linked above) for more information on the format, although it is essentially a generic container file format.
  • All of this information is thanks to the research done by David Moews, with a document here.
  • After the header, the rest of the file is made up of chunks containing an 8 byte header followed by its data. Almost all segment data is compressed using a run-length algorithm. Specifically:
    • The compressed data is a series of two kinds of chunks
    • In the first kind, the first byte equates to an integer 1 to 127. This means the byte is counting how many data bytes follow.
    • In the second kind, the first byte equates to an integer 129 to 255. If you subtract 127 from it, you end up with a count of how many times the following byte is repeated.
    • Chunks with a first byte of 0 or 128 never seem to occur.
    • Therefor, the maximum size of an uncompressed sub-chunk can be 127 bytes.

Segment Types

  • The following table is a list of segment types in the order they typically appear. Unless noted, they are compressed using the above algorithm. The lengths given are their compressed lengths.
Seg. type Length (bytes) Description
CNAM 32 (Uncompressed) City name
MISC 4800
ALTM 32768 (Uncompressed) Altitude map
XTER 16384 Terrain
XBLD 16384 Building
XZON 16384 Zones (eg: residential, industrial, commercial, ...)
XUND 16384 Underground (eg : pipes)
XTXT 16384 User-defined signs
XLAB 6400 Labels (eg: mayor's name)
XMIC 1200
XTHG 480
XBIT 16384 Bit fields per square (eg : powered, has water)
XTRF 4096 Traffic
XPLT 4096 Pollution
XVAL 4096
XCRM 4096 Crime rate
XPLC 1024 Police power
XFIR 1024 Fire power
XPOP 1024 Population
XROG 1024 Rate of grow
XGRP 3328

Additional notes on segment types:

MISC

Contains miscellaneous statistics. These are represented as 1200 4-byte integers, noted here as #0 through #1199. The values are stored big-endian. Here are the known values:

ID Description
2 Rotation (??)
3 Founding year of the city
4 Days elapsed since founding. Every month is 25 days.
5 Money
20 SimNation population (in 1,000's)
124-379 Number of squares with a given tile type (i.e, XBLD; from 00 to FF)
439 Neighboring city 1 population
443 Neighboring city 2 population
447 Neighboring city 3 population
451 Neighboring city 4 population

ALTM

Altitude map, which is uncompressed. Each "square" is two bytes, with them being scanned in top to bottom, and from right to left in each row. In my testing, this seems to mean that the first square is at the northern-most corner of the screen. Following that, squares proceed to the south-west, or left in this case. Let every two bytes represent a 16 bit integer, MSB first, such that bits 4-0 represent the altitude from 50 to 3150 feet. Taking the bit to an integer, multiply it by 100 then add 50 to get the altitude in feet. Bits 6-5 are unknown. Bit 7 seems to be set if a square is covered by water. Bits 15-8 are unknown.

Bit(s) Purpose
15-8 Unknown
7-5 Something to do with water coverage, see below
4-0 Altitude, see above

Notes from my own testing (in SCURK 1.0): It seems that the default altitude of a square (starting in SCURK) is 4 "units" high, represented by a binary 00100 which equals 450 feet. Raise that square by one, and it will become decimal 5, or binary 00101. At some point along a row of empty level squares, hex 0x0084 squares show up in groups of 22 bytes, or 11 squares. This is bin 10000100, which is still the usual four squares high, although bit 7 is set despite the square not being under water.

Furthermore, in a totally unmodified city (with only the name/year/budget having been set), the first eight bytes of ALTM data (or four squares) have this hex 0x0084 pattern, followed by 20 bytes (10 squares) with the hex 0x0004 pattern. Eight more bytes follow that with hex 0x0084, and the alternation continues although the number of squares in each set does not seem to correlate with anything. Upon generating another city with a different name, but with all other parameters the same, the alternating pattern is also exactly the same. Starting with hex 84 then hex 4 and repeating, the number of squares is: 4, 10, 4, 13, 3, 3, 31, 25, 8, 27, 3, 11, ... Bit 7 apparently does not seem to indicate water coverage, although it could indicate that water was on this tile at one time. Raising terrain as in the previous example does appear to disturb this pattern, with squares of hex 4 becoming more abundant. Adding a pond of water to a square sets bits 7 and 6. Interestingly, bulldozing the pond, or changing the elevation of the square (which visually removes the pond) does not unset those bits, despite the pond apparently being gone. Further testing conducted in SC2000 Win 95 version: Lowering the tile but adding the pond back leaves only bit 7 set, unsetting bits 6 and 5 if they were set. Raising it once again and adding the pond sets bit 5.

Ultimately, it seems clear that bits 7 thru 5 have something to do with water. What exactly that is remains unclear; perhaps it was supposed to be used in a feature that was never implemented.

XTER

This determines if there is land or water in the square, and how it slopes. Each square is represented by one "code" byte (keep in mind that the data here is compressed). For basic slope information, refer to the following graphic:

Note that bytes 0E and 0F are considered unknown/unused and may produce unexpected results.

Byte(s) Result
00-0D Dry land, possibility of an incline.
0E-0F Unused?
10-1D Slopes like the 0x set, although the tile is submerged in water.
1E-1F Unused?
20-2D Partially submerged
2E-2F Unused?
30-3D Not submerged, but may have water on top via placement by the water tool.
3E Waterfall
3F Unused?
40-41 Surf/canals, running either up/down or left/right.
42-45 Surf/bays, one opening which is surrounded by land.
46-54 Unused/gaping hole in the ground
55-FF Unused?

XBLD

Like XTER; each square is assigned one "code byte". This section is also compressed. In general, simply changing a value will result in an inconsistent simulation: buildings here are subject to the simulation and may not be permanent, or may have unintended consequences on other parts of the simulation.

When dealing with generic network-like objects (such as power lines, roads, and rails), the below image gives you an idea of what the intersection looks like. 0 means the code has zero offset in the category (e.g for powerlines 0E-1C, offset zero equals 0E).

Non-buildings:

Byte(s) Result
00 Clear/empty
01-04 Rubble
05 Radioactive waste
06-0C Trees, in increasing density
0D Small park (set XZON for 1x1 building)
0E-1C Power lines (refer to the network diagram above)
1D-2B Roads (refer to the network diagram above)
2C-3A Rails (refer to the network diagram above)
3B-3E Complements the above rail pieces by providing ramps prior to a slope (order is top, right, bottom, then left)
3F-42 Tunnel entrances (north, east, south, west)
43-44 Road/powerline crossings (road traveling east/west or north/south, vice versa for the powerline)
45-46 Road/rail crossings, same pattern as above
47-48 Rail/powerline crossings, same pattern as above
49-4A Highway east/west or north/south, set XZON for 1x1 building
4B-4C Road/highway crossings, set XZON for 1x1 building
4D-4E Rail/highway crossings, set XZON for 1x1 building
4F-50 Powerline/highway crossings, set XZON for 1x1 building
51-55 Suspension bridge pieces
56-59 Other road bridge pieces
5A-5B Rail bridge pieces
5C Elevated power lines
5D-60 Highway on-ramps
61-69 Highways (various directions, sloping, 2x2 size; set XZON for 2x2 building)
6A-6B Highway bridges (reinforced) Set XZON for 2x2 tile
6C-6F Sub/rail connections (set XZON for 1x1 building) in order: rail at east, west, north, south

Buildings:

Byte(s) Result
70-7B Residential 1x1, lower to upper class, 4/class
7C-83 Commercial 1x1; gas station, B&B, store, gas station, small office, office, warehouse, toy store
84-87 Industrial 1x1; warehouse, chem. tank, warehouse, substation
88-89 1x1 Construction
8A-8B 1x1 Abandoned
8C-93 Residential 2x2; cheap apartments, 2 apartments, 2 nice apartments, 3 condominiums
94-9D Commercial 2x2; Mall, store, office, resort, office, retail, 4 office buildings
9E-A5 Industrial 2x2; warehouse, chem. processing, 6 factories
A6-A9 Construction
AA-AD Abandoned building
AE-B1 Residential 3x3; 2 apartments, 2 condominium
B2-BB Commercial 3x3; office park, office tower, mall, theater, drive-in, 2 office towers, parking lot, office building, headquarters
BC-C1 Industrial 3x3; chem. processing, factory, thing, factory, warehouse, warehouse
C2-C3 Construction
C4-C5 Abandoned
C6-C8 Power plants 1x1; 2 hydro, 1 wind
C9-CF Power plants 4x4; nat. gas, oil, nuclear, solar, microwave, fusion, coal
D0-D8 City services; city hall, hospital, police, fire, museum, big park, school, stadium, prison, college, zoo, statue
DC Water pump
DD-DE Runway
DF Pier
E0 Crane
E1-E2 Control tower
E3 Warehouse (seaport)
E4-E5 Building (airport)
E6 Tarmac
E7 F-15b
E8 Hangar
E9 Subway station
EA Radar
EB Water tower
EC Bus station
ED Rail station
EE-EF Parking lot
F0 Loading bay
F1 Top secret
F2 Cargo yard
F3 Mayor' house
F4 Water treatment plant
F5 Library
F6 Hangar
F7 Church
F8 Marina
F9 Missile silo
FA Desalination plant
FB-FE Arcologies (plymouth, forest, draco, launch)
FF Braun Llama-dome

Other

ID Comments
CNAM The name of the city, uncompressed, and also optional it seems. When it's present, the length byte is a number 0 to 31, with that many bytes of city name. It's padded to 32 bytes with zeroes.

Navigation

Jump to a listing by...
All Formats - Common Formats - Standard Formats - Malformed Pages
Platforms
Microsoft:
Xbox
Xbox 360 		Nintendo:
GameCube
DS 		Desktop:
PC 		Sega:
Dreamcast 		Sony:
PlayStation
PlayStation 2
PlayStation 3
PlayStation Portable
Type
Animation - Archive - Audio - Image - Mesh - Miscellaneous - Model - Video
Endianness
Little-endian - Big-endian
BMS Scripts
Pages Without a BMS Script

All Pages with Scripts:
Recently Added Scripts

Program Support
No Known Support

MultiEx Commander - Game Extractor

Format Specification Completion
Work in Progress - Almost Done - Completed
Compression and Encryption
No Compression or Encryption Used - Unknown Compression or Encryption Used

One or Both Used:
Compression Used - Both Compression and Encryption Used

Retrieved from "https://wiki.xentax.spektr.name:443/index.php?title=Simcity_2000_Special_Edition_DAT_IDX&oldid=50305"