[Script] WeaponArcs -- Visible arcs that follow your token and maintain their relative rotation.

Update v0.1.3 -- added Arcs on the Edge, as well as Offset distances. (Thanks Angelo)

Update v0.1.2 -- fixed bug where WeaponArcs won't allow any paths to be changed, rather than just the Arc paths. (Thanks David M.)

Update v0.1.1 -- fixed crash when no angle or rotation are specified in the first argument.  (Thanks Tim M)

Commands

Instructions

Examples

Github: https://github.com/shdwjk/Roll20API/blob/master/WeaponArcs/WeaponArcs.js

Support my work on

If you use my scripts, want to contribute, and have the spare bucks to do so, go right ahead. However, please don't feel like you must contribute just to use them! I'd much rather have happy Roll20 users armed with my scripts than people not using them out of some sense of shame. Use them and be happy, completely guilt-free!

Disclaimer: This Patreon campaign is not affiliated with Roll20; as such, contributions are voluntary and Roll20 cannot provide support or refunds for contributions.

This seriously blows my mind that you had a request 4 days ago and now you've written a script like this!  I don't do any spacefaring roleplaying, but this is totally useful for D&D cones (especially breath weapons) and spheres and things.  Nice work! 

I don't play in any game that requires this, but mind = blown nonetheless. :)

Thanks!  Wish I'd had time to work on it before today. =D

wow, what a great concept.

Looks like a great way to do cone spell templates.

I am blown away...  Very very cool, thanks.

Sweet.  Let me know if you have any enhancement requests, of if you hit any bugs.

Meant to post this, earlier. Was too busy looking for my lower jaw.

HAHAHAAHAHA

I love this script. One of my players is a wizard and he was asking about Cone and Burst AoE markers he could use. This will come in handy for that.

One problem I am having and I know it is probably something easy but I have a macro that I created and works fine as a GM since I can target any token to put the effect onto. But what I want to do is set it up so my player can use it and it will ask them to pick a target and then put the type they pick onto the target token.

