Bug with sendToBack()

[jfrazierjr]

OK.. just so that every understands what the "problem" is (though it's really as designed), here is what is happening. In code prior to somewhere around b58 or so(+- a build or 3) EVERY single macro command that updated a token had an internal (as in inside the java code) call to a method called putToken().

This putToken method sends the updated copy of the token to the server who then sends the updated token back out to all clients. This worked fine when there were very few properties macro functions, and only "global" macros back in the day (ie, prior to around b35-b48 or so when a ton of macro stuff was changed/added) and caused little problem. So, EVERY time you updated a token with a macro function, the token was copied and replaced by the new copy. If you update 10 properties, thats 10 round trips to the server and all clients.

Trevor made some changes to many of the macro functions somewhere in the mid to late b50's( or so) and removed the call to putToken() and made a call after the macro had executed all of it's functions. This had multiple benefits: 1) reduced network traffic, 2) more responsive since the client machines are not constantly getting updates, 3) abort() will work correctly in most cases. In any event, whenever Trevor made that change, some of the macro functions either were missed by him, someone added a new macro function after the fact and did not know to remove the call to to putToken(), or it was left in on purpose for some specific functions because it made sense at the time.

Now... my question is, why are you calling sendToBack(). To me, it does not make sense in this context. Changing a token to the object layer seems to be better to me(unless I missed it and you are doing that and then sendToBack() to get a monster/player token above a background item)

[Raoden]

Now... my question is, why are you calling sendToBack(). To me, it does not make sense in this context. Changing a token to the object layer seems to be better to me(unless I missed it and you are doing that and then sendToBack() to get a monster/player token above a background item)

I can see reasons to want to use sendToBack() instead of move-to-Object-layer on a dead token. Mostly so that it can still be targeted by e.g. Raise Dead spell macros.

[jfrazierjr]

Now... my question is, why are you calling sendToBack(). To me, it does not make sense in this context. Changing a token to the object layer seems to be better to me(unless I missed it and you are doing that and then sendToBack() to get a monster/player token above a background item)

I can see reasons to want to use sendToBack() instead of move-to-Object-layer on a dead token. Mostly so that it can still be targeted by e.g. Raise Dead spell macros.

Ok, after playing with MT a bit and token stacks, I think I understand the issue and the why for. Of course, this does nothing to solve the problem itself.... as I said, it could be that this function was meant stay this way, or that it just overlooked at the time. I know Azhrei fixed a few functions recently to remove the call the putToken(), so perhaps this can be fixed in the same way... but based on his comment, it seems that he may be hesitant to do so for some reason...

[jfrazierjr]

<developer speak>

Hmmm... another question is the are reason the tokenStackMap is implemented as a plain HashMap instead of a map type that knows insertion order(ditto tokenStackSet)?? If the insertion order was kept, then a new token dropped on top of another would always be higher in the order and not have to depend on sendToBack() or visa versa. This would allow tokens to walk over each other and order would be maintained based on order they entered the cell instead of some arbitrary order. This might also give a bit more freedom when it comes to 3 or more tokens in the same cell since with only sendToBack() and sendToFront() you have to do a bit more shuffling instead of just dropping them in the order you want them....

Anyway, just a thought.
</developer speak >

[aliasmask]

I did a little research on what you can and can't use:
http://forums.rptools.net/viewtopic.php ... 9&#p142706

[netjiro]

Ah, the reason for sendToBack() as opposed to moving to object layer, in my case, is that both players and npcs have until the end of the round to try to heal someone who is about to die a horrible gruesome death. I cannot get the players to access the object layer, and I don't want to have to fiddle with the tokens more than necessary. With sendToBack() it takes less time when playing. Not a big deal, but it helps.

Thank you for the explanation of the inner workings.

Stacking by order of last movement would be very nice indeed, and would solve the problems I get now.