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.
 Entire forum ➜ MUSHclient ➜ Bug reports ➜ OnPluginBroadcast (w/ workaround)
OnPluginBroadcast (w/ workaround)

Posting of new messages is disabled at present.

Refresh page

Posted by WillFa   USA  (525 posts)  Bio
Date Tue 12 Aug 2008 06:58 AM (UTC)
Message
OnPluginBroadcast is not called in the main scriptfile.

I've seen in other places that you recommend having the script file poll the plugin and use GetPluginVariable, how ever notifying the main script of a change in your plugin is not possible. Setting a timer to poll variables is archaic, since the mechanism exists for one plugin to notify another, why not the "plugin" that's most easily modifiable, debuggable (since you have access to the Immediate... or "/print()") , and the plugin wizard pulls settings from?

It makes writing/debugging new plugins that interact with another difficult that this functionality is not present.
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #1 on Tue 12 Aug 2008 07:23 AM (UTC)
Message
That is how it was designed. To quote the page on plugin callbacks: "The following subroutines/functions will be called in your plugin if they are present."

My impression is that this is to move script authors towards plugins once they want to use more advanced functionality. This way, the main script space remains free for the user to use in ways he/she sees fit to use it, rather than the script author who may end up creating conflicts with the stuff a user already has installed.

That's my view, though... I don't think Nick Gammon actually spoke on the subject before, or I missed that.
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #2 on Tue 12 Aug 2008 07:50 AM (UTC)
Message
I understand this. My point is writing the plugin in the first place is a pain since debugging it is a lot more cumbersome than debugging the main script file. As for interfering with the user's script, supporting the callback function "OnPluginBroadcast" isn't really going to be there in the first place. In addition, it strongly encourages checking plugin ID and not just message# if you have plugins from multiple sources.

If the main script supports it: you use the main script file to write and debug it. You use the plugin wizard to move it to its own xml. You have modular code.

If you distribute this plugin then it allows a user who doesn't want to write their own plugins to easily extend your plugin without jumping through the hassles of rewriting, saving, ctrl+shift+p, reinstall, debug it in absentia (since you don't have immediate access to the plugin), resave, reinstall, et cetera.

I guess I'm just repeating myself.


Right now, I find myself leaving a lot of static code in the main file since adding a new feature to one facet of it is hard to write and debug.


All my work so far with miniwindows has been to write it in a lua file that I or someone else can "require" since the interaction between plugin and far more mutable script is only one way.

It was deemed having GetPluginVariable(""...) interact with the main world script was important enough to implement. I would think then that Plugin "" should recieve broadcasts too.
Top
Posted by Cage_fire_2000   USA  (119 posts)  Bio
Date Reply #3 on Wed 13 Aug 2008 04:10 AM (UTC)
Message
Yeah, I know, I've often thought it would make it easier to write plugins if the callbacks were called in the main script file as well as if they were another plugin. I mean if the callbacks from other plugins don't usually interfere with each other, why would they interfere in the main script?
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #4 on Wed 13 Aug 2008 04:34 AM (UTC)
Message
Quote:

OnPluginBroadcast is not called in the main scriptfile.


This isn't a bug. It is by design. All the OnPluginxxxxx functions are specifically targetted at being in plugins.

Quote:

If the main script supports it: you use the main script file to write and debug it. You use the plugin wizard to move it to its own xml. You have modular code.


It wouldn't be a heap of trouble to write a tiny plugin that intercepts OnPluginBroadcast - then dummies up an alias that your main script interacts with. This could be used for testing, and then when you are ready to move it all into a plugin just delete that alias.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #5 on Wed 13 Aug 2008 06:38 AM (UTC)

Amended on Wed 13 Aug 2008 07:17 AM (UTC) by WillFa

Message
Execute always processes in the World's environment. Thanks for the idea Nick!

This basically simulates calling OnPluginBroadcast from the command line. You need a scripting prefix defined for it to work; but, if you need this plugin, I expect you would already.


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<!-- Saved on Wednesday, August 13, 2008, 1:52 AM -->
<!-- MuClient version 4.34 -->

