<![CDATA[High Frontier Forums - Dev Log]]> http://highfrontier.com/forum/ Wed, 28 Oct 2026 18:38:13 +0000 MyBB <![CDATA[We're back!]]> http://highfrontier.com/forum/showthread.php?tid=221 Mon, 31 Jul 2017 11:02:13 -0700 http://highfrontier.com/forum/showthread.php?tid=221
Actually, "fled the country" is kind of close — we spent six weeks in Japan this summer.  We intended to continue working on High Frontier while there, but as it turned out, that just wasn't doable.

But we're back, and getting back on top of things now.  Expect to see regular updates resuming, including support for Steam coming real soon now!

So, if there is anything you'd especially like to see in the game, this is a great time to let us know!]]>
Actually, "fled the country" is kind of close — we spent six weeks in Japan this summer.  We intended to continue working on High Frontier while there, but as it turned out, that just wasn't doable.

But we're back, and getting back on top of things now.  Expect to see regular updates resuming, including support for Steam coming real soon now!

So, if there is anything you'd especially like to see in the game, this is a great time to let us know!]]> <![CDATA[0.27 is done and it's HUGE!]]> http://highfrontier.com/forum/showthread.php?tid=215 Fri, 05 May 2017 10:07:17 -0700 http://highfrontier.com/forum/showthread.php?tid=215

[Image: USvzMYz.png]

It's HUGE! Big Grin  We're very excited about all these little bits of spit'n'polish, and it was nice to take a break from deep physics code for a few weeks.  If you want any more details on any of the items above, feel free to poke around in the ticket list.

I'd love to push this out the door now, but we need to spend some time testing everything.  We'll get the new version to you just as soon as we're confident that it's ready!]]>

[Image: USvzMYz.png]

It's HUGE! Big Grin  We're very excited about all these little bits of spit'n'polish, and it was nice to take a break from deep physics code for a few weeks.  If you want any more details on any of the items above, feel free to poke around in the ticket list.

I'd love to push this out the door now, but we need to spend some time testing everything.  We'll get the new version to you just as soon as we're confident that it's ready!]]> <![CDATA[more good stuff this week]]> http://highfrontier.com/forum/showthread.php?tid=214 Sat, 22 Apr 2017 07:46:19 -0700 http://highfrontier.com/forum/showthread.php?tid=214
  • You can now go no more than $1M in debt, after which you can't spend any more money (except for summoning emergency services — that is always allowed).  And you can still zone, since zoning is free.
  • Improved the Clear tool in a number of ways: now shows what's going to be cleared and what it will cost, and cost varies now depending on what you're clearing.  Also, trees now fall over like trees, rather than being demolished like buildings!
  • Right-click can now be used to mean "done" in many contexts, such as finishing a path, or exiting a mode.
  • You can no longer make a cylinder with inverted endcaps that intersect each other.
I estimate we're another week or two from releasing 0.27.  We're pretty excited about it — a lot of small refinements like this make the game feel a lot better!]]>
  • You can now go no more than $1M in debt, after which you can't spend any more money (except for summoning emergency services — that is always allowed).  And you can still zone, since zoning is free.
  • Improved the Clear tool in a number of ways: now shows what's going to be cleared and what it will cost, and cost varies now depending on what you're clearing.  Also, trees now fall over like trees, rather than being demolished like buildings!
  • Right-click can now be used to mean "done" in many contexts, such as finishing a path, or exiting a mode.
  • You can no longer make a cylinder with inverted endcaps that intersect each other.
I estimate we're another week or two from releasing 0.27.  We're pretty excited about it — a lot of small refinements like this make the game feel a lot better!]]> <![CDATA[Stack of Donuts]]> http://highfrontier.com/forum/showthread.php?tid=212 Fri, 14 Apr 2017 09:50:45 -0700 http://highfrontier.com/forum/showthread.php?tid=212
This turned out to be a fairly specific problem with the secondary mirrors on torus and barbell parts not shading neighboring parts as they should.  That's fixed now, so this particular exploit won't work in version 0.27.

However you can still make a stack of donuts if you want, by adjusting the hub radius so as to push the secondary mirrors out:

[Image: Se5tBCd.png]


Why would you do this?  I'm not sure.  But you can! Smile]]>
This turned out to be a fairly specific problem with the secondary mirrors on torus and barbell parts not shading neighboring parts as they should.  That's fixed now, so this particular exploit won't work in version 0.27.

