#βœ… | listen for totem uses

1 messages Β· Page 1 of 1 (latest)

pale trellisBOT
#

Hi Kcat36! πŸ‘‹

That's a super cool idea for a custom display! You can definitely do this using FancyMenu's new Listeners feature.

Here's how you can set it up:

  1. Listen for the Totem Use Event:

    • You'll want to use the On Item Consumed listener. This listener fires when the player finishes consuming an item.
    • You can then check if the consumed item is a totem of undying. You can do this with a condition in the listener's action script, using something like the Is Text requirement to check if $$item_key (the consumed item's identifier) contains "totem_of_undying".
  2. Start a Countdown Timer:

    • Once the totem use is detected, you can use the Set Variable Value action to set a FancyMenu variable to a starting time (e.g., set totem_cooldown to 60 for 60 seconds).
    • Then, you'll need a Ticker element to decrement this variable over time. Have the Ticker run every 1000 milliseconds (1 second) and use the Set Variable Value action combined with the Calculator placeholder to subtract 1 from totem_cooldown each tick, until it reaches 0.
  3. Display the Timer:

    • Finally, use a Text element in your layout and display the totem_cooldown variable using the Get Variable Value placeholder: {"placeholder":"getvariable","values":{"name":"totem_cooldown"}}.

It might sound like a few steps, but once you get the hang of variables and listeners, it's quite straightforward!

You can find more information about Listeners here: Listeners
And about Variables here: Variables
And here's some info on Action Scripts, which you'll use for setting variables and conditions: Action Scripts

versed moat
#

how can i use is text for that again?

pale trellisBOT
# versed moat how can i use is text for that again?

To use the "Is Text" requirement for checking the totem, you'd integrate it within your listener's action script! 😊

Here's a detailed breakdown:

  1. Create Your Listener: Go to menu bar -> Customization -> Manage Listeners and create an On Item Consumed listener.
  2. Edit the Listener's Action Script: After creating the listener, you'll be able to manage its action script.
  3. Add an "IF Statement": Inside the action script, you'll want to add an "IF Statement" to check the consumed item.
  4. Configure the "IF Statement" with "Is Text":
    • For the condition of this IF Statement, select the Is Text requirement.
    • When configuring the "Is Text" requirement, you will set these specific values:
      • text: $$item_key (This is the special listener variable that holds the identifier of the item that was consumed.)
      • mode: contains (You want to check if the text contains "totem_of_undying", not necessarily that it equals it, in case there are other parts to the item ID.)
      • compare_with: totem_of_undying

So, the full JSON for the "Is Text" requirement value would look something like this in the action script editor:

{"mode":"contains","text":"$$item_key","compare_with":"totem_of_undying"}

This IF Statement will then only execute the actions nested inside it if the consumed item's key contains "totem_of_undying". Inside that IF block, you'd place your action to start the countdown timer variable!

You can find more about the "Is Text" requirement here: Conditions (Requirements)

versed moat
#

for the calculator, how do i even use that lol?

pale trellisBOT
# versed moat for the calculator, how do i even use that lol?

No worries at all! The Calculator placeholder can seem a little tricky at first because it uses an expression, but it's super powerful once you get the hang of it. Think of it like a mini-calculator right inside FancyMenu! βž•βž–βœ–οΈβž—

Here’s a simple way to use it for your countdown timer:

You'll set your Ticker element to run every second and update your totem_cooldown variable. The action script for that Set Variable Value action would look something like this:

totem_cooldown:{"placeholder":"calc","values":{"expression":"{"placeholder":"getvariable","values":{"name":"totem_cooldown"}} - 1","decimal":"false"}}

Let's break this down:

  1. totem_cooldown:: This is the name of your variable that you want to update.
  2. {"placeholder":"calc", ... }: This tells FancyMenu to use the Calculator.
  3. "expression":" ... ": This is where you put your math!
    • {"placeholder":"getvariable","values":{"name":"totem_cooldown"}}: This nested placeholder first gets the current value of your totem_cooldown variable.
    • - 1: Then, it subtracts 1 from that current value.
  4. "decimal":"false": This tells the calculator to return a whole number (an integer), which is perfect for counting down seconds!

