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 ➜ Suggestions ➜ Global Defaults, Logging (and XML format)

Global Defaults, Logging (and XML format)

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


Pages: 1  2 3  4  

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #15 on Wed 22 May 2002 02:32 AM (UTC)
Message
Cool! Thanks for implementing those, Nick.

Regarding this whole other "VM" thing:

First, you already have "virtual machines" in a sense, in that the client can be connected to multiple worlds (or the same world multiple times), and each runs with their own independant settings, etc.

When I talk about "virtual machines", I am thinking of the same thing, in most respects, except that each independant/virtual world settings space shares the command/box and output, and the "core" settings. This can be accomplished fairly easily by importing the "core" settings when you initialize the plugin/include code space.

If I were zapped into Nick's shoes, here's what I would do:

Create a new settings module, perhaps call it "formatting".
- Move "Echo my input in <colour>" to "formatting"
- Move "Note Colour" to "formatting".

Break the "World Details" GUI interface in two:
- Core/Main/Root/Base World Settings.
- World Interaction settings.

Core/Main/Root/Base World Settings:
- General | IP address
- General | Notes
- Appearance | Output
- Appearance | MXP/Pueblo
- Appearance | Sounds
- Appearance | Printing
- Input | Commands (Excluding input colour and SpeedWalking)
- Input | Keypad
- Input | Macros
- Input | Autosay
- Paste/Send | Paste
- Paste/Send | Send
- Scripting | Only the "Script Prefix" setting.

Interactive Settings:
- General | Connecting (Name, Password)
- General | Logging
- General | Timers
- Appearance | ANSI Colour *
- Appearance | Custom Colour *
- Appearance | "Formatting" * (See above)
- Appearance | Triggers
- Input | Commands - SpeedWalking ONLY
- Input | Aliases
- Scripting | Scripts (Except Prefix Character)
- Scripting | Variables

The Core settings could only be established in two places:
Global Preferences | Defaults.
Main/Core World file (which will over-ride Defaults).

The Interactive settings could be established in multiple places:
Global Preferences | Defaults.
Main/Core World file (which will over-ride Defaults).
Include files (run in a virtual machine).

You could then have multiple "virtual machines" acting on the same world input/output.

Each VM/Include inherits the Core settings, but NOT the Interactive Settings (from the Core file).

Items marked with a * can be over-ridden in VM/Include files, but the Core file MUST have default values, and certain aspects (such as Input/Output screen formatting) can not be over-ridden. (They are ignored). (I.E: Output from the mud will use the "Core" colour files, but Output from scripts/Triggers/Aliases may use colours further customized in their own VM/Include space.)

The GUI Interface for adjusting "Interactive" settings would allow you to dictate which machine's settings you are interacting upon. (By default the "Core" machine's).

