Sine and cosine functions?

[Mrugnak]

Is it just me, or are we missing functions for sine and cosine?

I'm writing a function to handle scattering grenadelike objects, as per the GURPS 4e rules. I need to somehow get from "6 cells in direction 120°" (the result of the GURPS rules) to something MapTools can use with Wiki: moveToken(), which wants X/Y grid compatable instructions.

Which means that, continuing the example, I need the results of sine(120°)*6 (for deltaY) and cosine(120°)*6 (for deltaX) to pass to Wiki: moveToken().

Help?

[CoveredInFish]

They are not in the macro code base but available as UDF here in the forums.

Look here

[Mrugnak]

They are not in the macro code base but available as UDF here in the forums.

Look here

Hurray!

[CoveredInFish]

I posted a "scatter" macro months ago that might help you as example.

[prestidigitator]

I noticed this a while ago too. Note that if you're just using angles that are increments of 30 degrees, the sines and cosines are easy (plus or minus 0, 1/2, sqrt(3)/2, 1). Otherwise, there are plenty of tables and approximations, as I'm sure the links folks posted above show.

[prestidigitator]

Hmm. Related question. When using a hex grid, it seems (from the result of getTokenX() and getTokenY() on a token that has Snap To Grid turned on) the center of a hex is always at integer x and y coordinates. How exactly does that work, and how are we supposed to use it when doing distance/position calculations?

[prestidigitator]

By the way, I found a defect. This code:

Code: Select all

[h: x = getTokenX()+1]

Results in "Illegal argument type java.lang.Integer, expecting java.math.BigDecimal or java.lang.String", but this code:

Code: Select all

[h: x = getTokenX()]
[h: x = x+1]

works fine. Same result if getTokenX() is passed an argument of 0 or 1.

(1.3.b66)

[Mrugnak]

Hmm. Related question. When using a hex grid, it seems (from the result of getTokenX() and getTokenY() on a token that has Snap To Grid turned on) the center of a hex is always at integer x and y coordinates. How exactly does that work, and how are we supposed to use it when doing distance/position calculations?

Yeah, I'm discovering that this is going to be more complicated than I thought, and I think this is the root of the problem. I expected to see results along the six faces, but they're often off slightly.

[Azhrei]

By the way, I found a defect. (1.3.b66)

Fixed for b67. Including Wiki: getTokenY() which had the same problem.

[Azhrei]

Yeah, I'm discovering that this is going to be more complicated than I thought, and I think this is the root of the problem. I expected to see results along the six faces, but they're often off slightly.

Depending on what you're trying to accomplish, the best way to reduce round-off is to do your math so that you don't produce any.

For example, moving from point A to point B on a hex grid:

Calculate the straight line distance from A to B. Move along the line in that direction by the size of one grid cell (let's call it 43 for a 50-pixel hex), allowing the token to "snap" into position. Query the coordinates of the new position and store into A. Rinse and repeat.

[prestidigitator]

For example, moving from point A to point B on a hex grid:

Calculate the straight line distance from A to B. Move along the line in that direction by the size of one grid cell (let's call it 43 for a 50-pixel hex), allowing the token to "snap" into position. Query the coordinates of the new position and store into A. Rinse and repeat.

I wish that worked. I've tried this macro with a vertical hex grid. Any idea why it works for all directions but North-East and South-East?

Code: Select all

[h: USE_UNITS = 0]
[h: GRID_SIZE = 50]

[h: abort(input("dir|North,North-West,South-West,South,South-East,North-East|Choose a direction|LIST"))]

[h, switch (dir), code:
   case 0:
   {
      [h: dx = 0]
      [h: dy = -1]
   };
   case 1:
   {
      [h: dx = -sqrt(3)/2]
      [h: dy = -1/2]
   };
   case 2:
   {
      [h: dx = -sqrt(3)/2]
      [h: dy = 1/2]
   };
   case 3:
   {
      [h: dx = 0]
      [h: dy = 1]
   };
   case 4:
   {
      [h: dx = sqrt(3)/2]
      [h: dy = 1/2]
   };
   case 5:
   {
      [h: dx = sqrt(3)/2]
      [h: dy = -1/2]
   };
   default:
   {
      [h: dx = 0]
      [h: dy = 0]
   }
]

[h: dist = if(USE_UNITS, GRID_SIZE, 1)]

[h: x = getTokenX(USE_UNITS)]
[h: x = x+dist*dx]
[h: y = getTokenY(USE_UNITS)]
[h: y = y+dist*dy]

[h: moveToken(x, y, USE_UNITS)]

Moved <[r: dx], [r: dy]>

EDIT: Oh. Nevermind, almost. I just tried it again. It DOES work for all directions as long as you DO use units (USE_UNITS = 1 above). If you DON'T use units, North-East and South-East don't work, but the rest do.

[Azhrei]

EDIT: Oh. Nevermind, almost. I just tried it again. It DOES work for all directions as long as you DO use units (USE_UNITS = 1 above). If you DON'T use units, North-East and South-East don't work, but the rest do.

If you're not using units, then your fractions get rounded down to zero.

Most likely. I haven't actually looked at the code very carefully. Sorry.

[prestidigitator]

EDIT: Oh. Nevermind, almost. I just tried it again. It DOES work for all directions as long as you DO use units (USE_UNITS = 1 above). If you DON'T use units, North-East and South-East don't work, but the rest do.

If you're not using units, then your fractions get rounded down to zero.

Most likely. I haven't actually looked at the code very carefully. Sorry.

That makes sense. I did also note that, while the values are integer when you use getTokenX/Y(), using units doesn't result in simple rectangular grid coordinates being returned by them on a hex grid. So I guess it's just a matter of increasing the grid size for the desired precision. For example, moving one hex south-east on a vertical hex grid with a size of 50 went from <332, 300> to <375, 325>, which is as close a difference as we can get to <50*cos(pi/6), 50*sin(pi/6)> using integer values. I'm reasonably satisfied.

[Mrugnak]

For example, moving from point A to point B on a hex grid:

Calculate the straight line distance from A to B. Move along the line in that direction by the size of one grid cell (let's call it 43 for a 50-pixel hex), allowing the token to "snap" into position. Query the coordinates of the new position and store into A. Rinse and repeat.

The problem is here you're not writing a macro, you're waving a token around with your mouse. My problem isn't strictly the Moving from point a to point b, but finding out where point B should be in the first place...