Send to hex grid location

I am trying to use a Send to Location trait to send a piece to a certain hex, whose LocationName reports as “5,2” (without quotes, checked with a text label on the piece).

However, Send to Location with the option “Region on Selected Map” and 5,2 as region name fails, with a “region not found error message”.

Is this a known behaviour/bug or what am I doing wrong? Can you send pieces to a specific hex on a grid?

This is with Vassal 3.1.18.

P.S. Yes, I have noticed I can use “Grid Location on Selected Map” with Vassal 3.2.0 beta1, and that works… Just wondering why the other method wouldn’t work if LocationName after all is set correctly… What’s a “Region”, anyway? Afaik, Vassal has maps, boards, zones, locations but… regions?

a region is a “region” as defined by the map tools (found on irregular grids).
Not to be confused with a gridLocation. That is a different map property


From: barbanera barbanera@fantafoot.com
To: messages@vassalengine.org
Sent: Wed, June 27, 2012 5:14:37 AM
Subject: [messages] Edit: Re: [Technical Support & Bugs] Send to hex grid
location

[This message has been edited.]

I am trying to use a Send to Location trait to send a piece to a certain
hex, whose LocationName reports as “5,2” (without quotes, checked with a
text label on the piece).

However, Send to Location with the option “Region on Selected Map” and
5,2 as region name fails, with a “region not found error message”.

Is this a known behaviour/bug or what am I doing wrong? Can you send
pieces to a specific hex on a grid?

This is with Vassal 3.1.18.

P.S. Yes, I have noticed I can use “Grid Location on Selected Map” with
Vassal 3.2.0 beta1, and that works… Just wondering why the other
method wouldn’t work if LocationName after all is set correctly… What’s
a “Region”, anyway? Afaik, Vassal has maps, boards, zones, locations
but… regions?


Read this topic online here:
https://forum.vassalengine.org/t/send-to-hex-grid-location/5055/1

I have never found regions that useful, primarily because:

  1. They are defined as points and cannot be defined as precisely as zones, and
  2. They have no system property to tell you what region a piece is currently in - such as, for example, $CurrentZone$

However, they do allow arbitrarily-defined snap locations, if you’re into that kind of thing (I find most snapping annoying, personally).

  1. Region as it is called is really just bad verbage, Point would have been a
    better term. It can be argued that it is more precise than a zone depending on
    how you look at it - a point in space (region) is more specific than an area of
    space (zone)

  2. locationName. (only works though if you have snap enabled of course)


From: irishwulf irishwulf@gmail.com
To: messages@vassalengine.org
Sent: Wed, June 27, 2012 11:58:46 AM
Subject: Re: [messages] [Technical Support & Bugs] Send to hex grid location

“barbanera” wrote:

I am trying to use a Send to Location trait to send a piece to a
certain hex, whose LocationName reports as “5,2” (without quotes,
checked with a text label on the piece).

However, Send to Location with the option “Region on Selected Map” and
5,2 as region name fails, with a “region not found error message”.

Is this a known behaviour/bug or what am I doing wrong? Can you send
pieces to a specific hex on a grid?

This is with Vassal 3.1.18.

P.S. Yes, I have noticed I can use “Grid Location on Selected Map”
with Vassal 3.2.0 beta1, and that works… Just wondering why the
other method wouldn’t work if LocationName after all is set
correctly… What’s a “Region”, anyway? Afaik, Vassal has maps, boards,
zones, locations but… regions?

I have never found regions that useful, primarily because:

  1. They are defined as points and cannot be defined as precisely as
    zones, and
  2. They have no system property to tell you what region a piece is
    currently in - such as, for example, $CurrentZone$

However, they do allow arbitrarily-defined snap locations, if you’re
into that kind of thing (I find most snapping annoying, personally).


Read this topic online here:
https://forum.vassalengine.org/t/send-to-hex-grid-location/5055/3

See, I never worked with hex grids before and that’s why I was surprised: I was expecting that if a hex is called “0502” then center dot in the hex will return LocationName as “0502”.

Otherwise, how could you ever send to location to a particular hex in Vassal 3.1.x?

The whole hex will report ‘0502’ as the locationName. This is defined when you set up grid numbering on the grid (‘Location format’). Specifically, the center of the piece is the one doing the asking.

The reason your example didn’t work is because you didn’t set up regions. They are, as Tim said, a feature of irregular grids, not anything else.

Ok, region=point in an irregular grid. Got it. After all I have been using irregular grids and send to regions for a long time. It was just the terminoly (region=point… weird) that was puzzling me now that I started investigating the hexes thing.