I feel like I've went over this quite a bit. Hopefully, you comprehend what I'm trying to get across. If you want even more details, I'll be happy to go into even more detail, though I am pretty sure this thread is fairly comprehensive now. :)

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 #16 on Wed 22 May 2002 02:59 AM (UTC)
Message
I wrote that last posting while offline, & watching my home team the Leafs lose another hockey game. :(

Shadowfyr: I call them virtual machines, because it's a pull from Windows technology.

If you load a DOS program in Windows, it is run in what is called a "virtual machine". From the perspective of that DOS program, it has a whole machine to itself. You can open up a second DOS program at the same time, and from the second DOS program's perspective, it ALSO thinks it has a whole machine to itself.

What you see on the screen, and what you type at the keyboard is only directed to the DOS program that has focus. They each run in their own "virtual machine", but they share the same hardware, and even software drivers (though they don't know it).

When you open up Mushclient, each world has it's own "World Space". You can have a "heal" alias in one world, and a "heal" alias in another world, and they may do two completely different things. You could have a variable called "Target" in one world, and another variable called "Target" in another world, and they can have different values. In a sense, each world is running in a "virtual" environment (or machine), and you can have multiple environments open at the same time.

What I propose is to allow "virtual" environments to be open for the SAME world, much in the sense VM's operate under windows, except what is typed at the keyboard, and what comes in from the world, is processed by EACH VM, instead of just one. Understand? Good. :) ...Now go back and read this thread from the beginning (and the other one where I proposed this too). :)

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

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

Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #17 on Wed 22 May 2002 04:34 AM (UTC)

Amended on Wed 22 May 2002 04:37 AM (UTC) by Nick Gammon

Message
Hmmm, Magnum you have obviously put a lot of thought into this so I hate to pour cold water onto it :P but I do have a few problems with it ...


  • Complexity - I don't want MUSHclient to get so complex to configure that people start saying "ah yes, MUSHclient was good until it got too complex to use". This idea of virtual machines might appeal to programmers but for many users could just be confusing
  • Implementation issues - you still have collision problems as far as I can see. For example, there is only one command area, so if you have two aliases (say, called "shop") - one in each VM - and one does "north; west" and the other does "south; east" what happens when you type "shop"?
  • GUI changes - it will get more complex to configure, and you still have the issue of how do you represent in the GUI interface whether a variable (eg. note colour) is a default or a world override?
  • Time - if you said to me "I just want the new version with the bug fixes and the include files, and I'll wear the possible overwriting of values" I could have it out in 30 minutes.
    But if you want all the changes to support virtual machines - multiple script environments, multiple script files, more complex GUI configuration interface, and so on - then I might have to say "that'll be another month away".
    Then I ask myself "will the time taken to make all those changes be repaid in registrations"? I mean, are there (say) 500 people who have not yet registered, who will if MUSHclient offers virtual machines. I doubt it somehow.


I have been thinking about this at some length today, and think this will be a workable compromise ...


  • You can have any number of <include> directives. Each of them can have, if you wish, the general settings (the <world> ones).
  • When reading the include files any setting that is duplicated will simply take the later one. eg.

    <world input_background_colour="gray" > </world>
    <world input_background_colour="blue" > </world>
    <world input_background_colour="red" > </world>

    So, it is up to you to have reasonably well set-out include files. A simple method is simply to have a default world file as the include file, that way you simply edit that world to change your default settings.

  • Any value read from an include file (but not from the "main" world file) is marked as "an included value" - in a separate internal table.

    eg.

    input_background_colour="red" (included)
    history_lines="1000" (main file)

  • If you then present the same attribute in the main file it still overwrites the included value. This gives you the means to have different values for some fields (eg. world IP address).

  • In the case of triggers, aliases, timers and variables, the overwriting occurs (if it occurs at all) based on the label (name). eg. trigger label "a" will overwrite trigger label "a".



So far, so good. The general rule here is "the last value prevails".

Now, the important bit ...


  • When saving a world file, any value that was:

    • Originally found in an include file; and
    • Still the same value as in the include file

    is not written out to the main world file.

    If this wasn't done, then every value (eg. input_background_colour) would be written back to the main file, and then would override the defaults, which isn't what you would want, if you ever changed the defaults - that is, the include file.

  • You will have provision (eg. a button) to "revert to defaults" which will have the effect of changing every attribute back to the value from the include file. Thus, if you changed the input_background_colour to green, and wanted to put it back to the default (included) value, clicking that button would do it. If you wanted to go back to the MUSHclient defaults, you would simply throw away the reference to the include file (ie. un-include it).



I think these proposals are reasonably simple to understand, and easy enough to implement. :)

- Nick Gammon

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

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #18 on Wed 22 May 2002 06:12 AM (UTC)
Message
You'll pardon me for countering your points, if only for the sake of a productive conversation that serves as a history for why MUclient has evolved in the manner that it did. :)
Quote:

Complexity - I don't want MUSHclient to get so complex to configure that people start saying "ah yes, MUSHclient was good until it got too complex to use". This idea of virtual machines might appeal to programmers but for many users could just be confusing

A lot of what I propose appears complicated for the manner in which you may have to overhaul/upgrade the client, but in the end, the interface would not be all that much different. I'll explain more 2 points down.

Under the current implementation (or the one you propose), as soon as the user attempts to do some "advanced" actions, things can get very complicated. I am thinking especially of shared "plugin" scripts. Frankly, installing someone else's script is a bitch, because you have to edit your main script file (Something newbies are afraid to do) to modify the current "workaround" method for using an "include" script. Your method would still not allow multiple scripts be called from XML files, and further, all script files MUST be in the same language.
Quote:

Implementation issues - you still have collision problems as far as I can see. For example, there is only one command area, so if you have two aliases (say, called "shop") - one in each VM - and one does "north; west" and the other does "south; east" what happens when you type "shop"?

When installing 3rd party XML or Script files, the user (or the programmer) has to worry about Alias\Trigger\Timer\Variable collisions. This is NOT as much an issue under my suggestion. (Since each are stored in their own "world space"\"virtual machine"). Same trigger names? Who cares! They won't collide.

Yes, your example presents a problem. First one VM would act on the alias (moving "north; west", THEN the other VM would ALSO act on the alias (moving "south; east"). However, I expect movement collisions like that would be very rare. On the other hand, an alias like "status" might be common, and if you had one in each VM, you would probably PREFER (as the user) that they BOTH get processed, rather than only one (wrong) one. I feel my proposal actually servers to improve the collision situation, since they all get processed, rather than just one. (Isn't that better)?

When it comes to plugins, it may be very hard to predict what another programmer will do. (Erase variables, Triggers, Aliases?!). Not an issue with my proposal.

Heh... As a side note, if you had each VM configured to use slightly different "Input my commands in <colour>" setting, you could tell by the colour which VM's Script/Alias/Trigger had sent what commands. :)
Quote:

GUI changes - it will get more complex to configure, and you still have the issue of how do you represent in the GUI interface whether a variable (eg. note colour) is a default or a world override?

Breaking the "World Details" into two entities sounds complicated, but I believe it doesn't really have to be. You could still have icons to quickly access your alias, trigger, timer screens, etc... For the amateur user, they would likely only interact with the "Core" VM settings, and that's perfectly fine. It would be much the same as it already is. Besides seperate interfaces for "Core" and "Include" settings, you basically only need to add one more tool. Here's a crude ANSI drawing:

------------------------------------------------------
Configuration - Merentha
------------------------------------------------------
- Main Settings       |
|  - General          |
|  |   L IP address   |
|  |   L Notes        |
|  + Appearance       |
|  + Input            |
|  + Paste/Send       |
|  + Scripting        |
- EQ Plugin           |
|  + General          |
|  + Appearance       |
|  + Input            |
|  + Paste/Send       |
|  + Scripting        |
+ Spell Queue Plugin  |
------------------------------------------------------

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 #19 on Wed 22 May 2002 06:13 AM (UTC)

Amended on Wed 22 May 2002 07:05 AM (UTC) by Magnum

Message
In that example, you operate on the different values that belong to the different VM's by accessing the appropriate "tree" branch. Another way to do it might be to have a frame across the top of the settings dialog box with a pulldown box, where you select the VM you would like to operate with, and click one button to add a new VM, or another button to remove a VM. (A VM really being an "include" directive to use an additional XML file). I like this latter method better, since it works better with the icons (which would take you to the alias screen, and whatever was last set in the pulldown would still be active).

In either case, for the amateur, most of the time they would likely have the main XML file selected. If they want to add a plugin, it's just a few clicks. No fuss!
Quote:

Time - if you said to me "I just want the new version with the bug fixes and the include files, and I'll wear the possible overwriting of values" I could have it out in 30 minutes.
But if you want all the changes to support virtual machines - multiple script environments, multiple script files, more complex GUI configuration interface, and so on - then I might have to say "that'll be another month away".
Then I ask myself "will the time taken to make all those changes be repaid in registrations"? I mean, are there (say) 500 people who have not yet registered, who will if MUSHclient offers virtual machines. I doubt it somehow.

That's a hard point to argue, but I'll try. :)

"-Multiple script envirmonments, multiple script files". You already do this, in a sense. I can have 2 worlds open, each with their own complete environments. I don't know - how hard would it be to code starting a new environment, and loading the same XML world file, but ignoring anything in the "Interactive" category I mention earlier in the thread? Also, modifying your code so that instead of sending input/output to just one environment, you send it to all environments tied to this world?

You've shown that you are already capable of ignoring some settings from an XML file. (See the very start of this thread). The second point is a little more complex. I imagine it's a matter of making multiple calls to multiple environments, instead of one call to one environment. Hmm... Depending on your code, could be very easy, or very hard.
? -current- ?
Send "latest output line to trigger matching routine"
? -multiple VM's- ?
Send "latest output line to trigger matching routine - main VM"
Send "latest output line to trigger matching routine - plugin 1 VM"
? -- ?
Would be nice if it were that easy. :)

Anyway, to get more directly to your point, I can only offer this:

If your client program is the (or one of only a few) clients that allows very user friendly plugin support, it may serve as more of a "requirement" to mud users.

Suppose, for example, I refined by EQ script even more (to handle a new EQ feature on the mud), refined and made public my SpellQueue, and made other plugins useful for a particular mud, I might actually get to a point where I pull people over to using your client because it's just so damn easy to install plugins, and them users just got to have my nifty plugins!

The nice thing is, you could use multiple plugins no fuss, no worries about which language they were programmed in.

Then it's a matter of fostering a community of people capable and willing to write plugins. Who knows? Plugins could be so popular they are the leading reason people elect to use your client! (Muds with Admin supported plugins on their webpage would be amazing).

Now granted, ShadowFyr and I are two of the most vocal users here, and if it's just us two, you probably won't see any dramatic sales (if any) in the very near future. This is more an issue of potential, I guess.

(I think I've already gotten at least 10 people from AOD to use Mushclient - wonder if any have registered?) ...and they don't even use my plugin for that mud. :)

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 #20 on Wed 22 May 2002 06:52 AM (UTC)
Message
One more rebuttal, and I don't mean to be rude. You DO rock. :)

Seems to me, the compromise that you propose seems somewhat complicated itself. In order for an end-user to use multiple XML files, they have to be weary of ANY setting collisions. If there are collisions, it may result in expectations not being met. ("I typed this alias and nothing happened!", "I programmed this trigger in my plugin XML, but it won't execute!")
Quote:

Any value read from an include file (but not from the "main" world file) is marked as "an included value" - in a separate internal table.

Any way to view these via interface? If you have multiple internal tables, isn't that just one step shy of what I proposed? (Each internal table is essentially the "environment"/"Virtual machine", isn't it?). ...or did you just mean only certain values (I.E: NOT triggers, aliases, variables)?
Quote:

