Troubleshooting

Punchy! says very little when a pack goes wrong. A file with a mistake is usually skipped without a message, and the game then draws the normal hands, so a pack can look as if it did nothing. This page takes the usual symptoms one at a time: a pack that does not load, a clip that does not play, a model part that does not show, particles that do not fire and an item that does not swing. Each one lists its causes from the most likely down, with the fix.

It is for players whose pack changed nothing and for pack makers whose files misbehave. The lists name the mistakes that make Punchy! drop a file without a word, so you know what to look for first.

Before you start

• The labels and behavior here are checked against Punchy! 3.0 for Fabric on Minecraft 26.3. Another version or loader can differ.
• Have logs/latest.log in your game folder at hand. It is the one place Punchy! writes a warning, and it does that only for clip files.
• Run your JSON through a validator before you test. Punchy! Studio checks it for you, as the last step below shows.
• Press F3+T after every change. Punchy! does not need a restart, except for a new particle picture or its frame count (see The look is wrong).

Start with these five checks

Video coming soon

Where to go for each symptom

What Punchy! drops without a message

Punchy! reads each kind of file in its own way. Clip files leave a warning in the log. Everything else is skipped quietly.

Some mistakes keep the file and throw away one value:

• A misspelled key. Punchy! ignores keys it does not know, in every kind of file.
• A kind key such as sword in lower case. Kinds under item are exact capitals, such as SWORD.
• A clip name written with other capitals than the clip has. It is another clip, which does not exist.
• A single number or a piece of text where a key needs three values. It is read as 0, 0, 0, or 1, 1, 1 for scale.
• A time key in timeline or sound_effects that is not a number. It is read as time 0.
• A loop value that is not true, "loop", "true" or "hold_on_last_frame". The clip plays once.
• A sound whose .ogg file is missing.
• A timeline token with extra text, such as disable_arm_tuning: true. It is a different text and matches nothing. The token is disable_arm_tuning.
• A particle key it does not know and a vector that does not have three parts. Both are ignored. A type that matches no picture is drawn with flame.png, or with the soul, smoke or ash picture when its name has soul, smoke, campfire or ash in it.

One file, three mistakes

This rule file looks fine, and it does nothing:

{
  "item": {
    "sword": {
      "customAnimation": [
        { "type": "attack", "name": "Test_Sword_Swing", }
      ]
    }
  }
}

The comma after the last member of the entry drops the whole file. Once that is fixed, sword is ignored because the kind must be SWORD. Once that is fixed, Test_Sword_Swing is not the clip test_sword_swing, so the moment plays its built-in clip. This is the file that works:

{
  "item": {
    "SWORD": {
      "customAnimation": [
        { "type": "attack", "name": "test_sword_swing" }
      ]
    }
  }
}

Test with a pack that works

When you cannot tell a game problem from a problem in your files, put your pack aside and build this one. It has three files and replaces the sword attack with a wide swing of the right arm.

If the arm swings, Punchy! and your pack setup are fine. Add your own files to this pack one at a time and reload after each. The one that stops the swing holds the mistake. If the arm does not swing, go through The pack does not load.

To see what a dropped clip looks like in the log, break this pack on purpose. In test_pack.animation.json, change "0.15": [-40, 20, -30] to "0.15": [-40, 20], so the key holds two values, save the file and press F3+T. The sword attack plays the built-in swing, and logs/latest.log has a line starting [Punchy] Could not load animation 'test_sword_swing'. Put the third value back and reload to get the arm swing again.

The pack does not load

Minecraft does not list the pack

• There is no pack.mcmeta next to assets. Minecraft needs it at the top of the folder or zip.
• The zip has an extra folder. Open the zip. pack.mcmeta and assets must be at the top, not inside a folder that holds them.

The pack is listed, and nothing changes

Check these in order.

1. The pack is not in Selected, or it is below Punchy!. For a clip or a rule that both define, the pack higher in Selected wins. A pack below Punchy! loses to it.

2. You did not reload. Press F3+T and wait a second.

