Tokens owning tokens

[Benz72]

I was wondering if it was possible/useful/wise to have a system where a token (PC) could 'own' several other tokens (gear). The idea would be that once a library of gear tokens was populated equipment selection could be pretty painless. Also, since tokens are associated with a picture file and sized appropriatelywe could display dropped gear on the map. presumably there would have to be some kind of mechanism for changing ownership (pick up A, drop B, give C to your friend, etc.).

Any thoughts?

[kristof65]

I've been thinking about something similar myself. In addition to the ownership, I think tokens would have to be settable to different sets of property values. They _may_ do this already, I haven't explored it much yet.

[neofax]

Other than visual satisfaction, what does this accomplish that cannot be done thru macros?

[kristof65]

For the newcomer/non-programmer, it's easier and more intuitive to grasp.

[Rumble]

Other than visual satisfaction, what does this accomplish that cannot be done thru macros?

One benefit is that it does distribute property sets over multiple tokens; it means that a Weapon token might have the Weapon property set - so you don't have to create complex data storage elements (like an elaborate JSON object) for all your weapons; instead you create a property set, and then duplicate the token for different weapons. It's nice for anyone writing macros, especially!

So, consider a D&D 4th Ed weapon, say. It might have a property set like:

Code: Select all

Group
Type
Hands
Proficiency
Damage
Enhancement
CriticalDice
Notes
MundaneProperties
MagicProperties
Range
Load

while an Armor token might have:

Code: Select all

Type
Weight
ACBonus
ArmorPenalty
Enhancement
Power
MagicProperty

This is actually an interesting idea doable right now. If you establish a set of tokens for the basic items - admittedly, a tedious process - you can "equip" your characters by simply setting a property on the character listing the different tokens of that particular type that they own. So a character token might have properties like Armor, Weapon, Neck Slot, and in each of those, a simple string list of the tokens they "own."

So if there was a token called "Mace" - just your standard Mace - you would enter the string "Mace" in the Weapons property on the character token. Subsequently, any macros you write could just use getProperty() to retrieve the relevant values from the "item tokens" rather than having to parse more complex structures. After a while of acquiring goodies, a character's weapon inventory property might read:

Code: Select all

Weapons:Mace, Warhammer, Javelin, Flaming Longsword +1

In fact, more than one character can "own" the same token - a Flaming Longsword +1 is identical no matter who wields it, so once you create a single Flaming Longsword +1 token, you don't need to create more. In this way, they act more as libraries than "visual" elements, though - if you wanted a visual "drop" aspect, you just name them uniquely (like "Flaming Longsword +1 - Harann").

The idea fascinates me. It...could be a cool way to simplify framework writing for some games.


As far as the visual side of things - there are macro commands that can easily handle "giving" gear to other tokens, and "dropping" gear on the map. Put a couple macros on the gear itself like "loot" or "pick up" and you're done.

[kristof65]

And if you add some sort of "token owning another token" ability, it should make things even easier. Take, for example, a unique party item that the party shares. When one PC passes it to another PC, right now both PCs have to have their properties modified to adjust - no matter if you would use Rumble's proposal, or via a macro. With it as a token that can be passed, it's as simple as changing ownership.

[aliasmask]

You can also use tables for such things, which can include a picture. The first field in the table will be the index number (alias for the object). The second field will have all your relevant data (probably a json object) and you can assign an image to each table row.

So, if you have a base library of objects they can be put in to a table and then you can create a lib token to control/access all the items. I did something similar with my spell reference library. I made the first row (row 0) the index for all the spells and then assigned a spell to each row. If I want, I can add an image to represent each spell.

The only problem with doing that is that the data is static and can only be changed manually (not through macros). So, if you have a new item, you add it manually to your list and then to your index. For example:

row0 index: ["longsword +1","longsword +2"]
row1 {"size":"medium","price":2000.00,"type":"slashing"}
row2 {"size":"medium","price":4000.00,"type":"slashing"}

or whatever data you want to store.

Adding an item would be you editing the text in row0 (add to end of list) and adding a new row.

I think you're looking for a non-programming solution using tokens, but if you're going to manipulate the data, you'll have to do some programming to move the data around. So, having your data all in one spot is, I think, the best way to do it. This is something I have thought about for myself and it is quite a large task.

In regards to having tokens be the items, I think that will be somewhat of a logistical nightmare moving, collecting and organizing all those tokens. But it would be less programming.

[Rumble]

And if you add some sort of "token owning another token" ability, it should make things even easier. Take, for example, a unique party item that the party shares. When one PC passes it to another PC, right now both PCs have to have their properties modified to adjust - no matter if you would use Rumble's proposal, or via a macro. With it as a token that can be passed, it's as simple as changing ownership.

