MapTool 1.3 Release Build 64

[Rumble]

Yep. If you'll notice this line:

Code: Select all

at net.rptools.maptool.util.PersistenceUtil.loadToken(PersistenceUtil.java:411)

in your exception log, you'll see that the problem relates to the binary asset storage. The problem was a bit tricky to track down originally because that code doesn't get called if the asset is already in the .maptool/assetcache directory. That's why some people don't see the problem. It also explains why it didn't turn up in my initial testing. I'm going to have to either start emptying my assetcache or telling MT to use a different directory for testing purposes...

I should have a build out soon to correct this.

Aha! That would explain why my Windows install sees it, but the new Linux install didn't. Cool.

[Azhrei]

Wow, this update touched a bunch of classes!

I've tested it with campaign files going back to 1.3.51; prior to that isn't supported in the current version of the code so I don't plan to go back any further. (A campaign saved in b48 definitely did not work.)

I've checked in the code to SVN, revision 5263. Note that the parser and rplib projects need to be checked out as well. In my setup, I have MapTool, plus those others, checked out as separate projects and the build path configured to treat the libraries as dependent projects. This ensures that they are up to date when I go to test MapTool.

Existing campaigns that store asset image data inside the XML using Base64 strings should be read correctly. New campaigns saved will write the binary data as separate files in the assets/ directory of the zip file with the proper filename extension on the end. I modified the way PersistenceUtil methods load and save assets and made sure that all locations called the loadAssets() and saveAssets() methods which they hadn't been doing previously.

I also found a few speed ups in a couple parts of the code and my campaign saves were quite a bit quicker (as well as about 5-6% smaller with the above asset change). I'd still like to find some way to compress the XML and turn compression off for the image data (they're already compressed) but I haven't looked into it very deeply yet.

While I was in there I fixed a few problems with importing and exporting maps. There were private fields in the Zone that were not being updated when an exported map was imported, causing duplicate maps. I've added an imported() method to the Zone which fixes the two issues I found (creationTime and id) and can easily be updated if other fields are added to the Zone that need to be finagled. I also implemented an incrementing counter that is prepended to the map name, so a map called "My House" will be named "Import 1 of My House" on the first import, with the number increasing each time. (Similar to how creature names are incremented.)

I noticed that the entire contents.xml file is loaded and saved as a single XML string! This has huge implications for memory consumption. I have a medium-size campaign with 35MB of XML stored there. I will look at using an OutputStream instead of a String. But it works and I'm not in any great hurry just yet.

If people with Eclipse will update and try this latest revision, I'll do a build tomorrow. I've got a game tonight though and I need to prep for it.

[plothos]

I also implemented an incrementing counter that is prepended to the map name, so a map called "My House" will be named "Import 1 of My House" on the first import, with the number increasing each time. (Similar to how creature names are incremented.)

Will this always occur, or just when there's a need to disambiguate? Because I can see that getting kinda annoying on the user end, if one was to import with any frequency.

[Azhrei]

Will this always occur, or just when there's a need to disambiguate? Because I can see that getting kinda annoying on the user end, if one was to import with any frequency.

Any time a map is imported. But yeah, I can see that getting annoying if you have to go back and rename them after the fact!

I suppose it could be only if an existing map of the same name is already there. Or I could cause the Rename Map... dialog to appear?

Right now I'll leave it as-is since it will correct the problem of multiple maps with the same name. And perhaps how to handle it could become a checkbox on the Preferences dialog. I was already planning to add a checkbox there to enable the map import/export so that more people could test it; it's a little clunky right now.

[Rumble]

Azhrei, I just synced with the repository and I'm not seeing the incrementing prefix on a map import - I imported a map called "Approaches", and ended up with two maps called "Approaches" in the map list. I'll re-update my source code and try again, just to be sure.

Edit: ah, heck with it. I'm getting all sorts of build path errors (including a reference to Users\Frank\libraries\parser.something.lib ) and can't build or run it.

[nortonweb]

Although these discussions are an interesting view being the "GM Screen" should that not be moved to 'Developer Notes'?
We aren't really talking about build 64 any more are we. Build 64 seems fairly unworkable at present (I won't be suggesting my players move to it yet) we are discussing the as yet unseen by the public build 65. Which is in development.

[Azhrei]

Yep, you're probably right. But the announcement thread is where people have historically reported initial bug findings, so it makes sense to discuss build-related problems/solutions here.

[Minch Ruwin]

Great Job Azhrei!

My two cents on the naming convention would be MapTools v1.3 and any bug fixes would be MapTools v1.3 HF0.1 (0.2, etc) where HF is "hot fix". That way we get folks used to the habit that we're not really intending to add functionality, just repair any bugs that are found.

Awesome work fellas!

Later. Minch.