You will have provision (eg. a button) to "revert to defaults" which will have the effect of changing every attribute back to the value from the include file.
Thus, if you changed the input_background_colour to green, and wanted to put it back to the default (included) value, clicking that button would do it. If you wanted to go back to the MUSHclient defaults, you would simply throw away the reference to the include file (ie. un-include it).

Sounds dangerous! All of the settings revert? ("Damnit, all the variables configured in my plugin XML file just reverted back to their 'empty'/ititialized defaults!") Err, where were those variables stored anyway? The main XML file, or the Plugin? ("Damnit, all those triggers I disabled just got re-enabled!").

Heh... Ok, I've made my points, I think. If you are firm in your position, Nick, I won't keep pushing my proposal. Of course, I'll adapt to whichever method you choose, as will the rest of us. :)

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

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

Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #21 on Wed 22 May 2002 07:05 AM (UTC)
Message
Quote:

You'll pardon me for countering your points, if only for the sake of a productive conversation that serves as a history for why MUclient has evolved in the manner that it did. :)


This is a good point. Sometimes it is interesting to know why something was not done, whereas release notes usually describe what was done.

While you were writing that I was getting things a bit more organised internally (options into an internal table including default values), which hasn't really committed me yet to any particular direction.

Whilst I am quite keen on your point about easy plug-ins, I don't quite see how this interacts with the VM concept.

