#1142 "Field of View" tool

stable 0.36

I'm thinking a line of sight tool that when you choose to use it, lightly greys out all the hexes you can't see. It's very tiresome to check LoS to more than three or four hexes, and it would be very handy just to know what you're able to see from a given point. I realize this might take a fair bit of work, but I think it would be extremely useful, especially to help people see the difference between the different LoS rules.


  • Johann

    Johann - 2013-10-05

    Proposed Patch

    I have made a new method: swing.BoardView1.drawLos() which draws a thick transparent border around all the hexes that can be "seen" by the selected hex. I included a menu option just below the "Toggle Isometric" called "Toggle Highlight LOS"

    This is my first attempt to make a major change in MegaMek and there are still some issues when you switch to isometric view and it took a small bit of refactoring -- I took code from the Deployment display to make this happen -- so maybe we could get someone to port these to the other BordView1 classes. I would do this, but I need some guidance on how to switch back-end graphics engines (or maybe I misunderstood the code here).

    Anyways, while this is on, you will get a "Field of View" from any hex you click on. It assumes mech to mech LOS though I have a comment and some code which could change this with the LOSTool's GUIPreferences...mechInFirst and mechInSecond fields.

    Other Notes

    • Fedora 19 (x86_64)
    • kernel 3.11.1-200
    • java 1.7.0_40 (OpenJDK)
    • Swing Application Framework ver 1.03 (rel 10)
    • eclipse (kepler)
    • MegaMek trunk as of Oct 5, 2013 (rev 9912)

    the patch file was created in the directory:


    and just for pedanticy:

      svn co http://svn.code.sf.net/p/megamek/code/trunk/megamek
      cd megamek
      patch -p0 -i highlightLOS_v1.diff
    Last edit: Johann 2013-10-05
  • Johann

    Johann - 2013-10-08

    Field of View (second iteration of HighlightLOS)

    OK, second attempt at a Field of View modification to the source. I renamed HIGHLIGHT_LOS to FOV_HIGHLIGHT and added FOV_DARKEN to darken hexes that are outside the field of view.

    Take a look at swing.BoardView1.drawLos() for the parameters used to draw the borders and the transparent-gray hexes. The colors could be adjusted there as well as the darkness/transparency.

    By default, I have the darkening of hexes outside the FOV but not the highlighting of those within. Both of these can now be toggled in the menu under View.

    The patch was made from the trunk as of Oct. 8, 2013 (rev. 9915) and can be applied using similar commands as above.

    Last edit: Johann 2013-10-08
    • Nicholas Walczak

      In the future, could you create the diff from the post-stable branch instead of trunk? It's much more likely for the patch to get incorporated into the post-stable branch before it gets incorporated into trunk.

      I looked at the original patch briefly over the weekend. Could you make the color adjustable? Like some of the other advanced options. I wasn't completely sold on the aesthetics, but I'll take a look at the second version. Perhaps making the lines a little thinner and having adjacent hexes touch?

      I'm also not sure how intuitive the transparency is to the user. Maybe more levels of transparency could help with this, I don't know.

      Have you considered using the selected unit and the unit(s) in a target hex when computing the LoS? The LoS tool options allow you to select non-mech or mech, but I feel like it would make sense to consider the attacker to be of the type of the currently selected unit, and you could use the type of any unit on a target hex as well.

      Finally, I don't like having yet another visible area loop. I feel like the code within the double for loop should be its own method and that method should be called while drawing the hexes for the current rendering method (isometric or orthographic).

      • Johann

        Johann - 2013-10-14

        Hello Nicholas,
        Thank you for looking at this!

        OK, I switched to the post-stable branch and I can make the line thickness, colors and distances changeable in the advanced settings. I am not sure what you mean by "how intuitive the transparency is to the user." but maybe this was addressed by the color change and the darkening of out-of-field-of-view hexes. I now have the entity in the selected and target hexes taken into account and I use the GUIPref's mechInFirst/Second as default.

        The visible loop problem is a bit harder to solve. The FieldOfView layer needs to respond to an individual hex-selection. I considered drawing the FOV in BoardView1.drawHex() but this is not triggered by selecting a hex (only on scrolling and drawing for the first time, or after any clearing of the graphics). Can you point me in the right direction as to where I should draw the FOV overlay?

        • Nicholas Walczak

          This is from memory, so I might be a little off, pretty I'm pretty sure that the drawHexes method gets called as part of the main paint method in BoardView1. If you call repaint, it indicates that the main paint method should be called again. That is, if you called repaint after the new hex is selected, it should update.

  • Nicholas Walczak

    Alright, I've incorporated this code into trunk, [r9958].

    I added the code based on the "darken" aspect instead of highlighting hexes. I feel that darkening the hexes without LoS is much more intuitive. Highlighting the hexes provides some information about distance, but I don't think this information is all that helpful.

    I made some adjustments to BoardView.getLosEffects. For determining the height in the source hex, it first looks if the selectedEntity state variable in BoardView1 and uses that. If that is null then it uses the mechInFirst GUIPreference. For the target hex, it looks at all of the entities in the target hex and uses the heigh of the tallest one. If none are present it uses the mechInSecond GUIPreference. I added a tooltip to the menu item that explains this. I also made it so that, if no hex is selected it will use the position of hte selectedEntity.

    I did have to update how selectedEntity gets set. I added a selectEntity method to IBoardView (and BoardView1). Now, when ClientGUI.selectEntityNum is called, it also sets the selectedEntity in BoardView1. This should ensure that the selectedEntity in BoardView1 is current.

    I did adjust the code so that drawLos is called in drawHexes, however this only works when isometric view is on (in fact, it's necessary to get the shadinw to be properly layered). However, it doesn't work here when isometric view isn't on. I never quite figured out why, but I'm guessing because something later in the pipeline causes issues.

    One thing I didn't do but could is make it so the transparency level can be set as an advanced parameter.

    In that same vein, I didn't test how this works when playing on a night map. I suspect that the transparency will be tough to discern at night.



    Commit: [r9958]

  • Nicholas Walczak

    I noticed some funkyness when using units with altitude (ASFs, Dropships, etc). I'll look into this.

  • Johann

    Johann - 2013-10-27

    Hi Nick,
    I have been developing the FOV layers and I have quite a few changes I'd like to push through. I added a new tab called "Tactical Overlay" in the client settings GUI, as well as doing some graphical clean-up in the way the settings are filled into the settings panel. I solved the visible loop problem you mention before and this fixed the isometric view and some other problems. Stay tuned.

    • Nicholas Walczak

      We should probably chat about some of the changes. Can you PM me on the Megamek forums? My username is Arlith.

  • Nicholas Walczak

    I committed a few fixes in [r9966]. First, I changed some of the shift-clicking behavior for the board view. Holding shift and clicking will turn your unit in the deployment and movement phases and it will torso twist in the firing phase. It also selects the hex you clicked on. This has the effect of adjusting where the FOV tool is centering its calculations. I now changed it so that when shift is held and the board view is clicked, the selected hex doesn't change.

    I made adjustments to how the attacker and target heights are computed for the FOV tool. This is related to FOV for aeros: the LoSEffects class uses Entity.absHeight() for computations and the FOV tool wasn't using this. This is what gives Aeros a very high elevation.

    I also used the Entity.elevationOccupied method to determine whether the surface or floor of a hex should be used.

    Finally, the default was to use Hex.floor for computing elevation. I changed this to surface. The reason is, it basically made it so water hexes wouldn't ever have LoS, since it was always assuming we wanted LoS to the bottom of the water. Surface makes more sense, so we indicate that units can see what's on top of the water.



    Commit: [r9966]

  • Johann

    Johann - 2013-10-29

    OK, I merged our efforts into a patch in the "trunk" this time (from revision 9976). It reorganizes the client settings dialog, adding a Tactical Overlay tab and adding a (needed) scroll bar to the advanced settings tab. I kept Nick's calculation of the LOS and reworked the methods to draw borders and layers over hexes. Both inside and outside FOV are now included and separate -- the alpha can be adjusted for both in the settings dialog.

    • Nicholas Walczak

      The changes have been merged in [r9977] with minor changes.



      Commit: [r9977]

  • Nicholas Walczak

    Since the patch has been incorporated, I'm going to close this ticket. Further issues/enhancements to this tool should have their own tickets.

  • Nicholas Walczak

    • status: open --> accepted
    • assigned_to: Nicholas Walczak
  • Nicholas Walczak

  • Nicholas Walczak

    • status: accepted --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks