Did you know that the MCUpdater team hosts a small pack of client-only mods suitable for inclusion in most serverpacks? No? Well, neither do most of our other users, apparently.
We’ve been doing this for years now, but I realized this week that we’ve never documented the process outside of one-on-one conversations on Discord. Oops 😛 Sorry, I’ll fix that now.
What is “the optional(s) pack”?
So yeah. The optional pack is a whole mess of mods for the recent popular modded MC versions:
When the next major MC version becomes feasible, we will update to support it as well.
All of these mods are safe to include on the client without any server-side support (though there may be server-side support for some mods as well). The pack is maintained and hosted by us as a community resource to save people time and effort – largely by preventing your players from whining about not having access to a popular mod that you don’t use and therefore forgot to include in your already massive pack.
And adding the pack is as simple as adding one line to your XML:
I typically put this include as the second entry in my <Server/> block, right after the Forge import. This makes it easy to override.
How/why/when do I override optional mods?
In many cases, you can happily import the optionals and then forget about it. But that’s not always the case. Let’s discuss a few scenarios where simply dropping the import into your pack is not enough.
I don’t want people installing mod X
You really don’t want both overlays fighting on your screen – it’s a case of one or the other. And because TOP has a server-side component, if you install it on your server, all of your clients will need to install it… and that means you’ll be serving them a link to TOP and they probably shouldn’t install Hwyla/Waila by accident. If you’re using our optionals pack, we provide links to Hwyla as well as a few of its more popular addons.
Disabling a mod is as simple as adding a line (anywhere after the import) that looks something like:
Where the ‘id’ is whatever ID is used in the import. (And yes, we call Hwyla “waila” because legacy reasons.)
And that’s it. The mod won’t show up for installation in MCUpdater and your users won’t accidentally get double overlays. Because we annotate any addons with the appropriate dependency attributes, they won’t show up in the list either – after all, if Waila isn’t in your pack and Waila Harvesting depends on it, they can’t install Waila Harvesting, so there’s no point in muddying things further.
The same goes for if you want to prevent people from using Journeymap or anything else really.
I want to provide a custom/different version of mod Y
Maybe you want to target a newer/older version of the mod. Maybe you compiled it yourself or otherwise need to host the mod from a different URL. Maybe we’re just being really slow about updating the public pack.
If there’s a mod we provide that you want to overwrite, you can do it. Just put in an entry in your pack like you would otherwise. As long as the mod ID you provide for your version matches the one in our import, MCUpdater will use whichever <Module/> entry comes last in the pack. If you only want to change one or two elements of the mod entry, you can define it as an Override and just provide the changes – but if you want to replace the whole block, you can do so as if the mod was never imported in the first place.
For an example of import chain overrides, see SMB’s post on incremental updates.
Wait, why are you including Library Z as an optional mod?!
Yeah, I know. Libraries are typically not optional… except when you’re only adding them in order to support an optional mod. So yes, we have a few major libraries in the pack. This isn’t ideal, but it’s also not a problem because if you’re using that library for something else in your pack, you’ll have a normal entry for the mod that installs the version you need. As long as you use the same mod ID, it will override, etc… and everything will play nice together.
In an effort to prevent people from accidentally installing unnecessary libraries (which shouldn’t hurt anything, it’s just a wasted install), the mod names for libraries is prefixed with an obvious “[library]” marker.
Wait again, I see mods in here that depend on Forestry and Thaumcraft and…
Yeah, I know. These are purely client-side addons that don’t need any special attention on the server to work. By specifying them as depending on a content mod, we are able to provide them conditionally. Just like disabling waila will prevent us from showing waila addons to users, serving a pack without forestry will prevent us from showing bee breeding jei addons to them.
If you are using a mod that has optional JEI/IGI-XML/etc… sort of addons that we’re including, make sure you match its ID and users will be able to see the optional addons for it.
When does the pack get updated?
When people complain about it, mostly. Often those people are the MCU team, but anyone in the community can pipe up and let us know that a mod is out of date, etc… There are two ways you can go about encouraging us to update the pack:
- Log into our Discord server and tell us.
- Send us a PR via https://github.com/mcupdater/pack-optional.
In either case, if it is a legitimate update, we should take care of it in a day or three. If you can’t wait that long, you should update your own pack while you’re waiting for us to update the public copy of the pack.
Argh! You updated the pack and now EVERYTHING IS RUINED!
Sorry. Let us know what update broke your client, and we’ll see what we can do. Either we’ll roll back the change or we’ll provide an alternative mod entry as appropriate.
I really love Mod A, will you add it to the pack so everyone else can enjoy it too?
Maybe. We’ve had to tighten down our criteria for including mods in the public pack. Right now, the requirements are:
- The mod must not require any server-side component to function. This means that mods like TOP and Ambidextrous are out because they have to be installed on the server as well as the client.
- The one minor exception to this are informational sort of plugins like JEI or In-Game-Info XML addons that depend on some 3rd party client+server mod.
- The mod must not be perceived by the community as a “cheat”. This means that x-ray stuff or client movement hacks are out. Basically anything that an average server operator might not want their users installing. If you want those on your own pack, more power to you – but they’re not going in the public pack for everyone.
- The mod must have an obvious client-side functionality. We’re not installing mods that are merely harmless to install on the client, they need to be there for a reason. So things like Morpheus are out because their functionality is purely server-side.
- The mod should be largely self-contained, no weird dependencies. I don’t like putting libraries in the optionals pack. If a mod is otherwise a good fit, but it depends on Modder Joe’s Self-Named Corelib Of Separate Modfulness… we’re probably going to pass. The only libraries I’m including are major ones that people have a reasonable chance of overriding and installing anyway. This isn’t a hard rule, but so if a mod is amazing, we’ll take it – joescorelib and all… but yeah. I really don’t like putting libraries in the optionals pack.
But all of these guidelines aside, we reserve the right to refuse to publicly provide a mod to folks for any reason, no explanation necessary. Maybe the mod has a track record of causing problems for clients. Maybe its author is a jerk. Maybe the mod is brand new, by an untrusted developer, and we want to give it some time. Whatever the case, we’ll try to explain the reasoning for our decision to add/exclude a mod… but don’t make any promises. And those decisions are likely final – continued whining after a decision has been made is unlikely to sway us. We have experience dealing with small children.
But yeah, that’s about it. Take a look at the pack, use it if you like. Join the community on Discord and let us know what you think – we’re doing this to make things better for everyone involved, but we can’t do it without feedback 😉