Will >> Will's blog
Fri, 12 Jan 2007
I had a craptastic conversation with one of the admin on Dark Rifts a couple of days ago the end result being that I decided to cut my losses and leave. They're not going in directions I'm interested in and I don't really have time for it anyhow.
Between all the mud projects I've worked on, I've probably written a couple hundred thousand lines of code in Java, Python, C and ending with LPC over the course of the last 7 or 8 years.
I'm still kind of bummed about it and I think that's the end of mud projects for me unless I get involved in Twisted Reality or Phantasmal/DGD. Twisted Reality is really interesting, though it's really different from other mud systems I've worked on.
Tue, 02 Jan 2007
I installed Mudos on my laptop which is running Ubuntu Edgy. I had two problems compiling the source for v22.2b14.
The first issue is this error when running
make: *** No rule to make target `obj/malloc.o', needed by `driver'. Stop.
The solution, bizarrely, is to just run
make again. I
don't know what the issue is, but discovered this in the depths of the
mailing list archives.
The second issue I get when compiling is this error:
socket_efuns.c: In function 'get_socket_addres': socket_efuns.c:1198: error: invalid lvalue in unary '&' make: *** [obj/socket_efuns.o] Error 1
Doing this change fixes the issue:
$ diff socket_efuns.c.orig socket_efuns.c 1198c1198,1199 < addr_in = &(local ? lpc_socks[fd].l_addr : lpc_socks[fd].r_addr); --- > // addr_in = &(local ? lpc_socks[fd].l_addr : lpc_socks[fd].r_addr); > addr_in = local ? &lpc_socks[fd].l_addr : &lpc_socks[fd].r_addr;
After that, everything works wonderfully.
Tue, 05 Apr 2005
It's shaping up to be a long, but productive week.
We're working through the problems a bunch of problems with the contributed plugins that have been sitting around for some time. This includes assigning licenses to all the plugins, adding version/author information, making sure they have some modicum of documentation, and at some point (hopefully) testing them all out in PyBlosxom 1.2. Hopefully this will put the contributed plugin pack in a much better state of being.
Steven, Bill, Wari, and Doug decided that it was high time we started using various features of CVS to make development better. I've had some growing pains with this and kind of wished people had figured things out and written up a process before making the changes. Even though I'm grumbling about the way it's happened, it is a good thing it is happening and it will make it a lot easier to do some of the things we've been doing for a while now. It'll also help a huge amount now that we've got more than one or two active developers.
I have a lot of plans for the PyBlosxom manual, but haven't had time to execute on any of them yet. The wiki we were storing documentation in was taken down since the jackass ISP that Wari had got all befuddled and confused and terminated his account with them. The problem here is that I had documentation in the wiki I hadn't had time to port to the manual yet. Fortunately, Wari sent me the contents of the wiki. I had documentation in there that I hadn't had time to port to the manual yet.
I'm 90% sure I know how to restructure what we've got right now to allow for Bill's index caching and also other storage systems. Depending on how things go with everyone else's PyBlosxom projects, I'll prototype this, write up a specification, send it round, and then implement the resulting modifications all before the next version of PyBlosxom.
Since Ted's PyBlosxom presentation at PyCon 2005, we've had 10-20x as much PyBlosxom development activity. That's been really exciting but also really daunting. Definitely a lot of growing pains mostly between my style of running things and peoples' vision for how things should be run.
Steven is still working on fixing the PyBlosxom registry to be a bit more user-friendly. We're short on flavour templates and some people really dislike this so I want to spend a week building new flavours at some point in the near future. Maybe I'll toss all the flavours in the contributed plugin pack to replace the existing flavour examples that come with it (I highly doubt anyone uses any of them).
I was accepted into the masters program at Northeastern University CCS. Starting in September, I'll be a full time grad student. My advisor is Mitch Wand (which is very exciting) and I was awarded a Dean's List Scholarship which reduces the costs assuming I maintain a 3.0 GPA and miscellaneous other things in fine print. All very exciting.
Need to learn Lisp, review all the stuff I learned in college, and attempt to get ahead of the game by covering as many of the things I'm going to be learning as possible.
I've adjusted the way I'm working on DarkRifts such that I'm limiting myself to one coding goal every week. This will reduce the amount of stuff I'm doing there, but more importantly, it makes it easier to schedule things and gives me time to work on all the other non-DarkRifts stuff out there.
I'm in the process of looking at Lulu to do some self-publishing. S and I wrote a children's book last year which might be a good candidate for Lulu. The problem being that we'd need to redo the layout.
On top of that, I'm novel-izing the D&D campaign that I've been in for a year and a half. That's been going really well so far. I'm done the first couple of chapters. If anyone else plans to do something like this, it helps to take really good session notes and maintain a public set of summaries that other people in the campaign can fix.
On top of that, S and I have some ideas on the next children's book, but we still need to sit down and flesh them out a bit.
Work has been super busy the last couple of weeks on top of everything else.And I started running again and I finally got around to cutting my hair, too.
Thu, 04 Nov 2004
Every once in a while, someone emails me about Stringbean and wonders why I'm not working on it much. Stringbean is more like an LPMud than a MOO and would allow for in-game coding of objects in Python. I've been giving a few reasons of why I'm not really actively working on it:
- It's not currently possible (without a lot of work) to build a restricted execution environment within the Python interpreter to protect the driver from the mudlib codebase if both are implemented in Python. That's not a wildly large issue except that it forces you to really trust in-game developers. The Zope folks have something like this in place, but I don't know if it would help me solve my problem or not. Mostly this requires a lot of research and work.
- It's difficult to terminate infinite loops and other long-running code which will cause mudlag. It's not uncommon for me to accidentally create an infinite loop. If you can't somehow halt execution, then this forces you to shut down the whole mud and restart it. When working on Varium, we created a reaper thread which would send a signal to the Python process causing the execution thread (which was the main thread of execution) to throw an exception and thus "terminate" execution. Even with this, it's not clear what state the driver would be in. This also requires a lot more research and work.
- I bumped into Twisted Reality (which is what this post is all about).
Twisted Reality is a MOO oriented mud so it's got a different focus than Stringbean does. However, Twisted Reality is also attempting to solve another big problem I have with muds using Aspects.
The problem is this: you build a bunch of objects the player can manipulate (things like torches, swords, hammers, nails, screwdrivers, ...) and in order to add another way for the players to manipulate and modify these objects, you have to code manipulation/modification-handling code for every single object. What if you wanted to allow players to burn an object? Well, for every object, you'd have to implement burn-handling code.
You could implement this using multiple inheritance. Each object inherits from a object-type class (armor, weapon, container, ...) as well as a material class (iron, wood, organic, copper, glass, ...). The material classes could handle effects like burning. But what if you had something like an axe with a wooden handle and an iron blade?
Anyhow, it'd be easier if the burn code could be centralized into one place--an aspect. The stuff in the Reality mailing list is interesting enough that even though I haven't looked into it further, it's caused me to want to wait to research it more before I go work on Stringbean again.
Mon, 27 Sep 2004
I had a splendid weekend with S's parents and then bumping around Harvard Square on Sunday. I did some studying for the GRE, but mostly took a couple of days off from doing work.
I also finished up overhauling all the code on DarkRifts to work with the MudOS v.22.2b14 driver. There's a huge amount of code and there were a lot of problems most of which are sorted out now. There are still a few problems, but no one seems to be logging in, so I don't really feel any urgency to work through the last bits.
I'm planning on pushing pyblosxom through to a 1.1 release soon. First, I'm going to package up the flavour files into flavour packs for the registry. Second, I'm going to add documentation to all the contributed plugins and move them all to the registry. Accomplishing those two tasks should give the code in CVS enough time to bake. Then we'll do a 1.1 release and start thinking about 1.2 which will likely involve a minor overhaul to how we pull files from the file system.
The next two weeks will be pretty busy. Already I'm way behind in replying to email.
Fri, 10 Sep 2004
In my copious free time, I do some work on a mud named DarkRifts. The mud itself runs on MudOS on top of a mudlib based on a mudlib based on TMI-2. I've worked on a few other mud projects, but decided I didn't want to run my own mud since I don't have enough time for that and it'd be better to help out with someone else's mud.
The mud is still pretty infantile in terms of maturity of the codebase and player base. We have seven guilds that are in-game (two of which are "starter" guilds) in two realms with twenty-nine different areas and several cities. We've got a few alpha-testers who come irregularly.
There's a lot of polish work to be done--but we're not at that stage yet, though we are progressing. One difficulty is that our alpha-testers are pretty irregular in their testing. So the mud is pretty quiet most of the time (I think we average 2 players online). The other difficulty is that we could use a few more coders to help even out the rough edges on that side of the equation.
Anyhow, if you have any interest in seeing what we've got going on, helping out, or otherwise chiming in, check out the DarkRifts website and/or add a comment below. If you log in, my name is "Flake". I idle there during the day and do some work on nights and weekends (I'm in Boston, MA which is Eastern Standard Time). Please drop in and say hi!
Sun, 15 Aug 2004
I've been super busy over the last few weeks. Between work and moving and weddings and trying to catch up with things, I haven't had much time to ruminate on anything or work on any of my projects.
There's one exception to that... I'm a coder on DarkRifts and I've been doing some minor refactoring and overhauls of some of the pieces of their mudlib. That's coming along nicely. The other coders have been really kicking in and getting things done lately. Watching the codebase flourish has been wonderful.
I'm not entirely sure what I should do with PyBlosxom. Development has pretty much stopped--Ted, Wari, Blake and I have all moved on to other things (babies, other projects, ...). No one else has stepped up to the plate. Though we keep getting emails on the dev lists and elsewhere about how no one will use PyBlosxom unless it does feature x and feature y and how there's lots of bad code and so on so forth. I wish more people would take the responsibility to help out.
Mon, 03 May 2004
I'm totally fascinated by game economies as they generally approximate real economies but usually have "faked" aspects because game economies usually lack feedback loops that real world economies have. Blah blah blah I am not an economist so I'm kind of fudging my English here blah blah blah. Regardless, I still find it really fascinating. I also find game weather systems really fascinating.
Wed, 21 Jan 2004
I'm on this crazy coding kick right now. For some reason I decided to go dig up Stringbean and see how it was doing. It's doing fine! Well, except for the fact it wouldn't start up. So I did some fixing and now it's fine and starts up and everything seems hunky dory. I have no clue what I was working on last.
Anyhow, for anyone interested, here's a tarball of a working, but very lacking, version of Stringbean. I release it under the GPL. I might at some point work on it some more, but if not, there it is.
Thu, 28 Aug 2003
Date: Tue, 05 Aug 2003 22:04:59 -0700 From: firstname.lastname@example.org Subject: SourceForge.net Project Removal Greetings, ... The varium project on SourceForge.net, originally registered on 2000-01-14, meets the criteria we have set up for this purge. If you fail to respond to this inquiry, your project will be removed in approximately 21 days. A final warning will be sent in approximately 14 days if we have not yet heard from you. ...
I worked on Varium with Josh and Pat for a couple of years. The project started out in C, then we talked about embedding Perl, then we switched over to writing the whole thing in Python. That was in the end of 1998. It's what got me coding in Python and also what got me working on apsects of mud development--a hobby I continue to this day in several forms which has helped significantly with my career and growth as a developer.
Even though I stopped working on Varium in 2000 and started working on bluemud (another Python-based mud server) and then left that project to work on stringbean which hasn't really gotten very far (for all kinds of really good reasons), it's sad to see these sorts of beginnings finally pass into the quiet of the night.
I have access to the code-base if anyone is interested. As Josh pointed out, there's very little documentation (i.e. almost none), the code-base is messy, and it was written in the days of Python 1.5.2 when I (and likely my cohorts as well) didn't really know what I was doing in Python land.