Brian Ortiz

I get mad when people don’t blog so I’d better set a good example!

I’ll be honest, I haven’t worked on OrtzIRC much. It needs more work that I’d first thought. The source is a mess and needs a lot of refactoring. I haven’t given up though, just taken a break!

In place of OrtzIRC, I’ve been working on the game I may have mentioned in the past. Hopefully the concept doesn’t turn out to be too unrealistic.

I’m planning on a space sim in the vein of Wing Commander, except it will be 2D top-down and not constrained to pre-determined “systems”. Everything will procedurally generated and the player will get around by “jumping” with an FTL drive to a set of coordinates, which may take you to something interesting, or take you to some empty space in the middle of nowhere.

Generating systems (at least visually) will be pretty easy. I think the challenge will be making those systems interesting and worth exploring. Another problem I can see is combat. In a 3D space sim, you fly the ship from a first-person perspective. But when it’s 2D to-down, you can’t do that. And so when you’re flying next to, or attacking, a ship much bigger than yours, you’d have to zoom out to see the other ship, at which point your ship would get very small on the screen and possibly make things difficult for you.

So many things to consider!

In the mean time, here are some screenshots:

The planet is still in the testing phase and is not yet “procedural”. The textures are generated with LibNoise.XNA

Finally got over a little hump recently with OrtzIRC.

I decided to dump ADO.NET and thus SQLite. I like SQLite, just not ADO.NET.

IRC settings are now stored as object and serialized to XML. Here’s an example.

<?xml version="1.0" encoding="utf-8"?>
<EpicServerList>
  <Network Name="Gamesurge">
    <Server Description="Randoms" Url="irc.gamesurge.net" Ports="6667" />
    <Server Description="Burstfire" Url="Burstfire.UK.EU.GameSurge.net" Ports="6667" />
  </Network>
  <Network Name="Freenode">
    <Server Description="Random" Url="chat.freenode.net" Ports="6667" />
  </Network>
</EpicServerList>

I’ll probably make a tool that will parse the settings from your current IRC client and build an XML file with this schema. What I’m hoping to eventually have is a Creative Commons directory of IRC networks/servers.

I finished a major feature of OrtzIRC recently, so I thought I would write a bit about how it works.

First of all, a big thanks to Max for being the grease when my gears wouldn’t turn, so to speak. And for talking me into doing commands this way instead of mine, which would not have worked out as well.

One of the goals with OrtzIRC is extensibility. OrtzIRC will have many categories of plugins which you write with your favorite .NET language, compile, and place in the plugins folder, much like Paint.NET. (Unlike Paint.NET, OrtzIRC will stay open source. wink wink) The first plugin category is commands.

Here’s what the “say” command looks like:

namespace OrtzIRC.Commands
{
    using OrtzIRC.Common;
    using OrtzIRC.PluginFramework;
 
    /// <summary>
    /// Parts a channel
    /// </summary>
    [Plugin]
    public class Say : ICommand
    {
        /// <summary>
        /// Sends a message to the current channel
        /// </summary>
        /// <param name="channel"></param>
        /// <param name="message"></param>
        public void Execute(Channel channel, string message)
        {
            channel.Say(message);
        }
    }
}

Like with most IRC clients, “say” is the only command called automatically (when you type into the command box without specifying a command).

Commands must follow these rules to work properly:

1. The class must implement the ICommand interface. At the moment this interface just lets the plugin loader know that it’s a command.
2. The class must also have the Plugin attribute. Plugin takes an optional string parameter to specify the name of the plugin (in this case the name of the command you type to execute the command, ie “/say”) otherwise the plugin’s name is the name of the class.
3. The command class must have at least one public Execute method. This method is what OrtzIRC calls when you type in a command.
4. The type of the first parameter in each of the Execute methods must be one of the following:
   • Channel
   • Server
   • PrivateMessageSession

   This parameter represents the context in which the command was executed, in other words, the window. (A channel window, PM window…)

5. The type of each of the remaining parameters must be either string or ChannelInfo. The ChannelInfo object is simply to let the command know that the user specified a channel name, ie “#luahelp”.
6. If you want autocomplete support the Execute methods must each have proper XML docs. (This has not yet been implemented, I will discuss it in more detail when it is)

