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