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.):
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.
sub setcolor(name, color)
...
setvariable "Pcolor_xxxx", "color"
...
end subHowever 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.