However you can still make a stack of donuts if you want, by adjusting the hub radius so as to push the secondary mirrors out:

[Image: Se5tBCd.png]


Why would you do this?  I'm not sure.  But you can! Smile]]> <![CDATA[busy day (NOT about the new physics engine)]]> http://highfrontier.com/forum/showthread.php?tid=209 Fri, 07 Apr 2017 15:01:08 -0700 http://highfrontier.com/forum/showthread.php?tid=209
[Image: QCIHu0C.png]

"Test" next to each of those means that it's fixed/implemented, and just waiting for final verification to be considered done.

If anybody's curious enough to want to know more about any of those, you can go to https://app.assembla.com/spaces/high-frontier/tickets and append the ticket number, e.g. https://app.assembla.com/spaces/high-frontier/tickets/238 .

We still have more on our to-do list, of course, but it feels good to have picked so much low-hanging fruit today, especially since we've been eyebrows-deep in physics code for so long!]]>
[Image: QCIHu0C.png]

"Test" next to each of those means that it's fixed/implemented, and just waiting for final verification to be considered done.

If anybody's curious enough to want to know more about any of those, you can go to https://app.assembla.com/spaces/high-frontier/tickets and append the ticket number, e.g. https://app.assembla.com/spaces/high-frontier/tickets/238 .

We still have more on our to-do list, of course, but it feels good to have picked so much low-hanging fruit today, especially since we've been eyebrows-deep in physics code for so long!]]> <![CDATA[new-physics update]]> http://highfrontier.com/forum/showthread.php?tid=204 Fri, 10 Mar 2017 10:27:07 -0800 http://highfrontier.com/forum/showthread.php?tid=204
[Image: 640px-Spacecolony1.jpg]

It's been a bit of a slog... the math is very dense, and it's a LONG walk from square 1 to where you can get anything at all to actually do anything.

But today we reached a bit of a milestone... we finally got a kinetic tree (that is, a set of connected rigid bodies) to move as expected.  This demo has two rigidbodies (three, if you count the stationary base) connected by two joints, with each joint revolving at a constant rate.

[Image: source.gif]

I know it doesn't look like much, but believe me, this is a victory!  It proves that at least some of all that code we've been writing for weeks works as intended.

Now we'll build on this, step by step, until we get those O'Neill cylinders working!]]>
[Image: 640px-Spacecolony1.jpg]

It's been a bit of a slog... the math is very dense, and it's a LONG walk from square 1 to where you can get anything at all to actually do anything.

But today we reached a bit of a milestone... we finally got a kinetic tree (that is, a set of connected rigid bodies) to move as expected.  This demo has two rigidbodies (three, if you count the stationary base) connected by two joints, with each joint revolving at a constant rate.

[Image: source.gif]

I know it doesn't look like much, but believe me, this is a victory!  It proves that at least some of all that code we've been writing for weeks works as intended.

Now we'll build on this, step by step, until we get those O'Neill cylinders working!]]> <![CDATA[What we're reading now]]> http://highfrontier.com/forum/showthread.php?tid=195 Tue, 17 Jan 2017 10:56:09 -0800 http://highfrontier.com/forum/showthread.php?tid=195
[Image: 518U2kSQP1L._SX322_BO1,204,203,200_.jpg]

This is all to equip us to fix this issue, though I can imagine some other great stuff that may come out of it.


So far, it seems like a really great book — well written, exceptionally clear, and with lots of pseudocode and examples.  It presents a very different approach to modeling physics than I've ever seen before; instead of dealing with linear and rotational motion separately, you mix them together, representing the state of an object with a single (six-dimensional) vector.

It looks like this approach simplifies the math (and the computer code!) quite a bit.  Pretty neat stuff!  If anybody has any interest in physics or simulation, I highly recommend it.]]>
[Image: 518U2kSQP1L._SX322_BO1,204,203,200_.jpg]

This is all to equip us to fix this issue, though I can imagine some other great stuff that may come out of it.


So far, it seems like a really great book — well written, exceptionally clear, and with lots of pseudocode and examples.  It presents a very different approach to modeling physics than I've ever seen before; instead of dealing with linear and rotational motion separately, you mix them together, representing the state of an object with a single (six-dimensional) vector.

