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
➜ Accessings Aliases, Triggers, Variables...in Plugins
|
Accessings Aliases, Triggers, Variables...in Plugins
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Vaejor
(120 posts) Bio
|
| Date
| Sun 22 Sep 2002 06:59 AM (UTC) |
| Message
| Okay Nick, it's time for me to cause another headache. ;)
How possible would it be to allow the GUI screens that access the Aliases, Triggers, Variables, Timers, etc(?) for the primary MushClient data file to also pull data from currently loaded Plugin files.
Also allow editting, automatic(?) saving of the plugin(with the plugin wizard, I figure this should be possible to rewrite the xml file, although extra formatting may be lost if you do it this way) after any changes are made.
I figure a dropdown box that would list the current MushClient file you have loaded and each plugin you have loaded, although it would always default to the primary file when the GUI is initially opened(although if you move around between screens without closing it, it should stay on the current selection, which makes somewhat easier to jump between sections for plugins if you really need to).
In addition to this, possibly another option on the header of the file for a 'readonly' attribute that basically would not allow the name to show up for it to be altered. This would allow for less casual changing of data for distributed files if the author wanted to implement it.
(Take 2 aspirins and ignore me for a week and you should be all better :} *muah*) | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Sun 22 Sep 2002 07:07 AM (UTC) |
| Message
| What you could do as a workaround is to copy the entire plugin to the clipboard, excepting the <plugin> section, and then "import" it into MUSHclient (preferably a session with no other triggers, aliases etc.)
That way they can be accessed from the GUI interface, and then either remake the plugin, or copy and paste the relevant parts (eg. all triggers) back into the plugin file.
My thought was that you would debug a plugin before making it a plugin, so to speak, ie. using the GUI interface.
Any last-minute tweaking of flags, triggers etc. isn't that tedious in the plugin text file.
Or in a smaller case, say you want to fix up one trigger, copy its definition from the plugin file, paste it into the trigger dialog, edit it, and copy and paste it back. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Magnum
Canada (580 posts) Bio
|
| Date
| Reply #2 on Sun 22 Sep 2002 04:27 PM (UTC) |
| Message
| Heh. This was something I mentioned way back, when there was heavy disussion on how to evolve MUSHclient to use plugins. :)
I had the same idea... A pulldown box at the top of the GUI settings window, that would let you select witch 'space' your were working with.
It would probably require some re-organization of the Configuration window... But once it's done, MUSHclient would use the same engine for both root/core data and plugin data.
I suspect Nick may want to leave this as something for next spring-ish, when perhaps he will consider working on the next major-ish update. :) |
Get my plugins here: http://www.magnumsworld.com/muds/
Constantly proving I don't know what I am doing...
Magnum. | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #3 on Sun 22 Sep 2002 11:25 PM (UTC) |
| Message
| I would have to agree here. It is not reasonable to assume that a plugin will be bug free when created or that it is even a good idea to develope it inside the existing world first. I have two that fall into this category.
The first is my druid potion plugin. I have made changes to it wuite a few times since its first release and in at least one case, I had to do a major rewite. There was no way to effectively drop the whole thing back into the main world file and script, then turn around and re-export it back into the script. Doing so would have been harder than continually reinstalling is was.
The second was my little spell status tracker. The problem here was that the same set of triggers are used by it and some of the core functions of my main script. To avoid making debugging 10 times harder I chose to duplicate the triggers and build a completely new plugin to house the needed code. It would have nearly doubled the size of my main script to have it in there and made fixing either one overly complex.
In both cases I missed a few things that would have helped testing a great deal.
1. There was no way to check the world variables used by the plugins, or even if they where created.
2. If I thought I had fixed something and closed the editor, then found something else was wrong, I had to reopen the editor, stumble through directories to get to the file, fix the problem, and finally reinstall it all over again.
3. If I forgot a command to call the plugin, there was no list of aliases, triggers or anything else I could check to see what I needed.
While plugins work really nicely, once created they work too much like a black box imho. You can't really look at any of what makes it tick, edit it to fix bugs or check the aliases to remind yourself of the correct aliases. All of it gets hidden like the plugin was some sort of runtime library and I have to say that this sometimes creates more drawbacks than benefits.
This is also compounded even more by those cases where the core function the the plugin is dependent on some of those OnPlugin... subs that the normal script can't access. In such a case, you can't 'build' all the interfaces and test the complete set of subs in the GUI. It simply won't work. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #4 on Mon 23 Sep 2002 02:24 AM (UTC) |
| Message
|
Quote:
1. There was no way to check the world variables used by the plugins, or even if they where created.
2. If I thought I had fixed something and closed the editor, then found something else was wrong, I had to reopen the editor, stumble through directories to get to the file, fix the problem, and finally reinstall it all over again.
3. If I forgot a command to call the plugin, there was no list of aliases, triggers or anything else I could check to see what I needed.
1. Try: /world.debug "plugins"
2. Press Shift+Ctrl+P to open the plugins window. Select the plugin. Click Edit.
3. /world.debug "plugins"
I didn't want to make a GUI interface to change plugin contents because plugins are read-only files (include files) that may well be shared by multiple worlds. What if you change a plugin that is used by more than one world? |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #5 on Mon 23 Sep 2002 02:30 AM (UTC) |
| Message
|
Quote:
There was no way to effectively drop the whole thing back into the main world file and script, then turn around and re-export it back into the script. Doing so would have been harder than continually reinstalling is was.
It's not that hard.
Edit the plugin, as described above. Select all. Copy. Go to the File menu -> Import -> Clipboard.
All the GUI things are now imported back into the world file. You can now play with them, and then either copy and paste them back into the plugin file, or make a new plugin.
As for the script, just copy between <script> and </script> into your script file. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #6 on Mon 23 Sep 2002 03:59 AM (UTC) |
| Message
| >1. Try: /world.debug "plugins"
>2. Press Shift+Ctrl+P to open the plugins window. Select the plugin. Click Edit.
>3. /world.debug "plugins"
Hmm. Ok.. Will try to remember that. As to the second message about copying the stuff back in.. As I said, in most cases I put stuff in plugins because they would either interfere with code in the main script or use things that are not supported in the main world, such and the OnPlugin... stuff, so it is not that terribly helpful. lol However the rest is helpful. But maybe a new icon added to the configuration bar for plugins would be helpful. ;) | | 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.
20,806 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top