Far Frontiers! Borders! And more!

I've been working on a bunch of different pieces, some of which are "close enough" to roll out, others need additional work. But I need to get things out for users to try out and comment on, so here's an intermediate step.

Far Frontiers Sector

Before FASA lost its license to publish Traveller material, Dale Kemper was working on a manuscript for a supplement for the Far Frontiers, the setting for most of the FASA adventures like the Sky Raiders trilogy, Ordeal by Eshaar, etc. Didn't know that's where they took place? That's 'cause the supplement never came out! Parts were published in Ares magazine and somewhat more in the Traveller Chronicle, but those are hard to come by.

Dale has recently started selling copies of the manuscript on eBay (seller id: sbgames999) and I picked one up. Nice stuff, and it’s a shame it never saw the light of day. I asked Dale if I could include his Far Frontiers work in the map site, and he agreed!

(Note: Dale's manuscript covers just the lower half of the sector - the top half is mostly Zhodani space. For now I’ve just left the top half of the sector empty. Also note that the data is slightly inconsistent with other publications – Traveller Chronicle, Trail of the Sky Raiders, etc. – I’ve left it as close to Dale’s original manuscript as possible, rather than incorporating other sources or corrections. Those may come later.)

Borders

At long last (and thanks to pioneering work by J Greely over at http://dotclue.org/t20) accurate micro-scale borders are starting to see the light of day! Zoom in to 16 pixels/parsec or lower and the hand-drawn borders will disappear and (if you’re in the right place, e.g. near the Domain of Deneb or Gateway Domain) you’ll see hex-level borders. Yay!

Now for the down sides:

• The border generation is not complete. Although J Greely’s allygen is an amazing tool, it does only a single sector. Rather than modifying it to handle multiple sectors I’ve been adding outsector hex runs by hand. (And if that sentence made sense to you, please volunteer to help!) So it’s been slow – about 20 minutes per sector.
• Most of my resources are in storage – all of the DGP Travellers’ Digest issues I paid far too much for on eBay and classic sources are unavailable to me right now, so I have to go on guesswork and automated border generation.

But worst of all: the map is now a hideous amalgam of different eras:

• Some of the data files are Rebellion-era (1120 or so)
• Some of the data files are Classic-era (1100)
• Some of the data files are Gateway-era (M1000)
• Routes are whatever I could find, so mostly a mix of CT and RT
• Borders are based off of the data for the sector at hand

Data files from different eras aren’t immediately obvious – you have to drill in and notice that the Vargr really made a dent in Deneb but hardly touched Corridor! Even Routes are usually not obvious, unless there’s a gap. But mismatching borders stick out like sore thumbs. Bleah.

Poster

Someone on COTI mentioned that he stitched together the tiles for the whole Spinward Marches by doing screenshots of the site. Ouch! To prevent that necessity in the future, you can now ask for a render of a sector in one shot. Just do:

http://www.travellermap.com/Poster.aspx?sector=Spinward%20Marches

You’ll get a GIF of the whole thing at 64 pixels/parsec resolution. Change the sector name (replace spaces with %20 or +) or tack on &options=nnnn – use a permalink in the main map to figure out the combination you like. I like 833, which turns off the subsector names.

Other changes

• Added xboat routes for the Corridor sector from the map in FFE04 The Short Adventures - the Memory Alpha adventure reconstruction includes the routes on a hex grid of the sector (circa 1111), in addition to the Atlas of the Imperium sector copy - w00t! The Imperial xboat network now actually connects the Spinward Marches to the core!
• Since I was dorking around with Corridor, I used the data from FFE04 to "regress" the sector to the classic era. This makes the borders mismatch (especially with Deneb) but my goal for the map is Classic Era (or Second Survey) so I actually want the DoD connected!
• In Firefox/Safari/Opera, when dragging the map, you can now drag with the mouse over the non-map parts of the page and the mouse won't freeze. Just stay inside the page itself - there appears to a bug (feature?) afflicting all W3C event model browsers such that they stop giving you mouse events outside the page, if you started the drag over an image.
• I moved the Map Style options to the top, and slightly compressed the control options, to give more room for search results.
  

Ω

Bugfix: Oh, sectors are *forty* hexes tall?

Sharp-eyed user "alx alx" noticed that a search for "Herod" wasn't finding Hinterworlds 1940. I was out of town so I couldn't look at the code, but I played around and discovered that no worlds in the xx40's were being found by a search!

Turns out to be a simple off-by-one error in the enumerator code - I had a "y < 40" where there should have been a "y <= 40". Fixed! Ω

Atlas Permalink Bugfix

The new Atlas option was being saved to Permalinks and was respected in the map, but wasn't being properly respected in the map frame. That's fixed now. Ω

Add a map to your site!

I was browsing the Great TML Landgrab site and lamented the fact that many of the grabbee sites don't have maps showing where the systems are.

Now there's no excuse - just add the following line of HTML to your page, adjust the coordinates, and you've got a full fidelity map:

<iframe src="http://www.travellermap.com/iframe.htm?x=-95.914&y=70.5&scale=64&options=887" style="width: 200px; height: 200px; border: solid 1px black;"></iframe>

Note that it looks like a Permalink from the site, but with one subtle difference: "/iframe.htm" is specified rather than just the default page ("/"). This is a version of the map with no UI, specifically for embedding.

You can get the x/y by finding the system on my map site and using the "Permalink" feature in the footer - click it and it will give you the full permament URL of what you've got centered. Then copy/paste into the URL above - remembering to change the URL to include "iframe.htm"

You'll get something like this:



Note that it's a fully functional map - you can drag with the mouse and zoom by using the mouse wheel or double-clicking (hold Alt to zoom out).

Go wild!

Edited 2007-03-19 to call attention to the "iframe.htm" part of the URL necessary for embedding. Ω

How did you do that?

The map works the same way (I assume - I don't know for sure) as the latest generation of commercial map sites - Windows Live Local , Google Maps, Yahoo! Maps, etc. Which is...

There are two parts: an HTML page and a special Web server application.

There's an HTML page with script in it. The page keeps track of three things: where your view is centered (in my case, astrographic coordinates), what your zoom level is (pixels/parsec) and what view options you have selected (coded into a binary number). When the page loads it runs a simple subroutine that tries to answer the question: "gosh, what should the user see here?"

This subroutine first figures out how big the window frame is, then breaks it down into 256x256 pixel "tiles", and then figures out specifically which tiles it needs to fill the frame based on where the user is looking.

Here's an example tile URL:

http://www.travellermap.com/Tile.aspx?x=-1.2&y=-1.0&scale=2&options=881

(For historical reasons the x/y values are actually scaled by the zoom level, so if you change the zoom level your point of focus will change. Strictly speaking, the x and y are in screen space rather than world space, but it's all just a transform away.)

The HTML page then just says "add a tile image at this URL to the page at this position" - in HTML parlance, it just creates a new IMG element with a SRC like the above and and uses STYLE to position it. It does this until the window frame is full. Drag/scrolling is actually pretty easy - the page captures mouse events and when the mouse drags, say, 10 pixels to the left, it simply offsets the HTML element which contains all of the tiles by 10 pixels to the left. And then (here's the magic bit) it simply runs the whole logic all over again - "gosh, what should the user see here?" which determines if any new tiles need to get loaded around the edges. Any time you change options the same thing happens - it just throws away the images you're looking at and figures out which tiles to ask for.

That leaves the server side. In this case it's an ASP.NET 2.0 web application on IIS6, but you could do the same thing with pretty much any server. The nice thing about ASP.NET is that you get GDI+ (a high fidelity graphics subsystem of Windows) available easily, but again there are equivalents for PHP if you were doing this on Apache.

The web app handles the incoming request for a tile URL (like the above), creates a temporary image in memory, and falls into a big rendering routine. Based on the zoom level, it figures out what to draw - from the whole galaxy to borders and rifts to routes and dot-maps to hexes and systems. Based on that, it figures out which data files to load (from a cache) and it either loads XML vector shapes which define the borders/rifts, a big XML file which defines which sectors are where and the metadata, or (at a low level) the standard .SEC files. It figures out what subset of that should be drawn in the current tile and draws it. (The way modern graphics systems work, you can draw "sloppily" outside the bounds of a box and it'll get clipped. This is convenient - I just draw everything "close" to a tile, and the right stuff shows up.)

Then the server takes the image in memory, converts it to a GIF, and returns it to the Web browser. Rinse and repeat.

Make sense? Ω