MapTool 1.3 Development Build 47

[Lindharin]

It would be nice if I could just have the macro on my GM token, and use the "Run for each Selected" with a player token selected. But whenever I do, the macro still acts on the GM token, not the player.

Hi,

I think the original paragraph might be misleading in that regard. Let me re-word it:

* When you use a macro in the selection panel (or global/campaign panel with "Apply to Each Selected" turned on), it will not cause you to lose any impersonation you had originally. If you are impersonating token A, but click on token B and use token B's macros (in the selection panel) on itself, once the macro is over you will be back to impersonating token A. Prior to this change, once you used a macro from token B, you lost your original impersonation and needed to manually re-impersonate token A.

What you want is different. You want the macros in the impersonate panel to affect other tokens, which does not work directly. You cannot just impersonate your GM token and have it's macros affect other tokens directly; the whole purpose of the impersonate panel is to let you use the macros of Token A even when it isn't selected at all.

If you put your "Give Player a Benny" marco in either the campaign panel or global panel, and turn on "Apply to each selected", it would do exactly what you want. If you don't want to use those panels for some reason, and the macro has to be on a GM token, then I'm not sure of any easy way to do it. Sorry!

Well, actually, there is one possibility. How easy it is depends on your setup. If you have multiple tokens selected simultaneously (either by holding down Shift while clicking on them, or dragging a selection box over them all) and run a token macro, it will run that macro once for each. So you could have your GM token impersonated with its macro button visible regardless of what's selected. Then Shift-Click on the GM token and the player token. When both are selected, run the macro and it will increment the property on both tokens. That will only help if your GM token is easily selectable (not hidden off in some corner of the map) and if you don't care that the GM token's Benny property gets incremented too.

[DrVesuvius]

It would be nice if I could just have the macro on my GM token, and use the "Run for each Selected" with a player token selected. But whenever I do, the macro still acts on the GM token, not the player.

Hi,

I think the original paragraph might be misleading in that regard. Let me re-word it:

* When you use a macro in the selection panel (or global/campaign panel with "Apply to Each Selected" turned on), it will not cause you to lose any impersonation you had originally. If you are impersonating token A, but click on token B and use token B's macros (in the selection panel) on itself, once the macro is over you will be back to impersonating token A. Prior to this change, once you used a macro from token B, you lost your original impersonation and needed to manually re-impersonate token A.

What you want is different. You want the macros in the impersonate panel to affect other tokens, which does not work directly. You cannot just impersonate your GM token and have it's macros affect other tokens directly; the whole purpose of the impersonate panel is to let you use the macros of Token A even when it isn't selected at all.

If you put your "Give Player a Benny" marco in either the campaign panel or global panel, and turn on "Apply to each selected", it would do exactly what you want. If you don't want to use those panels for some reason, and the macro has to be on a GM token, then I'm not sure of any easy way to do it. Sorry!

Ah that's cool. I just misinterpreted the original paragraph. I've no problems using campaign or global macros for this, just gotten out of the habit after experiencing some flaky behaviour with campaign macros not updating correctly.

Thanks for the response

Dr V

[Phergus]

If it's true that Client A is requesting an image from the server that has not fully been transferred from Client B, could the server not just cache that request until the transfer is finished?...

That's the way my thinking was headed on it.

Definitely don't want the server responding with an image not available message when the image in question is still be transferred from another client.

[trevor]

Some interesting debugging of the ? guys.

Here's a thought. I could put a "flush" menu item in or something so that when you get a ? you can run it and it will remove all entries in the image lookup cache that point to a broken or pending image. That will let it try to reload the image. If the image shows up then we know there's a timing issue. If it doesn't then we know it's a transfer problem.

My primary suspicion atm is a failure in the image loading. I've seen it not work when using PNGs, but switching to a JPG would then make it work.

[jfrazierjr]

Some interesting debugging of the ? guys.