OK, I suppose if you type "shop" and an alias in VM 1 picks it up, then that word could be echoed in a different colour - cute I suppose, although the idea of switching these VMs maybe for every alias and trigger is a bit daunting - I think you might get a speed penalty.

Without getting bogged down in whether or not we want virtual machines, or whatever, let's explore this plugin concept a bit more, and see where it takes us.

I can see the usefulness of (say) a wilderness walker plugin (snippet) being distributed as a single file. This might require:


  • Some triggers
  • Some aliases
  • Some variables
  • Some global settings (eg. scripting on), aliases enabled etc.
  • Some script routines


The new "import" function addresses all that (excepting maybe trigger/variable/alias name collisions). The only real remaining problem is incorporating scripts, maybe in different languages.

Now, making new script machines probably isn't too hard, as it does it anyway for different worlds. So, a snippet (plugin) could look like this:


<triggers>
  <trigger
   custom_colour="1"
   enabled="y"
   expand_variables="y"
   match="@target falls to the ground"
   name="target_falls"
   regexp="y"
   script="vm1:OnTargetFalls"
   sequence="100"
  >
  <send>kill @target</send>
  </trigger>
</triggers>
<script vm="vm1">

sub OnTargetFalls (a, b, c)

' blah blah

end sub

</script>


The important bits here (and they are just ideas right now) is that the trigger calls a script in vm1 (hence vm1:OnTargetFalls), and then the script tag defines the script that belongs to that vm. I use "vm" loosely, "namespace" might be just as good a term, or "script engine".

