I have couple nice things currently in my mind:

1) addActionListener for global (global variables) so that we could write a listener to react in situations where variables change.
2) actionListener for batwindow too. More precisely for closing the window. It would be nice to be able to do some cleaning if player closes the window (interrupt the running threads for example).
3) It would be nice if the batclient would call the close functions of the custom windows when closing or something, so that it would be possible to save the location of windows when the client is closed (for example with the actionlistener presented above)
4) Getters for size and location for batwindow interface. There are only setters currently as far as I know.

I created a statusbar -script and came to think that these would be useful features.

Regards,
Fitsio

About tab completition.

Now it seems to make a list of the possible completeable words from what words you type and see. And only completes the first word ever typed with a matching beginning.

IMO this could be a lot better. First of all, there is a bug if you type for example "tell risto,mikko,pekka moi", the tabcomplete-feature takes the names-argument, but omits the commas from that list. So after that if you type ris[tab], it will complete "ristomikkopekka", which is pretty much useless. After this it doesn't help no matter how many times you tell something to just "risto", the complete for "ris" will always be "ristomikkopekka".

So what I'm suggesting is that - if wanted - users could have total control over the tabcomplete-list. I tend to use that only for difficult-to-type player names, so it would be sufficent for me if I could just write a script that greps my friends and party for names and adds those as completeable.

Also it'd be really nice that the complete would roll over all possible alternatives of a written beginning (like in irssi). For example if I have two names pekka and petra in the list added in that order, now if I type p[tab] it will complete "pekka" and second tab won't do anything. So what I'd like is that if I typed p and pressed tab twice, the suggested word would be "petra". And even better yet if the entries would be suggested in alphabetical order and not in the one they were added.

Let me add a few feature requests/bugs (depends on how you see them) for the next version. Or if they are already in the current version, I apologise and ask for 11) more documentation.

1) Way to check if a self-created BatWindow is still open or closed. Maybe a listener like Fitsio suggested. Now I just close the old window manually with BatWindow.close() and then create a new one, but its location is reset.

2) Way to set BatWindows as always on top, and minimize.

3) Or a way to set main window (or other windows) as always on bottom. So that you can keep many smaller windows in the view, while still not resizing the main window to illegibly small size.

4) Let us move windows outside the working area in the main window. Now they just go as far as the borders go, which is pretty nasty if your screen size is small. I mud from a laptop with a 1024x768 screen, and in many of the windows there's lots of stuff which is sometimes unneeded, for example back rows in the party window. This is especially frustrating with the status monitor window which won't go closer than a kilometer from the borders. Also, if you are searching for a certain window under many others, it would be natural to move the top windows out of the way, but now you can't, if they are big enough. At least that would be in my computer using genes. Don't say "minimize" after you've read 2).

5) When scrolling the screen with page up and down, the screen scrolls exactly one screen. If the screen height is not an exact amount of lines, there is a line which is cut in half either on the top of the screen, or if you go a page up, on the bottom of the screen. Half lines are very illegible.

6) Fix TriggerManager.newTrigger() triggers to look and modify raw input instead of processed original line, or do some rework on the trigger system. Let me explain this a bit.

The intuitive way to look at triggers is that you get a line from the mud. It then gets passed to the first trigger in line, which modifies it somehow. Then the next trigger looks at this output and modifies it somehow, and this goes on until all the triggers have been processed.

I have my own plugin which looks at a line, in this case, battle line, and if it sees "Grinning diabolically" denoting a critical hit, it removes this from the line and adds "[crit 3]" to the end of the line (and in some point in the future, it will colour the line and ring a sound depending on if the crit was at you or at enemies). Now, I also have enabled the hilite.bcs trigset which comes with the client, but the triggers defined there don't see my modified line but the original one. Hilite trigger also sees "grinning diabolically", discards my modified line, and shows a line which has Grinning diabolically in red, and the rest of the original line as it is.

This "feature" has also another symptom. Another trigger in the set is for "unconscious" which it lites red. But if it sees unconscious on an already lited row, like on a channel, it discards the colour information and adds its own, so all you get is a white line with unconscious on red.

How could this be fixed? One way would be to modify newTrigger to look at the raw input. I think a better way would be to change trigger(String raw, String processedOriginalInput) to something like trigger(String rawInput, String processedInput, String rawOriginalInput, String processedOriginalInput). Of course processedInput would be the raw output of the previously processed trigger, but with no ansi control codes. This way the trigger programmer would not have to deal with control codes, but would also have the input it should have.