It looks like this approach simplifies the math (and the computer code!) quite a bit.  Pretty neat stuff!  If anybody has any interest in physics or simulation, I highly recommend it.]]> <![CDATA[scratching our heads (again) about rotational dynamics]]> http://highfrontier.com/forum/showthread.php?tid=194 Fri, 23 Dec 2016 07:30:51 -0800 http://highfrontier.com/forum/showthread.php?tid=194

High Frontier correctly simulates colonies where most of the mass is contained in one big rotating part.  However, systems with multiple big rotating parts — like two cylinders side-by-side — are not correctly simulated.

[Image: 10029474534_d8ac7d8a81_b.jpg]

This is something we've wanted to handle correctly for a long time, and it has finally made it to the top of our to-do list.

We've just posted in a physics forum about it, but if there's anyone here who feels comfortable with kinetic energy and moments of inertia, please jump in wherever is convenient for you.  We really want to get this right!]]>

High Frontier correctly simulates colonies where most of the mass is contained in one big rotating part.  However, systems with multiple big rotating parts — like two cylinders side-by-side — are not correctly simulated.

[Image: 10029474534_d8ac7d8a81_b.jpg]

This is something we've wanted to handle correctly for a long time, and it has finally made it to the top of our to-do list.

We've just posted in a physics forum about it, but if there's anyone here who feels comfortable with kinetic energy and moments of inertia, please jump in wherever is convenient for you.  We really want to get this right!]]> <![CDATA[Difficulties detaching parts?]]> http://highfrontier.com/forum/showthread.php?tid=193 Fri, 09 Dec 2016 10:47:19 -0800 http://highfrontier.com/forum/showthread.php?tid=193
We knew what we wanted: to disconnect two parts, you grab one and drag it "away" from the other.  To move them as a unit, you drag in any other direction.  The goal is to let you grab, say, half of a stack of parts, separate it from the other half, and put it somewhere else.  Sounds simple, right?

Unfortunately, defining what "away" means precisely enough to code has proved troublesome.  Even we got confused about it sometimes, and resorted to just deleting and re-creating a sticky part.

I think we have finally fixed this!

Today we sat down and really worked through it carefully.  The problem was really one of asymmetrical situations, like this:


[Image: gibaxzf.png]


Here, dragging the highlighted box to the right would separate the two parts, but dragging the tube to the left would not.  This example may look a bit contrived, but the same sort of situation comes up fairly often with things like solar panels and comm dishes.

But now we've extended the code to handle just this sort of thing!  You can now separate these parts by grabbing either one, and dragging in any direction that could be considered "away" from the other part.  So grab the box, and drag to the right or up, and they pop apart.  Grab the tube, and drag it down or to the left, and again they disconnect.  Drag in any other direction, and they move as a unit.

We spent some time loading a bunch of complex designs from our test games, and dragging things around.  I'm happy to say that the feeling here is sheer delight; not once did we find a case where parts were stuck stubbornly together, or where they fell apart unexpectedly.

Coming soon in version 0.26... we can't wait to hear what you think of this!
]]>
We knew what we wanted: to disconnect two parts, you grab one and drag it "away" from the other.  To move them as a unit, you drag in any other direction.  The goal is to let you grab, say, half of a stack of parts, separate it from the other half, and put it somewhere else.  Sounds simple, right?

Unfortunately, defining what "away" means precisely enough to code has proved troublesome.  Even we got confused about it sometimes, and resorted to just deleting and re-creating a sticky part.

I think we have finally fixed this!

Today we sat down and really worked through it carefully.  The problem was really one of asymmetrical situations, like this:


[Image: gibaxzf.png]


Here, dragging the highlighted box to the right would separate the two parts, but dragging the tube to the left would not.  This example may look a bit contrived, but the same sort of situation comes up fairly often with things like solar panels and comm dishes.

But now we've extended the code to handle just this sort of thing!  You can now separate these parts by grabbing either one, and dragging in any direction that could be considered "away" from the other part.  So grab the box, and drag to the right or up, and they pop apart.  Grab the tube, and drag it down or to the left, and again they disconnect.  Drag in any other direction, and they move as a unit.

We spent some time loading a bunch of complex designs from our test games, and dragging things around.  I'm happy to say that the feeling here is sheer delight; not once did we find a case where parts were stuck stubbornly together, or where they fell apart unexpectedly.

