Imper1um wrote:I'm looking at modifying the XML of an .rptok because I'm working on a program that will create the XML and zip up the files just like an .rptok file for use in Maptools.
Unfortunately, I do not know a few things, so I'm wondering a few things:
1. Is the order of the XML required to be in the order? I understand that all keys need to be there, but does the XML need to be in order, such as:
Order is not important in general. (I can't think of any instances where order is important off-hand, but it is potentially possible as some complex objects may need information from one field in order to properly interpret the next field. Nothing like that currently, though.)
The XStream library we use is
documented here and while much of it is Java-related you should be able to skip around that in order to glean what you need about the XML format.
2. What is the difference between id.baGUID and imageAssetMap.entry.net.rptools.lib.MD5Key.id? They look like two different structured keys, one being an alpha key (id.baGUID) and the other looks like an alphanumeric key (MD5Key). I did tie them down to two different assets in the assets folder, so I know that, but can I make up my own baGUID (Using C#'s Guid.NewGuid()), or does it have to be something specific? If it is something specific, what library do you use to generate the key?
Currently you can make up your own as long as they are unique. The current GUID objects are constructed from a hash based on the IP address and some random data; the actual value isn't important -- they are merely used as "Globally Unique IDentifiers" within the program.
4. Can I not include states in the state fields and it will be okay?
Um, don't know off-hand. You
should be able to leave them out and the XStream library will treat them as
null when reading them in (if you leave out the definition) or the Java code will treat them as
null when it tries to retrieve a particular key, i.e. state name. However, I don't know off-hand if the Java code will convert
null into
false automatically.
5. In the propertymap.store, is it okay to not include properties?
I would assume so, for the same reason as #4. I would suggest trying it. And as new builds of MapTool come out, be sure to keep an eye on the ChangeLog to ensure your code doesn't have any problem with it.
You will likely want to look at the
version field in the
properties.xml file as well, since that tells you how old the token file itself is. Right now MapTool doesn't actually use the version number for anything when reading in the token, but in the future it may be needed to apply automatic conversions. (This is actually a bug in MT; it does do conversions when reading in campaigns, but doesn't do any when reading in tokens. Theoretically it's possible that a token in a campaign might be read in just fine but the same token when stored as an RPTOK might fail while being read.
There's no simple way to fix this in the current version however. I expect to take care of it in 1.4.)
Thanks for your help. I should be showing off what I'm working on soon.
Cool. Hopefully it's cross-platform but even if it's not I'm sure there'll be people interested in additional automation tools...
And look inside the file or at the file size...