Keys, Claims, and Vehicle Redemption

keys.yml controls the item layer that turns Vehicle MC vehicles into claimable, redeemable content instead of admin-only spawn commands.

This matters because keys sit in the middle of several public workflows:

• a catalog click can give or redeem a vehicle key
• a world prop can hand out a key instead of a full spawned vehicle
• pickup can store a live vehicle into a dupe-safe key record
• the same key item can be styled differently for different vehicle families

What keys.yml really controls

The base key format is simple on paper:

keys:
  baseItem: minecraft:tripwire_hook{CustomModelData:12001}
  nameTemplate: '&6%vehicle_type_name% &7Key'
  lore:
    - '&7Redeems: &f%vehicle_type_name%'
    - '&8Key ID: %short_id%'
  redeemMode: on_use
  requireNonCreative: false
  idFormat:
    shortLength: 8

But those fields decide a lot of public behavior:

• baseItem decides what item form the entire vehicle-key system uses
• nameTemplate and lore decide whether the key feels premium, military, civilian, seasonal, or staff-only
• redeemMode decides how fast the handoff feels for players
• requireNonCreative decides whether staff in creative can test normal redemption flow
• idFormat.shortLength decides how readable the displayed short key ID is in support situations

Styling keys for real players

Good key styling should answer three questions immediately:

1. What vehicle does this unlock?
2. Is this a one-time redeemable key or part of a reusable workflow?
3. Does this belong to a civilian vehicle, a combat vehicle, a crate reward, or an event reward?

A clean pattern is to keep the item material consistent and use the name and lore to communicate the vehicle family:

keys:
  baseItem: minecraft:tripwire_hook{CustomModelData:12001}
  nameTemplate: '&6%vehicle_type_name% &7Vehicle Key'
  lore:
    - '&7Unlocks: &f%vehicle_type_name%'
    - '&7Use: &fRight-click to redeem'
    - '&8Key ID: %short_id%'

That keeps your economy and support pages easy to understand even when many different vehicles exist.

Claim and redeem effects

The same file also controls the feedback layer for claiming and redeeming:

effects:
  defaults:
    on-claim-success:
      title:
        - '&aVehicle Claimed!'
        - '&7%li%'
      sound:
        id: minecraft:entity.player.levelup
        volume: 1.0
        pitch: 1.2
    on-key-redeem-success:
      title:
        - '&aVehicle Unlocked!'
        - '&7%vehicle_type_name%'

This is the difference between:

• a key that feels dead and administrative
• a key that feels like part of a polished vehicle ecosystem

Use the default block for your global feel first, then use per-type only when a vehicle family genuinely deserves different claim or redeem feedback.

How keys interact with stored vehicles

Vehicle MC also uses keys as part of its pickup and stored-vehicle path.

That means some keys are not just simple "spawn this base vehicle" items. They can represent a stored vehicle record with state attached to it. Publicly, the important part is this:

• pickup should be treated as a state-preserving workflow, not just an item giveaway
• key duplication safety matters more once stored vehicles are enabled
• if you run pickup, redemption wording in messages.yml should be very clear so players understand whether they received a fresh key or a stored vehicle record

Good deployment pattern

1. Pick one base key item for the whole server.
2. Make the key name instantly readable.
3. Add one clean redeem-success title and sound.
4. Test normal player redemption before using prop-based redemption.
5. Only then mix keys into pickup, event props, or paid rewards.

Related pages

• spawn Pools, Tables, and Display Props
• catalog, Keys, Spawns, Messages, and Driver UI
• messages, Bossbars, and Driver Feedback