LOS and some help

Hello All,

I posted the following in the Module Forum, but maybe this is a better place. And again please forgive my ignorance … After looking at the code again, is there a way to traverse the lastRangeRect in the LOS_Thread code to determine which, if any, Hexes or Hexsides are crossed by that “line”. If I am reading the code correctly, the Rectangle that constitutes the range (assuming snap to grid) once the mouse button is released, should be traversable? I know, that is not a word, but is there existing code I could hack, or does someone know of a way to do this?



I am new here, so please bear with me. If this is not the right place, forum, etc… I have been trying to leverage both the LOS_Thread code and expanding upon the attackwizard from The Devil’s Cauldron which enhances the terrain features of a map to determine the following. From a source point S to an end point E, has some code already been published that determines all of the hex and hexsides that a line passes through AFTER the target has been selected. One drawback of the LOS_Thread is that it stores EVERY hex the mouse crosses during the drag events, so along the way if a player moves here and there all hexes get added to the list. What I would like are just those hexes and hexsides that are traversed between points S and E assuming we are snapping to the hex centers. Hence code like the following is great but not quite there. Anyone know of such a thing, I am sure it has been done?


String location = this.map.localizedLocationName(this.arrow);
if ((!this.checkList.contains(location)) && (!location.equals(this.anchorLocation))) {
this.checkList.add(location); // this adds every hex crossed, even if not in the line once targeted, this is a List<>
this.lastLocation = location;

I implemented a pixel-based LOS engine for VASL, so I’m familiar with what you’re trying to do. But I don’t understand this comment:

One drawback of the LOS_Thread is that it stores EVERY
hex the mouse crosses during the drag events

The LOS_Thread class doesn’t store anything and hexes do not exist as objects in VASSAL. Perhaps they do in your custom code?

Anyway, I implemented a custom hex grid in VASL. Once you do this determining which hexes are “touched” by the LOS is pretty straight forward, although managing the geometry can get tricky as the hex grid will probably have rounding errors.

Thanks for the reply. You are correct, LOS_Thread does not store anything, and hexes do not “exist” is VASSAL. I guess what I was trying to point out is this; in the LOS_Thread class, the mouse dragged event handler gets a String for the localizedLocationName for the point on the map (after determining SNAP or not) of the current coordinates of the mouse event, then checks to see if that string value is currently in a list of values and is not the “anchor” string. If so, then add it to a list. Of course, as you drag the mouse all over the map, regardless of whether or not the line drawn between the anchor and the arrow (the start and end points of your LOS) actually crosses the list of strings (whose values represent the localized location names on the map), the report output of the LOS_Thread includes ALL of those localized names. This is easy to verify, drag your mouse around a map, and when you have defined your anchor and arrow, the thread reports all of those “areas”. I would not classify it as a bug per se, but the output is not particularly helpful. For instance; checking the LOS between two locations on a map, that does have a hex grid defined (Last Chance for Victory…) reports this

spencer Checked LOS from N27.36 to N27.37

However, here is the report for the same LOS check between the same two “locations”, but when I checked the LOS I dragged my mouse “all over the map” so to speak …

spencer Checked LOS from N27.36 to N28.35, N28.34, N28.33, N28.32, N27.32, N27.31, N26.30, N26.29, N26.28, N25.29, N25.28, offboard, N25.27, N26.27, N27.27, N28.27, N28.26, N28.25, N27.26, N27.25, N26.25, N26.26, N27.28, N28.28, N28.29, N29.30, N29.31, N29.32, N30.32, N30.33, N30.34, N30.35, N30.36, N30.37, N30.38, N30.39, N30.40, N30.41, N30.42, N29.43, N29.44, N28.43, N28.44, N27.44, N26.43, N26.42, N25.42, N25.41, N25.40, N26.40, N26.39, N27.39, N26.38, N26.37, N25.37, N25.36, N26.36, N26.35, N26.34, N26.33, N26.32, N26.31, N26.41, N27.41, N27.42, N28.41, N28.40, N27.40, N27.38, N27.33, N28.36, N28.37, N28.38, N29.39, N29.40, N29.41, N29.42, N27.43, N29.37, N29.36, N29.35, N29.34, N27.30, N25.31, N27.34, N27.37

You see the final anchor and arrow (the bolded above) are the same, but there is considerably more “work” involved in the later. This is really kind of a red herring however I think. What I am hoping to accomplish is given a line drawn between the anchor and the arrow, what are all of the locations on the map that such a line crosses. In my case, all of the locations crossed by the line from the center point of one location (the anchor) to the center point of another location (the arrow). I have been using The Devil’s Cauldron as a reference for trying to accomplish this, but the LOS check in that game does not care about the intervening areas on the map between anchor and arrow, just the overall range (the distance between the two).

As I work through this I am amazed at how much effort went into VASSAL, and I am truly humbled by the contributors to this effort, both past and present. I had NO idea just how much went into this engine. So kudos ! And to all those helpful on these forums as well!


Okay, I’m following you now. The LOS_Thread adds the end points of every LOS check to a variable called “checkList” so it can show you all of the end points you checked per your example above. I wasn’t familiar with that as VASL overrides that feature and just shows the final end point no matter how many hexes are checked.

But again these are just a series of end points and won’t give you want you want. If you really want to find all hexes “touched” by the LOS you’ll have to code up a real hex grid and “do the math.”