!weapon-arc --add ?{Type|Cone, 60|Burst, 360} ?{Size|} ?{Color|Red, #ff0000|Blue, #6d9eeb|Green, #00ff00}

I'm not sure where of how to put @{target|token_id} into this, as I have tried and it asks for the target, drop down menu for Type, Size, & Color come up but then nothing happens.

HI Aaron.  I've been fiddle-farting around with this and loving it.  I was just playing with the two first arguments, angle|width and range.  I'm having difficulty understanding the definitions of angle and width.  Anyway, I tried:

!weapon-arc --add |70 12km

And this generated a scripting error that I was unsure about clearing - I had to close my console and the game and restart and all was OK.  Here's a screen shot of the console:

FYI. 

All the best,
--
Tim

This is super cool!

@Tim M -- Looks like you just omitted the angle in your command. If you include the pipe (|) in the --add option, seems to be looking for both angle (the direction of the centerline of the cone relative to token) and width (the full cone angle), e.g. --add 90|45 creates a cone with centerline 90deg clockwise from the top of the token, and a 45deg cone angle. The help says if you want to use the default rotation direction (straight up), omit angle and the pipe.

What David M. said. =D  

Update v0.1.1 -- fixed crash when no angle or rotation are specified in the first argument.  (Thanks Tim M)

this looks amazing!

it would be great to have an "offset-mode" that makes the area start at the edge of the current square.

For instance in these cases i would expect the area to start at the circled anchor point

!weapon-arc --add 90 3u #00ffff33 #00ffffff 3

!weapon-arc --add 45|90 3u #00ffff33 #00ffffff 3

Angelo, is that more about the range being 3u from the edge, or about the arc a 90|45 arc not including half the squares in front of the token, or both?  

The two points you circled are at 2 different distances from the center of the token: .5u and (.5*sqrt(2))u  Would the intent of an offset for you mean starting a constant distance from the center or starting on the edge of the bounding square?  Would you expect a 90|45 arc on a token rotated 45º to be on the grid edge, or the token edge?  And would you expect it to update if you rotate the token?

i am just thinking in terms of D&D 5e, if i say "3u" i would expect the area to start in front of my token and the edge to go all the way to 3 squares away (so to answer your question, both).

Diagonals are tricky but i was expecting them to be counted in the same way the ruler tool does (not sure if this is the same in all systems).

maybe it should always make it start in the square in front of my token, and from there pick the point on the edge/corner closest to my token? (half distance back towards the token)

EDIT: found this in the compendium showing a 30ft cone

Your ruler is currently set to 4e, which is basically the longer of x or y.  If you set it to Euclidian, you'll se 15ft at the arc edge:

You can add an extra half unit in:

!weapon-arc --add 45|90 3.5u

I think the offset is a good idea regardless, so I'll try to add some options around that in a future update.  I would like to take this idea and extend it to more of a spell effect sort of script.

Angelo said:

i am just thinking in terms of D&D 5e, if i say "3u" i would expect the area to start in front of my token and the edge to go all the way to 3 squares away (so to answer your question, both).

Diagonals are tricky but i was expecting them to be counted in the same way the ruler tool does (not sure if this is the same in all systems).

maybe it should always make it start in the square in front of my token, and from there pick the point on the edge/corner closest to my token? (half distance back towards the token)

EDIT - Cross posted with Aaron 

Using the diagonal measuring tool approach would result in a cone that extends farther than 3u along the XY axes, which wouldn't make much sense in 5e. To keep the XY also 3u, it would be a square! (4e, anyone?). So I think the range must remain a true radius. 

I agree that an --origin|[center/edge/corner] option would be awesome. Take the case of a Huge (3x3) creature casting burning hands (15ft cone, 3u range and 3u wide at the outer edge). Doesn't work as-is. See picture below, which used  --add 90|45 3u. Even if we did the extra math ahead of time o force the cone to extend the proper amount, it would be much wider at the "origin" than it should, and also too wide at the edge of the range (picture 2, forgive my reference triangle "cone"). 

You could get closer by reducing the cone angle, but again more math. Using the approximated --add 90|34 5u gives us picture 3 (almost there). As-is, accounting for token size could be built into formulas in the macros, but would require separate macros for each token size with the current version.

The Aaron said:

Your ruler is currently set to 4e, which is basically the longer of x or y.  If you set it to Euclidian, you'll se 15ft at the arc edge:

You can add an extra half unit in:

!weapon-arc --add 45|90 3.5u

I think the offset is a good idea regardless, so I'll try to add some options around that in a future update.  I would like to take this idea and extend it to more of a spell effect sort of script.

I have never changed the ruler options, but from what i see in the page settings it's the same for 5e/4e, they don't use euclidean.

The problem with just adding the size to compensate is that it's still covering squares directly to your left/right that it's not supposed to be covering.

like David M was saying, having an "--origin|edge" option that automatically shifts it based on the token size would be amazing

something like this works, you would need to get the token size dynamically, but for non-euclidean the formula needs to be changed to something else

 const addWeaponArc = (token,rotation,angle,length,c1,c2,stroke) => {
    let data = buildArc(angle,length);
    let visible = 'objects' === token.get('layer');
    let newTop = token.get('top');
    let newLeft= token.get('left');
    let tokenSize = 70;
    let theta = degreeToRadian(rotation);
    newTop = newTop - tokenSize * 0.5 * Math.cos(theta);
    newLeft = newLeft + tokenSize * 0.5 * Math.sin(theta);
    let arc = createObj('path',{
      fill: c1,
      stroke: c2,
      stroke_width: stroke,
      rotation: token.get('rotation')+rotation,
      width: 2*data.maxX,
      height: 2*data.maxY,
      top: newTop,
      left: newLeft,
      scaleX: 1,
      scaleY: 1,
      controlledby: token.id,
      layer: visible ? 'map' : 'gmlayer',
      path: pathDataFromPoints(data.points,rotation),
      pageid: token.get('pageid')
    });

A 5e cone is approximately 60°. Or exactly 53.13°...

So I've been told. I'd use 60.

Opacity Question

Aaron, where in the command is opacity specified?  Your help entry indicates a default of 99, but where would one but an alternate value in an example like this one?

!weapon-arc  --add  120 @{selected|bar2}km #b6d7a8 #000000 1

David M. said:

This is super cool!

@Tim M -- Looks like you just omitted the angle in your command. If you include the pipe (|) in the --add option, seems to be looking for both angle (the direction of the centerline of the cone relative to token) and width (the full cone angle), e.g. --add 90|45 creates a cone with centerline 90deg clockwise from the top of the token, and a 45deg cone angle. The help says if you want to use the default rotation direction (straight up), omit angle and the pipe.

Roger that, thanks, David.
--
Tim

Tim M said:

Opacity Question

Aaron, where in the command is opacity specified?  Your help entry indicates a default of 99, but where would one but an alternate value in an example like this one?

!weapon-arc  --add  120 @{selected|bar2}km #b6d7a8 #000000 1

It's in the HTML Color Entry.  

!weapon-arc  --add  120 @{selected|bar2}km #b6d7a899 #00000033 1

RRGGBB(AA)

The Aaron said:

What David M. said. =D  

Update v0.1.1 -- fixed crash when no angle or rotation are specified in the first argument.  (Thanks Tim M)

Honoured to have been of help.  Is the update in the same location as your first post mentions on github?  I just copied what was there, but it appears to be the same, at least according to the help.
--
Tim

Whoops!  grab it now, it should be there.  =D

The Aaron said:

Tim M said:

Opacity Question

Aaron, where in the command is opacity specified?  Your help entry indicates a default of 99, but where would one but an alternate value in an example like this one?

!weapon-arc  --add  120 @{selected|bar2}km #b6d7a8 #000000 1

It's in the HTML Color Entry.  

!weapon-arc  --add  120 @{selected|bar2}km #b6d7a899 #00000033 1

RRGGBB(AA)

Thanks so much for both replies!
--
Tim

WeaponArcs 0.1.1 is in the 1-click installs now!

Accidentally ran across this: I've noticed that when I have weapon-arcs enabled, I am unable to move any non-arc paths on any layer. They just snap back to their original location. When I disable the script, I can move stuff again.

Oh!!  I'll take a look.

Update v0.1.2 -- fixed bug where WeaponArcs won't allow any paths to be changed, rather than just the Arc paths. (Thanks David M.)

Hey Aaron, 

hope you don't mind but i took the liberty of slightly modifying the script and adding support for "edge areas".

I have added a new "--onEdge" option to toggle it (on --add) , it also fixes the scaling problems that another user was having.

In case you wanna merge it with yours here is a gist https://gist.github.com/ocangelo/cbb398bf9b5367d8b426d28bfa0d6d64

I have changed addWeaponArc, and onGraphicChange and added a new refreshArcGraphic to support scaling and areas along edges if you just care about those changes.

The tricky part with the option is that i had to store that info somewhere and change how you were storing the original rotation, if you run this script and have some areas already saved/displayed those might be messed up (but you can clear all your areas with "!weapon-arc --clear" and then readd them), not sure if you can find a better solution

EDIT: 

I have added an "--onOrigin" option as well and inside the defaults at the top a new one ("onEdge: false") to specify the default behavior

omfg, if you are using optional facing rules, this is golden.  And shit you are forcing me to keep pace.  I've got to come up with something else :)

Update v0.1.3 -- added Arcs on the Edge, as well as Offset distances. (Thanks Angelo)

For arcs that begin at half the token's width away from the token, use the --addEdge subcommand:

!weapon-arc --addEdge 60 2u

You can also use --addE for convenience.  It's case insensitive, so --addedge and --adde work fine also. This operates in all over ways just like --add.

For offsets, you can preface the distance with an offset amount, just like you preface the width with an angle.  Here is a 1u offset.

!weapon-arc --add 60 1u|2u

Offset with addEdge will offset from the edge:

!weapon-arc --addedge 60 1u|2u

And of course, you can chain a bunch of them together:

This should be in the 1-click next week.  I'm pretty sure I missed the cut off for this week.

nice!

in that version there seems to be a bug when scaling a token, it doesn't refresh the offsets properly; also if the scale is non uniform it messes it up (e.g. 3u on height and 2u on width)

Yeah, I was noticing the scale, problem the non-uniform I hadn't considered.  I'll look at that for 0.1.4. =D

On the non-uniform scale, where would you expect the edge to put it?

The Aaron said:

Yeah, I was noticing the scale, problem the non-uniform I hadn't considered.  I'll look at that for 0.1.4. =D

On the non-uniform scale, where would you expect the edge to put it?

I am personally not using non uniform scales (i play 5e), i am not sure what kind of behavior other systems would expect... if you look at the gist i have shared i was using cos/sin with the width/height separately and it seemed to be handling it fine