Difference between revisions of "MSCO07"
From SWGANH Wiki
(→Deltas Struct) |
|||
| (19 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | {{PageHeader|Baseline|MSCO 07}} | |
{|align="center" | {|align="center" | ||
|- | |- | ||
| Line 15: | Line 15: | ||
Few bytes left to figure out on this one. | Few bytes left to figure out on this one. | ||
<pre> | <pre> | ||
| − | SHORT: | + | SHORT: ObjOpperandCount |
| − | + | INT: SlotNameList | |
| − | INT: | + | INT: UpdateCounter |
| − | INT: | + | |
{ | { | ||
| − | + | ASTRING: SlotNameTable | |
| − | + | INT: NotUsed | |
| − | + | ASTRING: SlotName | |
} | } | ||
| − | + | INT: SlotContentsList | |
| − | INT: | + | INT: UpdateCounter |
| − | INT: | + | |
{ | { | ||
| − | + | INT: SlotContentType | |
} | } | ||
| − | + | INT: IngridientList | |
| − | INT: | + | INT: UpdateCounter |
| − | INT: | + | |
{ | { | ||
| − | + | INT: Counter | |
| − | + | { | |
| − | + | LONG: IngredientID | |
| − | LONG: | + | } |
| − | + | ||
} | } | ||
| − | + | INT: QuantityList | |
| − | INT: | + | INT: UpdateCounter |
| − | INT: | + | |
{ | { | ||
| − | + | INT: Counter | |
| − | + | { | |
| − | INT: | + | INT: IngredientQuantity |
| − | + | } | |
} | } | ||
| − | + | INT: SlotQualityList | |
| − | INT: | + | INT: UpdateCounter |
| − | INT: | + | |
{ | { | ||
| − | + | FLOAT: Quality | |
} | } | ||
| − | + | INT: CleanSlotList | |
| − | INT: | + | INT: UpdateCounter |
| − | INT: | + | |
{ | { | ||
| − | + | INT: Value | |
} | } | ||
| − | + | INT: SlotIndexList | |
| − | INT: | + | INT: UpdateCounter |
| − | INT: | + | |
{ | { | ||
| − | + | INT: SlotIndex | |
} | } | ||
| − | + | BYTE: IngredientsCounter | |
| − | + | INT: ExperimentationNameList | |
| − | BYTE: | + | INT: UpdateCounter |
| − | + | ||
| − | + | ||
| − | INT: | + | |
| − | INT: | + | |
{ | { | ||
| − | + | ASTRING: ExperimentationTable | |
| − | + | INT: NotUsed | |
| − | + | ASTRING: ExperimentationName | |
| − | + | ||
} | } | ||
| − | + | INT: CurrentExperimentationValueList | |
| − | + | INT: UpdateCounter | |
| − | INT: | + | |
| − | INT: | + | |
{ | { | ||
| − | + | FLOAT: CurrentExperimentationValue | |
} | } | ||
| − | + | INT: ExperimentationOffsetList | |
| − | + | INT: UpdateCounter | |
| − | INT: | + | |
| − | INT: | + | |
{ | { | ||
| − | + | FLOAT: ExperimentationValueOffset | |
} | } | ||
| − | + | INT: BlueBarSizeList | |
| − | + | INT: UpdateCounter | |
| − | INT: | + | |
| − | INT: | + | |
{ | { | ||
| − | + | FLOAT: Size | |
} | } | ||
| − | + | INT: MaxExperimentationList | |
| − | + | INT: UpdateCounter | |
| − | INT: | + | |
| − | INT: | + | |
{ | { | ||
| − | + | FLOAT: MaxExperimentationValue | |
} | } | ||
| − | + | INT: CustomizationNameList | |
| − | + | INT: UpdateCounter | |
| − | INT: | + | |
| − | INT: | + | |
{ | { | ||
| − | + | ASTRING: CustomizationName | |
} | } | ||
| + | INT: PalleteSelectionList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | INT: PalleteSelection | ||
| + | } | ||
| + | INT: PalleteStartIndexList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | INT: PalleteStartIndex | ||
| + | } | ||
| + | INT: PalleteEndIndexList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | INT: PalleteEndIndex | ||
| + | } | ||
| + | BYTE: CustomizationCounter | ||
| + | FLOAT: RiskFactor | ||
| + | INT: ObjectTemplateCustomizationList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | ASTRING: ObjectTemplateIFF | ||
| + | } | ||
| + | BYTE: ReadyFlag | ||
| + | </pre> | ||
| + | ===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 : | |
<pre> | <pre> | ||
| + | SHORT: UpdateCount | ||
| + | SHORT: UpdateType | ||
| + | { | ||
| + | 00: | ||
| + | INT: SlotNameList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | ASTRING: SlotNameTable | ||
| + | INT: NotUsed | ||
| + | ASTRING: SlotName | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | ASTRING: SlotNameTable | ||
| + | INT: NotUsed | ||
| + | ASTRING: SlotName | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | ASTRING: SlotNameTable | ||
| + | INT: NotUsed | ||
| + | ASTRING: SlotName | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 01: | ||
| + | INT: SlotContentsList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | INT: SlotContentType | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | INT: SlotContentType | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | INT: SlotContentType | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 02: | ||
| + | INT: IngridientList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | INT: Counter | ||
| + | { | ||
| + | LONG: IngredientID | ||
| + | } | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | INT: Counter | ||
| + | { | ||
| + | LONG: IngredientID | ||
| + | } | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | INT: Counter | ||
| + | { | ||
| + | LONG: IngredientID | ||
| + | } | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 03: | ||
| + | INT: QuantityList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | INT: Counter | ||
| + | { | ||
| + | INT: IngredientQuantity | ||
| + | } | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | INT: Counter | ||
| + | { | ||
| + | INT: IngredientQuantity | ||
| + | } | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | INT: Counter | ||
| + | { | ||
| + | INT: IngredientQuantity | ||
| + | } | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 04: | ||
| + | INT: SlotQualityList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | FLOAT: Quality | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | FLOAT: Quality | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | FLOAT: Quality | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 05: | ||
| + | INT: CleanSlotList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | INT: Value | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | INT: Value | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | INT: Value | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 06: | ||
| + | INT: SlotIndexList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | INT: SlotIndex | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | INT: SlotIndex | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | INT: SlotIndex | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 07: | ||
| + | BYTE: IngredientsCounter | ||
| + | 08: | ||
| + | INT: ExperimentationNameList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | ASTRING: ExperimentationTable | ||
| + | INT: NotUsed | ||
| + | ASTRING: ExperimentationName | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | ASTRING: ExperimentationTable | ||
| + | INT: NotUsed | ||
| + | ASTRING: ExperimentationName | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | ASTRING: ExperimentationTable | ||
| + | INT: NotUsed | ||
| + | ASTRING: ExperimentationName | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 09: | ||
| + | INT: CurrentExperimentationValueList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | FLOAT: CurrentExperimentationValue | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | FLOAT: CurrentExperimentationValue | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | FLOAT: CurrentExperimentationValue | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 0A: | ||
| + | INT: ExperimentationOffsetList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | FLOAT: ExperimentationValueOffset | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | FLOAT: ExperimentationValueOffset | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | FLOAT: ExperimentationValueOffset | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 0B: | ||
| + | INT: BlueBarSizeList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | FLOAT: Size | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | FLOAT: Size | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | FLOAT: Size | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 0C: | ||
| + | INT: MaxExperimentationList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | FLOAT: MaxExperimentationValue | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | FLOAT: MaxExperimentationValue | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | FLOAT: MaxExperimentationValue | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 0D: | ||
| + | INT: CustomizationNameList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | ASTRING: CustomizationName | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | ASTRING: CustomizationName | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | ASTRING: CustomizationName | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 0E: | ||
| + | INT: PalleteSelectionList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | INT: PalleteSelection | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | INT: PalleteSelection | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | INT: PalleteSelection | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 0F: | ||
| + | INT: PalleteStartIndexList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | INT: PalleteStartIndex | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | INT: PalleteStartIndex | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | INT: PalleteStartIndex | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 10: | ||
| + | INT: PalleteEndIndexList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | INT: PalleteEndIndex | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | INT: PalleteEndIndex | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | INT: PalleteEndIndex | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 11: | ||
| + | BYTE: CustomizationCounter | ||
| + | 12: | ||
| + | FLOAT: RiskFactor | ||
| + | 13: | ||
| + | INT: ObjectTemplateCustomizationList | ||
| + | INT: UpdateCounter | ||
| + | { | ||
| + | BYTE: SubType | ||
| + | { | ||
| + | 00:(remove) | ||
| + | SHORT: Index | ||
| + | 01:(add) | ||
| + | SHORT: Index | ||
| + | ASTRING: ObjectTemplateIFF | ||
| + | 02:(change) | ||
| + | SHORT: Index | ||
| + | ASTRING: ObjectTemplateIFF | ||
| + | 03:(resetall) | ||
| + | SHORT: NewListSize | ||
| + | { | ||
| + | ASTRING: ObjectTemplateIFF | ||
| + | } | ||
| + | 04:(clear) | ||
| + | } | ||
| + | } | ||
| + | 14: | ||
| + | BYTE: ReadyFlag | ||
| + | } | ||
| + | </pre> | ||
| − | + | |valign=top| | |
| + | ===Variable Descriptions=== | ||
| + | ---- | ||
| − | + | Obj_OperandCount = | |
| − | + | ---- | |
| − | + | ||
| − | + | ===Tags=== | |
| + | ---- | ||
| + | {| align="center" | ||
| + | |- | ||
| + | ||{{75%}} | ||
| + | |- | ||
| + | ||{{ServerPacket}} | ||
| + | |- | ||
| + | |} | ||
| + | |} | ||
| − | + | ===Xenos' Notes=== | |
| − | + | ---- | |
| − | + | <pre> | |
| − | + | ObjOpperandCount = 21 | |
| − | + | SlotName: | |
| − | + | The name of the ingredient slot in the schematic. This does not appear to be displayed | |
| − | + | as that is done by the DraftSlots(0x1BF) ObjectController. However it may be used | |
| − | + | to tie the slots together. | |
| − | + | SlotContents: | |
| − | + | This is a bitmask used to flag the contents of the slot once it contains something. | |
| − | + | 4 = resource | |
| − | + | 2 = component_item | |
| − | + | 1 = ?? | |
| − | + | 0 = nothing | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | IngridientList: | ||
| + | each element of this array contains an array of objectIDs for the ingredients. | ||
| + | Resources use the GlobalID of the resource in the slot (NOT THE CONTAINER) | ||
| + | Items use the objectID of the item object in the slot. For multiple components | ||
| + | per slot, each objectID is mentioned. The first objectID is the model that will | ||
| + | be displayed inside the slot. | ||
| + | QuantityList: | ||
| + | each element of this array contains an array of integers describing the quantity | ||
| + | of the elements in the IngredientList arrays (theres a 1 to 1 correlation). | ||
| + | Resources will simply have the quantity of the resource. | ||
| + | Items, because each objectID has to be used, contain a list of 1's. | ||
| + | IE. 3 objects in the slot. | ||
| + | IngedientList = [object1][object2][object3] | ||
| + | Quantitylist = [1][1][1], meaning 1 of each item. | ||
| + | The client will SUM this up and use it as the total. | ||
| + | SlotQuality: | ||
| + | This float does not do ANYTHING to the slot. I am ASSUMING the following: | ||
| + | before resource quality was automatically computed by the client, the server | ||
| + | would use this to show how much of the quality bar to fill AFTER an ingredient was | ||
| + | added. However people complained and SOE had this bar now show when highlighting | ||
| + | a resource to use. Because of the automation this variable was removed from use, | ||
| + | but not from packets. (lazy bastards). | ||
| − | + | CleanSlot: | |
| + | This integer seems to only be able to break the display when not set to 0. | ||
| + | On Baseline, the list is set to -1 for each element. Once something has been | ||
| + | added, the server sets it to 0. On remove, it remains 0. and readding keeps it at 0. | ||
| + | Using anything else while it is occupied causes it to incorrectly display everything. | ||
| + | It may be used as an offset for the SlotIndex because sometimes I was able to get it | ||
| + | to change the quantity of slot2 using an update to slot1 and this with a value of 1. | ||
| + | However it still just screws things up. Initialize and leave to 0 and just dont use it. | ||
| + | (Note: Its safe to set it back to -1 on removeslot, but on addslot it MUST BE 0). | ||
| − | + | SlotIndex: | |
| − | + | On Baseline this array is set to have each element describe its index in the array, | |
| − | + | possibly using it as the overall slot index reference that all the following packets | |
| + | use to describe which slot they are affecting. Start from 0 and count up by 1 for each | ||
| + | slot. | ||
| + | IE. 3 slots | ||
| + | SlotIndexList = [0][1][2] | ||
| − | + | IngredientsCounter: | |
| − | + | This is like an update counter for any change to the slot. Each time a slot is modified | |
| − | + | this increments by 4 per slot. Since initialization is considered a modification, it | |
| − | + | should on baseline be set as 4*slots. | |
| − | + | IE. 3 slots = 0x0C, or 12. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ExperimentationName: | |
| − | + | The name of the experimentation pools this schematic has. Each pool name is displayed | |
| − | + | in order as experimentable during the experimentation phase. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | CurrentExperimentationValue: | |
| + | This is considered as the "QUALITY" the item has for each area of experimentation. | ||
| + | This value is a percentage (decimal from 0->1) and is displayed as the initial | ||
| + | assembly quality as well as the current quality each step of experimentation. | ||
| − | + | ExperimentationOffset: | |
| + | each element in this array offsets the ExperimentationValue with the formula: | ||
| + | DisplayValue = ExperimentationValue - Offset | ||
| + | So far all schematics just set this to 0 because there really is no point in | ||
| + | penalizing the player. This may be used for experimentation failures, however | ||
| + | the server can just modify the current value and reduce it. I can't think | ||
| + | of any optimization this could give a server either, so set to 0 and leave alone. | ||
| − | + | BlueBarSize: | |
| + | the elements of this array are initialized to 1 in the baseline. Ive yet to | ||
| + | capture a packet that causes this to change otherwise. From experimenting | ||
| + | I found this is a percentage (decimal 0->1) that affects the size of the | ||
| + | blue bar pointed to by the arrow for each experimentation pool. It may | ||
| + | potentially be modified by failures, however I never even noticed this | ||
| + | blue par from all my time of play. So I deem it useless. set to 1 and move on. | ||
| − | + | MaxExperimentation: | |
| + | This is the maximum possible experimentation for each pool. It is solely based | ||
| + | on the resource quality calculated with the average resource weight of each pool. | ||
| + | For example, ARW = 740 makes this .74 or 74% maximum. Experimentation can not | ||
| + | exceed this quality. This is also a percentage (decimal from 0->1). | ||
| − | + | CustomizationName: | |
| − | + | This is the name of the customization variables for the given schematic. | |
| + | So far only things I've seen are: | ||
| + | "private/index_color_1" | ||
| + | "private/index_color_2" | ||
| + | for items that can have 2 different pallete colors modified. These can | ||
| + | be found inside the .IFF files so look there when building schematicDB. | ||
| − | + | PalleteSelection: | |
| − | + | This is the default and selected value for pallete customization. The | |
| − | + | server initializes it to the default colors, and then changes it after | |
| − | + | the client sends a CraftCustomization packet. It then can use this | |
| − | + | value to build the CustomizationString for MSCO6. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | PalleteStartIndex: | |
| − | + | Much like how slots and experimentation had a variable that SEEMED to | |
| − | + | screw around with the index/starting place of each display.. customization | |
| − | This | + | has this. This variable selects which pallete color to START from when |
| − | + | displaying the available options. The number of options is given by: | |
| + | Options = PalleteEndIndex - PalleteStartIndex | ||
| + | The server only seems to ever set this to 0. It was also noticed that | ||
| + | regardless of the color displayed on the left. When sampling options | ||
| + | the item model DOES NOT factor in this variable. So if you set this to 1 | ||
| + | and the colors are white gray black red and you choose red. It will | ||
| + | DISPLAY black with the item (red is 3, 3-1 is 2, 2 is black). | ||
| + | In conclusion: set to 0 and use PalleteEndIndex. | ||
| − | + | PalleteEndIndex: | |
| − | So that | + | the element in this array determines how many pallete options will be |
| − | + | available for customization. Starting from index PalleteStartIndex (should be 0), | |
| + | PalleteEndIndex number of options will be available. The most pallete options | ||
| + | so far seen are palletes with 255 options. So for that pallete you would set this | ||
| + | to 255 to have all of them, or a smaller number to only display the first of those | ||
| + | options. (It also explains why the latter pallete colors are more exotic than | ||
| + | the first ones ! ). | ||
| − | + | CustomizationCounter: | |
| + | Just like the IngedientsCounter, this is an update counter for the Customization. | ||
| + | However, since customization only applies once, it is initialized to the number | ||
| + | of customization palletes, and incremented by the number of customization palletes, | ||
| + | and this happens only once. | ||
| − | + | RiskFactor: | |
| − | // | + | This value is used to compute the risk assessed with experimentation. It is based |
| − | + | on the Average Mallability of the Resources used along with your Experimentation Skill | |
| + | and how many Experimentation Points you use, as well as how many Additional Pools | ||
| + | you are modifying. | ||
| + | The formulas are as follows: | ||
| + | RiskFactor = (AverageMallability - 500)/40 + ExperimentationSkill | ||
| + | Risk = (50 - RiskFactor + 5*PointsUsed)/ 100 | ||
| + | If negative, set to 0. Then Add for additional pools. | ||
| + | Risk += (5*AdditionalPools)/100 | ||
| − | + | Note: PointsUsed is the maximum of the number of points put into ANY ONE POOL during | |
| − | 03 | + | that experimentation roll. So if you add 5 points to pool1 and 3 points into pool2, |
| + | you only use 5 for the PointsUsed value and 1 for the AdditionalPools value. | ||
| + | It has also been observed regardless of how much experimentation skill you have | ||
| + | the 5% is added per additional pool used and it is always added. | ||
| + | Lesson: Just modify 1 pool at a time and go for multiple experimentation rolls. lol | ||
| − | // | + | ObjectTemplateCustomization: |
| − | + | Some customization allows for the changing of the model itself. | |
| − | + | Examples: Fountain, Gungan Head, Streetlamps, oh.. and Lightsabers! | |
| + | To add this option, put a list of the objectTemplateIFF path into this array. | ||
| + | This includes the directory and extension ie. "object/wearables/whatever.iff" | ||
| + | This then becomes a drop down list in customization and this option gets set | ||
| + | in the MSCO6 afterwards, and then applied to the prototype as the new ObjectCRC. | ||
| − | + | ReadyFlag: | |
| − | + | Set to 1 if the schematic is ready | |
| − | + | Set to 0 if the schematic isn't. | |
| − | + | Just set to 1 on initialization and leave it be! | |
| − | + | ||
| − | + | ||
| − | + | ||
</pre> | </pre> | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | ===Sample Packet=== | ||
---- | ---- | ||
| + | <pre> | ||
| + | </pre> | ||
Latest revision as of 20:32, 15 June 2008
Baseline - MSCO 07
SWGANH Wiki is a repository of Star Wars Galaxies Developer information. This site is only meant to be used by SWGANH Developer team.
|
BaseLine StructFew bytes left to figure out on this one.
SHORT: ObjOpperandCount
INT: SlotNameList
INT: UpdateCounter
{
ASTRING: SlotNameTable
INT: NotUsed
ASTRING: SlotName
}
INT: SlotContentsList
INT: UpdateCounter
{
INT: SlotContentType
}
INT: IngridientList
INT: UpdateCounter
{
INT: Counter
{
LONG: IngredientID
}
}
INT: QuantityList
INT: UpdateCounter
{
INT: Counter
{
INT: IngredientQuantity
}
}
INT: SlotQualityList
INT: UpdateCounter
{
FLOAT: Quality
}
INT: CleanSlotList
INT: UpdateCounter
{
INT: Value
}
INT: SlotIndexList
INT: UpdateCounter
{
INT: SlotIndex
}
BYTE: IngredientsCounter
INT: ExperimentationNameList
INT: UpdateCounter
{
ASTRING: ExperimentationTable
INT: NotUsed
ASTRING: ExperimentationName
}
INT: CurrentExperimentationValueList
INT: UpdateCounter
{
FLOAT: CurrentExperimentationValue
}
INT: ExperimentationOffsetList
INT: UpdateCounter
{
FLOAT: ExperimentationValueOffset
}
INT: BlueBarSizeList
INT: UpdateCounter
{
FLOAT: Size
}
INT: MaxExperimentationList
INT: UpdateCounter
{
FLOAT: MaxExperimentationValue
}
INT: CustomizationNameList
INT: UpdateCounter
{
ASTRING: CustomizationName
}
INT: PalleteSelectionList
INT: UpdateCounter
{
INT: PalleteSelection
}
INT: PalleteStartIndexList
INT: UpdateCounter
{
INT: PalleteStartIndex
}
INT: PalleteEndIndexList
INT: UpdateCounter
{
INT: PalleteEndIndex
}
BYTE: CustomizationCounter
FLOAT: RiskFactor
INT: ObjectTemplateCustomizationList
INT: UpdateCounter
{
ASTRING: ObjectTemplateIFF
}
BYTE: ReadyFlag
Deltas StructI'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 :
SHORT: UpdateCount
SHORT: UpdateType
{
00:
INT: SlotNameList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
ASTRING: SlotNameTable
INT: NotUsed
ASTRING: SlotName
02:(change)
SHORT: Index
ASTRING: SlotNameTable
INT: NotUsed
ASTRING: SlotName
03:(resetall)
SHORT: NewListSize
{
ASTRING: SlotNameTable
INT: NotUsed
ASTRING: SlotName
}
04:(clear)
}
}
01:
INT: SlotContentsList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
INT: SlotContentType
02:(change)
SHORT: Index
INT: SlotContentType
03:(resetall)
SHORT: NewListSize
{
INT: SlotContentType
}
04:(clear)
}
}
02:
INT: IngridientList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT:
01:(add)
SHORT: Index
INT: Counter
{
LONG: IngredientID
}
02:(change)
SHORT: Index
INT: Counter
{
LONG: IngredientID
}
03:(resetall)
SHORT: NewListSize
{
INT: Counter
{
LONG: IngredientID
}
}
04:(clear)
}
}
03:
INT: QuantityList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
INT: Counter
{
INT: IngredientQuantity
}
02:(change)
SHORT: Index
INT: Counter
{
INT: IngredientQuantity
}
03:(resetall)
SHORT: NewListSize
{
INT: Counter
{
INT: IngredientQuantity
}
}
04:(clear)
}
}
04:
INT: SlotQualityList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
FLOAT: Quality
02:(change)
SHORT: Index
FLOAT: Quality
03:(resetall)
SHORT: NewListSize
{
FLOAT: Quality
}
04:(clear)
}
}
05:
INT: CleanSlotList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
INT: Value
02:(change)
SHORT: Index
INT: Value
03:(resetall)
SHORT: NewListSize
{
INT: Value
}
04:(clear)
}
}
06:
INT: SlotIndexList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
INT: SlotIndex
02:(change)
SHORT: Index
INT: SlotIndex
03:(resetall)
SHORT: NewListSize
{
INT: SlotIndex
}
04:(clear)
}
}
07:
BYTE: IngredientsCounter
08:
INT: ExperimentationNameList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
ASTRING: ExperimentationTable
INT: NotUsed
ASTRING: ExperimentationName
02:(change)
SHORT: Index
ASTRING: ExperimentationTable
INT: NotUsed
ASTRING: ExperimentationName
03:(resetall)
SHORT: NewListSize
{
ASTRING: ExperimentationTable
INT: NotUsed
ASTRING: ExperimentationName
}
04:(clear)
}
}
09:
INT: CurrentExperimentationValueList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
FLOAT: CurrentExperimentationValue
02:(change)
SHORT: Index
FLOAT: CurrentExperimentationValue
03:(resetall)
SHORT: NewListSize
{
FLOAT: CurrentExperimentationValue
}
04:(clear)
}
}
0A:
INT: ExperimentationOffsetList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
FLOAT: ExperimentationValueOffset
02:(change)
SHORT: Index
FLOAT: ExperimentationValueOffset
03:(resetall)
SHORT: NewListSize
{
FLOAT: ExperimentationValueOffset
}
04:(clear)
}
}
0B:
INT: BlueBarSizeList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
FLOAT: Size
02:(change)
SHORT: Index
FLOAT: Size
03:(resetall)
SHORT: NewListSize
{
FLOAT: Size
}
04:(clear)
}
}
0C:
INT: MaxExperimentationList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
FLOAT: MaxExperimentationValue
02:(change)
SHORT: Index
FLOAT: MaxExperimentationValue
03:(resetall)
SHORT: NewListSize
{
FLOAT: MaxExperimentationValue
}
04:(clear)
}
}
0D:
INT: CustomizationNameList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
ASTRING: CustomizationName
02:(change)
SHORT: Index
ASTRING: CustomizationName
03:(resetall)
SHORT: NewListSize
{
ASTRING: CustomizationName
}
04:(clear)
}
}
0E:
INT: PalleteSelectionList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
INT: PalleteSelection
02:(change)
SHORT: Index
INT: PalleteSelection
03:(resetall)
SHORT: NewListSize
{
INT: PalleteSelection
}
04:(clear)
}
}
0F:
INT: PalleteStartIndexList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
INT: PalleteStartIndex
02:(change)
SHORT: Index
INT: PalleteStartIndex
03:(resetall)
SHORT: NewListSize
{
INT: PalleteStartIndex
}
04:(clear)
}
}
10:
INT: PalleteEndIndexList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
INT: PalleteEndIndex
02:(change)
SHORT: Index
INT: PalleteEndIndex
03:(resetall)
SHORT: NewListSize
{
INT: PalleteEndIndex
}
04:(clear)
}
}
11:
BYTE: CustomizationCounter
12:
FLOAT: RiskFactor
13:
INT: ObjectTemplateCustomizationList
INT: UpdateCounter
{
BYTE: SubType
{
00:(remove)
SHORT: Index
01:(add)
SHORT: Index
ASTRING: ObjectTemplateIFF
02:(change)
SHORT: Index
ASTRING: ObjectTemplateIFF
03:(resetall)
SHORT: NewListSize
{
ASTRING: ObjectTemplateIFF
}
04:(clear)
}
}
14:
BYTE: ReadyFlag
}
|
Variable DescriptionsObj_OperandCount = Tags
|
Xenos' Notes
ObjOpperandCount = 21 SlotName: The name of the ingredient slot in the schematic. This does not appear to be displayed as that is done by the DraftSlots(0x1BF) ObjectController. However it may be used to tie the slots together. SlotContents: This is a bitmask used to flag the contents of the slot once it contains something. 4 = resource 2 = component_item 1 = ?? 0 = nothing IngridientList: each element of this array contains an array of objectIDs for the ingredients. Resources use the GlobalID of the resource in the slot (NOT THE CONTAINER) Items use the objectID of the item object in the slot. For multiple components per slot, each objectID is mentioned. The first objectID is the model that will be displayed inside the slot. QuantityList: each element of this array contains an array of integers describing the quantity of the elements in the IngredientList arrays (theres a 1 to 1 correlation). Resources will simply have the quantity of the resource. Items, because each objectID has to be used, contain a list of 1's. IE. 3 objects in the slot. IngedientList = [object1][object2][object3] Quantitylist = [1][1][1], meaning 1 of each item. The client will SUM this up and use it as the total. SlotQuality: This float does not do ANYTHING to the slot. I am ASSUMING the following: before resource quality was automatically computed by the client, the server would use this to show how much of the quality bar to fill AFTER an ingredient was added. However people complained and SOE had this bar now show when highlighting a resource to use. Because of the automation this variable was removed from use, but not from packets. (lazy bastards). CleanSlot: This integer seems to only be able to break the display when not set to 0. On Baseline, the list is set to -1 for each element. Once something has been added, the server sets it to 0. On remove, it remains 0. and readding keeps it at 0. Using anything else while it is occupied causes it to incorrectly display everything. It may be used as an offset for the SlotIndex because sometimes I was able to get it to change the quantity of slot2 using an update to slot1 and this with a value of 1. However it still just screws things up. Initialize and leave to 0 and just dont use it. (Note: Its safe to set it back to -1 on removeslot, but on addslot it MUST BE 0). SlotIndex: On Baseline this array is set to have each element describe its index in the array, possibly using it as the overall slot index reference that all the following packets use to describe which slot they are affecting. Start from 0 and count up by 1 for each slot. IE. 3 slots SlotIndexList = [0][1][2] IngredientsCounter: This is like an update counter for any change to the slot. Each time a slot is modified this increments by 4 per slot. Since initialization is considered a modification, it should on baseline be set as 4*slots. IE. 3 slots = 0x0C, or 12. ExperimentationName: The name of the experimentation pools this schematic has. Each pool name is displayed in order as experimentable during the experimentation phase. CurrentExperimentationValue: This is considered as the "QUALITY" the item has for each area of experimentation. This value is a percentage (decimal from 0->1) and is displayed as the initial assembly quality as well as the current quality each step of experimentation. ExperimentationOffset: each element in this array offsets the ExperimentationValue with the formula: DisplayValue = ExperimentationValue - Offset So far all schematics just set this to 0 because there really is no point in penalizing the player. This may be used for experimentation failures, however the server can just modify the current value and reduce it. I can't think of any optimization this could give a server either, so set to 0 and leave alone. BlueBarSize: the elements of this array are initialized to 1 in the baseline. Ive yet to capture a packet that causes this to change otherwise. From experimenting I found this is a percentage (decimal 0->1) that affects the size of the blue bar pointed to by the arrow for each experimentation pool. It may potentially be modified by failures, however I never even noticed this blue par from all my time of play. So I deem it useless. set to 1 and move on. MaxExperimentation: This is the maximum possible experimentation for each pool. It is solely based on the resource quality calculated with the average resource weight of each pool. For example, ARW = 740 makes this .74 or 74% maximum. Experimentation can not exceed this quality. This is also a percentage (decimal from 0->1). CustomizationName: This is the name of the customization variables for the given schematic. So far only things I've seen are: "private/index_color_1" "private/index_color_2" for items that can have 2 different pallete colors modified. These can be found inside the .IFF files so look there when building schematicDB. PalleteSelection: This is the default and selected value for pallete customization. The server initializes it to the default colors, and then changes it after the client sends a CraftCustomization packet. It then can use this value to build the CustomizationString for MSCO6. PalleteStartIndex: Much like how slots and experimentation had a variable that SEEMED to screw around with the index/starting place of each display.. customization has this. This variable selects which pallete color to START from when displaying the available options. The number of options is given by: Options = PalleteEndIndex - PalleteStartIndex The server only seems to ever set this to 0. It was also noticed that regardless of the color displayed on the left. When sampling options the item model DOES NOT factor in this variable. So if you set this to 1 and the colors are white gray black red and you choose red. It will DISPLAY black with the item (red is 3, 3-1 is 2, 2 is black). In conclusion: set to 0 and use PalleteEndIndex. PalleteEndIndex: the element in this array determines how many pallete options will be available for customization. Starting from index PalleteStartIndex (should be 0), PalleteEndIndex number of options will be available. The most pallete options so far seen are palletes with 255 options. So for that pallete you would set this to 255 to have all of them, or a smaller number to only display the first of those options. (It also explains why the latter pallete colors are more exotic than the first ones ! ). CustomizationCounter: Just like the IngedientsCounter, this is an update counter for the Customization. However, since customization only applies once, it is initialized to the number of customization palletes, and incremented by the number of customization palletes, and this happens only once. RiskFactor: This value is used to compute the risk assessed with experimentation. It is based on the Average Mallability of the Resources used along with your Experimentation Skill and how many Experimentation Points you use, as well as how many Additional Pools you are modifying. The formulas are as follows: RiskFactor = (AverageMallability - 500)/40 + ExperimentationSkill Risk = (50 - RiskFactor + 5*PointsUsed)/ 100 If negative, set to 0. Then Add for additional pools. Risk += (5*AdditionalPools)/100 Note: PointsUsed is the maximum of the number of points put into ANY ONE POOL during that experimentation roll. So if you add 5 points to pool1 and 3 points into pool2, you only use 5 for the PointsUsed value and 1 for the AdditionalPools value. It has also been observed regardless of how much experimentation skill you have the 5% is added per additional pool used and it is always added. Lesson: Just modify 1 pool at a time and go for multiple experimentation rolls. lol ObjectTemplateCustomization: Some customization allows for the changing of the model itself. Examples: Fountain, Gungan Head, Streetlamps, oh.. and Lightsabers! To add this option, put a list of the objectTemplateIFF path into this array. This includes the directory and extension ie. "object/wearables/whatever.iff" This then becomes a drop down list in customization and this option gets set in the MSCO6 afterwards, and then applied to the prototype as the new ObjectCRC. ReadyFlag: Set to 1 if the schematic is ready Set to 0 if the schematic isn't. Just set to 1 on initialization and leave it be!
