Hi Pelle,
Just wanted to thank you for the great Hexmap extension. Did you know that Hexmap is featured in my new book, User Experience Mapping. To be precise in chapter 10 (page 297) with a screenshot and instructions. I introduce this as a better way to create hexagon maps with Inkscape. Hexagon maps are needed for ecosystem maps. Obviously I gave credit to you as creator of the tool, mentioning your name and the github url to Hex Map Extension.

The book is available on Amazon, just search "User Experience Mapping - Peter W. Szabo" (published by Packt Publishing).

Have a great day and thanks for the extension.
Peter
(@WSzP on Twitter)

Right now the extension creates independent layers at the top of the layer hierachy. For me it would be usefull to get one layer in the top hierachy with sublayers for the used options.

Currently only the document width and the width of hexes are considered to calculate a good size when none is specified. Depending on document size this can result in too high hexes, so that the rows are higher than the document height. This must be checked to make the size the maximum that fits both width and height.

I want to create a map with 1265 * 765 hexfields. At first a pythonw.exe runs (which is this extension, I guess) and closes after some time. Then Inkscape itself is in charge again .... runs ... and quits. I assume it's to much information for Inkscape to handle.

Could it be a solution to render the hexmap in packages, like row after row?

I want fields with a size of 5mm, but I cant enter the correct value because only 3 digits after the comma are allowed and 5mm = 0.1968504in. To get a value with 3 digits after the comma, I have to raise the number to 50000mm (1968.504in), but then the extension set the value back to 10.000.

Hex fields are placed outside the document:

(created with the changes in #9)

It is quite common to add a rectangle behind a hex grid when making a game board. Even if the exact colors and size has to be manually adjusted, it would be convenient if one could be automatically added behind the grid, of the exact same size, in its own layer.

When I enter a stroke size of 0,1[any unit], I got the error: „Stroke size must be positive“.

Apologies in advance -- I know little of Python or Github. In trying to debug the latest, I noticed that the Log file write method was changed to the pattern: Open, Write, Close, which I'm guessing was done to prevent an error message about exiting with an open Log file with the old code? Unfortunately, it's opened with a "w" attribute, which effectively leaves a one-line file on exit. Locally, I mimicked the earlier write() code, and then closed the log at the end of effect(). I've no idea if it's proper Python, but it did get rid of the error, and the logs are complete.

Currently the hex center is always a circle, and is sized according to the stroke width. As an enhancement, allow the user to identify an arbitrary object by its id to be used as the hex center marker. This object will be duplicated and centered on each hex center. It will not be resized. The original object should be left in the layer and position it was in.

Some games use plus symbols or stars as hex centers rather than dots. Creating a set of these can currently be done in inkscape by creating an object and cloning, but it takes a fair amount of trial-and-error to get the positioning right unless you figure out the math.

Currently bricks are forced to square shape, but not all games use that, and the old rectangular shape was more hex-like.

There should either be an option to make bricks square or not, default disabled.

I created hex grid with 5mm, but the center dots are a little to big:

Maybe use the stroke size for the dot size?

Creating hexes that are 1 inch actually creates hexes close to 3 inches in size instead. Noticed when testing in Inkscape 0.92. This might be related to new changes in Inkscape (0.91 and 0.92) for how to handle document user-units and view-port attributes?

I have a DIN A1 document and want to fill it with 600x400 hexagons, but the process got set to inactive after a while.

Here is the logfile:
hex.log

As seen in maps for a few games like (the RPG) Forbidden Lands.

First column A02, A04, A06, ... Second column B03, B05, B07, ....

Just have to figure out how to make this interacts with other options.

I'm amazed.

This is literally, in 45 years of gaming, only the second time I've seen "hex size" mean the point-to-point size.

At the very least, add a prominent note to the documentation on how to convert the normal size of a hex to the size used by the extension.

Settings: Default
Action: Click on Preview

It should be possible to align the grid towards an edge or corner, or center, of the document. The total size of the grid is known, as well as the document size, so this just needs an adjustment of the offset variables already calculated to handle stroke widths. Needs a long drop-down of options, default center.

The hex size determines the point-to-point size of the hexes (based on experiments I have performed). (this also seems to be true when the hexes are rotated: #1). How is the hex size value is related to brick size when style is set to brick?

I have a question, that may be an enhancement or not, or may be addressed elsewhere. Is there a way, with this extension or something similar, to create non-offset square grids, such as those used mainly in Dungeons & Dragons / Pathfinder type battle maps?

As I would like to automate creating a grid with co-ordinates, which your extension does for the hex and offset grid, but have no coding ability with python.

Is this something that could be added, or is this not a part of the intended design?

This isn't really an issue, but more of a documentation note for those using Inkscape in a Flatpak. You'll want to drop these files into the:

${HOME}/.var/app/org.inkscape.Inkscape/config/inkscape/extensions/

Then restart Inkscape.

It is only needed for the coordinates, but it would be nice to choose a font for the creation. Otherwise every single field have to be touched by hand.

BGG-user chris newell reports at least one error and several warnings related to old python functions in this extension.

"once I'd changed "xrange" to "range" in lines 370 and 377 it seems to work fine, though there are a large numver of deprecation warnings"

The half-hexes at top and bottom option actually does not add any half-hexes at the top at all, no hex fill and no coordinates or center dots.

For my project I need more than 1000 rows/columns, so it's a little problem that the maximal value is hardcoded:

If the value of 1000 is chosen freely and there have to be a fix value, I suggest to raise it.

Hello,
Thank you for providing this extension for Inkscape users!

This is just to let you know that most 3rd party Inkscape extensions, like this one, probably will not work with the upcoming new Inkscape version, the long-awaited version 1.0.

Here is the info you need to update this extension, so that it will work with 1.0 and future versions.
https://wiki.inkscape.org/wiki/index.php?title=Updating_your_Extension_for_1.0

If you have further questions, you can contact Inkscape developers via mailing lists, forum, or the chatroom.

If you have already updated it, please disregard this message.

All best,
brynn

When I try to use the Hexmap extension with its default settings, I get the following error message:

Traceback (most recent call last):
File "hexmap.py", line 509, in
effect.affect()
File "/usr/share/inkscape/extensions/inkex.py", line 285, in affect
self.output()
File "/usr/share/inkscape/extensions/inkex.py", line 272, in output
self.document.write(sys.stdout)
File "src/lxml/etree.pyx", line 2056, in lxml.etree._ElementTree.write
File "src/lxml/serializer.pxi", line 758, in lxml.etree._tofilelike
File "src/lxml/etree.pyx", line 318, in lxml.etree._ExceptionContext._raise_if_stored
File "src/lxml/serializer.pxi", line 682, in lxml.etree._FilelikeWriter.write
TypeError: write() argument must be str, not bytes

The grid layer consists of many single lines. If there isn't a reason against it, the extension could use Inkscapes method to combine all these lines to one single path.

Manually via: Menu -> Path -> Combine

The current way of deciding how big hexes to create is a bit obscure and not very flexible. Too much trial-and-error goes into creating a grid that properly fills the document (a pretty common use-case probably, or at least it is for me).

It should be possible to let the extension automatically calculate the number of rows and/or columns to use. Just leave out the numbers that should be calculated. At least one of the three must be given obviously, but that should be enough.

When I modify any value in the plug-in's pop-up dialog, I get an "Information" dialog window that says:

Inkscape has received additional data from the script executed. The script did not return an error, but this may indicate the results will not be as expected.

[Then inside a textbox within the window:]

  File "hexmap.py", line 136
    line.set("stroke-width", str(self.unittouu("%fin" % (1 / 90.0))))
                                                                    ^
TabError: inconsistent use of tabs and spaces in indentation

I have not yet been able to create a Hex map. I'm using the Ubuntu Inkscape package:

derek@dell-g3:~$ dpkg --list | grep inkscape
ii  inkscape                                   0.92.3-1                                        amd64        vector-based drawing program

When rotating the grid the hex size is calculated as the new height of the hexagons, resulting in smaller hexes than when not rotating the grid.

An option to define the border size would be nice.

Half hexes at top and bottom
Shift grid to side and wrap
First column half-hex down
Size of vertices

all should be moved from Coord to Style tab.

I just want to say that I find your extension useful and welcome.

I mention it in a blog post:

https://opensourcegamer.com/blog/blog/2020/09/21/i-need-a-hex-map/

So, keep up the good work.

I certainly appreciate it.

gizmo

When trying to create a hex-grid (using the default values), I get the error below:

The fantastic lxml wrapper for libxml2 is required by inkex.py and therefore this extension.Please download and install the latest version from http://cheeseshop.python.org/pypi/lxml/, or install it through your package manager by a command like: sudo apt-get install python-lxml

Technical details:
No module named lxml

But I have lxml installed:

$ sudo pip install lxml
Requirement already satisfied: lxml in /usr/lib/python3.7/site-packages (4.4.0)

And I can use it:

I'm using Anarchy Linux and these are the versions I'm using:

$ inkscape --version && python --version && uname -a
Inkscape 0.92.4 5da689c313, 2019-01-14
Python 3.7.4
Linux metztli 5.2.5-arch1-1-ARCH #1 SMP PREEMPT Wed Jul 31 08:30:34 UTC 2019 x86_64 GNU/Linux

I prefer spiked, or sharp endcaps on the line segments (i.e., thick at vertices, sharpening or tapering to a point as they finish, say at 10 or 15%). Is that a possibility? or is it doable in Illustrator in post? (I was only able to achieve it clumsily, with spikes often in wrong direction.)

Currently hexmapext generate the same amount of rows for each column.

Would you consider adding an option so that uneven rows could be generated.

For example instead of 17, 17, 17, 17, 17 rows, it would generate 17,16,17,16,17 rows.

I've briefly tried to hack this in myself, but I didn't get very far. The following sortof kinda has the effect I'd like:

if col % 2 == 0:
rows = rows + 1
else:
rows = rows - 1

However, this seems to break the vertices's at the outer edge.

The line /usr/bin/env python in hexmap.py might resolve to Python 3.x for some users (including me). The division for d in

then no longer returns an integer with Python 3, but a float value (as / is changed in Py 3). Which causes an issue for the return value. Replacing d = c / 26 with d = c // 26 fixes it and also works in Python 2.

The document has a size of DIN A1 and I let create 600 hexagons in columns:

It woud be nice if I was able to fill a standart A4 or A1 pages and with a margan on 20 mm for holes.
The scalling of Top - Botom is not working, but the Left - Right is.