Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identify zip file contents #576

Merged
merged 14 commits into from Jan 7, 2023
Merged

Conversation

Ryex
Copy link
Contributor

@Ryex Ryex commented Dec 10, 2022

Purpose

This PR will add support to identify zip archives (and in some cases bare folders) as containing:

  • Minecraft Data Packs (Presence of a valid pack.mcmeta and data folder at the archive root.)
    • add class DataPack : public Resource
    • add LocalDataPackParseTask
    • add tests
  • Minecraft Resource Packs (Presence of a valid pack.mcmeta and assets folder at the archive root.)
    • add additional checks to LocalResourcePackParseTask
    • update tests
  • Minecraft Texture Packs (for older minecraft versions prior to 1.6.1) (Presence of a pack.txt at the archive root while not parsing as a resource pack.)
    • add additional checks to LocalTexturePackParseTask
    • update tests
  • Optifine / Iris Shaderpacks (Presence of a shaders directory at the archive root)
    • add class ShaderPack : public Resource
    • add LocalShaderPackParseTask
    • add tests
  • A Minecraft Mod (presence of mcmod.info \ META-INF/mods.toml or mod loader equivalent file at the archive root)
    • add a bool validate(QFileInfo file) function to LocalModParseTask
    • add good tests ?
  • A Minecraft World (some worlds are distributed by CF, would also be good to import a world into an instance by dropping it on the window.) (detected by a named directory containing a level.dat)

With this support it will also add check during instance creation to ensure zip files are placed appropriately.

Added as a draft for tracking and review purposes.

Related Issues

When complete this should fix #349.

Additional Info

will enable the creation of support for managing datapacks.

Comment on lines +72 to +85
switch (type) {
default: {
auto res = Resource::compare(other, type);
if (res.first != 0)
return res;
}
case SortType::PACK_FORMAT: {
auto this_ver = packFormat();
auto other_ver = cast_other.packFormat();

if (this_ver > other_ver)
return { 1, type == SortType::PACK_FORMAT };
if (this_ver < other_ver)
return { -1, type == SortType::PACK_FORMAT };
}
}

Check notice

Code scanning / CodeQL

No trivial switch statements

This switch statement should either handle more cases, or be rewritten as an if statement.
@flowln flowln added bug Something isn't working enhancement New feature or request labels Dec 10, 2022
@flowln flowln added this to the 7.0 milestone Dec 10, 2022
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
moves the reading of mod files into `ModUtils` namespace

Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
@Ryex
Copy link
Contributor Author

Ryex commented Dec 24, 2022

Ok, just added a simple validator for Shaderpacks. Only world saves left and then I can write a function to take a file name and tell you what it is if it is any of these things.

I'm a little hung up on how to validate world saves

There are two real questions:

  1. Should this have it's own Resource class and parse task like the others? if so where should these classes live? launcher/minecraft/mod feels inappropriate but it's where everything else is.

  2. Should the validator identify and mark the save format? I know what your thinking "save format"? but there are two major ways a save could present.

  3. an archive containing

saves/
├─ <word_name>/
│  ├─ level.dat
  1. an archive containing
<word_name>/
├─ level.dat

The first is done to make extracting the save as easy as unpacking the archive to the minecraft folder while the second requires knowing to unpack to the saves folder but both are commonly used and distributed.

I think this change is significant enough that code handling the world save would like to know beforehand without needing to check itself. Should it use a m_format enum?

@flowln
Copy link
Contributor

flowln commented Dec 24, 2022

  1. Should this have it's own Resource class and parse task like the others? if so where should these classes live? launcher/minecraft/mod feels inappropriate but it's where everything else is.

I agree that the name isn't the best, but that folder should really be called resources instead of mod, considering all that is there now. I just didn't do it because it'll be a big big diff :p
Anyway, i think the world stuff can go there regardless of the current name of that folder

  1. Should the validator identify and mark the save format?

I think you can make it a separate enum if you really think it would change a lot of the code. It would possibly be similar to ResourceType, but only for Worlds. However, I don't see how that'd be such a big thing in the code for parsing it. Wouldn't it just be a simple check like this?

if ("saves" folder exists)
    goToSubfolder("saves");
// Continue parsing ...

Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
@Ryex
Copy link
Contributor Author

Ryex commented Dec 25, 2022

Ok, all the new validators and tests are in place. taking off WIP for preliminary review.

In order to truly close #349 I just have to add the check to the instance creation task after the files are downloaded

@Ryex Ryex marked this pull request as ready for review December 25, 2022 01:11
@Ryex Ryex changed the title WIP: Identify zip file contents Identify zip file contents Dec 25, 2022
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
@Ryex
Copy link
Contributor Author

