PostPosted: 17 Mar 2009, 15:58
As long is there IS progress, it's okay, I guess.
Talk about Knights and Merchants!
http://www.knightsandmerchants.net/forum/
http://www.knightsandmerchants.net/forum/viewtopic.php?t=220
<?xml version="1.0" encoding="utf-8"?>
<missionindex>
 <map compact="true">map01.map</map>
 <script type="dat">smission6.dat</script>
</missionindex>[/quote]
map and script may be in any order but both must appear.
compact="false" means the map is in the regular (TPR) format, "true" means it's in the new format. If you write "true" but that map is [i]not[/i] in the compact format it Will crash. So don't. The other way round is OK, but slower, so avoid if possible.
You can turn maps into the compact format like this: "tke convert source.map result.map compact" (if you don't know what this means just skip it)
The script type must match the actual type if it is specified, if it's omitted the file extension of the script file must match its type (so ".xml" for xml missions and ".dat" for the regular missions)
* Compact Map Format
This format takes less space for the same number of tiles and is easier to extend.
[code]int32: 0Â - maps never have a width of 0 so this is a safe initial identifier
int32: 0x31454B54Â (ascii TKE1, little-endian, format identifier)
int32: relative offset to map data
..
any number of optional blocks
possible blocks:
  RSA:  if this block is present, tile data is RSA encrypted
  if the timestamp is later than the current time or older than 2 years,
   the map will be saved in decrypted state, without the RSA block.
  struct
  {
   ascii: ".RSA" = 0x4153522E
   int64: timestamp
  }
..
possibly empty space
..
<offset>
unsigned int16: width
unsigned int16: height
  for each tile: (left to right, top to bottom)
struct tile
{
  byte: type
  byte: height
  byte: object
  struct
  {
   2bits: rotation
   bit: walkable
   bit: buildable
   4bits: reserved
  }
}
file should end here[/quote]
RSA support is currently at best experimental - but you don't need this anyway
Reserved bits should be zero and the "empty space" between the end of the optional blocks and the beginning of the tile data should indeed be empty. Failure to comply does not result in any errors yet but that may change - if you need to store anything extra in a map talk with me and I may add an "optional block" type (maybe for creation data, author data, website link, whatever.. ask first).
* Additions to the normal mission format
If they're used in a .mis or .cam (see below) file, the !SET_MAP command is ignored.
!CLEAR_ALL - clears the entire map
!SET_COLOR RED/BLUE/YELLOW - more colors will be added, sets the color for the current player, this is like remap and mapcolor combined and with pre-defined colors.
!ADD_WARE_TO_FIFTH - in case you need more warehouses (second third and fourth naturally also work)
(more will follow)
* xml mission scripts.
The specification is not finished yet, but it's slowly getting there. I'll keep you posted.
* single-file campaign files.
This specification was thought to be finished but contained serious flaws. There are, however, a few things that will stay.
Like the missions they are zip files, but renamed to .cam.
Features will include but are not limited to: changing the background of the briefing screen, the briefing audio, the briefing text (it will have to be translatable of course, which is what I'm fighting with now.), specifying where the markers are, what they look like, what they look like when hovered over with the mouse, what they look like when not yet unlocked, you can (mis)use those markers to put Any other picture Anywhere on the briefing screen (so be creative) as long as the picture is contained within the campaign file or specified as URL. Campaigns can, like missions, link to files that will be downloaded from the internet when needed - use this with care and not often, since sometimes people won't be connected to the internet. (could be useful to create update notices or something like that)
The index file must be called "index.xml" or "index"
Note that some listed features are currently unstable and/or missing from the old releases. For example in the old release you had to call the index files "index.xml" and "index" was not supported.
TPassability = (canAll, canWalk, canWalkRoad, canBuild, canBuildIron, canBuildGold, canMakeRoads, canMakeFields, canPlantTrees{should add tree types}, canFish);
1
3
2
5[/quote]
Then the result would be 5. Which is not surprising, since first it will apply the index 0 to strings, resulting in 1, then it will apply the index 1 resulting in 3 and finally it will apply the index 3, resulting in 5.
The same trick works for xpaths.
"http" files are downloaded before they are used. Beware that they may be downloaded multiple times in the current implementation (if strings would be a http file it would have been downloaded 3 times) I don't expect this to be a bottleneck but if it is I may cache the file after downloading.
Known issues & limitations
Yes there are some..
Due to the way filenames are kept apart from literal strings, it's impossible to have a literal string that equals a filename except when the [i]entire[/i] localized-string is a literal string. This may sound a bit arcane, so as a rule of thumb: name your files such that you will not need their name for anything else than to refer to that file.
It's not possible to let the locations of markers depend on the language. This might not sound like a limitation at first, but if you recall that markers may be (mis)used to put [i]any[/i] picture on the campaign screen, and that you can change the file being used for that picture based on the language, it might be clear to you that the pictures may have a different size and as such might have to be moved a bit. But you can't do that. Transparency is fully supported though, so to solve this, just put a transparent edge around the pictures so that their "middle" remains at the same place (relative to their upper left corner, which is used for positioning)
Comments please :)