Visual reminder of exceeded movement

[Rumble]

In my efforts to learn something about Java (MapTool is a fantastic teaching platform, actually) I've been working on things I think might be neat or useful in the software. One is related to the movement cost/movement blocking stuff that is frequently requested.

Movement blocking is well beyond me, but showing movement limits turned out to be fairly easy, and I thought I'd show everyone what I was doing. I've worked out how to embed a movement limit in a token, and then have the movement path change when that limit is exceeded.

Visually, it looks like this (this is not a mockup; it actually runs):

[spoiler=MoveLimit]

movelimit.png (165.61 KiB) Viewed 3330 times

[/spoiler]

Behind the scenes, it relies on a special variable token.moveLimit, which can be edited via macro (either directly, using that variable name - like token.name, or token.label, etc., or by two functions getMoveLimit() and setMoveLimit()).

It's way primitive at this point. Tokens are defaulted to 100 squares so it doesn't crash out if you move a token before you set its move limit; it only works on a square grid, and it only works in terms of squares, so it's not like "ready for prime time." However, I will continue to pursue it if other people think it might be useful!





...and, I was proud of myself for making it work. So I thought I'd preen a bit.

[CoveredInFish]

Hmm... nicely done. I'd like to see that as an feature in some official build. And btw, I like it more than some strict movement blocking...

[Full Bleed]

I've always wanted something like this built into MT.

It will be interesting to see where you go with it.

Would definitely like to see it work gridless though.

[Rumble]

Hmm... nicely done. I'd like to see that as an feature in some official build. And btw, I like it more than some strict movement blocking...

It's probably too late for b57. If there's another build or more before 1.3 is released as final, I will see if I can get this to be robust, and submit it as a patch (assuming that's okay with Trevor) and see if it makes it in. On the upside, this can be entirely separate from movement blocking (which could be a layer like vision blocking).

If not, hopefully something like that will make it into 1.4!

[Rumble]

I've always wanted something like this built into MT.

It will be interesting to see where you go with it.

Would definitely like to see it work gridless though.

I'm sure it will; I just need to go and understand how the gridless pathing works versus the gridded one.

[Haman]

I love it. I'd like to use it if it became possible with a hex based grid, since that's where I do my gaming, but irregardless, that's great work.

[Azhrei]

Hey, congrats on getting that working, Rumble! It's always a huge boost to achieve something new...

I'm not sure about using (yet another) predefined token field, though. I would prefer to see something done with properties instead. But we don't want to force people to use a specific property name, so some way to flag a particular property as being "movement distance" would probably be needed, something like the "@!#*" that we have now (but not another punctuation symbol! that seriously needs to be fixed!).

Grabbing the property value and converting it to an integer shouldn't be a huge performance drain and it provides an interesting option: terrain movement modifiers. If the property value were retrieved every time the token moved at least one grid position, the value could be a macro that calculated the cost of the current square and reduced the movement distance! (Not sure this is practical. I think a terrain movement modifier is a better choice.)

Good work, though! I was actually thinking about taking a look at it myself!

[palmer]

I disagree with Az. It's something that needs to be "defined" so that behaviour is consistent.

However, I have two questions regarding implementation.

A: MoveLimit is set to 5
When I drag 8 spaces, I get 3 reds. Cool.

QUESTION: If I drag 5, drop, then drag 5 again... is the second 5 white or red?
In other words, is the move limit per drag, and can it be dodged by one stepping it at a time?

B: How would one accommodate Extra Movement.
This is 4E specific, I admit, but I'm sure it comes up in other games.
There's one class ability that says "When the cursed enemy dies, you can immediately teleport 3 spaces, out of turn"
There are other movements that have different limits.
Eladrin have the racial ability to teleport 5 (vs their normal Walk speed of 6) once per battle.
Other abilities let you gain additional movement, in and out of turn. A basic rogue ability is "Move 2 spaces, then attack" which is bonus movement. A ranger can "Shift 1 space before or after the attack". Etc.

QUESTION: How could these be handled?
Using a macro to change token.MoveLimit is not practical. If they hit the "Free teleport for 3" macro, that can set [token.MoveLimit=3], but the macro is done running once they can actually move.
What's changing it back? Another macro?
So every time I want to use an ability that gives me extra/different movement, with a different speed than normal, I need to use a second macro to reset my speed?
No thank you.

[Rumble]

Thinking about this, it would be nice if you could flag a property; on the other hand, "token.moveLimit" (like token.name or any of those variables) seemed like something that could be inherent to the token, as a special variable. Obviously, there's room for debate, though.

I did get it to work with hexes as well; hex grids don't have a pathing line but it will turn the cell highlight red after X number of cells are traversed.

Palmer, with regard to your questions: I don't have it remembering how far you've moved (well, at least not yet, although as Azhrei pointed out, it would be possible to update the moveLimit value for each square/hex of movement. There would still need to be someway to reset it, though, at the end of the movement).

For extra movement, given the foregoing and the fact that there's not implementation of blocking (that is, it doesn't prevent you from dragging the token farther than the token.moveLimit; it just shows you when the current path is in excess of the token.moveLimit value) extra movement would not get any interesting visual change (it would be white, unless it exceeded the move limit setting).

