MSCO07

MSCO Packet Type QuickNav MSCO03 - MSCO06 - MSCO07 - MSCO08 - MSCO09

BaseLine Struct Few bytes left to figure out on this one. SHORT: Operand Count //Part 0 INT: Slot Counter INT: Update Counter { A_STRING: Slot String Lookup Directory INT: Unknown A_STRING: Slot Name } //Part 1 INT: Counter 1 INT: Update Counter { INT: Unknown, must be 4 if slot is filled } //Part 2 INT: Counter 2 INT: Update Counter { //here go the ingredient IDs INT: Counter for IngredientID { LONG: ingredient ID } } //Part 3 INT: Counter 3 INT: Update Counter { INT: Counter for Ingredient Amount { INT: amount of ingredient filled into slot } } //Part 4 INT: Counter 4 INT: Update Counter { INT: Unknown } //Part 5 INT: Counter INT: Update Counter { INT: Unknown } //Part 6 INT: Counter INT: Update Counter { INT: Unknown } //Part 7 BYTE: some sort of stale flag probably not used //Part 8 Experimentation Attributes INT: Counter INT: Update Counter { A_STRING: dir to look up string (crafting) INT: unknown A_STRING: Areas of Experimentation for the item eg expEffectiveness; expRange } //Part 9 Experimentation attributes Values INT: Counter INT: Update Counter { FLOAT: Experimentation Attribute Value } //Part 10 not tested yet INT: Counter INT: Update Counter { INT: Unknown } //Part 11 Assembly Attributes Values -> percentage of assembly succes // 100% = highest possible (30%) INT: Counter INT: Update Counter { FLOAT: Assembly Attribute Value } //Part 12 Max reachable Experimentation Attribute Value INT: Counter INT: Update Counter { FLOAT: Max Experimentation Attribute Value } //Part 18 unknown yet INT: Counter INT: Update Counter { FLOAT: failure probability given as 0.0 to 100.0 } Deltas Struct I've written the deltas part numbers in the baseline above. This Packet is to huge that one could make sense of it without structure. Thus the Delta parts themselves are further divided into - lets call them - slotspots. For every slot there is a 3 Byte slotspot in the Deltapart, save part 7, where the byte stale flag (??) is. So that every slotspot can be modified on its own and the monster gets more palateable the slotspots must be inserted. Think of it as a kind of FlowControl. So to set the amount of resource that got filled into the first slot : //Number of Parts we edit 01 00 //Part 03 00 Part 3 // its the resource entry for 1 slot that gets updated 01 00 00 00 one slot gets updated // update counter 01 00 00 00 *must* be increemented by 1 for every update, else it will be ignored // Slotspot 02 0X 00 02 is either 1 or two, probably a flag that sets a local or global value??? should be 2 however in case of editing slots 00 This is the number of the slot that gets modified ie the listnumber 00 must be zero else the change will be ignored //actual data 01 00 00 00 theres one listentry < note that there always can only be ONE listentry per (standard) slot 08 00 00 00 we enter 8 ResourceUnits in the Slot

Variable Descriptions Obj_OperandCount = Tags 75% This packet has been partially reversed. S→C This packet originates on the server. To Do

---