MT 1.3b60 Progress

[lmarkus001]

* Added setCurrentMap() function to allow initiative to be moved from map to map in macros.

How's this work, exactly?

setCurrentMap("map-name"). I added it for somebody who said they needed to write a macro that shifts tokens and initiative from one map to another. I don't remember how he was going to do it and I can't find the post right now...

That was me!

Capture current round
Capture current init
Remove from init
Move to map
setCurrentMap()
Set Current Round
Add to init
viola...

[trevor]

I'll get the internal testing machine working, and do a build later Monday if things look clear

So, you may be asking yourself "so where's the build?!"

Well, good question. It got play tested on Tuesday, and then a high demand feature was requested to be put in, so I've been hacking that out. Should be ready rsn.

[Rumble]

then a high demand feature was requested to be put in, so I've been hacking that out

You tease.

[Mrugnak]

... which feature? O.o

[dorpond]

It got play tested on Tuesday, and then.....[snipped]

*Raises Hand*
I'm guilty, but that's my job.

Good news though - got through a whole 4 hour game without a single issue or error!
So as of Tuesdays nights code, everything was rock solid! Woooo!

[Rumble]

So...what feature?

[trevor]

So...what feature?

heh, sorry, went out to dinner with the family.

Torstan has made some really fantastic art, markers and tileset for inclusion in MT, but on the bottom line I couldn't justify adding in 10 megs of images.

So I'm rebuilding the "Add to library" mechanism.

You can specify a local directory, a URL(any web address) pointing to a zip file, or select from a list of "official" MT art packs (e.g. Torstan's Library): just click it to download and install and it's ready to go.

[brad]

That is really awesome. You can just keep adding to it in the future. That will really help with people wanting to have an image library "out of the box".

[plothos]

Out of curiosity, if I had my players add a .zip file to their library with all my junk from a campaign in it, would this serve as a poor man's repository? If they added my images before the session in this way, would loading the maps during play go that much faster?

(No offense to the repository function, but the simple fact is I can never tell if it's doing anything - I've used it a lot and still have no idea if it's ever even worked, much less helped.)

[Chrest]

This sounds very, very cool. One of the major slowdowns for my group is waiting for graphics to load every time we move to a new map. If we can just send out a graphics pack ahead of time, that will be a major help.

[trevor]

if I had my players add a .zip file to their library with all my junk from a campaign in it, would this serve as a poor man's repository?

In fact I've been contemplating deprecating the repository feature in favor of this one. Then you can put your zip up somewhere, email out the URL and people can add it to their repo.

The downside is that the images will show up in their library, so secrets may get lost.

[dorpond]

The downside is that the images will show up in their library, so secrets may get lost.

That is huge enough to not have it replace our current setup then. If players could all view my RPtoks and maps, that would be devastating.

I love the idea though - for adding "art packs" and look very forward to having Torstans' be the first wave!

[Full Bleed]

The downside is that the images will show up in their library, so secrets may get lost.

Why not use password protected zip files where it has to fetch the password from the server to pull something out?

[plothos]

The downside is that the images will show up in their library, so secrets may get lost.

That is huge enough to not have it replace our current setup then. If players could all view my RPtoks and maps, that would be devastating.

Agreed, this occurred to me as soon as I posted my question - but of course this I would know was working, if we've confirmed (as I think we just did) that it'd work.

Um, the other thing I tried doing once was have my players download the repository zip and drop the files (i.e. the images) into their assetcache folder. But this doesn't seem to have worked, because a player even after doing so still ran into that fatal dialog background image problem we had a while back in conjunction with my Spell Manager.

Would the following be workable?
1. Add an option to save a file called "name.mtimg" or something that is essentially a single file containing the image data used in the campaign.
2. Upload the somewhere and have the players dl it.
3. Players can't "peek" (unless they're determined codies) because it's not in a standard image format and doesn't go by a .zip extension.
4. Players use the option "add to hidden resources", which unpacks the image files into a folder in the .maptool folder called "hidden resources" and into a subfolder by the name of the .mtimg file.
5. The name of the .mtimg (and thus the folder to look in) is associated with the campaign somehow (either at server startup or in campaign properties), and when players connect the server tells their machines to look for images there first.

Players could still find secrets this way, but only if determined and knowledgeable, which limits the problem (and the threat is voluntary anyway). But this has the virtue of being relatively user-friendly and pretty foolproof, in virtue of a dedicated file type and file menu options. (The "special" file could very easily just be a zipped folder going by a different extension.) Confirmation that it's in operation could even be had in the form of a note when the map is loading for the player that images are being looked for from the "hidden name.mtimg repository".

I don't know how workable that all would be, but it seems like since we already have the repository stuff coded, it might be easily adaptable to handle all that.

[trevor]

The downside is that the images will show up in their library, so secrets may get lost.

Why not use password protected zip files where it has to fetch the password from the server to pull something out?

Unfortunately Java doesn't support password encrypted zip files.

That, and technically you would probably want to encrypt each file, rather than the archive as a whole.

Beyond that though, is an even larger problem, which is, it's nearly impossible to create an air tight anti-image share scheme. We can make it trickier, but not impossible to see the images you get.

That said, we could still come up with something that could prevent inadvertent spoilers.