Musing: Has Anyone Managed to Evaluate move Costs Through Grid Squares or Hexes?

I'm wondering if anyone has set up a way to have an API calculate move costs as a token/character is moved, based on the terrain it traverses? The path of waypoints is saved in a token's lastmove property: Of course, through an API script, I can easily retrieve the start point and waypoints using , i.e. token.get("lastmove"): =================== Trace Move of Selected Units : 729.9856198446025,1059.3532451882934,714.3863388523724,981.3874173640249,751.9856198446025,914.4215895397566,789.5849008368327,847.4557617154883,827.1841818290628,780.48993389122,902.3827438135231,780.48993389122,939.9820248057533,847.4557617154883,1015.1805867902136,847.4557617154883,1090.379148774674,847.4557617154883 Units: 1 -------------------------- So I'd like to be able to evaluate each of these hexes (or squares) for move costs to make sure the 12 points available to the token above will allow the full move.  I figure I have a number of options to determine the move cost for each hex/square: Evaluating the graphics in the Map & Background inside the grid hex/square; Referring to a table of some sort, somewhere, that details terrain move costs; Having some notes in the GM layer for each hex/square, though that might make it pretty cluttered from the GM's point of view; Instead of plotting waypoints, I could have the players move one or groups of tokens one hex at a time; or a combination of the above or possibly some other suggestion? Evaluation and calculation of move costs would be done in an on("change:graphic", function(obj, prev) event. I guess it would be complicated to define the area of the hex a unit finds itself in.  I believe some have done some work in this area.  I'd also need to take into account linear obstacles like rivers and hill contours being crossed, I guess. Wondering if anything like this has been done or if this is something I should just leave to the players?  My original intent was to have my players plot out their move using the freehand or polygon/line tool to show where their tokens are going. Thanks in advance for any thoughts, -- Tim

I would create a "movement cost" overlay for the map that the GM could toggle-to-reveal when the game situation requires. The overlay would display the cost of moving through each hex on the map. I'd stash it on the map layer, and use the "to back" and "to front" features to display or hide it behind your map image (using the API to get the token ID and TokenMod macro to hotbutton the GM reveal/hide business). Of course, you could also set up a map key (displayed on the map or in a handout) to show why it costs more to move through any given hex. For example, a "tree" costs 2 and a "mountain" costs 3. The players would figure that out in time, and then you wouldn't need the overlay anymore. It would look something like this, except overlaying all the hexes: I'd first try having my players key in their move in the token bubbles, then see if it's worth it to become more automated.

Chris said: I would create a "movement cost" overlay for the map that the GM could toggle-to-reveal when the game situation requires. The overlay would Thanks Chris.  I'm going to poke at that approach a little more. All the best, -- Tim

I believe there is a bit of work on APIs that handles hex areas - not movement cost, if I recall, but reveal layers - so that's based on shapes, and that calculates which hexes are "within" a shape. So if you used that portion of the script (defining hex areas) you could calculate aggregate hex groups or even individual hexes with behind the scenes calculations of how much move cost there is to go to a hex. 

Pat said: I believe there is a bit of work on APIs that handles hex areas - not movement cost, if I recall, but reveal layers - so that's based on shapes, and that calculates which hexes are "within" a shape. So if you used that portion of the script (defining hex areas) you could calculate aggregate hex groups or even individual hexes with behind the scenes calculations of how much move cost there is to go to a hex.&nbsp; Thank you, Pat, I did do some searching in the forum, but did not find much.&nbsp; I'll look a bit more.&nbsp; I'm trying to figure out how to use Amit Patel's guidance at <a href="https://www.redblobgames.com/grids/hexagons/#hex-to-pixel" rel="nofollow">https://www.redblobgames.com/grids/hexagons/#hex-to-pixel</a> to figure out to do some of this. -- Tim

Maybe something like using the State object (it persists between sessions) to store a 3-dimensional array for each map, corresponding to the hex positions, e.g. (x,y,cost). This would be defined by the Page object's width, height, and grid properties. Default the cost to 1 unit, or whatever. Then during setup, you could use a special token with a token action that calls your script to update the cost values for terrain in a given x,y location via a query (perhaps with a default value if there is not much variation in cost). You move the token to a higher cost hex, and run the update. During play, have the api listen for tokens to move as you described, and add up the cost of each hex using waypoints, performing a lookup to the cost array for each waypoint. You would then output the total movement cost to the chat, perhaps comparing it to a "movement_points" attribute on the character associated with that token.&nbsp; Note: the 3d array method is not very memory efficient, as there will be a lot of empty/unused elements. Another option would be to instead use an array of hex objects&nbsp; var pt = { x: the x coord, y: the y coord, cost: the cost }; ...and then use any of the various js filter methods to get the movement cost for each waypoint. This would use a lot less memory, although your repeated lookups would be a bit more cumbersome from a processing standpoint.&nbsp;

David M. said: Maybe something like using the State object Thanks David.&nbsp; I've just noticed I've posted this in the Specific Use Questions &amp; Macros as opposed to the API section and I may re-ask there for further help.&nbsp; But the state variables as per <a href="https://roll20.zendesk.com/hc/en-us/articles/360037772793-API-Objects#API:Objects-state" rel="nofollow">https://roll20.zendesk.com/hc/en-us/articles/360037772793-API-Objects#API:Objects-state</a> sound really interesting, but I haven't quite figured out exactly what "state" actually means.&nbsp; The link above made me a little confused but I'll try to figure it out. In the meantime though, I figured a script with a simple switch to cover the myriad hexes.&nbsp; However, my biggest challenge is translating pixel coordinates to a hex label. All the best. -- Tim

Tim M said: In the meantime though, I figured a script with a simple switch to cover the myriad hexes.&nbsp; However, my biggest challenge is translating pixel coordinates to a hex label. I'll suggest Aaron's TokenMod script to operate the switch, in the unlikely event that you're not familiar with it. When I'm setting up a map cover, I'll usually place my image on the map layer, and set up a macro to show or hide it. Use the macro to place it behind my map image to hide it or in front of the map image to display it. Select the appropriate image(s) using the item's Token ID. For example: To show the item: !token-mod --ids -MKKkvza4uNXl-Mx94ti --order tofront To hide it behind the map: !token-mod --ids -MKKkvza4uNXl-Mx94ti --order toback *substitute your item's token id in place of -MKKkvza4uNXl-Mx94ti in this example.