Coming soon in version 0.26... we can't wait to hear what you think of this!
]]> <![CDATA[Rings Around Uranus]]> http://highfrontier.com/forum/showthread.php?tid=188 Thu, 17 Nov 2016 18:17:04 -0800 http://highfrontier.com/forum/showthread.php?tid=188

The colony here is actually orbiting one of the many minor moons of Uranus... looks an asteroid.  But I couldn't fit Uranus and the moon in the shot at the same time, and the planet is far prettier.

Everything is to scale; Uranus here is about 250,000 km away.]]>

The colony here is actually orbiting one of the many minor moons of Uranus... looks an asteroid.  But I couldn't fit Uranus and the moon in the shot at the same time, and the planet is far prettier.

Everything is to scale; Uranus here is about 250,000 km away.]]> <![CDATA[Jupiter and Saturn orbits]]> http://highfrontier.com/forum/showthread.php?tid=175 Fri, 14 Oct 2016 10:55:02 -0700 http://highfrontier.com/forum/showthread.php?tid=175
This has been challenging because there are so many great places to build out there — way more than we can reasonably include.  So, we're focusing on just the most important ones.  That includes the four largest moons of Jupiter, and the three biggest around Saturn.  Plus, around each gas giant, we're including a generic "minor moons" orbit you can choose.  Much like the main asteroid belt, this will place your colony around a smaller, randomly chosen hunk of rock and ice.

[Image: EJFihOe.png]

Of course in a standard game, these orbits won't be available until you've completed the required Projects.  Onward and outward!]]>
This has been challenging because there are so many great places to build out there — way more than we can reasonably include.  So, we're focusing on just the most important ones.  That includes the four largest moons of Jupiter, and the three biggest around Saturn.  Plus, around each gas giant, we're including a generic "minor moons" orbit you can choose.  Much like the main asteroid belt, this will place your colony around a smaller, randomly chosen hunk of rock and ice.

[Image: EJFihOe.png]

Of course in a standard game, these orbits won't be available until you've completed the required Projects.  Onward and outward!]]> <![CDATA[working on asteroids]]> http://highfrontier.com/forum/showthread.php?tid=166 Fri, 09 Sep 2016 15:22:28 -0700 http://highfrontier.com/forum/showthread.php?tid=166
So we're going to need some asteroids!  We started today working on generating these procedurally, so that there would be an essentially limitless supply of unique asteroids.  Here's what our first afternoon of work has produced...


[Image: c51iXSH.gif]

There's a lot more work to do, of course, but it seems like a decent start.  What do you think?
]]>
So we're going to need some asteroids!  We started today working on generating these procedurally, so that there would be an essentially limitless supply of unique asteroids.  Here's what our first afternoon of work has produced...


[Image: c51iXSH.gif]

There's a lot more work to do, of course, but it seems like a decent start.  What do you think?
]]> <![CDATA[Any interest in translating High Frontier to your native language?]]> http://highfrontier.com/forum/showthread.php?tid=165 Fri, 09 Sep 2016 08:29:06 -0700 http://highfrontier.com/forum/showthread.php?tid=165
We're planning localization support, both built-in and through mods.  But it'd be great to do this in collaboration with some actual players who are fluent in some other language.

So: Parlez-vous français?  ¿Hablas español?  日本語を話せますか？  क्या आप हिंदी बोलते हैं?  If so, please let us know!]]>
We're planning localization support, both built-in and through mods.  But it'd be great to do this in collaboration with some actual players who are fluent in some other language.

So: Parlez-vous français?  ¿Hablas español?  日本語を話せますか？  क्या आप हिंदी बोलते हैं?  If so, please let us know!]]> <![CDATA[The bigger they are, the more dust they make when you demolish them]]> http://highfrontier.com/forum/showthread.php?tid=157 Fri, 08 Jul 2016 11:20:28 -0700 http://highfrontier.com/forum/showthread.php?tid=157
[Image: s3ONLiK.gif]

(The dust suffers a bit from the video compression; it looks even better in the actual game!)]]>
[Image: s3ONLiK.gif]

(The dust suffers a bit from the video compression; it looks even better in the actual game!)]]> <![CDATA[sneak peek at building printer]]> http://highfrontier.com/forum/showthread.php?tid=156 Thu, 30 Jun 2016 15:54:16 -0700 http://highfrontier.com/forum/showthread.php?tid=156
[Image: 3hYmSIX.gif]

