Some ideas...

Been reading up on COM objects and trying to figure out a reasonable way to do something to integrate with MUSHClient. The following is a general concept I developed:



The '0' are COM interfaces. Basically Each plugin has the basic set of COM interfaces, but also a requirement that designers include ObjectName.Setup interface which passes the plugin code in the program a list of available commands, their inputs/outputs and any other info needed to add menu items, client interfaces, configuration and help files.

So.. You could then from in MUSHclient access the help for that plugin or send calls to it by sending the appropriate commands to the menu program. Current possibilities for plugins are:

Item database
A real mapper
My spell icon concept
A renderer (Produces a 3D pic from a text file or through
FTP to a server).
As in Render.Generate ("FTP", "ftp://ftp.someplace.com/file.sdl") or
Render.Generate ("Stream", "data from the mud").

So for instance if you used an alias to cast a spell it would call a script with something like:

Menusvr.command("SPIcon","Myworld","MySpell","Activate")

and then a trigger matching on the spell ending would call:

Menusvr.command("SPIcon","Myworld","MySpell","Terminate")

The menu itself would check to make sure a SPIcon plugin was loaded and that 'Activate' and 'Terminate' where valid command (from the setup) and call the linked COM interfaces to make it happen. One useful thing about this is you can add a Menusvr.Focus("Myworld") command that would automatically switch to or open/close windows plugins being used by each world by calling a 'hide' command in active ones and 'focus' in those that match the world. Along with the 'setup' command, these would be 'required' interfaces in the plugins, with predictable behaviors.

As for the mapper.. One obvious problem with them is exits that don't enter the same way they left and special commands. The special exit one is note easy to solve, but a drag-and-drop that let you 'merge' rooms where the exits are not the strict reverse of the entry would be fairly simple. Built in to a client you can use available exits and room descriptions to make a better match, but... 'if' I do make a mapper it will likely be a major challange to feed the built in mapping data to an external program to 'map' exits in only one direction (and hope that the correct exit is also the opposite one when headed back). For something like this though, it is a real problem, since merging a room is easy, but 'splitting' a bad one correctly...:

Room1
Some stuff.

Exits north and west.

north

Room2
Other stuff.

Exits south and east.

south

Room3 <-oops!
Some more stuff.

Exits north and southwest.

Similar complications would be true for an item database, since you would have to manual add them or trigger/script for only when you go to the shop to price them or something. It would also tend to be a lot more variable across worlds. :p

In any case I 'think' I can figure out how to make most of this work, but.. I need the basic menu bar program to load when you call it from MUSHClient, but be able to 'stay' loaded. The problem is that COM assumes that once the client is done talking to something it should release the object. :p A non-COM interface would be a pain and using an intermediary to run the menu doesn't work very well, since it has no real way to know if the program has actually loaded. This causes problems between Moray and POVRay, which use such an interface. I am also not entirely sure who to use a COM to talk 'between' two stand alone programs.

Making the menu itself a COM object would be best, but then it isn't loadable (It would be an EXE, but...??) without MUSHclient running and I am uncertain how MUSHclient releases COM objects (when the connection closes or you close the world?) To get around this I need a way to keep the menu running even if MUSHclinet dies completely. So... Can a COM server be it's own 'client'? If so then it could keep itself open until you shut it down from the menu itself. If not, then I have a major problem.

This is very confusing. lol

It would be much easier if I didn't have to worry about having the system shut down the server object unexpectedly because it thinks it isn't needed anymore, but COM isn't intended for 'persistant' execution. :p

Of course... It would be a lot easier if this was intergrated into MUSHclient, especially since I wouldn't need to code it then. Hint, hint. ;) (And those of you who think it is a good idea might actually see it happen eventually. lol)

This is an interesting and ambitious project. :)

I don't see why it couldn't work, and don't agree that COM can't be used for persistent execution. For example, when MUSHclient loads your script file it uses COM to compile the script, and remembers the dispatch ID of each routine needed (eg. triggers).

Then, later on, when the trigger fires it calls the COM routine identified by the dispatch ID. Thus, it is persistent for the entire execution of MUSHclient.

Similarly, the variables used in your scripts (global variables, ie. those outside subs) are remembered from call to call, so they persist too.

I think you could instantiate an external COM object, keeping its pointer in a global variable, use it when needed, and then release it at shutdown (eg. on world close script). That should all work OK.

