FAQ

How do I update SnPets?

Download the newer snpets-v* release and replace the jar. config.yml, the language files and the menu layouts auto-merge on restart, so new keys appear while your values and comments stay. Your pets/ folder and your traits.yml, boost-grades.yml and boxes.yml files are never overwritten.

Updating to 1.4.0 also moves your boxes/ folder into a single boxes.yml automatically - see the question about boxes-migrated/ below.

Can players skip the trait and boost roulette animation?

Since 1.12.0 they do better than skip it: they switch it off once, on the button at slot 8 of the traits and boosts menus, and the choice is saved on their own row so it holds across relogs and restarts. Roll Animation: Off shows the result at once, with the same reveal sound, the same chat line and the same redraw. It can never change what came out, because the roll is decided and saved before the first frame would have been drawn.

The click-to-skip 1.3.0 put on the spinning cell is retired - the setting replaced it. Both templates (anim-on, anim-off) merge into your guis/boosts.yml and guis/traits.yml on the first boot after the update. See The roll animation switch for what happens to the old click-actions block on your spinning template.

The switch covers the two roulettes only: a pet box keeps its own animation: block in boxes.yml, and a roulette you turned off with traits.roll.enabled: false or boosts.roll.enabled: false stays off for everyone regardless.

Can I style the three boost roll buttons separately? And where does the roulette spin?

Since 1.21.0, yes: guis/boosts.yml declares one template per button - roll-stat-experience, roll-stat-level and roll-stat-buff - instead of the old shared roll-stat, so each is restyled on its own. The boost roulette also moved: it plays on the stat cell(s) the roll is deciding (the new stat-spinning template) - one cell for a single-stat button, all three for Roll Every Boost - and never on the pet cell. See Where the boost roulette spins.

I updated to 1.12.0. Does anything happen to my database?

Yes, once, and it needs nothing from you. snpets_players gains one column, roll_animation, which is where each player's answer to the question above is kept. It is the first schema migration this plugin has ever needed, and it runs on the boot after the update: right after the tables are created, before any player row is read, on SQLite and MySQL alike.

Every player who already has a row keeps the animation on, which is what they had. Nothing else on the row is touched, no row is rewritten, and a boot that finds the column already there does nothing at all - so a downgrade and a re-upgrade are both uneventful. If the migration cannot run, the plugin refuses to enable and says so in the console rather than running against a table it cannot read, exactly as it already does when a table cannot be created.

A player unequipped the pet in slot 2 and the others moved. Is that a bug?

No, that is 1.3.0's behaviour. Equipped pets are kept in slots 1..n with no gap, so the free slots are always the last ones. The order of the pets is unchanged and the formation around the player looks exactly the same; only the slot numbers shift. An unequip performed while the player is OFFLINE leaves the gap until they next log in, where it is closed automatically.

How do I colour a pet's menu lines by its group?

Give the group a color: in config.yml and use {group-color} in the menu templates. See Configuration for the full recipe. Existing configs do not receive the new key: until you add one, {group-color} reuses the colour codes that group's display already starts with.

I wrote {group-color} in menus.boost-line and it printed literally. Why?

Because before 1.8.1 that fragment was formatted without it. The boost lines are built one by one and then handed to the pet cell as the single {boosts} value, and a placeholder value is never scanned again for placeholders, so the cell's own {group-color} could not reach inside them. 1.8.1 resolves the colour while the line itself is being built. The line you already edited starts working on the next boot: only the COMMENT above the key changed in the shipped file, your value is kept.

The same release binds {group-color} on the boosts menu's three stat cells and four roll buttons. It still does not exist on menus.grade-row, menus.group-separator or the menus.trait-effect-* lines, which describe a ladder rung or a trait rather than a pet.

My box has [rgb] in its display-name and chat shows the tag instead of the gradient.

Fixed in 1.8.1. [rgb] is a prefix tag: SnLib reads it at the START of a finished line, and a box or pet name spliced into a message as {box} or {pet} sits in the middle of one, so the tag was left as text (The [rgb]Basic Pet Box failed to open...) while the ITEM, whose name IS the whole line, rendered fine. Both boxes.yml and pets/<id>.yml now have their display-name tags applied when the file is read. Nothing to change on your side - those files are seed-only and are not touched.

