MapTool 1.1 build 11 progress

[trevor]

Been thinking about the Last Path feature. It would be pretty easy to enhance it just slightly more:

- Keep track of ALL previous token moves, all revertable
- Redo a move that was reverted

Basically create an undo-redo stack for token movement. In its current form it wouldn't keep move ordering between tokens, for example, if I move and you move, and I move, then revert two moves, only I will move, not you (even though you moved most recently before me). Don't know if that's a problem or not.

[Emryys]

Been thinking... if I move and you move, and I move, then revert two moves, only I will move, not you (even though you moved most recently before me). Don't know if that's a problem or not.

Watching a little Abbot and Costello lately...

[Phergus]

I could see it being handy for at least a few moves.

Especially if some spaz player bounces their token around a few times and then can't remember where they started at.

[dorpond]

I remember requesting this feature the first day I came on board here.

I vote YES!

[RPTroll]

How about a menu bar option to show the last N turns of movement for any token thats selected? N = 0 indicates no tail, N = 1 indicates the last movement, N=2 last two movements, etc.

[trevor]

What would the use case be ?

[RPTroll]

The usage case is the same as the right click option but it is at a global level for the client vs. a right click option. The reason for multiple turns is to allow you to revert back multiple turns or see how something got where over a specific time frame. I'm fine with showing only the last turn but others may like to see several turns of movement.

In some of the vehicle games, the change in your present speed is based on your speed last round due to acceleration/deceleration rates so for those sorts of games you'd want the tail 'alway on'. For d20, it would be a handy combat management tool to remind the DM which things just arrived vs. what's been in the fight for a while.

Also, there are times when movement happens so quickly on a client its hard to tell where it actually came from. Setting this globally means the player/gm doesn't have to select each token to turn it on. It can simply be the default behavior.

[dorpond]

So basically RPTroll wants to be able to specify how many are remembered.

Some games I have will have 4 players and others will have 6 players; plus we have up to 10 monsters to deal with that may need remembering also.

Perhaps he is right in that we could have some place in Options/Pref's to specify the "cache" size.

As a general rule though, I won't go back 2 rounds ago. if the mistake wasn't caught 2 or 3 rounds ago, it is too late unless someone died due to the error then I will go back how many it takes.. Nobody likes to kill off their players due to error.

[trevor]

I thought RPTroll was talking about the display of the path, not just what is stored. That is, you could say "show me the path from the last 3 moves" and see that entire path.

[dorpond]

OOHHHHhhhhh...

Gotcha!

[RPTroll]

I thought RPTroll was talking about the display of the path, not just what is stored. That is, you could say "show me the path from the last 3 moves" and see that entire path.

Correct. I thought I read that someone wanted that somewhere but don't feel like going back and looking.

For my usage, one round of movement is fine except when a mouse goes haywire and you have what appears to be several moves to the computer but is really just one in game terms. Also, there are times when a player will move his token to a corner, take a look then continue. In this cases he normally drops the token before proceeding with the second portion of the token's movement. The show multiple would help in these circumstance since you could see the round's total movement for that character.

[Phergus]

That is, you could say "show me the path from the last 3 moves" and see that entire path.

Sounds like a good thing to me.

[trevor]

I've created trackers for both of these cases.

Note that it will require a bit of a rework on the token network communication to support it so I've put the trackers off until later.

On a technical level (for those that are interested) tokens started off very very light weight, so on any change to them we just send the entire token back across the network. It was typically smaller than a single packet.

Over time the Token class has grown. We still send the entire thing as it's still a reasonable size (packet-wise). However, putting in the entire history of moves changes everything. Basically it will get bigger over time, and thus slowing down simple things like movement over time. So there has to be a change such that only changed properties are sent. Which has other implications for synchronizing concurrent property changes.

So, in short, it's gonna take some work no the underlying infrastructure.

[RPTroll]

Why not just track the token movement changes on the client. If you have it as a menu option I assume it will be different on each client so each client should track the tokens it can see. This means the players can't see the movement tails of those tokens that just came out of FoW (which is the way it should be).

[Azhrei]

You might consider storing the moves as vectors... Would that help? Most of the time, creatures move in a straight line, which would make the entire move a single vector element. The vectors could be encoded to get a lot of information into a small space: I'm thinking 3 bits to indicate direction from the current location (8 positions), 3 bits to represent facing, and the remaining bits used to indicate number of grid spaces covered. In a single short, you'd get up to 512 spaces of movement along a single direction. And a creature with a fly speed of 240 ft/round, who is hasted, has the Run feat, and is running would cover (240+30)*5 = 1350 feet per round, or 270 grid spaces. Plenty of room.

Just trying to find an implementation that might make things easier.