Revision as of 11:55, 29 December 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 ) , only sent when a slot is completely filled.

(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 only contain the necessary Object updates.

To finalize our slot update we have to send

(5)CraftAcknowledge (0000010C) (slot finalization)

After sending the CraftingSlotResponse, the animation used to symbolize the filling of the slot is stopped and the client displays the updated slot configuration. Additionally (alternatively) we can specify an error message that we want the client to display.

Please note, that slots can be configured as either optional or mandatory. After all mandatory slots have been filled, we can progress to the next crafting stage.

If the player empties a filled slot, the client sends the CraftEmptySlot 2800000108 Packet, in which the number of the slot to empty ( zerobased) and the id of the container where the resource goes are transmitted. After this the Ressource Quantity and Slot Configuration are updated as discussed before. The slotconfiguration gets acknowledged through a

(5) CraftAcknowledge (0000010C) (slot finalization) in which we send the Controller ID of the CraftEmptySlot Message (08 01 00 00).

Assembly report

Hitting the next button starts the Assembly and thus we are going to step 3/6, the crafting (assembly) summary. This is initiated by the client through sending a

CommandQueueEnque nextcraftingstage (6AD8ED4D)

The client uses the same message to end the experimentation process and to start prototype production.

In order to be ableto get past the assembly stage, we have to update

1) the experimentation flag (Yalp9 delta, var 1, value >= 1) if we want to experiment) (optional can be done earlier,same with exp points)

2) the crafting stage (Yalp9, delta var 2, value 3)

3)then an MSCO 3 delta, which updates section 5 is send

4) and an MSCO 7 delta, which updates section 9, 11,12 and 18

5) generic int response to with the result of the assembly

the MSCO3 contains information about basic stats of the object we are going to build. Basically its the string crafting, followed by the string with the name of the stat followed by the value as float.

the MSCO7 section 9 contains the Percentage values for the experimentation attributes (like speed, damage, filling, etc....) as float

section 11 contains the percentage of the assembly, with 100% being the highest possible assembly (thats 30%)as float

section 12 contains the maximum percentage an item can get given the best possible resources. ie it tells the client how long the experimentation bar will be of a given experimentational attribute and how much exp poibts I will need to max it.

section 18 contains the percentual likelihood of success. Im not exactly sure how its calculated. A value of 79.0 gives a risk of 1% in the experimentation window, whereas a value of 9.39 gives a risk assessment of 51% with only 1 ot of experimentation on my gas tool.

When everything is send and we hit the next button, we will have to decide whether we want to create a prototype, a schematic, or if we want to experiment. (only if the exp flag is set, otherwise we go straight to stage 4(customization))

This is done by the client WITHOUT further server/client communication

experimentation

On our decision to start experimenting, the client automatically opens the experimentation screen. This is done without further server / client communication. The client shows a few configurable objects on the experimentation screen, which are initialized through the MSCO 7 delta which is send on opening the Assembly screen and through Yalp 9 deltas.

1) to get the option to open the experimentation screen, the experimentation flag in the YALP 9 must be set.

2) The number of available Experimentation points is set in the YALP 9

3) The length of the Experimentation bar is set as a percentual Value in the MSCO 7 delta. Im not sure if 100% is always the same or if it is resource dependant

4) the already earned percentual amount as given through assembly is send through the MSCO 7 delta.

5) the percentual probability of success is send in the msco 7. It is only send once, so the values for different amounts of experimentation points used at once are calculated clientside. This is a float value. (0.0 to 100.0) 100 means no risk; 0 means very high risk

When we hit the experimentation button the client sends a

CraftExperiment (00000106) Packet

where the Experimentation areas abd their respective amount of Experimentationpoints to be used are determined.

This is answered by the server through sending an MSCO7 delta, where the number of available Experimentation points and the current experimentated percentage are updated.

The items attributes are updated through the MSCO 3 elta, too. I am not sure however whats that supposed to gain. After the schematic object is updated, the experimentation gets updated clientside through sending :

CraftExperimentationResponse (00000113) (Experimentation answer)

Customization

When we hit on the create Prototyp button, we will be taken to the Customization screen. Here we will be able to customize certain aspects of our item (colour, name).

First we get a nextcraftingstage cmd and move to stage 5(creation), with sending a crafting stage update and a generic int response.

Then the client will send the Craft Customization Packet, in which the customization options are transmitted. We answer this Packet by sending the CraftingSlotResponse 0000010C Packet in which we send the Controller ID of the CraftCustomization Message (A5 01 00 00).

Prototype Creation

After the customization Packet, the client sends a Command Queue Enqueue Packet with the CreatePrototyp CRC (0xD61FF415), which comes with 2 arguments, first an update counter, second the practice flag.

The server response to this is

1) acknowledgement by the CraftingSlotResponse Packet which might be better of being called CraftConfigurationAcknowledge

2)Creation of the Actual Item after the creation time, as indicated by the counter on the crafting tool.

The seconds on the crafting tool are displayed through a tano 3. The 9th part of the object [uint32] contains the value t o display on the upper right corner of the item. If zero it will display nothing.

schematic

Cancel Crafting Session

In the case that the crafting session gets canceled by the player, the client sends a Command Queue Enqueue Packet with the cancelcraftingsession crc (83250E2A), which is answered by sending a SetupSwgSharedNetworkMessages_(000001C2) with both int values as zero.

The client will then display the message : The crafting session has been canceled.