Request for a 3d LOF Line. See Topic for further notes.

[Ashen]

Is this helpful?

• Yes
• No

Greetings.

I am requesting for a developer to consider the following option for a simple 3D Line of Fire code. The essence of the idea, is that, while even Vassal is 2D in nature, a simple tool can be acheived to use a 3D representation. Albeit the variation of this 3D is different from game to game, I have a proposed programming solution:

The algorythm idea is as follows. It is incomplete, but I lack knowledge of the specific language to produce a finer version.

Let A1 be the Altitude of Model 1, and H1 its height. Default value is 0. Model 1 is Marker 1.

Developers of modules would have to manually insert Heights as a model stat, and Altitude is a game mechanic, chosen from the drop down menu after selecting a Marker. Default is 0 for both Height and Altitudes, unless Developers or Players choose otherwise. If a prone Option exists, is changes the value to the rule-set defined value (Developer’s responsibility).

Let A2 be the Altitude of Model 2, and H2 its height. Default value is 0. Model 2 is Marker 2.

Run the following:

H = (H1 + A1) - (H2 + A2) ; (Measures relative height from Marker 1’s Height and Marker 2’s Height, with relative Altitudes.)

Let D be the 2D horizontal distance from Center to Center of both Markers. (or developer defined as Center to Center, Edge to edge, etc).

Let R be the Real 3D Distance between two modes.

R = (H^2 + D^2)^(1/2)

Let T be the value of:

T = arctan(X/D)

This gives a real distance between Marker 1 and Marker 2, based on their 2D Distance, their Heights and their Elevation values.

Now, for the part I have no idea about.

Between [0, D] map points where Y(i) is a Integer. Place the value of Y(i) near the point, marking the point in some discernible fashion. These points, called here by Y(i), are defined on the Horizontal scale, thus:

X(i) = Y(i) * cotan(T)

Where X(i) belongs to [0, D], and Y(i) is an Integer. Halt when X(i) isn’t contained in [0, D].

This would produce a line, with vertical distances signalled along the course of the line, and is obstacles were present, with a defined Height, it would be simpelto see wether the Line of Fire was blocked or not by the obstacle, as its value would always have to be inside, or outside, of a Line of Fire vertical interval. Say you had an obstace between a portion of the ine that was between 3 inches and 2 inch tall, and your obstacle was 3 inches tall. Since both values are smaller or equal to the obstacle’s height, the LOF would be blocked.

Would it be complicated to implement such a code in a future version of Vassal?

[tar]

On Oct 21, 2008, at 3:16 AM, Ashen wrote:

Would it be complicated to implement such a code in a future version
of Vassal?

The major issue involves how you would end up coding terrain and
elevation of the underlying map. You would have to come up with some
method that allows this information to be specified. For large maps
it could be exceedingly tedious to add all of the information,
although it might be possible to create a graphical tool that does
this. This also gets complicated by the presence of hexside features
in many games that could provide some form of LOS block, such as
walls, hedgerows, ridgelines, etc.

Now, complicating any such endeavor is the large number of different
terrain models and Line of Sight (LOS) rules that are present in
games. In fact, coming up with reasonable LOS rules seems to be one
of the banes of wargame designers. Rich Berg has pretty much given up
on trying.

For starters, there are the traditional “layer cake” models, which are
reasonably straightforward to describe in rules and to compute. This
is one of the most common models and is used in a large number of the
old SPI tactical games, and many other successors. Unfortunately,
this model tends to perform poorly with gentle slopes and reverse
slopes. So some other games try to extend the rules a bit to make up
for this.

The Gamers Civil War Brigade Series (CWBS) uses a number of tests to
try to determine the actual shape of the ground, and have a fairly
complicated method for determining this. The Gamers Tactical Combat
Series (TCS) goes even further, and bases elevation on the contour
lines on the map graphic rather than being directly hex-based. This
would be a particular nightmare as far as the first issue of encoding
the elevation is concerned. Some versions of TCS rules, and IIRC the
Squad Leader rules also base LOS blockage on the actual map graphics
rather than being hex-based. That would seem to be a true nightmare
to compute.

These latter issues would be needed for a fully automated system. For
the suggestion of just showing an LOS ruler with height components,
you don’t need to know the LOS algorithm itself, you just need to have
the equation of the line connecting the points. That still requires
knowing the elevation of hexes and the height for units (i.e., in the
Great Battles of the American Civil War series, troops add 5’ to the
terrain height, since they fought standing up.)

So, the bottom line is that although it shouldn’t be too hard to
develop an LOS tool that shows both the distance ruler and an
elevation ruler (although the presentation of the information might be
a bit of a graphics challenge), the real roadblock would be the data
entry that would be required to code the map. This may be something
that could be addressed if terrain coding is ever added to Vassal.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Ashen]

I made this algorythm based on the Infinity Module, and on its rules, which are fairly simple. However, I do not believe that a automated height mechanism is needed, for this particular algorythm. All it is needed is that both players know the obstacle to be inside, or outside the Y values.

That of course, requires the mapper to just define arbitraly the measurement. In infinity Module’s case, the maker decided that most obstacles were 3 inches tall, with a few beign 2 and 1 inch tall. With such simplicy in play, I devised this algorythm merely to help folks understand where and how the LoF is blocked.

So, in this case, if you had a three inch wall between a LoF with points marked as 3 and 2, it’d be outside LoF, since the LoF is measured fro mthe highest possible model heights. But if the interval was 4 to 3, it’d no obstruct the view.

I would, however, if not for a general approach to vassal, liek to know how to implement this in a module.

[rk1]

It’s not possible to make a general solution for VASSAL, because, as Thomas says, every game has their own rules for obstacle heights and shapes. Also, the rules for whether an obstacle blocks LOS are often not based on standard geometry, as in your example.

To implement this, you’d need to write some custom Java code. At a minimum, you’d need to write a subclass of LOS_Thread that read some custom properties from Game Pieces on the map to determine the heights and provided its own text display.

rk

Post generated using Mail2Forum (mail2forum.com)