Custom Pointers Coding Toolkit - Over Several Posts

[Trenloe]

Really cool - thanks for spending the time to put this detail all together.

Do you have some example screenshots of what you can do with custom pointers?

[dulux-oz]

Sceenshots... Screenshots... Not really.

I cover Maps & Images in my upcomming Tutorial Video (see the Thread "New Tutorial Videos" in the Tavern Forumn - https://www.fantasygrounds.com/forum...utorial-Videos) and as my Übergame Ruleset uses three Custom Pointers (a 60-Degree Cone, a 120-Degree Cone and a Origin-Starting-Point Half-Wide Ellipse) we can see those ones there, but no, I don't have any (other) screenshots.

Basically, if we can draw it on paper there's a 99% chance we can draw it on-screen with the Toolkit (complex, multi-direction, multi-radii curves being the ones that may cause problems - try to break these down into simpler curves) - we've just gotta work out the starting/ending points, radii and offsets from the Origin. I suggest grabbing some graph paper and drawing your pointer on that to help work out these coordinates.

The Savage Worlds "Teardrop" Pointer/Template, for example, is simply two Lines joined by two Regular Curves - because the bottom Curve (the large one) covers more than 180-Degrees I'd draw that as two smaller Curves each starting at the Y-Axis and curving up to the left and right, and while the top Curve is less than 180-Degrees and so could be drawn "as is" by either of the Curve Functions, I'd probably draw it as two Curves as well, again, starting at the Y-Axis (actually the Origin) and curving down to the left and the right. The two LineCurves, obviously, would join these Curves.

[Moon Wizard]

The custom pointers are not often needed for ruleset development, so I think the best place for your data will be in the Library (perhaps in the Anatomy of a Ruleset).

Also, I'm hoping to get a wiki set up at some point, since there are add-ons available that can use the upgraded vBulletin login system.

Cheers,
JPG

[dulux-oz]

I was only joking JPG - well, half-joking. If you and the rest of the team want to put it in the Library or make it sticky or whatever, then thats fine with me

[Zeus]

dulux-oz/moon - just to clarify something. If we know the start/stop point of a pointer as well as its area coverage, it should be possible to track the image area covered by a pointer (mapped to x,y points in an image control). If this is the case then I believe this would be all that would be necessary to initiate a basic mechanism for determining Line of Sight to any targeted token (also on the same image).

I am thinking it maybe possible to attach an invisible 25-45 degree wide cone to all tokens, facing out from the current facing direction of the token. As the token rotates, so too does the LoS cone. Now to determine LoS we simply have to check to see if the x,y position of the target token falls within the LoS cone area, if it does we have LoS, if not we don't have LoS etc. etc.

[dulux-oz]

You wouldn't need to actually draw the "Invisible Cone" (although that's not a bad way to think about it) - you simple need to check if the Target coordinates were within an area defined by the coordinates defining the Cone.

The functions used to draw a Cone in the Toolkit take as arguments the Starting Coordinates of the Pointer, the Ending Coordinates of the Pointer and the Angle-Of-Arc of the Cone. This is convenient, because with these three things, plus the Coordinates of the Target, it is relatively simple to solve our problem - let me explain.

The Target lies in our Line-Of-Sight (ie within the "Invisible Cone") if:

1. The Target is between the two "arms" or straight-edges of our Cone, and
2. The distance from the Starting Point to the Target is less than or equal to the length of the Cone/Pointer.

• The angle that the Pointer lies relative to an arbitrary control line is given by the math.atan2() function.
• The angle that the line from the Starting Point to the Target (the TargetLine) lies relative to the arbitrary control line is also given by the math.atan2() function.
• Therefore the angle that the TargetLine and the Pointer make is simple the subtraction of the two math.atan2() results.
• If the absolute value (math.abs()) of the result of this subtraction is less than or equal to half of the Angle-Of-Arc then we have fulfilled Requirement 1 (half the Angle-Of-Arc because the Cone lies symmetrically on either side of the line used to define the Pointer).
• If the length of the TargetLine is less than or equal to the length of the Pointer than we have fulfilled Requirement 2.
• If both Requirement 1 and Requirement 2 are fulfilled (ie TRUE) the the target is within Line-Of-Sight.