So, every time this action runs (thanks to your Ticker), it grabs the current cooldown value, subtracts one, and saves that new value back into totem_cooldown!

You can find more examples and details about the Calculator and other placeholders here: Placeholders

Let me know if that helps, or if you'd like to walk through another example! 😊

versed moat
#

the if statement isnt working, but the ticker is

pale trellisBOT
# versed moat the if statement isnt working, but the ticker is

Oh no, that's not ideal! Let's get that IF statement working for you.

When an IF statement isn't triggering correctly but the action script around it (like the Ticker) is, it usually means the condition in the IF statement isn't being met as expected.

Since we're trying to detect if a consumed item is a totem, let's double-check how you've set up the Is Text requirement inside your listener's action script.

Could you please tell me:

  1. What does the full value of your Is Text requirement look like? (It would be the JSON string you entered when editing the requirement's value).
  2. Are there any other requirements in that same IF statement?
  3. Are you sure the On Item Consumed listener itself is firing? (You could test this by putting a simple Print to Game Log action right before your IF statement, with $$item_key as the message, to see what value it gets when you consume an item).

Sometimes, for item IDs, there might be slight variations depending on the Minecraft version or mod setup (e.g., minecraft:totem_of_undying vs. just totem_of_undying). Using contains mode should help, but it's good to confirm the exact string.

Once I have a bit more detail about your Is Text setup, we can debug it together! 😊

versed moat
#

for text i have: $$item_key
Compare to text: totem_of_undying

pale trellisBOT
# versed moat for text i have: $$item_key Compare to text: totem_of_undying

Thank you for that information! That's exactly what I needed.

Based on what you've provided:

  • text: $$item_key
  • compare_with: totem_of_undying

This setup looks correct, assuming the mode for the Is Text requirement is set to contains, as we discussed.

Let's try a quick diagnostic step to figure out why your IF statement isn't triggering:

Could you temporarily add a Print to Game Log action immediately before your IF statement in the listener's action script?

  • Set its value to: Consumed item: $$item_key

Then, go into a world and consume a totem of undying. After that, check your Minecraft latest.log file (located in your instance's /logs/ folder).

What does the log say for Consumed item: ...? Knowing the exact string that $$item_key resolves to when you consume the totem will help us confirm if totem_of_undying is the right text to compare against.

It's possible the game reports the item key with a prefix like minecraft:totem_of_undying, and while contains should usually catch that, it's always best to verify the exact output! 😊

versed moat
#

Consumed item: $$item_key isnt working for print to game log

pale trellisBOT
# versed moat Consumed item: $$item_key isnt working for print to game log

Aha! Thank you for testing that, Kcat36. That is a very important clue!

If Consumed item: $$item_key isn't printing the actual item key to the log, it means that the $$item_key listener variable might not be available or correctly populated for that specific On Item Consumed event in your version of FancyMenu, or at that exact point in the action script.

This is a scenario where we need to be a bit more robust in catching the item ID.

Here's a revised approach to make sure we're correctly getting the item key:

Instead of relying on $$item_key directly in the Print to Game Log (or Is Text requirement), let's explicitly capture the item ID into a FancyMenu variable first. This ensures the data is correctly processed and available for subsequent checks.

Here's how to modify your listener's action script:

  1. Add a Set Variable Value action at the very beginning of your On Item Consumed listener.

    • Set its value to: current_consumed_item_id:{"placeholder":"slot_item","values":{"slot":"-1"}}
    • Explanation: The slot_item placeholder with a slot value of -1 is designed to retrieve the item that was just consumed by the player. We're storing this value in a new FancyMenu variable named current_consumed_item_id.
  2. Now, modify your Print to Game Log action (for debugging):

    • Set its value to: Captured item: {"placeholder":"getvariable","values":{"name":"current_consumed_item_id"}}
    • Test this again by consuming a totem. This should now print the item ID to your log.
  3. Finally, update your Is Text requirement in the IF statement:

    • Change the text field from $$item_key to: {"placeholder":"getvariable","values":{"name":"current_consumed_item_id"}}
    • Keep mode: contains and compare_with: totem_of_undying

So, your IF statement's "Is Text" requirement value would effectively become:

#
{"mode":"contains","text":"{"placeholder":"getvariable","values":{"name":"current_consumed_item_id"}}","compare_with":"totem_of_undying"}

This way, we're first explicitly getting the item ID into a variable, and then the Is Text requirement can reliably check that variable's content.

Please let me know if this helps your Print to Game Log action work, and then if the IF statement starts triggering! 😊

versed moat
#

update, it worked for something other than a totem. are you sure totems are supported by the consumed action?

pale trellisBOT
# versed moat update, it worked for something other than a totem. are you sure totems are supp...

That's excellent diagnostic work! If it worked for another item but not the totem, you've pinpointed a crucial detail.

You're absolutely right to question if totems are supported by the On Item Consumed listener in the way we're thinking. Totems of Undying aren't "consumed" in the traditional sense like food or potions; they activate automatically when certain conditions are met (taking fatal damage). This automatic activation might not trigger the On Item Consumed event in the game's internal systems, or if it does, it might do so differently.

Given this, the On Item Consumed listener is likely not the correct event to track totem usage.

We need a different approach for detecting totem activation.

Unfortunately, based on the current available listeners, there isn't a direct "On Totem Used" or "On Player Revive" listener. However, we can use a clever workaround by monitoring a key player statistic: Absorption Hearts.

When a totem activates, it grants the player two absorption hearts (gold hearts). This is a unique and temporary effect that we can listen for!


Here's the revised strategy:

#
  1. Use an On Player Gained Absorption Hearts Listener or a Ticker combined with Has Player Absorption Hearts condition.

    • Option A: Dedicated Listener (if available in your FancyMenu version): Check your Manage Listeners for anything like "On Player Gained Absorption Hearts". This would be ideal.
    • Option B: Ticker + Condition (more reliable across versions):
      • Create a Ticker element that runs very frequently (e.g., every 50ms, or even less).
      • This Ticker will have an IF Statement with the condition Has Player Absorption Hearts.
      • Inside this IF Statement, you'd then check if a variable you've set (let's call it totem_active_already) is false. This prevents the timer from starting multiple times if absorption hearts persist for a moment.
      • If Has Player Absorption Hearts is true AND totem_active_already is false, then you know a totem (or a similar effect) just kicked in.
  2. Start Your Timer and Set a Flag:

    • Inside the logic where you detect the absorption hearts, set your totem_cooldown variable (e.g., to 60 seconds).
    • Also, crucially, set a flag variable, for example, totem_active_already to true. This flag prevents the timer from resetting or restarting multiple times during the absorption heart duration.
  3. Reset Your Flag When Absorption Wears Off:

    • You'll need another part of your logic (perhaps another listener or another ELSE IF in the Ticker) to detect when Has Player Absorption Hearts becomes false again.
    • When absorption hearts are gone, set totem_active_already back to false so it can detect the next totem usage.

This method focuses on the effect of the totem activation rather than a "consumption" event that might not fire for totems.

#

Let's explore Option B (Ticker + Condition) as it's more universally applicable. Would you like me to walk you through setting up that Ticker logic to detect the absorption hearts? 😊

versed moat
#

gapples would also do that, it's not viable

pale trellisBOT
# versed moat gapples would also do that, it's not viable

You are absolutely right, Kcat36! Golden apples also grant absorption hearts, which makes that particular approach not viable for exclusively tracking totems. My apologies, that was an oversight on my part.

This highlights the challenge with detecting very specific, context-dependent game events in a client-side mod like FancyMenu without a direct API hook from the game or mod loader for "totem used."

Let's rethink this from a different angle. If there's no direct listener for totem "use" and absorption hearts are ambiguous, we need to consider other unique aspects of totem activation:

  1. Death Screen / Player Death: Totems prevent death. If the On Death listener fires, it means a totem did not prevent death, or it was some unusual circumstance. We need the opposite – a near death event.

  2. Health Threshold / Damage Taken: This is where we might have a viable, albeit still slightly indirect, method.


New Approach: Monitoring Health and Damage

This method will be more complex and involve several parts, but it leverages FancyMenu's conditions and actions to infer totem usage. It won't be 100% perfect for every single edge case (e.g., if you have multiple mods that also grant instant health regeneration under 1 HP), but it should work for most typical totem activations.

The core idea:

  • Listen for player taking damage.
  • If player's health drops very low (e.g., 0.5 heart), and then rapidly increases without regeneration effects, it strongly suggests a totem.

Here's a conceptual outline (this will be involved!):

#
  1. Monitor Player Health and Damage (using a Ticker):

    • Create a Ticker element, running frequently (e.g., every 50-100ms).
    • This ticker will continuously update two variables:
      • last_known_health: Stores {"placeholder":"current_player_health"}
      • health_at_last_tick: Stores the value of last_known_health from the previous tick. (This requires a bit of variable juggling: save last_known_health to health_at_last_tick before updating last_known_health).
  2. Detect a Critical Health Drop:

    • Inside the Ticker's action script, use an IF Statement.
    • Condition: Is Number.
      • mode: smaller-than-or-equals
      • number: {"placeholder":"current_player_health"}
      • compare_with: 0.5 (or whatever low health you'd consider critical for totem activation)
    • Inside this IF block, set a variable: player_was_critically_low_health:true.
  3. Detect a Sudden Health Recovery (the "Totem Inference"):

    • Add an ELSE-IF statement in the Ticker, after the critical health drop check.
    • Condition (combining multiple checks with AND logic):
      • Is Variable Value (FM Variable): name: player_was_critically_low_health, expected_value: true
      • Is Number (compare health gain):
        • mode: bigger-than
        • number: {"placeholder":"calc","values":{"expression":"{"placeholder":"current_player_health"} - {"placeholder":"getvariable","values":{"name":"health_at_last_tick"}}","decimal":"true"}} (This calculates health gained since last tick)
        • compare_with: 2 (Meaning, did health go up by more than 2 hearts instantly?)
      • Is Number (optional: no active regeneration effect): This would be very complex to check reliably, but you could try detecting common regeneration effects.
#
  • If all these conditions are met (critical health -> sudden large health gain):
    * This is our "totem activated!" point!
    * Set totem_cooldown to your desired timer (e.g., 60).
    * Set player_was_critically_low_health:false (reset for next detection).
    * Optionally, print a debug message: Totem inferred to be used!.

Why this is complex and might have limitations:

  • False positives: Other mods providing instant, large health boosts or invulnerability might trigger it.
  • Timing: The ticker sensitivity needs to be high enough to catch the rapid health change.
  • Variable management: Requires careful sequencing of variable updates to get last_known_health and health_at_last_tick correct.

This is pushing the boundaries of what FancyMenu is designed for directly, but it's an interesting challenge!

Before we delve into the intricate variable management for capturing health over time, are you still interested in pursuing this path? Or is there perhaps a simpler, more direct listener I might be overlooking for a different player state related to totems? (For example, if a mod like Fabric's CustomDeathMessages gave a specific message for totem revivals, On Chat Message Received could be an option).

versed moat
#

last question, can you link how to do animated textures?

pale trellisBOT
#
Thread Message Limit Reached

This support thread has reached the maximum limit of 20 messages. To continue getting support, please start a new thread by asking your question in the #fancymenu-help channel.

Creating a new thread will help keep conversations organized and ensure you get the best support possible.

#

βœ… | listen for totem uses