I still wish there were a way to make the images hidden(ish) so you wouldn't have to actively avoid seeing what the GM has you pre-loading.
But this is a HUGE new feature. Loving it.
MT 1.3b60 Progress
Moderators: dorpond, trevor, Azhrei
Re: MT 1.3b60 Progress
Drop-In Utilities:
My Spell Manager for D&D3.5 and PFRPG
My Inventory Manager for D&D and PFRPG, but more generally useable than that.
My Message Manager -- My Top-Down D&D Token Images
and my Custom Initiative & Status/Spell-Effect Tracker (work in progress, but functional).
My Spell Manager for D&D3.5 and PFRPG
My Inventory Manager for D&D and PFRPG, but more generally useable than that.
My Message Manager -- My Top-Down D&D Token Images
and my Custom Initiative & Status/Spell-Effect Tracker (work in progress, but functional).
Re: MT 1.3b60 Progress
I noticed that when I go back into the dialog a second time after loading torstan's stuff that his items are no longer on the list. MapTool must be keeping track of which ones have already been grabbed...
Perhaps we can find a way to hide those (in the Image Explorer) by somehow tying them to the campaign.
For example, the GM creates a ZIP file. The individual assets are not encrypted in any way, but there is a properties.xml file that contains a campaign public key. If the corresponding private key doesn't exist in a list maintained in the Edit -> Preferences... panel -- on a tab named Protected Images[/b]? -- then the directory doesn't show up in the Image Library.
Obviously it doesn't need to be a real public/private key right now, just a simple string will do. But maybe we could think of a way to use it down the road. For example, MT must be connected to a server before it will access images inside the ZIP file and such files are never stored in the asset cache...
We can't stop a user from browsing the directory on their system and looking at the images, but we can make it appear (within MT) that they don't exist. If nothing else it removes the temptation.
Perhaps we can find a way to hide those (in the Image Explorer) by somehow tying them to the campaign.
For example, the GM creates a ZIP file. The individual assets are not encrypted in any way, but there is a properties.xml file that contains a campaign public key. If the corresponding private key doesn't exist in a list maintained in the Edit -> Preferences... panel -- on a tab named Protected Images[/b]? -- then the directory doesn't show up in the Image Library.
Obviously it doesn't need to be a real public/private key right now, just a simple string will do. But maybe we could think of a way to use it down the road. For example, MT must be connected to a server before it will access images inside the ZIP file and such files are never stored in the asset cache...
We can't stop a user from browsing the directory on their system and looking at the images, but we can make it appear (within MT) that they don't exist. If nothing else it removes the temptation.
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
Re: MT 1.3b60 Progress
azhrei that's roughly what I've been considering, although somewhat simplified.
Have the properties file just like the .cmpgn files do that indicate information such as the campaign ID it associates with, and it will only show up in the library if you have that campaign open and are the GM. Would be a pretty simple fix. I _might_ put that in for b60. Might.
Have the properties file just like the .cmpgn files do that indicate information such as the campaign ID it associates with, and it will only show up in the library if you have that campaign open and are the GM. Would be a pretty simple fix. I _might_ put that in for b60. Might.
Dreaming of a 1.3 release
Re: MT 1.3b60 Progress
I need to campaign (no pun intended) for that Mac event rewriter fix that I sent you. The Mac UI is useless without a USB mouse if that fix isn't there.
TO ALL MAC LAPTOP USERS: help me verify the problem!! Use MapTool without an external mouse. Drop a token onto the default map. Zoom in and out using the "two-finger" method on the touchpad to prove the touchpad works. Then use Cmnd-Click to pan the map. After you've panned things around a little, you won't be able to select the token using a regular click.
If the above accurately describes your situation, let me know via a PM. I'll send you a patched version of the MapTool JAR that you can try that corrects the issue. Thanks!
TO ALL MAC LAPTOP USERS: help me verify the problem!! Use MapTool without an external mouse. Drop a token onto the default map. Zoom in and out using the "two-finger" method on the touchpad to prove the touchpad works. Then use Cmnd-Click to pan the map. After you've panned things around a little, you won't be able to select the token using a regular click.
If the above accurately describes your situation, let me know via a PM. I'll send you a patched version of the MapTool JAR that you can try that corrects the issue. Thanks!
Re: MT 1.3b60 Progress
Azhrei wrote:I need to campaign (no pun intended) for that Mac event rewriter fix that I sent you. The Mac UI is useless without a USB mouse if that fix isn't there.
TO ALL MAC LAPTOP USERS: help me verify the problem!! Use MapTool without an external mouse. Drop a token onto the default map. Zoom in and out using the "two-finger" method on the touchpad to prove the touchpad works. Then use Cmnd-Click to pan the map. After you've panned things around a little, you won't be able to select the token using a regular click.
If the above accurately describes your situation, let me know via a PM. I'll send you a patched version of the MapTool JAR that you can try that corrects the issue. Thanks!
Will do as soon as someone puts together a version that doesn't suffer from that ole debbil 63MB memory allocation...
Re: MT 1.3b60 Progress
What happens if an image in one of the libraries is added/changed/deleted? Will the client automatically make or at least notify you of those changes, or will you have to know about them and then delete and re-download the library?
How am I going to stop some big mean mother hubbard from tearing me a structurally superfluous new behind?
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
Re: MT 1.3b60 Progress
This is the current behavior.Waneta wrote:you have to know about them and then delete and re-download the library?
In the future we can make it smarter.
Dreaming of a 1.3 release
Re: MT 1.3b60 Progress
I would like a compartmentalization or diff function for this.trevor wrote:azhrei that's roughly what I've been considering, although somewhat simplified.
Have the properties file just like the .cmpgn files do that indicate information such as the campaign ID it associates with, and it will only show up in the library if you have that campaign open and are the GM. Would be a pretty simple fix. I _might_ put that in for b60. Might.
I add to my cmpgn one map at a time. I'd like to be able to make an asset zip for each map, rather than the whole cmpgn. And ideally just a diff on that. If I've already used Grass1.png in map 1, I don't need it in the zip for map 2.
Otherwise, players have to download the entire cmpgn asset set every week when I add a new map.
My cmpgn right now exports a repository (under b56) at just under 12 megs zipped.
If I were to add another map, with another 300k worth of assets, this means my players would end up downloading 24 megs of stuff to get 12 megs of actual assets.
Horribly inefficient, especially for dialup users (thats ~40 mins for the 12 megs) and anyone with a bandwidth cap (i.e. college)
So some way to make a diff and only zip up new assets, or at least a way to export single maps... even if I have overlapping assets in map 1 and map 2, exporting map 2 won't be 12 megs.
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
Re: MT 1.3b60 Progress
Of course at that point it's probably just easier to have the server serve the new images
Dreaming of a 1.3 release
Re: MT 1.3b60 Progress
For someone who changes things every week, it might be useful if they just create a new resource package with "only new things" in it, and pass that out for this weeks game.
Changed files are the same as "new" files, as far as Maptools is concerned I believe - they should have a different CRC code and therefore show up as "new".
The problem of handling diffs etc is at the original creation end, then, not duplicated across all the players machines. THe players just need to accumulate the ever-growing list of packages.
Changed files are the same as "new" files, as far as Maptools is concerned I believe - they should have a different CRC code and therefore show up as "new".
The problem of handling diffs etc is at the original creation end, then, not duplicated across all the players machines. THe players just need to accumulate the ever-growing list of packages.