(Mind you, that's a big file, so it may take a moment or two to load.)

Cheers,
- Joe]]>
[Image: 3hYmSIX.gif]

(Mind you, that's a big file, so it may take a moment or two to load.)

Cheers,
- Joe]]> <![CDATA[Version 0.23 Progress report]]> http://highfrontier.com/forum/showthread.php?tid=154 Thu, 19 May 2016 08:07:14 -0700 http://highfrontier.com/forum/showthread.php?tid=154
[Image: SlBS44C.jpg]

This release is going to introduce emergencies & disaster response.  But that means we need a way to calculate (and for you to see) what areas are most susceptible to fire or crime, and while we're at it, we're calculating land values too (since those are all interrelated).  So we've developed heat-map style overlays you can turn on and off via the Statistics palette Econ tab, as shown above.

When an emergency does happen, you'll get a notification that includes an event marker.  When the emergency location is on screen, the marker points right at it; otherwise, it points in the direction of the event so you can quickly find it.  Then you can dispatch fire-fighters, police, or engineers to the scene (the dispatch call is represented by a big flashing beacon, which is that lamppost-looking thing in the screen shot below).

[Image: UZVvWQU.png]

The police beacon shown here actually causes the nearest police cruiser to come investigate.

So, great progress!  But there is still a lot to do: the police investigation doesn't actually help in any way (no comments about that being realistic, please!); crimes don't actually happen yet unless you trigger them with a console command; and there are no fire or impact disasters yet.  Fire should be especially interesting because we will want to render flames and smoke on the affected building, and have it spread to nearby structures if you don't contain it quickly enough.

Fortunately, summer vacation's almost here, which means my workforce will increase a bit!  We're going to work really hard on polishing up High Frontier over the next few months.

Please keep playing, and let us know what features or improvements you most want to see!]]>
[Image: SlBS44C.jpg]

This release is going to introduce emergencies & disaster response.  But that means we need a way to calculate (and for you to see) what areas are most susceptible to fire or crime, and while we're at it, we're calculating land values too (since those are all interrelated).  So we've developed heat-map style overlays you can turn on and off via the Statistics palette Econ tab, as shown above.

When an emergency does happen, you'll get a notification that includes an event marker.  When the emergency location is on screen, the marker points right at it; otherwise, it points in the direction of the event so you can quickly find it.  Then you can dispatch fire-fighters, police, or engineers to the scene (the dispatch call is represented by a big flashing beacon, which is that lamppost-looking thing in the screen shot below).

[Image: UZVvWQU.png]

The police beacon shown here actually causes the nearest police cruiser to come investigate.

So, great progress!  But there is still a lot to do: the police investigation doesn't actually help in any way (no comments about that being realistic, please!); crimes don't actually happen yet unless you trigger them with a console command; and there are no fire or impact disasters yet.  Fire should be especially interesting because we will want to render flames and smoke on the affected building, and have it spread to nearby structures if you don't contain it quickly enough.

Fortunately, summer vacation's almost here, which means my workforce will increase a bit!  We're going to work really hard on polishing up High Frontier over the next few months.

Please keep playing, and let us know what features or improvements you most want to see!]]> <![CDATA[Articulated squad car model]]> http://highfrontier.com/forum/showthread.php?tid=147 Mon, 04 Apr 2016 10:20:38 -0700 http://highfrontier.com/forum/showthread.php?tid=147
[Image: hZHMq.jpg]

You can play with it yourself here.]]>
[Image: hZHMq.jpg]

You can play with it yourself here.]]> <![CDATA[Emergencies & Disasters]]> http://highfrontier.com/forum/showthread.php?tid=145 Sat, 19 Mar 2016 06:59:10 -0700 http://highfrontier.com/forum/showthread.php?tid=145
  • fire
  • crime
  • hull breach
These are in addition to the slow problems that can already develop (CO2 imbalance, insufficient clean water, etc.).  We may also throw in a need for hospitals, depending on the population, which isn't really an emergency, but falls under the same sort of municipal services.

Any other ideas for sudden emergencies we should consider?  Rogue giant robots?  Science fair projects gone awry?  Let's brainstorm!]]>
  • fire
  • crime
  • hull breach
