Aardwolf custom Mushclient Development
Many of our players have come up with some great ideas to get new users to Aardwolf. However, there is no point going all out on getting completely new users to the website when they don’t know how to play when they get there. We have always struggled with being a large and complex game that can be difficult to learn, particularly for people who haven’t played a MUD before.
The Aylorian Academy was a first step towards making it easier to learn how to play Aardwolf, and the addition of the Flash Mud Client to the site is an improvement over the Java Client for folks who want to quickly try out the game.
The problem still remains of what they do afterwards? Installing a MUD client with no aliases, triggers, etc is only marginally better than no client at all. Configuring a client for the first time can be complex. A person that has never played a MUD before is not going to invest the time and energy when they’re so used to other games that just do it all for them.
After discussing some ideas with Nick Gammon, the author of Mushclient, we have created a custom version of Mushclient that, when installed, will:
- Install a number of Aardwolf specific plug-ins with it.
- Run a script that will determine the user’s desktop size then open various extra windows based on their screen real-estate. The font style and size are also set automatically.
The script has been tested on every resolution my laptop supports (12 different settings between 800*600 to 1920*1200) and works fine. The main point of this was originally to auto-configure and install some plugins for Aardwolf, but I made some code changes to improve the plugins while I was in there. The stats andmap windows are shown below and you can check out the example screenshot for the full layout.
For users of other clients, these are all tag driven and can be developed using basic triggers, depending on what your client supports. For existing Mushclient users the plugins will be made available individually.
Other than the auto-install, the cool part about the stats window is that it automatically updates everytime you see a prompt or battleprompt. No prompt configuration is needed for this, just an additional config toggle. Notice also that the map window includes the room name and exits.
For packaging up Mushclient itself, Nick kindly provided the NSI script he uses to package up Mushclient for release. A weekago I’d never so much as written a line of code in Mush or used NSI, so working on this has been fun.
It is not quite ready for release yet, it still needs some tidying up. There is also a lot of registry hacking in the NSI script, some of which can come out based on some recent changes Nick made to Mushclient itself.
Having a single download / install that gives new players what they need to get started with Aardwolf is a good step forward, particularly as the development of a custom client it as the end of a very long “todo” list.
I was going to include a section on “Why Mushclient?” here but the post is long enough already, so that can wait for a follow up post.
As you can see, the fact that there hasn’t been a reboot / announcement note of changes on the main MUD for a few days rarely means “nothing is happening”.
The base download will include map capture, stat capture and a spellup plugin. A channel capture plugin will be included but off by default. Speedwalking will be built into the MUD itself with a ‘runto’ command. Appreciate your comments on this. What else do you find essential to play Aardwolf?
Really, really awesome! I love the stat bars - this will definitely be a boon to new users (the whole package!)
So you’re going through with the runto then? It was a challenging script to code and kept wondering if you’d include it or not
Wow! This looks great! Having a proper client would definitely help, and Mushclient is about as good as it gets too.. wheeee!
I wish this was around when I started!
It looks fantastic and should help retain people who have never mudded before. The map capture is much more attractive and cool than the primitive map capture I use with my MUSHclient. You even placed it in the same spot I placed mine!
As a long time MUSHclient user, I’m excited that the plugins will also be made available to those of us who already use this client.
Another thing I find essential to play Aard is a CP capture window. Currently I have a primitive one located where you placed the stat capture window in your screenshot. To promote CPing, it would be slick if you had an optional CP capture window that refreshed after every kill.
Thanks so much!
Wow. I can hardly wait for it to be done. The spellup thing would be very useful for me - I currently use aliases, and it often leads to overcasting and a lot of time wasted. I’m sure this will make life a lot easier for new players, and even for a good number of existing players!
I think that Aard rocks on whatever client I’m using … but this is certainly going to sweeten the pot for a lot of players - old and new. Thanks for everything you’re doing, Lasher!
Looks good, looks like it’s missing double xp in the prompt, and perhaps putting gold/qp into the status window would be nice.
Oh and I think I’ve been using Zmud for to long, because that font looks funny.
[Lasher added]: Font is changeable on each plugin of course, that’s just the default
You can change the font rather easily it’s not a problem
Lasher: Do you still intend to look into the other features for zmud/cmud I noted you about earlier in the week?
[Lasher added]: Nod, in fact some of it is in this already. To get the map like that it already has new tags around room names and exits.
Innovations like this is what keeps Aardwolf such a great game!
What a long way we have come since V1
Thank you Lasher and Nick Gammon !
Looks Great lasher I cant wait to test this. Thanks for all the work you have been putting into Aardwolf and Thanks to nick for working so well with lasher.
Keep up the hard work
Looks great. I think it would be nice if there is a plug-in for the speedwalks,
so that you don’t have to code them all yourself. I have all speedwalks coded
for another client (mudmagic) but wonder whether I should change over…
Truly awesome! I agree with others who commented that they wish this had been available when they first came to Aard. I will definitely point people I personally know to try Aardwolf out (instead of wasting time with WoW).
Keep up the fantastic work!
Wow that really looks nice, hope I can tear myself from zmud to use it. The only thing I capture in zmud that helps me alot is tracking certain speech channels, maybe have a small 4 or 5 line capture at the top which could have selectable channels on which to capture, tells, gossip, auctions, etc.
This looks freakin awesome. For some layout hints / scripting ideas, please check out Aarddevil (Now with 100% less user tracking) - I was turned onto it last year and would never have made it to tier without the quest/CP/GQ tracking, health stat bars, etc that it has incorporated. If we can get a Linux-based equivalent (KMuddy-Capable perhaps?) I’ll have no more reason to dual boot Windows =oD
Cecil
Looks great from here. As someone whose first mud was Aardwolf I think this is a great step for helping new players. Very well done.
It looks great, but what would happen to the ignorant people like myself who paid for their copy of ZMud? Would we have to throw it away and download the new mushclient? “For users of other clients, these are all tag driven and can be developed using basic triggers, depending on what your client supports.” Or was this previous comment directed toward us, saying that we could accomplish the same effect with triggers? Other than that I think the mud has come a long way in the (off and on) 9 1/2 years that I’ve played here, thanks for everything and I hope you don’t stop.
Having an install package of mushclient for aardwolf is awesome.
Easy way for newbie players!!
Think stats isn’t important to show than exp to-next-level, alignment or gold
I think some quest/campaign window would be compulsory.
Quest is a lot of important in aard.
Btw, since i play aard from december, ive tried to make some scripts helping for a easy aard playing.
When i’ve seen this plug-ins for mush, these are similar than mine, but after i though i need some new functions as all prompt info available, pot manager, tick count, and channel window. (ex: http://i29.tinypic.com/qq7ukl.jpg).
Now, just for my preferences, working for parametrized plugin for everyone.
Programmed in LUA, just i’d like to ask how to open all window at the same time. I haven’t found it.
Under Global Options, world tab you can set a list of windows to open at startup. Ive been toying with it for a day or so now. I would like to find a copy of that character stat plugin.
I would like to see 2 things added.
1) Add or get Nick to add an always-on-top toggle for each world window so that it’s possible to make a secondary window float on top of the main one instead of instantly dropping behind it.
2) A tag that indicates location (continent and coordinate) on the continents for each movement step while both walking and running, or the location of the area on the continents while inside an area. so that I can give out my bigmap script which someone could then rewrite for MUSHclient…uh…maybe. Actually, I’m not too sure about that last part. Can MUSHclient write to arbitrary locations in the output window? If not, get that added too.
>Add or get Nick to add an always-on-top toggle for each world window
Not sure how you envisage that working. Conceptually an “always on top” window will not have another window on top of it.
You can make MUSHclient “always on top”, however that applies to the whole application, and it has somewhat the reverse effect - you can’t put secondary windows on top of it.
> Can MUSHclient write to arbitrary locations in the output window?
No, and it isn’t practical to do that directly. However for something like a mapper window you simply clear the whole window with DeleteOutput () and then recreate it.
The new installer works with Ubuntu, although you need to manually select a monospaced font.
Woah. Hi Nick.
> Not sure how you envisage that working. Conceptually an “always on top”
> window will not have another window on top of it.
I mean essentially a way to fix the display order of world windows so that ones that I designate as being “in front” or stable don’t fall to the back when typing in a different one. This would be especially useful for the map which does not require any user interaction, but should remain in front at all times. The current requirement of having the map off the edge of the main window is not ideal. Obviously two windows cannot both be “on top”, but they could both be fixed in order in a primary class of windows that do not reorder themselves when they lose focus.
> No, and it isn’t practical to do that directly. However for something like a
> mapper window you simply clear the whole window with DeleteOutput () and
> then recreate it.
Recreating the whole map is not ideal from the user standpoint. At least in zMUD it leads to an annoying redraw flicker (as well as slowdown from drawing way more than necessary) when the map is sufficiently large. I won’t be able to try it in MUSHclient for quite a while, so I don’t know if it will have the same problem. I’ve always found MUSHclient to be rather zippy, but this is not something that I’ve ever seen anyone else do.
For reference, the script I’m talking about is here:
http://www.not-porn.com/Aardwolf/BigmapWalker/index.html
The video also has an example of what I’m asking for w.r.t. the “on top” feature.
MUSHclient was developed using MFC libraries. Doing some sort of custom “on top” feature won’t be easy. I looked in the past, and I don’t think child windows can be made on top relative to other child windows. I just don’t think Windows supports that. Other programs that don’t have a parent->child design may well be able to achieve it.
As for the flicker, my testing here shows that even shoving my entire “score” screen to another window happens so fast I’m not even sure it has done it. I have been resorting to deliberately selecting text in the output window, just to see the selection go away.
The map screen we have been playing with is similar - in any case you *expect* a flicker, because the map is redrawn with different walls everywhere, as you move, however it looks smooth to me.
One of the reasons it looks smooth is the technical way it is done. If you have a lot of output all the buffering is done first, and then the screen refreshes, effectively resulting in a single redraw operation, not one per line.
> I looked in the past, and I don’t think child windows can be made on top
> relative to other child windows. I just don’t think Windows supports that.
Not ideal, but understandable.
> The map screen we have been playing with is similar - in any case you
> *expect* a flicker
In this case the entire map is static (except when changing continents, obviously) other than the location marker that moves when you move. So here any flicker is unexpected and distracting.
> As for the flicker, my testing here shows that even shoving my entire “score”
> screen to another window happens so fast I’m not even sure it has done it.
> One of the reasons it looks smooth is the technical way it is done. If you have
> a lot of output all the buffering is done first, and then the screen refreshes,
> effectively resulting in a single redraw operation, not one per line.
I’ll have to check it out. What you say certainly sounds promising. Expect to hear back from me soon about this.
Either way, Lasher, still want the tags!
Nick, You don’t play Aardwolf, do you? It’s cool that you’re checking in on the blog.
I am not exactly a long-term player, however I have made a few characters to test out some of the ideas we had with the plugins.
In the process we have shaken out a few bugs in MUSHclient, or at least, places where it could make more information available (such as the size of the main client window).
Meanwhile Lasher has been adding a few server tags (which any client could detect) to facilitate “screen scraping” of things like help displays, maps, character status, and so on.
Of course these tags are optional, so people can continue to play “the old fashioned” way, however it is quite fun to have relevant information broken out into multiple panes on your main window.
There is also no favoritism shown to MUSHclient in this respect. I would say that virtually any client that supports triggers, multiple screens, and moving text from one screen to another would cope with something like:
… help text here …
I imagine any of the more popular clients could make use of this information.
The important thing we are trying to do here is making playing MUDs more fun, and more accessible to newbies. Anything that eases new players into a game without needing to memorize, or make sense of, heaps of obscure information, must surely be a good thing.
The other things is that the general techniques employed here could easily be used by other MUDs as well, if they wanted to do something similar.
Hmm - the blog swallowed up what I was trying to demonstrate. Oh well, I’ll do it with square brackets.
[HELP]
… help text here …
[/HELP]
… was what I was trying to say. Imagine the square brackets being angle brackets, and that is what the MUD is sending.
So the plugins with the “runto” command are going to be implemented in a final version?
Jollygreen: ‘Runto’ was never going to be a plugin. It’s impossible to predict all the speedwalks someone could want, or where from. Runto came from the idea that if we have speedwalks available in the game with the ’speedwalks’ command, then we might as well just output them in alias format for including with the default mushclient install and any other client that wanted to convert them.
If we’re going to make them available in a client, might as well just simplify it and put them directly into the mud - that way everyone gets use of them regardless of client and they’re always up to date.
So, ‘runto’ will just be based on the speedwalks list. From Aylor recall, you would type ‘runto lidnesh’ for example, and it would execute the speedwalk to lidnesh. It gives nothing that isnt there today, just makes it easier than creating aliases and keeping them up to date as things change. For speedwalks from clans, manors, etc people will still need to generate their own speedwalks.
Hope this explains more clearly what ‘runto’ will be.
Fiendish/Nick, just brain dumping here, hope I get this across correctly.
Mushclient can’t write to a specific X,Y position on a screen, but it redraws a full screen very quickly.
As the continents are very fixed format (60*40, 40*40, etc), it would seem reasonable to be able to store them in a lua table that is refreshed to the screen and update that lua table as necessary, without having to redraw bigmap every time.
I was thinking about protocol to have a ‘bigmap’ on your screen that constantly updates so you see the red asterisks as people run around, and see yourself move as you run across the map. This would require the ability, while standing on a continent, to receive tags whenever other (visible) players move across it to.
In terms of protocol, something that tells the client:
etc could be workable.
It would seem resource intensive, but each area already has a linked list of players in the area and continents are just large areas, so probably not.
This would be much tougher in a full area due to lack of coordinates, but could make for an interesting experiment on bigmap. Let me know if you want to try.
Worst case is we do something fun and unique on the test port that turns out to be too much of a hog to make it live.
> This would be much tougher in a full area due to lack of coordinates.
My idea for inside areas is just to output the continent coordinate of the area entrance. That way the player knows where they are in the world even when they get to an area by some way other than the continents.
Your idea of pushing updates for other players as well sounds really cool, but I wonder if it wouldn’t break some sort of realism barrier if the player knows too much. It’s reasonable to know where you are in the world. Not necessarily so reasonable to know where everyone else is also. Maybe only show the players within automap range? Maybe that would get to be too expensive.
I’ve created a forum thread over at the MUSHclient forums for converting what I have in zMUD to Lua in MUSHclient.
http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=8748
Lasher,
I missed this in my reply…
> As the continents are very fixed format (60*40, 40*40, etc), it would seem
> reasonable to be able to store them in a lua table…
Only if you make it so that the client actually sees a color code for every symbol when it goes to update the internal maps. Currently it does not. While the maps certainly display as rectangles, the color codes are not regularly spaced. On the client end, I see only one color code per block of same-colored text. That makes the maps actually quite irregularly shaped.
Just something to keep in mind.
Anything we do that encourages repeated use of ‘bigmap’ is not a good idea, a few people doing it in private scripts is fine, it a lot started to do it in something released officially we could see lag from it. Might have to artifically lag the command somewhat killing the whole concept if that became the case. As cool as this could be, smooth running of the MUD itself has to be priority.
With that being said, I dont think that is what you’re actually doing. Bigmap changes so rarely that we could probably product a tagged version. Just one possibility of how it could look:
[continent]mesolar[/continent]
[rooms]
[0,0]..symbol and color for room 0,0 here[/0,0]
[0,1] …[/0,1]
[/rooms]
This wouldn’t be in the mud itself, but a download on the website, updated as necessary. Making the bigmap command output something like this to a file is no big deal, sending it over the mud probably not a good idea.
Anyway, just one possibility. Im terms of areas, I didnt actually mean knowing where you were on bigmap when inside an area, but doing the same thing for an entire area itself. That could be achieved by assigning coordinates within areas.
It would also likely mean the death of non-euclidian mazes outside of clans, I don’t suspect too many tears would be shed over that
‘bigmap’ (or equivalent) need only be used when the continents actually change, which is almost never, because the map data gets stored. If anything, this would eliminate the need to use the mud’s version more than once per new area going in.
In terms of data from the mud, all we need is the continent name (shortened form is fine) and continent coordinates in tags at each movement (walking and running preferably).
There’s no need for any special formatting of the map. Just leave it as is.
If you want, it can even be retrieved from the web server from inside the client instead of using the bigmap command on the mud by using that trick I learned for web voting. Both ways should work equally well (assuming the web server doesn’t go down or time out).
Though a “playerless” version of the continent maps without the red asterisk that can be requested from anywhere (”basemap ” or something) would be most helpful if you choose to use the mud instead of the web server.
> Might have to artifically lag the command somewhat killing the whole concept
> if that became the case.
You already do lag the command. That was the whole reason for making my version in the first place.
> In terms of areas, I didnt actually mean knowing where you were on
> bigmap when inside an area
Oh. I did.
> but doing the same thing for an entire area itself. That could be achieved by
> assigning coordinates within areas.
Isn’t that what the automap is for? Or do you want a new mediummap for each area? Because that’d be…well…we’re going to run out of screen real-estate.
Yeah let’s shelve anything to do with internal areas for now - too many bigger projects in progress as it is. I think to do something with those I’d like to make a proxy program for it anyway with some graphics. Or wait to see how the new mapping protocol shapes up (and how “open” it is).
First off I’d like to say that it’s about time that MUSHclient got the props that it deserves. I switched from a bought and paid for zMUD to Mc a while back after seeing how clean the interface was. The only downside was that the majority of plugins/scripts were made for zMUD. So glad to hear this news since it will bring more script developers over to this badass client.
As far as suggestions go there is one I’d like to offer up. Alot of us Aard players are stat whores and the vast majority of us use level/quest triggers to gather, store, and report various things like time to level, mobs killed last level, stats gained, qp recieved, and time to complete quest/campaign.
Would it be too much to ask to have some of that info output onto the stats window?
Can’t wait to get my hands on this.
Where it’s get out????? man,this look so F***********NG!!!!!!!!!