✅ | nine-slicing issue

[tawny oasis]

I have a button with a 1px border, but setting the nine-slicing pixels to 1 does not actually change the top and left side sizes for some reason.

[onyx thunder]

Hi! Please first select which type of question you want to ask:

• "Normal Question" is enough for most questions. If you are unsure, you should choose this mode. It provides quick and accurate answers to your questions and problems.
• "Complex Task" is for very complex questions and multi-step tasks. For example, questions involving complex action script, requirement, or placeholder logic. Normal users will almost never need this. Getting answers takes much longer here.

It is not possible for anybody to send messages in this thread before selecting a mode.

Selected mode: 💬 Normal Question

[onyx thunder]

Yep, in FancyMenu, nine-slicing doesn’t change the button’s border sizes by itself 🤔

It only tells FancyMenu which parts of the texture should stay fixed and which parts can stretch. So a 1px border will only really matter if:

• you’ve enabled Nine-Slice Custom Background
• you set both border values to 1
  • X borders = left/right
  • Y borders = top/bottom
• the button is actually being resized bigger than the source texture

If the button is basically the same size as the texture, you usually won’t notice a difference.

Also, nine-slicing does not change things like label padding or anchor positions, it’s only for how the texture scales 🧩

If you want, send me:

• a screenshot of the texture
• a screenshot of the button’s Button Textures settings
• and your /logs/latest.log grabbed right after testing

Then I can tell you whether it’s a settings issue or something else 🙂

[tawny oasis]

image 1) Button textures as they appear in the menu
image 2) the settings for the button

[onyx thunder]

Yeah, that’s actually expected behavior with nine-slicing in FancyMenu 😅

The important bit from the docs is: the nine-slice values are the “cut points” inside the texture, not a way to resize the visible border itself. So a 1 means “keep the outer 1 pixel on that side fixed.”

That means:

• if your PNG already has a 1px border, setting the slice to 1 won’t make that border look smaller
• it also won’t magically change the visible top/left edge thickness
• if the border still looks thick, the texture itself is probably thicker than 1px, or the other button states use different textures/settings

A couple things to double-check:

• set the same nine-slice values for Normal, Hover, and Inactive
• make sure the actual PNG border is really 1px wide
• if you want a different visible border thickness, you need to edit the image itself, not just the nine-slice values

So in short: nine-slicing controls stretching, not the border’s actual pixel thickness 🧩

If you want, I can also help you figure out whether your texture is being sliced correctly from the screenshot you sent.

[tawny oasis]

I was able to set the border sizes correctly, but the middle isn't showing correctly

[onyx thunder]

Ahh gotcha, in that case the center part is probably being stretched as intended, but the texture content in the middle doesn’t hold up when scaled 😅

With FancyMenu nine-slicing, the middle area is meant to be the “stretchable” part. So:

• corners stay fixed
• edges stretch in one direction
• middle stretches in both directions

That means if your button has anything detailed in the center, it can look weird, blurry, or distorted when the button gets resized. Nine-slicing is best when the middle is just a flat fill, gradient, or simple pattern.

If you want the middle to:

• look the same everywhere → make the center area simpler in the PNG
• repeat instead of stretch → nine-slicing is the wrong tool; you’d want a tiled texture approach instead
• stay crisp while resizing → give the center more empty/simple space in the source texture

Also make sure all 3 states use the same slice setup:

• Normal
• Hover
• Inactive

If you want, send me one thing:

• does the middle look like it’s being stretched, blank/transparent, or shifted?

And if it still seems wrong after that, please grab your /logs/latest.log right after testing and send it too 🙏🙂

[tawny oasis]

The middle seems to lose its gradient

[onyx thunder]

Yep, that’s the part that usually happens with nine-slicing 😅

The docs basically describe the middle as the part that gets stretched in both directions. So if your button’s center contains a subtle gradient, it can end up looking flatter or “washed out” once it’s scaled.

In other words: with nine-slicing, the center is not meant to preserve fine detail perfectly. It’s best when the middle is:

• flat
• simple
• or a broad gradient that still looks okay when stretched

So if the gradient is important, the usual fix is to make the gradient area in the PNG a bit larger / simpler so it still looks good when stretched. If it’s a tiny, delicate gradient, nine-slicing will probably distort it a bit.

Also worth noting: button textures support nine-slicing, but not texture tiling like image elements/backgrounds do, so there isn’t a “repeat the gradient instead of stretching it” option for buttons in the docs.

So short version:

• Yes, that’s expected behavior
• Nine-slicing stretches the middle
• Fine gradients in the center can look off
• Best fix is to redesign the texture so the middle is more stretch-friendly 🎨

If you want, I can help you tweak the texture layout so the gradient keeps looking nice without losing the button borders 👍

[tawny oasis]

Please assist, I'm not sure what the nine-slicing is considering the "center" of my button here

[onyx thunder]

Yeah, totally, the “center” in nine-slicing can be a little confusing at first 😅

Think of your button texture like a 3x3 grid:

