copyToken - how to get around property assignment limitation

[Azhrei]

Revisiting this... in recent changes it appears you can load the Updates parameter of the Wiki: copyToken() and have it run a macro! Unfortunately I sure can't get it to work...

You are calling Wiki: currentToken() in the first macro and storing it in m1args. That means when the first macro is executed, the active token will be whichever was active for the macro and it will still be the same when Wiki: copyToken() is executed and m1args is passed to the second macro. So I suggest you leave out the "tToken" field from m1args since inside the macro Wiki: currentToken() will already return the correct (i.e. newly created) token.

You're also using Wiki: setCurrentMap() which has some known problems that I discussed recently in another post (I probably didn't update the wiki though, so I need to do that). In this specific case it looks like you're not modifying any tokens after calling Wiki: setCurrentMap() and you then switch back to another map, so you should be fine. But in general you should avoid Wiki: setCurrentMap() and use other functions like Wiki: getInfo().

[lmarkus001]

You are calling Wiki: currentToken() in the first macro and storing it in m1args. That means when the first macro is executed, the active token will be whichever was active for the macro and it will still be the same when Wiki: copyToken() is executed and m1args is passed to the second macro. So I suggest you leave out the "tToken" field from m1args since inside the macro Wiki: currentToken() will already return the correct (i.e. newly created) token.

You're also using Wiki: setCurrentMap() which has some known problems that I discussed recently in another post (I probably didn't update the wiki though, so I need to do that). In this specific case it looks like you're not modifying any tokens after calling Wiki: setCurrentMap() and you then switch back to another map, so you should be fine. But in general you should avoid Wiki: setCurrentMap() and use other functions like Wiki: getInfo().

No token is selected when I run the macro. In my last incarnation I added the currentToken() in hopes that it would capture the ID of the copied token since the sub-macro was not making any changes to properties ( I was hoping to pass it the copyID and get it working ). So the code fails with or without the tToken info.

Wiki: getInfo() does not appear to yield token information (just map, client, etc.). The setCurrentMap is used to get a list of token names, it is set then returned, then an input happens, then the copy occurs.

@alliasmask
Your idea is ok, but it is far less "masses" friendly. The simplicity of dropping a populated critter token on a map is a more important functionality.

[lmarkus001]

Ok enough time spent on this. Thanks everyone for your input! I yield and will just have the user run a macro after copying. Wiki: copyToken() has always been persnickety and is not worth my time

[Azhrei]

No token is selected when I run the macro. In my last incarnation I added the currentToken() in hopes that it would capture the ID of the copied token since the sub-macro was not making any changes to properties ( I was hoping to pass it the copyID and get it working ). So the code fails with or without the tToken info.

Edit: this code didn't work. It should have, but it didn't update the HP property. I'm looking into it.

Um, here's an example -- I was trying to avoid this because I'm not a macro expert and I'll likely introduce stupid errors!

copyToken Test - main macro

I've left out the [h:] options so I can show what the result looks like in the chat log. For this to work, you must have a token named "Osuald" on the current map and you must have a macro named Testing on the Campaign panel (it's in the next spoiler).

Code: Select all

[ original = "Osuald" ]
[ posX = 1 ]
[ someMacroName = "Testing@Campaign" ]
[ m1args = "junk" ]
<br>
[ updates = "{
  name: '[r: original + posX][h, macro(someMacroName): m1args]',
  x: '[r: posX][h: posX = posX + 1]'
}" ]
<br>
[ copyToken(original, 4, "", updates) ] 

Testing@Campaign

Code: Select all

[input("dummy||Testing")]
[ HP = 42 ] 

Yeah, pretty wimpy. But demonstrative, which is what I was going for.

Here's what the screen looks like at various points during its execution.

Prior to beginning

Before.png (112.71 KiB) Viewed 567 times

During the creation of the first token

During #1.png (145.25 KiB) Viewed 567 times

During the creation of the second token

During #2.png (150.32 KiB) Viewed 567 times

After the copy is complete

After.png (91.67 KiB) Viewed 567 times

What the chat window looks like when complete