Code follows (feel free to tidy-up, it's written for explanation purposes not for code/processing/memory efficiencies):

function fpLOSTrue(nStartingXCoord,nStartingYCoord,nEndingXCoord,nEndingYCoord,nTargetXCoord,nTargetYCoord,nArcDegrees)
if nArcDegrees < 0 or
nArcDegrees > 360 then
return false;
end
local nHalfArcRadians = math.rad(nArcAngleDegrees)/2;
local nTargetLineAngleRadians = math.atan2( nTargetXCoord - nStartXCoord, nStartYCoord - nTargetYCoord );
local nPointerAngleRadians = math.atan2( nEndXCoord - nStartXCoord, nStartYCoord - nEndYCoord );
local bReq1 = ( math.abs( nPointerAngleRadians - nTargetLineAngleRadians ) <= nHalfArcRadians );
local nLengthTokenLine = math.sqrt( ( nStartingXCoord - nTargetXCoord )^2 + ( nStartingYCoord - nTargetYCoord )^2 );
local nLengthPointer = math.sqrt( ( nStartingXCoord - nEndingXCoord )^2 + ( nStartingYCoord - nEndingYCoord )^2 );
local bReq2 = ( nLengthPointer - nLengthTokenLine >= 0);
return (bReq1 and bReq2);
end

You'll note that the fpLOSTrue() function will work with any Angle-Of-Arc, includeing 0 (a Line) and 360 (a Full Circle).

Usage:
I suggest using the Target Token's Coordinates as the Target Coordinates, the "Current Token's" Coordinates as the Starting Coordinates, choose an arbitrary angle for the Angle-Of-Arc (as Übergame is built on Hex-Grids I'd personally use 60-Degrees), then the only thing to calculate is the Ending Coordinates, which would depend upon both the chosen arbitrary length of the "Invisible Cone" and the facing of the "Current Token".

Any questions please ask

[Zeus]

Thanks dulux-oz.

I shall have to have a play with this when I get back. Your right about not having to draw the LoS cones and thanks for the additional method, that should help get things started nicely. I'll have a think about how to best handle obstructions (walls, columns, enemies, other pc's etc. etc.), which would also need to be factored into determining LoS but thats more advanced and for later on. It could be possible to combine this functionality with the multi-layered maps functionality which could allow for a method to allow GM's to place obstruction tokens on one layer, effectively mapping the walls etc. Hmmm, intriguing possibilities arise ...

[Callum]

But even as is, this enables the drawing of a pointer shape and targeting all tokens inside it, right?

[dulux-oz]

Not quite, no.

The Pointer_Toolkit will allow us to draw a Cone Pointer based on its Starting Point and Ending Point, provided we supply the relevant function with a "hard wired" Angle-Of-Arc, which will then be drawn by FG2 for us.

The fpLOSTrue() function will allow us to determine if a Target Point lies within the area defined by a Cone with a Starting Point, Ending Point and an Angle-Of-Arc.

The Starting Points, Ending Points and Angle-Of-Arcs supplied to both Function and Toolkit COULD be the same, but there is no intruinsic relationship between the Toolkit and the fpLOSTrue() function.

The hard part is that the Starting Point, Ending Point, and Target Point need to be exposed to us by the FG2 Code (ie the FG2 Coders) so that we can use them in both the Function and/or the Toolkit - as far as the Toolkit is concerned, the Starting Point and Ending Point are exposed via the inbuilt onBuildCustomPointer() function. However, we would need to have these two Points and the Target Point exposed to us in some other function for us to be able to use them in the fpLOSTrue() function, and the to best of my knowledge that expossure function does not exist.

Until it does we cannot do automatic targeting (at least not via this menthod).

Also note that while fpLOSTrue() can be used to target along a Line, within a Cone shape of any Angle-Of-Arc (even greater than 180-Degrees) or even within a Circle, it does not and cannot work with a Square shape (the geometry formuals and logic would be different) and that the Toolkit can only draw Cones less than 180-Degrees - let me say it again - there is NO intruinsic relationship between the Toolkit and the fpLOSTrue() function.

As far as walls and other obstructions would be concerned - if the obstruction "breaks" the TargetLine then the Target would fall out of LOS. You could combine fpLOSTrue() (which returns a Boolean) with another Boolean Function that determins if the TargetLine is broken to get our result of LOS or not. If we use this idea than we would need to use more than just the CentrePoints of Tokens as, by its definition, a point has no length or width (it's a Zero-D object). You would have to have some sort of 2-D (or at least a 1-D object, like a line) breaking the TargetLine ie you would need to determin the Token's "Corners" or "Radius" (for a Square or Circular Token, respectively).

Also, you may want to consider characters/monsters (ie Tokens) as a special case, because if a party menber is standing between the Attacker and the Target but is closer to the Attacker than the Target than LOS may not exist, but if closer to the Target then LOS may occure (with a cover bonus of some sort, obviously). Also needed to be taken into accout are the relative heights of the creatures represented by the Tokens - a Halfling is not going to stop LOS on or for a Giant, for example, no matter where they stand relative to each other.

Just my $0.02 worth <WEG>

[lokiare]

Ok, so where would I put the <imagecontrol> xml stuff if I were going to create an extension with this?