Library plugins

[goaaats]

Sparked by discussion in #606, this discussion is about the idea of library plugins.

• Will not be shown in installer
• Can be added to manifests of other plugins as optional or required dependencies with a minimum and maximum version(npm style?)
• Can provide functionality via IPC

To be considered:

• Our distribution infrastructure and the nature of what we're doing doesn't really accomodate this right now:
  => We don't keep track of old versions of plugins, so negotiating the "best version" to install would be impossible
  => Plugins need updates to support new game versions

I feel more confident adding something like this now with the rework of the plugin system in api4. Is this feasible? Is it overcomplicating things?

[anna-is-cute]

Why? We already have a package manager for plugins; it's called NuGet. Especially now that API 4 has isolation, there's no issue with mixing versions.

[goaaats]

Do assemblies isolated like that share state? Or would they need to negotiate via IPC as well?
The discussed use was the "library" plugin providing the infrastructure to show text in the info bar and offer order/style customization via ImGui or commands.

[anna-is-cute]

No, but I think a way to share state would be a better endeavour for solving this problem than recreating a package manager. Many things that would benefit from shared state are things that should be in Dalamud proper, as well. It would fix a few context menu issues in XivCommon if it was either in Dalamud or could trust Dalamud to coordinate state.

[philpax]

What do other modding communities do?

For JC2-MP, we officially blessed certain plugins and gave them a standard IPC API, but you still had to install the plugin on your server. That's fine if you're a server admin, but pretty annoying if you're a user.

Minecraft side-steps this issue with modpacks, I think, but my understanding is that it's generally a bit of a shitshow over there anyway.

Garry seems to have thrown out his toys for S&box, but I don't have hands-on experience and can't comment.

For the specific Server Info issue this stemmed from, I think making it an actual plugin is fine. As mentioned in the issue itself, it'll probably need some kind of UI configurator, and at that point it can't really be hidden as a library dependency.

[ackwell]

What do other modding communities do?

Beatsaber is a good example of the inverse, IMO.

Fair few libraries providing core logic, though they're UI-less.

---

Also the official factorio modding system has a quite sophisticated dependency system:

[daemitus]

👎 I can support a persistent arbitrary data store in Dalamud, but there's no reason to support library plugins imo.

[karashiiro]

I like the idea of being able to reuse functionality, but I don't think there's yet been a situation that has made that worth having a spaghetti dependency graph. It's a little annoying with BetterDiscord already, where upstream deps get updates all the time as opposed to plugins themselves being responsible for bundling those updates in bulk. That said, I assume BD has a good reason for doing things that way since Discord updates so frequently and can break things randomly.

Beyond that, plugin dependencies give people an excuse to push the responsibility for updating their own stuff onto someone else, which I dislike on principle (we already do that with Dalamud itself, but that's unavoidable afaik). Everyone should be responsible for making sure their own plugins work.

[ackwell]

I'm not a fan of purely "library" dependencies, as that's what NuGet technically provides - but stateful dependencies is certainly something that is lacking currently.

Using the OP's example as a discussion point, it needs to

1. Offer a single point of control over the server info bar
2. Preferably provide a user-facing GUI to edit the ordering

For implementation,

• Using NuGet naively would potentially result in multiple copies fighting over control for the element, effectively failing both 1 and 2.
• Using NuGet with some manner of shared state would technically resolve 1, though raises questions on which plugin becomes responsible for rendering the GUI from 2
• Dalamud can absorb the logic here, which resolves 1 and 2 easily - but raises questions for scope creep. Is dalamud a plugin host, or is it a full plugin infrastructure + game SDK?
• A seperate plugin with a naive x depends on y relationship in the plugin api also easily resolves 1 and 2 with existing GUI and IPC systems.

As far as I see it, only the last two options hold water. It's easy enough to say that dalamud should absorb this logic, but I do see this sort of thing becoming more common as people start messing with the game's native UI more, and imgui less.

A decision needs to be made between Dalamud being a general purpose SDK that absorbs this logic, and a light(ish) weight host that defers this responsibility to consumers.

[WesselKuipers]

I can see something like this being useful for certain types of plugins that would either conflict with other plugins or would needlessly tax some other system/API.

To use my own plugin (FCNameColor) as an example of issues I've run into:

Right now there are several plugins that mess with nameplates with no real way to guarantee that they'll play nice with each other whatsoever. I'm not sure what the most elegant way would be to make it so that they do somewhat work together, but having a library dependency to manage this could be a potential solution.

Another one would be plugins that rely on Lodestone data. My plugin fetches the current character’s Lodestone ID, FC ID, as well as the FC’s list of members. This can be relatively taxing on Lodestone to the point where it can run into rate limiting issues should SE decide to limit these pages even more than they currently are. I’m not sure how many other plugins there are right now that rely on the list of FC members, but it’s not hard to imagine that you wouldn’t want to have several plugins redundantly fetching this data.

@kalilistic added IPC support for FCNC to help resolve this a little, so you can ask for the list of FC members that way, but I wouldn’t want to force players who don’t care about a plugin like FCNC to have to install it just for that. Currently as far as I know only PlayerTrack makes use of this but it’s mostly there to prevent potential conflicts with nameplates. A library plugin could be a solution there, though some sort of Dalamud data storage would also be fine for this one in particular.