So yeah, it would have to be macro-controlled, likely two macros, and obviously not optimal. I assume it would be possible to integrate moveLimit resetting with Initiative, but...I guess it would be an open question how to implement it all.

Things to think about:

- Should movement limits count down until some event causes them to be reset? (per Palmer's example, if your moveLimit is 8, and you do two drags of the same token, should it remember the first drag when deciding whether to change the color of the path)

- What event resets movement limits? Something programmatic? Macros only? Either-or?

- Should it be a fixed token property, or a flagged property?

I have no idea what the answers should be.

[Full Bleed]

Just to throw more logs on the fire... what about being able to define custom movement ranges like Walk (20), Jog (30), Run (60)?

I'd also like to see an option where the total movement was tracked through a turn and then reset through the init panel when init advances.

As usual, a simple idea starts to get complicated real quick.

[Rumble]

Just to throw more logs on the fire... what about being able to define custom movement ranges like Walk (20), Jog (30), Run (60)?

I'd also like to see an option where the total movement was tracked through a turn and then reset through the init panel when init advances.

As usual, a simple idea starts to get complicated real quick.

Is this where I run and hide?

I've hit a snage on gridless pathing. So far, on a gridless map, the path will turn red if the movement limit is exceeded, but adding a waypoint resets the color of the path (it will turn red if you again exceed the distance, so the waypoint is effectively starting a new path each time it's added). Somewhere, I have not quite grasped how waypoints interact with gridless paths, so I'm working on it.

As for movement ranges, that would require you to be able to indicate what kind of move it was before you move the token (unless you mean, change the path color 2, 3, or some arbitrary number of times as the path gets longer? In that case, the issue becomes art assets - different color highlights for each range, and so forth).

As for the "expended movement tracking," I'm sure I can figure out how to do that, and I have it in mind as I work on this.

[palmer]

OK, the approach I'm seeing...
Have both a dedicated variable AND a flagged property.

The property is we'll call MovementProp. This is your base move rate.
The variable is token.MovePoints

Every finalized movement deducts from MovePoints.

Now, if you have a power that gives you extra movement, then it goes addMovePoints(BonusMovement) which is the same as [token.MovePoints = token.MovePoints + BonusMovement] and is probably Trusted.
If it gives you a different number (like Teleport 5 instead of Move 6), then it uses setMovePoints(Value).

As for resetting the MovePoints...

A: When you gain Initiative, then the system automatically runs [token.MovePoints = MovementProp], giving you your base number of movement.

B: Macro coders should add [setMovePoints(Value)] to any "End Turn" macros in order to manually reset points.

[lmarkus001]

While you are at it, can you add multiple undo's to the Revert Last Move? /wink

[Mathemagician]

As far as where to store these types of settings are concerned, could we do this with the movement property? It's a default in the basic set...

The user could specify progessive movement costs via json:

Code: Select all

Walk=json.set('','Walk',20)
Jog =json.set('','Jog',30)
Run=json.set('',Run,60)

Movement=json.append("",Walk,Jog,Run)
 

Then your movement limits visual display could alternate colors through a predefined sequence, maybe:

It highlights path white and displays "walk" until you've moved 20 units, then it turns blue and displays "jog" until you've moved 30 units, and then it turns green and displays "run" until you've moved 60 units, after which it turns red and near the cursor it reads "max move exceeded"

I think this is pretty flexible in terms of other systems (eg, D&D4e we could set "shift, move, double move") and also allows the adventurous macro programmer to use this to set different modes "what's that, your character got in a vehicle? I'll just run a macro that updates the movement field to the right settings..."

Theoretically, that macro approach could be done with the walk/jog/run situation, but I know my players like to see "ok, I can move this far with a normal move, how far with a double move?"

[lmarkus001]

I think the special token variable is a decent approach. Properties are very system and campaign variable. For example, in my Framework I use Movement to be the text string describing the many movement capabilities, but I use Speed to store the JSON object that has the many properties. I guess my point is a property can contain just about anything in it, and the move highlighting code really needs specific inputs.

As an aside, here is a Speed object for D&D... and this does not capture Enhancements like Haste or Boots of Speed/Flying etc.


Speed:

Code: Select all

{
   "base" : 30,
   "climb" : 0,
   "swim" : 0,
   "burrow" : 0,
   "fly" : 0,
   "flymaneuver" : 0,
   "encumbered" : 0,
   "special" : ""
}