Here's a thought. I could put a "flush" menu item in or something so that when you get a ? you can run it and it will remove all entries in the image lookup cache that point to a broken or pending image. That will let it try to reload the image. If the image shows up then we know there's a timing issue. If it doesn't then we know it's a transfer problem.

My primary suspicion atm is a failure in the image loading. I've seen it not work when using PNGs, but switching to a JPG would then make it work.

But if I am understand Az correctly, the image stored with the token is the broken image constant, not the correct asset. If this is the case, then the problem seems to be the transfer of the image asset id gets hosed up. Of course, I could have totally flaked out on what Az said(wouldn't be the first time).

[lmarkus001]

BUG: addToInitiative()

[*]addToInitiative(token, allow-duplicates, initiative) Add a token to the initiative list. If the allow-duplicates flag is false (default is false) then the macro will not add the token if it is already in the initiative list. If the initiative value argument is passed then the value of the initiative will be set for the token whether it was actually added or not. To set the initiative argument you must set the allow-duplicates argument.

This function appears to take a snapshot in time, then perform the addition, and then modify the initiative value as a distinct action. The result is that if multiple people attempt to add a token to the init panel at approximately the same time, some will not show up, and some will show up without their value set.

Another attempt at describing the issue:

3 MT clients, 3 Tokens
all 3 attempt to add one token to the Init Panel at the same time.

What occurs is one or more of the Tokens may not be in the Initiative panel, and some may not have their initiative set.

So an end result could look like:

Token1
Token3 = 5


Macro used for testing (although it fails for a far simpler macro):

Code: Select all

/self [R: token.name]
[H: dieroll = d20 ]
[H: tImprovedInitiative = getStrProp(Feats, "ImprovedInitiative")]
[H: tImprovedInitiative = if(tImprovedInitiative == "", 0, tImprovedInitiative)]
[H: Initiative = (tImprovedInitiative * 4) + DexB]
[H: tres = dieroll + Initiative + (0.1 * Initiative)]
<b>Initiative: [T(tres): dieroll + Initiative]</b>
[H: addToInitiative(0,tres)]

A test case I use to quickly show the issue is:

2 MT running on different machines (one is the server).
On the server, select 11 tokens, on the client select one token.
Now with a mouse in each hand, attempt to press the Init macro button at the same time (you can vary the timing to see different behavior).

So a behavior I can reproduce reliably is:

If I press the single token macro a brief instant after I press the Campaign macro to run Init on 11 macros on the server, what I will see is some set of tokens get added (say 8), then the single token from the client gets added, and the rest get discarded.

So it looks like when the single client macro is executed, it takes a snapshot in time of the panel which now shows the 8 that have been added, it then continues processing and adds its single token to the list giving us a final list of 9. Meanwhile the other 3 tokens on the server get added to the panel for a total of 11, but then the client macro completes and overwrites changing us to a panel of 9 tokens.

UPDATE: This behavior also occurs with the setInitiative() function.

Specifically, the behavior of not setting the initiative value (or setting but having it cleared) if multiple init setting macros are run at the same time.

UPDATE: Token.init = # also has this behavior

[lmarkus001]

Has anyone tested the bug relating to removing tokens from the Initiative Panel? I know the bug was active in b45 and I did not see a direct mention to a fix in b46/7 (and I know a bunch of other fixes did not make it into b46/7 that were stated submitted a couple of months ago).

As of now, I am afraid to right click and remove as it is a fatal session issue and it is easier to just skip over those elements during a session instead of risking a crash.

[Phergus]

My primary suspicion atm is a failure in the image loading. I've seen it not work when using PNGs, but switching to a JPG would then make it work.

In one of the online tests I was involved with a PNG that wouldn't appear when dropped in by either of two player clients did appear when it was dropped in by the GM. Of course both already had it in the asset caches at that point.

Are you thinking a loading problem as in failing to open the file because the transfer is perhaps still writing to it or a loading problem with the PNG image loader?

[palmer]

BUG:

Soft fog (revealed map, but out of player token view) hides tokens, but does not prevent mouseover of them.


This the the GM view. The tokens are set as visible, but are out of LOS (topology is laid on the walls as expected).
This is me mousing over the token (you can't see the cursor). As expected, you see the bar, name and get the bottom left stat sheet popup (not shown) as well as visible area (white outline) as it has normal sight enabled (ranged attacks).

Now, I walk over to my girlfriend's computer (connected as player, Phaien to be exact), see this and screencap it there (emailing to self). FYI Phaien is the light source.


Even though she cannot see the token, she can see the name label, the area it can see (since when did that happen?) and the stat sheet popup.

Not visible is the actual token, and it's bar.health.
This really makes ambushes hard to run...

[Azhrei]

My primary suspicion atm is a failure in the image loading. I've seen it not work when using PNGs, but switching to a JPG would then make it work.

In one of the online tests I was involved with a PNG that wouldn't appear when dropped in by either of two player clients did appear when it was dropped in by the GM. Of course both already had it in the asset caches at that point.

Agreed. I've seen this effect as well.

Are you thinking a loading problem as in failing to open the file because the transfer is perhaps still writing to it or a loading problem with the PNG image loader?

"Still writing to it" meaning the image is incomplete? One of the things I've done is to enable the stacktrace printing on every exception regarding image loading even if the exception is being handled by the code. There are only a few of those. I get exceptions in a couple of spots, but they relate to problems loading the image using a separate thread. And the debugging log shows an MD5Key that does not exist in the assetcache. As I've mentioned, it IS in the token, though. I just don't know how it got into the token in the first place! However, given that it IS there, the code is acting correctly and displaying the "?".

So how does the bad MD5Key get into the token in the first place?? This is what has me stumped right now. So I went through the code starting with the EditTokenDialog to see how the values change, but I don't see any problems in the code (doesn't mean they're not there, just that I can't see them!). If I work on the assumption that the dialog box is okay, the only other place to look (AFAIK) is in the network transport.

I'm definitely not giving up on this! It bugs the heck out of me!

[dorpond]

BUG:

Soft fog (revealed map, but out of player token view) hides tokens, but does not prevent mouseover of them.

I had this same issue happen to me last night - all the players could mouseover the soft fog and see the labels of the monsters that were clearly out of LOS. It sucked. I'll make sure Trevor is aware of this today.

[Phergus]

"Still writing to it" meaning the image is incomplete?

Yes or the saving to disk process is writing to a temp file first and only renames it/moves it to the correct name in the cache when complete.

One of the things I've done is to enable the stacktrace printing on every exception regarding image loading even if the exception is being handled by the code. There are only a few of those. I get exceptions in a couple of spots, but they relate to problems loading the image using a separate thread. And the debugging log shows an MD5Key that does not exist in the assetcache.

If the transfer is even just a little bit slow, the server may be trying to load the image data from the file in the asset cache while the transfer is still ongoing. IF the image is still being written to the disk when the Server tries to get it then load image attempt will fail and the Server will flag it as "broken".

[Rumble]

BUG:

Soft fog (revealed map, but out of player token view) hides tokens, but does not prevent mouseover of them.

I had this same issue happen to me last night - all the players could mouseover the soft fog and see the labels of the monsters that were clearly out of LOS. It sucked. I'll make sure Trevor is aware of this today.

This issue happened to me today - I played an encounter today that used Vision and Topology, but no fog (basically, a well-lit room with obstacles that blocked sight) and if the player moused over the square in which a token out of LOS resided, they could see the label and the popup portrait for the supposedly "out of sight" token.

[Hawke]

Do we know if this soft-fog-mouseover bug is present in b45?

[dorpond]

Do we know if this soft-fog-mouseover bug is present in b45?

Probably not because we were using B45 for a long while before jumping to B47 and never noticed it. FYI however: Trevor will fix this in the next version and is giving MT serious TLC over the Thanksgiving holiday. If you can hang in there for B48, it will be worth it. B47 brought much better client performance too.