I could make a DLL interface, and have plug-ins, but why bother when this works?

>I think you could instantiate an external COM object,
>keeping its pointer in a global variable, use it when
>needed, and then release it at shutdown (eg. on world
>close script). That should all work OK.

Yes, but that is sort of the point. You can have client crashes (rare), script bugs that require reloading them, etc. All such things can terminate the COM server and lose track of where things are and what is happening. It can probably be worked around, but I would rather have it runnable using a call, but also stand alone. In the case of Moray and POVRay the COM link used can run POVRay from inside Moray, but generally it works poorly since the linking object is not really 'aware' of the other programs execution, so it can mistakenly believe it loaded and ready when it is not. There is no easy way to fix this. I suppose I could make it save a datafile with all info for the worlds being used so if something crops up it can 'reset' to a prior state, but it would be necessary to also force users to save the state info in the plugins or pass the needed data to the server as part of the shutdown process. It is unwieldy and prone to collisions where it is still busy trying to sort stuff out and the client starts talking to it again. I would rather have it loadable, but capable of being used offline and that looks to be a bit complicated.

The individual plugins are not a problem, it is keeping the server alive long enough to deal with any such accidents or for offline use. COM was not really intended to allow either.

>I could make a DLL interface, and have plug-ins, but why
>bother when this works?

Because there is no 'direct' way to pass some forms of data to an external program. A mapper for instance should recieve 1) the command that was sent, 2) A room description and 3) the exits for that room.

Item 1 can't be passed easilly from the client, though you can sort of fake it by pulling the data from the current mapping feature and feeding that into a program. The problem is you can't extend the set of commands recognized, so unless you alias every instance of nw, ne, sw, se, out, enter *, leave, climb, etc. you can't catch those that are not standard. It makes doing it right a nightmare.

Items 2 and 3 are nearly impossible to get. You can, but the irony here is that you can retrieve the non-standard ones really easy, but standard n, s, e, w, u, d are not 'caught' by aliases or other methods that can call scripts, so grabbing the room info can't be done for them.

Trying to do it externally is a mess and there are probably other cases where getting data from the client to the external COM object is a major pain. I see only two real advantages I see with my idea is that it can be linked to other programs, but since MUSHclient is the only Windows client that supports it.... which is a dubious recommendation for this method. The other benefit is that you don't take up space in the clients name space keeping track of the whole mess. This is helpful, but I am not sure it outways the limitation of trying to shoehorn some things in through the scripting.

Most things I agree can be done the way I intend. The mapper though is a pain to get right when built in, it will be a nightmare to make work the way MUSHclient handles directions and its own limited path caching.

Maybe an optional new script routine to go with the world.connect, etc., called world.OnCommand. It would execute each time a new command was sent to output and let you handle it directly. Currently there is no way to execute a script whenever a command is sent, so mapping like I want to do would be on a 1 second timer. You could move 3-4 rooms in some cases in the time it would take for the mapping script to even realize it had something to do. This precludes setting a trigger to grab the room text, as you would need in order to successfully run such a good mapper. It just isn't feasible as things stand. I had planned to cheat and just map the direction you moved and let the person go back and call a capture script to get exits and room description, but it is a silly way to do it.

I hate to contradict you, but keypad commands are indeed captured by aliases, thus you can implement an "oncommand" right now with the current version. Just make an alias:


Match on: *
Label: blah
Script: OnCommand


An example script will demonstrate how it works. You could put a case statement in there if you wanted to capture all commands and process them yourself.

?? Can more than one alias match on a command? It 'looks' like aliases match on the first thing they see, unlike triggers which you can tell to continue matching on other items.

If it does match '*', then still continues on to match on other aliases then fine, but having to build a script to deal with everything that you alias, because it ignores all matches after the first one, would be worse than it is already. I am also slightly unclear about how commands in macros are passed to the command list, since it seems odd that a macro should match an alias if the intent was to 'only' do what is set in the macro. For instance.. If I use a F2 macro that does 'injure giant' I don't necessarilly want it to execute an 'injure *' alias that does:

flag giant
injure giant

The only way to avoid this, that I can see, is for macros to not pass their commands to the alias parser and then n, s, e, w, etc. would still not be caught, since they are passed by the macro system, not the normal command window. If I can't use the keypad what is the point of having support for one? This is one of those either/or cases. Either it passes macro output to the alias parser and fowls some things up or it doesn't and messes something else up. It can't work both ways. When you add better macro support including the ability to call scripts from them this will go away, but for now the behaviour you suggest is true has major drawbacks and I don't see how it can work if it behaves differently.

