Reciprocal "Clone" Tokens?

[growlly]

Though I'm still stuck on the Frames and Dialogs tutorial, I'm trying to press on with designing a relatively simple homebrew RPG in MapTool. I recently had the idea of using two different map scales--one "main map" that is large scale and smaller-scale "inset" maps for when players enter buildings. In other words, the main map would show the token standing on a building square while the player is moving around inside the building on the inset map. A challenge is that players would ideally have a copy of their token on each map, and the copies would need to have reciprocity (i.e., when one takes damage, the other takes damage) until the inset token is deleted. So, is it possible to have tokens with reciprocal clones on two maps at the same time? Would it be easier to have two maps running at the same time or two instances of MapTool open? Thanks.

[wolph42]

Though I'm still stuck on the Frames and Dialogs tutorial, I'm trying to press on with designing a relatively simple homebrew RPG in MapTool. I recently had the idea of using two different map scales--one "main map" that is large scale and smaller-scale "inset" maps for when players enter buildings. In other words, the main map would show the token standing on a building square while the player is moving around inside the building on the inset map. A challenge is that players would ideally have a copy of their token on each map, and the copies would need to have reciprocity (i.e., when one takes damage, the other takes damage) until the inset token is deleted. So, is it possible to have tokens with reciprocal clones on two maps at the same time? Would it be easier to have two maps running at the same time or two instances of MapTool open? Thanks.

ah you hit the touchy subject! The short one: no. A bit longer: hopefully in 1.4.
And the full answer:
this issue has been plagueing user for a long time, I too have the issue of multiple player tokens on different maps and not knowing which is 'recent' as every copy *is* unique. There are plans however to have this sorted out in 1.4, but no more then plans so far.
IRC though, aliasmask had some sort of players lib:token thingie that (again IRC) does something like what you want.
The point is is thats it is not possible to update a token if you not on the map of that token nor to access its data. The exception is a lib:token which is accessible throughout the entire campaign. So IRC AM created a system where the 'actual' player token was a lib:token and all its copies referred to that lib:token, so you had everything centralized and you could have copies of tokens on different maps without the worry of tracking their status and which one is most recent.
I don't know however whether that development was done and is working as i"ve never used it.

I have to say though, as its generic I should transfer it to the bag of tricks as I've done with ALL other generic drop-ins created for maptool. Until now I've never thought of that....but in this case I'm a bit weary as alias' code is usually a bit scary...

@AM: where is that post of you actually?

edit: ok I had a quick look and it *is* possible. On the attached test map I have a lib:Dragon and two tokens 'Dragon' on two different maps. As you can see they both refer to the lib:dragon. Its a bit tricky to setup but if you limit it to PC only, its doable.
With that however comes a drawback, cause if you want to change (e.g. HP) on an NPC you're gonna use Wiki: setProperty(), but if you're gonna change that value on a PC token, then you need Wiki: setLibProperty ()as you should write the change directly to the central lib. There are ways to deal with this, for one you could redefine the setProperty function which checks whether the token in question is a PC or NPC and executes the right set accordingly.
So you *can* do this, but its a bit of a hassle.
Retrieving properties is simple as you can always directly refer to the (N)PC token to get the correct value.

[aliasmask]

Nah, I just talked about it. It was just too much of an overhaul to really tackle, but it's mechanically possible. You would store things like states statuses in a variable rather than relying on the current token. I thought it was wolph and CiF who made some game board where you moved one token and it moved on the other map as well.

In your case growlly, I would just have a macro do a copyToken when you're ready to move back to other map. The other token would just be a placeholder. But if you want something that updated both when the other is updated, that's a little tricky depending on how fancy you want to be.

For example, let's say you have a token named Bob on Map1, and Bob on Map2. You would need to tell Bob of Map1 to update Bob of Map2 and visa versa. Getting and setting data of tokens on different maps requires you to change maps or do a really complicated copy, delete, paste of the tokens. Changing maps is actually doable, it just causes your screen to flicker in most cases.

I could go on about how to do it, but really the best way is to just copy/paste the most recent tokens when you change maps. If you're trying to manipulate and sync two tokens things get complicated fast.

@wolph - I actually do have lib:player_playerName tokens generated and they hold player information. I use it mainly for chat purposes, but putting all the token info on there would be doable. I have them generated at start up which causes some problems (for the gm), so I halfway made a login procedure to avoid start up issues. But that's on the back burner for now.

[wolph42]

where you moved one token and it moved on the other map as well.

yup, its in the bag of tricks and its called shadow token, however not on a different maptool-map, it only works on one maptool-map, but then you can have two seperate maps on the maptool-map where you apply this feature. I did look into 'intermap sync' but as there is no light/proper way to know who is on which map its not feasible to do so. If you could know who is where, you could send the move update to the player who is on that map and if no one is on that map, no update is required.

@wolph - I actually do have lib:player_playerName tokens generated and they hold player information. I use it mainly for chat purposes, but putting all the token info on there would be doable. I have them generated at start up which causes some problems (for the gm), so I halfway made a login procedure to avoid start up issues. But that's on the back burner for now.

yeah I know but I can't find it.

It turns out however that its not really that hard to use a 'central' token and have placeholdertokens on other maps.
What I roughly did:
lib:tokenName contains properties

Code: Select all

Strength
Toughness 
etc.

the placeholder 'tokenName' contains properties as follows:

Code: Select all

Strength: {getLibProperty("Strength", "lib:"+token.name)}
Toughness: etc.

