TKE

[Thunderwolf]

As long is there IS progress, it's okay, I guess.

[harold]

For the people who do not read on the Polish forum I'll also put descriptions of new formats here.

* Single Map Missions
A zip file with a .mis extension instead of .zip. This is actually a fairly common thing to do
[quote=wikipedia]Some software uses the ZIP file format as a wrapper for a large number of small items in a specific structure; when this is done a different file extension is usually used. Examples of this usage are Java JAR files, Python .egg files, SilverLight .xap files, id Software .pk3/.pk4 files, package files for StepMania and Winamp/Windows Media Player skins, XPInstall, as well as OpenDocument and Office Open XML office formats.[/quote]
Files like that can be identified by their starting letters, "PK" (for Phil Katz)

Anyway. The file should contain a file named "index.xml" (or just "index", and you may use capital letters), the contents of which should look like

  Code:

<?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.

[Krom]

Say, it didn't occured to me before I made it to KaM Remake: Walkable/Buildable bits, this is tileset property and it's much more versatile than these 2 switches

Here's excerpt from my code:

TPassability = (canAll, canWalk, canWalkRoad, canBuild, canBuildIron, canBuildGold, canMakeRoads, canMakeFields, canPlantTrees{should add tree types}, canFish);

I'm unfamiliar with XML, how is it accessed, via special XML wrapper? Please show me few examples how you handle XML.

[harold]

The switches are there to override the "regular" properties of a tile - usually only useful to make normally walkable tiles unwalkable..
This forum has bad issues* with XML in code blocks, it removes all attributes etc..

Anyway, yes, I mainly use XPaths to query the XML file, because that makes my code short and easy to write. It's not the fastest way but it's fast enough. Writing is easier, you can just keep a stack of strings (for each element) and I probably don't need to explain how to use it.

  Code:

string map = xmlDoc.SelectSingleNode("//map/text()", nsMgr).Value;[/quote] edit: * ok XML issues resolved, by "disable HTML in this post"

[Krom]

You mean like pseudocode

QueryValue = xmlDoc.SelectSingleNode("//parent-node/child-node", nsMgr???).Value;

Sounds easy to use

[harold]

It can do a bit more than that, you can read about it here: http://www.w3schools.com/XPath/xpath_syntax.asp

I also put in trees now but it's a bit of a hack (they don't move etc)
Still, it looks nice..
http://img14.imageshack.us/img14/856/devscreeny26.png
This is Blue Base, of the tutorial.

Edit: now they move, but I can't show that..

[harold]

I've been struggling for hours with a new kind of thing and I think I finally got it right - but I'm not even sure whether You like it (which might be more important than whether I like it myself)
The problem was localization of missions and campaigns, the solution I came up with covers much more than that and ended up being much more powerful then I intended it to be. That isn't a bad thing though.
And for all that I don't have a proper name for it..

Anyway, "the thing" works like this. Most strings (most filenames and displayed text, but not the author and background image) are passed through a converter that took me 3 hours to write.
Now I'm not going to explain how it does it unless anyone asks me since it's a long story, but I'm going to explain what it does.
It takes a string such as AllStrings{lang}.txt{23} and it spits out the string on the 23rd (starting at 0th) line of the file AllStringsen-GB.txt, or the file AllStringsnl-NL.txt or well it should be clear now. {lang} is replaced by the currently used language code.
That was the simple example, now comes the real work.
A valid localized-string is:
* a string that after pre-processing* does not contain { brackets } (literal string)
* a localized-string plus {index} where index is (after processing!) a decimal number
* a localized-string plus {xpath} where xpath is (after processing) a string that starts with a / (slash)
* a localized-string plus {} (brackets with nothing inside) I don't know what this is good for, but you can use it.
Anything else is not a valid localized-string.
pre-processing:
All occurrences of {lang} {Lang} {language} and {Language} are replaced by the current language code.
All occurrences of {Author} are replaced by the name of the author of the campaign/mission (as specified in the campaign/mission) - you could use this (in combination with "http files") to make it harder to change the Author field for people who are not you, it won't be impossible though.
{Version} is replaced by the version of the campaign/mission
{Date} is replaced by the current date in dd-mm-yyyy format (dashes, day before month)
{Time} is replaced by the current time in hh:mm format (24h)

main processing:
Here is where the "(after processing!)" note comes into play. It means that you can nest indexers like so:
strings{strings{strings{0}}}
If the file "strings" contains:

  Code:

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 :)

[Krom]

I understand words from the description. Yet I can't imagine what are you talking about
Why is it needed and what for?

Language libs are preset. Scenery lang libs can be simply merged on loading. Why nest all the weird things when you can simple write the text on your own? How many times would one use any of your example {Author} presets...

That is a good "off class" project, as long as you enjoy making it - it's great! How it's related to KaM .... I don't know.

[harold]

Well it would be needed for new missions. That the language libs are preset isn't really a good thing - what if you need new strings?
This way you can have:
* new strings, translated to any language you like
* translated pictures - in case they contain text
* update notices, using {Version} in combination with a website
* math, though it's not Turing complete you have access to XPath's math capabilities (in addition to the weird example I showed), might be more useful when I add {Players} (for multiplayer)
I'll try to make it possible to know the colour of a player, like {Players} it would only be available when the game has started of course.

{Author} isn't very useful of course but it only took 1 line of code to add it
If you include it in website addresses it means that people who want to change the author will have to download those files. So it may be a good idea to include it in update checkers so that updates for the original mission won't go to changed missions

[Krom]

From all you listed I can think of some use only for Translated pictures...

You talking about things that are already preset when scenery/map is released.

And no, I wouldn't like having anything to be downloaded from the web without my notice. It could be unsafe.

[harold]

It would only be unsafe if the downloader or the picture loader or the mission loader has a serious error in it (or even the text loader)
The picture loader might contain such an error but the mission loader and text loader are in C# so they can't contain such error (they would crash first, and not execute the bad code), the downloader and the picture loader are from Microsoft which makes them hard to trust, but I'm sure they'd get loads of complaints unless they fixed them.

Under no circumstances would an executable file be executed.

what do you mean with "You talking about things that are already preset when scenery/map is released." ?

[harold]

Forgot to note:
You can of course also apply an xpath to an indexer, in case you have a file like this:

  Code:

<line>line0</line> <line>line1</line> <line>line2</line> <line>line3</line> <line>line4</line>[/quote] File a valid XML "file" on each line.

[Krom]

OMG I can't imagine one single case where it would be needed

Seriously, harold, these things are very cool and etc. I just don't think they are useful in KaM. Unless you could provide some astonishing working examples maybe...

RTF would be far more convincing a new feature.

[harold]

It isn't really a feature "on purpose", it's just a side-effect of how the parser works, an other side effect is that you can use "wrong brackets" if you want to (such as s}0}//text() in this case)

RTF would be impossible to implement though, the fonts don't allow it, and embedded pictures are painful.. and anyway you could just use a picture..

[harold]

Ok we're still fighting a bit with it, but the de-palletizing now mostly happens on the GPU. That means that sprites only need to be in memory once, instead of the old system where sprites affected by player colour would have to been in memory 'once for every different colour'.
How much memory this saves depends on the number of different player colours being used of course, but the savings are generally quite big.