Hex maps?

[S Ferguson]

Is it possoble in FG to have hex placement on a map rather than the traditional squares? I prefer hexes as they are less prone to error when judging, say, area effects and facing amongst other things. Just curious.

[Ikael]

FG supports hexes. There should be option to switch grid type between hex and square. Checkout the right click menu option in images

[S Ferguson]

I usually don't even use "tokens" in games, nor run combat scenarios, but the ruleset I want to implement (in a couple of months...) uses hexes exclusively. Thaks for the tip! :)

[S Ferguson]

If you do use hexes in games, does the ruler and line adjust for correct distances?

[Moon Wizard]

The distances are measured as whole grid square distances multiplied by the unit measurement (i.e. 5 in 3.5E D&D, 1 in 4E D&D, etc.)

I believe that the hex measurement is correct, but haven't spent much time with it so let me know.

Regards,
JPG

[S Ferguson]

The distances are measured as whole grid square distances multiplied by the unit measurement (i.e. 5 in 3.5E D&D, 1 in 4E D&D, etc.)

I believe that the hex measurement is correct, but haven't spent much time with it so let me know.

Regards,
JPG

I will, I assure you; and I will do the math if neccessary.

[S Ferguson]

Unfortunately, it was just as I thought. Because of the nature of the pointing system in FG it tends to "lock in" on a square grid. When translated to hexes, it marks off the corners of the hexes so that they conform to a square: i.e. drawing a cone from the center of a hex out is not possible becase it may not a point on the underlying (or overlying) square. Traditionally, when using hexes, one measures from the center of one hex to the center of another to gauge for distances. Currently in FG, this is just not possible (unless the point happens to coincide with the grid, in which case it centers the grid about that point).

[Moon Wizard]

The snap behavior is vertex and center snap. So, the pointers and tokens should snap to center points or vertex points. If the pointer you draw has start and end points in center of grid, is the measurement you're expecting correct?

Regards,
JPG

[Zeus]

You may also want to check out the GURPs ruleset, it implements Ronke's extension for adding measuring distances to hex maps. It used to work be allowing the user to draw a pointer with a scale guide thus allowing point to point distance measuring. A bit like a measuring tape. If I recall it allowed snapping from the centre of a hex.

I think Joshua also used the code in the Foundation ruleset.

[S Ferguson]

The snap behavior is vertex and center snap. So, the pointers and tokens should snap to center points or vertex points. If the pointer you draw has start and end points in center of grid, is the measurement you're expecting correct?

Regards,
JPG

Not really, The math seems to be a bit off. It's true you can snap to center points, but the measurement, from the center of one hex to the center of an adjacent hez should be the scale of the hex-size.circumscribed by a circle. I'm getting what appear to be, numbers generated by taxi-cab measurements, i.e. 1 up 1 over, 1 up in a still seemingly "square" nature. however it's dealable with (although sometimes it won't let me snap from center to center); Any constant, I can scale. I'll see what the GURPS measuring tools come up with (as suggested by Dr Zeuss above, and compare values.

Cheers,
S

[S Ferguson]

Found it. The measuremnts "across the grain" (i.e. from a center across the horizontal lines to another center) works fine in all the variations I have (say it's 2 yds), but because of the vertex locking, measurements "along the grain" are either too close or too far (ie either 1 yd or 3, not 2). The GURPS ruleset handles this in the proper fashion, assumably using "midpoints" as "vertices" and yielding the proper 2 yds. Now to figure out how it was done....

[ronnke]

It should also be noted that when you first create your hex grid, make sure the grid size is an even number, it will ensure your distances are calculated accurately.

[Moon Wizard]

The default measurement is number of spaces traversed, not radial distance.

Cheers,
JPG

[S Ferguson]

The default measurement is number of spaces traversed, not radial distance.

Cheers,
JPG

That would explain the error in the math. In a grid system, it's far easier to count "squares travelled" than in hex based movement, with a more prominent "sideslip" system, especially when moving across the grain. The Radial rule just goes back to games that measured LOS from the center of one hex to the center of another; that and miniatures gaming, in which if you aren't in the center of the hex, where are you anyway? :)

[S Ferguson]

The default measurement is number of spaces traversed, not radial distance.

Cheers,
JPG

Oh, and it isn't true radial distance. It's more like drawing a larger hex, than the one you currently have. Just a little bit more acturate than squares, as it approximates radial measuremnt closer.

[Moon Wizard]

There are always going to be different ways of measuring "distance" in RPG systems (especially hex systems). Thus, the reason why FG provides hooks for measuring your own pointers and token paths. ;)

Regards,
JPG

[S Ferguson]

There are always going to be different ways of measuring "distance" in RPG systems (especially hex systems). Thus, the reason why FG provides hooks for measuring your own pointers and token paths. ;)

Regards,
JPG

Thanks. I'll stick with the one for GURPS for now. It handles what needs to be handled. Another extension added to my list.... <<exunts stage left>>