Hi!

I was testing Endergetic Expansion in my 1.20.1 modpack, and noticed that Ender Fire does not have compatibility/integration with the mod Soul Fire'd. This mod makes Soul Fire unique, with different attributes compared to normal Fire. It also adds an API that allows other mod developers to implement their own custom fire types. I was wondering if it would be possible to have out-of-the-box compatibility with this mod? I spoke to the developer, and this is what they had to say (I'll also rope them in on this GitHub issue):

Thanks!

This same request is mentioned on the Soul Fire'd repository here: crystal-nest/soul-fire-d/issues/64

We have no intention of maintaining compatibility with this mod.
They are welcome to add compatibility on their side.

Hi! I'm the developer behind Soul Fire'd!

Soul Fire'd aim is mainly to provide an API for other modders to create their own custom fires easily and quickly, while keeping full customizability. So, while "maintaining compatibility" can be technically true, I'd see it more like "leveraging" SF to ease your development and benefiting from additional compatibility with other mods that add other custom fires (or fire mechanics).

Of course, as a mod author myself, I know that it can be annoying to have to depend on another mod. However, exactly because I know the struggle, I:

• Support a wide range of Minecraft versions (as the time of writing, 1.18.2, 1.19.2, 1.19.4, 1.20.1, 1.20.2, 1.20.4, 1.21, 1.21.1, 1.21.3, 1.21.4).
• Support the main mod loaders (Fabric, Forge, NeoForge).
• Am willing to port SF to any other version/loader another mod may require.
• Provide an up-to-date, detailed wiki for every SF API aspect.
• Accept other mods embedding SF (more about this at the bottom).
• Give the utmost priority to any request that might come from other mod authors using SF API.
• Help other mod authors first using the API by making PRs.

Soul Fire'd is already integrated into many other mods. You can find a list of all known compatible mods here.
Regarding EE, though I haven't had time to thoroughly inspect its code, I believe compatibility could be added with a simple JSON file, similar to how BYG implemented it. However, this approach has a downside from a development perspective: it prevents you from streamlining your fire-related logic. Instead, you'd need to maintain boilerplate code for basic Minecraft compatibility, whereas using the SF API would allow you to handle everything seamlessly and with much less upkeep.
An example of this second approach can be found from Infernal Expansion PR, but also in the PR I already opened for Caverns & Chasms.

If there's anything I overlooked, please let me know!
Thank you for the time and attention.

My above message is final unless you were to switch to a much easier system.
It's unsustainable, and honestly a bit rude, to ask other mods to hard depend on you, especially with how you've structured the system in a way that's not easy for mods to maintain.

If it's just a simple soft-dependent JSON file, then I'd be willing to merge that.

I understand your motivation to remove the boilerplate code, but the primary issue is the difficulty of hard depending on your mod for a basic vanilla-like block. We would never merge a hard dependency for something so simple in any of our mods.

I don't know your mod's goals, but if it's to fix the common compatibility issues with fire blocks, you should design the system as softly as possible.

My above message is final unless you were to switch to a much easier system. It's unsustainable, and honestly a bit rude, to ask other mods to hard depend on you, especially with how you've structured the system in a way that's not easy for mods to maintain.

Thank you for replying.
I'd be glad to find ways to make it easier for other mods! Is there something you suggest?

Currently the gist of it is:

1. Register your fire(s) within the API.
2. Register your fire related block and items with SF API rather than Forge/NeoForge one (but the use of the returned object is the same).

If we take IE code, for example, point 1 is implemented by:

• IEFireTypes, calling SF API to register their fire.
  Fires are registered with a straightforward builder pattern.
• InfernalExpansion.java L89, loading the aforementioned IEFireTypes class.

While point 2 we have:

• IEBlocks L249 to L252, calling SF API to register lantern, torch, campfire and fire.
• Block items and the particle type are registered in pretty much the same way, but in other IE init classes.

And then, thanks to 1 & 2, IE removed:

• Mixins to handle fire behavior.
• Lots of logic in their classes for fire, campfire, torch, and lantern.
• Manual assignment of fire and campfire tags.
• Custom campfire entity.
• Registration of fire related blocks to the cutout renderer.

And it ended up benefiting from the expanded compatibility, since IE before had custom code to handle BYG fires, but that comes free with SF (because BYG supports SF).

In the case of EE, the process would be about the same:
Lots of boilerplate removal at the price of a few extra lines to register your fire (and technically changing the registration of fire related game objects from Forge API to SF API, but it's basically the same, except that it's slightly more streamlined with SF API).

That's not all though. EE (unlike C&C) could actually just add compatibility with SF by adding a simple JSON file, similarly to what BYG did.
The upside is that this is quicker to implement and doesn't require for EE to add SF as a dependency (embedded or not) and you still get full compatibility, however you'd lose the benefit of removing boilerplate code.
In my opinion, boilerplate code is harder to maintain than a few lines of code to comply to an API, because any change to Minecraft that would currently require you to put more effort to update would now be delegated to the API.

Lastly, I would like to add that IE is currently using SF API to register EE ender fire, so that when IE is installed alongside EE, ender fire already works properly with SF. IE does it via code, but for EE the datapack way would be equivalent (it's just that IE was already using the API, so it was better to keep it all in one file rather than mixing Java and JSON).
For this reason, directly adding EE compatibility with SF would also benefit IE a little bit.

As said initially, I remain open to any suggestion. The aim of SF, as with any other mod API, is to make life easier.
If there are ways to make it even easier than it currently is, I'm all for it.
If you have further questions, please let me know. Thank you again.

If you want, I can make two PRs, one with the soft dependency and one with the hard, and then you can compare and chose whichever you think is best for EE.

I understand that depending on a mod API for a restricted scope can feel cumbersome.
With Soul Fire'd, not only you streamline the fire block itself, but also all other related stuff like campfire, torch, lantern (and the respective items), the particle and any custom behavior you'd like. SF also handles aspects related to entities burning.

Since for EE, all of this is just a Vanilla copy with a few changes, the main advantages of adding a hard dependency would be:

• Removing your custom classes for the fire, campfire, torch, wall torch, campfire entity, and fire particle.
• Removing the BaseFireMixin.
• Removing some other related code lines, like cutout registration, fire and campfire definitions, etc.
• Encapsulate any change Vanilla Minecraft might apply in the future about these stuff behind SF.
• Be fully integrated with other mods using Soul Fire'd, like IE, Torch hit, BYG, Danger Close, etc.

The only disadvantage would be to add a new dependency.

Using the datapack way, which was designed exactly to allow mods that don't do much other than Vanilla-like stuff with their fire(s) to have a soft dependency, EE would get the advantage of being fully integrated with almost all other mods using Soul Fire'd, but would lose all other advantages.

To be honest, the datapack way is also less work for me ahah
But I'd like one day to see SF become the go-to for when someone needs to implement anything fire related, so I'm more than willing to offer all the support I can to other mod authors.

Last note, and sorry for my inability to be brief, but while EE is fine with a soft dependency, C&C unfortunately isn't, for two reasons:

1. Its EntityRenderDispatcherMixin.
2. The many points where entities are set on fire.

However, an optional hard dependency could still be possible.
But I guess it's better to keep C&C discussions on the already open PR, where you can already see how adding Soul Fire'd would look like.

Thanks again for you time.