We could probably work around collisions by a simple system of registering some prefix (eg. "magnum_") so that each scripter has to use a different prefix, and it is their job to be internally consistent. Thus you might have variables "magnum_hp", triggers "magnum_trigger_1" and so on.

It wouldn't have to be that long-winded, every forum user could, on request, be assigned a 4 character code, for example.

- Nick Gammon

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

Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #22 on Wed 22 May 2002 07:09 AM (UTC)
Message
Quote:

Any way to view these via interface? If you have multiple internal tables, isn't that just one step shy of what I proposed? (Each internal table is essentially the "environment"/"Virtual machine", isn't it?). ...or did you just mean only certain values (I.E: NOT triggers, aliases, variables)?


That would be simple enough. Right now you can view the internal table of configuration names.

Anyway, what I meant was one-off attributes (eg. text colour), not multiple things like triggers. So, "revert to default" would basically restore default colours, trigger enable flag, stuff like that. Things that only occur once.

Even then, it could be limited to the configuration screen you are on, with a bit more work. Eg. you are viewing the Output configuration screen, and want to go back to defaults, so you hit a small button that simply restores what you see right there, to their default values.

- Nick Gammon

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

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #23 on Wed 22 May 2002 08:31 AM (UTC)
Message
Interesting. I'm still trying to get a handle on what this XML stuff is capable of, so perhaps there are aspects of my proposal that were premature.

Quote:

Whilst I am quite keen on your point about easy plug-ins, I don't quite see how this interacts with the VM concept.

Now, making new script machines probably isn't too hard, as it does it anyway for different worlds.

This is really what got me started on the idea. It seemed that a previous limitation was that you could not run multiple scripts because there was only one "script machine" per world. As you say, you could do it for different worlds though, so I concluded: "Let one world have multiple script machines running!". I am under the assumption (though I have never tried), that I could open one world that uses VBScript, and another that uses JScript, hence my theory that if one world could use multiple script machines, they could be in different languages. :)

BTW, I don't really like the term machine either... I just used it for lack of any other term I could think if.

Anyway, I thought: If you're gonna make a seperate namespace for scripting, may as well do it for triggers\aliases\timers\variables. Everything stretched from there. I actually figured that part would be relatively easy for you to program, it simply required sending the input/output to multiple "MUclient engines" instead of just one.

Another reason for including plugin triggers\aliases\timers\variables (Man, need an acronym for that - LOL) is that I assumed there would be some confusion as to which script engine a particular trigger should use. Wrapping them together in the same virtual space seemed the logical conclusion. (I do note your solution now).

Finally, it seemed to me that confining each plugin's settings in it's own space would serve to actually improve the collisions situation, by virtually eliminating the issue, save that one example you poked me with. :)

...and all of this could be accomplished relatively easily by just modifying your input/output interface with your internal Mushclient engine so that the input/output gets sent to multiple places, instead of just one.
Quote:

OK, I suppose if you type "shop" and an alias in VM 1 picks it up, then that word could be echoed in a different colour - cute I suppose, although the idea of switching these VMs maybe for every alias and trigger is a bit daunting - I think you might get a speed penalty.

In my mind, a "VM" will usually be a bundle of aliases and triggers. Maybe this is a bit simplistic, but I thought: Call the trigger matching routine that checks 120 triggers once, or call it twice, first checking 100 triggers, then checking 20 triggers - Is there much difference?
Quote:

Without getting bogged down in whether or not we want virtual machines, or whatever, let's explore this plugin concept a bit more, and see where it takes us.

Yes, Sorry, I know I didn't really do that so far in this message.

How about plugin removal?