3. A file is in the wrong folder. Folder names are exact and lower case. A folder called animation is not an error. Punchy! never looks in it.

   What	Where it goes
   Clips	assets/minecraft/punchy/animations/, any .json file, subfolders too. assets/punchy/animations/ is read as well, but Punchy! files those clips under the built-in Punchy! pack, so keep your own clips in the first folder
   Rules (compat files)	assets/minecraft/punchy/compat/ or assets/punchy/compat/, any .json file, subfolders too
   Model part definitions	assets/<namespace>/punchy/model_parts_items/definitions/, any depth
   Sounds	assets/punchy/sounds/animationssounds/<name>.ogg, and an event for each in assets/punchy/sounds.json (Studio writes the events for you)

4. A name Minecraft cannot read. A file or folder name with a capital letter, a space or another character a resource id cannot hold is skipped by Minecraft itself, so Punchy! never gets it. Use lower case letters, digits, _, - and ..

5. The pack format does not cover your game. Minecraft marks a pack whose pack_format, min_format and max_format do not fit your version as made for an older or a newer version, and asks before it loads it. The table on Resource packs has the numbers. Punchy! Studio writes them for you.

6. Something is applied after the packs and wins. Punchy! applies things in this order, and a later step overrides an earlier one where both set the same thing:

   1. The rule files of all packs, merged. The higher pack wins each field.
   2. config/punchy/punchy_tuning.json, the tuning you saved, only when no tuning profile is active.
   3. Your choices in Mix Packs.
   4. The active tuning profile from config/punchy/profiles/.

   On Minecraft 26.2 the active tuning profile comes before your Mix Packs choices, and the positions it sets stay. So a choice you made in Mix Packs, a profile you saved in the Hand Editor or an old punchy_tuning.json can hide a pack. A customGroups name saved in punchy_tuning.json does nothing, because only a rule file registers group names. In the Hand Editor, Reset To Default removes the saved tuning and deactivates the active profile. In Mix Packs, Use resource pack order clears every choice. See Mix the packs and Tuning editor and debug.

7. Punchy! is off, or the item is left alone. With Enable Punchy OFF the game draws your hands the vanilla way. An item in the Item Blacklist never animates. The switches table lists the settings that can do this.

8. You are not in first person. Punchy! animates your own first person hands only.

Punchy: resource pack disabled

A window with this title opens the first time you attack, mine, use an item or inspect in first person while no active pack gives Punchy! a rule file or a first-person clip. It says Punchy! found neither in your active resource packs. Turn on the built-in Punchy! pack, or another pack made for Punchy!, in Options, Resource Packs, then press F3+T.

Your settings went back to the defaults

A mistake in config/punchy/punchy_config.json makes Punchy! write a new file with the default settings. Keep a copy before you edit it, and edit it with the game closed. See Settings and controls.

My clip does not play

A clip needs three things: the pack, the clip file and a rule that names the clip. Work through the questions in this order.

Is the clip loaded?

• The file is not in a clip folder. Clips are read from assets/minecraft/punchy/animations/ in every selected pack, from any .json file at any depth. Use that folder for your own pack: clips in assets/punchy/animations/ are read too, but filed under the built-in Punchy! pack.
• The log names the file. A line starting [Punchy] Could not read animations from pack means the file is not valid JSON, or its top level is not an object. The file gives no clips until you fix it. The error under the line often points at the place where reading stopped.
• The log names the clip. A line starting [Punchy] Could not load animation names one dropped clip. The usual causes are a key that does not have exactly three values, a Molang expression that does not compile, a time key that is not a number, a bones, bone or timeline that is not an object, and an animation_length that is not a number.
• There is nothing in the log, and still no clip. Either the file has no animations object, or the clip’s value is not an object, or the file is not in a selected pack. Punchy! stays silent about all three.
• Two clips have one name. The clip from the pack higher in Selected wins as a whole. Punchy! never mixes the bones of two clips. Do not count on either of two files in one pack that hold the same clip name. Rename one. Studio’s Library says whether Punchy! plays this pack’s copy of a clip or another pack’s.
• The clip has no length. Without animation_length the length is 0. Walk, sprint, jump, fall and landing clips of length 0 are ignored. Give every clip a length that fits its last key.

