InteractiveUseEndedEvent

A TIMED interaction is over: the use that InteractiveUsedEvent started with a duration above zero has finished. It closes the busy period of InteractiveUseRequest.

WHAT TO DO WHEN YOU RECEIVE IT

1. IF element_id IS THE ELEMENT YOU ARE USING, YOU ARE FREE AGAIN. Clear your busy state: you may send InteractiveUseRequest again, for any element, and walk again. The official client clears its busy flag, forgets which element its character was using, and lets its movement service accept walks again. 2. THE ELEMENT IS FREE. Remove element_id from your record of "who is using which element" (the official client keeps one, filled by element id from every timed InteractiveUsedEvent, and removes the entry here). 3. THE RESULT IS ELSEWHERE. This message only says the interaction ended. What it changed - the resource harvested, the element's new state - arrives as InteractiveElementUpdatedEvent / StatedElementUpdatedEvent and the inventory and job messages.

CHECK element_id BEFORE CLEARING YOUR BUSY STATE. Whether the server sends this only to the character that used the element, or to everyone on the map, is not established, and the client's code points both ways. It clears its own busy state on every one, without comparing the element with the one its character was using: that only makes sense if it receives nothing but its own. It also removes the element from the table that every timed InteractiveUsedEvent fills, other characters' uses included: that only makes sense if it receives theirs too. If element_id is not the element you are using, apply step 2 only.

skill_id echoes which action ended (the action's skill_id, not an offer's skill_instance_uid). The official client never reads it; where a build pads the message with another unread int32 it stays unnamed.

3.6.12.16 pads this message with an int64 the client never reads. Never rely on it.

FROM 3.7.1.0 THE TYPED HANDLERS READ NO FIELD: they clear the busy flag and let the movement service accept walks again, unconditionally, and the table of elements in use is gone, so step 2 has no counterpart in that client. Its interaction filter still compares element_id with the element the character started using, which is how this signature names both members on every build.