As I mentioned before, I've been doing some work in WPF recently (actually, I was doing it in Silverlight, but I abandoned that due to some of the security limitations - I wanted to be able to launch Word from my app and then communicate between my Silverlight app and a Word add-in I was developing, but that wasn't possible [you can't start processes from Silverlight], so I've switched to a WPF app deployed via ClickOnce which is probably close enough.)

Aaaaanyway (that was a rather long set up for the rest of my post which is actually pretty to-the-point!), my Word add-in is also WPF and I am using the hosting feature of WinForms to link my VSTO add-in to the WPF controls and so on. So far, it's been a magical experience, but I ran into a problem when trying to create a "theme" for my app (the default WPF theme is fugly!).

I found this post on Dr. WPF's blog, and it explained one way to get application-level resources in a hosted environment (you basically just have to create the Application object yourself).

The only problem was that one of the buttons I have in my Ribbon opens a WPF window. If you then closed that window and clicked the button to open it again, you would get the following exception:

An exception occured while calling function "ButtonClick". The exception message is:

Thrown exception of type System.InvalidOperationException with message:
       "The Application object is being shut down."
Stack trace:
   at System.Windows.Application.GetResourcePackage(Uri packageUri)
   at System.Windows.Application.GetResourceOrContentPart(Uri uri)
   at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator)
   ...

The fix was actually on that post that I linked to, but since it was in the comments, way down the bottom, I missed it on my first look. Anyway, the answer was that I had to set the ShutdownMode correctly on the application, like so:

if (System.Windows.Application.Current == null)
{
    new System.Windows.Application {
           ShutdownMode = ShutdownMode.OnExplicitShutdown
       };
}

(The fully-qualified type names are required since VSTO has an Application property that was otherwise interfering)

If you don't set ShutdownMode correctly, the default action is that the first window to be opened is designated as the "main" window, and so when the main window closes, WPF will shut down the Application object as well. By setting it to OnExplicitShutdown, you have to remember to explcitly call Application.Shutdown, but at least we have explicit control over when it happens.

I've been playing around with Silverlight recently, and I've discovered that my method of programming in Silverlight is slightly different to programming with any other framework that I've used in the past.

Normally, I'll read an "introduction" or "getting started" style guide, which will usually get you a basic "hello world" or whatever, and then it's usually a fairly simple matter of adding functionality to that until I get whatever I was trying to do in the first place.

For example, my recent forays into Lua and Luabind were like that. I started off reading the "Programming in Lua" book, which gave an overview of the language itself, then I used the fantastic Luabind documentation to fill in the gaps of how to integrate it with my game.

Now, I did struggle a bit with one or two things (as you can see my blog post), but for the most part it was exceedingly simple and I was up and running in about 3 days.

But Silverlight has been different. The way I've been programming in Silverlight is:

1. Decide what I want to do next
2. Fumble around with the classes, properties and methods I can see in the Intellisense list
3. Give up and google search
4. Find a post on the Silverlight forums, Stack Overflow, or something like that
5. Do whatever it says to get stuff to work
6. Go to step #1

I don't know if it's just because the Silverlight framework is so huge (though I never had this problem with Win Forms or ASP.NET, I'm sure) maybe it's just because in the past, when I've started on a new technology, it's usually been by starting with an existing codebase (that is, when I start a new job), or whether it's just because Silverlight really is that confusing and inconsistent.

Anyway, I'll stick with it, and hopefully I'll have that "aha!" moment when it'll all start to fall into place and I'm no longer just fumbling around in the dark... we'll see.

I've been working on integrating Lua into War Worlds for programming the AI player and so far, it's been going really well. I've been using Luabind to help me bind C++ classes and methods to Lua tables and functions and it's mostly been really easy.

I've never really use Lua before about a week and a half ago when I started, but it's such a well-designed and logical language that I've managed to pick up quite a bit of it. I haven't really looked into some of the more advanced stuff, yet, though (like object inheritance, threads and so on) but maybe I'll look into that in the future...

But I hit my first major stumbling block yesterday when I was trying to define a method in C++ that returned an array of C++ objects to the Lua code (I'll give some more details of exactly what I'm doing in another post, perhaps). Without further ado, I'll give you an example of the function I was trying to expose to Lua:

struct find_options { /* ... */ };

class player
{
private:
  std::vector<entity> findunits(find_options options);
};

Now let's say we want to expose this method to Lua. It took me a while to figure out the exact syntax, and I won't bother you will all the trouble I was having. Instead I'll just skip straight to the answer (it makes a lot of sense once you know how to do it, actually):

class player
{
private:
  std::vector<entity> findunits(find_options options);

  luabind::object lua_findunits(luabind::object options, lua_State *L);

public:
  void init();
};

void player::init()
{
  luabind::module(L)
    [
      luabind::class_<player>("player")
        .def("findunits", &player::lua_findunits, luabind::raw(_3))
    ];
  luabind::globals(L)["self"] = this;
}

luabind::object player::lua_findunits(luabind::object options, lua_State *L)
{
  // create the response object - we'll populate it as an array
  luabind::object result = luabind::maketable(L);

  // do the "real" findunits
  std::vector<entity> entities = findunits(find_options(options));
  int index = 1;
  BOOST_FOREACH(entity ent, entities)
  {
    result[index++] = entity_wrapper(ent);
  }

  return result;
}

And on the Lua side,

local units = self:findunits({ unit_type="factory" })
for _,u in ipairs(units) do
    log.write(u:kind())
end

And that's it! Now, the important part is the use of luabind::raw(_3) on line 17. That instructs luabind to pass the lua_State as the third parameter (that's what the _3 means) - remember that the first parameter to member function is always the "this" pointer, and in this case the second parameter is our "options" parameter.

