Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Plugins ➜ Perspective on "World" files.

Perspective on "World" files.

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


Posted by Magnum   Canada  (580 posts)  Bio
Date Fri 09 Aug 2002 02:55 AM (UTC)
Message
Because this E-mail conversation turned lengthy and covered what I thought was an interesting perspective on my part, I'm posting the content here:
Quote:

Your plugin looks pretty cool.

Just a suggestion, maybe make some of the commands respond to no arguments, eg.

eqlvl
Huh?

That didn't match the alias, and I'm not sure what the syntax is, so you might respond:

Syntax: eqlvl <desired level>
Eg.     eqlvl 42

However you have taken the plugin idea and run with it, exactly how I was hoping it would happen. :) I suppose you have tried: /world.debug "plugins"

The new plugin wizard will simplify smaller plugins, and even ones like yours, and hopefully will lead to a whole swag of them being written.

Things like the recent requests "WHO lists to a separate window", "equipment to a separate window", etc, would all make good plugins.

Someone could also do a better "plugin_list" plugin - eg. list a single plugin if wanted, show all aliases, variables etc. and so on.

Anyway, looks good. :)

Regards,
- Nick

Thanks! :)

The "eqhelp" command accepts arguments. Specifically, the other aliases as arguments. For example "eqhelp eqlvl" gives you the help for the "eqlvl" alias. In most cases, if an argument is illegal for some reason, the plugin will list the appropriate help file for that alias. However, that said, your suggestion is valid. An alias that expects arguments should present the help if NO arguments were provided. I'll fix that.

Actually, I've never used /world.debug. For some reason, I've overlooked that function, but it's definitely useful for plugins, where there is no other quick method to check the value of a variable. I'll be using it in the future. :)

Although I currently only use one character at the primary mud I play, I envision some point where I will want to use more. This presents a challenge to me, because much of my script is still written in the main world's support structure. I don't like the idea of sharing a world file between characters, because the 'state' data should be independent for each player. I don't like the idea of cloning the world file, because changes reflected in one file will not migrate to the other files.

I have to admit, I wish you had designed MUSHclient with that in mind, keeping separate world files and player files to accommodate the different requirements.

With that perspective, the way to look at MUSHclient now, is that the world file is not actually the world file, but the --player-- file.

Given that, my tasks for the current mud I play are to migrate all "world" related material to plugins. It's the plugins that are truly the "world" files, for they can be incorporated into any "--player--" file.

For myself, that's a monumental task, because my "support structure" is quite large. I am currently looking at developing an "AOD_Monitor" plugin which handles the monitoring of a wide assortment of data from the mud, such as my current health, how long a spell has been effecting me or a mob, etc. I am also considering developing an "AOD_Spell_Queue" plugin, which is responsible for allowing me to queue spells\skills so that they will cast one after another. This one has it's complexities, because I might want to develop it with sub-plugins of it's own, one for each guild in the game... (Which could be problematic because some guilds share skills\spells with other guilds). Yet another plugin I am considering is an "AOD_AutoBots" plugin. It would be a controversial plugin that does many of the things people already automate on the mud, but no one wants to talk about, for fear of being site banned for illegal script use. Stuff like repeat heal skill when one completes, repeat offensive spell when one completes, autoleave the ferry, corpse looting (when your flag is
removed on a mob), etc.

The biggest challenge to all of that is the interdependency between the plugins. All of those proposed plugins require certain levels of interdependency on the others. The "monitor" calls the "Spellqueue" when my health drops too low, the "Autobots" only function when they are toggled on, and depend on "Monitor" data, and issue calls to the "SpellQueue", etc. Given the stickiness of making cross-plugin calls, this could require some interesting and
innovative subroutines. Also, because of that interdependency, I pretty much need all 3 to in production at the same time, else I go without a lot of functionality while I develop the next one. It's enough to make me want to just keep them all in the current state they are in... but again, it's not practical if I want to develop ALT characters.

Anyway, the reason I got into all that ranting was simply to respond to your suggested plugins. :) I agree, they would all be valuable... but if you were trying to make a 'hint', I'm afraid I might be too busy with my own Godzilla's to tackle any small fries. I expect pretty much all of my plugins will be comparable in size and complexity to my current "AOD_EQ" plugin. (And somewhere in there I've got to do some playing! LOL)

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

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

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #1 on Fri 09 Aug 2002 02:57 AM (UTC)

Amended on Fri 09 Aug 2002 07:59 AM (UTC) by Magnum

Message
Quote:

I have to admit, I wish you had designed MUSHclient with that in mind, keeping separate world files and player files to accommodate the different requirements.

With that perspective, the way to look at MUSHclient now, is that the world file is not actually the world file, but the --player-- file.

What I am intending, and you can do it right now to a certain extent (a fairly large extent) is to use include files inside world file. Thus you can share fixed things between characters.

eg. (off the top of my head):

<include name="My standard world file settings.xml" />
<include name="My standard triggers.xml" />
<include name="My standard aliases.xml" />
<include name="My standard timers.xml" />

<world
  player = "Magnum"
  password = "Swordfish"
>

I think that would work, I intend it to.

This lets the world file become the player file, and the include files become the world files, which is what you are trying to achieve, but coming at it from another direction.

Of course, using plugins does a similar thing anyway (as they are include files).
Quote:

Also, because of that interdependency, I pretty much need all 3 to in production at the same time, else I go without a lot of functionality while I develop the next one. It's enough to make me want to just keep them all in the current state they are in... but again, it's not practical if I want to develop ALT characters.

Perhaps to a certain extent, include files would solve this.
Quote:

Anyway, the reason I got into all that ranting was simply to respond to your suggested plugins. :) I agree, they would all be valuable... but if you were trying to make a 'hint', I'm afraid I might be too busy with my own Godzilla's to tackle any small fries.

No matter, I might do them myself to test my plugin wizard. You may find it will help you automate the conversion of your world files into plugins, as what it does is let you select (deselect) existing triggers etc. thus taking a desired subset of your own world file and turn it into one plugin (ie., all related things). This should actually be simple and quick, although the scripting support will be harder, obviously.
Quote:

As I was writing this, I realized there may be some value in posting it to the forums. Would you mind? (I would remove your "P.S., and down).

Sure, go ahead. :)

- Nick

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

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

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #2 on Fri 09 Aug 2002 03:03 AM (UTC)
Message
Yup. The "include" solution works well. Although it would take some work to convert my script to plugins, I'll likely do it anyway at some point, just because it was a labour of love writing them, and it would be a pleasure to share them with other AOD players.

The Admin's have pretty much kept off my back for the most part... hopefully because they realize I am not writing anything that auto - gains experience or gains money. It's a very thin line to tread, and I don't want to cross it and get banned from the mud.

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

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

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #3 on Fri 09 Aug 2002 08:41 PM (UTC)

Amended on Fri 09 Aug 2002 08:45 PM (UTC) by Shadowfyr

Message
Yeah.. With all the new stuff you seem to be planning to add though, you are probably walking an even thinner line. lol

The most complex thing I have done so far I am also currently 90% through changing to a plugin. It is a 'legal' version of my potion lister for druids. Legal in that it hasn't a clue what potions exist, how they are mixed or what herbs can be found, until someone forages for herbs and mixes something with them. Support exists to add them manually as well. ;)

Spent the last two days designing all the 'support' files, including the help, now I have to rewrite the actual list part. The whole thing is only 3 subs in my world file, but like 15 in the plugin, because I need to provide all the commands, help, etc. to use it without anything hard coded into it. :p Now I need to completely redesign the three original subs to deal if all the changes. lol Going to be interesting.

You should get a kick out of this (which I discovered trying to find an easy solution to array problems):

c = split("x,y,z",",")
redim preserve c(1)
world.note join (c,",")

produces: ,
The data is not preserved, but the array is resized. ?? Why?

dim c(2)
c = split("x,y,z",",")
redim preserve c(1)

Generates and error: array fixed or locked. Huh?

redim c(2)
c = split("x,y,z",",")
redim preserve c(1)
world.note join (c,",")

Actually produces the right result: x,y

Let us all give thanks and praise MicroSloth for their consistancy and exceptional documentation of features.. lol
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.


15,281 views.

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

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.