Ability to use AddPackFindersEvent for optional Resource packs that are on by default

[Soaryn]

While the example of AddPackFindersEvent is highly useful, it is missing the functionality of having a resource pack added that is on by default without being forced required.

The current options are to either accept it is default off, or always on. It would be preferable to have an option of on by default with the ability to disable by the user.

[diesieben07]

I think this could already be accomplished by using PackRepository#setSelected, could it not?

[Soaryn]

@OrionDevelopment Obligatory ping as requested

[marchermans]

I think this could already be accomplished by using PackRepository#setSelected, could it not?

Sadly not the PackRepository does not exist yet, and as far as we can see there is no way for that to be done by default.

[diesieben07]

Sadly not the PackRepository does not exist yet, and as far as we can see there is no way for that to be done by default.

Yes, it needs to be done later. And the mod also needs to keep track of whether it already "auto-enabled" the pack before, so that the user can disable it again without the mod re-enabling it. Sure, Forge could add functionality for this, but it should definitely be possible already.

[marchermans]

Sadly not the PackRepository does not exist yet, and as far as we can see there is no way for that to be done by default.

Yes, it needs to be done later. And the mod also needs to keep track of whether it already "auto-enabled" the pack before, so that the user can disable it again without the mod re-enabling it. Sure, Forge could add functionality for this, but it should definitely be possible already.

My point is yeah that is a possible clunky solution. Would we consider adding an endpoint to the API that facilitates this properly.

[diesieben07]

What would "properly" mean, though, if not essentially what I described?

[marchermans]

What would "properly" mean, though, if not essentially what I described?

As far as I can see marking the pack as enabled causes a second pack reload with the performance hit of that execution.
It would be good if a modder could do this directly in the event don't you think?

So yes I don't consider the current method "properly"

[diesieben07]

RegisterClientReloadListenersEvent could be used to do it, it fires before the first resource reload and after pack finders are added.

[marchermans]

RegisterClientReloadListenersEvent could be used to do it, it fires before the first resource reload and after pack finders are added.

Nice idea I overlooked that option, but on the client side we are tending to make things properly possible in the correct events or directly in the registration place.

Having to hijack such an event is not a great idea in my opinion. But yeah @Soaryn You could indeed do it in that event to enable it by name. That said I will look into adding an additional endpoint in the original event to enable it by default without making it required.

[diesieben07]

Yes, a separate event should be added.

That said I will look into adding an additional endpoint in the original event to enable it by default without making it required.

This will not be trivial, because at this point the game has not even loaded the user-selected resource packs from the options.

[Soaryn]

Was curious if any traction had been done on a solution for this for forge :)

[marchermans]

I did not have the time, no.
Feel free to make a PR yourself.