It doesn't hurt to ask!
Post Mar 03, 2018 13:44
This was talked about in a different forum but I'd just like to officially make the suggestion so it's documented in case it ever bubbles to the top of the priority list.

Personally I'd use this for roads and possibly rivers on my hex maps but I'm going to make the suggestion as generic and simple (as in complexity of the description NOT ease of implementation... I have no idea how hard it would be to actually make happen) as I can (looking down now that I'm done it's still pretty darn long... sorry but this is as simple as I could think of)

The "lines" layer would be a third layer as I understand it that could move up and down with respect to the existing "terrain" and "marker" layer. I'd personally put it between the two for my purposes but others may have uses for it elsewhere.

Each "line" on the layer would be make up of segments that connect the hex/square center point with either a vertex or an edge midpoint. On a square map this means a single line segment could be from the center straight up, down, right, or left; or any of the four diagonals. Each square/hex could have 0 to all of these segments (or anything in between). So in the case of a single square with them ALL it would be visually an X and a + in the square for a total of 8 segments. In a hex there would be 12 possible segments. Each segment could have it's own color (color picker) and width (from 1 pixel to the size of an edge... if this would need to be independent from the grid and based on tile size instead then the smaller hex edge size would be used as the upper limit of both)

Drawing lines: When the user clicks a hex/square with the line tool a segment is created starting at the nearest control point (edge midpoint, vertex, or center point) and extending to the cursor with the color/size specified in the drawing tool properties. If the start/previous point is the center then as the user drags the cursor to the shape perimeter the tool would snap the line from the tool the nearest perimeter control point (vertex or edge midpoint) when the cursor hits the perimeter. If the user continues to drag beyond the perimeter into another square/hex the tool would create a new segment in the same color/size as the previous but to the center point in such a way the segments would always alternate center to perimeter or perimeter to center (no single center to center segment but it's possible visually using two segments. No perimeter point to perimeter point along an edge, there's already a tool that does edge lines which is different from this suggestion). If the start/previous point of the segment is a perimeter point then as the user drags the new segment being created would snap to the center point when the user drags from the perimeter at least 1/4 the tile size. While a bit complex to explain this could be done across many hex/squares in one simple drag motion by the user so they don't have do click for each tiny segment.

It would thus be possible in a simple example using a square map for ease of explanation to draw one line that's made of two segments (in the example square) that comes in from the W to the center to the NE and is blue (with one width) for a river and on through other squares in both direction and also a different line made up of two segments (in the example square) that comes in from the NW to the center to the S and is brown (with a different width) and on through other squares in both directions. The user would draw these features (road or river) with a single stroke that spans multiple squares with the tool laying down the required segments as they go.

Deleting lines: Lines could be deleted either one segment at a time or with a fill type delete that deletes all connected segments with the same size, color properties. This would allow the user to use the single segment delete to drag the eraser tool segment by segment. It would also allow in complex maps with many interconnected lines the user to wipe away large chucks with the matching connected size/color delete. For delete needs in the middle the user could delete key segments to disconnect a section of matching lines from the rest and then use the flood delete to wipe out larger sections once disconnected without getting EVERYTHING of that type and without having to go segment by segment. There could also be an overall clear layer that would nuke all the lines of all styles at once.

Z-order: If there are a number of different style lines on the layer there could be "bring to front" and "push to back" tools that work on all matching color/size lines (connected or not). This would allow the user to ensure the "roads" are on top of the "rivers" within the layer for example.

Again while I'd personally use this for roads/rivers on my hex maps I think the suggestion is generic enough being just "lines" that other users could find many other uses for this capability.
Post Mar 07, 2019 18:00
First slighty off-topic: Thanks for sharing my map tweet!

Anyway the "roads" issue this post was an attempt to address in a generic way is really troubling me now as I have my maps near perfect except roads...

I don't care if it's implemented in the way prior post describes, that was just me trying to constructive and come up with a generic feature that could do what I want but conceivably be used by others for other things.

At the end of the day I just want roads on my map that go from the center of a hex to the center of an edge and can be chained without seams across hexes. This is what I've tried:

Make "markers" for the roads. I don't want my tree, mountain, swamp, etc. "marker" on a road tile anyway so putting it at as a marker seemed like something to try. Issues:
  • I need a different marker for every combination of center to edge which means 63 (2^6-1) markers just for roads.
  • I can't seem to get the diags to line up and make a seemless straight line.
  • I DO need the city markers to be on top of the roads but you can't have two markers in the same hex. if I make combined markers too then I'd need a 63 * number of city type markers (currently 3) for the cities as well.
I also tried to just export the map as a PNG and add the roads in post production... the issues there:
  • The roads don't automatically snap to the hex grid
  • The roads draw over the hex gridlines
  • The roads draw over the city markers
  • As post production I'd have to keep redoing this every time I export
I'm certainly open to any other ideas people have to get these roads in.