For basic slope information, refer to the following graphic: Each square is represented by one "code" byte (keep in mind that the data here is compressed). This determines if there is land or water in the square, and how it slopes. 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. Raising it once again and adding the pond sets bit 5. 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. 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. Adding a pond of water to a square sets bits 7 and 6. Raising terrain as in the previous example does appear to disturb this pattern, with squares of hex 4 becoming more abundant. Bit 7 apparently does not seem to indicate water coverage, although it could indicate that water was on this tile at one time. 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. Upon generating another city with a different name, but with all other parameters the same, the alternating pattern is also exactly the same. 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. This is bin 10000100, which is still the usual four squares high, although bit 7 is set despite the square not being under water.įurthermore, 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. At some point along a row of empty level squares, hex 0x0084 squares show up in groups of 22 bytes, or 11 squares. Raise that square by one, and it will become decimal 5, or binary 00101. 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. Something to do with water coverage, see below Bit 7 seems to be set if a square is covered by water. Taking the bit to an integer, multiply it by 100 then add 50 to get the altitude in feet. Let every two bytes represent a 16 bit integer, MSB first, such that bits 4-0 represent the altitude from 50 to 3150 feet. Following that, squares proceed to the south-west, or left in this case. In my testing, this seems to mean that the first square is at the northern-most corner of the screen. Each "square" is two bytes, with them being scanned in top to bottom, and from right to left in each row. Number of squares with a given tile type (i.e, XBLD from 00 to FF)Īltitude map, which is uncompressed. Here are the known values:ĭays elapsed since founding. These are represented as 1200 4-byte integers, noted here as #0 through #1199. )īit fields per square (eg : powered, has water)Ĭontains miscellaneous statistics. Zones (eg: residential, industrial, commercial. The lengths given are their compressed lengths. Unless noted, they are compressed using the above algorithm.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |