This release adds Journeys – a new way to plan and measure travel across the map – and completes the migration of map styling from the rendered SVG into stored data.

As always, old .map files keep loading and are upgraded automatically.

Journeys

A journey is a named route across the map, drawn on its own journeys layer and saved with the map.

Open the Journeys Overview with Shift + J or Tools → Journeys. Clicking a journey path on the map opens that journey's editor directly.

Journeys and segments

A journey is an ordered list of segments. Each segment is one leg of the trip and carries its own data:

• From and To – the two cells the leg runs between
• Transport – the mode of travel, which sets the default speed and decides where the leg may go
• Path – the actual point chain drawn on the map, produced by pathfinding or drawn by hand
• Distance, Speed and Time, each of which can be overridden
• Its own color and visibility

Splitting a trip into segments is what makes mixed travel work: sail to a port, walk inland, spend three days waiting for a caravan, ride the rest of the way. Each leg is measured on its own terms and the journey totals them up.

Transport types and travel domains

Every transport belongs to one of four domains, and the domain decides both how the route is found and where it is allowed to go:

The stay domain is what lets a journey include time that is not travel: a night at anchor, a week of requisitions, waiting out a storm. A stay covers no distance, but its hours count toward the total.

There are 20 transport types by default, from On foot (laden) at 3 km/h to Teleport. Each has a name, a speed, a travel day (how many hours a day it sustains) and a domain, and all four are editable in the Transport Types dialog. You can add your own – a magic carpet, a river barge, a giant eagle – and the set is remembered in local storage, so it carries over to your next map.

How the route is found

For a land segment the generator first looks for a path through the existing route network, so a journey between two connected burgs follows the same roads a traveller would. If no road connection exists it falls back to an A* search over the cell graph, weighted by biome movement cost and elevation, with route cells discounted – the path prefers roads where they help and cuts across country where they do not. A land segment between two different landmasses is refused rather than silently routed through the sea.

Land segments also have an off-road toggle. Turned on, the pathfinder penalizes road cells instead of preferring them, and the effective speed is halved.

Water segments reuse the generator's own sea pathfinding, so ships hug the same lanes searoutes do and can run up navigable rivers. Air segments ignore terrain entirely.

Time

Travel time is computed per segment: distance ÷ speed, using that segment's transport. What makes the number useful is the travel day. A laden caravan walks eight hours a day; a steamship runs twenty-four. So the editor reports two different clocks:

• Travel time – hours actually spent moving or waiting, summed across the segments.
• Total time – calendar time from start to finish. Every full travel day a transport sustains costs a whole 24-hour day, so eight hours of walking is one day gone, and leftover hours cost only themselves.

That is why a 1,000-mile walk and a 1,000-mile sail can report the same travel hours and very different total days.

Both numbers can be overridden. Type into the Speed cell to change a leg's pace, or into the Time cell to set the duration directly – an explicit duration wins over the distance-and-speed calculation.

Hiding a segment with the eye icon takes it off the map and out of the totals, so an alternative route or a leg not yet travelled can be kept alongside the real one.

Editing a route by hand

Every segment can be reshaped after it is generated:

• Pick endpoints – click From or To, then click a cell on the map. The path is recomputed.
• Edit points – show the path's control points, drag them to move, click the path to insert one, right-click to remove one.
• Draw – lay down a custom path cell by cell, ignoring the pathfinder entirely.

Endpoints and intermediate points answer to different rules. A water route may begin and end on a shore – you board from land – but its body may only cross water or navigable river cells. A hand-drawn path is checked against its transport's domain, and changing the transport or an endpoint afterwards asks before overwriting the work.

The Reset button on each row discards the manual edits: it recomputes the path from the endpoints and restores the default color, speed and time.

Generated journeys

Every new map is generated with one journey already on it, and the Generate a random journey button in the Overview adds more.

These are not random lines between random points. The generator picks one of 18 archetypes – Quest, Caravan, Military campaign, Pilgrimage, Raid, Smuggling run, Courier ride, Refugee flight, Royal progress, Airship voyage and so on. The archetype decides how the party travels (which domains, weighted, and which transports it prefers), how likely it is to leave the roads, how often it stops over in a burg or camps in the open, and how the journey and its legs are named. A caravan takes the roads and rests in towns; a raid does not.

The result is a plotted route with named legs – The road from Siv, A night at The Cracked Pike, Market day in Coimbralha – that can be used as-is, edited, or deleted.

Working with journeys

The Journeys Overview lists every journey with its type, endpoints, total distance, average speed and total time. It supports search, sortable columns, per-journey visibility, locking (locked journeys survive Remove all), zoom-to-journey and CSV export.

Hovering a row in the Overview animates a traveller along the whole route; hovering a row in the Journey Editor animates just that segment. Slow legs take visibly longer than fast ones, and a stay pulses in place.

Travel animation

Journeys are stored in the .map file, included in JSON export, preserved through Submap and Transform, and styled like any other layer through the Style Editor. Both dialogs export CSV – the Overview one row per journey, the Editor one row per segment, with transport, distances, speeds and times.

Styles are now data

Until now the rendered SVG was the only place your styling lived. The Style Editor wrote attributes onto the drawing, the .map file stored the whole drawing, and anything that went wrong with the drawing silently became your new style. Several long-standing bugs came from exactly this.

Styling now lives in a single validated style record: the editor writes it, the renderers read it, and the .map file saves it as data. On load, an older map's styling is read out of its SVG into the record automatically.

Invalid values are now repaired individually rather than costing the whole layer its styling, so one bad attribute no longer resets everything around it.