If these rules are not followed, the command will either not be loaded or not called when the user attempts to execute it. When a user types in a command, the plugin system looks through the commands it has loaded and looks for one that meets all these requirements and whose parameters match the parameters given by the user.

This command system is much more dynamic and easier on the programmer than other systems I have seen, which usually require the programmer to manage arguments manually and add a lot of redundant code.

Questions, comments, suggestions welcome.

‘Bout time for a quick update!

OrtzIRC’s first (major) feature is in; Drop-In Commands.  I’ll post more detail in the future but basically you write some commands in C#, compile it, plop it in the plugins directory, and restart OrtzIRC. The command code is dynamically called when you enter an IRC command. I haven’t decided on scripting support but it’s not out of the question.

Just a few more core functionality features to put in like server settings and favorite channels and I’ll be ready to call it “alpha” and get ahold of some testers!

I’ll try to twitter about progress with OrtzIRC more. Also, I’d use hashtags if hashtags.org worked…

Time for another update.

Last time I posted about OrtzIRC, I mentioned I was looking at using System.AddIn as the framework for OrtzIRC’s plugins. (I’ll just call it MAF for Managed AddIn Framework, what it used to be called) Well the biggest problem with MAF is that it’s so freaking complicated. After I finally sat down for a while and read up on it, it just seemed to get more and more complex. And even more so when I started asking “well, how would I do this?”. For instance, everything that crosses the isolation boundary needs a contract. Events, collections (you have to use IListContract), everything. So for OrtzIRC this meant every single event (something like two dozen) needed to be redefined as contracts. (Or wrapped, or whatever) Another problem is that nobody uses it. I’ve only found two projects on CodePlex that use it and virtually no blog posts about it. I’ll admit, I never completely understood it all, but I’m pretty sure it would’ve been a LOT of work. Our own way may also be a lot of work, but at least it’s our own way. Which is what I really wanted to discuss today…

As a quick side note, I did discover the Managed Extensibility Framework, being developed by Microsoft, presumably for future inclusion in the .NET framework. It looks really nice. Much simpler than MAF. And more popular too, at least on Stack Overflow. It’s a really young project though, and although they’re making it rather clear that MEF is here to stay, I think I’ll wait until CTP to give it serious consideration.

So Max and I had a disagreement about how to do the command plugins but that has been resolved (he won lol). So I’ll just point you to his two posts he wrote about it rather than re-explain it.

Onward and upward!

Progress has been slow, but it hasn’t stopped. It’s been a while since the last update so forgive me if I repeat anything.

The biggest news to tell is probably FlamingIRC. I decided pretty early on that there was no need to reinvent the wheel and so decided against writing my own IRC lib. So I went with what seemed to be the most popular IRC library for .NET, Thresher. After having it pointed out to me how old and outdated the code for Thresher was (I think it was written for the first version of .NET) I decided to fork it and name it FlamingIRC. Sadly it’s under the GPL so it has to stay that way. I hate how viral GPL is. It’s very heavy-handed.

Max Schmeling sort of gave OrtzIRC a shot of adrenaline, cleaning up some of my code and improving a lot of things overall. I just wish I could code as fast as him…

I’m still thinking about features to add, mainly plugins and scripting. I’ve been thinking that both a plugin system and a scripting system would be over kill, but that seems to be how XChat does it so I’ll have to do some more research. If you have any experience with implementing plugin systems and/or scripting systems or know where I can get some information on implementing them, please leave a comment!

I don’t think I’ve linked to the project page yet, so here you go. You can take a look at the code if you want but there really isn’t anything to see yet. However if you do happen to see any bugs, or if you have any feature requests feel free to open an issue. I also started a page on planned features, mostly for my reference., which is obviously subject to frequent change.

I was working pretty hard on OrtzIRC (compared to other projects). I discovered the awesomeness of the class diagram system and I was getting a lot of the classes laid out. Then some guys in IRC were talking about IRC fameworks and someone mentioned Thresher.

After looking at Thresher’s code I realized I was completely reinventing the wheel and that my own backend would probably end up looking a lot like it. So I decided to use Thresher for my IRC connecting and stuff, although I will probably make a lot of changes to make it do the things I want it to. Right now it doesn’t do things like keep track of channel info, it looks like it’s mostly event-based, like for bots. It just passes around channel names as strings. Needs moar OO.

So now I can concentrate a little more on scripting, which is where I believe OrtzIRC’s power will lie.