Service Outage: Oct 31st

The travellermap.com site will be offline for several hours in the evening (Pacific Time) of Oct 31st, 2012.

The hosting provider is upgrading the host machine.


Good news everyone! Following the upgrade, my monitoring site is reporting 99.9% uptime, which is a significant boost. I'm not counting any chickens, but the new hardware/software has definitely improved things.



Image Regression Tests and Text Quality

I've started to put together a quick and dirty image regression test - an HTML page that will load a set of image pairs and generate a third image showing differences between the two so it's easy to spot changes - for example, if I intentionally moved a glyph up a few pixels (good) or introduced a bug so that gas giants stopped rendering (bad). If the images match perfectly, nothing shows up in the diff.

Call for input: what other URLs would be good to have in a corpus of tests as reference images?

While building this I compared my development machine vs. the live site, and was struck once again by how badly the text rendering is done on the server since it stands out in the image diffs. I was able to make a one line change which dramatically improves the text and glyph quality, so if you've saved off any bitmaps recently you probably want to redo them. It's embarrassing that I didn't do this earlier!

I also enabled CORS headers for image generating APIs, but that's probably not of use to anyone unless you're using WebGL to render map tiles or some such.



Style Tweaks

Another item crossed off the to-do list - borders and routes now have a maximum width when you zoom in, and text has a maximum font size. I'm actually not sure I'm totally happy with this, as it means that everything looks a bit spindly when you are at 256 pixels/parsec. So I'll probably revise things over time. Previously, once you hit 64 px/pc everything just got bigger, except for the UWP which appeared at 128px/pc (wedged in uncomfortably), so zooming was relatively "smooth", especially on touch devices. In any case, this doesn't affect anything at 64 px/pc and below, so most users won't notice.

Perhaps more subtle but affecting more users: I reduced the width of borders and routes very slightly and adjusted the shade of blue used for "wet" worlds to better match the Spinward Marches poster. I also tweaked the parameters for Candy style a bit and made its legend more relevant.

Additionally, I restored a fix that had been lost at some point: the images used in the legend are no longer rendered live but use static resources to reduce server load.


Since I was there, two more fixes:

  • Tweaked base positions so they're better positioned at every scale
  • Made sure sector borders are always thicker than subsector borders.



Rendering Order

Prolific nitpicker 77topaz pointed out that subsector names render on top of borders. That's not new, but I agree it's not ideal given that the subsector name is less critical than the world details at large scales. Sector and subsector names used to render at the same "layer". I've split them up.

Here's the new order, starting at the "back":
  • "nebula" background (Candy style only)
  • "galaxy" background (spiral arms)
  • pseudo-random stars
  • rifts (which black out the pseudo-random stars snd backgrounds)
  • "macro" borders
  • "macro" routes
  • sector grid
  • subsector grid
  • parsec grid (hexes)
  • subsector names
  • "micro" borders
  • "micro" routes
  • sector names - which need to be on top of borders/routes to be legible at relevant scales
  • "macro" capitals/home-worlds
  • "micro" government names
  • worlds
Changing the order is pretty straightforward so suggestions are welcome.

Note that individual words are rendered a hex at a time. In the future I'd like to do this in multiple passes, so that for example all zones are rendered, then all names so that zones don't overlap long names of neighboring hexes.

Unrelated: thanks to cubiq.org if you visit the touch map on an iOS device you'll now get a pop-up letting you know you can add it to your home screen as an application.



Cursors and Glyphs

More To-Do items To-Done:

  • The mouse cursor over the map is once again a crosshair. When you start dragging it will change to a drag-hand.
  • Per discussion in a previous post, base symbols have been overhauled and the legend has been updated. Following precedent in paper publications from the CT and MT eras, there is no attempt to make map symbols universally unique. For example, non-Imperial naval bases all use red stars  regardless of allegiance (Vargr, Aslan Tlaukhu, Solomani, Federation, K'kree, Droyne...). I've tried to follow established precedent wherever possible.
  • In addition to Research Stations, symbols are now rendered for Imperial Prisons (code: Pr), Imperial Reserves (code: Re) and Exile Camps (code: Ex), following the Spinward Marches Map symbology.



Base Codes

Hey folks, I need your help.

Base codes need some work. Here are some of the issues:

  • Droyne base codes P and Q don't have unique symbols
  • Solomani Naval bases (code F per David Pulver's updated Solomani Rim data) should have a red star to match Supplement 10
  • Generic naval base (classic code J) doesn't have a unique symbol
  • Generic scout base (classic code V) doesn't have a unique symbol
I put together a spreadsheet of base codes and symbols showing what the map uses today, what it should use, and what needs to be sorted out, as well as precedent from previous publications. Can you help suggest additions or corrections? Additional symbols can be used, although I'd prefer to mix/match the existing orthography and normal/highlight colors (i.e. white/red for poster style). Nothing crazy.

The "Pattern" column may merit some explanation. It is used to match Xx.B where Xx is the allegiance code and B is the base code. Symbols * and ? are wildcards (matching anything or one character, respectively), so A? is "any Aslan", V? is "any Vargr", and * is "anything". A suffix of >CD means that code B decomposes into two additional codes, for example code A in classic files is handled by the pattern Im.A>NS meaning "if allegiance is Imperial and code is A, that's really an Imperial Naval Base and Imperial Scout Base". Newer files may encode this as NS directly, so this is only needed in parsing older files.

Anyway... suggestions/corrections appreciated.