MODRINTH_PROJECTS doesn't work without MODRINTH_PROJECT being present

[douglasparker]

Describe the problem

I am not currently using a modpack, and MODRINTH_PROJECTS will not work without MODRINTH_PROJECT being present.

Using a fake slug does not fix this issue.

Container definition

services:
    minecraft:
      image: itzg/minecraft-server:java17
      container_name: minecraft
      environment:
        EULA: "TRUE"
        VERSION: "1.19.4"
        TYPE: "MODRINTH"
        MODRINTH_LOADER: "fabric"
        MODRINTH_DEFAULT_VERSION_TYPE: "release"
        # litematica was manually added due to need. Will be added to Modrinth in the near future.
        MODRINTH_PROJECT: "fake-slug"
        MODRINTH_PROJECTS: "-bedrock-plus,advancementinfo,adventurez,amecs,anti-xray,antighost,appleskin,areas,artifacts,auth-me,axolotl-buckets,bad-wither-no-cookie,bedrockify,bedrockwaters,better-enchanted-books,better-stats,betterend:beta,betterf3,betternether:beta,boat-item-view,borderless-mining,bosses-of-mass-destruction:beta,capes,carpet,carry-on,cem,cherished-worlds,chunk-loaders,cit-resewn,client-tweaks,comforts,continuity:beta,cosmetic-armor,crafting-tweaks,ctrl-q,cyberanner-ironchest,dark-waters,dcwa,dismount-entity,double-doors,dripsounds-fabric:beta,dynamic-fps,dynamiccrosshair,dynamiccrosshaircompat,edf-remastered,enchanting-infuser,entityculling,entitytexturefeatures,every-compat,fabric-api,fabric-seasons,fabricskyboxes,fabricskyboxes-interop,fabrishot,fallingleaves,fantasy-furniture,farmers-delight-fabric,fastanim,fastload,ferrite-core,feytweaks,fwaystones,gildedarmor,goated,grass-seeds,highlight,htm,immediatelyfast,indium,inventory-profiles-next,invmove:beta,iris,item-highlighter,jei:beta,just-enough-resources-jer:beta,krypton,lambdynamiclights,language-reload,lithium,log-cleaner,lostfeatures:beta,macos-input-fixes,make_bubbles_pop,mavm,memoryleakfix,midnightcontrols,mine-treasure,minecraftcapes,mixintrace,mob-captains,modmenu,mooshroom-tweaks,more-babies,morechathistory,moreculling,mouse-tweaks,move-boats,move-minecarts,netherportalfix,no-chat-reports,no-resource-pack-warnings,not-enough-animations,noxesium,optigui:beta,paladins-furniture,patchouli,presence-footsteps,random-village-names,reeses-sodium-options,skeleton-horse-spawn,smoothboot-fabric,sodium,sodium-extra,sodium-shadowy-path-blocks,sound-physics-remastered:beta,starlight,stendhal,superflat-world-no-slimes,supplementaries,terralith,tooltipfix,towns-and-towers,travelersbackpack,tree-harvester,universal-enchants,useless-reptile:beta,village-spawn-point,villager-names-serilum,visual-overhaul,visuality:beta,wavey-capes,weaker-spiderwebs,windchimes,yigd,yosbr,yungs-better-desert-temples,yungs-better-dungeons,yungs-better-mineshafts,yungs-better-nether-fortresses,yungs-better-ocean-monuments,yungs-better-strongholds,yungs-better-witch-huts,yungs-bridges,yungs-extras,zombie-horse-spawn,zoomify"
        MODRINTH_DOWNLOAD_OPTIONAL_DEPENDENCIES: true
        MEMORY: "12G"
      volumes:
        - ./minecraft:/data
      ports:
        - 0.0.0.0:25565:25565
      stdin_open: true # docker run -i
      tty: true # docker run -t
      restart: unless-stopped

Container logs

MODRINTH_PROJECT: missing