<!-- Plugin "BroadCastForwarder" generated by Plugin Wizard -->

<muclient>
<plugin
   name="BroadcastForwarder"
   id="5d606ce28f87afdedec09043"
   language="Lua"
   save_state="n"
   date_written="2008-08-13 01:49:50"
   requires="4.0"
   version="1.0"
   >

</plugin>


<!--  Get our standard constants -->

<include name="constants.lua"/>

<!--  Script  -->


<script>
<![CDATA[
function OnPluginBroadcast (msg, id, name, text)
  if GetInfo(28) == "Lua" then
	local scriptPrefix = GetInfo(36)  -- script prefix char
	local cmd = scriptPrefix .. "OnPluginBroadcast (" .. msg .. ", [[" .. id .. "]], [[" .. name .. "]], [[" .. text .. "]])"
    Execute(cmd)
  end
end
]]>
</script>


</muclient>
Top
Posted by Cage_fire_2000   USA  (119 posts)  Bio
Date Reply #6 on Wed 13 Aug 2008 04:36 PM (UTC)
Message
Hmm, I never thought of that, that's pretty neat, hmm, would that crash or generate an error message if OnPluginBroadcast isn't defined in the main script, or would it just ignore it? If it would generate an error or crash, does PluginSupports() work on the main script file? If so, one might be able to write a general plugin that could forward more of the callbacks, although that wouldn't work for callbacks that return stuff, like OnPluginCommand() or OnPluginPacketReceived(). Any suggestions on how one might debug those in the main script?
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #7 on Wed 13 Aug 2008 05:19 PM (UTC)
Message
I'm kind of torn, actually.

I don't like using the script prefix since people might turn it off. I know I turn it off because it interferes with aliases I'm used to, and I can't find a proper prefix - nor do I need the function.

Second, it is dependant on the language of the main world. Which means you need to write various versions for different scripting languages.

Third, you need to add in special tests to see if the function is defined. This is easy to do (Lua: if func ~= nil then) but adds to the bloat because you need to work around it per language.


I feel using an alias with a magic unwieldy match is a better choice, something like CallbacksPlugin:broadcast(). It has its own advantages and disadvantages, most prominent in my mind are the following:

1) The aliases need to be defined in the main world, or they'll error. Although you can work around this by also defining them in your own plugin with the keep_evaluating="y" flag and just not letting them do shit. So this point doesn't actually matter.

2) Parameters other than strings/ints will require special reparsing. Can't avoid this either way though, I believe... are there any callbacks that pass tables/arrays/lists as an argument, anyhow?

3) It requires the user to make special triggers to use as callbacks, rather than a scriptfunction. In my opinion, this could be a problem, although it doesn't have to be. You can just supply a template_triggers.xml file, which can import empty triggers with the proper signatures through the File>Import() function. It is a one-time action, so it could go with the installation process. It would be nice if it could be initialized from the plugin during first installation, but it isn't possible to affect the main script from within te plugin.

I think that's about it... but maybe I am overlooking some stuff still. My preference goes with the second one so far, though. It forces less settings upon the user, which is a good thing.
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #8 on Wed 13 Aug 2008 09:59 PM (UTC)
Message
The Script Prefix can be more than one character. If you don't care about using it, just set it to "#^%$" and forget about it. :) (Mine's currently set to `` since / interferes with some of my aliases)

About writing different versions for different languages... It works for me! If it doesn't work for you, you have the source right there. ;) Since the only reason you'd really need it is during the plugin authoring process, 3 lines of code is not hard to adapt. Especially since you only need to change the preformatted string identifier ([[ foo ]] for Lua, """ foo """ (or r"foo") for python, etc) that's parsed into the 'cmd' variable.


It's a workaround, not a solution. It's not intended to be distributed with your plugin, since your plugin inherantly supports the OnPlugin* functions.


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.

23,811 views.

Posting of new messages is disabled at present.

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.

Home