[2.0.0-1.19.2] Compatibility issue: Raised and Tough As Nails Integration

[Oszoou]

Description

I have encountered a compatibility issue between the Raised and Tough As Nails. The temperature indicator does not accurately reflect changes in the hotbar, as illustrated by the attached screenshots. This inconsistency hinders the smooth integration of these two mods.

Screenshots

1. Expected Behavior:
2. Actual Behavior:

Note

Furthermore, I would like to suggest the removal of the "modular support system" from the mod. This component appears to lack practical utility and unnecessarily increases the number of files, making the maintenance process more complex. By eliminating this feature, we can streamline the mod's functionality and simplify its ongoing management.

We appreciate your attention to this matter and kindly request your prompt assistance in resolving the compatibility issue between Raised and Tough As Nails.

[yurisuika]

I can see about fixing that up for the mod, but you must understand the reasons for the modular support system.

When I add support for another mod, what I am really doing is injecting into their code. This is naturally hacky and unstable and may break with any update of the mod. With a modular support system, multiple versions of a mod can be supported.

You can't mix and match your versions without such a system, so it gives the user the luxury of choice. Otherwise, the user may have to eliminate one mod, be forced to play on a certain mod version (this may have further reaching implications like compatibility with a certain version of FAPI or Forge), or may decide to just stop running Raised. This is because it will crash when something can't be mixed into.

While this use case has only seen limited appliances so far (mods such as Botania or Create that change stuff), there is another issue that prevents me from supporting mods. That is the issue of predictability. When game versions change, especially nowadays, they tend to change a lot of stuff internally. Even if your code looks the same, you may need to rebuild it because some signatures have changed. We saw this issue just with the 1.20 release, as trying to keep mods supported that aren't even out yet just resulted in the mod crashing when they did come out, as I can't exactly predict what they will be like when they do come out. I try to keep Raised up to date by the snapshot, and some mods that I "support" at least get versions out upon game version release. But some also come out well after that. Needless to say, this just would just result in a bunch of releases to fix mods whenever they come out. It was the main reason I moved to this system to begin with.

It may be one more step for the user, but it ensures all of the above to be the least troublesome as possible. The best way for support to occur would be for the mods that I support to add support for Raised on their end. And if they decide to do so and I already had been injecting into their mod with the modular support file, well guess what the user can just delete the support file and I have to do absolutely nothing on my end! It really would be that painless.

[yurisuika]

And a further proof of point of why this system is beneficial, just read about the situation with Farmer's Delight.

https://github.com/yurisuika/Raised/issues/54

A day after their release which added some stuff to the hotbar, someone made a PR request to add support for it to Raised. It took them 7 months to merge the PR request. In the meantime, I broke apart the ability to move stuff into the two, for HUD and Chat. Long story short, this broke the fix in that PR request months before it was even merged. I even had added Farmer's Delight "support" to Raised in the meantime because someone requested it. I don't think they actually released anything until July.

Long story short, later on I readded legacy support having found this out (with 2.0.0) as the release I made for 1.20 was soon found to break with FD (the issue of predictability) and some other mods I tried to predict for. So, for a while, FD had support for Raised but it wasn't even working because it was for that legacy object that was no longer in the mod at the time, but at least it was being supported internally by Raised. If I hadn't split apart the chat and hud, we would have seen the stuff in FD being doubly raised or lowered, because it was being done so on both ends!

Now, this is a bit of a silly case caused by lack of communication or knowledge of the other party's actions, but it does go to show what can happen and how the modular support system can come to the rescue.

[yurisuika]

Just another point looking at Tough As Nails, I see there are versions specifically for 1.20.1 and 1.20. Just because Raised can run on both versions at once doesn't mean other mods can. Without a modular support system, it would simply not be possible to support both TAN 1.20-9.0.0.91 and 1.20.1-9.0.0.93 without having to break down Raised into every version itself. One more benefit of the modular system.

[yurisuika]

The orb is done... from what I can tell the hyperthermia and hypothermia work fine already, so I take it the orb itself was the only issue.

[Oszoou]

Thank you for resolving the compatibility issue with Tough As Nails. I appreciate your efforts in fixing the problem. I apologize for not clearly specifying that the orb was the only issue I observed. Furthermore, I now understand the reasons for "modular support systems". However, I am unsure if any changes have been made to the hotbar mechanics in Minecraft or Tough As Nails since version 1.12, as the Console Experience mod seemed to function properly in 1.12.2 alongside Tough As Nails without additional "modular support system". For reference, you can find the relevant code here.

[yurisuika]

That is interesting. It appears to use Forge events which I am wholly unfamiliar with. It would seem that Forge has (or at least had) specified element types for different parts of the HUD. I cannot find them in current Forge versions, however. The last version of the mod was on 1.16. It seems that Forge used to make it easy to classify what your HUD element should belong to, and this mod took advantage of that to translate some of those on the Y axis when the render events are called.

In 1.17, it seems Forge removed some of those element types, specifically the ones he was using to translate the desired HUD elements. As of 1.20 it is entirely different. I suspect this is why the mod stopped updating after that.

It seems the Fabric version of the mod was only made for 1.14 and did not have the ability to move around the hotbar etc.

I can poke around and see what I can make happen. It may very well be able to be done in 1.16 Forge, but 1.20? I cannot say. I have high doubts anything similar can be done with Fabric.

But that may take a long time as I will have a lot to figure out. I will still get the backporting of TAN support done and releases put out shortly.