class DayZPlayerInventory

MAx distance for itme to be repair (without it it can be use for getting position from server)

limmit number of items transfere duting repair.

deferred hand event

deferred weapon event

cancels any handevents that will be executed this frame @NOTE: this is used in situations where the player performs an action that renders the event invalid exactly on the frame it will be executed

deferred weapon's fsm handling of events @NOTE: "post" stores the event for later use when ::CommandHandler is being run

reaction to engine callback originates in: engine - DayZPlayer::OnSyncJuncture script - PlayerBase.OnSyncJuncture

reaction to engine callback originates in: engine - DayZPlayer::OnSyncJuncture script - PlayerBase.OnSyncJuncture

Function and setup is still messy due to the switch statement and relation with reading.

It could be cleaner if we used classes to handle each inventory command type, but that comes at a performance cost and will also probably require making a fair amount of changes elsewhere.

The downsides with this system right now: 1. It makes it hard to track what is written/read from the serializer 2. It makes this file very very large

The new changes at least remove the massive switch block and allow for all inventory commands to respond back to the client if something goes wrong

reaction to engine callback originates in engine - DayZPlayerInventory::HandleStoredJunctureData

stores received input user data for later handling /aaa

reaction to engine callback originates in: engine - DayZPlayer::OnInputUserDataReceived script - DayZPlayerImplement.OnInputUserDataReceived

reaction to engine callback originates in engine - DayZPlayerInventory::HandleStoredInputUserData

stores received input user data for later handling

Juncture is only ever Server Req->Client Ack and Perform->Server Perform, never remote

Juncture is only ever Server Req->Client Ack and Perform->Server Perform, never remote

Never end here, always return in send junture part MW Do not check for action validity on remotes or when performing through juncture. Juncture locks guarentee the item is safe to interact with and the server has validated the command at this point. Checking at this point is both wasteful and can result in a failure which leads to desync

TODO(kumarjac): We should continue with the execution and not have this special block but making a change here now will require testing

TODO(kumarjac): We should probably set the result to failure like so

Continuing on with execution of rest of the function

'HandEventBase.CanPerformEventEx' updates failure reason

'HandEventBase.CanPerformEventEx' updates failure reason

'HandEventBase.CheckRequestEx' updates failure reason

Check whether the juncture for the related player and items has been acquired.

Do not check for action validity on remotes or when performing through juncture. Juncture locks guarentee the item is safe to interact with and the server has validated the command at this point. Checking at this point is both wasteful and can result in a failure which leads to desync

Returns: false on malformed data, true on anything else, including cheats

Only send juncture back to client

General purpose serializer change from read to write here if the validation doesn't update it

Serializer can be updated and re-written to when we may want to only correct the client instead of denying the inventory command

Serializer can be updated and re-written to when we may want to only correct the client instead of denying the inventory command

Serializer can be updated and re-written to when we may want to only correct the client instead of denying the inventory command

Remote inputs are processed in sync juncture once performed on the server - this code below was executing the inventory command before the player simulation timeestamp for remotes which is illegal

Engine callback - network synchronization of FSM's state. not intended to direct use.

engine reaction to load from database originates in: engine - Person::BinLoad script - PlayerBase.OnAfterStoreLoad

reaction of remote weapon to (common user/anim/...) event sent from server

reaction of remote weapon to (common user/anim/...) event sent from server

If singleplayer or the client is executing this

Default structure suffices

Local, checks only stuff that is in guaranteed sync

Local, checks only stuff that is in guaranteed sync

Do not check for action validity on remotes or when performing through juncture. Juncture locks guarentee the item is safe to interact with and the server has validated the command at this point. Checking at this point is both wasteful and can result in a failure which leads to desync