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
➜ Extension to CallPlugin
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Shadowfyr
USA (1,792 posts) Bio
|
| Date
| Tue 13 Aug 2002 08:22 PM (UTC) Amended on Tue 13 Aug 2002 08:25 PM (UTC) by Shadowfyr
|
| Message
| I recently thought about puting out a druid potion plugin companion, that would let you set the color using one of the 142 HTML names or the 665 available to unix libplot. However I ran into a snag... I also wanted to add some other things to it with the same problem. :p The routine for setting colors does this (roughly, the real code checks for correct values, etc.):
sub setcolor(name, color)
...
setvariable "Pcolor_xxxx", "color"
...
end sub
However this would mean releasing a new version of the plugin to make it work, since CallPlugin only allows one arguement.
Why not, since a varient type can be defined as an array, add support for the following?
long CallPlugin(BSTR PluginID, BSTR Routine, Array Argument);
This need not pass the array, but rather mushclient could 'spilt' it before making the script call, thus allowing multiple arguements. It should generate the same error as trying to call the above example with 'call setcolor(blah)' or 'call setcolor(blah, blah, blah)' and thus allow an appropriate error code.
As things stand any attempt to make efficient code or add a feature without releasing a new version of the original plugin (which in my case is silly, since the new plugin does not effect the main plugins actually function).
Oh, and another reason for the companion was to allow someone who has added similar color setting to their plugin to tell the companion the id, function name and arguements needed and thus use it to provide the same name-->color matching in for it. Not to mention just looking a color up. The only function I can support using the existing calls is the last one, which would let them look up the color, but force them to use the original plugin to set it.
I can work around the problem (I supposed) by using queue to provide the needed setting, but that doesn't help with the terrain matching part I had intended to provide, since someone who is foraging may use the up arrow to queue there next move anyway and queueing the set command would mess up normal game play. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Wed 14 Aug 2002 11:49 PM (UTC) |
| Message
| I'm not sure that all 3 scripting engines (VBscript, JScript and Perlscript) support supplying arrays as script arguments.
For now, why not just do it yourself, eg.
world.CallPlugin "80cc18937a2aca27079567f0", "SetColour", "Pcolor_xxxx, color"
Then use "split" to split the argument into its two components. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Shadowfyr
USA (1,792 posts) Bio
|
| Date
| Reply #2 on Thu 15 Aug 2002 02:45 AM (UTC) |
| Message
| Umm. Well...
1. That would require redesigning the original plugin, which I was trying to avoid. I may as well put out a new version of the plugin that includes the function.
2. Second, I intended to design it so that it could be adapted to work with anyones plugin that set a color.
The easiest way I could see to do this is to pass the world.callplugin routines an array and have 'it' check to see if the variant type was an array. If it detected on, it could then send each element in the array as a 'seperate' parameter to the sub being called. Passing the array itself does not after all really solve the problem, for the same reason as problem 1.
Since you can't define the number of parameters expected when making the call, I considered this to be the best solution. It would allow you to use normal parameters with the subs, but make it possible to call them externally with more than one of them.
As for potential problems, such as mushclient not knowing the number expected.. It should generate an error like with any other case where you pass an unexpected number to the routine. It is up to the script writer to fix any miscommunications. ;) | | 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.
8,779 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top