HasPlayerItem: Difference between revisions
Document Lua APIs available or improved from G1R:MP 0.1.2 |
Document upcoming 0.1.9 custom native keys, shared doors, server Lua callbacks and persistence; not a release |
||
| Line 40: | Line 40: | ||
[[Category:Player Functions]] | [[Category:Player Functions]] | ||
[[Category:Inventory Functions]] | [[Category:Inventory Functions]] | ||
<!-- customkeys019:start --> | |||
'''Available from 0.1.9 (upcoming; not yet publicly released). Not included in public 0.1.8. Use matching updated server and clients.''' | |||
== Registered custom keys == | |||
This existing API also accepts the canonical item string from [[registerKeyDefinition]] in upcoming 0.1.9. Server registration, active definition and appropriate presentation readiness are required for mutations; use [[isPlayerKeyDefinitionReady]]. Do not pass the donor model alias as the custom item identity. Existing call shapes and limits remain; [[spawnItem]] creates one world item per call, whereas give/remove counts can manage copies. See [[Custom keys]] for safe server-side issuance, drop, pickup and persistence. | |||
<!-- customkeys019:end --> | |||
Revision as of 20:00, 19 October 2026
hasPlayerItem
Checks the authoritative server runtime cache for at least one copy of a known inventory item.
Syntax
bool hasPlayerItem(int playerId, string itemKey)
Parameters
| Name | Type | Required | Description |
|---|---|---|---|
playerId |
int |
yes | The connected player identifier. |
itemKey |
string |
yes | A rune, armor, or melee weapon key from the server catalog. |
Returns
Returns true when the authoritative quantity is greater than zero; otherwise returns false.
Examples
Equip a sword only when it is present in the inventory:
if hasPlayerItem(playerId, "1h_sword_01") then
setPlayerWeapon(playerId, "1h_sword_01")
end
Notes
- Available only in server-side resource scripts.
- The same cache tracks accepted native world-item pickups and drops, completed native consumable uses, and successful Lua inventory mutations.
Available from 0.1.9 (upcoming; not yet publicly released). Not included in public 0.1.8. Use matching updated server and clients.
Registered custom keys
This existing API also accepts the canonical item string from registerKeyDefinition in upcoming 0.1.9. Server registration, active definition and appropriate presentation readiness are required for mutations; use isPlayerKeyDefinitionReady. Do not pass the donor model alias as the custom item identity. Existing call shapes and limits remain; spawnItem creates one world item per call, whereas give/remove counts can manage copies. See Custom keys for safe server-side issuance, drop, pickup and persistence.