Chat window when done.png (27.94 KiB) Viewed 567 times

Hope that helps!

Wiki: getInfo() does not appear to yield token information (just map, client, etc.). The setCurrentMap is used to get a list of token names, it is set then returned, then an input happens, then the copy occurs.

Yeah, my bad. I thought it did but I just went and looked a the "map" type and it does not include a list of tokens on that map. In addition, the Wiki: getTokens() function doesn't have a parameter that lets you grab tokens from a specific map either. So your technique is the only one I can think of that works. Sigh.

[Azhrei]

Forget it. I can't make this work either.

I can get it to copy tokens, but not run the macro with the correct token context. Or I can get it to do the token context, but then the changes to the token are delayed so the properties don't change values.

From looking at the code it appears that while running a macro is possible, there are no hooks to set the token context in a way that doesn't cause problems somewhere else.

I'm going to update the wiki and take out the note about the token context. My apologies, Lindsay, for making you waste your time.

[MikeKozar]

I'm not sure if I'm missing what we're trying to accomplish, but here is some code that is working for me...

Here is the initial copy:

Code: Select all

[ original = "Osuald" ]
[ posX = 1 ]
<br>
[ updates = "{
  name: '[r: original + posX]',
  x: '[r: posX = posX + 1]',
 delta=1
}" ]
<br>
[ newDudes = copyToken(original, 4,"",updates) ] 
[foreach(Dude,newDudes), CODE:{
	[macro("update@Lib:Matrix"): Dude]
	}]

...and here we set the HP. I made it random, just to make sure it is really firing four different times...

Code: Select all

[ switchToken(macro.args)]
[input("dummy||Testing|LABEL")]
[ HP = 1d42 ] 

It is less elegant then embedding the macro, but it does kick out four new Osualds on demand.

[lmarkus001]

Thanks for following up Azrhei!

@MikeKozar
Thanks for sharing. Yeah I actually use copyToken() and Wiki: execLink() -deferred with some success. You may want to look into using the deferred option of execLink as it will execute the linked macro after the current macro runs, mostly, sorta, with luck

I have various subMacros that I reuse a lot (things to update states and bars, modify various data sets, etc.) that I just wanted to be able to call in the deferred macro call. But certain things just don't work in a deferred call after a copyToken (specifically state/bar changes).

In practice, it is not onerous for the user to run two macros. The first they are selecting what type+quantity+location of token to bring to the map, the second they are choosing to apply modifications. It would be smoother as a single operation but I can live with it

[aliasmask]

But certain things just don't work in a deferred call after a copyToken (specifically state/bar changes).

Ah, yeah, that is a problem. Now that there is a clock we can access, maybe we can build in a delay for the deferred call so the copied tokens complete before execution. I have an animation example, but that could probably be used as a base. Basically, the code I want to execute waits until the time is up and then executes. Deferred calls calling deferred calls. You can find the campaign example here: http://forums.rptools.net/viewtopic.php?f=20&t=17377

[Azhrei]

We're not worried about this for 1.3 as 1.4 will "have an entirely new approach" (it was invented at the Dastrom Institute ).

Since the delayed actions are inside the MapTool code, about all that can be done from the MTscripter's point of view is to use Wiki: macroLink().

[MikeKozar]

@MikeKozar
Thanks for sharing. Yeah I actually use copyToken() and Wiki: execLink() -deferred with some success. You may want to look into using the deferred option of execLink as it will execute the linked macro after the current macro runs, mostly, sorta, with luck

My framework uses it deferred, certainly. However, this happens to correctly assign properties to a new token without deferment. Unintentional; I was coding late at night and submitted once it started working. Until you pointed it out, I didn't realize it wasn't being deferred. I wonder why it works.

[aliasmask]

Speaking of deferred execution... I'm noticing a different, uh... process(?). Before, a macro would run and contain a deferred link. Once the macro completed, then the deferred link would execute. I'm not seeing that now. For my debugger to work properly the deferred link should wait until the macro completes.

edit: I just ran a little test and it seems to be working correctly in my test. I'll take a look at my code and see if I can sort it out.