OnPlayerWeaponChangeResult: Difference between revisions

From Wiki G1R-MP G1 Remake Multiplayer
Jump to navigation Jump to search
Document upcoming 0.1.4 weapon confirmation and mouse camera APIs
 
Release 0.1.4 BUILD133 / Protocol 36 and document authenticated event origin
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
= onPlayerWeaponChangeResult =
= onPlayerWeaponChangeResult =
'''Since 0.1.4 (in development; not in public 0.1.3).'''
'''Since 0.1.4. Requires a compatible client and server.'''


Server event: function(playerId, itemKey, ok, reason, requestId). Delivered only to the requesting resource.
Server event delivered only to the resource that requested the weapon change.


See [[Weapon control]] for the full contract, return values, lifecycle, limitations and examples.
<syntaxhighlight lang="lua">
onPlayerWeaponChangeResult(playerId, itemKey, ok, reason, requestId)
</syntaxhighlight>
 
* <code>playerId</code>: the player whose request finished.
* <code>itemKey</code>: the requested catalog key, or <code>"none"</code> for clearing both weapon slots.
* <code>ok</code>: whether native completion passed server validation.
* <code>reason</code>: <code>"confirmed"</code> for success, or a failure reason such as <code>"superseded"</code>, <code>"native-equip-not-allowed"</code>, <code>"readback-timeout"</code> or <code>"client-confirmation-timeout"</code>.
* <code>requestId</code>: the identifier of this request, useful for correlating results.
 
A successful clear requires empty native inventory slots and completed carry-visual cleanup. The updated server commits the confirmed empty equipment to replication/late-join state. Request identity, current life revision and deadline are checked; failed, expired, superseded or cancelled requests cannot commit a successful clear.
 
This event is not an acknowledgement from every remote renderer. A later manual change may already be reflected by [[getPlayerWeaponState]] when a script handles the result. Failure/timeout is not rollback; inspect current state before retrying. Stopping the owning resource discards pending result delivery, while an already issued native operation may finish.
 
<syntaxhighlight lang="lua">
addEventHandler("onPlayerWeaponChangeResult", resourceRoot,
    function(playerId, itemKey, ok, reason, requestId)
        if not ok then
            outputDebugString("Weapon request failed: " .. tostring(reason))
            return
        end
        local state = getPlayerWeaponState(playerId)
        if state and state.fresh then
            -- Use current state.melee and state.ranged for persistence.
        end
    end)
</syntaxhighlight>
 
See [[Weapon control]] and [[setPlayerWeapon]].
[[Category:Lua API]]
[[Category:Lua API]]
[[Category:Server Events]]
[[Category:Server Events]]
[[Category:Lua Events]]
[[Category:Lua Events]]

Latest revision as of 20:40, 21 September 2026

onPlayerWeaponChangeResult

Since 0.1.4. Requires a compatible client and server.

Server event delivered only to the resource that requested the weapon change.

onPlayerWeaponChangeResult(playerId, itemKey, ok, reason, requestId)
  • playerId: the player whose request finished.
  • itemKey: the requested catalog key, or "none" for clearing both weapon slots.
  • ok: whether native completion passed server validation.
  • reason: "confirmed" for success, or a failure reason such as "superseded", "native-equip-not-allowed", "readback-timeout" or "client-confirmation-timeout".
  • requestId: the identifier of this request, useful for correlating results.

A successful clear requires empty native inventory slots and completed carry-visual cleanup. The updated server commits the confirmed empty equipment to replication/late-join state. Request identity, current life revision and deadline are checked; failed, expired, superseded or cancelled requests cannot commit a successful clear.

This event is not an acknowledgement from every remote renderer. A later manual change may already be reflected by getPlayerWeaponState when a script handles the result. Failure/timeout is not rollback; inspect current state before retrying. Stopping the owning resource discards pending result delivery, while an already issued native operation may finish.

addEventHandler("onPlayerWeaponChangeResult", resourceRoot,
    function(playerId, itemKey, ok, reason, requestId)
        if not ok then
            outputDebugString("Weapon request failed: " .. tostring(reason))
            return
        end
        local state = getPlayerWeaponState(playerId)
        if state and state.fresh then
            -- Use current state.melee and state.ranged for persistence.
        end
    end)

See Weapon control and setPlayerWeapon.