MapTool 1.3 Development Build 55

[Orchard]

Seconding right back atchya. For me "Saving A Map" means the pretty stuff that I move my tokens around on top of. So that would be Background and Object layer, drawings and stamps. Oh and VBL I guess (though I don't personally use that). No tokens, campaign properties, states or anything like that.

I can understand how some users might think of saving a map as saving a pre-packaged encounter, with populated monster tokens already set up ready to pounce. That's a perfectly valid user requirement too, and I can see how that would be harder to implement.

"Save Current Map" vs "Export Current Map as Campaign/Import Campaign" - two different sets of functions.

If the first one is achievable it'll be useful for some of us.

Even if "Save Current Map" couldn't save VBL, it would still be a time saver (it being quicker to add VBL to an already drawn map than to draw the map from scratch, and THEN still have to add VBL manually.

What about this: the ability to Export map, then a dialogue to select what ELSE get's exported? Objects, VBL, tokens, etc. You could even allow for a fine-grained selection (save token X, but none of the rest) via tree-style checklists (or whatever those are called). And you could have the same dialogue show up on import.

This way, if you are exporting for personal use, you only transfer what's necessary, but if you are transferring for community use, then you can give more, and let the end-user select what they do and do not want, down to the bare map if they so desire. All with a few mouse clicks, as I see it.

[hyperactiveChipmunk]

Seconding right back atchya. For me "Saving A Map" means the pretty stuff that I move my tokens around on top of. So that would be Background and Object layer, drawings and stamps. Oh and VBL I guess (though I don't personally use that). No tokens, campaign properties, states or anything like that.

I can understand how some users might think of saving a map as saving a pre-packaged encounter, with populated monster tokens already set up ready to pounce. That's a perfectly valid user requirement too, and I can see how that would be harder to implement.

"Save Current Map" vs "Export Current Map as Campaign/Import Campaign" - two different sets of functions.

If the first one is achievable it'll be useful for some of us.

Even if "Save Current Map" couldn't save VBL, it would still be a time saver (it being quicker to add VBL to an already drawn map than to draw the map from scratch, and THEN still have to add VBL manually.

What about this: the ability to Export map, then a dialogue to select what ELSE get's exported? Objects, VBL, tokens, etc. You could even allow for a fine-grained selection (save token X, but none of the rest) via tree-style checklists (or whatever those are called). And you could have the same dialogue show up on import.

This way, if you are exporting for personal use, you only transfer what's necessary, but if you are transferring for community use, then you can give more, and let the end-user select what they do and do not want, down to the bare map if they so desire. All with a few mouse clicks, as I see it.

Sure thing. Would you like a complimentary perpetual motion machine with that order? Perhaps some cold fusion on the side?

>8)

-hC

[FdL]

I second the motion to make it just save maps. Just maps, saving and loading those would be huge.

See, for example, right now if I want to have random forest or urban encounters, I have to make a map specifically for those in each of the campaign files I have.

With an option to save and load individual maps, you can do that on the fly, have a small library of maps and just fire them up. Combined with pre-programmed monster tokens, this is godsend for the fast-minded, improvising DM (and for those like me too :p)

If I may digress a bit further, along with maps being exportable/importable, something very important is to have a way within the program to make the maps fit to the grid. Maybe stretching or resizing, something like that. Right now taking any map image and using it with MapTool can take a LOT more work than it should...

[Azhrei]

The current load/save patches save the whole thing (I think they're still current, but to be honest I haven't looked at them in quite some time and Trevor told me there's now a Versioning class for external files). That means the contents of all four layers, including FOW and VBL. But nothing other than the map and its contents: no sight/light, properties, etc.

As a realistic approach, people who are saving a map and importing it into another campaign are going to be importing it into the same framework, most likely. I seriously doubt that properties are going to be an issue. And a simple check during import to see if any tokens use a non-existent property would be enough to popup a dialog warning that tokens A, B, and C have been reset to the "Basic" property type.

And if the map is not coming back into the same campaign setting, simply delete the tokens on the Token and Hidden layer (assuming there are npcs of some type on the Hidden layer and not objects).

That functionality seems enough to satisfy most of the requests seen here for loading/saving of maps.

I would offer to make a JAR file available for people to test, but my MT has a bunch of other patches in the code so I couldn't give you a pristine b55+load/save JAR file (it has some other init panel stuff and various cleanups in it).

[Mrugnak]

As a realistic approach, people who are saving a map and importing it into another campaign are going to be importing it into the same framework, most likely.

That, right there, is an assumption that means 3.5 GMs cant use maps safely from 4.0 campaigns, or Pathfinder games and vice versa, or from other peoples implementations of the same game.

Never mind GURPS GMs wanting maps for their own games, or trading with Hero system folks, or Savage Worlds - Deadlands is published in Savage Worlds and in GURPS, for example.

[Azhrei]

As a realistic approach, people who are saving a map and importing it into another campaign are going to be importing it into the same framework, most likely.

That, right there, is an assumption that means 3.5 GMs cant use maps safely from 4.0 campaigns, or Pathfinder games and vice versa, or from other peoples implementations of the same game.

Never mind GURPS GMs wanting maps for their own games, or trading with Hero system folks, or Savage Worlds - Deadlands is published in Savage Worlds and in GURPS, for example.

You carefully left out the sentence from the following paragraph!

And if the map is not coming back into the same campaign setting, simply delete the tokens on the Token and Hidden layer (assuming there are npcs of some type on the Hidden layer and not objects).

Which means no compatibility is lost.

[toyrobots]

I'd really like a way to save the maps I draw within maptool. Some of them look pretty good and would be worth sharing...

They could be posted in various mapsharing forums (like the one I haunt for Rise of the Runelords on Paizo's Pathfinder forums), which will further spread the glory and popularity of maptool.

If I want to share a map now it is sort of a pain.

But honestly, unless it is really easy to do this, it should wait for 1.4. I require a stable release.

[trevor]

Here's my hesitation: I could drop the map save in as it stands, but one of the very first responses will be "Why are my tokens not saving with the map", I guarantee.

So then we'll build the full map save feature, but that'll be an entirely different file format. So then all saved maps break, and new ones won't be backward compatible.

[trevor]

- Single Image:
1) Horizontal depletes/fills the wrong way.
2) When told to place at the bottom, it stays exactly in the Top position, and behaves like it.
3) When told to place at left or right, it depletes as if the image was rotated and placed on the side, but the image is still at the top of the token (depletes the right way for a vertical bar though).

