Data Storage and Library Token Usage

[FrozenPhoenix]

Earlier today I finally got the time to start working on a few of the ideas that I've had in terms of a framework that I'd like to create as my D&D begins playing using Maptools. One thing that I noticed was a lack of any documentation on how to actually store data relevant to a framework. (I assume I noticed this is because of my total lack of experience here! ) I am hoping to accomplish two things here. The first is to confirm my ideas about how I believe data storage works; the second is to provide a framework that could be used to post information on the Wiki about this topic. I'll speak very conversationally at least initially, so I can point out where I hit a few road blocks.

-------------

The only way to store framework specific information about such details as weapon statistics, armor statistics, consumables, etc. is to assign this information to a token. To that end, a library token is typically used. I was initially confused by this as most of the library tokens from various frameworks that I downloaded and looked at had a nearly empty set of properties. From there, I didn't know where else the type of background information that I was considering could be stored, so I moved to macros. After a lot of browsing and distraction (lousy attention issues... Why do all of the threads have to be so interesting?), I had moved through JSON and stumbled on this thread.

From there, I noticed mention of properties again. That was the point at which I realized that the reason I did not see all of the information was because the token properties where the information was being stored were not listed as token properties under the token type in the campaign properties. Those data storage properties were considered to be properties of that token in another game, and thus were hidden, but still able to be read/changed with the proper commands.

For the example that I linked to above, the property would be generated by the macro that was being discussed and would contain a JSON object that would in turn contain other JSON objects, etc.. It seems it should also be possible to create your token with your data storage properties explicitly listed as campaign properties of that token type and use a complicated one line statements to create the JSON objects that you need. It seems VERY obvious that the macro approach is far superior in terms of ease of data entry and in terms of adding data incrementally.

I believe the importance of using library tokens stems from the need to send an updated copy of a token every time that something is changed. Thus, for information that is unlikely to change during play (i.e. weapon stats, powers, etc.), it is best to store this bulk data on specialized tokens as opposed to spreading it out and letting it eat up your bandwidth. When such information needs to be added/edited, it can be done before or after the game, negating the need to send a fresh copy of the token until the next gaming session.

-------------

So, do I more or less have it right? If so, I may consider typing up a cleaner framework for addition to the wiki. If I don't... well, I will do my best to hide my shame and work through my issues. At least if I were wrong I would have the consolation that I was attempting to clarify a few issues that may have affected others.

[Rumble]

