So I’ve been motivated to work on Decal lately for some reason.  Maybe it was Virindi and Flynn talking about it; maybe I was just bored with my other projects.  I spent a few days on bugs here and there, hopefully fixing the vendor bug in adapter and another one with world iterators, and decide to test some of my own plugins.  Of course the biggest one is QuickBuff, since it’s the least simple, and of course it crashes horribly whenever I click start.  It seems somewhere along the line the ‘magic’ COM-thread marshaling quit working.  I’m not sure if it’s because of Vista or a recent .NET update, but either way, QB was dead.

I knew the issue was thread marshaling because the error was obvious:  COM Interface not found.  Of course I don’t want to debug this issue because I don’t really know how Mekle fixed it in the first place.  Instead I start converting everything to use the Invoke method that was already present in my framework to move all COM calls to the main thread.  After half a day of refactoring my task class everything looks good.  Until I get around to testing things.  It looks like my Invoke method isn’t working at all.

It turned out that I didn’t do enough research when I was looking up synchronization methods.  I had found and decided on the SynchronizationContext object, but the class doesn’t actually do anything.  Apparently it’s meant to be more of an example to implement a custom sync context.  After many, many false starts and even more crashes, I eventually went back to the good old Control.Invoke method.  I wanted to avoid this to keep from having a dependency on System.Windows.Forms, but aside from implementing my own sync context, I didn’t have much choice.

All said and done, this turned out to be a great batch of work.  The plugin is way faster and smoother than it was before and seemingly more stable too.  I even went ahead and implemented the adhoc/smart buffing feature, and I’m considering going forward with rebuilding the profile editor using the current view system.

I’ll do a release after I clean up the adhoc view some more, probably this weekend.

So we've been both working on and putting off the new view system in Decal for ages.  Checksum did a lot of work to give us something to extend, and we've been chugging along with that.  We have a couple of semi-usable controls, and a simple form/view loader.  The integration with Decal still lacks a great deal, but there's one very big problem with the system:  It's fugly.

Above you can see NVS or Decal.Forms in our test container.  It's not going to win any beauty pageants for some time.

We do have a powerful theme system that goes along with NVS though.  Once the controls stabilize, and we start working on performance, it shouldn't be hard to make things look great.  Of course, none of us have any artistic talent so it'll never look that good (unless we can con an artsy person into the core team).

In support of this effort (though mostly just so I can say I finally finished rewriting it) I've put some effort into reviving Portal Opus.  I had been sitting on the framework for ages now and decided a couple of days ago to go ahead and integrate Ken's DatUtils to speed up the progress (his spell table object probably saved me an entire night of coding easily).  Right now it supports all of the textures that Decal supports and loads the skill and spell tables.  I'm going to fool-proof it a bit and post an alpha in the near future.  After that, I'm going to start building a model viewer into it too.

For some time now I've been working on a project, QuickBuff/NB2-Lite, the former being its name, the later being its purpose.  The premise is to have a plugin that can take the old nb2 profiles we probably all have still laying around and run them.  Recently I've been making a lot of progress on this and have been able to ssuccessfully run buff profiles.  Unfortunately vital recovery is still incomplete, and I haven't yet started on equipment manipulations.

I very much wanted to bring back the old nb2, but between the network parser changes and the control infrastructure changing, that became less and less of a reality.  The network parser alone was enough to make me want to drop it since nb2 is just a huge network driven state engine.  Not to mention the sheer amount of code duplication within that engine.  I don't know how nerf ever managed to maintain this code as long as he did.

Expect to hear more on this in the future as I near the testing phase.  I'll probably also start requesting copies of your profiles so that I can make sure everything works as expected.

I know I said something about tomorrow, but once I started working out the examples I wanted, I found many defiencies in my original setup.  I've since been working out a complete overhaul of the message system.  Once I complete the refining of the new system, I'll go over everything including the differences between the two.

It's been a while since I've said anything about Decal so today I've decided to share some things about the next public release of Decal.  We've come a long way with Adapter and our new rendering code so this upcoming release will likely be the last time you guys see the old view system.  You can also expect a few other components to be completely redone and at least one to be gone forever.

There are two new features in Adapter that will be the focus of today's article.  One will make life easier for devs, the other will make things much more interesting for them.  Firstly, to make development and maintenance easier, I've added another code hook-up attribute to the system, BaseEvent.  The purpose of BaseEvent is very much like that of ControlEvent.  It works on the protected 'system' events that exist as part of PluginBase (which mostly come from ACHooks in the Decal core).  When applied to an event handler, these attributes will automatically hook up and tear down the connection to that event.

