![Slot Cycler [Forge & Fabric]](https://media.forgecdn.net/avatars/thumbnails/857/360/256/256/638261764350055775.png)
[Suggestion]: Compatibility with AutoHUD
Opened this issue · 23 comments
Suggestion (Required)
Currently, AutoHUD isn't compatible with Slot Cycler, and it still shows the hotbar of Slot Cycler 24/7.
I request that there is compatibility with AutoHUD, so the hotbar is hidden when it is not used, like the main hotbar is.
I was told to have this suggested to you, as the dev for AutoHUD was unable to have compatibility with Slot Cycler due to how Slot Cycler is structured.
For some weird reason, Arch-Loom doesn't like remapping the compat file in my common module. I'll have to keep three copies of the compat file, let's hope that does not cause issues in the future. Otherwise this seems to work very well.
Common artifacts of my mods are not remapped to intermediary so they can be used in other common modules even if those do not use Loom (like VanillaGradle). Maybe there is an issue with that? Works fine for me though.
https://github.com/Fuzss/hotbarslotcycling/blob/be80cd363acf7ec9618c19c41f6069eee7b31555/1.20.4/Common/build.gradle#L9
Ah, that is probably the difference, then. I was wondering why it worked fine for depending on other mods' (like yacl) common module.
I'll have to look into whether I can make that work with yarn somehow.
Fixed in v20.4.2, had a different design for that in mind first.
Hi, any plans on releasing that version soon? Other than the remapping issues (which are easily worked around by duplicating the code on my end until I figure it out) it seems to all work well now.
Oh, I see. I was just looking at the mod numbers. Apologies!
I'll finish up some other work, then test & finally push a new version of AutoHUD. If everything (hopefully) works I'll let you know.
Oh it's already out! Slot Cycler v20.4.1 includes v20.4.2 of the Hotbar Slot Cycling library which fixes the api methods being called on the wrong instances.
As the author of AutoHUD, I am happy to assist with this. I just could not figure out how to edit & PR, or mixin to your mod, with the library indirections you have set up.
Hey @Crendgrim, would love to get this working!
The class responsible for rendering the hud elements can be found here: https://github.com/Fuzss/hotbarslotcycling/blob/main/1.20.4/Common/src/main/java/fuzs/hotbarslotcycling/impl/client/handler/SlotsRendererHandler.java
The main method SlotsRendererHandler::onRenderGui is simply invoked via Fabric Api's HudRenderCallback.
Just let me know what I need to do to support AutoHUD!
I have to add in my ugly hacks for compiling against jij mods again, but otherwise that looks like I can easily add compatibility from my side!
You don't actually need Slot Cycler at all, it's just one application for the hotbar slot cycling concept. I have other projects in development which use the same functionality from the Hotbar Slot Cycling library.
The library is it's own mod. You can easily get it as described here: https://github.com/Fuzss/modresources?tab=readme-ov-file#maven
Everything seems to work fine, except that I cannot make the background texture draw without full opacity. What works fine for everything about the vanilla HUD I cannot get to work here. And I don't quite understand yet why that might be.
Once I figure that out, I can release this.
Here is my work in progress (Fabric only for now; but it seemed to work fine on (Neo)Forge as well for the simple version, so it should still do).
What I dislike most is that I have to first render the background texture to a framebuffer to render it with transparency; I have yet to figure out why that is. I already have the facility for that because of items, though (heck built-in model providers, Mojang) and it seems to work at least.
@Fuzss I have a comprehension question and a request.
In SlotsRendererHandler.java line 33, you check whether backwardStack and forwardStack are both non-empty. One of them can only be empty if the other is also empty, correct?
Assuming I understand that correctly, you then call a private method that double checks this invariant again.
I'd like to force the render of an (empty) selector anyway to give it a "hide" animation. Right now, I need to inject into all four isEmpty checks. Would it be possible to remove the checks from either outside or inside the private helper method to keep my mixin cleaner?
Otherwise, compatibility is 99% done and working really nicely!
Sure, I can remove the check on line 33.
Would you mind sharing your approach before you release it?
Honestly I'd prefer if I could change up some parts of my implementation to offer some api hooks instead of you having to use mixins to change stuff around.
Yeah I'm familiar with your item transparency code, coincidentally found that when researching how to render fading items for my Pick Up Notifier mod hehe.
I've just uploaded a new release of Hotbar Slot Cycling that exposes all rendering functionality in the public api.
You should now simply be able to retrieve the existing renderer from there via CyclingSlotsRenderer::getSlotsRenderer, store it, wrap it in your own implementation of the CyclingSlotsRenderer interface, and set your implementation to be used by my mod via CyclingSlotsRenderer::setSlotsRenderer.
Please give me a heads-up before you release your new version, since I haven't uploaded my new version to CF / Modrinth yet in case you need any more changes in the implementation.
It almost works! SlotsRendererHandler needs to call its methods on CyclingSlotsRenderer.getSlotsRenderer() instead of this. If I change that, this commit works perfectly without any mixins: Crendgrim/AutoHUD@755a377
(I can and will most probably move that all to a common folder still, and maybe split the classes, but details)
I love the clean API, I can certainly learn from that, heh.
Technically, this could live in either mod now, too, which feels very good. I think AutoHUD is still the better place for it, because I'm more likely to mess around with my API and improving how that works in the (far?) future.
