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

[wolph42]

Im using it from macro.arts how can i get the individual?

[CoveredInFish]

hmmm ... macro.arts.

That is a nice typo.

[wolph42]

@abbreviated dutch cleaning agent: is it possible that you've missed this post?

[jfrazierjr]

Ok.. so what if instead of the java code doing the whole "if its one token do this, if it's a bunch of tokens do this", perhaps the shortest solution is to add an additional function that runs after all of the onTokenMove have fired. onTokenMoveComplete. In your onTokenMove, you could set some variables on Lib token (such as the map(s) to move to). Then after all the tokens have moved, the onTokenMoveComplete would change maps or something like that....

[CoveredInFish]

No. I didnt missed it but I hadnt the time to delve deep into it to find the error. Plus I had hoped you found something already since you seemed to progress anyway.

Have you checked the content of macro.args? (of course you have)

Does the error only happen with the token id? If that would be it you could try using currentToken() since the macroLink should set the correct token context.

Otherwise I have no clue yet.


EDIT: the answer to the question that reminded me of one of the greatest books in time ("Sun Tzu - the art of macro") is: use Wiki: getLastPath()

[wolph42]

Ok.. so what if instead of the java code doing the whole "if its one token do this, if it's a bunch of tokens do this", perhaps the shortest solution is to add an additional function that runs after all of the onTokenMove have fired. onTokenMoveComplete. In your onTokenMove, you could set some variables on Lib token (such as the map(s) to move to). Then after all the tokens have moved, the onTokenMoveComplete would change maps or something like that....

I'm not sure thats necessary, I'm still working on CIF's suggestion in parallel to handling multiple tokens. If that works such a java code woulnd't be necessary. However up to now I haven't worked on it (as I said in parallel) as I was waiting for an answer, which I just got, so gonna check that out.

What is necessary is some way to deal with multiple tokens in general. Maybe you could just create another patch with onMoveMultipleTokens or just onMoveTokens (though that might be too subtle). And fire one or the other depending on the selection. On the other hand if you could just make the current patch work in such a way that the lastpath and ontriggered contain actually the values of the selected token and not some other, that would likely already be enough.

You mentioned earlier

Also, are you using the path from marco.args or are you getting it individually? That could make a difference also.

I'm using macro.args. What do you mean with 'are you getting it individually', how do you do that?
Edit: ah I just read the post of CIF about use lastpath(), that's probably what you mean?

@CIF, I'll try some stuff you mentioned.

Edit2: CIF's answer helped, this might solve the problem, need to dig further to see where it leads now:

Pause.jpg (58.87 KiB) Viewed 3724 times

Any clue why they're different?

So to keep on rambling: I think the best final solution is two macros: onTokenMove and onTokensMove the first you already got and works, this macro handles ALL moves individually. The second handles multiple tokens as one group and does one run.

Edit3:

Does the error only happen with the token id? If that would be it you could try using currentToken() since the macroLink should set the correct token context.

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

[wolph42]

No. I didnt missed it but I hadnt the time to delve deep into it to find the error. Plus I had hoped you found something already since you seemed to progress anyway.
Have you checked the content of macro.args? (of course you have)
Does the error only happen with the token id? If that would be it you could try using currentToken() since the macroLink should set the correct token context.
Otherwise I have no clue yet.
EDIT: the answer to the question that reminded me of one of the greatest books in time ("Sun Tzu - the art of macro") is: use Wiki: getLastPath()

... the macro handling this part was called moveToken...
At one point I got into an infinite loop and then stuff starting to dawn...

it works!

[CoveredInFish]

So you solved it?

I made a mini test setup that worked fine. (i just tested if calling deferred is working the way i expected it to!)

Code: Select all

@@moveToken
@PROPS@ autoExecute=true ; color=default ; fontColor=black ; group= ; includeLabel=false ; sortBy=0 ; index=1 ; fontSize=1.00em ; minWidth= ; playerEditable=false ; maxWidth= ; tooltip= ; applyToSelected=false ; 
[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: moveToken(x,y,1) ]
[h: goto(tokId)] 

@@onTokenMove
@PROPS@ autoExecute=true ; color=default ; fontColor=black ; group= ; includeLabel=false ; sortBy=0 ; index=2 ; fontSize=1.00em ; minWidth= ; playerEditable=false ; maxWidth= ; tooltip= ; applyToSelected=false ; 
[h: currentTok = currentToken()]
[h: lnk = macroLinkText("moveToken@Lib:move", "none", json.set("", "x", 0, "y", 0, "tokId", currentTok), currentTok)]
[h: execLink(lnk,1)]
 

using moveToken as macro name shouldnt be a problem unless you make it a UDF

[wolph42]

Yes I solved it. I've got everything working and I was also able to remove the deferred link cause later on I figured that "moveTokenToMap" also takes an X and Y for the new map should have thouhgt of that earlier.
So now
- it runs only once! and not for every selected token
- it can teleport multiple token to a new map ONTO the teleportpad in the right order

HOWEVER

funky stuff is hapn'n... sometimes!?!:
- when the tokens are map-transported a copy of the remaining three is left behind on a seeminly random spot on the map
- the tokens do not arrive on the pad but next to it
and sometimes everything works perfectly... it looks like if you play with them for a while, the funky stuff stops.

Also the moveTokentoMap works with cell-units, while the rest works with grid-units, meaning a /50 conversion was necessary which obviously will not work on other grids... but thats a worry for later.

btw, I just looked at your code, you do know that your making exactly the same mistake as I did... you have a macro moveToken, calling the function moveToken... this is a bomb waiting to happen