Another way to deal with colors would be to define some ColouredString class (extends String) which would define all the usual String functions but so that they retain colour information. Then trigger coder could just do his usual matches() or startsWith() or substring() and not worry about colours that much. In the end the colours would be used to produce a line for the user.

Finally I want to point out that BatMud seems to use some strange control codes like (esc)<20000000 and (esc)|, which I don't recognize, and can't google. If they are proprietary codes only for BatClient, it would make all the more sense to leave the control code processing to BatClient.

7) Add a way to define priorities for plugin triggers (for example the BatClientTrigger interface could define a function int getPriority()). Now you don't have any way to control which of your triggers go off in which order (maybe the file ordering of the .jars has to do something with it).

This, and the last item, has to do with stability. If you code something that you want to release to others, you want some control over things. If I would like to release the crit trigger I explained, I would have to add installation instructions "Please remove all your other triggers which satisfy these conditions..." which, for someone who uses just standard trig sets, might be a bit difficult. I, on the other hand, know that these trigs exist, and could define mine to go off the very last.

8) Line gagging for triggers defined in plugins. Returning null and "" are taken, so maybe return "some weird control code" or throw new GagException() should have to be used.

9) No word wrapping for clientside script editor. It isn't very natural to write word wrapped Java where // has visibility of one line and " " can't pass line boundaries.

10) Do something for command line browsing with up and down keys. Example: You type one command and press enter. Then you press up arrow to redo that command, and press enter. But next you have to press down arrow to get that last message back. Then you continue pressing down arrow + enter, to repeat that command. I find this up+down+down+down very odd, and if you're not paying too much attention (think of merchant skills or torch creation) you're bound to hit up enter somewhere, like you do in every other software in the earth.

Several requests:

1:

I would like to second Slobber's request for changes to handling of raw/processed text.

What I would really like to have is access to the way in which the client manages channels and sending mud output to these channels.

One way in which I can do this at the moment is to write a simple plug in that assigns some kind of attributes to lines of output from the mud and then dispatches lines to various channels based upon their attributes. I.e. I draw no distinction between special attributes for hilighting text and attributes that specify which channels a line of text should be sent to.

This is a bit of a duplication of effort since the client must contain some similar functionality. However, the real problem is that when one intercepts all text in order to assign attributes (channels or whatever), the original codes for colouring and emboldening of text etc are lost. Basically, unless I design a pretty smart set of triggers, I lose all the nice bold on exits, and various other hilights that are set by the mud itself.

So, please can we have some access to raw mud output, plain text output (what we have currently), and also Slobber's suggested processed output after a trigger.

2:

Triggers on text sent to the mud.

Please can we have a hook for catching text entered at the command line. This is incredibly useful for various purposes. It really is handy to be able to act on normal input and also to be able to modify regular input in special circumstances.

Also, this can allow custom logging to include input to the mud as well as output. Something that the current logging does not appear to do.

3:

Command line font. Please can we have some functionality to modify this.



Thanks
Tim

After a bit more poking around I've found the bits of Javadoc the the plugin interface.

This appears to offer most of what I need for dealing with output from the mud.

I assume that the chain of processing is something like:

Mud output ---> Initial buffering --> call to plugin trigger() methods --> call to script trigger() hook with plain text --> triggers --> channels --> windows

The plugin trigger() call supplies the much needed raw lines of text and codes from the mud.

However, I'm not certain as to the chain of processing and how to put things back into the chain at certain points.

The plugin trigger() method can be used to modify the text that is sent onwards in the chain, and, I assume, that through the use of a ClientGUI object, send text directly to channels.

I'm not sure how I would send text earlier into the chain so that the plugin trigger() methods may be called again (risking loops, but allowing a plugin to create output that other plugins can act upon).

Some clarification would be very handy, especially to those people who would like to implement processing in scripts rather than plugins (I think I'm pretty happy with the plugins).

Also, could we have some similar plugin hooks for text typed at prompts, before it is sent to the mud? Or is that already available?

Finally, the plugin functionality looks very nice to me, three cheers for whoever put that together, I think it's a bit better than I expected. Unless you advise me otherwise, I might look into creating a little plugin of a basic (crude) framework for "plugged in" triggers. A bit of a duplication of effort, but this would allow me to create myself a simple way to write sophisticated triggers with lots of channel handling and text attribute handling stuff. E.g. the [crit N] type of thing that has been previously mentioned that would allow script triggers (well, the regexps at least) to be created more easily.

Thanks

Tim.
Now, If I can get the JavaVM/Client to work on my kick ass home box, I might actually convert to using the bat client rather than tf, thereby saving some more sanity.

Amarth said some time ago that it's not coming. We're supposed to use mudside command and alias to do these things, or just $script execution, and I'm quite sure it can be done... if we get some of these:
1) mudside support to create a "command" command and alias quietly ("command -q asdf say fdsa")
2) ability to gag stuff from plugins (I'm not comfortable with trigger.newTrigger gags) so that I can gag the command creation lines myself.
3) mudside support to create an empty alias (eg. '_tgt' is aliased to ''), so that we still can use the default target in situations where it's needed.

