✅ | Modpack Update overlay

[crystal copper]

I am building a modpack update checker and need the exact .txt layout code. I am using the latest FancyMenu version (v3+).

My Goal:

I want a layout to only LOAD if the local modpack version is NOT EQUAL to the web version.

Technical Details:

• Local Source: config/fancymenu/modpack_version.json (Key: $.localVersion).
• Web Source: https://raw.githubusercontent.com/TylerBits/orb-meta/main/latest-version.txt.
• Variable 1: modpack_current_version (needs to pull from the JSON).
• Variable 2: orb-version (needs to pull from the web).

What I Need:

1. The layout-meta code for a "Layout-Wide Loading Requirement" using if_not + equals comparison between these two variables. Use the full JSON placeholder syntax as recommended in the v3 docs.
2. A Ticker element that successfully overwrites these two variables on launch.
3. Please clarify: Does the file path in the JSON placeholder require `` or just the path string?
4. If the layout fails to load (versions match), will the Ticker inside that layout still run to update variables for next time? If not, where should I put the Ticker?

Please provide the code in a copy-pasteable format for a .txt layout file.

[eager dew]

Hey Tyler, thanks for the detailed write-up! Since FancyMenu’s documentation doesn’t publish the exact .txt layout schema, I can’t drop in a guaranteed copy/paste file. But I can walk you through each piece and show you how to assemble it in the layout editor/exported file—then you can adjust the real .txt via the editor or by checking the file that FancyMenu saves when you hit Save.

1. Layout-Wide Requirement (load only when versions differ)

You’ll want a layout-wide loading requirement that uses the Is Text requirement in “OPPOSITE” mode (if_not), comparing the two variables. The requirement should look like this in the editor:

• Requirement: Is Text
• Comparison: equals
• Text value: {"placeholder":"getvariable","values":{"name":"modpack_current_version"}}
• Compare With: {"placeholder":"getvariable","values":{"name":"orb-version"}}
• Toggle the “OPPOSITE” mode (some UI label like “invert requirement”)

This ensures the layout only loads when the values differ.

When you save, FancyMenu serializes that into the layout .txt. You can inspect the exported layout (in config/fancymenu/customization/…) to see the exact layout_meta block it generated (the technical docs describe how the layout file stores requirements). Take that block and reuse it—it will look like what the editor writes.

If you want to hand-edit it, copy the serialized requirement block and set inverted = true (the exact property names should match what the editor uses).

2. Ticker that updates the variables

Add a Ticker element (preferably in a layout that always loads, like a universal layout or a layout with no failing requirements) and give it this action script:

1. Set Variable Value modpack_current_version:
   {"placeholder":"json","values":{"source":"/config/fancymenu/modpack_version.json","json_path":"$.localVersion"}}
2. Set Variable Value orb-version:
   {"placeholder":"webtext","values":{"link":"https://raw.githubusercontent.com/TylerBits/orb-meta/main/latest-version.txt","cache":"60"}}

Tick mode can be On Layout Load (or a small delay) so it runs every time the menu opens. The json placeholder pulls from your local file, and webtext fetches the plain text from the URL (both placeholders are documented in Placeholders).

3. Do JSON placeholders need extra ```` around file paths?

Nope—just provide the path as a normal string. Example:

{"placeholder":"json","values":{"source":"/config/fancymenu/modpack_version.json","json_path":"$.localVersion"}}

You don’t wrap the path in extra backticks; it’s just the string that points to the file (see the Resources and Placeholders docs).

4. What happens if the layout doesn’t load?

If the requirement says “don’t load when versions match,” the layout won’t load at all—so none of the elements inside that layout (including the Ticker) run. That’s why the Ticker must live in a layout that always loads (e.g., a universal layout without restrictive requirements), so it can refresh both variables before the version check runs. Then the check can live in the version-warning layout or wherever you need it to gate the rest of the UI.

---

📝 Actionable workflow:

1. Create a universal layout (no requirements) containing the Ticker that sets both variables via the placeholders above.
2. Create your version-check layout with the layout-wide “Is Text” requirement (in inverted mode) comparing modpack_current_version and orb-version.
3. After saving the layout, open config/fancymenu/customization/<layout>.txt to copy the generated layout_meta block and reuse it elsewhere if needed.

If you need the layout file reviewed or want a real human to double-check your URL/JSON file, please press the Request Human Help button—I can’t open links myself.

[crystal copper]

I have the layout ready, but I need to confirm two things before I relaunch:

1. Ticker Deadlock: If I keep the Ticker inside the 'update_checker.txt' layout, and that layout's Loading Requirement fails (hiding the layout), will the Ticker still run in the background to fetch new versions? Or MUST I move the Ticker to a different layout that is always visible?

2. Key Validation: In your last message, you used the key "link" for the webtext placeholder:
   {"placeholder":"webtext","values":{"link":"URL","cache":"60"}}
   In some docs, this key is "source" or "url". Can you double-check which specific key the latest v3 parser requires for the 'webtext' placeholder?

3. Inverting Logic: To confirm, is 'requirement_mode: if_not' the correct way to write "Hide if Equals" in the .txt file, or should I use 'requirement_mode: if' with a 'not_equals' comparison mode?

[eager dew]

1. Ticker deadlock: A Ticker only runs if the layout that owns it is actually loaded. When a layout’s loading requirements fail, the layout (and every element inside, including that Ticker) never gets created, so it can’t refresh the variables. Put the Ticker in a layout that is always enabled (e.g., a universal layout with no requirements) or in a helper layout that has no version check. The version-check layout can then rely on those variables without needing to run the Ticker itself.
   (See the “Requirements” doc on how loading requirements gate element visibility: Conditions (Loading Requirements).)

2. webtext key name: According to the current Placeholder reference, webtext expects link as the key for the URL. The cached example there is {"placeholder":"webtext","values":{"link":"https://example.com/textfile.txt","interval":"10"}}, so keep using link (and you can add cache or interval as additional options).
   (Reference: Placeholders → “Web Text (webtext)” section.)

3. Inverting the requirement: If you want “hide when variables are equal,” keep the comparison as equals but toggle the requirement into opposite mode (that’s serialized as requirement_mode = if_not). You don’t need not_equals; just use equals with the inverted flag. That matches how the editor handles “OPPOSITE” mode in IF blocks (see the toggle example).
   (See the “Toggle Parts of Layouts” guide where the requirement’s mode is set to “OPPOSITE,” which corresponds to if_not in the .txt file: Toggle Parts of Layouts.)

[crystal copper]

It also needs to change the variable if player joins a world

[eager dew]

You can keep that logic outside of any layout by using a listener instead—listeners fire even when layouts aren’t loading, so they’re perfect for “keep fetching the latest version” work.
Use a listener like On Singleplayer World Entered / On Server Joined (depending on whether you also want it for multiplayer) and give it the same action script you already use in your Ticker to update modpack_current_version and orb-version via the json/webtext placeholders. That way, every time the player joins a world or server the listener runs, updates the variables, and the version-check layout can react correctly when it finally loads.

See the Listeners doc for the available events and how to attach action scripts to them.

[eager dew]

Thread Marked as Solved

This support thread has been automatically marked as solved because there were no new messages for at least 24 hours.

If you still need help, feel free to continue the conversation or create a new support thread.

Marked automatically after 24h of inactivity