UpdateInvPartial

class UpdateInvPartial : OutgoingGameMessage

Update inv partial is used to send an update of an inventory that doesn't include the entire inventory. This is typically used after the first UpdateInvFull update has been performed, as subsequent updates tend to be smaller, such as picking up an object - only a single slot in the player's inventory would change, not warranting the full 28-slot update as a result.

A general rule of thumb for when to use partial updates is if the percentage of modified objects is less than two thirds of that of the highest modified index. So, if our inventory has a capacity of 1,000, and we have sparsely modified 500 indices throughout that, including the 999th index, it is more beneficial to use the partial inventory update, as the total bandwidth used by it is generally going to be less than what the full update would require. If, however, there is a continuous sequence of indices that have been modified, such as everything from indices 0 to 100, it is more beneficial to use the full update and set the capacity to 100 in that.

Below is a percentage-breakdown of how much more bandwidth the partial update requires per object basis given different criteria, compared to the full update:

14.3% if slot < 128 && count >= 255
28.6% if slot >= 128 && count >= 255
33.3% if slot < 128 && count < 255
66.6% if slot >= 128 && count < 255

While it is impossible to truly estimate what the exact threshold is, this provides a good general idea of when to use either packet.

Constructors

Link copied to clipboard
constructor(interfaceId: Int, componentId: Int, inventoryId: Int, provider: UpdateInvPartial.IndexedObjectProvider)
constructor(combinedId: Int, inventoryId: Int, provider: UpdateInvPartial.IndexedObjectProvider)
constructor(inventoryId: Int, provider: UpdateInvPartial.IndexedObjectProvider)

Types

Link copied to clipboard
abstract class IndexedObjectProvider(indices: Iterator<Int>)

An object provider interface is used to acquire the objs that exist in different inventories. These objs are bit-packed into a long, which gets further placed into a long array. This is all in order to avoid garbage creation with inventories, as this can be a considerable hot-spot for that.

Properties

Link copied to clipboard
open override val category: ServerProtCategory
Link copied to clipboard

the combined id of the interface and the component id. For IF3-type interfaces, only negative values are allowed. If one wishes to make the inventory a "mirror", e.g. for trading, how both the player's own and the partner's inventory share the id, a value of < -70000 is expected, this tells the client that the respective inventory is a "mirrored" one. For normal IF3 interfaces, a value of -1 is perfectly acceptable.

Link copied to clipboard

the component on which the inventory lies

Link copied to clipboard
val count: Int

the number of items added into this partial update.

Link copied to clipboard

the IF1 interface on which the inventory lies. For IF3 interfaces, no interfaceId should be provided.

Link copied to clipboard

the id of the inventory to update

Functions

Link copied to clipboard
open operator override fun equals(other: Any?): Boolean
Link copied to clipboard
open override fun estimateSize(): Int
Link copied to clipboard
fun getObject(slot: Int): Long

Gets the bitpacked obj in the slot provided.

Link copied to clipboard
open override fun hashCode(): Int
Link copied to clipboard
Link copied to clipboard
open override fun toString(): String