Gammon Forum : MUSHclient : Suggestions : Future versions: Implementing Plugins

Entire forum ➜ MUSHclient ➜ Suggestions ➜ Future versions: Implementing Plugins

Future versions: Implementing Plugins

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2

Posted by

Magnum Canada (580 posts) Bio

Date

Reply #15 on Sun 26 May 2002 04:52 AM (UTC)

Message

Quote:

I don't like the idea of writing to plugin files.

You make some good points in that post, that I hadn't considered. You're absolutely right.

I suppose if you ever managed to adopt the nested objects idea, you could just store the whole Global Object, and all it's nested Objects in the main XML file, but that's a road that won't get travelled any time soon.

Like I indicated before, my brain is fried on the subject. I'll leave it in your hands for the time being, till I get a feel for where you are going with the Plugin idea, and how you are implementing it.

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.

Top

Posted by

DanPrice Australia (3 posts) Bio

Date

Reply #16 on Fri 31 May 2002 01:34 PM (UTC)

Message

Well, as an amateur coder, i can say that most of this conversation is way over my head.
But in the spirit of contribution i thought i would say how i think that you should make the plugins work, in the moron's programming language of english.

First off, I've decided that the 'plugins' should be little program sort of things, e.g. item databases, world mappers, that sort of thing. In my magical world of plugins, the plugin would have three basic 'sections', 1.something to start it,
2.the thing that it does and
3.what it sends back to the world.
The start would be like a 'trigger' or alias to make it go off and to collect any data that it needs to run. Next, the plugin runs, does its thing. Finally, if it needs to, it sends stuff either to the mud window (eg if you change the look), or back to the actual mud.

In this sort of thing the plugin is like a parasite that leeches onto mushclient. It has its own little dropdown menu or tab or whatever, and under this it has other little areas for any triggers it might use, any variables it uses, a help file explaining it, this sort of thing. *IF* the plugin wants to get other triggers that arent part of it, well it should be able to, just let it do it via the existing script functions. I reckon that'll solve the problem of having the same names for triggers.

So this is what i think a plugin should be. i realise this probably does help but i think it sort of explains my suggestion on how to code it so the little morons like me can understand them and make their very own. Having said this, if i have grasped the wrong end of the stick, please tell me if im talking complete nonsense, i'd like to know :P

Would you like some gum?
Go on, its spearmint flavour....

Top

Posted by

Shadowfyr USA (1,792 posts) Bio

Date

Reply #17 on Fri 31 May 2002 09:25 PM (UTC)

Amended on Fri 31 May 2002 09:27 PM (UTC) by Shadowfyr

Message

Well Dan.. I have put a bit of thought into making a sort of floating task bar sort of thing that could support such plugins as you are talking about and link itself into MUSHClient through triggers and scripting, however imbedding such a thing into MUSHClient directly has to potential to slow the client down a lot and thus is not likely to happen unless someone can 'prove' that it can be done without causing such a drop in efficiency and since this isn't opensource it won't happen. ;)

As to what we are discussing... We are talking about the ability to include other peoples scripts into our own worlds in a way that lets both our scripts and theirs to work as intended without interfering with one another. In this sense a 'plugin' is a piece of a world file with scripts, triggers and other things that are needed to use someone elses code, but loaded in such a way that they won't do anything but what they are intended to do. The problem is that there are a lot of things they need to do and many of those things have the potential of messing with stuff your own scripts and world files have no way to know have been changed by a plugin. The issue is how to allow them and still effectively prevent such conflicts. I believe we have resolved most of the issues, but there may still be a few issues that need to be resolved, but we are waiting to see how Gammon figures out how to fit things together before jumping in again to point out all the flaws. ;)

One big issue though is what to do if the plugged-in script 'needs' to be able to store settings or data and expects the clients world file variables to store that information. It is the only major thing we haven't really resolved in our discussions.

Top

Posted by

Nick Gammon Australia (23,173 posts) Bio Forum Administrator

Date

Reply #18 on Fri 31 May 2002 10:25 PM (UTC)

Message

DanPrice,

You have described pretty closely how I intend plugins to work, so you are on the track. :)

Just as an update, I have most of that working now. A plugin (written in XML) implements the following:

Triggers
Aliases
Timers
Variables
Scripts

All in their own space (namespace? engine?) so they don't clash with other MUSHclient things of the same name. Also, scripts can be in their own language (eg. one plugin in VBscript, another in Jscript, a third in Perlscript).

Most of the existing script commands will refer to their own namespace (eg. addtrigger), again to prevent clashes.

I haven't yet tackled "saving state", and in any case I think some plugins won't need to. By saving state I mean remembering from one invocation (of MUSHclient) to the next what it was up to (list of spells etc.).

However what seems reasonable is to allow a script to save its variables into a "plugin save file", on a plugin-world basis. What I mean by that is, since plugins might be shared between worlds, you need to save the state per plugin, per world. eg. if you have 5 plugins and 4 worlds you potentially have 20 states that need saving.

It all seems to work fairly well, and I am now implementing a GUI interface (plugin list) so you can add/remove plugins in an orderly way.

After some fairly extensive testing I should be able to let some keen scripters at it in the middle of next week. The sooner the better, as a lot of the replies to queries on the forum would be well done as a small plugin.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

67,327 views.

This is page 2, subject is 2 pages long: 1 2

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top