• top-left / top-right / bottom-left / bottom-right = corners
• top edge / bottom edge / left edge / right edge = borders
• the middle square = the stretchable center

So if your borders are set to 1, then FancyMenu treats:

• the first 1 pixel from the left as the left border
• the first 1 pixel from the top as the top border
• the last 1 pixel from the right as the right border
• the last 1 pixel from the bottom as the bottom border

Everything in between is the center.

Example:
If your texture is 20x20 and borders are 1, then the center is basically the 18x18 area in the middle.

For the button, that center is the part that gets stretched in both directions. So if your gradient lives inside that center area, it will get resized too, which is why it can look like the gradient is fading or flattening out.

A good way to picture it:

• corners stay exact
• edges stretch only along one axis
• center stretches both ways

So if you want the gradient to keep looking nice, the easiest fix is usually:

• make the center area simpler
• use a bigger, softer gradient
• or put the interesting gradient mostly in the parts that won’t get heavily stretched

If you want, I can help you figure out the exact center area from your texture size. Just tell me the PNG dimensions, like 18x18 or 20x20 🖼️😊

[tawny oasis]

That worked, thank you!

[onyx thunder]

Ayy awesome, glad that fixed it 😄🎉

If you run into anything else with FancyMenu stuff, just drop it here and I’ll help you out 💙🛠️

[tawny oasis]

I do have another question: how to animate on hover? The element animator and I don't get along.

[onyx thunder]

Yep, and honestly, the docs don’t really show a true one-click “start animation when hover begins” feature for normal elements 😅

The clean workaround is to use Is Element Hovered from the Requirements system and swap between two versions of the element:

1. Make a normal version of the element.
2. Make a second copy that has the hover animation on it.
3. Put the animated copy under an Element Animator.
4. Add an Is Element Hovered requirement to the animated copy, using the ID of the element you want to hover over.
5. Keep the normal copy visible when that requirement is false.

So basically:

• not hovered = normal element
• hovered = animated element shows instead 🎛️

If you’re only trying to do a simple hover change, like:

• color change
• texture change
• label change

…then a button’s built-in hover texture/state is way easier than using the Animator.

If you want, tell me what kind of hover effect you want exactly:

• grow bigger
• slide a bit
• fade in/out
• rotate
• glow/pulse

…and I’ll map out the simplest FancyMenu setup for that 🙂

[tawny oasis]

I want the hovered element to kind of bounce/slide smoothly up

[onyx thunder]

Yep, if you want a smooth little hover lift without fighting the Element Animator, the cleanest workaround is to drive the Y position with a variable 😄

A simple setup is:

1. Create a variable like hover_progress

   • start it at 0

2. Give the element Advanced Positioning for Y

3. Add a Ticker that checks whether the element is hovered

4. In that ticker:

   • if hovered, increase hover_progress a bit each tick until it reaches 1
   • if not hovered, decrease it back down to 0

5. Use hover_progress in the element’s Y position:

   • normal_y - (hover_progress * 4) or * 6
   • keep the movement small so hover doesn’t flicker

A rough example of the logic:

• hovered: move toward 1
• not hovered: move toward 0

Then your Y position becomes something like:
base_y - (hover_progress * 6)

That gives you the smooth slide-up feel without needing the Animator at all 🎮

A couple tips:

• use a small lift, like 3 to 6 pixels
• if it starts losing hover because it moves away from the cursor, reduce the distance a bit
• if you want it to feel softer, use a shorter ticker delay and smaller variable steps

If you want, I can write you the exact Ticker action script + the exact advanced Y position expression for your button size and position 🛠️🙂

[tawny oasis]

Please write up the action scripts, thank you!

[onyx thunder]

Absolutely, here’s a simple smooth hover-lift setup that does not use the Element Animator at all 😄

Use one variable, one Ticker, and advanced Y positioning.

1. Create a variable

• Name: hover_progress
• Initial value: 0

2. Add a Ticker element

• Set the tick delay to something like 20–40 ms
• Put this action script on the ticker

