DOE: Locations Extension

LOL well the core rulesets seem to all use 1 item window that just hides fields it doesn't need and displays ones it does, should be easy enough to layout with one window class. I'm thinking about coding it up to do the conversions itself where appropriate, but honestly in most cases you're not going to be going to a shopkeeper in the DC and trying to pay them with Kroner lol.

Other than that, I've got a lot of ideas on ways to extend this, considering if I can set it up so some extensions are required even.

I'm looking at possibly asking to use the map layer extension, so I can make one of the layers the coordinates (auto generated), as well as manually entered elevations. Would be nice if I could use software to rip them out of an image and put them into a lua table by the coord, but I don't think that will be feasible.
Also have to find a way to represent facing in the movement point calculations, and represent the firing arcs when you hover over someone, or arcs + ranges when you hover over a weapon, instead of reach like in 3.5/PF.

Given how BAR and things like that on items will work, it's going to be very interesting to setup the items to begin with.

Lots to do!

Check out the posts in the Pointers Toolkit Thread (also on the Wiki) - we talk about LOS, etc, in their quite extensible (although the short answer in "No, can't be done" at the moment)

So you're saying Line of Sight is impossible, why is that?

I wasn't thinking about line of sight, I'd leave that up to the DM to decide, although I suppose I could use the rules from BT regarding elevation between the target and see, but if we're tracing out a ray across the map, why can't we check what grid spaces are under it, and then their contents?

That aside, none of what I was talking about was intended to work with LOS. Is there another issue I'm going to encounter with what I've been speaking about?

Its all explained in the posts of that thread :)

From what I'm seeing, it should be relatively easy using the fpLOSTrue functionality and automatically drawn pointers, scripted from variables already coded in ahead of time.

I see someone mentions a map layer idea, which is similar to what I'm doing, where they can exlcude items from line of site, given that I can use a line for targetting which is a spline, I should be able to decide true line of site on such a layer.

In addition since I can retrieve each coordinate in between, I should be able to look at another layer with that same coordinate and gather any attached data (such as data stored by string controls into database nodes linked to those coordinates for elevation, or obstruction).

FG may not be setup to support it in a ruleset by default, but your own posts seem to indicate that I can do this. And your custom cone pointers should allow me to setup the firing arcs that I would need as well. Though I may want to change the visual display of them somewhat, I'll worrying about tailoring that after I get something functional.

This sounds like it might actually be really coming together, the hardest part will be entering the map data. I'll have to examine how the hex grid elements are made, if they're collections of lines, I should be able to locate each "side" of the hex, and set up a layer where the GM can simply click on the edges of hexes to turn them into obstructions from that direction/to that direction, or make them not obstructing, and then check those as part of the line of sight check while targetting.

Yeah, but check paragraph 3 of post #19 of that thread - we don't have all the info we need to do the LOS, which is why FG doesn't do LOS yet

Quote:

---

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>

---

I assume this is the post you meant?

So What you're saying is when a move or pointer is started, while the game renders start and end points and tells us if a coordinate is in them, it doesn't tell us the actual coordinates of the start and end points, correct?

If we already know the coordinates of the target and the origin token, couldn't we just test coordinates on the spline for being in the path, it's a long way of doing the same thing, ut it sounds possible, or am I missing something?

Quote:

---

Originally Posted by GrimmSpector

If we already know the coordinates of the target..

---

No, we don't!

Its all about getting access to the coordinates - the the Starting coordinates of the targeting/LOS cone, the Ending coordinates of the targeting/LOS Cone, and the coordinates of the target. The onBuildCustomPointer function exposes the first two sets to us, but there is nothing currently in FG that exposes the Target's co-ordinates, so until there is we can't do LOS (via this method). Yes, FG has these coordinates internally, but there's no-way to "get at them" so we (the Community Devs) can use them. Similarly, there's no exposure of the Grids' coordinates in a way we can use either -in short, "no can do" at this time, not until we can "get at" the target's coordinates.

And I think we should move this discussion back over to the other thread if we're going to continue on with it :)

So we can't ask a token where it's located in anyway...must be some work around.

What about setting up a function that draws 0 length or very short length splines from every token, to get it's coordinates, then stores them, and also does this whenever a token moves?

Also, which thread did you want to move to?

Quote:

---

Originally Posted by GrimmSpector

So we can't ask a token where it's located in anyway...must be some work around.

Also, which thread did you want to move to?

---

Not one that we've found yet.

And I ment the Toolkit Thread.