#✅ | 🙋 | placeholder doesn't work

1 messages · Page 1 of 1 (latest)

livid cradleBOT
#

I’m checking the FancyMenu docs on that placeholder behavior first, then I’ll compare it with any existing issue reports. Fingers crossed we can figure out what’s blocking the file copy 😅

#

I found one possible pitfall: the copy action may be parsing the path differently than expected, so I’m verifying the placeholder details instead of guessing 🙈 I’m checking whether last_world_server is even meant to return a usable file name in that exact spot.

#

Aha, I found a matching GitHub issue for this exact placeholder combo , it’s a known bug, not something you’re doing wrong 🙌 I’m pulling that into a clean workaround you can use right now.

#

Yep , this looks like a known FancyMenu bug, not a mistake in your syntax 😅

There’s already an issue for the exact combo you’re using: #1214.
It says last_world_server ignores full_world_path=false when type is set to both.

So in short:

  • type: "both" + full_world_path: "false" is broken right now
  • that’s why your copied file path doesn’t resolve the way you expect
  • the no-extension part is not the problem here

What you can do right now:

  • If you only need world names: use type: "world"
  • If you need world + server behavior, use two separate texts/actions instead of both
  • If you’re not on a dev build yet, updating FancyMenu may already fix it, since the issue is marked as fixed in dev

Example for world-only:

{"placeholder":"last_world_server","values":{"type":"world","full_world_path":"false"}}

If you want, I can help you rewrite the exact ticker action so it works with your file path 🙂

#

I’m checking whether this is a FancyMenu placeholder/path quirk or another known bug 🤔 I’ll look for similar reports and compare it with the docs so I don’t guess.

#

I checked for a matching GitHub issue and didn’t find a direct hit yet 🔎 I’m narrowing it down to whether the source-path placeholder itself is the problem or if it’s the file name/path resolution.

#

I found the docs page that describes file-copy actions and placeholder support 👍 The next thing I’m checking is whether the action expects a raw path expression there or if there’s a special parsing limitation on the source side.

#

Aha, I found the likely difference: world and both don’t behave the same if the last thing wasn’t a world 🎯 I’m just making sure I phrase the workaround cleanly so it matches the actual placeholder behavior.

#

Yep, that difference matters a lot 🙂

type: "world" and type: "both" are not the same:

  • world = only returns a world name
  • both = returns a world name or a server name

So if your ticker runs when you’re not actually in a singleplayer world, world can come back empty, and then your source path becomes something like config/mod/ instead of config/mod/<world name>.

A few important points:

  • I did check the docs/issue list, and I don’t see a note that files with no extension are unsupported.
  • The source path has to match the file exactly.
  • A destination folder can be created, but a source file must already exist at that exact resolved path.

So the first thing I’d try is using both in the source too:

config/mod/{"placeholder":"last_world_server","values":{"type":"both","full_world_path":"false"}}||saves/{"placeholder":"last_world_server","values":{"type":"both","full_world_path":"false"}}/folder/{"placeholder":"last_world_server","values":{"type":"both","full_world_path":"false"}}

If that works, then the problem was just that world was resolving to nothing in that moment.

If it still doesn’t work, the next best debug step is to print the resolved source path right before the copy action, so you can see whether FancyMenu is generating the expected filename or not. If you want, I can help you set up that exact debug test 👍

#

Got it , I’m re-checking this as a pure source-path resolution problem now 🧐 If the placeholder is both everywhere and it still fails, I want to confirm whether FancyMenu supports placeholders in the source half of a copy action at all.

#

I confirmed the copy action docs mention placeholder-style action values in general, and I still don’t see a special restriction on no-extension files 🧩 So I’m leaning toward the source file simply not existing at the resolved path, rather than the placeholder syntax being unsupported.

#

Gotcha , thanks for clarifying 🙈

If it’s both everywhere now and it still fails, then this is probably not the last_world_server bug from before.

What I can say with confidence:

  • The docs do support placeholders in action values generally.
  • I didn’t find any docs note that files with no extension are a problem.
  • So a file like config/mod/MyWorld is valid if that exact file exists.

That means the most likely issue is one of these:

  1. The placeholder resolves to a name that does not exactly match the file on disk
  2. The file is actually somewhere else, or named slightly differently
  3. The copy action is failing because the source path becomes invalid after placeholder expansion

The fastest way to isolate it is to test these two cases:

  • config/mod/test||... → works
  • config/mod/<resolved world name>||... → fails

If the second one fails, then the problem is almost certainly that the resolved value is not the exact source filename.

A very good debug test is:

  • print the resolved source path right before the copy action
  • compare that output to the actual file name in config/mod/

For example, log just:

{"placeholder":"last_world_server","values":{"type":"both","full_world_path":"false"}}

Then check whether that output is exactly the file name you expect, character-for-character.

If you want, send me:

  • the exact filename in config/mod/
  • the exact placeholder output you get
  • and whether you’re testing from a world or a server

…and I can help you narrow it down properly 🙂

#

<@&1365490168563372113>

Human Help Requested

@empty current has requested human assistance.

A human moderator will help as soon as possible.

Requested by krxl
#

🙋 | placeholder doesn't work

empty current
#

it was my mistake the file had a prefix i didn't see

livid cradleBOT
# empty current it was my mistake the file had a prefix i didn't see

Ahhh gotcha 😄 that explains it then.

So it wasn’t the placeholder at all , the source file name just didn’t match exactly because of the hidden prefix. Those little path/name details are so easy to miss 🙈

Glad you found it! If you want, I can still help you sanity-check the final ticker path so nothing else trips you up.

#

✅ | 🙋 | placeholder doesn't work