Sorry, guys.  It’s been a boring couple of days where I’ve been working behind the scenes, fixing things that appeared to be working in the previous screenshots, but actually weren’t, quite.  Here’s a rough list:

• UI Button mouseover/dragover now works properly if the cursor moves between 2D and 3D parts of the screen.  (2D UI mouseover state wasn’t working properly if the cursor moved over part of the 3D scene).  This involved refactoring a lot of the old cursor control logic which was brought in from MMORPG Tycoon v1.1.
• Cursor Behaviours which have custom draw functionality (such as the outline display used for the building placement, and the “terrain brush” for painting on the terrain) no longer have that draw functionality called when the cursor is hovering over a 2D UI interface.  (Fixes building outlines being drawn on the terrain when your cursor isn’t in a place where clicking would actually create the building)
• Buildings and ActionBars now create their own “build this building” and “display this action bar” powers, instead of needing those to be separately declared in data files.  Not sure if this is entirely the right solve long-term, but it requires less fiddling with data files in the short term, so I’m doing it for now.  It’ll be easy to switch this back, if necessary.
• ActionBar buttons now support “tooltips” which appear when you hover over them.  These tooltips are can be defined in data, or in code.  (Currently, they’re all defined in data).  These are using the old “Tooltip” functionality from MMORPG Tycoon v1.1, just adjusted to use a bitmap font instead of the vector font.  These aren’t going to be the final tooltips;  the final tooltips will need a lot more space than these provide.  But for milestone one, they’ll do fine for letting people know what the different placeholder UI icons mean.
• Massive restructuring of all UI button drawing code.  As this code was inherited from the v1.1 version, it wasn’t really set up in a good way for v2.0;  it worked, but it was violating lots of the “best practices” about how VectorStorm display lists should now be constructed.  I’d still like to switch these from using static vertex arrays to using VBOs instead, but at least they’re not messing around with the material system’s innards any more.  Further fixing of this button drawing code should wait until M2 or later.
• Quest target arrows now remove themselves from the scene after retracting.  (Previously, they hung around, infinitely short, so you’d just have a horizontal white line glowing above the quest giver).  I’m still a little nervous about how I’ve hooked up these target arrows;  feels like it’s breaking encapsulation, since some of the cleanup logic is on the arrow.  But it’ll do for now.
• Quest editing display can now be closed again.  Previously, once it was open, it was open forever.  Now you can click on the quest button a second time to close the quest editing display.  Or alternately, you can click on a different quest to edit that other quest.  This has all been wired up with a bunch of “Quest Edit” powers, which work exactly like the various “Construct a Building” powers and the various “Open an Action Bar” powers.
• Again, since the quest editing is now wired up through the “powers” system (which can automatically handle turning things off, in addition to turning them on), it means that when the quest list action bar is hidden, the quest editing interface also automatically vanishes.

Full list of stuff left to do for M1:

• Implement add/remove quests on a quest giver.
• Add a button + cursor behaviour to let the player set the quest destination for each quest on the quest giver.
• Implement UI to let the player set Hunt/Fetch quest type for each quest on the quest giver.
• Interface to set the quest giver’s level (Should this be set on the quest giver, or on individual quests, or maybe on grinding areas?  Grinding areas might actually be the best place to set it;  then hunt quests can inherit their level from the grinding area they’re targeting, and this would allow a single region to contain both high-level and low-level areas, if desired.  On the other hand, this would allow a quest giver’s first quest to be higher level than his second quest, which is certainly undesirable.  But maybe it should be the player’s job to just not do that.  This will require more thought.)
• Subscriber AI should prefer to do quests of a level matching his own level.  (however quest level is determined.  See above.)
• Subscriber AI needs to send their player to a new region, once they’ve out-levelled their current region, or if they become bored and decide to go exploring.  (For M1, characters will despawn and their subscribers will unsubscribe upon reaching the region exit, after scoring)
• For M1 only, implement a simple on-screen scoring system to report the number and percentage of characters to exit the region.  Bonus points for characters who are level 5 when they leave, and for subscribers who are not bored at the time that they leave the starting region.  Maybe also bonus points for more time taken before leaving?  Not sure about that one.
• For M1 only, automatically place a region exit at one edge of the starting region, locked so that the player cannot move or destroy it.
• For M1 only, remove “capital city” from the building interface;  M1 is about building a starting area, so having a major capital city is not appropriate.
• For M1 only, remove “game mode 3” from code+data.  Not going to tip my hand about that one just yet.  :)
• Create a simple (but easily recognisable) visual model for graveyards.
• Set up a simple system for writing out OpenGL driver and performance data to a text file, to help tune performance and find what sort of hardware I need to support.
• Win32 build.  (the Win32 build is, sadly, extremely out-of-date at the moment.  It’s Visual Studio project really needs some love, to bring it up to date.)