OLD Wolph42's 'Drop-in' Bag of MT Tricks OLD

[CoveredInFish]

Have you tried using a deferred macroLink (Wiki: execLink()) instead of using a pause?

[wolph42]

Have you tried using a deferred macroLink (Wiki: execLink()) instead of using a pause?

Hmm good point. Only problem is that im pretty bad working with it. Still haven't got the hang of it. Any examples oy there that I can use as reference?

[CoveredInFish]

You create a macro that does the stuff after the pause. Like this...

Code: Select all

[h: args = macro.args]
[h: id = json.get(args, "id")]
[h: switchToken(id)]
[h: moveToken(json.get(args, "x"), json.get(args, "y"), 1 )]
[h: goto(id)]

then you create a Wiki: macroLinkText() and use Wiki: execLink() to execute that link defered.

Code: Select all

[h:'<!--Teleports Starts A to B-->']

... snipped many lines of code ...

[Text = "Entering map: "+newMap]

[h: lnk = macroLinkText("moveToken@Lib:token", "none", json.set("", "x", NewX, "y", NewY, "id", currentTok), currentTok)]
[h: execLink(lnk,1)]

[abort(0)]
};{}] 
}]

Not tested.

[wolph42]

Thnx I'll give it a shot.

[jfrazierjr]

Your not on that map yet. Use swithmap first. Then find the 'to' token and get the coordinates. Then use switchfrommap. Done.(I hope....)

[wolph42]

Your not on that map yet. Use swithmap first. Then find the 'to' token and get the coordinates. Then use switchfrommap. Done.(I hope....)

Been there done that. Not working. I'll go for scalemans suggestion.
One other thing I noticed that moving 4 tokens at the same time gives a delay. How does your patch exactly work with four tokens moving at once? Cause if it runs for every token I think it's 'preferable' that it only runs once! This means more programming in the
Macro but I think that will speed things up. Your thoughts?

[jfrazierjr]

Your not on that map yet. Use swithmap first. Then find the 'to' token and get the coordinates. Then use switchfrommap. Done.(I hope....)

Been there done that. Not working. I'll go for scalemans suggestion.

Bummer.. thought that would have worked.

One other thing I noticed that moving 4 tokens at the same time gives a delay. How does your patch exactly work with four tokens moving at once? Cause if it runs for every token I think it's 'preferable' that it only runs once! This means more programming in the Macro but I think that will speed things up. Your thoughts?

Would be nice, but no, you can't do it. The macro is called for each token and I can't see any way to change it to do it once and have it still do that same type of thing.

[Azhrei]

The macro is called for each token and I can't see any way to change it to do it once and have it still do that same type of thing.

Well, it would be possible to define separate semantics between moving a single token and moving multiple tokens. Moving a single token calls that token's macro(s), but moving multiple tokens invokes a single macro on a Lib: token or something which is then passed the token ids of the tokens being moved.

(Hm, I wonder if that could be extended to handle facing as well? Then you could select multiple tokens and a macro could define how those tokens are rotated/moved when the facing is changed. This would allow tokens on hex grids to be rotated around an arbitrary center. Double-hm...)

[wolph42]

Would be nice, but no, you can't do it. The macro is called for each token and I can't see any way to change it to do it once and have it still do that same type of thing.

so... until you figured out what Az is talking about, the only thing the intermap macro needs to to is to keep count of selected tokens and just switch back to the original map until all selected token are moved (I hope). Thats easy to implement but rather inefficient as it runs through ALL loops for every single token. But it'll do for now.

