Oh yeah...
Turn off snap-to-grid for a token, turn on show last movement and then drag it around.
Can make for some interesting movement patterns and a measurement error in at least one case:
The path is the previous move that started in the first glowy hex and ended in the selected position. The new move is being shown as 5' but would obviously be closer to 10'.
Not a big deal to me. Was just messing around.
MapTool 1.1 build 11 progress
Moderators: dorpond, trevor, Azhrei
Not from a single square. And all movement happens by exiting a single square and moving to a new one. If the movement continues in the same 1-of-8 directions, it creates a single vector, but if the 1-of-8 direction should change, a new vector entry is started. Add up a bunch of segments and you get the full movement.trevor wrote:Although an admirable idea, it still suffers from the problem of slowing down over time. I expect the size estimates are a bit low (there's a lot more than 8 directions ).
Basically, if a creature were to move 8 squares horizontally and 3 squares vertically, there would be 5 or 6 vectors, depending on how each portion of the move was broken down. In any case, that's 12 bytes if the values are packed into 16-bit shorts. And vectors don't have the problem of specifying absolute grid coordinates who values are essentially unbounded and hence could eventually overflow any chosen data type.
It probably doesn't matter, though. Assuming that whatever format is used allows for a 16-bit value to represent some segment of movement, it would require a thousand segments to see a noticeable drag (0.5 seconds) on a 56K dial-up connection.
Oops, I forgot about that. But then, don't most game systems assume that combat is on some sort of grid?Phergus wrote:That assumes enforced snap-to-grid. With free-form movement it isn't true.
All in all, I don't really see much of an overhead problem at today's speeds of 56k or more. If it does become a problem, using link-level stream compression might be the way to go...