Does a rule play it?

A clip file alone plays nothing. A rule in a compat file has to name it. Punchy! does not report a rule that finds nothing, and a rule file with a mistake is dropped whole. Check these in order.

1. The rule file was dropped. See the table above. Studio’s Bindings workspace reports Punchy would ignore this file and gives the reason.
2. The kind is not exact. Keys under item are the exact capital names of the kinds, such as SWORD or PICKAXE. A lower case sword is ignored. A custom group name has to match a customGroups entry exactly.
3. The item id is wrong. Keys under itemSpecific are item ids in lower case with their namespace, such as minecraft:iron_sword. A key that is not a valid lower case id is dropped. An items list inside an entry holds item ids and #tags. A custom group name there never matches.
4. The type is wrong. type is matched after it is put in lower case and _, - and spaces are removed, so use_bow, useBow and usebow are one type. A misspelled type matches nothing, and nothing is reported.
5. The clip name is wrong. Names are case sensitive. For an attack combo, var_1, var_2 and var_3 are used in turn, and name only when all three are blank. For a single clip, animation is read first, then name, then var_1. A name that matches no clip is not reported. The moment plays its built-in clip instead, when one is loaded.
6. A list replaced yours. An item’s own customAnimation list replaces its group’s list as a whole, and an empty list does too. Types missing from it are filled from default_animations. Copy the types you still want into the item’s list.
7. Two entries became one. When a default_animations list is also in play, entries with the same type and key in one list can collapse into the last one. Give them different key values.
8. Another pack’s rule wins. A lower pack adds an entry only for a type the higher pack does not have. If the higher pack has an attack entry for SWORD, yours is not used. Studio’s Effective tab shows the winner.
9. Something saved beats the pack. See the order of what is applied after the packs, in The pack is listed, and nothing changes. A setup you loaded in Mix Packs is applied again at every reload, so a pick you made after loading it goes back to the setup’s choice when you press F3+T. Click Save as… with the same name to keep the pick, or pick Current choices in the setup list. See Setups.
10. A condition is not met. An entry with items, in_water, inside_water, block_detection, weather_detection, time_detection or biome_detection plays only when every one of them holds. A variation plays only when all of its conditions pass, and the highest priority wins.
11. A more specific entry wins. Entries of one type are sorted by their selectors: items counts most, then each of the world conditions above counts one. Entries with the same score keep their order in the list.

Does the moment happen?

• Walk, sprint, jump, fall and landing. These play only when Resource Pack Movement is ON on the Movement tab. It is OFF by default. A move with no clip keeps the built-in movement, and a fall clip plays only after a drop of more than 3 blocks.
• A bow release. A use_bow_shot entry must exist, or nothing plays on release. The draw must reach a power of 0.1, and you need an arrow or creative mode.
• A key animation. A triggerable entry needs a key, or it never reaches the Controls screen. A key name that Punchy! does not know gives no default key. The key the player chose in Controls always beats the pack’s key. Entries with the same id share one binding, so the first one’s title and key are used.
• An idle clip. It plays only while no other clip, swim, walk on water, mining or use is playing. Set loop to true, or it plays once.
• An inspect clip. It plays when you press the Inspect key, I by default, and only with no screen open.
• The wrong moment. Studio’s Test tab, with Play in Game, plays your clip the way a chosen action would, at Punchy!‘s real speed. Its trace says how Punchy! picked the clip.

It plays, but not as you expect