[WireUpBaseEvents]
publicclass Test : PluginBase
{
protectedoverridevoid Startup()
{
// Network events
// this is the old way of doing it
//this.ServerDispatch += new EventHandler<NetworkMessageEventArgs>(Test_ServerDispatch);
}

[BaseEvent("ServerDispatch")]
void Test_ServerDispatch(object sender, NetworkMessageEventArgs e)
{
thrownew Exception("The method or operation is not implemented.");
}

protectedoverridevoid Shutdown()
{
// old tear down
//this.ServerDispatch -= this.Test_ServerDispatch;
}
}

This may not look like much since once you add the attribute, you only save one line of code.  What it does for you, is guarantee proper shutdown of all of your events.  I've found many times in my code where my tear-down code missed several events.

Now for the more interesting stuff.  Plugin devs often want to share the functionality of their plugin with others.  They also sometimes want to get information from other plugins.  This can't always be implemented to suit all (depending on language/knowledge/etc) so we've added a message notification system to Adapter to help things along.  With the next release of Decal, all Adapter plugins will be able to consume a single event "AdapterMessage", and they will be notified of all messages sent between plugins.  Sending a message is very simple as well, you just derive an object from AdapterMessageEventArgs, add in the information you want to share, and call SendAdapterMessage.

I'll talk a bit more about messages tomorrow, along with some examples on how to use it.

Brain drain's kept me from generating as much code as I'd need to start the series describing the rewrite of ACAim.  I'm slowly chugging along at it and will start posting once I'm a bit more comfortable with my progress.

This is one of the reasons why we hate dealing with the rendering system:  It's hacked.  We take over the call to create that AC makes and "do things" to the object so that Decal knows when to draw.  Well it turns out that our repeating textures were directly related to this.

In the previous version of Decal, the rendering hack consisted of a proxy object, a complete reimplementation of the DX object, that told us what was happening.  Under this model, AC had a reference to our proxy, and we had the real object.  In the new system, we decided to go with another method, vtable patching, which only alters the particular functions we want.

Well, as things would have it, Checksum created the initial hooking setup for Decal3, not Haz or myself, so this little detail wasn't exactly fresh in our minds.  So here we are, testing various ways of drawing to the screen, expecting the DX object to behave normally, but we keep getting this weird repeating effect.  We found a few methods to, ah... minimize the visible effect, but this backfired when multiple huds were generated.

Well it just so happened that Check popped up again while we were exploring the issue, took a glance at our code, and "reminded" us about the hook.  We nearly died when we realized what was actually happening.

To keep Decal drawing on the screen on top of AC's 3D, we hook a DX function called EndScene.  When AC calls this function, we send a signal to Decal to do all of it's rendering work.  Well, in our new HUD implementation, we use a technique that renders on an off-screen texture instead of the main window.  As part of that operation however, we have to call EndScene.  It turns out that our repeating texture was actually a recursion issue that somehow fixed itself before causing a crash.  So we reworked the code a bit to call the real EndScene and no more issue.

Just goes to show you how being too close to a particular project can bite you when the bugs creep up.

Well,  I wanted to officially give an update on the status of my various projects.  First, Plugin Manager has been updated and works the same as before.  Second, I've started a project to redo the "engine" portion of NB2 in c#.  I'll be releasing this once it's stable as a profile-runner.  It won't have any edit functions, but at least you'll be able to use what you have.

I may continue this project as a replacement for NB2 in the future.  I haven't really decided yet how to progress on that particular matter.

Lastly for the developers, we've been working hard on getting a new and better HUD implementation, and I can honestly say we've made some progress.  Some of it more humorous than others (There should only be *3* images in the shot).

Well, after much pain and suffering, mostly on Haz's part, the new HUD system is finally making progress, and since I'm in a mood, I'm going to talk a bit about how it will work in the .NET Native Framework in an upcoming alpha release.

Firstly, creating a HUD:

// hudRect defines the area of the screen on which we draw
Rectangle hudRect =new Rectangle(10, 50, 300, 16);
Decal.Adapter.Wrappers.HUD hud = Host.Huds.CreateHUD(hudRect);

Now that we have a HUD, lets make it colorful!

Color myBGColor = Color.FromArgb(64, Color.Gray);
hud.Fill(myBGColor);

This gives us a nice, mostly transparent grey background.  Lastly, we'll render some text:

hud.BeginText("Times New Roman", 16);
hud.WriteText("SomeText", Color.White);
hud.EndText();

And that's IT!  Of course there are other neat features that need to be tweaked a bit, and some issues that need to be solved, but we'll have progress or kill someone trying!  Lastly I leave you with a potential outcome of the above code, of course with some additions.