You raise some interesting points. :)

Aliases are iteratively tested, so a quick test will show that you can have an alias that matches on "*" and also match on other things.

However I think the problem you will probably detect is that the alias will match on the results of the previous alias sustitution.

Thus, depending on the order, if you had two aliases:

Match: *

and

Match: k
Send: kick

The one that matched on "*" might get "k" or "kick" sent to it.

I am out of room to add more strings to the world file, so an "oncommand" callback will have to wait until I convert the world file into XML format, something that is not that far off.

Meanwhile, yes, macros (eg. F3) and keypad keys *do* go through alias detection. This is a feature, that is mentioned in various other posts. eg. You can use that to make a key (like F3) call a script.

Macro: F3
Send: _froggle_it_

Alias: _froggle_it_
Script: my_script_here

Thus, pressing F3 in this example would call a script. If macros (and keypad keys) didn't do that then you would lose the ability to bind them to script routines.

In your example (injure giant) if this particular case was a problem then you could work around it by sending the text indirectly.

eg.

Macro: F2
Send: _injure_giant_interim_word_

Alias: _injure_giant_interim_word_
Script: do_injure_giant

Script does: world.send "injure giant"

You are the first to say this is a problem, and even in this case I think you making up a hypothetical situation.

When the world file moves to XML it will be easier to add extra flags (eg. send directly, send via alias etc.).

For now the default behaviour seems to suit most people.

Your correct, it is a hypothitical situation, since I usually use much shorter things like 'cf *' which for me calls a script to make sure I am not doing something stupid like flagging and attacking my slave or familiar, then flags the mob and hits it with the spell I currently have set up. However.. The spell I currently use is called 'hail' so had I set this alias up now rather than several months ago when I used 'cause wounds' the name is short enough I could have easilly made the mistake of creating an alias and a macro that employed the same command. The only reason it wouldn't have caused me a problem is the fact that I don't need to target a mob that I am already fighting.

I picked up the habit of thinking about hypothetical possibilities in highschool programming to some extent and had it later hammered into me in college where failing to consider a possible side effect could crash a report generator or database management system on a mainframe. It is a bit hard for me to not notice these sorts of things. ;) lol

Just think about this, ShadowFyr:

The more you pose these hypothetical problems to Nick, the less time he has to code new features into the client. :)

I try and keep the requests down to the essentials that I actually desire... or, like in the case of the SetCommand-related functions, I made a few extra suggestions to 'complete' the command box handling routines, even though some are a little esoteric, and may not be used often. Still... I see some interesting possibilities now they will exist...

Maybe true Magnum.. Generally I only mention stuff I plan to use as well and only press the issue when the solution requires some complex work around. The more time the client spends doing w-x-y-z, when it should simply do y-z the less efficient it is anyway. ;) Sometimes it is better to have more than one way to do something simply because it is faster and less complex (especially for new people). I only present hypotheticals when I see something that I consider an unneeded complication or just plain impossible. The fact that currently only Gammon has a real clear idea what actually works and what doesn't tends to not help things much either.

Where's that new help...? lol

In any case Gammon did say I made some good points. The fact that you can work around the problem doesn't change the validity of that fact. If you say nothing, nothing changes. ;)

You are right ShadowFyr, it is very good to think about what hypothetically might go wrong as you code, something I do all the time. Most of the time I second-guess problems before they arise, sometimes I don't, which is how you can crash the client in rather obscure ways, like deleting a trigger in the script routine that that trigger called - ie deleting it from under itself.

However in your example of the way command input is processed, then if I changed that then it would make it stop working for other people.

As I said, when I have a more flexible world file layout, I can add extra flags, eg. an alias might be flagged to not be tested against a function key, or vice-versa.

I am planning to try to integrate web help and program help into one set of files. That way you can get the same help as in the program, on the web, rather than having me having to put everything in twice.

Once I finalise the features in the new version, I'll take a look at the help file.

>However in your example of the way command input is
>processed, then if I changed that then it would make it stop
>working for other people.

And I understand the reason this is true. I was just replying to Magnum's sort of implication that mearly pointing out possible problems is some how inappropriate.

As to the help.. I understand that as well. It is definitely a good idea to get new changes working first. I didn't imply otherwise.