• It is too fast to see. Without an anim_speed_ token, most clips play at the Animation Speed setting, 5.5 times faster than authored by default. Add anim_speed_1; to the timeline at time 0.0. The token takes values from 0.5 to 5.5. Bow, crossbow, shield, trident and swim clips already play at their authored speed. Equip clips always do.
• A token does nothing. Tokens are exact text, split on ; and put in lower case. disable_arm_tuning is a token and disable_arm_tuning: true is not. The item switch tokens that hide an item need an underscore and an id or a star, as in hide_right_switch_item_*.
• The combo starts over, or the next swing waits. An attack combo plays var_1, var_2 and var_3 in turn. It goes back to var_1 after more than 30 ticks without an attack, or when the number of clips in the combo changes. A new attack clip also waits about 5.7 ticks after the last one started. An entry with "trigger_on_input": true and combo names plays on the input and skips that wait.
• A clip from Blender turns the wrong way. A clip made with the Punchy Blender add-on uses the older key layout, so leave use_keyframes_v2 out of its timeline. With it, a turn about Y or Z plays 9 to 11 degrees off. The steps are in Create an animation.
• The camera does not shake. Put the keys on the camera bone, and check that Enable Camera Animations on the General tab is on. The keys move your view in legacy clips and in clips with use_keyframes_v2 alike. On Minecraft 1.21.11 even a shake of half a degree shows. On the other versions a turn of the bone reaches your view only when it is bigger than about 1.6 degrees or the bone also moves, so make a gentle shake a little stronger.
• The left hand plays the right hand’s clip. Punchy! never mirrors a clip. To give a hand its own clip, name a second clip with _left or _right at the end of the name. The side of the hand that plays wins, then the bare name.
• A sound is silent. The file must be assets/punchy/sounds/animationssounds/<name>.ogg, and the name in sound_effects must match the file name exactly. Keep the file name in lower case, as Minecraft requires. Minecraft also needs an event for the sound in assets/punchy/sounds.json, and Studio writes it when it exports a sound. A clip that plays once plays every sound keyed on it, one at the very end included. A sound placed at time 0 plays when the clip starts, also in a clip that blends in from the current pose, and again each time a looping clip wraps.

For the full lists, see Why a clip does not play and Things that stop a rule working.

My model part does not show

Punchy! reports none of these in the game. A model part with a mistake often just disappears, and the normal item is drawn. Open Studio’s Model Parts Library (Ctrl+O in the Model workspace). It lists every definition in your loaded packs in Punchy!‘s order, and says for each item whether it is rendered, shadowed by another definition, blocked by a named one or never matching.

Video coming soon

The definition is dropped

Punchy! checks a definition when it loads the resources and removes the whole file for any of these:

• The file is in the wrong place. Definitions are read only from a definitions folder under assets/<namespace>/punchy/model_parts_items/.
• The JSON cannot be read, or the top level is not an object.
• There is no item. There is no items and no item, items is an empty list, or it holds only blank text. When items is present, item is ignored.
• There is no geo, or no texture, or the id is not a valid resource id. A capital letter in an id is enough.
• A value has the wrong JSON type. Examples are a display entry that is not an object, a rotation or translation that is not a list of numbers, a texture_anim count that is not a number, an items that is text instead of a list, and a field of a modelPartsAnimation entry of the wrong type, such as "items": "minecraft:lantern".

Fix the file and press F3+T. In Studio, the Lint panel on the Definition tab names the reason with Punchy drops this definition.

The definition is kept, but the normal item is drawn

• The geometry file is missing or cannot be read. Punchy! does not check the file when it loads the definition. The definition still claims its items, draws nothing and hides every later definition for them. A geometry with no minecraft:geometry list, no bones or a bone with no name does not load.
• The geo id is not complete. It is used exactly as written, so write the whole id with the ending: mypack:punchy/model_parts_items/geo/baton.geo.json. The ids in animations are used as written too, so they end in .animation.json. A texture id may leave out .png.
• Another definition sorts first. Pack order does not decide. Punchy! sorts definitions by their full id as text, namespace first and capitals ignored, and uses the first one that matches the held item. Studio can put your definition first in the order when you export it.
• A named definition is in play. A definition with a customName beats every unnamed one when the stack carries that name. When a named definition exists for an item and your stack does not match its name, no unnamed definition is used and the normal item draws.
• The item does not match. Bare ids get the minecraft namespace. A #namespace:tag entry matches every item with that tag. An entry that cannot be read is skipped, so a typo shows as no match.
• You are using the item. While you eat, drink, draw a bow or block with a shield, Punchy! draws the normal item instead of your model. The model stays when the definition has an animation entry of a use type (useItem, useEat, useDrink, use_bow, use_bow_shot, use_crossbow, use_crossbow_shot, spear_charge or use_shield) or a using state model.
• Punchy!‘s own renderer goes first. A held chest, boat, raft, minecart, piston or enchanting table is drawn by Punchy! before model parts get a turn.
• You look at it in third person or the inventory. Model parts draw in your own first person hands only.
• The whole system is off. Resource Pack Model Parts on the Items & World tab is OFF, or disableResourcePackModelParts is true in config/punchy/punchy_config.json. Press F3+T after changing it.