(Hm, I won't if that could be extended to handle facing as well? Then you could select multiple tokens and a macro could define how those tokens are rotated/moved when the facing is changed. This would allow tokens on hex grids to be rotated around an arbitrary center. Double-hm...)

focus Az... 1.4 and world domination...FOCUS!!

[jfrazierjr]

The macro is called for each token and I can't see any way to change it to do it once and have it still do that same type of thing.

Well, it would be possible to define separate semantics between moving a single token and moving multiple tokens. Moving a single token calls that token's macro(s), but moving multiple tokens invokes a single macro on a Lib: token or something which is then passed the token ids of the tokens being moved.

Well.. I think perhaps in this case, I would branch in the code to run either macro a or macro b.

[wolph42]

You create a macro that does the stuff after the pause. Like this...
[snip]
Not tested.

Ok implemented it and I get a:

java.lang.NumberFormatException: For input string: "tokId" error executing expression tokId = json.get(args, "tokId").

any clue?!?
Here is the teleport function

Code: Select all

[h:'<!--Teleports Starts A to B-->']
[h, for(i,1,numInterPads+1), CODE:{
    [teleportStartName = "interPad " + i]
    [teleporterTriggered = movedOverToken(teleportStartName,lastPath)]
    [if(json.contains(teleporterTriggered,currentLocation)), CODE:{
        [Token(teleportStartName): newMap = pairedMap]
        [teleportEndName = "interPad " + i]
        
        [Token(teleportStartName):    offsetCentreX    = CurrentX - coordX]
        [Token(teleportStartName):    offsetCentreY     = CurrentY - coordY]
        
        [moveTokenToMap(currentTok, newMap, 0, 0, 0)]
        [setCurrentMap(newMap)]

        [Token(teleportEndName): endCentreX     = coordX]
        [Token(teleportEndName): endCentreY     = coordY]
        [NewX         = endCentreX + offsetCentreX]
        [NewY         = endCentreY + offsetCentreY]
        
        [h:'<!--The pause is necessary, or the new coords wont be set-->']
        [Text = "Entering map: "+newMap]
[h:'<!--this is what its all about-------------------------------------------------------------------------------------------------------------------------------------------------------------------->']
        [h: lnk = macroLinkText("moveToken@Lib:onTokenMove", "none", json.set("", "x", NewX, "y", NewY, "tokId", currentTok), currentTok)]
        [h: execLink(lnk,1)]
        
        [abort(0)]
    };{}] 
}] 

And here the deferred link, where the error is made:

Code: Select all

[h:'<!-- move token to teleport pad after map jump -->']

[h: args = macro.args]
[h: tokId = json.get(args, "tokId")]
[h: x = json.get(args, "x")]
[h: y = json.get(args, "y")]

[h: switchToken(tokId)]
[h: pause("args","tokId","x","y")]
[h: moveToken(x,y,1) ]
[h: goto(tokId)] 

The weird thing is that the pause function gives all the correct values...?!? So the tokenId IS set correctly, but somehow there still is an error generated

[wolph42]

in addition to the latter post, more stuff goes awry, this is meant for jfrazierjr:
The basic question is: 'what's wrong with this picture':

The attachment pause.jpg is no longer available

Some help: look at the last entry in the 'lastPath' and the 'currentLocation' which obviously should be the same!!!

So what did I do. I started reworking the cmpgn file to handle multiple token selection. To do this I basically ONLY handle the first token in multiple selection and abort the funtion for the rest of the call. To do this I use a counter that counts how many tokens are selected and as long as the counter != 0 it lowers the counter by 1 and then aborts ontokenmove. This works!!
However if the first token is not in the top left of the selection somehow lastpath and teleporttriggered take the lastpath of another token than the one selected.
e.g. four tokens created in this order 1,2,3,4 if I move these around ontokenmove will handle these tokens in the order 1,2,3,4. And thus with my multiple selection trick, it will only do 1 and aborts on 2 to 4. If I create the following token formation on the map
2 3
4 1
So the 1 is not in the top left --> the above path 'error' occurs. And obviously:

Code: Select all

[if(json.contains(teleporterTriggered,currentLocation)), CODE:{ 

gives false, meaning that although all four tokens are on the telpad, they are not teleported.

Any clue?!?

edit: i've attached the cmpn file, just move the four tokens on the pad and look at the pause result (there are four end paths, so you get four pop-ups, its the 2nd that counts) and the fact that the tokens aren't moved

[jfrazierjr]

Yea... don't do that.

here is the deal. The way the existing code works is it gets a lit of the selected tokens IN AN UNORDERED SET, meaning there is no implied ordering of who was selected first, last, etc. It then loops over each of those tokens and runs the onTokenMove macro.

Yea, it's a bummer. yea, there is probably a way around it, but no, I probably won't be dealing with this in 1.3(and hopefully in 1.4 there will be a better way.) This is one of those limitations I mentioned in the poll I guess. Now, I may take a look at this, but I just don't want you to get your hopes up. I am kind of limited in time for the next few weeks and have some other things I have to get to such as the owner only functions as well as a few more functions for token move that are "required". With that being said, I "might" add a secondary move function for use only when there are multiple tokens selected, but that depends on how much time I can squeeze out.

Your best bet in this case is to abort the macro if more than one token is being moved or have your players move each token individually or deal with the fact of having to constantly switch back and forth between the maps.

[wolph42]

IN AN UNORDERED SET

I guessed so much, but that still doesn't make any sense! no matter which token is selected in the onTokenMove THAT's the token for which you get the current location and the lastpath.

How it now works looks like it picks one of the token, starts onTokenMove, but for the lastpath it picks an enitrely different token while still in the same run?!? That's something that should not happen.

e.g.
1. select tokens a,b,c,d in formation
d c
a b
2. move the selected token
3. onTokenMove is triggered,
4. onTokenMove picks token 'a' first and runs through the code
5. getCurrentXY results in the XY of token 'a' (as it should) however lastPath picks the lastPath of another token (in this case 'd')?!?
6. onTokenMove picks token 'b' and runs through the code
etc.

the fact your patch handles them unordered, doesn't matter, it gives the wrong result for lastpath and triggered (at least so it seems)

[jfrazierjr]

Well.. I can take a look... but its not like I ever make a mistake Anyway, what if you add more tokens. does the coords all ways come out in the upper left corner? if so, it might be possible that the selection set is order in such a way as to "group" them into what amounts to a big box and UI boxes start at the top-left most pixel point. Also, are you using the path from marco.args or are you getting it individually? That could make a difference also.