FiveM weapon list, with the numbers behind it

GiveWeaponToPed takes a ped, a weapon hash, an ammo count and two booleans — whether the weapon is hidden, and whether to force it into the ped’s hands. That is the easy one. The two that cost people an afternoon are the components and the tints, for the same two reasons every time.

A component is given after the weapon, never before

GiveWeaponComponentToPed attaches a part to a weapon the ped already owns. Call it on a ped that does not hold the weapon yet and nothing happens — no error, no warning, no return value to check. The attachment simply never appears, which looks exactly like a wrong component name, so that is where people go looking. The fix is the order: weapon first, component second. If your loadout code builds a list and loops it, give the weapon before the loop.

The same silence covers the other common case: giving a component to a weapon that does not take it. COMPONENT_AT_AR_SUPP fits the assault rifles and nothing else. The table above lists only the components each weapon actually declares an attach point for, which is the part a generic component list cannot tell you.

The component hash is not the component name

The name is a string. The native wants a number — the Jenkins one-at-a-time hash of that string, which GetHashKey works out at runtime. Lua will pass the string itself to the native without complaint, the call fails quietly, and nothing in the console mentions it. Every component in the table shows both, so you can hard-code the number if you would rather not hash at runtime.

RegisterCommand('loadout', function()
    local ped = PlayerPedId()
    local weapon = GetHashKey('WEAPON_CARBINERIFLE')

    GiveWeaponToPed(ped, weapon, 250, false, true)

    for _, part in ipairs({
        'COMPONENT_CARBINERIFLE_CLIP_02',
        'COMPONENT_AT_SCOPE_MEDIUM',
        'COMPONENT_AT_AR_SUPP',
    }) do
        GiveWeaponComponentToPed(ped, weapon, GetHashKey(part))
    end

    SetPedWeaponTintIndex(ped, weapon, 5)
    SetCurrentPedWeapon(ped, weapon, true)
end, false)

Tints are indices, not colours

SetPedWeaponTintIndex takes a number that indexes the weapon’s own tint table. There is no RGB anywhere in this: a tint is a texture the game already has, and the index picks which one. Expand any row above and every index is there with its name and a copy button.

There are only 4 distinct tables across all 120 weapons. Almost everything points at the standard eight — black, green, gold, pink, army, LSPD, orange, platinum. The Mk II weapons use a 33-entry table, the alien weapons a seven-entry one, and two revolvers declare a single black entry. The table a weapon points at is tint-spec data from the dump rather than a promise that the game draws a finish for it — a knife points at the standard eight the same way a pistol does, and only the ones Ammu-Nation sells a finish for have anything to show.

A camo is a different thing wearing a similar name. Mk II camos are components: you give them with GiveWeaponComponentToPed like a scope, then choose the colourway on top with SetPedWeaponComponentTintIndex. That is why the Mk II rows carry a long list of COMPONENT_..._CAMO entries as well as a tint table. We do not print names for those camos — our sources repeat the same English label across every camo index of a weapon, and a wrong name is worse than none.

local ped = PlayerPedId()
local ok, weapon = GetCurrentPedWeapon(ped, true)

if ok and IsWeaponValid(weapon) then
    print(('group %s · clip %d · tint %d'):format(
        GetWeapontypeGroup(weapon),
        GetWeaponClipSize(weapon),
        GetPedWeaponTintIndex(ped, weapon)
    ))

    print('damage', GetWeaponDamage(weapon, 0))

    if HasPedGotWeaponComponent(ped, weapon, GetHashKey('COMPONENT_AT_AR_SUPP')) then
        print('suppressed')
    end
end