Where are MUSHclient variables (created by the script) stored?
If the script uses World.AddAlias or AddTrigger or AddTimer, where are those stored?

Will there be an easy way to "cleanup" all that was added by an included XML file and it's script, should you want it removed? (I ask because I expect my method would store all of that in the plugin XML file, so remove the file, and everything related is gone). (And as a potential plugin programmer, I want to know if I would have to write cleanup routines).

Ok, all of that aside, your proposal does seem workable to me now that I understand it better. Your Prefix idea seems like something a smart programmer should do, though I can't say I'm thrilled at the idea of relying on the programmer to do so. Even myself, I sort of complied, by making all variables in my EQ script start with "EQ", but that's still too generic. (Just checked, I missed using a prefix on one, Doh!)

I'm not sure which proposal was the "harder" way to do things, but since it's your baby, I'll trust that you know best. :)

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,792 posts)  Bio
Date Reply #24 on Wed 22 May 2002 06:40 PM (UTC)

Amended on Wed 22 May 2002 06:42 PM (UTC) by Shadowfyr

Message
Hmm.. Well first to Magnum..

Since multiple VMs can be setup for different script and even different languages there is no real reason to create extra overhead by using multiple VMs for each include. This would probably eat more time than the text positioning stuff every one keep arguing about and really isn't that necessary.

To Gammons concerns...

Last includes colors override everyone elses... Bad idea. Even if a way is provided when adding a new one to change it's position relative to others in the load process I really don't wan't someone elses file overriding my own world file settings. My suggestion of have to directly import the xml (or maybe even just an option of 'import color tables') would be far better, since it won't touch my own settings unless I specifically ask it to do so.

Collisions.. Simple, don't assign users a unique ID, generate one when the xml is loaded and propagate it through all the connected bits. So all triggers, aliases, etc. would get XXXX_ tagged onto that at world load and any script routines loaded with it would also be tagged the same way, both in the 'loaded' script and the triggers, aliases, etc. that reference them. That way no actually change needs to be made to anyones scripts or triggers, etc. The client just tags the first included bits with 0001_, the second with 0002_, etc. The added time to do this automatically is negligable unless some fool keeps hitting the 'reload' script button or something. Hmm.. Which brings up the fact that you would need to keep track of 'where' each one was loaded from and the number tacked onto it so if a reload is requested they get retagged properly. It seems to me that this is definitely a better way to do things than making everyone attached their own ID to them.

While this doesn't fix alias problems like you 'shop' example, such collisions are likely to happen no matter how you deal with them. It is better to simply warn the user that duplicates of that sort exist, that they could pose a problem and let them handle the adjustments. Otherwise you run the risk of overriding one they need with one that doesn't do anything they find useful. Knowing that the collision exists lets them delete or edit them as needed, but simply loading both and not warning them or overiding one with the other is a bad idea.

Default colors.. I cannot imagine one single instance when I will ever need to 'reset to default' colors or any other settings. Doing so is very likely with triggers and other things to have unexpected and unwanted results and may have the same with the colors (though having that option 'may' be useful as long as you can also 'undo' it if you hit it by accident). I may need to reset a custom color in a script back to that set in my world file or the defaults that MUSHClient uses, but never the entire table. I can't frankly imagine anyone else wanting to either. What is needed is to have a base 'default' color settings and a world file color setting and the ability to do stuff like NoteColorRGB Default, NoteColorRGB World or NoteColorRGB 'Your color', from inside the script where they are most useful. Currently have have to either hunt the value down or guess, neither of which is very helpful.
Top

Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #25 on Wed 22 May 2002 10:21 PM (UTC)
Message
Quote:

Last includes colors override everyone elses... Bad idea. Even if a way is provided when adding a new one to change it's position relative to others in the load process I really don't wan't someone elses file overriding my own world file settings.


My proposal was that you would have:


  • General includes (eg. default triggers, settings)
  • Plugins or whatever you call them
  • The main <world .... > </world> attributes


Since the main attributes would come last, by definition, then it would be impossible for a plugin to change (say) the IP address of the world.

I suppose what might happen is that a plugin changes (say) the world.note colour, which you had set up in your earlier include file. One simple solution, and probably the obvious one, is to have your include files last in the list (ie. after the plugins). I think I would have the ability to change the include list order, which in any case you could do by editing the world file.