Then, whenever you would want to dynamically alter the stuff you send on command line, you just have to automatically prepare a command or alias beforehand. Of course this is more work, but you get the added benefit of mudside almost-instantaneous batch command execution for the defined commands. The downside is, of course, that if you really go all out with this one, you'll have a hundred of command definitions per situation change (look, move, tick, battleround?), but I checked, it looks like a cheap operation mudside.

I'm planning an automatic targeter whenever I'm not too annoyed with coding, so at least that much seems possible and at least part of the previous chapter isn't sarcasm. But if you have interesting counter-examples, I'd like to hear them too.

Slobber

Regarding hooks for commands (text) sent to the mud:




I'm not sure that would help much for client side custom logging. Currently I can't find any way to record what I have typed at the command prompt or what has been sent to the mud.

Also, whenever triggers need to know what text was just sent, it's a damn sight easier to do client side than to have to create commands for every single operation that triggers may need to know about.

Allowing triggers to see commands typed for the mud is incredibly convenient for doing sophisticated client side operations without having to use awkward to type (or remember) syntax.

For example, tf functions can be invoked using "/function", no shift key press required on my keyboard, this is handy. However, I could go further and, under certain circumstances, I could pick up special keywords (with no special punctuation). So, rather than using a command like "/myfunc", I could just type "myfunc".

Tim

Another request:

I have been told that there are some additional codes/data transferred between the mud and batclient. If this is the case, would it be possible that some access is granted to this information?

If there are codes that help in the identification/classification of text from the mud, this would be particularly handy for people writing beanshell scripts and plugins that may need to recognize the origin of text.

Tim

Having access to the raw additional codes that batmud sends to the client is a straightforward solution, but might become a nightmare for code maintenance. It would be better if there's some sort of eventhandler for the additional information that batmud sends to the client, to which you can register your custom made handler.

I think in general, the current plugin design is immature. For decent plugin development, some sort of framework is needed which enables bat client users to combine plugins.

Developers need better ways to register triggers, gag output, access special client windows, etc. Personally, I started coding a set of triggers and enhancements, but put my project on-hold as I'm afraid a lot of things will/should be changed on how plugins are handled. Hopefully, the next client update will give us a better idea about triggers with the new trigger manager that's shown in the 1.7 sneak preview.

Hopefully some resources can be assigned to the documentation of public interfaces and classes, as the current javadoc is a bit sparse.

In my opinion this client has great potential, and the best way to promote its use is to have a nice set of player-made triggers and features.

Cheers,

Niliz.

I hadn't even considered that the Mud would send additional data entirely independently of normal output.

I entirely agree with what you have said, and I suspect there are other players who also think similar things.

Plugins are a nice step forward. However, it seems to me that they offer only two extra features beyond normal scripts: 1) the ability to write functionality purely in Java (i.e. not beanshell), 2) the ability to see ANSI codes in the trigger() method.

It is a shame that more of the internal interfaces were not exposed in some way. Some quite nice looking functionality for displaying party members etc has been added. However, there doesn't appear to be any way in which our script/plugins can modify/enchance or interact with these new features in any way.

I once requested that such extra functionality be provided by beanshell scripts, so that anyone who was interested could adapt the scripts or contribute compatible functionality. I can see how this may be an issue for copyright reasons. However, I still believe that work spent on a sensible framework, the core of the client, is at least as useful as work spent on extra features that could, potentially, be provided by players themselves.

Currently I find myself duplicating (rather basic) features of the client so that I can have some control over certain details. With a bit of luck I will be able to supply some working code (a plugin and maybe some scripts) that will demonstrate what I am up to. It's nothing very clever or even very useful, but should give an idea of why I ask for a more open/customizable interface to the client.

Tim

Plugins
=====


I've been doing a bit of investigation into bat client plugins. I have several requests.


1) Firstly, an old one. Please, please, please can we have some decent documentation.

I have spent some time finding out things that really could have been documented and really should be much easier to document than to discover by a trial and error approach.

In my opinion, the lack of proper documentation is far more likely to cause people to abandon the bat client than lack of functionality. If, in advance of any tinkering that I might try, I knew how certain functionality actually worked (or was intended to work), I would be able to save myself some trouble and get the client working to my tastes a lot more rapidly.