After updating to 1.2.1 my empty bulk delete buttons are still grey glass. Why?

Because the merge adds missing keys but never overwrites a value your file already carries, and that material is a value. Open guis/bulk_delete.yml, set templates.group-empty.material to "{icon}", and restart. Deleting the file and restarting reseeds the whole thing instead. New installs already ship the fixed value.

A player picked a pet in Boosts, closed the menu and it was still picked. Is that fixed?

Yes, since 1.2.1. Closing every SnPets menu forgets the pick, while moving between menus keeps it. It is driven by the close-actions key each guis/*.yml now carries; the key merges in on the first boot after the update.

Can I run an admin command without telling anyone?

Yes. Add -s to skip the message the target player would get, -sf to skip your own confirmation, or both, in any order:

/pets admin give Bob ember_fox 3 5 -s -sf
/pets admin givebox Bob basic 10 -s
/pets admin clear Bob all -sf

-sf only hides confirmations of things that WORKED. If the command is refused - a full storage, a pet that does not exist, an unknown box - or if a query fails, you are told regardless. Silence under -sf therefore means "it worked", never "something went wrong and you missed it".

Put the flags at the END of the line. Anything typed after the first flag is ignored, so /pets admin give Bob ember_fox -s 5 gives one pet rather than five.

My players never used to be told when I gave them a pet. Did that change?

Yes, in 1.5.0. /pets admin give, /pets admin givebox and /pets admin giveallbox now send the receiver a line of their own - messages.pet-received and messages.box-received, both new keys in lang/messages_<code>.yml. They are merged into your existing lang file automatically on the first boot after the update, so you can restyle or blank them like any other message, and you can suppress them per command with -s. /pets admin currency already worked this way and is unchanged. Offline players are never messaged.

My pets changed shape after updating to 1.6.0. What happened?

1.6.0 added formation.shape, which picks the curve the arc is cut from. CIRCLE is the old behaviour: every pet sits formation.radius blocks out. OVAL keeps radius at the owner's SIDES and uses the new formation.back-radius straight behind them, so the arc hugs the owner's back and opens out at the flanks.

config.yml is managed, which means SnLib inserts the two new keys into your existing file but never overwrites a value you already had. So your server became an OVAL with your own old radius at the sides and 1.4 blocks behind.

In practice that is a very small change, because a 180-degree arc puts its two ends exactly on the owner's sides, where an oval and a circle coincide. With the old arc-degrees: 180, one pet and two pets do not move at all, and from three pets up nothing moves more than 0.2 blocks. Set formation.shape: CIRCLE and run /pets reload to pin the old look exactly.

Two behaviours are worth knowing before you keep the oval. The pets take an even share of the angle, which is an even spacing on the ground only on a circle - on an oval the ones near the ends bunch up (about 23% at four pets, 28% at six; one, two and three pets are unaffected). And formation.facing: OUTWARD / CENTER point along the circle's radius rather than the oval's true normal, off by up to 10 degrees; that costs nothing under the default OWNER_YAW, which ignores the angle entirely.

An unknown value is not fatal: the plugin logs one warning per load and falls back to CIRCLE. An absent value falls back to CIRCLE silently - that is deliberate, and it is what keeps a config written before 1.6.0 on its old circle. So deleting the key does not restore OVAL, it gives you CIRCLE.

I updated to 1.6.0 but my pets are still the old size and height. Why?

Because that is deliberate. 1.6.0 also changed the SHIPPED defaults - formation.radius 1.6 to 2.0, height-offset 0.35 to 1.9, arc-degrees 180 to 190, facing-offset 0 to 180, animation.head-size 0.7 to 1.3 and the bounce to 0.06 / 0.1 - but a managed file only ever gains missing KEYS, never new VALUES. A new install gets the new look; an existing one keeps every number you set. Copy the values above into your config.yml by hand if you want it.

One to watch: models.height-offset is SUMMED with formation.height-offset. A BetterModel pet that should stand on the ground wants roughly the negative of whatever formation.height-offset is on your server - about -1.9 if you adopt the new 1.9, but still about -0.35 if you kept your old value. Copying -1.9 onto a server that never adopted 1.9 sinks the model about 1.55 blocks into the floor.

Can I announce only SOME fusions?

Yes, since 1.6.0. config.yml's fusion.broadcast is now only the DEFAULT. Any pet can override it in its own pets/<id>.yml:

fusion:
  into: gale_sprite
  chance: 35.0
  cost: 25000
  broadcast: true

The flag belongs to the PARENT - the pet being consumed, the one whose file declares into - so you announce a fusion by writing the key on the pet players fuse AWAY, not on the one they get. Leave the key out and that pet follows the global setting. pets/ is seed-only, so no pet file you already have receives the key on update: everything keeps following fusion.broadcast until you write it yourself.

On a fresh install the two shipped pet files already set it - stone_golem.yml has broadcast: true and ember_fox.yml has broadcast: false - and seed-only means they stay that way. So turning the global on will not make Ember Fox announce; edit or delete the key in its file for that. A value that is present but not a boolean (broadcast: 1, where yes and on would have worked) reads as false and logs a warning naming the file.

Fuse All never announces, whatever any pet file says. It rolls per pair and would otherwise post one line for every winning pair.

How do players trade pets with each other?

Since 1.7.0, by turning the pet into an item. In the main menu, shift + right click a pet in the storage grid - or, since 1.11.0, press Q over it, the drop key, Ctrl+Q included: it leaves the storage and becomes a player head in the player's inventory, wearing that pet's own texture and carrying its whole state - pet type, level, experience, trait and the three boost grades. A right click with that head puts the pet into the clicker's storage, with everything it had. Hand it over, drop it, put it in a chest, or sell it on a shop plugin: the head is an ordinary item.

Since 1.17.0 the head also remembers WHO took it out, and only that player can redeem it - see Can somebody else redeem my pet item? below.

Nothing is destroyed by a refusal. A redeem into a full storage, into a profile that is still loading, in creative mode while allow-creative is off, or with the feature switched off hands the item straight back with its state intact. Taking a pet out is refused - and the pet is left exactly where it was - when it is EQUIPPED (unequip it first), when its pets/<id>.yml is gone, or when the player has no free inventory slot. A pet is never dropped on the floor to make the click work.

The head is not placeable, so clicking a block with it can never place it and destroy the pet on it, and boxes.blocked-blocks applies to the redeem click too - clicking a chest opens the chest.

Both triggers run the same action with the same refusals. pet-items.enabled: false switches the whole feature off, both triggers at once, and leaves the heads already in circulation redeemable.

Can somebody else redeem my pet item?

Not since 1.17.0, if the head was taken out on 1.17.0 or later. Extracting a pet now stamps the head with your UUID and your name; a player who right clicks a head that is not theirs is refused with messages.pet-item-not-yours, which names the owner, and the head goes back into their inventory untouched. Nothing is destroyed and nothing is consumed.

The UUID is what the lock matches on, never the name. Changing your nick does not cost you your pets, and a player who takes your old nick does not gain them.

There is no config switch for this: an item with no owner tag is free and an item with one is locked, which is the whole rule. Redeeming your own head works exactly as before, and the pet it creates belongs to whoever redeemed it - so a player who redeems a head and later takes the same pet out again is stamped as its owner in their turn.

How does somebody claim a pet item that is not theirs?

With an ownership scroll, added in 1.18.0. Hand one out with /pets admin givescroll <player> ownership [amount], then have the player pick it up onto their cursor and left or right click the pet head in their own inventory. The head becomes theirs: its owner tags are rewritten, its {owner} lore line is repainted with their name, and one scroll is consumed. Nothing is written to the database - a pet item's owner lives in the item's own tags until it is redeemed.

It refuses, and consumes nothing, when the head already names them, when the slot holds more than one head (a stack carries ONE set of tags, so a single scroll would re-stamp every copy - split it first), when the pet is outside that scroll's whitelist / blacklist, when the pet's pets/<id>.yml is gone, when pet-items.enabled is off, or in creative while pet-items.allow-creative is off.

Dropping the scroll on anything that is not a pet item does nothing at all and costs nothing: the click is the ordinary inventory swap it looks like.

How do I use a level or a rarity scroll?

Since 1.19.0: open the pets menu with /pets, pick the scroll up onto your cursor out of your own inventory, and left or right click a pet - an equipped slot marker along the top row, or a stored pet in the grid. It is applied to that pet and one scroll is consumed. In 1.18.0 those two were defined, given and stamped but nothing spent them; scrolls handed out back then work exactly as they would have.

A level scroll raises the pet by the number stamped on that stack. A rarity scroll turns it into whatever its pets/<id>.yml names under upgrades-to, keeping its level, experience, trait and boosts. Neither is ever right clicked, and neither works on a pet ITEM in your inventory - that is the ownership scroll's surface, and dropping the wrong one there says so instead of eating it.

Why can I move my own items now while the pets menu is open?

Because that is the only way to pick a scroll up. guis/main.yml gained player-inventory: open in 1.19.0, so the bottom half of the window behaves normally while the menu is up. Every click on the menu's own cells is still cancelled, and so is the double-click gather, so nothing rendered in the menu can be pulled out of it. Two things got better for free: the ownership scroll now works with the menu open, and splitting a stack in your own inventory works again.

Set player-inventory: locked in guis/main.yml to get the old frozen behaviour back. The level and rarity scrolls stop working with it, because a cursor that can never hold anything cannot drop one on a pet.

My pet is at max level and the level scroll refuses. Is that right?

Yes, and it keeps the scroll. The ceiling it checks is the pet's OWN cap - the pet's max-level widened by its trait and by its level boost grade - so the same pet can accept a scroll after a trait roll that it refused before one.

A scroll that would carry the pet PAST the cap is not refused: the pet goes to the cap and the scroll is spent, so the last levels of a climb are reachable. The message tells you the levels really gained rather than the number printed on the item.

The rarity scroll worked but my pet left its slot. Where did it go?

To your storage, and the plugin says so. An upgrade rewrites the pet as a new one, and a new pet brings its own incompatibility and unique-group rules, so putting it straight back into the slot would be the plugin taking a decision the equip path owns. Equip it again from the grid. It kept its level, experience, trait, boosts and obtained date.

The rarity scroll says the pet does not upgrade into anything.

That pet's pets/<id>.yml declares no upgrades-to, which is how a pet at the top of its ladder is written. Add the key to that file by hand - pets/ is seed-only, so nothing merges into it - and reload. A pet whose upgrades-to names a file that no longer exists, or that names the pet itself, is refused the same way. Nothing is consumed in any of those cases.

Can I stop a scroll being used on certain pets?

Yes, per scroll, in the scrolls band of config.yml:

scrolls:
  ownership:
    whitelist: []                 # EMPTY means every pet
    blacklist:
      - stone_golem

The whitelist runs first - an empty one means every pet - and the blacklist after it, so an id in both is refused. Neither list is checked when the file loads: an id that names no pet simply never matches, which is the same outcome as a typo minus a false alarm on every boot.

To switch a whole scroll off instead, set scrolls.<type>.enabled: false. The give command then refuses it, and every copy already in circulation goes inert - nothing is taken away from anybody, and switching it back on restores them.

I already run SnPets. Do I get the scrolls band automatically?

Yes. config.yml is managed, so the whole scrolls: band is merged into your file on the first boot after updating, comments and all, with your existing values untouched. The same goes for the 13 new lang/messages_*.yml keys of 1.18.0 and the 7 more of 1.19.0.

guis/main.yml is managed too, so 1.19.0's three keys arrive on their own: player-inventory, the storage-drop-target item and input: true on slot-filled. Leave storage-drop-target alone - it never renders, and it is the only thing that makes the storage grid accept a scroll.

The one thing that does not arrive on its own is upgrades-to in your pet files: pets/ is seed-only, seeded once and never merged again, so you add that key to your own pets/<id>.yml files by hand. Only a fresh install receives the commented example. Until you do, the rarity scroll has nothing to turn those pets into and refuses without consuming.

I updated but the pet cells do not mention shift + right click or Q. Is it working?

It is. guis/main.yml is managed, so your install received the templates.pet-entry.shift-right-click-actions key (1.7.0) and drop-click-actions (1.11.0) and both triggers work immediately. What it did NOT receive are the lore lines that advertise them, because those are part of a lore LIST you already have and the merge never rewrites your own list values. Add them by hand:

      - ""
      - "&e&lSHIFT + RIGHT CLICK"
      - "&e&lQ (DROP)"
      - "&6Take this pet out as an item you can trade"

or delete the whole lore: list under templates.pet-entry and let the next boot write the shipped one back. Upgrading from 1.10.0 or earlier, &e&lQ (DROP) is the single line you are missing.

How do I put a name above every pet?

Since 1.8.0 that is built in. config.yml has a holograms band controlling how the text LOOKS - height-offset, line-spacing, scale, background (ARGB hex, empty for none), shadow, see-through and line-width - plus default-lines, the lines used by any pet that does not name its own. What each pet SAYS is in its pets/<id>.yml:

hologram:
  enabled: true
  lines:
    - "{group-color}{pet}"
    - "&7Lv. &f{level}&7/&f{level-cap}"
    - "&8{owner}"
  # height-offset: 0.9

You can use every placeholder a pet cell of any menu uses - {pet}, {level}, {level-cap}, {exp}, {exp-next}, {percent}, {group}, {group-color}, {trait}, {buff}, {buff-value} - plus {owner}. PlaceholderAPI tokens work too and resolve against the pet's OWNER, not against whoever is reading, because one label is shown to everyone who can see the pet.

Note that pets/ is seeded once and never merged again, so your existing pet files will NOT receive a hologram: block. They use holograms.default-lines instead until you write one. Only an explicit enabled: false silences a pet.

I updated to 1.8.0 and every pet suddenly has text over it. How do I turn that off?

config.yml is managed, so your server received the whole holograms band on the first boot after the update, with enabled: true and a two-line default. Set holograms.enabled: false and run /pets reload to go back to bare pets, or replace holograms.default-lines with [] to keep the feature available for the pets that declare their own lines while every other pet stays silent.

My model pets have the text inside them. Why?

Because the offset is measured from the pet, and "the pet" is not the same object in both cases. A head pet's label rides the head itself, which already sits formation.height-offset above the owner's feet. A model pet's label rides the invisible carrier its bones ride, which also carries models.height-offset - so on a server that pushed models down to stand on the ground (models.height-offset: -1.9), a label at 0.9 lands 0.9 blocks above the model's FEET.

Give those pets a bigger hologram.height-offset of their own. The shipped stone_golem.yml does exactly that, with 1.2.

Why is there no DecentHolograms option? I already run it.

Because a DecentHolograms hologram cannot ride the pet, and riding the pet is the whole point. It is a server-side hologram with its own tick and its own teleports, per line and per viewer: a second stream of position updates on a second clock, which is exactly the drift that makes a follower hologram look wrong when the server hitches. SnLib's own HologramUtil cannot be used either - it has no move call at all and does not expose the entity id, so following a pet would mean deleting and respawning a real entity several times a second.

What SnPets sends instead is a client-side text entity MOUNTED on the pet. The client positions it from the pet on every one of its own ticks, and the plugin never sends a single position packet for a label. Nothing has to be installed and nothing can fall behind.

One deliberate limit comes with that: the text does not bob along with a head pet's bounce (the bounce is a rendering transformation, which passengers do not inherit). The DecentHolograms LOOK is not a limit though - see the next question.

The text above my pets leans towards me and it looks bad. Can it stay straight?

Yes, and from 1.10.0 it does by default. Labels are drawn with the vertical billboard: they turn only around the vertical axis, so the lines stay upright however far above or below them you stand, which is the DecentHolograms look. Before 1.10.0 they used center, which turns on both axes and tilts the whole stack towards the camera.

config.yml is managed, so upgrading is enough - holograms.billboard: vertical arrives on the next boot. If you preferred the tilt, set that key to center and everything else stays as it is. horizontal and fixed are also accepted; neither reads well on a name plate. The setting is global, with no per-pet override, so a server has one label aesthetic rather than a mix.

Does it support Folia?

No, SnPets is not Folia-compatible. Run it on Paper 1.20.4 or newer. Both the 1.20 and 1.21 lines are supported.

Do pets lag the server with many players online?

No. Pets are packets, not entities, so they never enter the entity table, never tick physics and never get saved to the region files. The whole server shares one animation tick rather than one task per pet or per owner, so adding players adds work linearly, not a scheduler task each. An unequipped pet costs nothing at all.

Do I need BetterModel?

No. Without it every pet renders as a player head, which is the built-in default. Install it only if you want a pet type to render as an animated model with separate idle and moving animations.

A player says their pets vanished. What happened?

Check /pets toggle first: it hides the player's own pets and is the usual answer. If other players cannot see them either, check /pets hide on the viewer's side, then the worlds section in config.yml, which can disable rendering in a named world.

Why does a player receive no buff in one world?

Buffs have a per-world gate in config.yml. In a gated world the placeholder reports zero because the player genuinely receives nothing there. That is configuration, not a bug.

Can two players see each other's pets?

Yes, unless the viewer ran /pets hide or the world gates rendering off. Each viewer's own preference is respected, so one player hiding pets never affects anyone else's view.

My boxes/ folder was renamed to boxes-migrated/. Where did my boxes go?

Into boxes.yml, which is where every box lives from 1.4.0 on: one top-level key per box, named after the file it came from. The migration runs once, on the first boot after updating, and it never deletes anything - boxes-migrated/ is your original folder, kept exactly as it was, including the per-box comments that a YAML reader cannot carry onto a key.

Every box id is preserved, so the box items already in players' inventories and shulkers keep opening. The one exception is a file name containing a dot (my.box.yml), which cannot be a yml key: it becomes my_box and the console says so loudly, because that box's item id changes and the copies already handed out stop opening.

Once you are happy with boxes.yml you can delete boxes-migrated/ yourself. Nothing reads it.

My migrated boxes never fail to open. Where is the success chance?

boxes.yml is seed-only, so an update never adds keys to it - which is exactly what protects the boxes you wrote. That means a migrated box has no chance block, and a box without one always opens: identical to how it behaved before 1.4.0. Add the band by hand to any box you want to turn into a gamble:

rare:
  chance:
    min: 60
    max: 90

Add {chance} to that box's lore too if you want the odds shown on the item.

A player opened a box and got nothing. Are the pets lost?

If the box failed its success roll, that is working as designed: the box is consumed, the player is told which percentage it was rolling against, and nothing is granted. Only boxes with a chance band below 100 can do this, and the percentage is written on the item itself.

Otherwise, no, nothing is lost. If the database write fails, the boxes are handed straight back and the player is told, so nothing is consumed. If storage filled up between the click and the grant, the open lands partially on purpose and reports how many pets did not fit. Free storage and open the rest.

A player has more pets stored than their capacity allows. How?

They opened boxes faster than the pets could be written. Before 1.8.2 the capacity check ran the instant you clicked, while the pets themselves were saved a few ticks later, so a second click that arrived in between still saw the old count and was let in again. Shift-clicking six or seven stacks in a row could leave a storage of 54 holding 107 pets.

Update to 1.8.2. Each open now holds the places it was granted for as long as its pets are in flight, so a simultaneous open sees them as already taken: the excess is trimmed on the click that does not fit, and the boxes it would have opened are returned. Nothing to configure.

Storages that are already over capacity stay as they are - the update stops the overfill, it does not delete anyone's pets. Nothing new enters until the player is back under their limit, which is the same rule that has always applied after unequipping a pet into a full storage.

The refusal said (57/54) on a storage of 54. Is the limit being bypassed?

No, and on 1.12.1 the message no longer says that. The limit was always enforced - what you were reading was a counting artefact in the message itself. While an open's pets are being written, the places they will take are held for them, and for a fraction of a second a pet can be visible as both "held" and "already stored". The decision was correct throughout (there really was no room), but the number quoted added those places twice, so a stack spammed fast enough produced (57/54), (62/54), (67/54).

Update to 1.12.1. Held places may now raise the quoted number up to the capacity and no further, so the refusals read (54/54). Nothing to configure, and nothing about what is accepted or refused changed - only the number shown.

A number above the capacity is still shown when it is real: a storage left over its limit by a historic overfill, an admin grant or a capacity you lowered will correctly say (107/54), because that is the player's actual state and not a pet counted twice.

How do I give a rank more pet slots or storage?

Grant snpets.slots.<n> or snpets.storage.<n> in your permissions plugin. The highest value a player holds wins, so stacking nodes across ranks is safe. The value is read on join, so a rank change applies the next time the player logs in. Since 1.22.0 the permission is the FLOOR: it replaces the config base when higher, and everything sold with /pets admin slots|storage give adds on top of it.

I gave a player 1 slot and their total did not go up. Why?

You are on 1.21.0 or earlier. Until then the effective count was the highest of the config base, the rank permission and the purchased value, so with slots.base-count: 1 a first purchased slot vanished into the base the player already had. Since 1.22.0 purchases ADD on top of max(base, permission): give 1 slot on a stock install and the total goes from 1 to 2. Nothing has to be migrated - existing purchases simply start counting the moment 1.22.0 boots.

I gave someone 100 slots and they only got 7. Why?

slots.max-count in config.yml, which ships at 7 from 1.9.0 on. It is the ceiling on the TOTAL slots an admin command may leave (on the purchased slots before 1.22.0), and a command past it is clamped rather than cancelled - so the grant went through, it just stopped at a total of 7, and the admin was told so before the usual confirmation. 7 is the number of pet cells the shipped guis/main.yml layout can draw; anything past it would be bought and never usable.

Raise the key if you widened the menu layout, or set it to 0 to remove the ceiling entirely. storage.max-capacity is the same knob for storage and ships at 0, so storage grants are unlimited out of the box.

Two things it does not do: it does not cap snpets.slots.<n> permission grants, so a rank can still grant more than a command can; and it never lowers a row by itself. Lowering the key on a live server leaves players above it alone until the next slots give/set on them.

Can I still type -s and -sf the way I always did?

Yes, nothing about them changed in 1.9.0 - they just tab-complete now, as the last two optional parameters of every /pets admin command. Trailing junk is still accepted in silence, and the flags are still trailing and order-independent.

Your lang/messages_en.yml will grow an args entry for each of them under every admin command on the first boot after the update. That block is only the visible labels of each argument in the usage line; editing or deleting an entry never changes how a command is typed.

Can I add my own pets?

Yes. Copy a file in pets/ and rename it: the file name is the pet id. The folder is yours after the first boot, so nothing you add or delete there is ever undone by an update. Boxes work the same way, except they are keys inside boxes.yml rather than separate files: copy a whole top-level block and rename the key.

Do I need EdTools?

No. It is optional, exactly like BetterModel. Without it no pet grants a booster, no pet can use the EDTOOLS_BLOCK_BREAK experience source, no EdTools class is ever loaded and everything else works unchanged. Install it only if you want an equipped pet to boost your server's currencies or its global enchant multiplier, or to level from the blocks your omnitools break.

I gave a pet edtools-boosts and it grants nothing. Why?

Almost certainly the one-decimal rule. SnPets never hands EdTools more than one decimal of the fraction it wants, so the granted boost moves in steps of 10%: a summed total below 5% rounds to zero and the booster is removed rather than written at nothing. A pet with initial: 2.0 at level 1 is worth 2%, which rounds away.

Write your pets in tens if you want what you wrote. Two other things to check: the console line at boot must say EdTools detected, and an unknown currency id logs one warning naming it.

Since 1.15.0, check the entry's max: too if it has one. The ceiling is applied to that pet BEFORE the totals are summed and before this rounding, so a pet capped at max: 4 contributes 4 and, on its own, still rounds away to nothing. That ordering is also what makes the ceiling safe to use: three pets capped at 4 sum to 12 and grant +10%, which capping after the rounding would have lost. A max: of 0, a negative one, or no max: at all all mean no ceiling.

My pet's menu line says "Buff Damage: 0.0%" even though the pet boosts currencies

That was the pre-1.20.0 behavior. {buff} and {buff-value} used to show only the vanilla buff: block - a pet that declares none defaults to a damage buff worth zero at every level, which is the "Damage 0.0%" you saw, no matter the pet's level. Since 1.20.0 a pet whose vanilla buff grants nothing resolves both placeholders from its edtools-boosts block instead: {buff} shows the boosted currencies (named per your messages.edtools-currency-<id> lang entries, the raw id otherwise) and {buff-value} the live value at the pet's current level, cap and widening included. A pet that declares a real vanilla buff: is untouched. If you still see the zero line on 1.20.0, the pet's edtools-boosts block grants nothing at its level - see the one-decimal question above.

I already run SnPets. Why do my pets have no edtools-boosts block?

Because pets/ is seeded once and never merged again, which is the same reason your pet files did not grow a hologram: block in 1.8.0. The commented example ships in pets/ember_fox.yml for a fresh install only; on a server you already run you paste the block into the pet files yourself. The edtools band of config.yml does arrive on its own, because that file is managed.

How do I turn the pet boosters off without uninstalling EdTools?

Set edtools.enabled: false and run /pets reload. The boosters already granted are removed immediately; you do not need to restart. Turning it back on and reloading writes them again.

Can a TRAIT boost an EdTools currency?

Yes, since 1.16.0. Give the trait an effects.edtools block in traits.yml and list flat percentage points per currency id, or under one of enchants / enchant / global-enchants / encantamientos for the global enchant multiplier:

lucrative:
  weight: 10.0
  effects:
    edtools:
      essence: 15.0

The difference from a pet's own edtools-boosts is what makes it useful: the pet does not need to declare anything. Any equipped pet carrying the trait pays those points, so the trait upgrades the whole collection instead of one pet family. They are also FLAT - no level scaling, no widening by boost grades, and no clamping by a pet entry's max: - and they join the same per-currency total, so the one-decimal rule in the answer above still decides what actually lands. Two equipped pets carrying the trait pay it twice.

traits.yml is seeded once and never merged again, so on an existing server you add the key by hand; a fresh install gets a commented example inside the studious entry. Full rules in Configuration.

Can a pet boost one specific enchant?

No, only the global enchant multiplier. That is the whole of what EdTools exposes to other plugins, so it is a limit of the integration rather than a decision SnPets made. Use one of enchants, enchant, global-enchants or encantamientos as the key.

My pets get no experience from EdTools mining. Why?

Because BLOCK_BREAK does not see it. EdTools consumes the blocks its omnitools break without ever firing a vanilla BlockBreakEvent, so on a farming server those two count completely different things. Set the pet's experience.source to EDTOOLS_BLOCK_BREAK instead, and leave experience.sources.edtools-block-break on in config.yml. pets/<id>.yml is seed only, so you edit the pet files you already have by hand; the config key arrives on its own.

Can a pet level from only one of my EdTools tools?

Yes. Add an optional experience.tools list to that pet's file, holding the EdTools tool ids as EdTools itself names them:

experience:
  source: EDTOOLS_BLOCK_BREAK
  ratio: 0.5
  tools:
    - crop-tool

The ids are matched case-insensitively and are never validated against EdTools, so one that names no tool simply never matches. Leave the list out (or empty) and every omnitool counts. The experience.materials whitelist still applies on top, exactly as it does for BLOCK_BREAK.

Does the EdTools experience source lag the server?

No. It is the busiest event a farming server produces - thousands a second with bulk enchants - and EdTools fires it off the main thread, so the handler does one cancel check and one counter increment and nothing else. A single shared task pays the totals out coalesced per (player, block, tool) every 5 ticks. There is no task per block, no one-tick timer, and no task per player. On a server without EdTools the listener is never registered and the task never runs.

I turned EdTools off mid-session. Do I have to restart?

No. Disabling or enabling EdTools unregisters or registers the break listener on its own, and stops or starts the drain with it. The same is true if you install EdTools after SnPets has already started.