Sugestion: export resource pack options as vannila zip. #9

Helpdesk

CuteistFox · 2024-04-03T22:21:24+02:00

CuteistFox commented

2024-04-03 22:21:24 +02:00

It would be usefull if there was a option witch would export the chosen resource pack (after the changes) as a zip that can be used in a vannila instance. The reason this is usefull is both for my snapshot instance and my quilt instance.

Johannes commented

2024-04-03 23:19:13 +02:00

I have actually considered creating a separate, stand-alone application for "applying" configs to packs without the mod, but decided against it because building and maintaining that would require a lot of effort. This also applies to a lesser extent to the feature you recommended:
Respackopts works by redirecting individual calls to methods provided by ResourcePack. As such, it does not interact with the underlying storage in any way and never considers more than the pre-loaded metadata file and the current resource.
This means that this kind of bulk transformation is not something it is designed to do and would have to either be hacked in by reconstructing a pack at the other end of the API, which would never work properly, or be an entirely separate system, which, again, means a lot of maintainance work for little benefit, a larger chance of issues and the possibility of behavioral differences.

In summary: though this is something I considered doing, I will probably not implement it here. Feel free to do so in your own project, though.
(Also: Quilt seems to pretty much be dead and never worked well anyways, so you probably should not use it)

I have actually considered creating a separate, stand-alone application for "applying" configs to packs without the mod, but decided against it because building and maintaining that would require a lot of effort. This also applies to a lesser extent to the feature you recommended: Respackopts works by redirecting individual calls to methods provided by ResourcePack. As such, it does not interact with the underlying storage in any way and never considers more than the pre-loaded metadata file and the current resource. This means that this kind of bulk transformation is not something it is designed to do and would have to either be hacked in by reconstructing a pack at the other end of the API, which would never work properly, or be an entirely separate system, which, again, means a lot of maintainance work for little benefit, a larger chance of issues and the possibility of behavioral differences. In summary: though this is something I considered doing, I will probably not implement it here. Feel free to do so in your own project, though. (Also: Quilt seems to pretty much be dead and never worked well anyways, so you probably should not use it)

Johannes closed this issue

2024-04-03 23:19:13 +02:00

CuteistFox commented

2024-04-04 03:04:26 +02:00

(Also: Quilt seems to pretty much be dead and never worked well anyways, so you probably should not use it)

Quilt isnt dead. But based on that line i shouldent open a issue for quilt in libjf.

> (Also: Quilt seems to pretty much be dead and never worked well anyways, so you probably should not use it) Quilt isnt dead. But based on that line i shouldent open a issue for quilt in libjf.

Comment

No Label

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: JfMods/Respackopts#9