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
➜ Plugins
➜ Plugin development workflow
Plugin development workflow
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| Victorious
(89 posts) Bio
|
Date
| Fri 13 Nov 2015 04:42 PM (UTC) |
Message
| Hi,
My main plugin development workflow has always made heavy usage of the gui; adding triggers and aliases into the main world file, and using groups to separate triggers and aliases between plugins to manage them. However, I have so many triggers and aliases that it takes my screen reader a while to speak when i bring up the list of triggers/aliases (even when using the tree view option to control which groups are shown).
An alternative would be to export all the triggers and aliases and d script into an xml file and then edit it directly; that does sound a bit inconvenient for me as I like having the gui interface. I know that I can always add a trigger/alias on the gui and then copy and paste it into the xml though.
Would be interested to here the experiences of developers who use the xml directly as compared to the gui. | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #1 on Sat 14 Nov 2015 12:08 AM (UTC) |
Message
| One thing you can do to reduce the list of triggers, etc. is to use filters. In the trigger list dialog you can click on the "..." button and enter a script, like this:
function filter (name, trigger)
return trigger.sequence == 42
end -- filter
That would display only triggers with a sequence number of 42.
You could use that (or some other criteria) to reduce the list down to a particular couple of triggers.
Alternatively, you might make a "dummy" world which you only use for the GUI interface, to add (or modify) triggers and aliases. By doing them in a small dummy world you don't have to have listed all the triggers you aren't interested in right now.
You can use the Copy/Paste buttons to transfer to or from this world, to your plugin text.
Quote:
An alternative would be to export all the triggers and aliases and d script into an xml file and then edit it directly;
I tend to do that myself, because often an alias is quite similar to a different one, just change the word it matches on and the script it calls, and you are done! Quite quick. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Reply #2 on Sun 15 Nov 2015 03:23 PM (UTC) |
Message
| I am what you might call one of the more experienced MUSHclient script writers. I work exclusively in plugin .xml text files, and hate working through MUSHclient's GUI interface for anything other than single throwaway triggers or aliases.
1) My text editor allows me to set the terms of interaction with my plugin as a whole complex body of interconnected pieces without having to jump constantly back and forth between different interface dialogues. Everything I need is all in a single document. All of the functions I want to invoke, all of the triggers that invoke them, everything all completely searchable.
2) Related to 1, it allows complete separation of code for different projects. I don't have to worry about tripping over triggers or aliases that have nothing to do with the code project I'm working on.
3) Calling the same functions from multiple triggers or aliases without sticking those functions somewhere outside of the GUI is quite cumbersome, so working in text files makes code reuse much easier.
4) Perhaps not useful for someone using a screen reader, but as a fully sighted programmer I lean heavily on the very convenient crutch of syntax colorization in my text editor. It helps me read and write code faster without getting lost in a sea of variables, conditionals, operators, functions, constants, etc. |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Reply #3 on Tue 17 Nov 2015 02:36 PM (UTC) Amended on Tue 17 Nov 2015 02:37 PM (UTC) by Fiendish
|
Message
| Another thing that working outside of the MUSHclient GUI gives me is the ability to do side-by-side direct comparisons of one version of some code with an older or newer version of it. This is particularly helpful for finding bugs introduced at known times. |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #4 on Tue 17 Nov 2015 07:43 PM (UTC) |
Message
|
Quote:
My text editor ...
What editor do you use?
Quote:
I lean heavily on the very convenient crutch of syntax colorization in my text editor.
How does your editor manage the fact that the plugin files are Lua embedded inside XML? (when syntax colouring) |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Reply #5 on Wed 18 Nov 2015 02:30 PM (UTC) |
Message
|
Quote: What editor do you use?
Usually just gedit. ( https://en.wikipedia.org/wiki/Gedit )
Quote: How does your editor manage the fact that the plugin files are Lua embedded inside XML? (when syntax colouring)
I tell it that I want to treat them as Lua, because that's where I spend most of my time. |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #6 on Wed 18 Nov 2015 08:32 PM (UTC) |
Message
| I've been using Geany recently. I found Gedit a bit limited in some respects. For example, doing a replace-all inside a selection only.
Plus it breaks out functions and variables by scanning the source, usually quite effectively. You can put the cursor on a function call and then get it to take you to the function definition. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Victorious
(89 posts) Bio
|
Date
| Reply #7 on Sat 21 Nov 2015 06:53 PM (UTC) Amended on Sat 21 Nov 2015 07:09 PM (UTC) by Victorious
|
Message
| I've been running into those sorts of problems as well, i.e having data from multiple plugins and scripts especially increases my risk of name collisions, so I think I'll switch to an xml based workflow.
Slightly off topic, but is it possible to call code from another plugin? For example, I was thinking a plugin that extracted information from the prompt, and then have it somehow giving this data to other plugins that needed it, rather than each separate plugin duplicating the same functionality.
Edit: the options I've found are BroadcastPlugin andCallPlugin, and it looks like BroadcastPlugin is what I want in this case. As numbers are used to denote the type of event being passed, is there a way to share an enum so that if I change the event numbers used by the plugin doing the broadcasting, that it doesn't break listening plugins? And is there a solution if I'm trying to pass a more complex type like a table? | Top |
|
Posted by
| Fiendish
USA (2,534 posts) Bio
Global Moderator |
Date
| Reply #8 on Sat 21 Nov 2015 07:06 PM (UTC) |
Message
| |
Posted by
| Victorious
(89 posts) Bio
|
Date
| Reply #9 on Sat 21 Nov 2015 07:14 PM (UTC) |
Message
| Heh you replied just as I was editing my original post. | 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.
28,986 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top