What do you think of changing CallPlugin so that passing a blank plugin ID string directs the call to the world instead of a plugin? I don't particularly need this, but it would be useful along a similar vein to using hotspots outside a plugin. Are there any issues to this idea that would make it unworkable or unsafe?
CallPlugin
Posted by Twisol on Fri 08 Jan 2010 07:10 PM — 6 posts, 14,803 views.
Well, I am reluctant to add features, which may be quite a bit of work, and that no-one actually wants or needs.
I was mostly thinking that it would, firstly, be a decent alternative to the current hack of using the scripting prefix and embedded code to call to the world file. I also had the recent idea of using PPI to register a custon OnPluginATCP method, which my ATCP plugin could call to on any plugin that's requested access to the information when ATCP data was receceived. It would circumvent the annoyances involved in using OnPluginBroadcast to pass complex information between plugin, and by allowing CallPlugin to call to the world file, you could easily receive ATCP data without any plugin fluff. (If you're just experimenting, or you want a quick and dirty thing going, the world file is often easier to work with than a plugin.)
I'm testing a patch for this right now, if it works I'll send you the patch and you can do what you like with it. :)
EDIT: Sent!
EDIT: Sent!
I'm not sure I want to encourage the blurring of boundaries between plugins and the main script file.
If you really want to test stuff outside a plugin, you could simulate CallPlugin yourself with an alias and a bit of scripting. This could be useful in a development environment. In a release environment, having stuff like that available is going to encourage plugin writers to start insisting on certain scripts/languages etc. being set up in the main world file, something I tried to avoid.
If you really want to test stuff outside a plugin, you could simulate CallPlugin yourself with an alias and a bit of scripting. This could be useful in a development environment. In a release environment, having stuff like that available is going to encourage plugin writers to start insisting on certain scripts/languages etc. being set up in the main world file, something I tried to avoid.
Actually, I thought it would help keep things separate. All CallPlugin() requires is a method name and a string parameter. To simulate it, you do have to enforce a certain language, or more work to support any. (That was the point of PPI, after all: allow diverse plugins and languages to speak to eachother transparently)
If you don't want to use it, that's fine. I thought it would be helpful in creating asynchronous callbacks though, i.e. you pass a plugin the name of a callback, it does stuff and returns, and at some later point it calls that method back.
EDIT: Although I do have to ask, what do you see the script file being used for? Me, I always saw it as a sort of plugin in its own right, together with the world aliases, triggers, timers, etc. It's clearly not meant to be reused and distributed, that's what plugins are for, but I always believed that if a user wanted to do something in the script file, there shouldn't be any reason that a plugin can yet the script file can't. Just my two cents.
If you don't want to use it, that's fine. I thought it would be helpful in creating asynchronous callbacks though, i.e. you pass a plugin the name of a callback, it does stuff and returns, and at some later point it calls that method back.
EDIT: Although I do have to ask, what do you see the script file being used for? Me, I always saw it as a sort of plugin in its own right, together with the world aliases, triggers, timers, etc. It's clearly not meant to be reused and distributed, that's what plugins are for, but I always believed that if a user wanted to do something in the script file, there shouldn't be any reason that a plugin can yet the script file can't. Just my two cents.