Difference between revisions of "Crafting (Sequence)"
(→Assembly report) |
|||
| Line 158: | Line 158: | ||
This is done by the client WITHOUT further server/client communication | This is done by the client WITHOUT further server/client communication | ||
| + | |||
| + | =experimentation= | ||
| + | |||
| + | =prototyp creation= | ||
| + | |||
| + | =schematic= | ||
Revision as of 16:53, 15 April 2007
Contents
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.
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
(Tangible Object 3) server -> client ONAT Object (init, link, 3,6,8,9, close schem object))
(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
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 only contain the necessary Object updates.
To finalize our slot update we have to send
(5) Generic Int response (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.
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 2) the crafting stage (Yalp9, delta var 2, value 3)
then an MSCO 3 delta, which updates section 5 is send
and an MSCO 7 delta, which updates section 9, 11,12 and 18
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.
This is done by the client WITHOUT further server/client communication
