Difference between revisions of "SEEMAP.DAT"
m (Added see also) |
m (categorizing) |
||
| (6 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | This file is only used by tactical saves. | + | This file is only used by tactical saves and has a length of [[WGLOB.DAT|wglob[2] times wglob[3] times wglob[4]]] bytes. It details which areas of the map have been explored. |
| − | + | ||
| − | + | Each tile is detailed using three bits of an entire byte. The offset for any given byte is ''X Map Length'' * (''Map Level'' * ''Y Map Length'' + ''X'') + ''Y''. | |
| − | + | ||
| − | + | * Bit 1 (1): Has the west wall been seen? | |
| − | Each tile is detailed | + | * Bit 2 (2): Has the north wall been seen? |
| − | (1) | + | * Bit 3 (4): Has the ground/contents been seen? |
| − | + | ||
| − | north wall | + | When the respective SEEMAP offset for a given tile has bit 3 active you can see all elements (walls, contents, etc) on the screen, otherwise nothing will be visible at all. |
| − | + | ||
| − | example, a | + | For example, if a tile has a northern wall in it and a soldier standing further north looks at it, he'll see the wall (and bit 2 will flip to on) but the wall will still remain invisible on screen because he can't see past it into the rest of the tile. |
| − | is | + | |
| + | On the other hand, if he was standing to the south, he'd be able to see everything in the tile and so all three bits would flag and everything becomes visible. | ||
| + | |||
| + | That is to say, the first two bits are redundant. They're set and then ignored. | ||
| + | |||
| + | Not really sure why the programmers bothered with this, I guess they changed their mind on how the fog of war display would work at some point but didn't bother to simplify the backend to match. | ||
| + | |||
| + | |||
| + | ''Daiky 20/07/2011 : the first two bits actually are not redundant: they are used to show the west and north doors, these "type of walls" are the only exception. It make sense because otherwise you would never find a door in a west or north wall when it all would remain invisible.'' | ||
==See Also== | ==See Also== | ||
* [[Saved Game Files]] | * [[Saved Game Files]] | ||
| + | * [[Saved_Game_Files#Battlescape_Files|Battlescape Files]] | ||
| + | [[Category:Game Files]] | ||
| + | [[Category:Enemy Unknown/UFO Defense]] | ||
Latest revision as of 04:39, 23 July 2013
This file is only used by tactical saves and has a length of wglob[2] times wglob[3] times wglob[4] bytes. It details which areas of the map have been explored.
Each tile is detailed using three bits of an entire byte. The offset for any given byte is X Map Length * (Map Level * Y Map Length + X) + Y.
- Bit 1 (1): Has the west wall been seen?
- Bit 2 (2): Has the north wall been seen?
- Bit 3 (4): Has the ground/contents been seen?
When the respective SEEMAP offset for a given tile has bit 3 active you can see all elements (walls, contents, etc) on the screen, otherwise nothing will be visible at all.
For example, if a tile has a northern wall in it and a soldier standing further north looks at it, he'll see the wall (and bit 2 will flip to on) but the wall will still remain invisible on screen because he can't see past it into the rest of the tile.
On the other hand, if he was standing to the south, he'd be able to see everything in the tile and so all three bits would flag and everything becomes visible.
That is to say, the first two bits are redundant. They're set and then ignored.
Not really sure why the programmers bothered with this, I guess they changed their mind on how the fog of war display would work at some point but didn't bother to simplify the backend to match.
Daiky 20/07/2011 : the first two bits actually are not redundant: they are used to show the west and north doors, these "type of walls" are the only exception. It make sense because otherwise you would never find a door in a west or north wall when it all would remain invisible.