Quote:

How about plugin removal?

Where are MUSHclient variables (created by the script) stored?
If the script uses World.AddAlias or AddTrigger or AddTimer, where are those stored?


All of those things (triggers, aliases, timers, variables or TATV for short, or should that be VATT?) are stored in "maps" (hash-table lookups) as part of the main world document.

As for plugin removal, read on.




What I propose now as a tentative plan, which I will attempt to do, is allow some sort of plugin concept in include files. This will:


  • Establish a namespace, to avoid collisions for VATT names, although not necessarily their function (eg. you might still have two "shop" aliases).
  • Establish a virtual machine, or scripting engine space, into which the scripts could be placed


The idea is it should be simple to use, so this is what I imagine it to be ...



<plugin name="Magnum's wilderness walker"
        language="vbscript"
        author="Magnum"
>
<description>
This lets you walk through the wilderness blah blah ...
</description>
<use>
To use it type BLAH followed by BLAH
</use>
</plugin>

<!-- This has established the start of a plugin - one per include file I would suggest -->

<triggers>
  <trigger
   custom_colour="1"
   enabled="y"
   expand_variables="y"
   match="@target falls to the ground"
   name="target_falls"
   regexp="y"
   script="OnTargetFalls"
   sequence="100"
  >
  <send>kill @target</send>
  </trigger>
</triggers>

<aliases>
  <alias
   match="gems"
   enabled="y"
   ignore_case="y"
   name="gems"
  >
  <send>insert gems into statue</send>
  </alias>
</aliases>

<script>
<![CDATA[
'
' Using CDATA means you don't have to worry about > signs 
'  in the script.
'

sub OnTargetFalls (a, b, c)
 world.note world.getvariable ("blah")
end sub

]]> 
</script>


OK, what this will do is:


  • Generate a namespace prefix (eg. P1 for plugin 1) automatically.
  • Any labels found in the plugin (and perhaps labels are mandatory?) will be prefixed by the namespace prefix. So we would have:

    • Trigger: P1:OnTargetFalls
    • Alias: P1:gems
    • Variable: P1:blah

    Since the character ":" can't be used as a normal label, you can't "fudge" a forged namespace.
  • Any calls (in scripts) to AddTrigger, GetTriggerInfo, SetVariable etc. will automatically have the namespace prepended, so you will avoid name collisions, without really having to work at it.
  • The contents of each <script> directive will be concatenated to make a "total script string", which will be passed to the (appropriate) script engine for parsing (the script engine specified in the <plugin> tag).
  • Perhaps - if the script won't parse, the entire plugin is discarded. That might be for the best. Otherwise you might have "dangling" triggers and aliases that should do something, but don't.
  • The reason for concatenating scripts snippets is so each (say) trigger can have its own script handler under it, which seems to me to be a neater way of developing the plugin.
  • With a bit of work, if there is a parse error, MUSHclient could work out which line of which include file actually caused the error (effectively un-concatenating the script snippets).


You would still potentially have behaviour collisions (eg. two triggers that match on the same text) however that should be pretty good. With the stuff like author, description, etc. in the <plugin> tag, you could have a simple "installed plugins" window that lists plugins and what they do.

Uninstallation would simply involve removing each VATT that matches the plugin namespace, and discarding the script.

- Nick Gammon

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

Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #26 on Wed 22 May 2002 11:05 PM (UTC)
Message
Ok. Looks good..

I would still like some way to tell the client within a script to reset a color to the one in the world file or even the default though, currently you can set the color in a script, but not return it to the previous state without knowing the correct color definition. Of course since it uses the custom color table right now that is not much of a problem, but when/if triggers and stuff has a 'color picker' option added this will become a real problem, since unless you leave it as one of the existing custom colors you won't have any obvious default color to return to. For mine I had it set to use the 'normal' color and in that case you still can't tell it to reset to the original color without knowing the specific value to use.
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #27 on Wed 22 May 2002 11:39 PM (UTC)

Amended on Wed 22 May 2002 11:53 PM (UTC) by Magnum

Message
Again, interesting.
Quote:

Establish a namespace, to avoid collisions for VATT names, although not necessarily their function (eg. you might still have two "shop" aliases).
Establish a virtual machine, or scripting engine space, into which the scripts could be placed

