[1.16] Optional dependencies and data files

[Mirality]

What's the recommended method to deal with optional dependencies of your mod?  For example:

1. If there's a block/item that should only exist if another mod is loaded as well (but is not otherwise required to run your mod).
2. If recipes or loot tables should change depending on whether another mod is there or not.

 

For #1, it seems like the best idea is to not register those items (so that they don't show up in JEI/elsewhere and get deleted from the world if you removed the other mod).  But even in the starting-a-brand-new-world case, this still results in data pack loading errors for missing recipe/loot/advancement targets etc.  Everything seems to actually work (because it then ignores the file, which is what was wanted anyway), it's just clutter in the logs that may unnecessarily alarm people, and it'd be nice if there were a tidier way to do it.

 

For #2, I have no real idea what the solution for that might be.  (Mod packs can deal with it easily enough by adding an extra data pack, but there should be a way for a specific mod to alter its defaults too, without adding an extra jar.)

 

Is it perhaps possible to define multiple data pack folders in a single mod, and have the mod code control which of the packs are loaded (and in which order)?   (i.e. the regular "data" folder is always loaded, but then the code decides whether or not to load another pack in a different folder in the same jar.)  That way you can have the data for mod-specific items in a folder that doesn't get loaded unless the mod is, or have your "base" recipes in one folder and then override them in a second folder if a particular mod is loaded.

[Mirality]

For #1, I'm actually trying to consolidate two small addon mods (that each only add one or two blocks) with required dependencies into one mod with optional dependencies.  Or is it really better to keep it as two separate mods regardless?

 

How do you go about hiding registered items?  Isn't that set in the properties at registration time?  (As far as I can see, that's immutable.)  Never mind, I've found that one, isInGroup can be overridden.

 

What should you do if the block exists in the world but someone removes the dependent mod?  (If the block remains registered, it will continue to exist in the world, but then interacting with it will try calling things in the other mod that isn't there any more and will crash, unless the code is littered with "if the mod isn't there do nothing" checks absolutely everywhere.)

 

I tried making an ILootCondition but it still resulted in error log spam.  Although possibly that was because the block wasn't registered due to #1.

 

Edited January 5, 2021 by Mirality

[Mirality]

25 minutes ago, diesieben07 said:

Personally I think it would be better to have it all in one mod that can adjust its behavior automatically - this way the installation process for users is simpler.

I agree, but that's different from what you seemed to be saying before... 😌

[Mirality]

So does "thou shalt register all thine things" apply to tile entities too?  Or is it safe to only conditionally register them if you want them to disappear from the world if the condition fails?

 

Currently there's a pitched battle between "a mod requires me to implement an interface directly on the TileEntity" and "I want to be able to run without that mod loaded".  (And the optional interface annotation thing that I've seen talked about appears to no longer exist.)

 

I'm aware that the correct answer is probably "it should be checking for capabilities instead"... but it isn't, and there's not much I can do about that.

 

My workaround is to register a dummy TileEntity that does nothing at all (including throwing away any NBT), but it'd be cleaner if I could just not register it and have it stop existing entirely.  I assume that if the player later loads the other mod again then the block will generate a new TileEntity, either by itself or when they break and replace it.

[Mirality]

7 minutes ago, diesieben07 said:

It should definitely not just be a dummy, and you definitely should not be throwing away NBT data.

Basically all I'm doing is `extends TileEntity` and calling `super` in the constructor.  Whatever the default behaviour of that is, is what it does.  The fake has no other methods implemented.

 

The tile entity has no reason to exist at all if the other mod isn't loaded; there's nothing for it to do.  It could possibly preserve some NBT data for when the other mod shows back up again (if TileEntity doesn't already do that -- but I assume it throws away the custom data), but I don't really see the point because any data it saved would be useless since the other mod's TileEntities would definitely have been destroyed while it wasn't loaded, and would have to be regenerated with different values if you reloaded the other mod anyway.

Edited January 6, 2021 by Mirality