To be clear, as it stands now, the only way to do this is via macro (to actually link a token to another token). Adding in a formal built-in method would be a new feature (something for 1.4, I'm sure).

[Benz72]

The big picture here is game accessability. There are (I assume) plenty of people writing campaign files for D&D, but everything else is progressing in fits and starts. Having a programmer-lite solution, no matter how monotonous, may make more games accessible as a larger number of lower skill people can contribute to the process. The trick is getting the programming set up to allow it.

Thanks for your thoughts so far. Please keep them coming.

[Rumble]

The big picture here is game accessability. There are (I assume) plenty of people writing campaign files for D&D, but everything else is progressing in fits and starts. Having a programmer-lite solution, no matter how monotonous, may make more games accessible as a larger number of lower skill people can contribute to the process. The trick is getting the programming set up to allow it.

Thanks for your thoughts so far. Please keep them coming.

Here's the other problem - how much work does the user have to do vs. how much work is done by MapTool itself? Simple "this token owns that token" capability...doesn't really seem that useful in itself - you can just say that, now, and get pretty much the same effect.

It would seem (to me, at least) that there'd still be a whole lot that would have to be done by writing custom scripts to make it actually useful. Game accessibility doesn't really change, unless I'm misunderstanding the thrust of the idea.

[aliasmask]

The big picture here is game accessability. There are (I assume) plenty of people writing campaign files for D&D, but everything else is progressing in fits and starts. Having a programmer-lite solution, no matter how monotonous, may make more games accessible as a larger number of lower skill people can contribute to the process. The trick is getting the programming set up to allow it.

Thanks for your thoughts so far. Please keep them coming.

Here's the other problem - how much work does the user have to do vs. how much work is done by MapTool itself? Simple "this token owns that token" capability...doesn't really seem that useful in itself - you can just say that, now, and get pretty much the same effect.

It would seem (to me, at least) that there'd still be a whole lot that would have to be done by writing custom scripts to make it actually useful. Game accessibility doesn't really change, unless I'm misunderstanding the thrust of the idea.

I agree.

[kristof65]

How useful it is really depends on a lot of things - at it's basic, token owning another token could make a really simple inventory system that anyone could use without macros (depending, of course, where the tokens are 'stored'.)

I think where the real power comes in is in the ability of non-programmers to assist programmers in building frameworks.

FREX, I know there are frameworks out there that have inventory systems, etc, using macros and that there are individual macros for such. From what I can tell, though in order to customize those, I would have start modifying tables and the like to make them truly useful to me. And while I understand the concept of tables, library tokens, etc, the actual application of such is something that I don't really feel like tackling right now.

But if you build inventory systems where the items within in are added/deleted simply by adding item tokens to/from the framework, then it opens the system up to the non-programmer being able to contribute useful tokens that are more than just images. I could spend a full non-stop week attempting to fill a table with every item in the PHB and still not finish it, but together, the MT community could conceviably duplicate the entire PHB equipment list within a couple hours, with nothing more than 10-20 minutes work out of each of us.

As Rumble pointed out, it's partially doable now - but it depends on some programming to be super useful. But if we take a look at what tokens are, and how their uses could be expanded in future versions (say 1.4), it could grow pretty powerful even with nothing more than rudimentary programming.

FREX - its been pointed out that for replicating tabletop wargames like WFB, you need a way to group a set of tokens together to move them together. What if you tied this to "ownership" - IE, the leader token "owns" the other tokens, and they all move together? Or, as mentioned before, simple inventory systems - PCs carrying all their items, or on the GM side, chests full of treasure items.

If, at a minimum, one token owning another meant they moved together when either one was moved, it would still be useful.

[Rumble]

If, at a minimum, one token owning another meant they moved together when either one was moved, it would still be useful.

That, alone, would be a really cool thing. I hadn't thought of that. As for all that other stuff you just said I would wager that we can do it right now. The only problem, as mentioned, is that it leans heavily on scripting. However, if we can skip just a few steps of the programming side (even as simply as having a tab under Edit Token that provides a list of owned tokens), then overhead is decreased.

I'm all for the idea - I think abstract token ownership is a good one - with the recognition that (at least IMO) preserving MapTool's really excellent almost-pure-game-agnosticism will mean it will probably have to be not much more than abstract token-owns-token relationships.

[Azhrei]

The idea of a token owning another is discussed/covered in the Permissions thread which was an idea-gathering tool for the 1.4 series. You might check there if you're interested in seeing the use cases concerning _why_ it would be useful. (You'll have to search for the thread as I don't have handy.)

[abarrach]

This is my first post here, so I wanted to quickly thank the people who worked on RPTools for all the great work they've done, and to Rumble for the D&D4e framework he built on top.

Ok, now to the point... I am really interested in this idea of tokens owning tokens. My current D&D4e character is an Invoker, and one of his abilities is Summoning. The summoned creatures (angel in the case I'm thinking about) is not only controlled by the character, they also inherit some of the stats (e.g. Str, Wis, AC, Ref), and their HP is half the Invoker's HP.

Sure, when I summon my creature I can plop it's token on the field and adjust it's stats as needed, but I think it'd be even better if those stats updated automagically as my character's stats change (either by leveling up, or some other enhancement).