Why not make life simpler for yourself, and just store the Plugin's VATT stuff back into the Plugin XML file? (Instead of the main world XML file).

Do that, and you've pretty much met the proposal I had offered.

I don't know what kind of overhead you have in writing this new code. In a way, Establishing these new namespaces is very similar to establishing a new namespace for a different connection/world.

As a final step towards my proposal, you clone the "core" settings I mentioned earlier (from the main/core XML file), and throw them into this new namespace as well, and you've got the thing I was calling a "virtual machine" which is just the label I came up with for "namespace".

So far, you have a private namespace for the script engine, and a private namespace for the VATTs. Why bother assigning them names? Just link the two namespaces together, and you're set. I.E: The triggers from the Plugin VATTs aren't going to conflict with the core VATTs. Have them ONLY use the "linked" script space. You don't need to worry about collisions, since both the VATT information and it's linked Script namespace are independant from the core/world namespace [and any other plugin]. (What's going to collide?) Saves you the hassle of rewriting all your functions to provide prefix labels!

The reason for throwing in the other "core" settings, is that it simplifies things for you, and just helps make the plugin namespace more robust. Each plugin\XML file kind of runs like it's own world file, independant of the others. You would not need to modify any of your functions. (Only the way a namespace is initialized, and interacted with).

I'm sorry, I didn't mean to turn this into a rant to do things my way. It just seems like you are kind of heading down the path anyway, and I guess I can't help but see my full proposal as easier. I've got to remind myself that there are things I don't know, and what I guess "might" be very easy for you, could in fact be somewhat difficult.

The one downside to my proposal, is that if a Plugin/Include is kind of like a whole new world (except sharing the input/output of a root world), then that Plugin's XML file will be altered as it is used... In such a case, you would not want to share your own [modified] plugin file with someone else. (You should instead share a "virgin" plugin).

The other downside, is that you would not have interaction between the namespaces unless you programmed a special interface... but you kind of already have that since it is already possible to interact with another world environment. (Isn't it)?

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

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

Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #28 on Wed 22 May 2002 11:39 PM (UTC)
Message
Can you clarify:


  • Which colour you are referring to? An ANSI colour? A custom colour? World.note colour?
  • What would you reset it to? The MUSHclient default? The colour found in the latest include file? The colour directly after the world was loaded?

- Nick Gammon

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

Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #29 on Thu 23 May 2002 12:41 AM (UTC)

Amended on Thu 23 May 2002 12:42 AM (UTC) by Nick Gammon

Message
I appreciate that you are probably trying to make things easier for me, but the fact is that multiple namespaces won't really work like that. The problem is that the scripting interface, that everyone is accustomed to, has a single point of interaction with MUSHclient, namely the "world" object, which is a COM object which internally represents the world document, of which there is only one.

No matter how much you try to move into different engines, or namespaces, there will remain some things of which there can only be one, eg. the output buffer, which is accessed by GetLineInfo.

Here, for instance, is the implementation of world.getvariable, which you see is attached to the world document ...


VARIANT CMUSHclientDoc::GetVariable(LPCTSTR VariableName) 
{
CString strVariableName = VariableName;
CVariable * variable_item;
VARIANT vaResult;

  VariantInit(&vaResult);

  vaResult.vt = VT_NULL;

  // return if bad name, if so return NULL
  if (CheckObjectName (strVariableName))
    return vaResult;

  vaResult.vt = VT_EMPTY;

  // see if variable exists, if not return EMPTY
  if (!m_VariableMap.Lookup (strVariableName, variable_item))
	  return vaResult;

  SetUpVariantString (vaResult, variable_item->strContents);

  return vaResult;

}


Since I would need to keep a world document, to make namespaces work in the way you suggest would mean moving things like getvariable to a different com object (the namespace, or engine, object), thus requiring a lot of script changes.

However my proposed change would merely require that, if a trigger which is part of a plugin calls a script, it sets up a global variable (for the world) which is the current namespace name, then with a one-line addition to getvariable, it will access the correct variable, something like this:


strFullName = strNamespace + strVariableName;


In this case "strNamespace" might be "P1:" or might simply be empty for non-plugins.

- 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.


126,042 views.

This is page 2, subject is 4 pages long:  [Previous page]  1  2 3  4  [Next page]

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.