IF: Is Element Hovered -> my_button_id

  Set Variable Value
  hover_progress:{"placeholder":"minnum","values":{"first":"1","second":"{"placeholder":"calc","values":{"decimal":"true","expression":"{"placeholder":"getvariable","values":{"name":"hover_progress"}} + 0.15"}}}}

ELSE

  Set Variable Value
  hover_progress:{"placeholder":"maxnum","values":{"first":"0","second":"{"placeholder":"calc","values":{"decimal":"true","expression":"{"placeholder":"getvariable","values":{"name":"hover_progress"}} - 0.15"}}}}

Replace my_button_id with the actual element ID of the thing you want to hover over.

3. Use hover_progress in the element’s Y position
   If your normal Y position is, for example, 80, set the Y field to:

{"placeholder":"calc","values":{"decimal":"false","expression":"80 - ({"placeholder":"getvariable","values":{"name":"hover_progress"}} * 6)"}}

That gives you a smooth lift of up to 6 pixels.

A couple quick tweak tips:

• smaller step value like 0.08 = smoother but slower
• bigger lift value like 8 = more noticeable bounce
• if it feels too snappy, lower the 0.15 step

If you want, I can also write you a slightly more “bouncy” version with a tiny overshoot effect too 🙂🧩

[tawny oasis]

That somehow managed to cause a complete catastrophic crash of my game, and I'm going to need to go into the actual menu text file to fix it because even attempting to edit it in-game locks everything up again. No idea how I managed that one.

[onyx thunder]

Oof, that’s rough 😵‍💫💥

First things first: please make sure you’re on the latest builds of:

• FancyMenu
• Konkrete
• Melody
• your mod loader
• Fabric API, if you’re on Fabric

Then I need your /logs/latest.log file grabbed right after the crash happened. That’s the important bit, if you can send that, I can actually see what went wrong.

If you don’t send the log, I can’t help debug this properly 🙏

Also, if you can, tell me:

• your Minecraft version
• your mod loader
• your FancyMenu version
• what exact action script/layout you added before it started crashing

If the game now locks up every time you open that menu, we can work from the log to figure out what part needs to be removed or fixed 🛠️🙂

[tawny oasis]

Minecraft 1.20.1, Fabric loader 1.18.6, Fancymenu 3.9.0 (although I just swapped it to 3.9.1). As far as I know, I followed all of your directions for scripts.

[onyx thunder]

Oof 😵‍💫 that sounds like a hover feedback loop, not just a normal “bad animation” setup.

The most likely problem is:

• the ticker is checking if the element is hovered
• while the same element is being moved by hover_progress
• so the hover target keeps moving under the mouse and the screen can end up constantly re-processing itself

That can absolutely hard-lock the editor/menu.

The safer fix is to split it into 2 parts:

1. a fixed, invisible hover detector
2. a visible element that actually moves

That means: don’t use the moving element itself as the thing that gets checked by Is Element Hovered 🧩

A safer setup looks like this:

1. Create a transparent “hitbox” element

• same size/position as the button
• no movement
• no visual texture, or fully transparent texture
• this is only for hover detection

2. Keep your visible button/image separate

• this is the one that moves up smoothly

3. Use a Ticker to update hover_progress

• if the hitbox is hovered, move hover_progress toward 1
• otherwise, move it toward 0

4. Use hover_progress only in the visible element’s Y position

If you want, I can write the exact safe action scripts for that split setup next, just tell me the element type you’re moving:

• button
• image
• text
• something else

And if the layout is still locking up right now, I’d stop editing that broken version and restore/remove the last hover-ticker setup first 🔧🙂

[tawny oasis]

Let's try the element animator, how do I get it to play a 'rise' animation when hovered, and then a 'lowering' animation when the hover stops?

[onyx thunder]

Yep, the clean way is to use two animators, because the docs only give us play-state controls like enable, disable, and reset, not a reverse-play action 😅

So the setup is:

• hover_rise animator = plays from “down” to “up”
• hover_lower animator = plays from “up” to “down”
• a small invisible hover detector element
• a ticker that starts the right animator when hover changes

1) Make the two animators

Create two Element Animators:

hover_rise

Keyframes:

• start: normal/resting position
• end: raised position

Example:

• 0 ms → normal Y
• 120 ms → Y lifted up a few pixels

hover_lower

Keyframes:

• start: raised position
• end: normal/resting position

Example:

• 0 ms → lifted Y
• 120 ms → normal Y

Important:

• turn off looping on both
• make both animate the same visible target element
• don’t make the hovered detector itself move

2) Add a fixed hover detector

Make a separate invisible element:

• same size/position as the thing you want to hover
• no animation
• this is the element the hover check uses

Let’s call its ID hover_hitbox.

3) Create a state variable

Add a FancyMenu variable:

• name: hover_state
• value: false

This prevents the animators from restarting every tick.

4) Add a Ticker

Set a small delay, like 20–40 ms.

Use this action logic:

IF Is Element Hovered -> hover_hitbox

  IF Is Variable Value -> hover_state:false
    Set Variable Value -> hover_state:true
    Reset Element Animator -> hover_rise
    Enable Element Animator -> hover_rise
    Disable Element Animator -> hover_lower

ELSE

  IF Is Variable Value -> hover_state:true
    Set Variable Value -> hover_state:false
    Reset Element Animator -> hover_lower
    Enable Element Animator -> hover_lower
    Disable Element Animator -> hover_rise

5) Make it feel bouncy

If you want the “rise” to feel more alive, use a tiny overshoot in the keyframes of hover_rise, like:

• 0 ms → normal
• 80 ms → slightly above the final position
• 120 ms → final raised position

And for lowering, mirror that in reverse.

Why this works better

Because the hover detector stays still, hover doesn’t keep changing while the element moves. That avoids the nasty feedback loop that can freeze things up 🫠

If you want, I can also sketch the exact keyframe timings for a nice “soft bounce” hover, like a smooth little pop-up instead of just a slide.

[onyx thunder]

Thread Marked as Solved

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

The AI helper is now disabled. If you still need help, please create a new support thread.

Marked automatically after 24h of inactivity