We need the lua_State because we want to return a new luabind::object (which we do in this case, so we can return an array to a Lua-managed set of objects).

In a similar vein to my mesh viewer tool, I've spent a bit of time writing a particle effect viewer. This tool is probably even more useful than the mesh viewer, because (as I've learned over the last few days) it can be quite tiresome tweaking a particle effect, reloading the game, cause the effect to "go off" and going back and tweaking it a bit more.

So the particle effect viewer (screenshots don't do particle effects justice, of course, so you can see a couple of videos if you click the thumbnail to the right) was a very useful tool. Basically, it just displays the effect and it has a "reset" button which, when you click it, will re-load the effect from disk. In this way, I could set up the initial effect file, play it in the viewer, adjust it and click "reset" without having to exit, tweak, reload every time.

For my first real particle effect, I did an explosion (what else?) and given than I'm a horrible artist, I borrowed the concept from the recent Make a Particle Explosion Effect article over on gamedev.net. I'll admit that I even "borrowed" the particle texture he had made for that article - I swear as soon as I find an artist, I'll replace that texture! - but I think the overall effect is pretty cool!

I've tried to make my particle system powerful, but that does tend to make editing effect files quite complicated. Basically, the files are XML and they simply describe a series of "emitters" that go together to make up the whole effect. For example, my explosion effect here has 6 separate emitters - one for the bright flash, one for the actual firey part, one for the radiating sparks, one for radiating smoke trails, one for the flying debris and one for the little circular sparks. For each emitter, you can set things like the texture, colour scheme, movement and so on, and it all comes together to create some pretty neat effects.

Currently, the vast majority of the processing for the particles is done on the CPU. Obviously that's probably not that great going forward (though I'm thinking if I at least do it on a separate thread, it might scale better than it does currently?) but I'll have to look into doing more of them on the GPU in the future. I think for the time being, it's pretty good, though.

I started up Firefox this morning, and it popped up the following (not so) helpful dialog:

Now, I don't mind blocking addons if they actually cause problems, but this dialog isn't very helpful at indicating why it was blocked. If you click on the "More information" link, it takes you here, which in turn takes you here.

From looking at that bug list, it seems that they blocked the plugin because of a WPF vulnerability which a) wasn't even related to Firefox and b) is now fixed anyway.

Now, I've said before that I'm no consipracy theorist, but if this had been the other way around (Microsoft blocking a Mozilla extension) then the internet would've exploded with complaints by now. All I can see are a bunch of people on that buglist complaining, and not much else.

It seems to me that the people who decided to block the extensions were simply being a bit overzealous with their "block-hammer" and banned it too quickly - without fully researching the problem. After all, it seems it was blocked after reading some technet blog post which recommended individuals disable the plugin if they are affected. There's a big difference between an individual disabling a plugin (or a company disabling it company-wide) and Mozilla blocking the plugin for everybody. Especially since there's doesn't seem to be any way to "unblock" it that doesn't involve disabling the blocklist entirely (which is, in general, a good feature and doesn't need to be disabled completely!)

I guess in the end it all comes down to the fact that everybody makes mistakes. It was a mistake to block these plugins, and it looks like they're working to fix it (though the comments on that bug don't seem to inspire much confidence that it's a high priority - the first bug went from reported to blocked in about 10 hours whereas the bug to unblock has been open for over a day without getting off "NEW").