Campaign Compatibility

Notes on testing the latest builds of MapTool

Moderators: dorpond, trevor, Azhrei

Post Reply
User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Campaign Compatibility

Post by JamzTheMan »

Az, is there anything you can do to mark a field/variable so that it's "saved" but also "skipped" if missing?

I have a new field for my light sources but of course if you mark it transient then it's not saved and is lost. I think I know the answer but just making sure. I'd like it to be backwards compatible if possible.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Campaign Compatibility

Post by Azhrei »

Not built in to XStream (the library MT uses).

However, if the object has an instance member that is not initialized when the XML is read in, that member will be set to it's Java-defined initial value (such as 0 for integers and null for references).

That doesn't help for backward compatibility, though. There's no way (currently) for b87 to know which fields exist in b89 and which don't. So if it sees a field that it doesn't recognize, the only practical thing for the XStream library to do is to error out and complain. The XStream library itself would have to include code that allows it to ignore individual fields in the XML data stream and it doesn't.

One other possibility that I haven't coded yet... When b87 tries to open a campaign file created by b89, it could ask the RPTools.net web site if there's a conversion file available. This conversion file would be able to massage the incoming b89 XML data stream into something that b87 could digest. However, this is difficult to do efficiently. One way is to put a Java .class file on the web site and have MT use that (but this wouldn't be secure). Another is to put one or more regular expressions in the file and have MT pass the data stream through each one before forwarding it to XStream. This could work except the interface to XStream isn't geared for this (the wrong kind of constructors). Another choice would be to pass the data to the web site and have it convert it and send it back (obviously way too much overhead in this!).

I'm open to ideas. (Probably not for 1.3, though. ;))

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: Campaign Compatibility

Post by JamzTheMan »

How about a Save As/For option instead? Maybe we can keep the older classes in the package or elsewhere, and if needed, you could save the campaign "back" to a previous version? So instead of trying to future proof, you just build in the conversion.

The campaign would then always save in that older version unless the user changes it. Maybe, you even allow multiple versions in the same campaign. I'm basically thinking it could work just like MS Excel, Save as 2013, Save as 97-2000, etc.

It give a little more flexibility but you can still cut off major versions, eg, nothing before be b67.

And agree, spit balling now for 1.4/2.0.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Campaign Compatibility

Post by jfrazierjr »

Though I agree it would be quite a lot of work to put into 1.3, another possible option that's somewhat easy (conceptually at least) to handle would be a pre-load processor via an external xslt stylesheet(perhaps located in the .maptool directory) which handles the xml file and re-writes it before passing to the xstream library. I don't know much about how the load mechanism works, but if the Xstream library does NOT handle the zip/unzip aspect, it could be inserted after the unzip operation MT does, but before it passes it to XStream to build the classes into objects.

For that matter, a UI with a simple xpath(meaning someone would have to crap open the xml and figure out the xpath) of the nodes that "break" and have any provided xpath statements removed from the campaign file. Thinking about this now, I think this would be the best approach vs the stylesheet mentioned above.

In either case, we would want to either backup the original campaign file or create a dummy one for that session so that the original is not blasted away.

Another thought is that someone with a bit of java/xml experience could easily write a stand alone converter that would open the campaign file and strip "bad" content out(again, based upon xpath) and write it back out again.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: Campaign Compatibility

Post by JamzTheMan »

That's not a bad idea Jz, the external converter that is. I can take a look at it. It doesn't have to be java, in fact i may do it in php/xpath, i already have several pieces of such code for hero lab files.

Although, once you define the xpaths needed, it could really be plugged into MT, a external java program, or anything else.

Of course it should have the standard "you may lose some functionality in downgrading" warning.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Campaign Compatibility

Post by Azhrei »

Two things.

1. If you save in an older format you lose functionality (because the information regarding that functionality is gone).

I'm guessing you don't want that. :)

2. If you check the source code in the FileUtil class (I think that's where it is, might be in PackedFile) there are some comments for exactly the suggestion Joe had. ;)

I think the comments even say that it would be cool to put the transforms on our web site and have MT grab them dynamically based on which versions were being manipulated.

But there's a lot of ground work that would have to go into it and the XStream interface layer is really not setup very well for it. The whole section needs a rewrite. I was going to tackle file IO for 2.0 and still might, but now the question is whether we want to use a completely new approach. Maybe we create a bunch of directories and put serialized objects in those directories, or maybe we use a database with ORM tools, or maybe we use java.nio so we can have memory-mapped files, or maybe...

As you can see, this is currently up in the air. I've got some international travel coming up and then a lot of business that will keep me traveling for the rest of the month (anyone in San Jose/Costa Rica wanna get together for dinner next week? Or Bellevue/WA the week of the 12th?). But I plan to spend some hotel room time working out the details of the ORM approach. I have used both annotations and external XML files and I don't like either one of them. :(

Post Reply

Return to “Testing”