External Packages for Mudlet

[Widjet]

I've been toying with an idea to make script packages easier and more flexible for mudlet. My idea was that we could have 'external packages', which are sets of .lua files within a directory hierarchy that exist in some location separate from the rest of mudlet. The mudlet profile would have a list of paths to these external packages, and it would load them every time the profile is loaded (with a 'reload' button if you want to make changes to them).

It would have the following advantages:

• Better support for version control systems - as every script is a separate file, people could collaborate on a system without tromping over each other's changes.
• Ability to share a system between mudlet profiles - for example, you could have a UI that's common between each of the IRE games, and whenever you make changes to it, the changes propagate to all of them.
• Edit scripts with an external editor - whilst the built-in lua code editor is not too bad, external editors/IDEs can do so much more.

In addition to this, we could add support for automatic updates. Along with a path, each package could include an update URL, which is checked for any new versions, and can download them if the user wishes. It could even be possible to use the Github API to automatically pull down the latest version of a script from a git repository.

Triggers, aliases and buttons could take the form of lua files that define certain variables that are carefully imported, eg:

Code: [show] | [select all] lua

pattern = "^hello (.+)$"
type = "regex"
function script()

end

It would be possible to edit these external files from within the mudlet script editor, and every time you save your changes in the editor, the changes would be written to the files.

For commercial efforts (which I don't do, but can sympathise with), you could have precompiled lua chunks that are loaded in as scripts.

So, in short, I think it's a good idea, and I'd be happy to have a go at adding it in my own fork of mudlet, here. Would anyone else be interested in this feature? Are there any other things that you would request as part of it? Can anyone see any problems with it? Has anyone tried to do this before?

[Vadi]

This is a great idea and this has been tried before indeed - and I think your branch has them already, looking at the merges. Modules were added by Chris and address several of the issues you've described here! It's not exactly as you describe, there are some differences, but I think studying and extending them would be the way to go.

[Widjet]

If you're referring to these sorts of modules, there are a couple of problems:

• The user has to reload them from a new zip file every time there's an update. Sometimes you end up with duplicates loaded in your profile.
• The modules cannot be easily edited/collaborated on since they are part of monolithic xml files that do not lend themselves to version control or external editors.
• Once they are part of your profile, edits to these modules are edits to your profile, which are not propagated to other instances of the modules (eg: as part of your other profiles) unless you export/import them.

They're a step in the right direction, and they're what inspired this idea. But I think this approach, of individual code files that are loaded separately from the profile, would be qualitatively very different.

But yes, the implementation would be very similar - I would basically be overriding the save/load method for modules if they are flagged as external.

The sourceforge git repository hasn't seen any activity for a very long time now, we've been stuck at mudlet 2.0rc10 for over 3 months. Is there a new source repository that I don't know about? Is Heiko still around?

[Vadi]

Ahh ok - it wasn't entirely clear if you knew about modules, so I wanted to bring up. I'll think about this all in detail and respond accordingly later (in general this looks like a good thing).

Yeah, the main repository is still on sf and Heiko is around.

[chris]

Some comments on that:
The user has to reload them from a new zip file every time there's an update.

This isn't true, the module is loaded from a path, change what's in the path and you change the module. Just replace the file and the changes are reflected in mudlet.

The modules cannot be easily edited/collaborated on since they are part of monolithic xml files...

You can edit them inside mudlet, and save changes. This isn't an issue for me, if it is for you then you can use the lua loadfile command to transverse directories, etc.

Once they are part of your profile, edits to these modules are edits to your profile, which are not propagated to other instances of the modules (eg: as part of your other profiles) unless you export/import them.

Again, wrong. Module changes will be propagated to the module in all other loaded instances.

This might just be an issue with the latest public release of mudlet. I have no idea where the latest release is stuck at with functionality. If you can compile you might want to try the latest instance of my repository.