fix(es_extended/server/main): add the weapon before restoring its tint and components

esx:giveInventoryItem applies the tint and the components to the receiving
player before calling addWeapon. Both setWeaponTint and addWeaponComponent
start with getWeapon and only proceed when the player already owns the weapon,
and the handler returns early a few lines above if the target does own it - so
at that point the target provably does not, and both calls do nothing.

The result is that handing a weapon to another player silently strips its
attachments and its paint. The pickup path in the same file already adds the
weapon first and then restores tint and components.

The values are snapshotted from the source weapon before any of this, and
removeWeapon already ran before addWeapon, so only the position of the two
restore blocks changes.

Verified on artifact 25770 by running both orders against a loadout:
  tint and component first -> both return false, weapon ends up tint 0 with no
                              components
  addWeapon first          -> both return true, weapon ends up tint 1 with the
                              component attached
This commit is contained in:
Selt
2026-07-27 05:19:51 +02:00
parent ca597cf6f4
commit 7538debb6f
+3 -3
View File
@@ -474,6 +474,9 @@ if not Config.CustomInventory then
local weaponComponents = ESX.Table.Clone(weapon.components)
local weaponTint = weapon.tintIndex
sourceXPlayer.removeWeapon(itemName)
targetXPlayer.addWeapon(itemName, itemCount)
if weaponTint then
targetXPlayer.setWeaponTint(itemName, weaponTint)
end
@@ -484,9 +487,6 @@ if not Config.CustomInventory then
end
end
sourceXPlayer.removeWeapon(itemName)
targetXPlayer.addWeapon(itemName, itemCount)
if weaponObject.ammo and itemCount > 0 then
local ammoLabel = weaponObject.ammo.label
sourceXPlayer.showNotification(TranslateCap("gave_weapon_withammo", weaponLabel, itemCount, ammoLabel, targetXPlayer.name))