HasPlayerItem: Difference between revisions

From Wiki G1R-MP G1 Remake Multiplayer
Jump to navigation Jump to search
Complete Lua function catalog
Release 0.1.9 / BUILD264 / Protocol42: availability and download setup; preserve experimental limits
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
<!-- This page is generated automatically from the function definition: hasPlayerItem. -->
= hasPlayerItem =
= hasPlayerItem =
Checks whether a player owns at least one copy of a known inventory item.
<div style="background:#fff5f5; border:1px solid #d13b3b; border-left:5px solid #d13b3b; color:#111111; padding:0.85rem 1rem; margin:0.75rem 0 1rem;">
<div style="color:#111111; font-weight:bold; letter-spacing:0.04em;">IMPROVED FROM UPDATE 0.1.2</div>
<div style="color:#111111; margin-top:0.25rem;">This function is available in earlier releases and has corrected or expanded behavior in G1R:MP 0.1.2 and later. The contract below describes the updated behavior.</div>
</div>
 
Checks the authoritative server runtime cache for at least one copy of a known inventory item.


== Syntax ==
== Syntax ==
Line 30: Line 34:
== Notes ==
== Notes ==
* Available only in server-side resource scripts.
* 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.


[[Category:Lua Functions]]
[[Category:Lua Functions]]
Line 35: Line 40:
[[Category:Player Functions]]
[[Category:Player Functions]]
[[Category:Inventory Functions]]
[[Category:Inventory Functions]]
<!-- customkeys019:start -->
'''Available from 0.1.9. Use matching updated server and clients.'''
== Registered custom keys ==
This existing API also accepts the canonical item string from [[registerKeyDefinition]] in 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 -->

Latest revision as of 13:28, 20 October 2026

hasPlayerItem

IMPROVED FROM UPDATE 0.1.2
This function is available in earlier releases and has corrected or expanded behavior in G1R:MP 0.1.2 and later. The contract below describes the updated behavior.

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. Use matching updated server and clients.

Registered custom keys

This existing API also accepts the canonical item string from registerKeyDefinition in 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.