I confess that I'm not sure I understand your post. However, I will say that I really don't use the Library Token for data storage at all - nothing gets saved to the Library Token in my framework (though that's not a rule).

The reasons to use Library Tokens, in my mind, are:

1. One set of macro code to maintain, rather than the same code on dozens of tokens
2. Library tokens allow the use of functions not available to "rank and file" tokens (though this is more that "trusted" macros can use them, the Lib:token makes it easy to make sure the macro is trusted)

Information that pertains to the character, I store on the character token in various properties. I do not use hidden token properties as a rule; I outline the properties needed in the framework and create them as campaign properties. The macros on the Lib:token, which are called by the character tokens, generate the properties and store them on the appropriate character token. Others use a different approach (and, with the use of hidden properties, it is possible to create a more portable framework, but I'm not sure that the benefits are sufficient not to just use a template campaign file).

[FrozenPhoenix]

Well, the way in which it came up was this. I plan on adding information incrementally as my players need it. However, we all tend to make new characters quite often and as such I would prefer to store certain information to make it persistent and accessible to present and future characters rather than just storing it on the character tokens.

For example, I was considering creating a token named Lib:Weapons (or possibly just making it Lib:Items and bringing all items into it), and using a macro to set up a dialog that I could use to input information. This way, as we play and we use more and more weapons, I would be getting a more complete list of the weapons and all of their properties. Then, when we inevitably reuse a certain item, I don't have to input all of the information again. Instead, I can have the character creation/leveling macro that I am working on reference the correct library property, pull out the base weapon information, pull out the enchantment information, etc., and then put all of that onto the player's token for me.

Is that clearer? I genuinely want to set up an item database, and I'd like to use the token properties of my library token to hold the information. I don't particularly care about whether the information appears when I actually look at the library token's properties, it'll mostly appear as nonsense, which is what I assumed some of the other frameworks were doing. I could easily be wrong, but it was the idea that I got from looking at a lot of disparate information.

Edit: Fixed a few things to clarify... and thanks for the response!

[Azhrei]

I do use Library tokens for data storage and I think the OP's understanding of why they might be used that way matches my own.

I use them primarily for information that would be relevant to all tokens or to a map in general. For my Pathfinder game, that means: (1) the harrow deck readings from CotCT. These are like tarot cards and I need to keep track of which cards are drawn at the beginning of each chapter as the results are pertinent to the story in that chapter. The library token holds which cards were drawn while the actual card data is stored in a table (that thanks to applekor the players can no longer see the contents!). The library token includes macros to display the layout of said harrow reading, with different results depending on whether the person running the macro is a GM or a player (the GM gets tooltips for each card, a summary of how to read the layout as an extra table column on the right, and a hint as to whether the card is especially important in its position).

I am building a series of macros for thelevitator's new custom game system. Library tokens will hold short-term and long-term read-write data and tables will hold long-term read-only data. Tokens will hold data relevant only to that token.

[Rumble]

Ah, okay, I did misunderstand. Though I don't do it, that is a perfect use of the properties on a token - you can use those properties via macro and have no information other than the weapon's name recorded on the token itself, for instance.

If I were to do that, I wouldn't use hidden properties - I'd create a property set specifically for that library token - but that's because I like to see what I am working with (and if I have to come back to it later, it's easier for me to follow what I was doing).

One caveat, though, is that I wouldn't do that for game system elements that aren't open - so 4th edition feats, powers, weapons and such are stuff I would not store, or at least, I won't store them as written in the books. Mechanics, maybe, but no descriptive text. It's also the reason there's no descriptive text in my framework, and that people have to input their own power information.

[Brigand]

Game mechanics are generic enough that they can't be copyrighted.

[Rumble]

Game mechanics are generic enough that they can't be copyrighted.

However, the expression thereof can be; therefore, as I said, I don't mind storing the mechanics (say, dice sizes, bonuses, etc), but I won't be including libraries of powers, feats, items, etc. Specific expression that is more substantial than "Axe, d10, +2" (which, I agree, is too generic to be copyrighted) would not be something I would put verbatim into my framework.

[FrozenPhoenix]

This gets into an interesting question. I had been told before that so long as the information was created for personal use (by myself and players) and not distributed, that you could use any of the 4e information. Is that correct? And if so, what about distributing an empty framework, with no information, but that contains macros that would allow others to input whatever information you choose?

Also, with all of the other available files out there, where is the line? You can find specific items/monsters/whatever within. I know that the 4e license is much more strict than any of the previous D&D systems, but I am not a lawyer and have a limited understanding of what the license translates into in practice.

[Rumble]

This gets into an interesting question. I had been told before that so long as the information was created for personal use (by myself and players) and not distributed, that you could use any of the 4e information. Is that correct? And if so, what about distributing an empty framework, with no information, but that contains macros that would allow others to input whatever information you choose?

Also, with all of the other available files out there, where is the line? You can find specific items/monsters/whatever within. I know that the 4e license is much more strict than any of the previous D&D systems, but I am not a lawyer and have a limited understanding of what the license translates into in practice.

That question can only really be answered by a lawyer. The essence of it is that you can't copyright an idea (or a procedure, like a game mechanic, though such a thing could possibly be patented), but you can copyright the specific expression of that idea in some medium. So the actual words used to describe a mechanic are potentially copyrightable, even if rolling a 20-sided die and adding a value to the result is not.

What you intend to do with your reproduction of copyrighted material has no bearing on whether your actions violate the copyright with the exception of things that fall into "fair use," which is hard to pinpoint. If you were quoting the mechanics in an academic paper? Probably no problem. Making copies and distributing them to friends (even with no profit motive)? Could be a problem, if the copyright holder wished to make it one.

Distributing a macro framework with no proprietary info? I wouldn't worry about. But if I were to upload the 4th edition monster manual in the form of tokens or a Library token with monsters on it and let people use the tokens, then, in my I-am-so-NOT-a-lawyer opinion, I am skating on much thinner ice.

What are the odds of anything happening? Slim, probably. Might get a cease & desist letter, which if you comply is likely to be the end of it. And remember, it will depend on the game - D&D 3.5 has a license that specifically lets you do some of that stuff. 4th Edition is a different matter.

Again, this is lawyer territory. I'm not one; my experience with copyright is based on being a librarian and working with rights management in several areas, reading a lot, and going after people who've used my art without permission.

[Veggiesama]

Rumble, stumbling over his newfound moderator powers, accidentally blew away Veggiesama's post.

[Rumble]

Goddarnit. Veggie, I'm really sorry. I meant to quote and accidentally hit EDIT, and since I'm a post-approving mod, I have edit powers.

I think I wiped out your post and replaced it with mine. I am VERY sorry! I'll see what I can do to fix it.

Also, as a peace offering, I will show you "varsFromJSON": Create the following macro, and name it varsFromJSON (or whatever you like):

Code: Select all

[h:testObj =arg(0)]
[h:varList=json.fields(testObj)]
[h,foreach(var,varList),CODE:
{
     [value = json.get(testObj,var)]
     [set(var,value)]
}]

Then, create a user-defined function like so:

Code: Select all

[defineFunction("varsFromJSON", "varsFromJSON@Lib:4E", 0, 0)]

When you initialize that by running the defineFunction macro (or putting it in "onCampaignLoad"), you can then do things like:

Code: Select all

[varsFromJSON(myObject)]

And voila! You have variables.

[Veggiesama]

Hahaha, now I need mod powers to RECTIFY this situation by FORCE! This trangression shall not go unpunished! This means WAAAGHH!!

I'll post what I did earlier, but Rumble's solution with user-defined functions (I still need to learn those) looks like a better alternative:

Calling macro:

Code: Select all

[MACRO("unloadLibraryProperties@this"):""]
[H: varsFromStrProp(macro.return)]

To achieve a hit, you must roll a [R: THRESHOLD_HIT] or higher on a [R: SR4_DIE].

Code: Select all

<!-- Veggiesama's unloadLibraryProperties macro, MapTool B55 -->

[H: LIB = "Lib:SR4"]
[H: return = ""]
[H: return = setStrProp(return, "LIB", LIB)]
[H: return = setStrProp(return, "SR4_DIE",           getLibProperty("SR4_DIE"          , LIB))]
[H: return = setStrProp(return, "MINIMUM_TO_GLITCH", getLibProperty("MINIMUM_TO_GLITCH", LIB))]
[H: return = setStrProp(return, "THRESHOLD_HIT",     getLibProperty("THRESHOLD_HIT"    , LIB))]
[H: return = setStrProp(return, "THRESHOLD_REROLL",  getLibProperty("THRESHOLD_REROLL" , LIB))]
[H: return = setStrProp(return, "SHOW_NPC_PHYSICAL", getLibProperty("SHOW_NPC_PHYSICAL", LIB))]
[H: return = setStrProp(return, "SHOW_NPC_STUN",     getLibProperty("SHOW_NPC_STUN"    , LIB))]
[H: return = setStrProp(return, "SHOW_NPC_MATRIX",   getLibProperty("SHOW_NPC_MATRIX"  , LIB))]
[H: return = setStrProp(return, "SHOW_NPC_EDGE",     getLibProperty("SHOW_NPC_EDGE"    , LIB))]
[H: return = setStrProp(return, "SHOW_NPC_AMMO",     getLibProperty("SHOW_NPC_AMMO"    , LIB))]
[H: return = setStrProp(return, "BAR_LIST",          getLibProperty("BAR_LIST"         , LIB))]
[H: return = setStrProp(return, "SHOW_NPC_VAR_LIST", getLibProperty("SHOW_NPC_VAR_LIST", LIB))]
[H: return = setStrProp(return, "FIRE_MODE_LIST",    getLibProperty("FIRE_MODE_LIST"   , LIB))]
[H: return = setStrProp(return, "FIRE_MODE_BULLETS_LIST",     getLibProperty("FIRE_MODE_BULLETS_LIST"    , LIB))]
[H: return = setStrProp(return, "FIRE_MODE_DESCRIPTION_LIST", getLibProperty("FIRE_MODE_DESCRIPTION_LIST", LIB))]
[H: macro.return = return]