Ryex commented Dec 25, 2022

And... DONE!
Added a check on FlameInstaceCreationTask to validate zip resources are in the right place.

checked with these modpacks

Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
@Ryex
Copy link
Contributor Author

Ryex commented Dec 25, 2022

validated that world saves are handled correctly via https://www.curseforge.com/minecraft/modpacks/mythcraft-revilo2

@Ryex
Copy link
Contributor Author

Ryex commented Dec 25, 2022

.. the build fails.... oh that is weird. in my machine somehow it knows how to convert QString to QFileInfo...

OH! it's a qt 5 vs 6 thing

fix: validatePath in validateZIPResouces

Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
@Ryex
Copy link
Contributor Author

Ryex commented Dec 26, 2022

ok, fixed

@flowln flowln self-requested a review December 26, 2022 13:18
Copy link
Contributor

@flowln flowln left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry for the big amount of comment changes 😅

When you changed the process functions to return a bool instead of void, you also added checks to see if they returned the expected values. In principle, that's good, however maybe that's a bit too strict. For instance, suppose a resource pack doesn't have a pack.png file. It is a valid state, since it will just use the default image on the game, but when you check its result, and returns false from the entire processing of the resource pack, you make it so that the lack of an image is considered as a failure. Shouldn't that be changed, so that optional fields don't trigger this kind of failure?

otherwise the logic looks mostly fine, thanks ☺️

launcher/minecraft/mod/DataPack.h Outdated Show resolved Hide resolved
launcher/minecraft/mod/DataPack.h Outdated Show resolved Hide resolved
launcher/minecraft/mod/DataPack.h Outdated Show resolved Hide resolved
launcher/minecraft/mod/Mod.cpp Outdated Show resolved Hide resolved
launcher/minecraft/mod/ResourcePack.cpp Outdated Show resolved Hide resolved
launcher/modplatform/flame/FlameInstanceCreationTask.cpp Outdated Show resolved Hide resolved
launcher/modplatform/flame/FlameInstanceCreationTask.cpp Outdated Show resolved Hide resolved
launcher/modplatform/flame/FlameInstanceCreationTask.cpp Outdated Show resolved Hide resolved
launcher/modplatform/flame/FlameInstanceCreationTask.cpp Outdated Show resolved Hide resolved
launcher/modplatform/flame/FlameInstanceCreationTask.cpp Outdated Show resolved Hide resolved
@Ryex Ryex force-pushed the identify-zip-packs branch 3 times, most recently from 5fe5a94 to bc0da56 Compare December 26, 2022 21:43
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
@Ryex
Copy link
Contributor Author

Ryex commented Dec 26, 2022

ok, all cleaned up now. sorry for the mess.

Copy link
Contributor

@flowln flowln left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, all cleaned up now. sorry for the mess.

don't worry about it, it's a lot of code to keep track off, some stuff inevitably slips by 🙂

i only have a single note here, otherwise this looks fine for me i think!

launcher/modplatform/flame/FlameInstanceCreationTask.cpp Outdated Show resolved Hide resolved
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
Copy link
Contributor

@flowln flowln left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(only noting the newlines :p)

this looks good to me, thank you!

launcher/minecraft/mod/tasks/LocalResourceParse.h Outdated Show resolved Hide resolved
launcher/minecraft/mod/tasks/LocalResourceParse.cpp Outdated Show resolved Hide resolved
Co-authored-by: flow <flowlnlnln@gmail.com>
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
@Ryex Ryex mentioned this pull request Dec 31, 2022
@Scrumplex
Copy link
Member

When you changed the process functions to return a bool instead of void, you also added checks to see if they returned the expected values. In principle, that's good, however maybe that's a bit too strict. For instance, suppose a resource pack doesn't have a pack.png file. It is a valid state, since it will just use the default image on the game, but when you check its result, and returns false from the entire processing of the resource pack, you make it so that the lack of an image is considered as a failure. Shouldn't that be changed, so that optional fields don't trigger this kind of failure?

any comment about this?

As long as other metadata checks out, it probably shouldn't fail if pack.png doesn't exist/is bad.

Copy link
Member

@Scrumplex Scrumplex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@flowln
Copy link
Contributor

flowln commented Jan 7, 2023

any comment about this?

As long as other metadata checks out, it probably shouldn't fail if pack.png doesn't exist/is bad.

they changed it already iirc, see here

@Scrumplex
Copy link
Member

Oh I see, I misread that code 👀

@Scrumplex Scrumplex merged commit f3f6284 into PrismLauncher:develop Jan 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CurseForge mods distributed as .zip get downloaded to the resourcepacks folder
3 participants