MSCO07

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.

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

BaseLine Struct Few 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 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 : 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 Descriptions Obj_OperandCount = Tags 75% This packet has been partially reversed. S→C This packet originates on the server.

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!

Sample Packet

---