[jfrazierjr]

funky stuff is hapn'n... sometimes!?!:
- when the tokens are map-transported a copy of the remaining three is left behind on a seeminly random spot on the map
- the tokens do not arrive on the pad but next to it
and sometimes everything works perfectly... it looks like if you play with them for a while, the funky stuff stops.

Did you try what I suggested with say a 3x3 set of tokens? It appears as if the Path sent into the function is not for a single token, but for the entire token drag, which would always get a bounding box of the upper left corner of the combined tokens. The way the Path is pulled, it is calculated BEFORE the list of tokens is looped over, so it gets the path for the entire movement set of tokens. I would expect that the coords would always been the smallest box that would contain all of the selected tokens, so if you did a non square selection of tokens, it would probably report what would appear to be a really odd number in marco.args

So, basically, if multiple tokens, don't use macro.args, use getLastPath() with a specific token.

[CoveredInFish]

using moveToken as macro name shouldnt be a problem unless you make it a UDF

I made the same mistake since i copied most of the code from here. Anyway I think that aslong I dont use some defineFunction stuff everything should be fine. Give that naming macros the same as functions is a bad practice (unless you want them to be that function anyway).

[wolph42]

funky stuff is hapn'n... sometimes!?!:
- when the tokens are map-transported a copy of the remaining three is left behind on a seeminly random spot on the map
- the tokens do not arrive on the pad but next to it
and sometimes everything works perfectly... it looks like if you play with them for a while, the funky stuff stops.

Did you try what I suggested with say a 3x3 set of tokens? It appears as if the Path sent into the function is not for a single token, but for the entire token drag, which would always get a bounding box of the upper left corner of the combined tokens. The way the Path is pulled, it is calculated BEFORE the list of tokens is looped over, so it gets the path for the entire movement set of tokens. I would expect that the coords would always been the smallest box that would contain all of the selected tokens, so if you did a non square selection of tokens, it would probably report what would appear to be a really odd number in marco.args

So, basically, if multiple tokens, don't use macro.args, use getLastPath() with a specific token.

I did, which resulted in the fact that it works...however with sometimes funky stuff appearing. I only use the getLastPath of one of the tokens (doesn't really matter which one) to check if its on the pad --> triggered. If so then I transport all selected tokens to the new pad and I use currentXY for every selected token to move them INDIVIDUALLY to the new map. This should work and this does work. However sometimes its doesn't and this is not formation related or lastpath related as I can move the same formation to the same spot twice in a row under the same conditions and 1 time it works and 1 time it does strange stuff as described before.
To be honest, because of two identical situations ending up different, I think its a bug in your patch...

Edit: to break it down:
I use foreach(token,selectedtokens)
wherein I calculate the offset the token has in respect to the starting teleport pad
then I get the coordinates of the landing pad (on the other map) and add that to the offset, which results in coordinates that are on the exactly (relative) same spot as the starting pad.
Then I just use moveTokenToMap with the new map name and the just calculated coordinates.

This I do for every token and when that's finished I use setCurrentMap(...) to switch map.

If I do this outside of onTokenMove, it should work without the funky stuff appearing (though I haven't tested it)

@CIF, and I made a UDF of it...

[wolph42]

ok, I made a simple test setup for bugtracking. I've removed all surplus code so its easy to see whats happn'n.

It actually repeats now, so its a constant bug!

What to do:
1. move one token onto the pad, it will 'dissapear' cause it has been moved to the testmap. Goto test map, drop it onto the pad and it will be moved back.
2. now move all four token onto the pad and you will notice that a bit to the bottom right 3 (stacked) tokens appeared. If you try to move one you will get a

java error

ava.lang.NullPointerException
at net.rptools.maptool.client.ui.zone.ZoneRenderer.commitMoveSelectionSet(ZoneRenderer.java:433)
at net.rptools.maptool.client.tool.PointerTool.stopTokenDrag(PointerTool.java:201)
at net.rptools.maptool.client.tool.PointerTool.mouseReleased(PointerTool.java:528)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at net.rptools.maptool.client.swing.MapToolEventQueue.dispatchEvent(MapToolEventQueue.java:24)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

. If you move to the test map you will notice that the 4 tokens have arrived correctly. So for some reason the remaining three tokens are 'locked' to the currentmap when transported...

[jfrazierjr]

Argh... your making me do to much work!!!

I did not get the java error, but the problem is that the tokens are moved to the new map, and then in the next loop for the token, they are moved right back.

Here is how it works now in the java source(pseudo code boiled down a lot):

Code: Select all

foreach token in selectionlist

    moveTheTokenOnTheMap() // this is the internal java stuff that 
                                             // happens to move a token and  
                                             // send the updates to the clients
                                             // it also sets up the token's lastPath
                                             // so it can be reverted later
    if isToken && isVisible
         error = onTokenMove(token)
    end if

    If error 
         revertLastMove()
    end if
end for loop

So, anything you do to multiple tokens is going to be screwy if you are doing moves and such based on the selection. If I change it to add a onMoveMultipleTokens() function, I can check the selection count before calling onTokenMove(and not do that) and then after the foreach loop call the "new" function. Then I would have to loop back over each token IF false was returned (so they could be "put back" to their previous location)

How does that sound? I will create a NEW selection list so as to filter out tokens of specific kinds (such as those that are not visible and not tokens(ie, stamps) and will likely pass the "new" selection set into the onMoveMultipleTokens() function. There, does that make you happy now?

[wolph42]

There, does that make you happy now?