View source for Simcity 2000 Special Edition DAT IDX

{{GRAFPageHeader}}

= IDX + DAT = 

* ''' Format Type ''':    Archive <br> 
* ''' [http://en.wikipedia.org/wiki/Endianness Endian Order] ''': Little Endian <br> 


== Format Specifications == 

<code><b>
<font color="blue"> ''' // for each file ''' </font> <br> 
: uint32 {4}&nbsp;&nbsp; - ID <br> 
: uint32 {4}&nbsp;&nbsp; - File Offset <br> 
<br>
</b>
</code>

== MultiEx BMS Script == 

Not written yet<br><br>

== Notes and Comments == 

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

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


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

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

<span style="color:blue">// HEADER </span>
{| style="margin-left:1em"
|-
| char {4}
| - Chunk Type ID (<span style="color:purple">'FORM'</span>)
|-
| int32 {4}
| - Total count of bytes in file minus first 8 in the header
|-
| char {4}
| - File type (always <span style="color:purple">'SCDH'</span> for SimCity 2000)
|}

<p style="color:blue">// Begin segments/nested chunks. For each nested chunk:</p>
<span style="color:blue; margin-left:1em">// Segment header</span>
{| style="margin-left:2em"
|-
| char {4}
| - Segment type
|-
| int32 {4}
| - Byte count of the ''data'' in this segment (excluding this header)
|}

<p style="color:blue; margin-left:1em">// Segment data, begin sub-segment bytes (let <span style="color:red">x</span> = the byte's value)</p>
:: byte {1}
:: <span style="color:blue">// If 1 <= <span style="color:red">x</span> <= 127:</span>
::: byte {<span style="color:red">x</span>} - Raw, uncompressed data
:: <span style="color:blue">// If 129 <= <span style="color:red">x</span> <= 255:</span>
::: byte {1} - The following byte repeats <span style="color:red">x</span>-127 times.

: <span style="color:blue">// Repeat for the rest of this segment's data length.</span>

</b></code>

== 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 [http://djm.cc/simcity-2000-info.txt 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.

{| class="wikitable"
! Seg. type
! Length (bytes)
|-
|CNAM
|32 (Uncompressed)
|-
|MISC
|4800
|-
|ALTM
|32768 (Uncompressed)
|-
|XTER
|16384
|-
|XBLD
|16384
|-
|XZON
|16384
|-
|XUND
|16384
|-
|XTXT
|16384
|-
|XLAB
|6400
|-
|XMIC
|1200
|-
|XTHG
|480
|-
|XBIT
|16384
|-
|XTRF
|4096
|-
|XPLT
|4096
|-
|XVAL
|4096
|-
|XCRM
|4096
|-
|XPLC
|1024
|-
|XFIR
|1024
|-
|XPOP
|1024
|-
|XROG
|1024
|-
|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:
{| class="wikitable"
!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 [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
|-
|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, <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.

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.

=== XTER ===
This determines if there is land or water in the square, and how it slopes. Each square is represented by one "code" byte. To describe how the terrain slopes, we'll use these four letters in a square:
{|
|-
|a
|b
|-
|c
|d
|}
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]]