Local states (Token)

[bobifle]

Like tokens have local properties that don't need to be defined at the campaign level, they could have local states that don't need to be defined at the campaign level.

I'm currently building a list of tokens, for dnd 5e, and I'm trying to make them as much as possible agnostic to the framework. And by framework, I mainly means those campaign defined variables like states, lights, campaign properties and so on... All the things you need a a cmpgn file for.

The objective is for my tokens to be drag and dropable on any framework, possibly a newly created cmpgn and still have most of their feature working.

So like people felt the need to have local token properties, tokens could have local states that you don't need to bother defining at the cmpgn level. Anyone else came up with that kind of issue ?

PS: speaking for myself, I would not need a user interface for it, a macro function setState(name, assetId) is just as good.

[Phergus]

Would these states have visual component like the current states?

[bobifle]

yep, that would be the idea.

If I'm not wrong, states have 3 majors differences with properties:

* they have only 2 possible values, 0 or 1
* they can have a visual component over the token
* they appear in the context menu along with all other states and are automatically set to 0 by the clear all states command

[Full Bleed]

It seem like a decent idea for making a more self-contained tokens that would have more framework cross-compatibility. But it also seems potentially inefficient/redundant. For example, the size of tokens would grow significantly, multiplied by the number of tokens, etc.

Not sure that's as big an issue today as it would have been when a good portion of the user base was using 32 bit java...

I think you'd need some way to, once the token is imported into a campaign file, have the option to transfer the state into the campaign state repository and remove the redundancy. And then, of course, if you exported the token again you'd need some way for it to know which states needed to be re-mounted back on to the token to maintain its dependency outside the framework.

Probably a lot more to this feature than meets the eye...

[Phergus]

Probably a lot more to this feature than meets the eye...

Yup. Imagine the size of a token with 20 or 30 state images attached to it. And every time someone drags it across a map that token has to be transferred across the network again. (This will be addressed in 2.0)

How do you deal with conflicts where two tokens are dropped in with internal states that have the same names but different images or clash with the image positioning?

Lot's of interface work to be done to support this idea.

@Bobifle - Can you give an example of what particular situation token-side states would address?

[bobifle]

@Bobifle - Can you give an example of what particular situation token-side states would address?

Inability to drop a token on a map and have its internal state work properly if not defined at the campaign level. Meaning I need to provide additional campaign file that a user cannot "source" above his own campaign. Not to mention that editing states manually with the gui is a painful process, while a search and replace in my macros does the trick otherwise.

How do you deal with conflicts where two tokens are dropped in with internal states that have the same names but different images or clash with the image positioning

It works like properties. there's no conflict, each token uses the assetid associated to its internal state.

If I'm not wrong, having multiple tokens referencing the same assetid should not yield multiple png/jpg tranfsert over the network. The client already cached a instance of the asset and will use it for each token state referencing that asset. No matter the method (current or my proposal) the same amount of binary image should transit over the network. But I may completely wrong on this, I don't know MT internals that well. Disk space ofc will be higher as states images would be stored in each token rptok file. But disk space is less an issue imo and we're speaking about a dozen of states with very small images, not a very big deal on modern PCs.

As for the interface changes, like local token properties, local states are only accessible from macros. GUI only users don't have access to local state and will stick to the campaign states.

And to think of it, lights could also have their own local token definition.

[Phergus]

@Bobifle - Can you give an example of what particular situation token-side states would address?

Inability to drop a token on a map and have its internal state work properly if not defined at the campaign level. Meaning I need to provide additional campaign file that a user cannot "source" above his own campaign.

That's a circular definition and not what I asked for. You've literally said that MT needs to add local states so that tokens with local states can be loaded into MT.

What problem is this solving? Give a specific example. What situation during a game session do you run into where local states would have made things easier? When and why would they be used instead of campaign defined ones?

Not to mention that editing states manually with the gui is a painful process, while a search and replace in my macros does the trick otherwise.

That's a separate issue. You don't add new and different functionality because the UI for the existing functionality is hard to use.

