Improving the VASL LOS-tool

[von Marwitz]

All right, folks.
Mebbe I felt the urge to increase my nerd factor. Or I just could not resist being laughed at...

I have observed that under certain circumstances the LOS Tool in VASL is imperfect:



In the situation above, the overlay causes a rather long text to appear that might blot out some crucial part of the LOS: Is the LOS blocked by the woods in R6? You can't see it.

This inspired me to think up a way that the text label always appears in a postion so that it cannot blot out the LOS - regardless how it is drawn.

Basically, what is needed is a certain coordinate where the text starts (either right-aligned or left-aligned from that coordinate) that never interferes with LOS.

I never liked math nor was I good at it nor have I cared about it in the last decades. On top of that I can't program nor do I have an idea of what's going on inside VASL. Nor am I a native English speaker and are not familiar with mathematical terms. So perfect prerequisites to have a go at it.

Those of you that have an idea of what you are doing are invited to shred, correct or enhance my idea.

So here's the basic idea:

VASL will have some sort of coordinate for any point on the map. So if you draw a LOS, VASL will know the coordinates of the starting point of the LOS (S) and the ending point of the LOS (E).

I want VASL to place the text label next to the LOS always at a certain distance and angle in relation to the starting point of the LOS (S). This label point shall be called L. To do so, VASL needs the coordinate of L automatically determined. I believe the trick can be done with some trigonometry.

The same should be done for the text label next to the ending point of the LOS. But to present the idea, I will only focus on the label point close to the starting point of the LOS.

As I have always suffered from unreadably scribblings of my math teachers, I will keep on the tradition they taught me and provide scribblings in the picture below:


When you are through with it, you know the way how to get the coordinate of the point where the text label next to the starting point should be placed (L). Don't nail me on the specific values - they are just there to provide an example.

With the coordinate of L given, what still might be needed is to set the direction to which the text of the label will flow from that point (i.e. left-aligned or right aligned). I believe that the following rules should apply:

IF the X-coordinate of E ≥ the X-coordinate of S THEN right-align the text from coordinate L.
IF the X-coordinate of E < the X-coordinate of S THEN left-align the text from coordinate L.
IF the Y-coordinate of E ≥ the Y-coordinate of S THEN top-align the text from coordinate L.*
IF the Y-coordinate of E < the Y-coordinate of S THEN bottom-align the text from coordinate L.*

* Any convenient distance of pixels, say for example, if the L coordinates are (1000,1000) change to (1000,1050) or (1000,950).

That's basically it. Now this only needs to be turned into code that VASL can understand...

Remarks anyone?

von Marwitz

 

[bprobst]

Or, you know, you could turn "verbose LOS" off?

 

[von Marwitz]

Or, you know, you could turn "verbose LOS" off?

Indeed, I did not think of this.

However, "verbose LOS" on makes generally sense, so room for improvement is there.

von Marwitz

 

[DougRim]

I think this is a good idea for the LOS text that appears at the end point (which can be quite long in verbose "the-only-choice-to-make" mode ), regardless of the presence of an overlay or not. The way the text is currently displayed almost always covers up some part of the LOS.

I also think we can simplify the math quite dramatically through the use of arbitrary values. Pushing the text label away from the los end point by 20 pixels in the x and y directions would clear it away from the los thread (and if not we can experiment with larger values).

As you point out at the end, the key is to know the relative positions of the start and end points of the LOS to determine if the "pushing" needs to be left or right, up or down. VASL has the info and my first thought is that it would not be hard to write some code to perform the tests you suggest.

I am doing some other debugging of the LOS code at the moment and am happy to put this in my job jar.

Doug

 

[von Marwitz]

I also think we can simplify the math quite dramatically through the use of arbitrary values. Pushing the text label away from the los end point by 20 pixels in the x and y directions would clear it away from the los thread (and if not we can experiment with larger values).

Being a German I did my best to do what is expected of us: Overengineer things...

However, if you merely push it away a fixed distance in x and y directions from the LOS end point, the label will inevitably cross the LOS depending on the direction it is drawn. That is why I believe you need a Label point (keyed to the LOS end point and LOS start point respectively), from which to set a fixed amount of pixels in the x and y directions to be safe.

von Marwitz

 

[zgrose]

I wonder if you can just make the line yellow if that text is supposed to appear. Or something like that.

 

[von Marwitz]

I wonder if you can just make the line yellow if that text is supposed to appear. Or something like that.

Would not help as you do not only need to see the line but also the terrain beneath the text that might block the LOS.

von Marwitz

 

[zgrose]

Would not help as you do not only need to see the line but also the terrain beneath the text that might block the LOS.

von Marwitz

I mean remove this text and replace the meaning of the text (this line is not calculating) with the yellow value. There are possibly other places where the text is needed, but as an indicator a color should be sufficient.

 

[jrv]

You could make a separate little window that displayed the LOS info. If you were really engineering it, the LOS info would be a stream of data that UI elements could subscribe to. So you might have the information displayed on the LOS thread (the way it is now), in one or more separate windows and/or in the chatter window.

JR

 

[DougRim]

You could make a separate little window that displayed the LOS info. If you were really engineering it, the LOS info would be a stream of data that UI elements could subscribe to. So you might have the information displayed on the LOS thread (the way it is now), in one or more separate windows and/or in the chatter window.

JR

Perfection is the enemy of good enough.

 

[jrv]

Perfection is the enemy of good enough.

I usually hear something like this when a new product is about to come out that wipes the one that is good enough off the map.

JR

 

[DougRim]

I usually hear something like this when a new product is about to come out that wipes the one that is good enough off the map.

JR

True enough.

 

[Sully]

vM your math teacher would be proud of you.

Arccos aside, it should be easy to print the verbose text such that it is never on the line. I can look at this when I'm back in the states if Doug doesn't pick it up.

 

[DougRim]

vM your math teacher would be proud of you.

Arccos aside, it should be easy to print the verbose text such that it is never on the line. I can look at this when I'm back in the states if Doug doesn't pick it up.

I'm on the case. Trying a quick and dirty approach first before touching the third rail called mathematics.

 

[DougRim]

Have a look at the attached clips and let me know what you think. In my testing, neither the source label nor the target label ever obscures the los thread (with our without overlays present).

If anyone wants to do more robust testing, I can put a link here to a VASL module with this code change included and you can draw los through 360 degrees.

 

[von Marwitz]

Looks good!

von Marwitz

 

[TopT]

Agreed, that looks very nice!