Revision as of 17:45, 14 April 2007

Baaaaaaaaaaaaaaaaack

Description

The crafting process is monitored in the Player Object. The relevant values are set through the Yalp 9 at initialization and / or changed through the relevant deltas in the crafting process.

The Sequence

Upon double clicking the craft item the client sends 3 Packets, through which a crc list of the available schematics is requested.

For starters let us break it down into the steps needed to open up the different crafting screens.

Schematic selection aka 1st screen

Upon using the crafting tool, the usual radial menu packets are sent. Additional the client sends a

CommandQueueEnqueue : SynchronizedUIListen (F9996AB6)and a

CommandQueueEnqueue : requestcraftingsession (094AC516)

Client Initiates

1) client -> server radial menu request Packet

2) client -> server F9996AB6 synchronizeduilisten

3) client -> server 094AC516 requestcraftingsession

server response The server responds with the customary Menu response and by sending the DraftSchematics (00000102) Packet

4) server -> client Menu response

5) server -> client DraftSchematics (00000102)

client response Triggered through the DraftSchematics Packet, the Client requests the DraftSlotsBatches and the ResourceWeightsBatches. In these Batches the Complete 64bit ID (crc + uint32 ID)of every schematic the Crafter has access to is send as Unicode strings.

6) ComandQueueEnqueue 5FD21EB0 requestdraftslotsbatch

7) ComandQueueEnqueue 9A8B385C requestresourceweightsbatch

server response The server responds to the BatchRequestPackets by sending the SlotConfiguration for every requested schematic in the DraftSlotsqueryResponse and by sending the ResourceWeights in the ResourceWeights Packet.

8) DraftSlotsQueryResponse

9) ResourceWeights

opening the 2nd crafting screen

Once we have decided what schematic to use we mark it and hit the next button.

Upon hitting the button, the client sends the SelectDraftSchemaric-CRC via CommanQueueEnqueue and the server responds with creating the Schematic Object and the (not the but rather a) tangible object for the Object we want to craft. If all the objects were send in the right way the client will display the second crafting screen, after the MSCO 7 has been send. Please note, that the MSCO 7 will be discarded, and the screen remain unchanged, if the objects are in some way faulty.

client

(1) 0x89242E02 selectdraftschematic request to open the 2nd craft screen

server

(Manufacture Schematic Object 2) server -> client MSCO Object (init, link, 3,6,8,9, close schem object))

(Tangible Object 3) server -> client ONAT Object (init, link, 3,6,8,9, close schem object))

(DraftSlots (00000103) 4) server -> client links tool, schematic and tano and sends the slotconfiguration))

(MSCO7 5) server -> client MSCO7 aka the slotobject))

Slot Configuration aka Screen 2

During this crafting stage the client will send a lot (!) attributesbatches. These are used to keep track of the inventory items that will get represented in the inventory view. We can now fill the slots by either dragging the resource component over the slot we wish to fill it in, or by doubleclicking on said component. When we doubleclick, the component will be filled into the next free fitting slot.

On filling a component in a slot, the client sends a CraftFillSlot Packet, in which the ID of the ingredient, the slot and an updatecounter, which increments by 1 are sent. Please note that the counter keeps incrementing through unrelated crafting sessions

client

(1) CraftFillSlot

in the server answer, we update the resource stack size and send all in all 3 Packets to update our slot configuration.

the 1st is the msco 6 delta, where we tell the client, which slot were filling (the slot int send by the client in the craftfillslot Packet), the 2nd is the MSCO 7 delta, which updates our Slot Object. The MSCO is quite peculiar, AND the first MSCO7 delta differs in live significantly from the others. From my experience this isnt necessary though.

server

(2) ONCR 3 delta (update resource stack size)

(3) MSCO 6 delta (to keep track of filled slots )

(4) MSCO 7 delta MSCO 7 aka the slotobject update

One odditie with the MSCO 7 is, that the MSCO delta for the first filled slot contains updates for every objectmember, whereas the msco 7 deltas for all subsequent slotfills onlz contain the necessary Object updates.

To finalize our slot update we have to send

(5) Generic Int response (slot finalization)