Tokens owning tokens

[Azhrei]

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).

That's not the expected use of the "tokens owning tokens" feature, though.

What you want can be done with a single macro. Attach said macro to your summoned creature. When you drop the token on the map, execute the macro. Have the macro prompt you to indicate which token is the one it should be linked to (or just default it to you token's name). Now the macro can read the stats off of your token and adjust them on the summoned creature's token.

I have a macro that adds the "Fiendish" template to a creature by updating its stats and modifying a few key properties. Your macro would be doing essentially the same thing.

[TyeJae]

I actually wrote a block of code that allows a player to look in his inventory and drop items to the map, however, I just have a generic image that is dropped to the map, but the name will be whatever name of the item you dropped. Then other players can pick those items up and it goes into their inventory.

I posted it a little over a month ago. I don't know if you could modify it to your liking, but here is the link... Here it is

[Alhazred]

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.

Yeah, this was the first thing I did WAY back when I established my library framework for our 4e campaign. Actually I made a token for each race, class, and most types of gear. Each one has its own custom property list. The character tokens simply have a property for each slot that lets you specify which one of these tokens is the equipment in that slot (if any). Then there are macros for switching each slot (well, some of them at least, never did get them all). I also made a 'gear' property that lists all the gear that PC has, so when they go to equip they just see what items they own that they can switch. If they acquire more gear then they can get the big old list of everything and add it to gear.

In general this works pretty well. The only real issue is the amount of maintenance. Its not bad but if an item doesn't show up in any token then one has to be created by the DM. Its usually a matter of just copy and make a few minor property edits but it can be tedious at times. The final downside is you end up with a LOT of tokens. My library token map has several 100 tokens on it. I'm not sure that's a big deal if you keep them organized, but it is a bit of clutter.

Another advantage is that I can also have macros attached to gear and allow those to be fired off, so if a player wants to use a power of their magic item the macro can be ON the item (and they can quickly make a character macro that calls it). This works pretty well overall.

[neofax]

This is where a actual database would come in handy. However, you could build a pseudo one from others example. Place JSON arrays inside the Table function. So, you could have a Class JSON that holds Starting HP, Ability bonuses, Reflex/Will/Save bonuses and such and then the actual tokens pull their info from these JSON's inside the table. You could use it for powers, clases, races, equipment... basically whatever and you could build one atop another so if a weapon has a power, the one JSON would call the other. It is a write once use anywhere scenario and t should be easily maintainable. So if the developer were to add a new idea (Pool points anyone?) just tack that bit inside the JSON.

[Alhazred]

This is where a actual database would come in handy. However, you could build a pseudo one from others example. Place JSON arrays inside the Table function. So, you could have a Class JSON that holds Starting HP, Ability bonuses, Reflex/Will/Save bonuses and such and then the actual tokens pull their info from these JSON's inside the table. You could use it for powers, clases, races, equipment... basically whatever and you could build one atop another so if a weapon has a power, the one JSON would call the other. It is a write once use anywhere scenario and t should be easily maintainable. So if the developer were to add a new idea (Pool points anyone?) just tack that bit inside the JSON.

Yeah, I looked into that. I have a couple reasons for favoring the implementation I used. The main one is its pretty modular. Each token represents a thing of its type (property set) and it can encapsulate all the logic to return those values (so the properties can change, be made into Jason or put into a table for that matter). I can drop a new version of a token onto the library and replace the old one, I can go back to an older version if the newer one doesn't work, etc.

Tables work OK and probably can do a good bit with them, and maybe someone can come up with a particularly elegant implementation of that too. Of course you can also take the 3rd approach which would be say an 'armors' library token that contains basically a table in Json. There really are a lot of ways to slice it and dice it. The main consideration I have is SPEED. Json eats stack fast and gets way slow. By using straight linear properties on tokens the performance is way better. Maptool these days really runs a lot of macro code VERY slowly unfortunately.

One thing that would make a real difference would be allowing tables to be defined with multiple columns and a built-in API that let you treat them as mini-databases. For that matter if you could drop in a JDBC driver or JDO driver and store tables in a database that would really move things forward a lot in that direction. Then it would be easy to use existing database editing tools to get the data INTO Maptool, which is currently a hairy problem. I have perl code to mine the Compendium for 4e but there is no easy way to get that data into Maptool. It currently requires either manufacturing tokens in perl or brain surgery on a campaign file to insert it into a table (and then its still only got one column per table...).