It draws, but not as you meant

• A cube is missing. Every cube needs origin and size. Give it a uv object with the faces you want, each with uv and uv_size. The faces are north, south, east, west, up and down, and only the faces you list are drawn. A uv object with no usable face drops the cube.
• Only some cubes show. Once any cube has a uv object, a cube with the short [u, v] form is not drawn. A model made only of short form cubes does draw, but without glow, bone textures, particles or bone physics.
• The texture looks stretched or shifted. Punchy! scales the UV by texture_width and texture_height of the geometry, 64 by 64 when they are missing, never by the size of your PNG. The geometry reads them from description when that object exists, and from the top level only when it does not. A UV past the edge is clamped to the edge, not repeated.
• The model is the wrong size or in the wrong place. The file is in pixels, 16 to a block, and the X axis is mirrored. Build the model around the middle and use display to fit it to the hand. Rotations are in degrees and translation is divided by 16.
• The texture is missing or wrong. Punchy! does not check at load that the file exists. It adds .png when the id has none, and puts textures/ in front unless the path already starts with textures/ or punchy/model_parts_items/textures/.
• A texture animation stands still. The PNG must be exactly frames times the frame height tall, and frames must be more than 1. A mismatch stops the animation without a message.
• A bone does not glow. The name in bone_emission must match the bone exactly. A bone named blur, clamp, strength, intensity or brightness cannot glow. Levels from 1 to 15 set how bright the glow is, and 15 is full brightness. Levels from 16 to 100 glow at full brightness and add bloom only when blur is on. strength set to 0 also turns the glow off.
• The clip does not move it. An entry that names a clip that does not exist plays the idle clip instead, when the part has one. Bone names in a clip must match the geometry exactly. See Item clips.
• A bucket does not change. See Why my bucket does not change.

The complete lists are in Things that stop a model part from showing and Things that make Punchy! skip your model.

Particles do not fire

The emitters of a definition run while its model part is drawn, so if the part is not showing, start with My model part does not show. Emitters in a compat rule file also run on an item that has no model part.

Nothing appears

1. Particles are off. Enable Particle System on the Effects tab is OFF. Every emitter is reset and none emits.
2. Punchy! never reads the emitter. In a definition, the keys are particle, particles, particle_effects, particle_emission and particleEmission. particle_emitters is read only in compat rule files, in item and itemSpecific entries. An emptyHand entry has no particles.
3. A more specific list replaced yours. For an item, the compat list comes from the most specific itemSpecific entry that has particles, from a match on the item’s name and custom model data down to the plain item id (matching enchantment variants add their emitters to it), and only then from the group. A more specific list replaces the lower ones, and does not add to them. The definition’s own list is added in front of whichever list wins.
4. The emitter was dropped. "enabled": false removes it. An empty particle() makes none. A bare word that is not a valid id makes none. An object whose keys are all ignored makes none.
5. It spawns nothing. A count of 0, a chance of 0 or a t of 0 spawns no particle.
6. A clip silences it. The active animation entry has "disable_all_particles": true.
7. The picture is not found. See The look is wrong.

It fires at the wrong times