How do you deal with conflicts where two tokens are dropped in with internal states that have the same names but different images or clash with the image positioning

It works like properties. there's no conflict, each token uses the assetid associated to its internal state.

Missing the point. If you create a token with an local state of Pouncing and it's state image is blue cat. Someone else creates a token with a Pouncing local state but it uses a yellow spring. The user has a Pouncing state in the campaign that has a green triangle has included those two tokens. What is returned by State.Pouncing if used on one of those tokens? Which state is set by setState("Pouncing",1)? The local state or the campaign state. If the players or GM are presented with 3 different symbols that are all supposed to represent the same state, and possibly in 3 different locations, how are they supposed to know which is which?

As you don't want a GUI for it, how will users know what states are on a token so they can be used? Would these states show up on the right-click menu of a token?

In your discussion of frameworks, you suggest that macros on tokens aren't part of a framework but you want to have states on tokens that would presumably be read/set via campaign macros? Macros that would only be valid if those specific tokens were present.

[bobifle]

Alright, first my english may be failing me I apologize for my poor descriptions. But I think overall what I ask does make sense so bear with me :

I have this token that I want to display a certain icon when it is disabled. So one of its macro does the following:
setState("disabled", 1)

To which MT complains that there is no disabled state. I have to add it campaign wide. As soon as I do this (add the state campaign wide), my token is no more usable in any other campaign file and cannot be dragged in to let's say another campaign file I'm using with another group.

Another issue with adding it campaign wide is that the state will appear in the context menu for all tokens, including those for which the "disabled" state is not applicable.

To all your other questions, the answer is always :"it works like properties"

How would a campaign "pouncing" property be handled vs a local "pouncing" property ? I don't actually know the answer but the usual way for these scope issue is to favor the local setting. Like in most language, ppl should avoid naming different things with the same name on different scopes.

Users will know which states are available using the context menu, I'm assuming very few users would query avalaible states through the chat windows with macros (but hey, they could)

you suggest that macros on tokens aren't part of a framework but you want to have states on tokens that would presumably be read/set via campaign macros?

Not exactly, for instance, the dnd 5e framework does not know anything about the disabled state, that does not mean that my token macros won't know about it.

I really hope I'm making sense.

[Phergus]

It's just as likely my english failing me.

I'm going to try a different tack but first make sure I'm following the core of what you're proposing.

• You want to have tokens that have states defined on them complete with the corresponding images.
• These states would represent conditions for monsters/characters that can occur in the rules of a particular game.
• It sounds like you are proposing that different tokens could have differing subsets of states. State Anxious only applies to tokens Bob, Frank and Ernie so it wouldn't be seen on tokens Tom, Dick and Harry.
• To set these states on a given token you would use the contextual menu or setState() macro function.
• The goal is to make your tokens portable across frameworks. I have to assume you just mean frameworks for the same game system.

Is all that correct?

[bobifle]

Yes, that is all correct.

[aliasmask]

We would need to update how we update token data from server to client. Transferring all the token info per change would be daunting with those extra images.

Why not just save the image data when saving a token. Then when you drop the token in a new campaign, it adds those states. If the same state already exists, then no image update.

But at the same time, saved tokens shouldn't be transferring token states, imo. The token should be neutral when transferred across campaigns. In either case, saving all the state info on a token would be very confusing for the framework creator since it could have states he doesn't know about. It would just be an added image to token.

Speaking of which, I could get behind special effect images that appear below a token and outside the normal confines of the footprint. Add a forcefield to a token, highlight the base of a token in iso view... stuff like that.

[bobifle]

Speaking of which, I could get behind special effect images that appear below a token and outside the normal confines of the footprint. Add a forcefield to a token, highlight the base of a token in iso view... stuff like that.

That would solve almost everything, all we would be missing is a way for tokens to register contextual menu items

[aliasmask]

We would still treat them like states except they have different draw orders and can be drawn outside the footprint. The size and orientation can be controlled in the campaign properties of the "state" as with macroscript.

[bobifle]

I am sadness