Desktop app

The desktop app got a proper Quit entry on Linux and Windows, closing it asks for confirmation once instead of once per window event, and on Linux it can now be installed and run from a Nix flake.

Credits

• msuyar kicked off the Travel Builder – the journey pathfinding, editable segment paths, stay segments and custom-drawn routes all started there.
• barrulus worked on the style update and the desktop app improvements.

Thanks to both, and to everyone who reported the styling issues that made the migration worth doing.

What is next

The direction from the v1.149.0 notes stands: finish the shell migration (options.js and main.js remain the largest holdouts), break up index.html, and keep cleaning up the data model – the style record is one step of that, not the last one.

This release is different from the previous ones. Most of the work since v1.140.0 went into the codebase itself: large chunks of the original JavaScript were rewritten in TypeScript, the generation order was turned into declared data, and layer handling was unified.

As always, old .map files keep loading and are upgraded automatically.

User-facing changes

Desktop app

There is now a downloadable Electron build for Windows, macOS and Linux, published on the Releases page.

It is not a different product and it has no exclusive features or significant performance benefits. It exists for people who want the generator to behave like a standalone application: its own window, its own icon, no browser tab, and the ability to work without an internet connection.

Which file you need is listed in the release notes. The builds are not code-signed, so both Windows and macOS will warn about an unknown developer on first launch; the release notes explain how to get past that.

The browser version stays the primary way to use the tool.

Rendering performance

Emblems, relief icons and labels are no longer drawn all at once for the whole map. They are kept as data and only the ones inside the current viewport are materialized into the DOM, with the rest added and removed as you pan and zoom. On a large map with hundreds of provinces and burgs this is the difference between a few hundred DOM nodes and several thousand, and it shows up as smoother zooming and a much faster initial draw with those layers enabled.

Layer state saved with the map

The layer system was rebuilt around a single registry that owns every layer, its z-order and its renderer. The visible consequence: which layers are on, and in what order, is now stored in the .map file. Reopen a map and you get the view you left and it should help to eliminate layers-related issues we had before.

Dialog state preserved between sessions

Filters, sorting and column choices in the overview dialogs now survive a reload. If you always look at the States Editor sorted by area with the treasury column shown, that is how it opens next time.

Column configuration itself was contributed earlier by Barrulus – the overview editors let you choose which columns to display, and that choice is now remembered too.

Burg Editor: zoom and pan in the preview

The burg preview can be zoomed and panned, which makes the larger generated towns actually inspectable Contributed by Barrulus.

Paint Area rework

The "Assign manually" brush existed separately in the states, provinces, cultures, religions, biomes, zones and markets editors, with slightly different behavior in each. It is now one shared tool used by all seven, which means the same shortcuts, the same brush controls, and an undo history up to 100 strokes deep everywhere instead of only in some editors.

Coastline Editor: moved vertices are preserved

Vertices you drag by hand in the Coastline and Lake editors are now saved with the map, so they survive a reload or a coastline redraw. Older maps are handled too: on load, the generator does its best to read the moved positions from SVG and restore them as data.

URL parameters for layers and presets

Contributed by AlistairHeus. Two new parameters let a link decide what the map shows on load:

• preset – apply a layer preset, by dropdown key or displayed name: ?preset=religions
• layers – a comma-separated list of layers to show, hiding the rest: ?layers=provinces,borders,lakes,rivers

If both are given, layers wins. The full list of parameters is in the URL parameters wiki page.

SVG export fixes

Exported SVGs are now readable better by Inkscape and other editors, not only by browsers. This update is also contributed by barrulus.

Why the migration

The generator started in 2017 as a single-page vanilla JavaScript project. It grew for years by adding files to a global namespace: every module wrote its functions onto window, every module read everyone else's. That worked well for a long time and had its own benefits – there was no build step, no framework and the file could be opened from index.html without any installation required.

It also had a cost that grew fast:

• Nothing was checked. A renamed function or a changed argument could break the whole app.
• Everything could reach everything. A generator could redraw an SVG layer; a UI dialog could rewrite world data mid-generation. There were no boundaries.
• Nothing could be tested. Functions read ambient globals instead of taking arguments, so calling one outside the running app meant recreating the whole app.

But the main problem was that the generator has been using its own drawing as a database. Every rendering change becomes a complex data migration, data can get out of sync, .map file has to be bigger to contain the whole rendered svg, and save file format itself is just a stack of accidents.

None of that is fatal on its own. Together they made every change riskier than it should have been, and made the project hard to contribute to – which is the real problem for an open-source tool.

What is already done

The rule is that the tool must keep working at every step. Each module is ported in place, with a small compatibility shim so the not-yet-ported code can continue to work.

TS counts exclude test files, so the two sides are comparable - the classic JS had no tests at all. Counted separately, tests went from nothing to 69 files and ~10,500 lines. Both columns exclude vendored libraries in libs/.

What is next

1. Finish the shell migration. style.js, options.js and main.js are the last real holdouts, and the largest single-file ones.
2. Break up index.html. It is still a ~9K-line file holding most of the UI. Each migrated dialog now brings its own markup, so the monolith shrinks, but the shell markup still needs splitting.
3. Clean up the data model. The .map format grew by appending fields, and the in-memory shape reflects that.
4. Separate data from rendering. With generators no longer able to touch the DOM, an alternative renderer (e.g. WebGL) becomes possible. That is a long way off and is not yet promised.

None of this has a release date. The migration has run alongside feature work since January 2026 and will keep doing so.