For me, the lack of documentation is the largest issue and, it could be argued, actually contributes to all the problems, drawbacks and omissions that I see in the client.

Also, while "how-to" style documentation is helpful, I have yet to see "how-to" documents that are an adequate alternative to proper documentation. So, please, could we first have some more detail on how things actually work, fit together etc etc followed by any examples of how to do things.

There are tonnes of questions that I could ask, mostly about small details. I won't put them
all here.


2a) The process() method.

Could this be altered and could the BatClientPlugin class be modified (uptuned!)

The process method looks like it is, potentially, the gateway between different plugins and scripts.

However, there doesn't appear to be a sensible way for plugins to get hold of a PluginManager object in order to call the processPlugin() method.

I've got this working by overriding the init method. I.e.

public void init(PluginManager pluginManager, ...
super.init(pluginManager, global, macroManager,
net, triggerManager, clientGUI);
this.pm = pluginManager; // Store the PluginManager.
}

There appear to be methods for retrieving the other interface objects (triggerManager etc).


2b) The data object argument to process().

Sadly, this is of limited use due to the way that plugins are loaded.

Each plugin is loaded by its own ClassLoader which means that all the classes defined in a plugin will be treated as different (incompatible) with similar classes of another plugin. Even if they are defined using the same class file (and even if the class file part of a single library archive shared by multiple plugins).

What this means is that it is pretty difficult to pass user defined classes between plugins or scripts and plugins. This takes a lot of potential out of the process method.

The method allows just a single argument and has no return value. If you can't pass a standard Java class to achieve what you want (and retrieve any result you may want), then you have to use reflection to get at the internals of the object that is passed to process.

I.e. The following code will NOT work.

[codebox]

public class MyData {
public String command;
public int count;
public boolean result;

public MyData(String cmd, int c) {
command = cmd;
count = c;
result = false;
}
}

MyData md = new MyData("get values", 10);
PluginManager.processPlugin("my_plugin", md);


// And then in the plugin:
// Using the same definition of MyData.

process(Object data) {

MyData md = (MyData)data;

....

}
[/codebox]

The result would be a class cast exception in the process() method of the plugin. Although the class of data will have the same name, methods, variables, as a MyData object. It will not be compatible with the MyData class that was loaded by the ClassLoader used for the plugin
(it doesn't matter if an interface is used, the result is the same, interfaces and classes loaded by different ClassLoaders are treated as different interfaces/classes).

My request is to have the facility to load interfaces (and other classes) into a parent of all the class loaders used for plugins. If it were possible to load classes higher up in the hierarchy and allow them to be used in all plugins, then it would allow plugins to communicate much more easily. My strategy would be to have plugins return an interface of some sort via the process() method.


3) Plugin initialization.

If plugins are to interact, there is another requirement. It would be necesssary to have plugins initialize in some ordered manner so that one can be certain that requests are not made to a not yet loaded/initialized plugin. Currently, my hack to do this is to place initial requests from one plugin to another in the connect() method of the requesting plugin. At this point, all plugins will have been initialized and the connect() method will be called before any other work is done.

Perhaps there could be several startup hook methods of BatClientPlugin that could be called in a particular order. One for plugin intialization and subsequent methods for further intialization after all plugins have loaded.


4) Channels and the generic window.

Please could we have some access to either how text is dispatched to different windows (tabs) or, at least, could we have a method to enumerate all the tabs and the channels associated with these tabs.

The generic window appears to pick up all "channels" not explicitly viewed elsewhere. However, suppose a plugin or script generates some output to go to a custom channel. This output may well duplicate, to a certain extent, output that goes to one, or more, other channels.

The result is that, unless you explicitly view the custom channel, you will get duplicate output in the generic window. This is, I believe, unavoidable if you want the generic window to work correctly. However, it may make the development of output generating scripts/plugins a bit more difficult because it requires users to set up their client to view particular (probably custom) channels or see the extraneous generic output.

A simple solution would be to make sure that output to custom channels is only generated when they are explicitly active somewhere, and/or when any channels receiving duplicate output are
not being viewed on the same tab as the custom channel.


Tim

These should be included in the next upcoming version, at least of most parts if not 100%.

Should be included in v1.70 also.

Some enhancements to these already implemented in next version.



We could probably do it the Winamp-style (aka sticky when reaching border, but letting it pass). Considering.



Good catch, added to the list. Let's see if it'll still make it to v1.70.



Let's see now..



This was an unintended feature and was on the list already.