[please comment] package sharing solution

[Vadi]

Well, until it comes up as an issue, I think it'll be alright for now. Meanwhile, you can maintain the non-pollution which we promote via proper namespace usage and Lua modules.

[tsuujin]

Frankly, I hated plugin design in MUSH, it was the one MUSH feature which I thought completely stupid. Writing a plugin was tedious, and communication with others even more so.

Global namespace has it's drawbacks, but the ease of use is well worth it.

The only advantage to sandboxing is not having to define everything as an array value which saves a few keystrokes

[Vadi]

Don't even have to use the extra keystrokes. Lua has a module system that works fine in Mudlet:

[Hadoryu]

And I'll certainly be using that. I didn't mean to derail things too far with the sandboxing thing, I think that's a closed case as it is.

Regarding installing/uninstalling - won't this be an issue with script generated triggers and aliases as well? Since you can already unload scripts, I assume it should be an analogous procedure for simply unloading all the scripts of a particular plugin.

Perhaps a plugin explorer window that can help look through what a package contains, along with allowing packages to be installed/uninstalled/reinstalled/disabled on demand?

[Vadi]

Yes, the perm* functions should have an optional argument to specify which package they belong to (if none, it'll just go into the 'general' category that is the users or whatever).

Not sure on how to attribute items to the package they belong. Having a separate window for this would sort of duplicate all existing alias/trigger groups.

Since all the parents children would belong to the same group as the parent, perhaps the different package attributions could be set on the parent level. Like... right-click on group, select one of the packages already installed to attribute to or click on 'create new package'. In the tree display list, if the parent belongs to a package, it would be listed as '<package> - <parent name>'.

[tsuujin]

Yes, the perm* functions should have an optional argument to specify which package they belong to (if none, it'll just go into the 'general' category that is the users or whatever).

Not sure on how to attribute items to the package they belong. Having a separate window for this would sort of duplicate all existing alias/trigger groups.

Since all the parents children would belong to the same group as the parent, perhaps the different package attributions could be set on the parent level. Like... right-click on group, select one of the packages already installed to attribute to or click on 'create new package'. In the tree display list, if the parent belongs to a package, it would be listed as '<package> - <parent name>'.

You could always just add a "package name" field to the existing dialogs for all items, put it right up above the existing "name" fields.

[Vadi]

Yeah, a combo box + line edit combination on the same horizontal space would work.

[Heiko]

What I currently have in mind is to add a package name field to folders only. This means that all children are considered to be part of the parent folder's package that has a set name and will be removed if the package is uninstalled.
This makes it possible to create optional sub packages e.g. trigger kits that only apply to certain character classes.

[tsuujin]

What I currently have in mind is to add a package name field to folders only. This means that all children are considered to be part of the parent folder's package that has a set name and will be removed if the package is uninstalled.
This makes it possible to create optional sub packages e.g. trigger kits that only apply to certain character classes.

I'd really prefer to be able to specify individual items as package items, with the option of turning every folder element to that package. I just dislike the idea of Mudlet making decisions about my folder layout for me.

[Heiko]

The problem with this approach clearly is that items without parent folders that are part of the package would all be exported as parentless root elements. This would destroy chains, filters etc..