• It fires 20 times a second. An emitter with no triggers, no rate and no emit_interval releases count particles every game tick. Add chance, a rate or an emit_interval.
• A rate is ignored. An emitter whose triggers are only jump, landing, attack, use or a clip moment fires once per event and never uses rate or emit_interval. Add a continuous trigger such as walking to get a stream. mining is both a pulse and continuous.
• It never fires with two pulses. Several triggers on one emitter must all be true at the same time by default. jump and landing never are, because landing needs the ground and jumping needs the air. Add "trigger_mode": "any", or split the triggers into separate emitters.
• My triggers are ignored in a definition. In a definition, triggers must be an object with named flags, such as { "walking": true }. A list there is ignored and the emitter is always on. The list form is for compat rule files. A compat list means any of the names. A list whose names are all misspelled leaves the emitter always on.
• An empty triggers object, or an on_animation with only a name, leaves the emitter always on. Give it a flag, or a name and a timecode.
• use_item does nothing in the object form of a definition. Write it as a flat key, trigger_use_item, or use a script string.
• A walking, sprinting, swimming or falling emitter stays quiet. Walking is true on the ground while you move and do not sprint or swim. Sprinting needs movement too. Swimming is true in water. Falling needs a fall with downward speed, and min_blocks raises the distance it needs.
• The clip moment never fires. on_animation_name must match a clip that plays, in any capitals: an item clip of the model part, or the arm clip of a customAnimation entry. on_animation_timecode is in seconds into that clip. On an item clip, a timecode of 0 does not fire when the clip starts, so use a time after 0.
• It stopped for good. An emitter with emit_for stops after that many seconds of its own age. Editing its text or pressing F3+T starts it again.
• It spawns too much. Each event spawns at most 120 particles, and a rate is capped at 120 a second.

The look is wrong

• The picture is not the one you wrote in type. type does not spawn the vanilla particle. It chooses the picture. With no texture, Punchy! looks for the type’s own particle definition, then textures/particle/<type>.png or <type>_0.png, then a guess by name (soul, smoke, campfire or ash), then flame.png.
• A new picture does not show. Punchy! remembers a texture it did not find, and it remembers how many frames a strip has. F3+T does not clear that. Restart the game after you add the file or its frames.
• An animated particle does not move. The base file ends in _0, the frames count up with no gap to _63, and the texture id ends in _0. A particle pinned with lock_in_model never animates.
• There is no glow. Check these:
  • fullbright, full_day_light or bright_at_dark is on. fullbright is on by default, except for types with leaf or leaves in the name and for particles with bright_at_dark on, unless you write fullbright yourself.
  • For fullbright and full_day_light, Enable Model Parts Glow is ON. full_day_light also glows only in daylight, in a level that has sky light.
  • emissive_strength is above 0.
  • light_percent is not set, or it is 100.
  • A bright_at_dark particle does not need Enable Model Parts Glow, but it does need Enable Blur Glow At Dark ON on the Effects tab.
• The glow keys are ignored in an object. emissive_strength, emission_strength, emissive_blur, emission_blur, emissive_clamp and emission_clamp are ignored in object form. Write them in a particle(...) script string, or use the short keys emissive, strength, blur and clamp.
• A script breaks. In a script string a comma ends a pair. Write a vector with colons, as in offset=0:0.2:0, and a list of blocks or biomes with | between the names.
• It appears at the hand, not at the bone. A bone name that matches no bone puts the emitter at the hand position instead of dropping it. Check the spelling and the capitals against the geometry.
• A list of three became a vector. In an object, a list of exactly three values is read as x:y:z. Write block and biome lists as one text joined with |.

Studio’s Particles tab shows the default of every key. Its Trigger Test panel toggles walking, sprinting, swimming and falling, fires jumps, landings, attacks, mining and uses, and says which emitters would emit now.

Video coming soon

The long list is in Things that go wrong on the Particles page.

An item does not swing

Held items swing as pendulums, driven by turning the camera, walking, jumping and landing. An item that is standing still does not move, so test by turning and jumping.

The whole item