These are in addition to the slow problems that can already develop (CO2 imbalance, insufficient clean water, etc.).  We may also throw in a need for hospitals, depending on the population, which isn't really an emergency, but falls under the same sort of municipal services.

Any other ideas for sudden emergencies we should consider?  Rogue giant robots?  Science fair projects gone awry?  Let's brainstorm!]]> <![CDATA[Pathfinding in a wrap-around world]]> http://highfrontier.com/forum/showthread.php?tid=141 Sat, 12 Mar 2016 06:24:56 -0800 http://highfrontier.com/forum/showthread.php?tid=141 this little issue, where sometimes we see a resident walking off across the lake (or otherwise going where nobody should be).

And wow, that turns out to be one deep rabbit hole!

The problem is that path-finding and navigation in a cylindrical coordinate system (which applies to torus and sphere habs in High Frontier, as well as cylinders of course) is a whole lot more complicated than normal path-finding.  Every point has an infinite number of equivalent coordinates.  For example, if your cylinder is 100 units around, then a point at X=10 is the same as X=110, X=-90, X=210, and so on.

We were normalizing all coordinates (basically using modular arithmetic) to get all the coordinates into a standard range, but that doesn't work correctly in some cases.  A little path from X=90 to X=110 ends up looking like a big path from X=90 to X=10, and then we find a ton of intersections with that and other paths which are halfway around the cylinder.  Bad mojo.

We've just about got our heads wrapped around it now; it's all solvable, but tricky.  There's been surprisingly little written about this situation, so we will be doing at least a blog post, if not a tech report, once we have it all sorted out!

- Joe]]> this little issue, where sometimes we see a resident walking off across the lake (or otherwise going where nobody should be).

And wow, that turns out to be one deep rabbit hole!

The problem is that path-finding and navigation in a cylindrical coordinate system (which applies to torus and sphere habs in High Frontier, as well as cylinders of course) is a whole lot more complicated than normal path-finding.  Every point has an infinite number of equivalent coordinates.  For example, if your cylinder is 100 units around, then a point at X=10 is the same as X=110, X=-90, X=210, and so on.

We were normalizing all coordinates (basically using modular arithmetic) to get all the coordinates into a standard range, but that doesn't work correctly in some cases.  A little path from X=90 to X=110 ends up looking like a big path from X=90 to X=10, and then we find a ton of intersections with that and other paths which are halfway around the cylinder.  Bad mojo.

We've just about got our heads wrapped around it now; it's all solvable, but tricky.  There's been surprisingly little written about this situation, so we will be doing at least a blog post, if not a tech report, once we have it all sorted out!

- Joe]]> <![CDATA[Types of paths]]> http://highfrontier.com/forum/showthread.php?tid=140 Thu, 03 Mar 2016 08:08:26 -0800 http://highfrontier.com/forum/showthread.php?tid=140
We are going to be adding at least two, maybe three more path types, and possibly changing that one.  All this has led to some research into path types in both urban and rural settings.

This blog has some interesting musings on path types by their usage ("Of 10 path types, only 8 are for walking").  Lots of interesting food for thought there.

One thing that has occurred to us recently is that with the coming of delivery drones, roads and vehicles in a space colony are probably even less necessary than previously thought.  The main reason to have them, in a city at least, is to move heavy things around... but if you can do that through the air, then you don't need to congest the ground any more.  Of course this assumes some sort of mass-transit system that can move people (and handheld packages) more effectively than just walking around.  We'll get to that too, though probably not in the next release.

Still, if anybody here has an interest in urban architecture, please chime in!  We'd love to hear your thoughts.]]>
We are going to be adding at least two, maybe three more path types, and possibly changing that one.  All this has led to some research into path types in both urban and rural settings.

This blog has some interesting musings on path types by their usage ("Of 10 path types, only 8 are for walking").  Lots of interesting food for thought there.

One thing that has occurred to us recently is that with the coming of delivery drones, roads and vehicles in a space colony are probably even less necessary than previously thought.  The main reason to have them, in a city at least, is to move heavy things around... but if you can do that through the air, then you don't need to congest the ground any more.  Of course this assumes some sort of mass-transit system that can move people (and handheld packages) more effectively than just walking around.  We'll get to that too, though probably not in the next release.

Still, if anybody here has an interest in urban architecture, please chime in!  We'd love to hear your thoughts.]]>