Since it's been quiet on most fronts with the alpha, our continued development, and the impending patch, I just wanted to let everyone know things are rolling along.  I've been having some trouble with my development setup the past few days that has hindered me, but I've mostly solved that as of a short while ago.  Tonight I'll be hitting the new rendering system hard, and may even have some good news or screenies by the end of the week.

Also, here's a quick overview of the status of the plugins/utilities that I maintain:

Zone Launcher -- Retired.  I did however hack up a quick version that works with the new launcher.  It apparently has a naming conflict with some other app that was announced a few days after I posted the update.  Oh well.

Plugin Manager  -- Limbo.  I will be updating this as soon as I figure out how.

Mouse Wheel 2  -- Actually updated already.  It just needs to stay current with our changes.  It's also waiting on QueryKeyboardMap to work again.

AC AIM -- Planning.  I will not exactly be updating this;  I'll be completely rewriting it using the new .NET framework.  I'll also be using that time to write a series of articles detailing the development process using the new framework.

Nerfus Buffus 2  -- In Progress.  NB is broken.  Very broken.  I will be updating it, but I'm having to rewrite large chunks of it.  I don't really have an ETA other than to say it will NOT be ready when decal releases.  If time permits, I plan to do my best to have it out with in the month following decal.

Going further into how and why we're breaking things, I'd like to take a moment to cover our protocol system.  As many of you know, we keep a huge xml file that documents the known AC protocol.  Well, in the downtime, this file has seen MASSIVE reorganization.  Ken has been kind enough to do this work almost alone.  This has included updating all of the old packets that have changed with ToD and also some much needed upgrades to the file for clarity, new features, and ease of use.  Another point in this massive upgrade, was a change in the objects plugins use to access protocol information:  IMessage[2] and IMessageMember.

NB2 is a heavy user of protocol information.  Even though it uses filters, there is still quite a bit of parsing that occurs.  The usual method for updating a plugins protocol functions tends to only involve changing the packet type or renaming a few fields.  This time around however, many, many packets were renumbered, and with Ken's hard work, probably 3/4 of the fields have been renamed.  Then comes the kicker, with the changes to IMessage the Member method no longer exists.  This means NB2 won't even compile until I replace all of the calls to the proper replacements.  Then I have to go back to changing the numbers and field names.  One last fun bit is the inclusion of many new "types" in the protocol.  This means that anyone parsing data might have to add some extra calls in their code.  That may seem annoying at first, but it makes much more sense with the changes.

Another, but slightly less annoying, change keeping it down is the removal of several methods from IPluginSite.  Any function that in the past used a memloc in PluginSite has been removed and is now only found in ACHooks.  Well, NB2 is old enough that ACHooks was still rather young, and didn't get used much.  These changes are generally not very difficult.

Next time we'll cover either the new .NET Plugin Framework or what will eventually be Decal's new rendering engine (depending on how far into it I get).

So many of you know that we've been "fixing" Decal lately.  Some of you are also aware that we've broken compat with the old version.  What very few know, beyond those of us doing the work, is just how extensive this breakage has been.  I'll try to further explain the damage we've done, starting with a history lesson.

In Decal 1.x, there were about 4 modules:  DenAgent, Inject, DecalNet, and DecalControls.  DenAgent is the familiar windows gui everyone uses to configure their plugins.  DecalControls is obviously the home for all of the buttons decal shows in-game.  DecalNet is our network parser.  That leaves behind Inject.  While the name implies that it might have something to do with injecting the Decal code into AC, that's only a fraction of what it did.  Inject *WAS* Decal.  It handled all of the hooking, all of the rendering, all of the input.  Every interaction except reading packets passed through Inject in some way.

When Cibo came back and gave us his vision of Decal2, we gained a few more modules:  Decal, DecalFilters, and DecalInput.  The idea here was to shift core functionality away from Inject and into Decal.  For plugins and filters this happened about 50%.  Decal now started and stopped "services" which loaded the plugins and filters.  Unfortunately, Inject kept a tight grasp on the Rendering and Input code.  Even though we now had a module named DecalInput, it only contained services to let plugins generate input, it didn't help process input from AC at all.

So this is where we arrive.  We've tried through the years to patch functionality into this model with out breaking it.  We have so much legacy code and cross referenced crap to maintain most of us babble code non-sense in our sleep.  Finally ToD has given us a chance to fix all of that.  With the massive changes to AC's rendering engine, our graphics code died.  We've hacked together a temp solution so that we can get the rest of decal working, but we have grand plans indeed for a new one.  We've also taken several more functions away from Inject, and will continue to do so until it does little more than... well inject.

Next we'll go over some of the more specific things that have been changed, or maybe give a little more insight into the depths of Decal.