that works quite well. But have a look at the example campaign to see for yourself.

States indeed is a bit tricky, but I can think of a relatively solution for that as well: as you say store states on the lib, and when you hover over the token one property checks whether the local states have changed in regard to the central state and if so then it runs a 'stateUpdate' macro.

[Jagged]

I thought it was wolph and CiF who made some game board where you moved one token and it moved on the other map as well.

I did it here in my Bonded Warehouse Map. There's a code snippet too, although this example is moving shadow tokens on different parts of the same map.

[aliasmask]

I thought it was wolph and CiF who made some game board where you moved one token and it moved on the other map as well.

I did it here in my Bonded Warehouse Map. There's a code snippet too, although this example is moving shadow tokens on different parts of the same map.

Ah, yeah, that was you and not CiF (haven't heard from him in awhile). I only read the posts and didn't realize it was only for the same map. Makes sense because you don't have to do map flipping or moving token to current and then back to other map at new x,y. Although, I think it would pretty much ignore trying to draw it on current map if it no longer existed on current by the end of the macro. All the draw token stuff is done last in a separate process.

[wolph42]

I thought it was wolph and CiF who made some game board where you moved one token and it moved on the other map as well.

I did it here in my Bonded Warehouse Map. There's a code snippet too, although this example is moving shadow tokens on different parts of the same map.

funny, so we both undertook the same project, bit ineffecient, but that happens more.

[growlly]

In your case growlly, I would just have a macro do a copyToken when you're ready to move back to other map. The other token would just be a placeholder. But if you want something that updated both when the other is updated, that's a little tricky depending on how fancy you want to be.

For example, let's say you have a token named Bob on Map1, and Bob on Map2. You would need to tell Bob of Map1 to update Bob of Map2 and visa versa. Getting and setting data of tokens on different maps requires you to change maps or do a really complicated copy, delete, paste of the tokens. Changing maps is actually doable, it just causes your screen to flicker in most cases.

I could go on about how to do it, but really the best way is to just copy/paste the most recent tokens when you change maps. If you're trying to manipulate and sync two tokens things get complicated fast.

Based on reading this thread so far, I think this is what I'll do. I actually did watch wolph's Shadow Token video on YouTube, but in my case they absolutely have to be on different maps because the maps are on different units-per-square scales. My main concern is that when the player does stuff with one token (takes damage, uses action points, uses ammunition), he would have to remember to edit his other token to match it. But with a copytoken macro, at least all he'd have to do is click that button and delete the one on the other map. Too bad there's not a "replace token" or "overwrite token" when you make a copy. I looked at the copyToken wiki page. Is there an easy way to have it copy the token where the macro button resides and prompt the user for which map to copy it to from a list of available maps?

<thinking out loud>
I wonder if a solution for the future would be to have a macro that assigns a "ReciprocityID" where you select a receiving token. Then another "UpdateClone" macro overwrites the ID'd receiving token with the source token (or rather, updates everything except the ReciprocityID. You could then have the tokens update each other by having the second token ID and update the first one.
</thinking>

ah you hit the touchy subject! The short one: no. A bit longer: hopefully in 1.4.
And the full answer:
this issue has been plagueing user for a long time, I too have the issue of multiple player tokens on different maps and not knowing which is 'recent' as every copy *is* unique.

Ha, well sometimes it's good to hit a touchy subject! I wonder how the token IDs are generated. Are they just random numbers or could they be assigned to some kind of time code? And could you update the ID with a new timecode when something on the token changes? Just thinking out loud again.

[aliasmask]

What function does the token on the non-current map play? In my games, when dealing with area maps and keeping track of player progress I either have a party token or I use macros with moveTokenToMap. When doing that, I post a link to chat showing (and linking) the coordinates it's moving from to the coordinates it's moving to on the new map. When they want to go back, they could click the link or you could just have a macro that say go back to travel map having saved the coordinates.

[growlly]

What function does the token on the non-current map play?

I kind of vaguely alluded in the first post, but here's more detail on my vision:
My homebrew game is a modern warfare setting. The "main map" is the typical map where most stuff happens. The scale is large: 1 square = 30 feet. This lets combat occur over longer ranges, and it means that I can just define cover/defense bonuses based on the square the token is on rather than having to place individual pieces of cover for characters to use. Generally, the maps don't need to be very detailed because of the scale, and I want to be able to make maps quickly.

The only downside to this from a game design standpoint is that combat inside of buildings would be uninteresting. For example, imagine players entering a 60' x 90' building and fighting enemies inside. On the main map, it would be just a 2 x 3 gray box with similar cover values on each square. My solution was to use a separate "inset map" for building interiors. On the inset map, you have to hide behind cover pieces rather than stand on top of them. All the rest of rules are the same, but the scale reduces to 1 square = 5 feet.

So why did I want reciprocating clones instead of just moving the tokens? Hypothetically, players could enter a building, shoot at an enemy outside the building, and shoot at an enemy inside the building. Shooting outside the building would be done on the main map, and shooting inside would be done in the inset.

I suppose a simpler alternative would be to make the entire map on the small scale and come up with a way to handle broad "stand in this area" cover for outdoor areas and only do individual pieces of "you have to hide behind this" cover indoors. Hmmm...

[aliasmask]

Have you seen this. I've done something similar for large city maps. I'll have an overview of map and for specific areas I will have a more detailed map. In fact, I'm doing that for my next game. The PCs are intended to go to a church for a battle inside, but able to navigate the city map to get there. Once there, they zoom in.