[init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 2 1000 1000 4096 May 20 22:43 /data'
[init] Resolved version given 1.19.4 into 1.19.4 and major version 1.19
[init] Resolving type given MODRINTH
[init] ERROR: MODRINTH_PROJECT is required to be set

MODRINTH_PROJECT: Fake slug

[init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 2 1000 1000 4096 May 20 22:43 /data'
[init] Resolved version given 1.19.4 into 1.19.4 and major version 1.19
[init] Resolving type given MODRINTH
[mc-image-helper] 22:45:14.921 ERROR : Invalid parameter provided for 'install-modrinth-modpack' command: Unable to locate requested project given ProjectRef(idOrSlug=fake-slug, versionType=null, versionId=null, versionName=null)
[init] ERROR failed to install Modrinth modpack

[itzg]

Hmm, you're basically conflating the two features, but the confusion is understandable since "modrinth project" is used in two similar but different ways.

• TYPE=MODRINTH, requires MODRINTH_PROJECT, singular, to reference a modpack located on the Modrinth website. (I don't yet have support for local mrpack or modrinth.index.json files.) In this case, the modpack is declaring the loader type and version to use. I should probably rename this variable MODRINTH_MODPACK_PROJECT. I avoided that at first because it felt like too much for people (i.e. me) to type.
• MODRINTH_PROJECTS, pural, refers to individual mod/plugin projects. In this case, you must declare the mod loader via TYPE, such as TYPE=FORGE, TYPE=FABRIC and the corresponding loader version variable...unless you're using both features were you bootstrap with a modpack and layer on more mods/plugins

So, with that explanation it feels like I need to at least fix up the modpack project variable name. Anything else you think would help clarify things?

[douglasparker]

Ah, that makes sense thank you!

So, with that explanation it feels like I need to at least fix up the modpack project variable name. Anything else you think would help clarify things?

I think there are three things that confuse people the most when reviewing the documentation:

1. TYPE variable can refer to mod loader type, but can also refer to Modrinth, CurseForge, etc.
2. Environmental variable names are sometimes confusing and different depending on TYPE
3. README.md is massive and overwhelming for new users.

• Point 1 can be cleared up with documentation, and / or a separate variable such as MOD_PLATFORM
• Point 2 could be cleared up by using more intuitive variable names and using the same variable names consistently. (Functionality would be based on TYPE MOD_PLATFORM or similar and the rest of the variables would be generic / abstract, i.e. no CF_* or MODRINTH_* variables.
• As for point 3, I just saw your comment in The README is massive. Consider moving configuration docs to their own files #2138. I will take a look at these docs going forward!

[itzg]

• Point 1 can be cleared up with documentation, and / or a separate variable such as MOD_PLATFORM

Good point that I have overloaded TYPE now. I like that idea of MOD_PLATFORM -- I might have it be an alias, but update the docs to refer to that new variable name.

• Point 2 could be cleared up by using more intuitive variable names and using the same variable names consistently. (Functionality would be based on TYPE MOD_PLATFORM or similar and the rest of the variables would be generic / abstract, i.e. no CF_* or MODRINTH_* variables.

I see what you mean, but I'll need to give this one some thought. I feel like the "namespace" variable prefixes have been helpful for me to troubleshoot reported issues.

• As for point 3, I just saw your comment in The README is massive. Consider moving configuration docs to their own files #2138. I will take a look at these docs going forward!

Be warned that the documentation content has drifted. Totally my fault for being lazy and not updating that other repo. As alluded to in that issue, I'm thinking of transplanting https://github.com/itzg/docker-minecraft-docs/tree/main/docs/java over to this repo so that PRs can address both code and docs as one reviewable unit. But that also feels like a "bad thing" and diminishes the beauty of one consolidated docs site. What are your thoughts there?

[douglasparker]

As alluded to in that issue, I'm thinking of transplanting https://github.com/itzg/docker-minecraft-docs/tree/main/docs/java over to this repo so that PRs can address both code and docs as one reviewable unit. But that also feels like a "bad thing" and diminishes the beauty of one consolidated docs site. What are your thoughts there?

I personally feel like it would work really well to combine the docs into this repository. It would still look really well within it's own subfolder docs/ and you can integrate it with PRs and GitHub Actions for deployment and/or PR checks.

[itzg]

Thanks! That feedback is very helpful.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please add a comment describing the reason to keep this issue open.

[itzg]

Documentation was updated and MOD_PLATFORM with an option for "MODRINTH". I believe this can be considered closed, but please comment if it needs to be re-opened.

[shampeon]

Just tried to use this according to the latest documentation, and I'm still getting an error that MODRINTH_PROJECT needs to be set.

docker-compose.yml fragment:

  minecraft-milo-mod:
    image: itzg/minecraft-server:latest
    restart: "unless-stopped"
    ports:
      - 25566:25565
      - 24454:24454
    volumes:
      - "/mnt/storage/minecraft/data/milo-mod:/data"
    stdin_open: true # docker run -i
    tty: true # docker run -t
    # Environment variables
    environment:
      EULA: "true"
      TYPE: FORGE
      VERSION: "1.18.2"
      DEBUG: "true"
      MOD_PLATFORM: MODRINTH
      MODRINTH_PROJECTS: "chipped, create, farmers-delight, essential, biomesyougo, rubidium, terrablender, create-steam-n-rails, simple-voice-chat"
      TZ: "America/Los_Angeles" # timezone
      ENABLE_WHITELIST: "true"

Error:

+ fixJavaPath
+ which java
+ cd /data
+ export ORIGINAL_TYPE=FORGE
+ ORIGINAL_TYPE=FORGE
+ isTrue false
+ case "${1,,}" in
+ return 1
+ isTrue false
+ case "${1,,}" in
+ return 1
+ [[ -n '' ]]
+ [[ -n '' ]
+ [[ -n '' ]]
+ [[ -n '' ]]
+ [[ -n '' ]]
+ : MODRINTH
+ case "${TYPE^^}" in
+ [[ -n MODRINTH ]]
+ case "${MOD_PLATFORM^^}" in
+ exec /start-deployModrinth
[init] 2023-08-12 15:31:20-07:00 ERROR: MODRINTH_PROJECT is required to be set
+ export HOME=/data
+ HOME=/data
++ id -u
++ id -g
++ ls -lnd /data
+ log 'Running as uid=1000 gid=1000 with /data as '\''drwxrwxr-x 4 1000 1000 11 Aug 12 15:17 /data'\'''
+ local oldState
++ shopt -po xtrace
+ oldState='set -o xtrace'
+ shopt -u -o xtrace
[init] 2023-08-12 15:32:20-07:00 Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 4 1000 1000 11 Aug 12 15:17 /data'
+ '[' '!' -e /data/eula.txt ']'
+ isTrue false
+ case "${1,,}" in
+ return 1
+ isTrue false
+ case "${1,,}" in
+ return 1
+ [[ -n '' ]]
+ [[ -n '' ]]
+ echo password=4637cf09d019540a2a8dcd3a
+ fixJavaPath
+ which java
+ cd /data
+ export ORIGINAL_TYPE=FORGE
+ ORIGINAL_TYPE=FORGE
+ isTrue false
+ case "${1,,}" in
+ return 1
+ isTrue false
+ case "${1,,}" in
+ return 1
+ [[ -n '' ]]
+ [[ -n '' ]]
+ [[ -n '' ]]
+ [[ -n '' ]]
+ [[ -n '' ]]
+ : MODRINTH
+ case "${TYPE^^}" in
+ [[ -n MODRINTH ]]
+ case "${MOD_PLATFORM^^}" in
+ exec /start-deployModrinth
[init] 2023-08-12 15:32:20-07:00 ERROR: MODRINTH_PROJECT is required to be set

[itzg]

Apparently the naming/documentation is still confusing. I think I am going to rename the MODRINTH_PROJECT (singular) to MODRINTH_MODPACK, which is required with MOD_PLATFORM: MODRINTH. I'll alias the variable so that it doesn't break existing configurations.

[itzg]

Latest image now uses MODRINTH_MODPACK as the input variable.