Multiple Optifabrics
Opened this issue · 5 comments
Looking at the forks list, some others are also maintaining Optifabric, like shedaniel and Chocohead. Would it be a good idea to try to consolidate to one line of development? It could allow for faster development, and then those who look for Optifabric aren't confused by the multiple versions.
if @Chocohead prefers to maintain Optifabric-updated in my stead, I will not object.
I would certainly agree that consolidation is the best way of getting OptiFabric moving along as best it can. Were the different forks all aiming to achieve different goals then perhaps the situation would be different, but they're all ultimately just trying to get OptiFabric working with as many mods as possible.
The reality of maintaining OptiFabric for any length of time is that mod compatibility is the biggest thing you are up against. That is why I went for trying to ease the burden within my own fork, aiming to make Mixin LVT conflicts especially easier to resolve without needing to PR to individual mods. I would say it would therefore make sense to continue on with that as it should make everyone's lives easier.
Modmuss and I have spoken a few days ago about the original OptiFabric Curse project, so I can modify and upload directly to that now, giving a sense of officialness I suppose which should help draw contributors to a single place. If you want to archive yours once we do that, that remains up to you, I've been refrained from pushing openly to be the sole solution until it was a bit clearer what forks were out there and how they were doing. I'd certainly welcome any help that you (or indeed anyone else) might be willing to offer all the same; be it testing mods to see if they work, contributing fixes for the mods which don't, or even just updating the main readme/project description to be clearer of the options which exist now.
@Chocohead Yes, I agree. Moreover I would be glad if someone took the burden of updating Optifabric off my back.
On a related side note, I would like to have your opinion on if it is possible to implement more "universal" solutions to conflict-causing problems rather than dealing with them one by one -- It seems that each mod incompatibility is resolved manually on Optifabric's side through numerous quick-n-dirty patches. Is there a way to implement a solution that is not on a per-mod basis?
For example, it seems to be that around half the conflicts from mods are due to the way Optifabric changes the opcodes of every method/field/class it touches to be public, even when not completely necessary. Would it be possible to reimplement this as something less invasive?
Whether a problem can be universally fixed or not depends on the nature of what is wrong. I'd collect the problems you'd see into five different categorises:
- Access issues from AWs not applying to things OptiFine changes
- Injection problems from OptiFine renaming lambdas then OptiFabric not mapping them back
- Injection problems from OptiFine moving methods about (often due to Forge's changes)
- Injection problems from OptiFine changing the local variables in a method
- Something softer, such as the rendering pipe line being slightly different
The first certainly can be fixed in whole, in fact I already have (Chocohead/OptiFabric@973ccc7). For some reason OptiFabric makes everything which isn't private public, in spite of the most likely change being something private being made public. So I took the conclusion it makes more sense to just pick which ever is wider between any AWs which have been applied and Optifine's patched access.
The seconds stems from a bug which OptiFabric has had since 1.14.4 from a bad update. None of the lambdas were being renamed which means they effectively all disappeared. Fabric API for example uses two in ThreadedAnvilChunkStorage for the chunk load/unload events which OptiFabric just patched back, without even ensuring they were being called (which they weren't). This causes loading problems in mods as the events never fire, although it was rare for this to result in crashes, clothesline just didn't render existing lines which is how I found out. I gave it a good go to remap back as many lambdas as possible: Chocohead/OptiFabric@afc68e0.
The third and fourth are where the more universal fixes become more difficult, as typically the methods or their contents changing is not something which can be reverted without having to apply what OptiFine does some other way anyway. For the cases where it's just adding a Forge change obviously that's less of a problem, but it's presuming OptiFine won't do anything else for skipped patches isn't always a safe thing to presume. The best that can be done is making the patches which are needed as simple to make as possible, as it avoids side effects from them as well as reducing the effort to make the fix in the first place. For LVT problems at least I think I've got it down to be about as simple as it could be: Chocohead/OptiFabric@01a0441.
The fifth and final might not even be fixable. If you take a case like Satin which adds its own shaders, or Sodium replacing the renderer itself, it just might not be possible to make them work alongside Optifine. Other times it might be possible but just unclear what is needed to do, if a mod is relying on something which Optifine subtly changes. Either way, there's no chance you can really generally fix these situations, just take and conclude on what to do as they come.
@Chocohead Incredible! With all the things you've already done, it is completely clear now that you should be the one to continue Optifabric. Thanks for indulging me with such a detailed answer to my question. I will now archive this project and direct others to your fork.