Modifying Aardwolf plugins

Anyone know if it's feasible to re-work the plugins Aardwolf supplies with it's client package for use with another MUD? If so, how would you do it?

Easily? Only if your other MUD uses GMCP in the same way that Aardwolf does. Otherwise you're probably looking at some significant work.

To amplify on that, most of the plugins rely on "imbedded" information (hidden by telnet escape sequences). You don't normally see it (eg, current room number). The protocol is called GMCP (Generic MUD Control Protocol).

If your MUD doesn't send the protocol, you are out of luck really. If it does, the plugins are probably close to working.

I suppose you can extract the information other ways (effectively, with lots of triggers) but the amount of work involved probably means you may as well start from scratch.

I guess that's basically what I'm after. I'd like the mini-windows to capture stuff that a trigger matches on. I was just hoping it might be possible to get some working mini-window code that could be used for that.

I've never had much luck with plugins. I got some to work once, but it's never obvious everything that has to be done to make it work and except for known test cases, if you will, nothing ever works right off the bat it seems.

Thanks for the input.

I would personally break the problem down into two steps:

1. Find the information you want (eg. with triggers). Initially just do Note function calls (or print) to confirm you are getting what you want, when you want.
   
2. Looking at some of the examples for miniwindows, turn the data into nice readable displays. Just think of the window as a "canvas" that you can draw on, addressable to any pixel. Eg. put text starting 10 pixels down, and 5 pixels across, in font x, size y.

Out of curiousity, why not implement one of the out-of-band protocols? GMCP has already been mentioned, but you could do the same with MSDP, ZMP, ATCP, etc. They really do make it much easier to create a custom interface.

You could create gauges based on the prompt, for example, but that requires a trigger that matches a specific prompt pattern, and the gauges will only update each time a prompt is drawn on the screen. With an out-of-band protocol, however, you can literally sit there watching your gauges refill without anything being displayed in the text window.

The difference becomes even more significant when you start including things like group stats, equipment, score sheet, maps, etc. Do you really want a score sheet that only updates when you literally type 'score'? Wouldn't it be nicer to have one that updates in realtime, removing the need to even type 'score'? Do you really want players to have to type 'map' and view an ASCII map, just so that it can be displayed graphically in a miniwindow?

Well, it's not my mud, just one I want to play without typing score incessantly and having to remember what the prompt means, among other things (they put a lot of data into a small space, so there's no easy x/y hp).

In any case, my experience with coding MUDs extends no farther than having written an unfinished and fairly mediocre server in Java for the purpose of learning. I've looked at a few small pieces of Circle, and if it's any measure, server code is pretty darn complicated.

Also those protocols, so far as I know, are a really significant coding exercise, even when you understand too.

It's non-trivial to implement, but there are a few snippets available that can be plugged into most muds with little effort.

However if it's not your mud then your options are obviously limited. I guess you could always ask the admin though.