- Two Images:
1) When told to place at the bottom, it stays exactly in the Top position, and behaves like it.
2) When told to place at left or right, it depletes as if the image was rotated and placed on the side, but the image is still at the top of the token (depletes in the inverse direction, ie, full is on bottom and empty is on top).

- Multiple Images:
- When told to place at the bottom, right or left, it stays exactly in the Top position, and behaves like it.

I just did a test, and it looks like it is working correctly. Be sure that your health bar images are not square. They need to be exactly the right size (no filler). If the image is square, then it will always look like it is on the top or left. I've noticed that many of the posted health bars in the User Contrib forum are square images.

[palmer]

Don't make it a "Save" function then.

Make it an "Export"

Coordinate and get it pre-documented in the wiki.
Get Brad to do a new video just for this feature.

And yeah, that question will still come up... and we'll still answer it.

Honestly, if that's your entire reason for hesitating, then you never should have made "Vision: Off" the default setting. We get constant questions asking why they draw VBL and it doesn't hide anything.
(N.b. A major source of these questions would be Brad's videos)

"Export Map" can't be as bad as the "Turn Vision to Day or Night" questions are.

PS: Please change the default vision, or make it a user pref. I've had too many maps where I draw tons of VBL, only to have the players see everything anyways because it defaulted to Off and I forgot

[galneweinhaw]

PS: Please change the default vision, or make it a user pref. I've had too many maps where I draw tons of VBL, only to have the players see everything anyways because it defaulted to Off and I forgot

Seconded =D

User pref please!

[Full Bleed]

Honestly, if that's your entire reason for hesitating, then you never should have made "Vision: Off" the default setting. We get constant questions asking why they draw VBL and it doesn't hide anything.

Creating a second case for consistent user questions shouldn't be justified by the fact that there are existing cases that cause consistent user questions.


It just seems like the functionality people are looking for here should be part of a more advanced and user friendly Export function to me. I don't see how complicating the save process will be a good thing.

[Natha]

Here's my hesitation: I could drop the map save in as it stands, but one of the very first responses will be "Why are my tokens not saving with the map", I guarantee.

Good point but why don't call it "Export map background " or something ?
Then add an "Export Full map" later (1.4) ?

So then we'll build the full map save feature, but that'll be an entirely different file format. So then all saved maps break, and new ones won't be backward compatible.

Unless you make 2 different exports with their own format and goals like I said above ?

[palmer]

Except that Trevor went and described exactly what his original idea on "save map" was... a 1-map campaign.

And we HAVE that file format already. It's called .cmpgn

I think Export vs Save would save a lot of hassles.
For what Trevor was thinking, I'd call "Export Encounter" or scenario.

Really, the save framework is there already... just needs a tweak to not save tokens or other maps.

It's the IMPORT that matters.

[DrVesuvius]

Here's my hesitation: I could drop the map save in as it stands, but one of the very first responses will be "Why are my tokens not saving with the map", I guarantee.

So then we'll build the full map save feature, but that'll be an entirely different file format. So then all saved maps break, and new ones won't be backward compatible.

If you think that people are going to interpret "map" as including tokens, VBL, campaign properties, states etc, then don't call it "Save/Load Map". Call it "Save/Load Terrain" or something.

Here's my sample use case, a real, practicle example that came up in my current 50 Fathoms game. Early in the campaign the PCs visited (well, broke into) Pettigrew Manor, a large country house. I drew it out in MapTool, rooms, furniture, surrounding scenery etc. We played the session and they didn't burn it down. They then set sail and spend a couple of months of real time sailing the Pirate Sea visiting various places. To prevent the campaign file from bloating too much I did a housekeeping of the early maps, which included removing the map for Pettigrew Manor. Months later, they return to the island and re-visit Pettigrew Manor. Now I have no way of getting the originally drawn building into the current campaign file. So there's nothing left but to draw it again.

If we had a "Save/Load Terrain" option, it would be immensely useful to be able to save maps like that for later re-use.

Honestly I'm not sure I understand the argument that says "We can't give functionality A, because then some users will want A+B and implementing A+B is hard" That way nothing would ever get done.

I'm not seriously suggesting using the "Terrain" name - personally I think "Save/Load Map" covers the meaning quite well, and people who want to save complete encounters with tokens, VBL, campaign properties etc should do so as Campaigns. Whatever it's called "Save Encounter", "Save Background", "Export Map", can we please have the ability to save and load individual instances of the equivalent of the paper battlemap we'd lay down on the table in a face-to-face game.