What I came up with isn't a framework by any means. With the exception of a campaign macro and a couple of tables, all of the functionality and all of the data is stored within a single library token (or more if you want to get fancy), which can be exported/imported from campaign to campaign as necessary.
As usual, try it out at your own risk. It's still rough around the edges and in no way thoroughly bulletproofed or tested. I've only put the scripts together in the last couple of days, so there's probably all sorts of issues waiting to be found -- and I haven't had a chance to check out that image-not-loading-over-the-internet issue (largely because I run a subversion repository for the asset cache -- players just double-click a batch file prior to running map tools and it updates everything for them -- so they always have the latest assets).
All that being said, it did seem to work pretty well for the game I played last night, so...
OVERVIEW
This macro system provides an interface and backend functionality to create, edit, store, delete, and view handouts, to notify players of handouts that are now available to them, and to allow players to view a current list of their handouts, highlighting those that have not yet been viewed. It also allows a GM to limit access to handouts, setting their permissions on a player-by-player basis.
Handout functionality and data is all stored in a library token and accessed by a campaign macro. Two tables store information about handout styles and some icons used for the handout menus and so on.
INSTALLATION
1) Import the Handout Styles and Handout Icons tables into your campaign.
2) Add the handouts library token to a map in your campaign (preferrably on the hidden layer). Ensure it is visible to players and its name begins with "Lib:". These values should be enabled by default for this token.
3) Import the Handouts macro into your campaign macros.
REQUIREMENTS
- Map Tools 1.3.b57. I can't vouch it'll work on earlier versions but it probably will. Maybe. =)
- When you start your server, ensure that Player's Receive Campaign Macros is enabled.
FILES
Handouts Library Token
Handouts Campaign Macro
Handouts Icons Table
Handouts Styles Table
EXAMPLES
Handouts Campaign File
USAGE GUIDE
All of the functionality of this handouts system is available via the "Handouts" campaign macro. Simply click it to bring up the relevant frame (either the GM Handouts frame if you are the GM or the Player Handouts frame if you are a player).
HANDOUT DATA
Handouts contain a bunch of different types of data, only a little of which is actually useful to the player/GM. THere are five primary pieces of information that are important (the remainder are pretty much hidden from the end user so they can safely be ignored). These are: title, summary, content, and style.
The handout title is what appears at the top of the handout. It's a simple text string. Not much more you can say about it. I like to keep handout titles fairly full of flavour text, so that players have to view the handout to actually get an idea of what it's about. eg. "A Dark And Hungry God Arises". Gotta love stealing book titles. =)
The summary is a single line of text which gives a bit more detail about the handout. I usually use it for descriptions of where the handout was found or what it's about. eg. "Found on the body of a dead cleric in the tombs of the Al'harach."
The content is just what it sounds like. It's the bulk of what the handout is about. It can contain html (limited to 3.2 ugh) and can also be used to add images like portraits and so on. At the moment I'm only doing minimal amounts of formatting on the content of a handout (simple line breaks and so on), but sometime in the future I'm thinking of implementing things like decoration initial text and so on. Until then, you can always just do something like what's below to get your decorative text.
Code: Select all
<span style = "font-family: Impact; font-size:3em;">D</span>ecorativeIndividual handout data is completely contained within the library token. Thus, exporting the library token will effectively save all your handouts out to a separate file which you can then import into other campaigns.
GM HANDOUT
The GM handout view is a frame which forms the core interface for the GM. So far I've been using it docked over to the right of the screen so I can quickly flick it open and add/remove/adjust handouts as needed. That seems to work fairly well for me.
The GM handout view allows a GM to create new handouts (by clicking the create button at the top-left), to remove existing handouts (by pressing the remove button adjacent to each handout entry, and then checking "Yes" when prompted for whether you want to confirm the deletion), to refresh the current list of handouts (by clicking the refresh button at the top-right -- handy if you have multiple GMs adding separate entries), and to edit existing handouts (by clicking on an individual handout entry).
At the moment, the only way to adjust handout permissions is to click on the handout entry and go into the edit handout dialog and then adjust them there. I'm thinking about re-working the GM handout view slightly to allow you to set the permissions directly from that interface, but I dunno... I guess I'll see how much of a hassle it is to have to go through an extra screen every time first.
CREATE/EDIT HANDOUT
The create/edit handout dialog is the next screen of importance. It allows you to fill out the main details of the handout (title, summary, content, and style, by typing into the relevant field or selecting a style from the list), to preview what the handout currently looks like given the values currently in the fields (by clicking the Preview button at the top-right), and to edit which players have permission to access the handout (by clicking the permissions button at the top-left).
Also of note on the create/edit handout dialog are the options to add GM Notes, Image, Notes, or a Portrait from a token to the content. Simply click the relevant button and you'll be prompted to select an NPC token on the current map to grab the data from. This data will then be appended to the current content. I'm afraid limitations in the scripting language prevent me from putting together a full inline-type editor for it all, but I'm sure you know how to use cut-and-paste by now right? =)
The thing to remember about this system for adding token information (notes, gm notes, image, or portrait) is that you only have to be on the same map as the token when you're adding that token information to the content. Once it's been added to the content of the handout, you're free to do what you want and you can change maps as desired. In fact, the way it works you can even select a portrait from a token in one map, switch to another map, then get GM notes or another portrait from a second token, then switch to a third map and get more data from a third token.
The main benefits of this system are that it allows data to be collected from multiple tokens on different maps, it allows users to view images and so on without being on the same map as the token (because it stores the asset id within an image tag rather than trying to look the data up dynamically from a token or static table, the image will always show up as long as it's within the client's asset cache), and that you can more easily customize the appearance of individual handouts.
The downside to this system however is that if you change a token's notes or portrait or whatever, you have to manually open up the handout and re-add the token information to the content. Personally I'm fine with that though, it only takes a few seconds.
EDIT PERMISSIONS
This dialog allows you to simply tick/untick the checkboxes of which players you want to have permission to view the handout. If the box is checked, the player has access to the handout. If it's not checked, they don't (and it won't even show up in their list).
The GM(s) can set Permissions for each handout so that they are only available to certain players. If you're a player and you don't have permission to view a handout, you won't have it in your list and you won't be able to view it.
Once the GM sets permission for a player to view a handout, any players who have not been previously notified of the handout are sent a whisper which they can click on to both view the handout and refresh the player handout view.
PLAYER HANDOUT
The player handout view is a simple list of the handouts that the player has permission to view. Unread handouts are highlighted with a different icon and a coloured background to better indicate to the player which ones are new and which ones are old. The player view really only has two options for the player. He can opt to refresh the list (updating it with any new handouts he has permission to read, or compacting/expanding the entries if he checks the "compact" box in the top left) or he can click on a handout to view it.
Currently I'm only allowing viewing one handout at a time. When I had players test out a prior version that opened each handout into its own dialog, they quickly got overwhelmed and frustrated by all the extra windows. It's a trivial change to adjust the functionality to allow multiple dialogs though, so if you want it...
HANDOUT CATEGORIES
It should be noted that I have designed the handout functionality to benefit from the use of multiple library tokens, each of which has identical functionality but acts as a separate "category" of data. This means you can keep different types of handouts separate, keep your lists of handouts within the bounds of reason, and more easily decide which handouts you want to switch from map to map. For example, you could create an adventure-specific list of handouts while having your campaign handouts in a separate token entirely.
To create a new category of handouts, simply import a new Handout library token into the campaign and set it up identically to your first one (hidden, visible to players, etc). Then double-click on the token and change it's name to Lib:<your_category_name> where <your_category_name> is the name of your handout category. For example, I use Lib:Adventure Handouts and Lib:Campaign Handouts as two separate library tokens.
Once you've got the appropriate library token in place, right-click on the Handouts macro in your campaign macro list and select Duplicate. Then right-click one of the two macros and select Edit. Change the label of the macro to something more descriptive, then adjust the command so that it points to your new library token. Simply replace the Lib:Handouts part of the macro with Lib:<your_category_name>. For example, for the campaign handouts library token from the earlier example, the command would become:
Code: Select all
[macro("Handouts@Lib:Campaign Handouts"): ""]HANDOUT STYLES
The Handout Styles table stores information about the appearance of individual handouts -- cutting down how much html formatting you have to do to add them and reducing the size they take up in the token. The zeroth column of the table specifies how many entries there are in the table. Each subsequent entry has its range set to an incrementing value (1 for the first entry, 2 for the second, etc). The value for each entry is a text string -- simple css which overrides the default handout appearance. The css classes are handout_text, handout_summary, handout_title, and so on. The image for the table entry specifies the background to use for the handout. Two dark parchment/paper type ones are included by default.
FINAL WORDS
I'm still in the middle of developing this, but I figured it was worth putting out there. Hopefully people won't find this too broken to use. Any feedback or suggestions are appreciated.