But I must again the same question… was there any way to send to location to a particular hex in Vassal 3.1.x?

(A part from maybe adding an irregular grid on top of the hex grid and painstakingly adding names for the center dots one by one, that is.)

The way I’ve always done it is to put the (x,y) pixel location into the sendto dialog. And to get THAT, I do the following:
I create a dummy at-start stack in the target map window. I put one dummy piece in the stack. (It must have a piece.) I then edit the stack and use the “relocate” button. This shows the map with the at-start stack piece in it. (Usually in the map’s top left corner at (0,0)). I drag the piece to where I want to send-to to go. I push snap-to-grid if appropriate. I save and exit. The at-start stack dialog now shows me the precise pixel location that I need. I copy to the send-to command. I then move the stack again for the next send-to command, and so on. I delete the stack when I’m done.

Since you’ve never shied from doing things the complicated way, I attached a demo of how you could do this manually. You would have to set up a horrible combination of traits (really only like 10, maybe), but you wouldn’t have to define a bunch of regions. My main sequence goes:

  1. Prompt for X (of course, you probably already have an X in mind - this is for demonstration)
  2. Prompt for Y
  3. Set temporary variables - one to hold the actual Y offset, and one copy of X that you can play around with freely
  4. Decrement X by 2’s in a loop, to ultimately determine if X is odd or even
  5. Double Y (you need to be able to step by half-heights, so the Y grid location is only about half of the actual offset)
  6. Adjust Y down if X is even (depending on how you’ve defined your grid)
  7. Fire STL with advanced options, using the X grid location and the translated Y grid location.

-Seth

P.S. Of course, in 3.2 it’s just right there in the STL dialog!

Hey by the way the advanced options of STL only support integers, so this will eventually drift, let’s say, after about the 50th grid location horizontally. What you could do to mitigate this is to perform the coordinate computations yourself using only iteration and summation. You could, for instance, do this:

  1. Set either the grid height or width to an integer, to make your life much simpler. If you can’t, that’s okay, you’ll just have to do the following twice. I’m assuming the height is an integer, in this case.
  2. Create a Dynamic Property ‘temp_X_coord’, set it to 0.
  3. Now loop on your gridLoc_X (that is, the x coordinate of the grid location), reducing gridLoc_X by 1 and increasing temp_X_coord by some multiple of your actual hex width. So, for instance, in my module the width is 55.462. I would increase temp_X_coord each iteration by 554, which is roughly ten time the hex width. Once your gridLoc_X runs out, you should have an X coordinate, in pixels, that is 10 times too big (or whatever your multiple is, if not 10).
  4. Divide temp_X_coord by 10 (or whatever your multiple is). To do this, you might loop on temp_X_coord, decrementing temp_X_coord by 10 each round and incrementing some other property, say, final_X_coord, by 1 each round. Better, however, would be to perform a series of loops to reduce the number of computations you have to do - so for instance, you might do:
    3a) Loop on temp_X_coord, decrementing temp_X_coord by, say, 1000, as long as temp_X_Coord >= 1000. On each loop, increment final_X_coord by 100.
    3b) Loop on temp_X_coord, decrementing temp_X_coord by 100, as long as temp_X_coord >= 100. On each loop, increment final_X_coord by 10.
    3c) Loop on temp_X_coord, decrementing temp_X_coord by 10, as long as temp_X_coord >= 10. On each loop, increment final_X_coord by 1.
    In the end, final_X_coord should be pretty close to the correct X coordinate, in pixels, for your piece.
  5. Use final_X_coord in your Send To Location.

This method would fall apart closer to the 500th grid location across, if you were multiplying by 10. Make it 100, 1000, whatever, to get the needed precision.

-Seth

Wait, ok… so the short answer was: yes, you could do it in 3.1.x but in a very, very… should I say very convoluted way :slight_smile:

Thxs for all suggestions, though. Of course this was all academic and 3.2.0 solves this issue now.

Oh, barbanera, how I wish you had just let me believe this was necessary for Marval Heroes, rather than merely an enormous waste of my time. :cry:

I am sorry mate… that of the various issues/problems/requests-for-help I raise every now and then, you had to spend enourmous amounts of time just on the one that was merely a theoretical question (to clarify my understanding of the term “Region”), since in practice I forewarned I knew that the problem was now easily solved in 3.2.0 …

What can I say… I will send you a free copy of the next module I make :stuck_out_tongue: