MapTool 1.3 Development Build 40

[lmarkus001]

Have you tried Kobolds? Goblins are not very lawful, so it seems odd they would always pick on #52. Perhaps Kobolds would help you to see the pattern better...

[Orchard]

Have you tried Kobolds? Goblins are not very lawful, so it seems odd they would always pick on #52. Perhaps Kobolds would help you to see the pattern better...

Well, formians or something might be an even better choice, in that case....

...just sayin.

[Micco]

I would still argue that a refactoring of the code for the next minor revision (i.e. 1.4) should include a revamping of key elements in the system to use explicit identification instead of the current name resolution scheme. Obviously we can't entirely get rid of name resolution since it still has value in the /im command, but disambiguation wherever else possible would be a great help.

I've poked around the naming handling/maiming code extensively. It is in serious need of refactoring IMHO. It's on my "to do" list, but RL has seriously kicked me in the butt lately and looks to continue the beating for the next couple of months. So I won't be able to take a shot at even refactoring the naming stuff till later in the fall.

I very much agree with applekor on the explicit ID. It will take a major revision change, and should be part of the initial 1.4 change since it will break so much that is out there. But it is fairly critical to open up the next level of opportunities for MT (i.e., targeting).

[Craig]

Okay. I did a test and yes, right-click uses /im.

So there are a few things to come out of this.

• /im is not case-sensitive

• /im only uses the player name of a token
  • I've argued as to why I think this is a really bad idea, but I can see why this would be a coding nightmare to fix

• Copying and pasting tokens without changing their names will break macros that use/modify properties

This also answers my question about players running tokens on monsters. As long as 'Restricted Player Impersonation' is ticked, this should stop players modifying monsters by changing their token name.

So it's at least as much of a feature as a bug and winds up with me asking for /im to be clever enough to look at the GM name as well when it is used implicitly in the right-click menu, macro panels and so on.

Yep, I forgot this earlier, but the macro code usually checks for ownership to make sure that you can't run a token on something you don't own. This is one of the "problems" surrounding how to get a "targeting" system to work and why it is not as easy as saying "everything selected is my target, just run the macro". Though it would be a good feature to have,
I would be just as happy to have a "roll this expression x times" with a prompt and me still have to manually update any non owned token properties in some way (macro). Perhaps a good side benefit is selection based targeting WITHOUT selection modification. For example, if using Kniza's proposal(as implemented by Mr. Pokeylope) for multiple rolls:

[C:targets."target.Name takes damage: " + (1d8 + str + dex + end) + "<br>"]

where SELECTION starts a loop on selected elements and prints out something like:

Goblin 1 takes damage: 9
Goblin 7 takes damage: 3
Goblin 12 takes damage: 12

The loop is already there in the design of this feature, the question comes to can it be pulled from the count of selected elements or not and then can the current one's name be pulled out and printed to chat.

Oh... this is the other place where having unique names is good, because if they are all Goblin, then how does the DM know which one took which damage. For me as a player of ranged people, the one with the highest damage output would always hit the closes melee enemy. Lucky me, eh????

When using strict token ownership you can not select tokens that you do not own, so using selected tokens as targets wont wotk

[jfrazierjr]

Okay. I did a test and yes, right-click uses /im.

So there are a few things to come out of this.

• /im is not case-sensitive

• /im only uses the player name of a token
  • I've argued as to why I think this is a really bad idea, but I can see why this would be a coding nightmare to fix

• Copying and pasting tokens without changing their names will break macros that use/modify properties

This also answers my question about players running tokens on monsters. As long as 'Restricted Player Impersonation' is ticked, this should stop players modifying monsters by changing their token name.

So it's at least as much of a feature as a bug and winds up with me asking for /im to be clever enough to look at the GM name as well when it is used implicitly in the right-click menu, macro panels and so on.

Yep, I forgot this earlier, but the macro code usually checks for ownership to make sure that you can't run a token on something you don't own. This is one of the "problems" surrounding how to get a "targeting" system to work and why it is not as easy as saying "everything selected is my target, just run the macro". Though it would be a good feature to have,
I would be just as happy to have a "roll this expression x times" with a prompt and me still have to manually update any non owned token properties in some way (macro). Perhaps a good side benefit is selection based targeting WITHOUT selection modification. For example, if using Kniza's proposal(as implemented by Mr. Pokeylope) for multiple rolls:

[C:targets."target.Name takes damage: " + (1d8 + str + dex + end) + "<br>"]

where SELECTION starts a loop on selected elements and prints out something like:

Goblin 1 takes damage: 9
Goblin 7 takes damage: 3
Goblin 12 takes damage: 12

The loop is already there in the design of this feature, the question comes to can it be pulled from the count of selected elements or not and then can the current one's name be pulled out and printed to chat.

Oh... this is the other place where having unique names is good, because if they are all Goblin, then how does the DM know which one took which damage. For me as a player of ranged people, the one with the highest damage output would always hit the closes melee enemy. Lucky me, eh????

When using strict token ownership you can not select tokens that you do not own, so using selected tokens as targets wont wotk

Yea, I know.. I am just doing a what if scenario... especially since someone said they were working on some type of targeting scenario already.

[lmarkus001]

Ran a session with b40 last night. Overall it went well. Having Initiative in game was WONDERFUL!

b40 is exceedingly slower than b39. By slower I mean that selecting and moving tokens is far slower. My uneducated but observational guess is the Initiative panel is doing too much recalculating when people are moving tokens about.

[jfrazierjr]

Ran a session with b40 last night. Overall it went well. Having Initiative in game was WONDERFUL!

b40 is exceedingly slower than b39. By slower I mean that selecting and moving tokens is far slower. My uneducated but observational guess is the Initiative panel is doing too much recalculating when people are moving tokens about.

That's odd.... though I have not looked, I have no idea why moving would have anything to do with initiative, and I highly doubt it does. I wonder if there are any other possible causes, possibly light? Are you playing D&D and/or using the shadowy light options on set on the D&D lights default? If so, that's your culprit and will be most likely for another build or a few before Trevor can get it fixed. Changing the lights back to not have shadowy areas will help dramatically.

[lmarkus001]

Yes D&D, Yes shadowy light, but was the same in b39 wasn't it? Our b39 performance was an order of magnitude better.

[Keterys]

Was creating a new party last night, doing a lot of macro editing through selection tab and having people log on, edit new stuff, etc... and ran into massive problems with macros reverting, resetting, being lost entirely. At one point someone went from the state they were in to where they were in several minutes prior, losing several new macros, regaining a couple that had been deleted, etc.

[RPTroll]

I recommend giving folks your campaign props file and a token with your basic macros and let them work on it in a stand alone way for now until the get token edit locking in place.

[jay]

Ran a session with b40 last night. Overall it went well. Having Initiative in game was WONDERFUL!

b40 is exceedingly slower than b39. By slower I mean that selecting and moving tokens is far slower. My uneducated but observational guess is the Initiative panel is doing too much recalculating when people are moving tokens about.

I took a look and couldn't find anything. The init panel is not getting called while the tokens are moving. It does get called after the tokens stop moving, but there isn't anything I can do about that.

[Full Bleed]

OK, looks like the initiative panel may may have been broken backward compatibility.

Also, giliath has updated the string comparisons to be more flexible (ignore leading/trailing spaces, ignore case).

If I get the fix from jay for the init panel stuff, I'll do a new build tonight to fix it.

So, any plans for a new build soon? I don't want b40 to eat my main campaign like it seems to have for several others but I'd love to start working on some new stuff.

[Full Bleed]

Ran a session with b40 last night. Overall it went well. Having Initiative in game was WONDERFUL!

b40 is exceedingly slower than b39. By slower I mean that selecting and moving tokens is far slower. My uneducated but observational guess is the Initiative panel is doing too much recalculating when people are moving tokens about.

I took a look and couldn't find anything. The init panel is not getting called while the tokens are moving. It does get called after the tokens stop moving, but there isn't anything I can do about that.

I think I know what the problem is.

Right now when you move a token (has to be a rptok file) it doesn't really move until you move your mouse off the token after "dropping" it. Unless you recognize that new behaviour it feels like there is some kind of performance issue and some moves can seem to take a looooong time.


Now, even though this appears to be a bug (or a change in behaviour), after playing around with it I think it could open the door to a future implementation of a "quick-waypoint mode" where you wouldn't have to use any additional buttons to move and drop waypoints (i.e. space bar or 3rd mouse button.)

Imagine being about to drop a waypoint by doing the following:

1) Click'n Hold.
2) Move
3) Unclick
3a) At this point, you could just "complete" the move by moving the mouse off the token as you have to do right now. Or, if you wanted to drop a waypoint and continue moving you could:

4) Click'n Hold again (dropping a quick-waypoint)
5) Move
6) Unclick
6a) Then move cursor off token to "complete"

I think it would be pretty slick actually.

[lmarkus001]

The state images are visible even if the token is not visible to the players. This is only an issue for exposed area of the map, but I had a case where a gnoll ran around behind a staircase, and the PCs could track his movement by watching his state images.

Oh and I just about went blind (as the GM) because the opacity setting for the GM Fog really needs to be adjustable! Note this image which is a GM view...

[trevor]

I recommend giving folks your campaign props file and a token with your basic macros and let them work on it in a stand alone way for now until the get token edit locking in place.

Yes please. Then I can profile it and see what's taking so long