1. Item physics are off. Enable Item Physics on the Items & World tab is OFF. The pendulums stop, and so does the slime wobble.
2. The item has no mode. An item swings only when a physics entry gives it FULL_PENDULUM or FORWARD_PENDULUM. Punchy!‘s own rules do that for lanterns. NONE means no pendulum. The names are not case sensitive, but they must be spelled out. full and forward work only in bone physics.
3. The entry is ignored whole. In a group, pattern or itemSpecific entry, a physics object whose name is not a valid mode is ignored with its settings. A physics object with settings and no name does nothing.
4. The keys are not read. The physics object takes camelCase names: limitDeg, limitDegUp, limitDegDown, force, speed, cameraSens, gravity, motionSens, invert and handSpace. limit_deg and the other snake case names are ignored without a message.
5. A pose changed the mode. A pose you write for one hand has its own physics, as text, and the pose decides that hand’s mode. Write physics in the pose or in the entry that holds it. An object in the physics of a pose drops the whole rule file.
6. The limits hold it still. A limit of 0 on both sides holds the swing still. limitDegUp written alone leaves the down limit at 55, not at limitDeg.
7. A clip pauses it. While a clip with the token disable_pendulum or disable_pendulum_physics plays on the arm, the swing is suppressed.
8. A profile or saved tuning sets the same item. See the order in The pack is listed, and nothing changes.

Single bones of a model part

1. The bone spec has no effect. A bone entry in bone_physics is kept only when it has enableCreaturePhysics, enableSlimePhysics or a pendulum mode. Limits and percentages alone are dropped. The mode is read from pendulum_mode, pendulumMode, pendulum or physics_mode, and the first one that is not NONE wins. Here full and forward are valid.
2. The bone is named wrong. Bone names are case sensitive and must match the geometry. A bone with no spec of its own uses the nearest parent’s spec.
3. The bone is switched off. A bone listed in disable_physics_bones, or whose parent is, gets no item physics. The list in the active animation entry replaces the definition’s list, even when it is empty.
4. The model is made of short form cubes. A model that uses only [u, v] cubes draws without bone physics. Give each cube a uv object.
5. The feedback pose does nothing. physicsFeedback works only on models shaped like an axolotl: bones head, body or body_root, and legs_front or leg1.

Studio’s Physics Test Rig drives a virtual player that turns, walks, sprints, jumps, drops and kicks, and draws the swing of each pendulum as a graph.

Video coming soon

The long list is in Things that stop a swing.

An item vanished or sits in the wrong place

• A pose has no scale. A pose without scale is scaled to 0, so the item is drawn at size 0 and cannot be seen. Write "scale": 1.0 in every pose.
• The right and left shorthand sits in the wrong place. It works under a kind key or a custom group key, only when transforms is absent. It is not read in itemSpecific entries, and a pattern entry loses it. Put the poses under transforms.
• The kind is not what you think. A kind written in an itemSpecific entry must be in exact capitals. A lower case value is ignored, and the item’s own kind is used. A pattern entry with no kind and a key that is not a kind turns its items into INGREDIENT.
• A saved profile or tuning moves it. Check the order above, then try Reset To Default in the Hand Editor. See Tuning editor and debug.
• Your arms disappear when you look down. If you have the First Person Model mod, see the FAQ.

Switches that hide a pack’s work

Each of these settings can make a working pack look broken.

Settings and controls lists every row of every tab.

Report a bug

If you still cannot find it, ask in the Punchy Discord. The Help & Support tab of the F8 menu has a Discord row and a Report a bug (Discord) row, each with an Open button, and both open the same invite. A report is easier to answer when it has:

• The Punchy! version, the Minecraft version and the loader. The Copy debug info row on the Help & Support tab puts them on the clipboard, together with the settings you changed, so you can paste them into your report.
• The packs that are in Selected, in order, and the other mods that touch first person, such as Better Combat or First Person Model.
• The file that does not work, or the line of it, and what you expected to see.
• logs/latest.log from after a F3+T reload, or at least the lines that contain [Punchy].
• What Studio’s checks say, if you use it: the Check for Problems list, the Bindings Effective tab or the Lint panel.

Related pages

• Resource packs has where each file goes and which pack wins.
• Create an animation takes a clip from nothing to playing in game.
• Animation types and triggers lists every moment a rule can play a clip for.
• Compat rules explains rule files and what drops one.
• Model parts covers definitions, geometry, item clips and particles.
• Item physics covers pendulums and bone physics.
• Mix the packs and Tuning editor and debug cover the saved choices that can override a pack.
• Punchy! Studio runs the checks used on this page.
• FAQ answers the short questions.
• Punchy! Moves troubleshooting is the page for the third person mod.