MapTool 1.3 Development Build 55

[Merkuri]

Couldn't we add a note somewhere to the export screen that says, "Note, this will only save X,Y, and Z, but not A and B." I think as long as you let people know what to expect with a feature they'll be okay with it not being exactly what they want. Oh, they'll ask for it to do more, but you always have people asking for more. At least this way they hopefully won't be under the impression that it does one thing when it was designed to do another.

[trevor]

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.

Heh, after 4 years of development and community involvement, you'd be surprised how .... passionate voices in the community can get when they don't get B.

That, and it wouldn't be A+B it would be B, which means all the people who had and liked A would be very unhappy with the change. Often times it's easier to implement something the Right Way than give a hack and have to take it away later.

That said, I'm certainly open to the interests of the community. If they feel they will be happy with A, then I can put it in, but it will be well documented why B doesn't exist, and anyone who asks will need to be gently reminded why

[Orchard]

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.

Heh, after 4 years of development and community involvement, you'd be surprised how .... passionate voices in the community can get when they don't get B.

That, and it wouldn't be A+B it would be B, which means all the people who had and liked A would be very unhappy with the change. Often times it's easier to implement something the Right Way than give a hack and have to take it away later.

That said, I'm certainly open to the interests of the community. If they feel they will be happy with A, then I can put it in, but it will be well documented why B doesn't exist, and anyone who asks will need to be gently reminded why

I'm curious: I know it is extra work to put in user-selected granularity on the map export/save functionality, but the question is, how much more work is it? Being able to define what you want to save at export/save time seems like the solution to a lot of problems, but if its a real pain for you, then I can understand the problems.

I'm coming at this from the mindset of working with a large statistical package that does something along these lines: if you hit 'save as' you are asked which of the columns (variables) from your data-set you would like to save (and you can even save selected rows (or if you like to think of it this way: responses to each set of variables)). In some ways it works like an SQL query, but its all point and click. Likewise when you import a dataset you can selectively import some or all of the variables/columns. It's a rather slick setup, and increases data portability (imagine if portions of your data-set are sensitive, but you want to share only a portion of it--this is very useful).

In the same vein, being able to selectively export/import tokens, VBL, and various other components of the campaign file (possibly including multiple maps) would go a long way toward solving the argument of 'what needs to be done'. Of course, this does go back to 'doing it right the first time', but I'm simply saying that if we are really going to make map import/export a reality, then it may be best to do so with a good deal of flexibility. Which is, of course, yet another massive undertaking for someone.

[Azinctus]

Often times it's easier to implement something the Right Way than give a hack and have to take it away later.

You have a tough job Trevor. I would use the A option, saving a terrain file without tokens, I have a complicated map I'd like to use again but its in the wrong campaign file now, I'd be happy with the background layer alone, but if objects and LBL can come too that will save me work.

If later in 1.4 development you bring in new more powerful features that are not backwardly compatible that's fine, in fact we hope you and the other developer do just that. We ordinary users will be happy to share 1.3 maps for a while and we'll change up to 1.4 and the new map file system when we see some must-have feature has been implemented.

But in the meantime get all the functionality you can, without giving yourself a headache, into 1.3 before moving onto new ground. And if those functions are hacks we won't complain and we will patiently explain to anyone who asks that: it had to be this way for now, but Trevor has a plan for bigger and better things in the future.

[Cweord]

The problem with just the background layer, is what if the background layer is just a background, so your tables and chairs etc are on the object layer . . . .

The problem with this is the effect on people that have created maps already that they want to export may not be able to.

My choice would 2 options, export map, which would have no tokens but would have the object layer and VBL, and export senario, which would have all of the above + tokens.

That way, if you are using an identical senario in a different campaign, you can just plug and play . . .

[trevor]

Keeping stamps should be OK, just not tokens (with properties, sight, lights, macros, etc.)

[Amaril]

Keeping stamps should be OK, just not tokens (with properties, sight, lights, macros, etc.)

What about stamps with notes?

[trevor]

The problem comes up with dependencies on campaign properties, anything that's not a campaign property would be (well, I should say "should") be fine, such as token notes.

[Amaril]

The problem comes up with dependencies on campaign properties, anything that's not a campaign property would be (well, I should say "should") be fine, such as token notes.

Just making sure whoever develops such functionality keeps notes in mind.

I also think that any tokens imported into a campaign should adopt the default values for that campaign IF the properties do not match. That should be assumed by users.

[toyrobots]

You know what? I really want this feature.

But not now.

I want a 1.3 release more.

[DrVesuvius]

You know what? I really want a 1.3 release.

But not now.

I want this feature more.

Seriously, I understand Trevor's concerns about doing half a job on the "Save Individual Map" option. But a lot of us have said how much we'd like to see it and a lot of us have said that the "half job" is actually the half of the functionality we'd need. Personally I'd find it a pain if every time I wanted to save a map fo re-use I had to clear it of tokens first to save it "clean".

I'm not going to post on this matter any more, as I don't think there's much more to say without endlessly repeating the same arguments.

[Big_Mac]

Can we stop with the new stuff for 1.3? PLEASE. Lets get it to release. Concentrate on bugs no more changes. This is called project creep. Everyone wants what they want a sometimes forget that we do not pay for this tool. Trevor does an awesome job, PERIOD. And just because some feature does get implemented when Trevor hoped it would, people say he's breaking promises. He is the primary developer and is not paid. He does this for the fun and challenge. Let let him get this out and on to new stuff like some type of export or what ever. Give him some time to think it over.

Please lets all work toward getting 1.3 final.

[Cweord]

I couldn't agree more

[Amaril]

Please do not try to do this for 1.3! It can wait until 1.4. We are in desperate need of a stable release.

[toyrobots]

I suspect I am not the only one actually waiting on a final release of 1.3 to create my next campaign file. Keeping up the the dev releases is simply exhausting. I need something I can learn in my own time without it being obsolete in two weeks.

That and 1.2 is truly pathetic by comparison now.